JP3836272B2 - 移動ポイント・ツー・ポイント・プロトコル - Google Patents
移動ポイント・ツー・ポイント・プロトコル Download PDFInfo
- Publication number
- JP3836272B2 JP3836272B2 JP12656299A JP12656299A JP3836272B2 JP 3836272 B2 JP3836272 B2 JP 3836272B2 JP 12656299 A JP12656299 A JP 12656299A JP 12656299 A JP12656299 A JP 12656299A JP 3836272 B2 JP3836272 B2 JP 3836272B2
- Authority
- JP
- Japan
- Prior art keywords
- lac
- tunnel
- call
- server
- message
- 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 - Fee Related
Links
- 238000000034 method Methods 0.000 claims description 33
- 230000005641 tunneling Effects 0.000 claims description 5
- 238000004891 communication Methods 0.000 description 27
- 230000006870 function Effects 0.000 description 16
- 230000004044 response Effects 0.000 description 11
- 101000961042 Pseudopleuronectes americanus Ice-structuring protein A Proteins 0.000 description 9
- 101000961041 Pseudopleuronectes americanus Ice-structuring protein B Proteins 0.000 description 9
- 238000012546 transfer Methods 0.000 description 8
- 230000008859 change Effects 0.000 description 6
- 238000010586 diagram Methods 0.000 description 6
- 238000012545 processing Methods 0.000 description 5
- 230000008569 process Effects 0.000 description 3
- 235000008694 Humulus lupulus Nutrition 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000003139 buffering effect Effects 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/168—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP] specially adapted for link layer protocols, e.g. asynchronous transfer mode [ATM], synchronous optical network [SONET] or point-to-point protocol [PPP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0272—Virtual private networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/324—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W36/00—Hand-off or reselection arrangements
- H04W36/0005—Control or signalling for completing the hand-off
- H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/30—Connection release
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
- H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
- H04W88/14—Backbone network devices
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
- Computer And Data Communications (AREA)
Description
【０００１】
【発明の分野】
本発明は、概して、通信に関し、特にパケット通信システムに関する。
関連する主題が、本出願と同じ日付で出願された「多重ホップ・ポイント・ツー・ポイント・プロトコル」と称する日本国特許出願で開示されている。
【０００２】
【発明の背景】
通信手段としてのインターネットの用途の１つは、ワークグループを互いに結合していわゆる「仮想私設網」（Ｖertual Ｐrivate Ｎetwork：ＶＰＮ）を提供する高度データ・バックボーンとしての使用法である。ＶＰＮの応用例の１つは、従業員が、例えば、自宅でインターネットを通じて企業のデータ・ネットワークに遠隔アクセスできる企業環境におけるものである。ＶＰＮは、公衆設備を使用するにもかかわらず、閉じたユーザ・グループに参加する遠隔ユーザにセキュリティと認証を提供する。事実上、ＶＰＮを使用することによって、企業とその従業員にはＷＡＮと同様の手段が提供される（ユーザが直接企業のネットワークにダイヤルする等の方法で、企業のネットワークが直接遠隔アクセスを提供することもできるが、ＶＰＮを使用する方が経済的に有利である）。
【０００３】
ＶＰＮを提供するために、「ポイント・ツー・ポイント・トンネル・プロトコル」（Ｐoint-to-Ｐoint Ｔunneling Ｐrotocol:ＰＰＴＰ）や「レイヤ２フォワーディング」（Ｌayer ２ Ｆorwarding:Ｌ２Ｆ）プロトコルといったトンネル・プロトコルが使用される。一般的に言って、トンネル・プロトコルは、１つのパケットを別のパケットの内部に配置することにより、公衆網を通じて専用データ・ストリームを作成することを可能にする。ＶＰＮの場合、ＩＰパケットが別のＩＰパケットの内部に配置される。業界標準の開発を目指して、インターネット・エンジニアリング・タスク・フォース（Ｉnternet Ｅngineering Ｔask Ｆorce：ＩＥＴＦ）は、「レイヤ２トンネル・プロトコル」（Ｌayer ２ Ｔunnel Ｐrotocol）を開発しているが、これはＰＰＴＰとＬ２Ｆプロトコルの混成物である（例えば、K.Hamzeh、T.Kolar、M.Littlewood、G.Singh Pall、J.Taarud、A.J.Valencia及びW.Vertheinの「レイヤ２トンネルプロトコル”ＬＴ２Ｐ”（Layer Two Tunneling Protocol“L2TP”）」（Internet draft、1998年3月）を参照されたい。）。
【０００４】
遠隔ユーザにとって、ＶＰＮにアクセスする通常の形態は、「在来型の電話サービス」（Ｐlain-Ｏld-Ｔelephone Ｓervice:ＰＯＴＳ）接続により、ＶＰＮを提供する「インターネット・サービス・プロバイダ」（Ｉnternet Ｓervice Ｐrovider：ＩＳＰ）にアクセスすることである。例えば、ユーザは、アナログモデムをパーソナル・コンピュータまたはその相当品に組み込み、特定ＩＳＰ（ここでは「ホーム」ＩＳＰと呼ぶ）のカスタマ・アカウントを取得する（ユーザのパーソナル・コンピュータが上記のトンネル・プロトコルの１つをサポートするよう正しく設定されていることも前提となる）。ユーザは、「ホーム」ＩＳＰに関連する電話番号をダイヤルするなどして簡単にホームＩＳＰにデータ呼出を行った後ＶＰＮに「ログイン(logging in)」してＶＰＮにアクセスする。
【０００５】
【発明の概要】
ＩＳＰへのアクセスは、ネットワーク・アクセス・サーバ（Ｎetwork ＡccessＳerver：ＮＡＳ）を通じて行われる。パーソナル・コミュニケーション・サービス（Ｐersoal Ｃommunication Ｓervice：ＰＣＳ）無線環境では、上記で説明したトンネル・プロトコルによって遠隔ユーザは、既存の呼で、ＶＰＮへのアクセスを提供するＮＡＳを変更できないことが認識された。すなわち、ユーザが物理的に移動すると、ユーザは既存のＶＰＮ接続から切断、即ちドロップされる。
【０００６】
従って、本発明によれば、ＮＡＳまたはＬＡＣは、既存のＰＰＰ接続を１つのＮＡＳから別のＮＡＳに移転する「ハンドオフ」機能を組み込む。
【０００７】
本発明の実施例では、ＮＡＳで使用するために３つの新しい制御メッセージが定義される。すなわち、(ｉ)継続呼要求(Continued Call Request)、(ii)継続呼応答(Continued Call Reply)および(iii)継続呼接続(Continued Call Connect)である。これらの３つの制御メッセージはＬ２ＴＰ制御メッセージ・ヘッダ、メッセージ識別子（例えば、継続呼要求等）および多数のフィールドを含んでいる。
【０００８】
上記の結果、ユーザは現行のＰＰＰ接続を終了してから新しいＰＰＰ接続を回復する必要はない。
【０００９】
【発明の詳細な記述】
すでに言及したように、本出願は、上記の特許出願に関連している。すなわち、詳細な説明は参照を容易にするため３つの節に分けられる。
【００１０】
＜多重ホップ・ポイントツーポイント・プロトコル＞
図１は、本発明の原理による例示としての通信システム１００を示す。本発明の概念以外、構成要素は周知であるので、詳細には説明しない。例えば、パーソナル・コンピュータ（Ｐersonal Ｃomputer:ＰＣ）１１０には、公衆電話網（Ｐublic-Ｓwitched-Ｔelephone Ｎetwork:ＰＳＴＮ）１１０を通じてＩＳＰ Ｂにダイヤルアップ接続し、インターネット接続を確立するデータ通信機器（図示せず）が含まれる。同様に、通信システム１００の構成要素間の実線は対応する終端間の周知の通信機能を表している。例えば、ＰＣ１１０とＰＳＴＮ１１０間の接続は加入者回線接続を表し、ＩＳＰ Ｂとインターネット１２０間の接続は同期光通信網（Ｓynchronous Ｏptical ＮＥＴwork：ＳＯＮＥＴ）を通じて非同期転送モード（Ａsynchronous Ｔransfer Ｍode:ＡＴＭ）によってサポートされる等である。さらに、読者は上記のＬ２ＴＰプロトコルに精通していることが前提になる。
【００１１】
図１から見られるように、通信システム１００は、ＩＳＰ Ａネットワークによって表されるＩＳＰ Ａと、ＩＳＰ Ｂネットワークによって表されるＩＳＰＢの２つのＩＳＰを備えている。ＩＳＰ Ｂネットワークは、当業技術分野で周知の接続点（Ｐoint-Ｏf-Ｐresence：ＰＯＰ）ルータを含むネットワーク・アクセス・サーバ（Ｎetwork Ａccess Ｓerver：ＮＡＳ）１１５、ローカル・ネットワーク１２０およびルータ１２５を備えている。同様に、ＩＳＰ Ａネットワークは、ＮＡＳ１５５、ローカル・ネットワーク１６０およびルータ１６５を備えている。ＩＳＰ Ａが、例示としての企業のネットワークにネットワーク・サーバ（Ｎetwork Ｓerver：ＮＳ）１３５を通じてアクセスする遠隔地に位置する従業員にＶＰＮサービスを提供することが想定されているが、このＮＳ１３５は多くの機能の中でも特に、ルーチングとファイアウォール機能を提供する（企業のネットワークは、例えば、ＮＳ１３５の背後で適切に保護されたローカルエリア・ネットワーク（図示せず）の集合であると想定する。）。
【００１２】
遠隔ユーザが、一時的にせよ、国内の、ＩＳＰ ＡのサービスではなくＩＳＰＢのサービスの対象になる部分に位置することがあるのが観察された。さらに、ＩＳＰ ＡがそのＶＰＮ対象範囲を他の範囲に拡大しようとすることがある。従って、本発明の原理によれば、遠隔ユーザは自分のホームＩＳＰ、即ちまたはアンカＩＳＰ(anchor ISP)に加えて訪問中ＩＳＰ、即ちサーブＩＳＰ(serving ISP)を通じてＶＰＮにアクセスすることができる（ＩＳＰ ＡとＩＳＰ Ｂが別のサービス・プロバイダであることが想定されるが、これは必ずしも本発明の概念ではない。例えば、同じＩＳＰの中の別個のネットワークであってもよい）。すなわち、ＰＣ１０５に位置するユーザ（図示せず）は、国内を、例えば、移動しながら企業のネットワークにアクセスすることができる。
【００１３】
この時点で、次の定義が前提となる。
ｍＬ２ＴＰ−K.Hamzeh、T.Kolar、M.Littlewood、G.Singh Pall、J.Taarud、A.J.Valencia、及びW.Vertheinの「レイヤ２トンネルプロトコル”Ｌ２ＴＰ”（Layer Two Tunneling Protocol "L2TP"）」（Internet Draft、1998年3月）で定義され、以下で説明する修正によって定義されるＬ２ＴＰプロトコル。
ＬＡＣ−ｍＬ２ＴＰアクセス制御装置、すなわち、ｍＬ２ＴＰをサポートするＮＡＳ。
ＬＮＳ−ｍＬ２ＴＰをサポートするＮＳ。
アンカＬＡＣ−ＶＰＮサービスを提供するＬＮＳへのトンネルをサポートするＬＡＣ。
サーブＬＡＣ−アンカＬＡＣへのトンネルをサポートするＬＡＣ。
（これらの定義は本発明の概念の例示としての説明を単純化するために使用される。すなわち、当業者が認識するように、本発明の概念はこのように制限されるものではなく、あらゆるトンネル・プロトコルと関連処理機器に適用できる。）
【００１４】
本発明の概念によれば、ＩＳＰ ＡネットワークはアンカＬＡＣ１５５を示し、ＩＳＰ ＢネットワークはサーブＬＡＣ１１５を示す。以下さらに説明されるように、本発明の原理によれば、図１の通信システム１００は多重ホップ・トンネル(multi-hop tunnel)を提供する。図１の例は、２つのホップ・トンネルを示す。１つのホップはＩＳＰ ＢネットワークからＩＳＰ Ａネットワークに至り、もう１つのホップはＩＳＰ Ａネットワークから企業のネットワークに至っている。
【００１５】
ここで図２を参照すると、本発明の原理による方法の高レベルの流れ図が示される（サーブＬＡＣ１１５と他のそれぞれのサーバは、従来のプログラミング技術を使用して以下に説明する方法を実行するよう適切にプログラムされていると考えられるが、ここで使用されるプログラミング技術は周知のものなので説明しない。）。ステップ２０５では、遠隔ユーザがＰＳＴＮ１１０を通じてＩＳＰ ＢへのＰＰＰ（ポイント・ツー・ポイント・プロトコル）接続を開始する。ステップ２１０では、サーブＬＡＣ１１５が（例えば、所定の「ユーザ名」または「パスワード」を使用して）部分的にユーザを認証し、（図１の点線１で表される）接続を承認する（また、ＤＮＩＳ（Ｄialed Ｎumber Ｉdentification Ｓervice：ダイヤル番号識別サービス）、ＣＬＩＤ（Ｃalling Ｌine ＩＤentification：発呼回線識別）または他の同等の形態の識別法が使用されることもある）。明らかに、サーブＬＡＣ１１５がユーザを認証できない場合、接続は承認されない（このステップは図示されていない。）。
【００１６】
（背景として、また当業技術分野で周知のように、遠隔ユーザが新しいＰＰＰセッションの開始を希望する場合、ＰＣ１１０はサーブＬＡＣに対してＰＰＰ ＬＣＰ（Ｌink Ｃontrol Ｐrotocol：リンク制御プロトコル）構成要求を開始する。本発明の概念によれば、サーブＬＡＣは、アンカＬＡＣとの通信を開始する前に、ユーザの機器と、当業技術分野で周知のように、ＰＰＰ ＬＣＰとＰＰＰＰＡＰ／ＣＨＡＰ両方の段階を完了する。（安全なコンジット(Conduits)のために、ＩＥＴＦは、パスワード認証プロトコル（Ｐassword Ａuthentication Ｐrotocol：ＰＡＰ）とチャレンジ−ハンドシェーク認証プロトコル（Ｃhallenge-Ｈandshake Ａuthentication Ｐrotocol：ＣＨＡＰ）という、ＰＰＰ接続のセキュリティのための２つのプロトコルを定義した（例えば、IETF Request for Comment(RFC)1334、「ＰＰＰ認証プロトコル(PPP authentication Protocol)」を参照されたい））
【００１７】
ステップ２１５では、サーブＬＡＣ１１５が、遠隔ユーザがＶＰＮサービスの使用を希望していると判断する（この選択は、特定の「ユーザ名」に直接関連し、および／または、例えば、サービスＬＡＣ１１５が提供するポップアップ「ハイパーテキスト・トランスポート・プロトコル（Ｈyper Ｔext Ｔransport Ｐrotocol：ＨＴＴＰ）フォームによるなどの、ユーザからの個別の要求に関連する」。遠隔ユーザが仮想ダイヤルアップ・サービスを要求しない場合、サーブＬＡＣ１１５はステップ２２０で標準インターネット・アクセスを提供する。しかし、遠隔ユーザがＶＰＮの使用を希望する場合、サーブＬＡＣ１１５はステップ２２５で関連するアンカＬＡＣを特定する（以下説明する）。
【００１８】
サーブＬＡＣ１１５は、例えば、ユーザのＩＤを特定のアンカＬＡＣにアプリオリに関連づけるＶＰＮテーブルを保存している。こうしたテーブルの一部を以下表１に示す。この例では、ＰＣ１１０に関連する遠隔ユーザが、アンカＬＡＣであるＩＳＰＡ．ｃｏｍ、すなわちアンカＬＡＣ１５５に関連している。
【００１９】
【表１】
（単に“ユーザ名＠ＩＳＰＡ．ｃｏｍ”といった形で構成されたフィールドのリストを維持するといった同等の構造または操作が使用されることもあることに留意されたい。なお、ここでは＠記号の後の部分はアンカＬＡＣを示す。また、ＩＳＰ Ｂがユーザをサービスにマップするデータベースを維持することもある。仮想ダイヤルアップ、すなわち、遠隔ユーザをＶＰＮサービスに関連するものとして特定する場合、このマッピングはさらにアンカＬＡＣを特定する。また、当業技術分野で周知のように、サーブＬＡＣはこのタスクのためにローカルラディアスサーバ(local Radius Server)とのラディアス・アクセス要求／応答トランザクション(Radius Access/Response transaction)を使用することもある。）。
【００２０】
ステップ２３０では、サーブＬＡＣ１１５が、サーブＬＡＣ１１５自体とアンカＬＡＣ１５５の間にトンネルがあるかを確認する。すなわち、サーブＬＡＣ１１５は、トンネル識別（Ｔunnel ｉｄentification：Ｔｉｄ）値、現在そのトンネルを使用する呼の関連呼識別子（Ｃall ｉｄentifiers：Ｃｉｄ）および関連するアンカＬＡＣのＩＰアドレスによって表される現行トンネルの、以下表２で示されるようなテーブルを保守する。
【００２１】
【表２】
サーブＬＡＣとアンカＬＡＣの間にトンネル接続が現在存在しない場合、ステップ２３５で、サーブＬＡＣ１１５によってアンカＬＡＣへのトンネルが確立される（以下説明する）。サーブＬＡＣとアンカＬＡＣの間にトンネルが存在する場合、サーブＬＡＣ１１５は、ステップ２４０で、新しいＣｉｄを割り当て、表２を更新し、（以下さらに説明するように）ローカル・ネットワーク１２０、ルータ１２５、インターネット１３０、ルータ１６５およびローカル・ネットワーク１６０を通じてＶＰＮ要求をアンカＬＡＣ１５５に転送する。この要求の中で、サーブＬＡＣ１１５はユーザ識別情報をアンカＬＡＣ１５５に伝える。
【００２２】
ここで図３を参照すると、アンカＬＡＣ１５５はステップ３０５で要求を受信する。ステップ３１０では、アンカＬＡＣ１５５はさらに（例えば、上記で言及した所定の「ユーザ名」と「パスワード」を使用して）遠隔ユーザの認証を行い、（図１の点線２で表される）接続を承認する（また、サーブＬＡＣと同様、ＤＮＩＳ、ＣＬＩＤまたは他の同等の形態の識別が使用されることもある）。アンカＬＡＣ１５５がユーザを認証できない場合、接続は承認されない（このステップは図示されていない。この場合、サーブＬＡＣ１１５は同様にエラーメッセージを遠隔ユーザ（図示せず）に返送しなければならない）。
【００２３】
アンカＬＡＣ１５５は、例えば、ユーザのＩＤを特定のＬＮＳに先天的(a priori)に関連付けるＶＰＮテーブルを保存している。こうしたテーブルの一部を以下表３に示す。この例では、ＰＣ１１０に関連する遠隔ユーザが、ＩＰアドレスｇ．ｈ．ｉ．ｊによって表されるＬＮＳ１３５に関連している。
【表３】
（サーブＬＡＣ１１５と同様に、同等の構成または動作が使用できることに留意されたい。例えば、アンカＬＡＣは、ホーム・ラディアスサーバにより、ラディアス・アクセス要求／応答メッセージを通じてこの機能を行うことがある。）。ステップ３１５では、アンカＬＡＣ１５５は、表３を使用してこれが有効な要求かを確認する。これが有効な要求でない場合、アンカＬＡＣ１５５はステップ３２０で要求を拒否する。これが有効な要求である場合、アンカＬＡＣはステップ３２５で表３から関連ＬＮＳを識別する。
【００２４】
アンカＬＡＣは、遠隔ユーザとの間に確立された各ＶＰＮセッションについて、各通信方向に関する次の接続テーブルを保守していると想定される。
【表４】
アンカＬＡＣは、接続番号を各ＶＰＮセッションに関連づける。さらに、この接続番号は対応するユーザにマップされる。この表は、接続番号によって、（そのホップの関連トンネルＩＤと呼ＩＤ値を伴う）サーブＬＡＣのＩＰアドレスと、（その関連するホップの関連トンネルＩＤと呼ＩＤ値を伴う）関連ＬＮＳのＩＰアドレスを列挙する。ステップ３３０では、アンカＬＡＣ１５５がＶＰＮセッションを確立する（認証の確認等を行う）。（ここでも、ＬＮＳ１３５が（例えば、遠隔ユーザの認証ができない場合や遠隔ユーザを受け入れる余地がないために）ＶＰＮ要求を拒否した場合、アンカＬＡＣとサーブＬＡＣによって適当なエラーメッセージが生成される）。本発明の概念以外に、ＬＮＳ１３５とのＶＰＮセッションが当業技術分野で周知のように確立される。例えば、本発明の原理によれば、新しいＶＰＮセッションを確立する際に、アンカＬＡＣ１５５は新しいＣｉｄを割り当て、表４を更新する（例えば、新しい接続を割り当てる。）。この最後の接続は、図１の点線３によって表される。
【００２５】
この時点で、連結性はポイント・ツー・ポイントＰＰＰセッションであり、その終端は、一方では（ＰＣ１１０によって表される）遠隔ユーザのネットワーク・アプリケーションであり、もう一方ではこの連結性のＬＮＳ１３５ＰＰＰサポートへの終端である（必要な場合、ＬＮＳと共にサーブＬＡＣ、アンカＬＡＣで課金処理を行えることに留意されたい。すなわち、各構成要素はパケット、オクテット、接続の開始・終了時間をカウントすることができる。）。
【００２６】
上記の多重ホップ仮想ダイヤルアップ・サービスをサポートする目的で、ある形式のＬ２ＴＰ（ｍＬ２ＴＰ）プロトコルが使用されるが、これについて以下に説明する。Ｌ２ＴＰでは、各ＬＡＣ−ＬＮＳペア間の制御メッセージと、同じＬＡＣ−ＬＮＳペア間のペイロード・パケットという所定のトンネルで動作するｍＬ２ＴＰの２つの並列コンポーネントが存在する。後者は、ＬＡＣ−ＬＮＳペア間のユーザ・セッションに関するｍＬ２ＴＰカプセル化ＰＰＰパケットを転送する。Ｌ２ＴＰでは、Ｎｒ（次の受信）およびＮｓ（次の送信）フィールドが常に制御メッセージに表示され、必要に応じてパイロード・パケットに存在する。制御メッセージとペイロード・メッセージは別のシーケンス番号状態を使用する。上記のＬＡＣ／ＬＮＳペアのシナリオでは、（Ｎｒ、Ｎｓ）の保守と使用に関する限りＬ２ＴＰドラフト・プロトコル定義の変更はない。
【００２７】
しかし、サーブＬＡＣとアンカＬＡＣの間の接続では、アンカＬＡＣはサーブＬＡＣが送信する（Ｎｒ、Ｎｓ）値を監視するだけである。すなわち、本発明の概念によれば、アンカＬＡＣは単純にサーブＬＡＣから受信した値をＬＮＳに再送信する。さらに、アンカＬＡＣはここで、サーブＬＡＣが送信したパケットから観察された対応する（Ｎｒ、Ｎｓ）値によって（受信状態、送信状態）値（Ｓｒ、Ｓｓ）を更新する。サーブＬＡＣとアンカＬＡＣの間には疑いなくパケット損失が存在するので、アンカＬＡＣのＳｓ（Ｓｒ）値はサーブＬＡＣのＳｓ（Ｓｒ）値より小さい（小さい）。さらに、アンカＬＡＣは、サーブＬＡＣ／アンカＬＡＣ制御接続に関するものと、アンカＬＡＣ／ＬＮＳ制御接続に関するものとの２組の（Ｓｒ、Ｓｓ）変数を保守する。
【００２８】
ＰＰＰトンネルが形成される前に、本発明の概念によれば、サーブＬＡＣ、アンカＬＡＣおよびＬＮＳの間で制御メッセージを交換しなければならない。制御メッセージは、後にｍＬ２ＴＰ呼制御管理情報が伝えられた場合ペイロード・データの転送に使用されるのと同じトンネルを通じて交換される（後で説明する。）。
【００２９】
本発明の概念によれば、追加の属性値ペア（Ａttribute Ｖalue Ｐairs：ＡＶＰ）（後で説明する）が定義され、Ｌ２ＴＰ制御メッセージ（ひいてはｍＬ２ＴＰ制御メッセージとなる）で使用される。この追加ＡＶＰは上記で説明した多重ホップ機能と呼転送機能をサポートするためのものである。Ｌ２ＴＰの定義では、ＡＶＰはさらに制御信号を指定するためにも使用される。
【００３０】
上記で言及したように、上記で説明したＬＡＣ／ＬＮＳペアの場合、上記で言及したＬ２ＴＰドラフトで説明した手順に変更はない。すなわち、以下説明する追加手順が必要になるのは、多重ホップの場合だけである。
【００３１】
多重ホップ・メッセージの流れの例を図４に示す。図４から観察されるように、サーブＬＡＣとアンカＬＡＣの間にトンネル（Ｔｉｄ値で示される）と呼（Ｃｉｄ値で示される）が確立される。同様に、アンカＬＡＣとＬＮＳの間にトンネルと呼が確立される。図４に示すように、本発明の概念はサーブＬＡＣがアンカＬＡＣへのトンネルを確立することを要求する。本発明では、サーブＬＡＣはアンカＬＡＣをＬＮＳとして扱い、Ｌ２ＴＰ手順が使用されてトンネルを初期設定する。
【００３２】
トンネルが確立されると、多数の制御メッセージ・トランザクションが発生し、本発明の原理によってＰＰＰセッションを設定する。それらは図５乃至図７に示される。これらの図では、様々な制御メッセージの関連フィールドだけが図示される（サーブＬＡＣとアンカＬＡＣ間のトンネルのトンネルｉｄおよび呼ｉｄが、アンカＬＡＣとＬＮＳ間のそれらの数値と異なっている場合、アンカＬＡＣはそれらを何れかの方向に中継する前にパケット・ヘッダの関連フィールドを修正する。）。
【００３３】
図５に示すように、サーブＬＡＣはまず開始制御接続−要求（Start-Control-Connect-Request Message：ＳＣＣＲＱ)メッセージ（Ｌ２ＴＰの定義による）をアンカＬＡＣに送信し、両者間にトンネルを設定する。このメッセージを受信すると、アンカＬＡＣは開始制御接続−応答(Start-control-Connect-Reply Message:ＳＣＣＲＰ)によって応答する（これは上記で説明した何らかの認証に続いて行われる）。サーブＬＡＣは開始制御接続−接続(Start-Control-Connection-Connect：ＳＣＣＣＮ)メッセージによってアンカＬＡＣに対する確認を行う。
【００３４】
図５に示す開始制御接続(Start-Control-Connection)メッセージの交換に続いて、サーブＬＡＣは、図６に示すように、着信呼要求(Incoming-Call-Request：ＩＣＲＱ)メッセージをアンカＬＡＣに送信する。着信呼要求(Incoming-Call-Request)メッセージにはアンカＬＡＣがＬＮＳを識別するのに十分なユーザ・データと信用証明が含まれている。
【００３５】
前に述べたように、アンカＬＡＣとＬＮＳの間にトンネルが存在しない場合、アンカＬＡＣは、Ｌ２ＴＰの定義により、ＬＮＳとのＳＣＣＲ、ＳＣＣＲＰ、ＳＣＣＣＮメッセージ交換を開始する。トンネルが存在する場合、トンネル内の未使用スロットであるＣｉｄがアンカＬＡＣによって割り当てられる。この時点で、本発明の原理によれば、アンカＬＡＣはＩＣＲＱメッセージを（サーブＬＡＣから）中継し、ＬＮＳにこの新しいダイヤルアップ・セッションについて通知する。図６に示すように、アンカＬＡＣはＩＣＲＱメッセージをＬＮＳに中継する前にしかるべく修正する。修正されたフィールド、例えば、割当て呼ＩＤは、“*”によって示される。アンカＬＡＣはまた隠しＡＶＰを追加し、ＬＮＳにサポート可能な受信ウィンドウ・サイズを知らせる（追加ホップの場合、アンカＬＡＣは制御／ペイロード両方の接続について取り決められた最大ウィンドウ・サイズを記録することに留意されたい。また、サーブＬＡＣとアンカＬＡＣ間の制御接続のウィンドウ・サイズがアンカＬＡＣとＬＮＳ間の制御接続のものと異なっており、バッファリングが必要なことがある。バッファリングとシーケンス番号監視の追加を避けるために、アンカＬＡＣは必要に応じて、アンカＬＡＣがアンカＬＡＣからサーブＬＡＣの方向でサポートできるペイロード・セッション用の受信ウィンドウ・サイズをＬＮＳに知らせるＡＶＰを追加する。その結果、ＬＮＳは、ＩＣＲＰ応答の適当な受信ウィンドウ・サイズ値だけを含み、ひいてはＬＮＳ−アンカＬＡＣ−サーブＬＡＣ方向のペイロード・セッションのための１つのウィンドウ・サイズだけを含むことになる。）。
【００３６】
前に述べたように、ＬＮＳは接続を承認または拒否する。拒否は結果状態を含まなければならず、エラー表示を含むことがある。どちらの場合でも、ＬＮＳは、図６に示すように、着信呼応答(Incoming-Call-Reply：ＩＣＲＰ）メッセージをアンカＬＡＣに送信する。本発明によれば、次にアンカＬＡＣはＩＣＲＰメッセージを適当に修正し、サーブＬＡＣに中継する（やはり、修正されたフィールドは図６では“*”で示される）。ＬＮＳから受信されたパケット処理遅延（ＰＰＤ）フィールドにはＬＮＳの処理遅延だけが含まれるので、アンカＬＡＣはこの値にそれ自体のノードの処理遅延を追加する。次に、ＩＣＲＱメッセージがサーブＬＡＣに中継される。
【００３７】
それに応答して、サーブＬＡＣは、図７に示すように、着信呼接続(Incoming-Call-Connected：ＩＣＣＮ）メッセージをアンカＬＡＣに送信する。このメッセージの中で、サーブＬＡＣはすべてのＬＣＰ構成要求(Config Request)情報をプロキシ認証情報(Proxy Authentication Information)と共に伝える。すなわち、サーブＬＡＣはユーザの機器で行われたＬＣＰ構成要求／応答(Config Request/Ack)、ＰＰＰ ＰＡＰ／ＣＨＡＰの結果を転送する。アンカＬＡＣは、受信ＩＣＣＮメッセージのＰＰＤフィールドをＬＮＳに中継する前に修正する（現在、送信接続速度と受信接続速度は使用されない）。図示されていないが、本発明によれば、アンカＬＡＣはＬ２ＴＰで定義されたすべてのSet-Link-Info、HelloおよびWan-Error-Notifyメッセージをも中継する（上記の説明は多重ホップ・パケット・トンネルの概念を示すものであることが観察されるだろう。例えば、図１は２ホップ・パケット・トンネルを表している）。
【００３８】
上記で説明した多重ホップｍＬ２ＴＰトンネルはもっぱらフレーム層で発生することが観察されるだろう。すなわち、どんな目的のＰＰＰプロトコル処理でも、遠隔ユーザはＬＮＳと接続するように見えるので、ＬＮＳによるアドレス管理の実際の方法は上記で説明した仮想ダイヤルアップ・サービスとは無関係である。
【００３９】
＜移動ポイントツーポイント・プロトコル＞
ここで図８を参照すると、本発明の概念の他の実施例が示される。図８は図１と同様である。本発明の概念以外、構成要素は周知であるので、詳細には説明しない。同じ数字は同じ機能を示し、必要な場合以外それ以上説明しない。
過去
図８では、ＰＣ８０５には、パーソナル・コミュニケーション・サービス（Ｐersonal Ｃommunication Ｓervice：ＰＣＳ）無線ネットワーク８１０を通じてインターネットへの無線アクセスを確立するデータ通信機器（図示せず）が含まれる。ＰＣＳ無線ネットワークは当業技術分野で周知であるので詳細には説明しない。ＰＣＳ無線ネットワーク８１０は、要素８１５および８２０で表されるような複数の移動交換センタを備えている。各交換センタはある地理的範囲（図示せず）にサービスを提供する。要素８１５と８２０にはＮＡＳが含まれることが想定され、例えば、サーブＬＡＣは図１のサーブＬＡＣ１１５と同様である。まず、遠隔ユーザが上記で説明した多重ホップ技術を使用して企業のネットワークへのＶＰＮセッションを確立することが想定される。すなわち、遠隔ユーザは、この初期接続が要素８１５を通じて接続８１４と８１６により転送されるような地理的範囲にある。無線ＰＣＳ用の場合、初期ＰＰＰ接続は要素８１５とＰＣ８０５の間で行われる（簡単にするために交換要素の一部として示されているが、ＮＡＳ機能は機器の独立した部分でも行われる。同様に、ローカル・ネットワークやルータといった他の要素も簡単にするために図示しない）。
【００４０】
無線環境では、Ｌ２ＴＰのようなトンネル・プロトコルによっては遠隔ユーザが既存のＰＰＰ接続を１つの交換要素から他の交換要素に変更できないということが認識された。例えば、図８が本発明の概念を実施しないことを想定すると、遠隔ユーザが要素８２０（ひいては異なったＮＡＳ）のサービスの対象となる地理的範囲に移動する場合、ユーザの通信セッションは、当業技術分野で周知のように要素８２０に受け渡される。しかし、すでに述べたように、既存のＰＰＰ接続を１つのＮＡＳから別のＮＡＳに転送することはできないため、既存のＰＰＰ接続（ひいてはＶＰＮセッション）は中断し、復旧しなければならなくなる。この場合、図８の通信システムはこの問題を克服する。
【００４１】
従って、本発明によれば、ＮＡＳまたはＬＡＣは、既存のＮＡＳが既存のＰＰＰ接続を別のＮＡＳにハンドオフできるようにする「ハンドオフ」機能を組み込んでいる。この機能によれば、(ｉ)継続呼要求(Continued Call Request)、(ii)継続呼応答(Continued Call Reply)および(iii)継続呼接続(Continued Call Connect)という３つの新しい制御メッセージが定義される。上記の結果、ユーザは現行のＰＰＰ接続を終了してから新しいＰＰＰ接続を復旧する必要はない。この３つの制御メッセージは、Ｌ２ＴＰ制御メッセージ・ヘッダ、メッセージ識別子（例えば、継続呼要求等）および多数のフィールド（後で説明する）を含んでいる。
【００４２】
本発明の概念による、ハンドオフ・メッセージの流れの例を図９に示す。図９から観察されるように、トンネル（Ｔｉｄ値で示される）と呼（Ｃｉｄ値で示される）がまず要素８１５（ここにはサーブＬＡＣが含まれる）とアンカＬＡＣの間に確立される。同様に、アンカＬＡＣとＬＮＳの間にトンネルと呼が確立される（この初期ＶＰＮセッションを確立する方法は上記で説明済みである。）。図９に示すように、本発明の概念によれば、既存のサーブＬＡＣは既存のＰＰＰ接続を、要素８２０によって表されるような新しいサーブＬＡＣに転送することができる。
【００４３】
ここで、「ハンドオフ機能」を提供する際使用される方法の流れ図の例である図１０を参照されたい。すでに述べたように、ＰＣ８０５と企業のネットワークの間に要素８１５を通じたＶＰＮセッションが存在し、そこにサーブＬＡＣとアンカＬＡＣ１５５が含まれることが想定される。本発明の概念によれば、ＰＣＳ無線ネットワーク８１０は既存の呼状態変数に、各無線呼に関するＰＰＰ接続の存在（または存在しないこと）を示す追加変数を追加し、ＰＰＰ接続が存在する場合、例えば、アンカＬＡＣのＩＰアドレスであるアンカＬＡＣのＩＤを含むＰＰＰ接続情報を追加する。
【００４４】
図１０のステップ４０５では、ＰＣＳ無線ネットワーク８１０は、ＰＣ８０５が要素８１５のサービスの対象になる地理的範囲から別の地理的範囲、例えば、要素８２０のサービスの対象になり、別のサービスＬＡＣが含まれる範囲に移動したためハンドオフが必要になったことを検出する。ステップ４１０では、ＰＣＳ無線システムは要素８２０にハンドオフが迫っていることを通知する（ハンドオフを検出し遂行するために無線システムが使用する方法は当業技術分野で周知であり、本発明の概念には関連しない。従って、それらはここでは説明されず、図８の信号経路８１１で表される）。ここで、呼状態情報にはＰＰＰセッション識別子とＰＰＰ呼情報が含まれているので、（要素８２０の）新しいサーブＬＡＣはステップ４１５でアンカＬＡＣを識別する。ステップ４２０で、（要素８２０の）新しいサーブＬＡＣはそれ自体と識別されたアンカＬＡＣ（ここではアンカＬＡＣ１５５）の間にすでにトンネルがあるかを確認する。
【００４５】
トンネルがない場合、新しいサーブＬＡＣはまずステップ４２５で（前に説明されたように）トンネルを確立する。次に、本発明の概念によれば、新しいサーブＬＡＣはステップ４３０で継続呼要求(Continued-Call-Request：ＣＣＲＱ）メッセージをアンカＬＡＣに送信する。このＣＣＲＱメッセージには、既存のＰＰＰ接続に関連するユーザ名、移転先の（新しい）ＰＰＰセッションで使用されるＴｉｄとＣｉｄの値が含まれる。
【００４６】
ステップ４３５では、アンカＬＡＣは受信したＣＣＲＱメッセージからユーザ名を回復し、この情報を使用して古いサーブＬＡＣのＬＮＳとＩＰアドレスを、例えば、上記の表４で表される接続テーブルから判定する（この回復された情報には対応するユーザ・データグラム・プロトコル（Ｕser Ｄatagram Ｐrotocol：ＵＤＰ）ポート番号が含まれることもある）。このステップでは、アンカＬＡＣは呼切断通知(Call-Disconnect-Notify)メッセージ（例えば、Ｌ２ＴＰ参照）を古いサーブＬＡＣに送信し、かつ、例えば、上記の表４で、古いトンネルｉｄや古い呼ｉｄといった遠隔ユーザへのこのＰＰＰ接続に関連する既存の呼変数を識別する（他方、アンカＬＡＣが継続呼要求(Continued-Call-Request)を拒否した場合、サーブＬＡＣは、既存のＰＰＰセッションが切断され、新しいＰＰＰセッションが開始されるか、または単にＰＰＰセッションが中止されるように信号を返送する（このステップは図示しない））。
【００４７】
ステップ４４０では、アンカＬＡＣが適当な受信ウィンドウ・サイズで継続呼応答(Continued-Call-Reply：ＣＣＲＰ）メッセージによって応答する。ＣＣＲＰメッセージには現行のＮｒとＮｓの値に関する情報が含まれる。ステップ４４５では、（ステップ４３５で識別された）Ｔｉｄ、ＣｉｄおよびサーブＬＡＣのＩＰアドレス・フィールドのエントリを既存のＰＰＰ接続の新しい呼情報に置換することにより、接続テーブル（例えば、上記の表４）を更新する。ステップ４５０では、新しいサーブＬＡＣはＮｒ、ＮｓをＳｒ、Ｓｓ値に保存し、かつ必要な場合受信したＣＣＲＰメッセージから受信ウィンドウ・サイズを保存し、継続呼接続（Continued-Call-Connect：ＣＣＣＮ）メッセージをアンカＬＡＣに送信し、これをもってハンドオフを完了する。
【００４８】
ＰＰＰプロトコルの上記で説明したハンドオフ機能を裏付けるものとして、図１１は本発明の原理による上記で言及した新しい制御メッセージ・トランザクションの例を示す。図１１に示すように、ＣＣＲＱメッセージが識別されたアンカＬＡＣに送信される。
【００４９】
ＣＣＲＱメッセージは次のフィールドを含む。
−割当てＣｉｄ
−呼シリアルナンバー
−ベアラ（bearer:運搬）の種類
−物理チャネルＩＤ
−ダイヤルされた番号
−ダイヤルする番号
−副アドレス
−アンカＬＡＣ
−チャレンジ
−ユーザＡＶＰ
−ユーザ名
−ユーザのＭＩＮ／電話番号
【００５０】
アンカＬＡＣのフィールドは、この情報がハンドオフの際に利用可能であることを想定している（また、ハンドオフ処理がアンカＬＡＣに関する情報を新しいサーブＬＡＣに提供しない場合、ハンドオフ処理は、当業技術分野で周知のように新しいサーブＬＡＣが外部ラディアス・サーバの助けによってアンカＬＡＣ情報を検索する十分なユーザ情報を新しいサーブＬＡＣに提供しなければならない。すなわち、新しいサーブＬＡＣはラディアス・アクセス／応答メッセージにより、ホームラディアスサーバからアンカＬＡＣについて照会する。）。
【００５１】
ユーザＡＶＰ情報には（ユーザ名のような）ユーザ情報と、例えば、多重ホップ仮想ダイヤルアップ・サービス、ユーザのＩＤ（ＭＩＮ）、サービス・プロバイダの電話番号等といった他のユーザの信用証明が含まれる。
【００５２】
ＣＣＲＱメッセージに続いて、アンカＬＡＣは呼切断通知(Call-Disconnect-Notify)メッセージを古いサーブＬＡＣに送信する。次に、アンカＬＡＣは、保守の対象となる現行Ｓｒ、Ｓｓを含む継続呼応答(Continued-Call-Reply:ＣＣＲＰ）メッセージによって応答する。
【００５３】
ＣＣＲＰメッセージは次のフィールドを含む。
−割当てＣｉｄ
−結果コード
−受信ウィンドウ・サイズ
−ＰＰＤ
−Ｎｒ
−Ｎｓ
−チャレンジ
−チャレンジ応答
【００５４】
最後に、新しいサーブＬＡＣが継続呼接続(Continued-Call Connect：ＣＣＣＮ）によって応答する。ＣＣＣＮメッセージは次のフィールドを含む。
−接続速度
−フレーム種類
−受信ウィンドウ・サイズ
−ＰＰＤ
−チャレンジ応答
【００５５】
ここで図１２を参照すると、既存のＰＰＰ接続を１つのＮＡＳから別のＮＡＳに移転し、その際古いＮＡＳがＬＮＳに接続している場合、本発明の概念の他の実施例が示される（この例では、サーブＬＡＣは本質的に存在せず、例えば、もっと簡単に、アンカＬＡＣが既存のＰＰＰ接続を直接サポートする）。図１２は図８と同様である。本発明の概念以外、構成要素は周知であるので、詳細には説明しない。同じ数字は同じ機能を示し、必要な場合以外それ以上説明しない。
【００５６】
図１２では、ＰＣ８０５には、パーソナル・コミュニケーション・サービス（Ｐersonal Ｃommunication Ｓervice ：ＰＣＳ）無線ネットワーク９１０を通じてインターネットへの無線アクセスを確立するデータ通信機器（図示せず）が含まれる。ＰＣＳ無線サービスは当業技術分野で周知であるので詳細には説明しない。ＰＣＳ無線ネットワーク９１０は要素８７５および８８０で表されるような複数の移動交換センタを含む。各交換センタはある地理的範囲（図示せず）にサービスを提供する。要素８７５と８８０には、例えば、図１のアンカＬＡＣ１１５と同様のＬＡＣであるＮＡＳが含まれる。まず、遠隔ユーザが、例えば、Ｌ２ＴＰの該当部分を使用して、当業技術分野で周知のように企業のネットワークへのＶＰＮセッションを確立することが想定される。すなわち、遠隔ユーザはこの最初の接続が要素８７５を通じて接続８７４と８７６によりＬＮＳ９３５に転送されるような地理的範囲にある。無線ＰＣＳ適用業務の場合、初期ＰＰＰ接続は要素８７５とＰＣ８０５の間で行われる（簡単にするために交換要素の一部として示されているが、ＮＡＳ機能は機器の独立した部分でも行われる。同様に、ローカル・ネットワークやルータといった他の要素も簡単にするために図示しない）。
【００５７】
この実施例では、上記で説明したＣＣＲＱ、ＣＣＲＰ、ＣＣＣＮメッセージが新しいＬＡＣとＬＮＳの間で交換される点以外は、同じハンドオフ手順がＬＡＣ／ＬＮＳペアについて実行される。本発明の概念による、ハンドオフ・メッセージの流れの例を図１３に示す。図１３から観察されるように、トンネル（Ｔｉｄ値で示される）と呼（Ｃｉｄ値で示される）がまず要素８７５（ここにはＬＡＣが含まれる）とＬＮＳ９３５の間に確立される。図１３に示すように、本発明の概念は、既存のＬＡＣが既存のＰＰＰ接続を、要素８８０で表される新しいＬＡＣに移転することを可能にする。
【００５８】
ここで、「ハンドオフ機能」を提供する再使用される方法の流れ図の例である図１４を参照されたい。すでに述べたように、ＰＣ８０５と企業のネットワークの間に、ＬＡＣを含む要素８７５を通じてＶＰＮセッションが存在していることが想定される。本発明の概念によれば、ＰＣＳ無線ネットワーク９１０は既存の呼状態変数に、各無線呼に関するＰＰＰ接続の存在（または存在しないこと）を示す状態変数を追加し、ＰＰＰ接続が存在する場合、例えば、ＬＮＳのＩＰアドレスであるＬＮＳのＩＤを含むＰＰＰ接続情報を追加する。
【００５９】
図１４のステップ５０５では、ＰＣＳ無線ネットワーク９１０は、ＰＣ８０５が要素８７５のサービスの対象になる地理的範囲から別の地理的範囲、例えば、要素８８０のサービスの対象になり、別のサービスＬＡＣが含まれる範囲に移動したためハンドオフが必要になったことを検出する。ステップ５１０では、ＰＣＳ無線システムは要素８８０にハンドオフが迫っていることを通知する（ハンドオフを検出し遂行するために無線システムが使用する方法は当業技術分野で周知であり、本発明の概念には関連しない。従って、それらはここでは説明されず、図１２の信号経路９１１で表される）。ここで、呼状態情報にはＰＰＰセッション識別子とＰＰＰ呼情報が含まれているので、（要素８８０の）新しいＬＡＣはステップ５１５でアンカＬＡＣを識別する。ステップ５２０で、（要素８８０の）新しいＬＡＣはそれ自体と識別されたＬＮＳ（ここではＬＮＳ９３５）の間にすでにトンネルがあるかを確認する。
【００６０】
トンネルがない場合、新しいＬＡＣはまずステップ５２５で（前に説明されたように）トンネルを確立する。次に、本発明の概念によれば、新しいＬＡＣはステップ５３０で継続呼要求(Continued-Call-Request:ＣＣＲＱ）メッセージをＬＮＳに送信する。このＣＣＲＱメッセージには、既存のＰＰＰ接続に関連するユーザ名、移動先の（新しい）ＰＰＰセッションで使用されるＴｉｄとＣｉｄの値が含まれる。
【００６１】
ステップ５３５では、ＬＮＳは受信したＣＣＲＱメッセージからユーザ名を回復し、この情報を使用して古いＬＡＣのＩＰアドレスを判定する（この回復された情報には対応するユーザ・データグラム・プロトコル（Ｕser Ｄatagram Ｐrotocol:ＵＤＰ）ポート番号が含まれることもある）。このステップでは、アンカＬＡＣは呼切断通知(Call-Disconnect-Notify)メッセージ（例えば、Ｌ２ＴＰ参照）を古いＬＡＣに送信し、かつ、例えば、上記の表４で示されるものと同様だが、サーブＬＡＣ情報等は除く接続テーブルで、古いトンネルｉｄや古い呼ｉｄといった遠隔ユーザへのこのＰＰＰ接続に関連する既存の呼変数を識別する（他方、ＬＮＳが継続呼要求(Continued-Call-Request)を拒否した場合、新しいＬＡＣは、既存のＰＰＰセッションが切断され、新しいＰＰＰセッションが開始されるか、または単に古いＰＰＰセッションが中止されるように信号を返送する（このステップは図示しない））。
【００６２】
ステップ５４０では、ＬＮＳが適当な受信ウィンドウ・サイズで継続呼応答(Continued-Call-Reply:ＣＣＲＰ）メッセージによって応答する。ＣＣＲＰメッセージには現行のＮｒとＮｓの値に関する情報が含まれる。ステップ５４５では、ＬＮＳは、（ステップ５３５で識別された）Ｔｉｄ、ＣｉｄおよびＬＡＣのＩＰアドレス・フィールドのエントリを既存のＰＰＰ接続の新しい呼情報に置換することにより、接続テーブルを更新する。ステップ５５０では、新しいＬＡＣはＮｒ、Ｎｓを更新し、必要な場合受信したＣＣＲＰメッセージからＮｒ、Ｎｓと受信ウィンドウ・サイズを更新し、継続呼接続(Continued-Call-Connect:ＣＣＣＮ）メッセージをＬＮＳに送信し、これをもってハンドオフを完了する。
【００６３】
ＰＰＰプロトコルの上記で説明したハンドオフ機能を裏付けるものとして、図１５は本発明の原理による新しい制御メッセージ・トランザクションを示す。図１５に示すように、ＣＣＲＱメッセージが識別されたＬＮＳに送信される（また、ハンドオフ処理がＬＮＳに関する情報を新しいＬＡＣに提供しない場合、ハンドオフ処理は、当業技術分野で周知のように新しいＬＡＣが外部ラディアスサーバの助けによってＬＮＳ情報を検索する十分なユーザ情報を新しいＬＡＣに提供しなければならない。すなわち、新しいＬＡＣはラディアスアクセス／応答メッセージにより、ホームラディアスサーバからＬＮＳについて照会する）。ＣＣＲＱメッセージに続いて、ＬＮＳは呼切断通知(Call-Disconnect-Notify)メッセージを古いＬＡＣに送信する。次に、ＬＮＳは、保守の対象となる現行Ｓｒ、Ｓｓを含む継続呼応答(Continued-Call-Reply:ＣＣＲＰ）メッセージによって応答する。最後に、新しいＬＡＣが継続呼接続(Continued-Call Connect:ＣＣＣＮ）によって応答する。
【００６４】
上記で説明したように、ＰＰＰ接続は１つのＮＡＳから別のＮＡＳに移転される。新しく定義されたメッセージを裏付けるものとして、以下図５および図６に示されるように対応するＮＡＳについて追加呼状態が定義される。
【表５】
観察されるように、継続される呼について新しいＬＡＣ（またはＮＡＳ）に関連するｍＬ２ＴＰの追加された、または新しい呼状態はＣＣＲＰ応答待ち状態である。
【００６５】
古いＬＡＣ（またはＮＡＳ）について、確立された状態で呼切断通知(Call-Disconnect-Notify:ＣＤＮ）メッセージが受信されることに留意されたい。それに応答して、古いＬＡＣは呼をクリーンアップして切断し、アイドル状態に戻る。
【表６】
観察されるように、継続される呼について、アンカＬＡＣまたはＬＮＳに関連するｍＬ２ＴＰの追加された、または新しい呼状態はＣＣＣＮ待ち状態である。
【００６６】
＜ペイロード・メッセージの概観とｍＬ２ＴＰの輻輳制御＞
ｍＬ２ＴＰのペイロード・メッセージに関して、サーブＬＡＣとＬＮＳはＬ２ＴＰ手順を遵守する。アンカＬＡＣはペイロード・パケットについてＴｉｄとＣｉｄをスワップする。また、アンカＬＡＣはサーブＬＡＣが送信する（Ｎｒ、Ｎｓ）値を監視する（サーブＬＡＣとアンカＬＡＣの間にはパケット損失が存在するので、アンカＬＡＣのＳｒおよびＳｓの値はどちらもサーブＬＡＣが保守するこれらの数値より遅れると考えられることに留意されたい。）アンカＬＡＣはどちらの方向でもペイロード・パケットの（Ｎｒ、Ｎｓ）を変更しない。アンカＬＡＣは、継続呼要求(Continued-Call-Request)メッセージを新しいサーブＬＡＣから受信する時それ自体のＳｒ、Ｓｓ値だけを利用する。
【００６７】
輻輳制御に関して、Ｌ２ＴＰは受信ウィンドウ・サイズを維持する時期、Ｎｒ／Ｎｓを送信する時期およびＡＣＫを送信する時期に関するＬ２ＴＰの要求をｍＬ２ＴＰに適用する。さらに、ｍＬ２ＴＰはサーブＬＡＣとアンカＬＡＣについて次の追加要求を有する。
【００６８】
アンカＬＡＣはサーブＬＡＣが送信した（Ｎｒ、Ｎｓ）値の監視が必要である。アンカＬＡＣは、サーブＬＡＣから受信する継続呼接続(Continued-Call-Connect)メッセージに応答する時継続呼応答(Continued-Call-Reply)メッセージの中で保守する（Ｓｒ、Ｓｓ）値を含むべきである。サーブＬＡＣとアンカＬＡＣの間のネットワークは損失が大きいので、アンカＬＡＣが保守するＳｒ値はサーブＬＡＣより遅れることがある。
【００６９】
さらに、サーブＬＡＣは、当業技術分野の用語に従えば、単純なレシーバではなく完全なレシーバである。この要求は、ＰＰＰセッションの継続期間中にサーブＬＡＣの変更がある場合、新しいサーブＬＡＣがシーケンス外や重複したパケットを上部層に伝えないということである。
【００７０】
簡単に図１６を参照すると、代表的なＮＡＳの高レベル・ブロック図が示される。ＮＡＳは蓄積プログラム制御ベース・プロセッサ・アーキテクチャであり、プロセッサ６５０、メモリ６６０（プログラムの命令と、上記で言及した接続テーブル等のデータを保存する）および経路６６６で表されるように１つかそれ以上の通信機能を結合する通信インタフェース６６５を含む。
【００７１】
以上は本発明の原理を例示したものに過ぎず、当業技術分野に熟練した者には、ここで明示的に説明されていなくとも、本発明の原理を実施しその精神と範囲の中にある非常に多くの代替装置が考案できることを認識することができるだろう。例えば、本発明の概念はサーブＮＡＳが着信呼に関する多重ホップ・トンネルの確立を開始する場合で説明されたが、本発明の概念は、例えば、ＬＮＳが発信呼に関する多重ホップ・シーケンスを開始する場合にも等しく適用できる。こうした修正は簡単明瞭であり、図１７及び図１８で示されているのでここでは説明しない。
【図面の簡単な説明】
【図１】本発明の原理による通信システムを示す図である。
【図２】図１の通信システムを使用する例示としての方法の流れ図を示す図である。
【図３】図１の通信システムを使用する例示としての方法の流れ図を示す図である。
【図４】例示としての多重ホップ・メッセージの流れを示す図である。
【図５】例示としての制御メッセージのトランザクションを示す図である。
【図６】例示としての制御メッセージのトランザクションを示す図である。
【図７】例示としての制御メッセージのトランザクションを示す図である。
【図８】本発明の原理による通信システムの他の実施例を示す図である。
【図９】例示としてのハンドオフ・メッセージの流れを示す図である。
【図１０】図８の通信システムで使用される例示としての方法の流れ図を示す図である。
【図１１】例示としての制御メッセージのトランザクションを示す図である。
【図１２】本発明の原理による通信システムの他の実施例を示す図である。
【図１３】例示としてのハンドオフ・メッセージの流れを示す図である。
【図１４】図１２の通信システムで使用される例示としての方法の流れ図を示す図である。
【図１５】例示としての制御メッセージのトランザクションを示す図である。
【図１６】ネットワーク・アクセス・サーバの例示としての高レベル・ブロック図を示す図である。
【図１７】発信呼用の例示としての制御メッセージ・トランザクションを示す図である。
【図１８】発信呼用の例示としての制御メッセージ・トランザクションを示す図である。
【発明の分野】
本発明は、概して、通信に関し、特にパケット通信システムに関する。
関連する主題が、本出願と同じ日付で出願された「多重ホップ・ポイント・ツー・ポイント・プロトコル」と称する日本国特許出願で開示されている。
【０００２】
【発明の背景】
通信手段としてのインターネットの用途の１つは、ワークグループを互いに結合していわゆる「仮想私設網」（Ｖertual Ｐrivate Ｎetwork：ＶＰＮ）を提供する高度データ・バックボーンとしての使用法である。ＶＰＮの応用例の１つは、従業員が、例えば、自宅でインターネットを通じて企業のデータ・ネットワークに遠隔アクセスできる企業環境におけるものである。ＶＰＮは、公衆設備を使用するにもかかわらず、閉じたユーザ・グループに参加する遠隔ユーザにセキュリティと認証を提供する。事実上、ＶＰＮを使用することによって、企業とその従業員にはＷＡＮと同様の手段が提供される（ユーザが直接企業のネットワークにダイヤルする等の方法で、企業のネットワークが直接遠隔アクセスを提供することもできるが、ＶＰＮを使用する方が経済的に有利である）。
【０００３】
ＶＰＮを提供するために、「ポイント・ツー・ポイント・トンネル・プロトコル」（Ｐoint-to-Ｐoint Ｔunneling Ｐrotocol:ＰＰＴＰ）や「レイヤ２フォワーディング」（Ｌayer ２ Ｆorwarding:Ｌ２Ｆ）プロトコルといったトンネル・プロトコルが使用される。一般的に言って、トンネル・プロトコルは、１つのパケットを別のパケットの内部に配置することにより、公衆網を通じて専用データ・ストリームを作成することを可能にする。ＶＰＮの場合、ＩＰパケットが別のＩＰパケットの内部に配置される。業界標準の開発を目指して、インターネット・エンジニアリング・タスク・フォース（Ｉnternet Ｅngineering Ｔask Ｆorce：ＩＥＴＦ）は、「レイヤ２トンネル・プロトコル」（Ｌayer ２ Ｔunnel Ｐrotocol）を開発しているが、これはＰＰＴＰとＬ２Ｆプロトコルの混成物である（例えば、K.Hamzeh、T.Kolar、M.Littlewood、G.Singh Pall、J.Taarud、A.J.Valencia及びW.Vertheinの「レイヤ２トンネルプロトコル”ＬＴ２Ｐ”（Layer Two Tunneling Protocol“L2TP”）」（Internet draft、1998年3月）を参照されたい。）。
【０００４】
遠隔ユーザにとって、ＶＰＮにアクセスする通常の形態は、「在来型の電話サービス」（Ｐlain-Ｏld-Ｔelephone Ｓervice:ＰＯＴＳ）接続により、ＶＰＮを提供する「インターネット・サービス・プロバイダ」（Ｉnternet Ｓervice Ｐrovider：ＩＳＰ）にアクセスすることである。例えば、ユーザは、アナログモデムをパーソナル・コンピュータまたはその相当品に組み込み、特定ＩＳＰ（ここでは「ホーム」ＩＳＰと呼ぶ）のカスタマ・アカウントを取得する（ユーザのパーソナル・コンピュータが上記のトンネル・プロトコルの１つをサポートするよう正しく設定されていることも前提となる）。ユーザは、「ホーム」ＩＳＰに関連する電話番号をダイヤルするなどして簡単にホームＩＳＰにデータ呼出を行った後ＶＰＮに「ログイン(logging in)」してＶＰＮにアクセスする。
【０００５】
【発明の概要】
ＩＳＰへのアクセスは、ネットワーク・アクセス・サーバ（Ｎetwork ＡccessＳerver：ＮＡＳ）を通じて行われる。パーソナル・コミュニケーション・サービス（Ｐersoal Ｃommunication Ｓervice：ＰＣＳ）無線環境では、上記で説明したトンネル・プロトコルによって遠隔ユーザは、既存の呼で、ＶＰＮへのアクセスを提供するＮＡＳを変更できないことが認識された。すなわち、ユーザが物理的に移動すると、ユーザは既存のＶＰＮ接続から切断、即ちドロップされる。
【０００６】
従って、本発明によれば、ＮＡＳまたはＬＡＣは、既存のＰＰＰ接続を１つのＮＡＳから別のＮＡＳに移転する「ハンドオフ」機能を組み込む。
【０００７】
本発明の実施例では、ＮＡＳで使用するために３つの新しい制御メッセージが定義される。すなわち、(ｉ)継続呼要求(Continued Call Request)、(ii)継続呼応答(Continued Call Reply)および(iii)継続呼接続(Continued Call Connect)である。これらの３つの制御メッセージはＬ２ＴＰ制御メッセージ・ヘッダ、メッセージ識別子（例えば、継続呼要求等）および多数のフィールドを含んでいる。
【０００８】
上記の結果、ユーザは現行のＰＰＰ接続を終了してから新しいＰＰＰ接続を回復する必要はない。
【０００９】
【発明の詳細な記述】
すでに言及したように、本出願は、上記の特許出願に関連している。すなわち、詳細な説明は参照を容易にするため３つの節に分けられる。
【００１０】
＜多重ホップ・ポイントツーポイント・プロトコル＞
図１は、本発明の原理による例示としての通信システム１００を示す。本発明の概念以外、構成要素は周知であるので、詳細には説明しない。例えば、パーソナル・コンピュータ（Ｐersonal Ｃomputer:ＰＣ）１１０には、公衆電話網（Ｐublic-Ｓwitched-Ｔelephone Ｎetwork:ＰＳＴＮ）１１０を通じてＩＳＰ Ｂにダイヤルアップ接続し、インターネット接続を確立するデータ通信機器（図示せず）が含まれる。同様に、通信システム１００の構成要素間の実線は対応する終端間の周知の通信機能を表している。例えば、ＰＣ１１０とＰＳＴＮ１１０間の接続は加入者回線接続を表し、ＩＳＰ Ｂとインターネット１２０間の接続は同期光通信網（Ｓynchronous Ｏptical ＮＥＴwork：ＳＯＮＥＴ）を通じて非同期転送モード（Ａsynchronous Ｔransfer Ｍode:ＡＴＭ）によってサポートされる等である。さらに、読者は上記のＬ２ＴＰプロトコルに精通していることが前提になる。
【００１１】
図１から見られるように、通信システム１００は、ＩＳＰ Ａネットワークによって表されるＩＳＰ Ａと、ＩＳＰ Ｂネットワークによって表されるＩＳＰＢの２つのＩＳＰを備えている。ＩＳＰ Ｂネットワークは、当業技術分野で周知の接続点（Ｐoint-Ｏf-Ｐresence：ＰＯＰ）ルータを含むネットワーク・アクセス・サーバ（Ｎetwork Ａccess Ｓerver：ＮＡＳ）１１５、ローカル・ネットワーク１２０およびルータ１２５を備えている。同様に、ＩＳＰ Ａネットワークは、ＮＡＳ１５５、ローカル・ネットワーク１６０およびルータ１６５を備えている。ＩＳＰ Ａが、例示としての企業のネットワークにネットワーク・サーバ（Ｎetwork Ｓerver：ＮＳ）１３５を通じてアクセスする遠隔地に位置する従業員にＶＰＮサービスを提供することが想定されているが、このＮＳ１３５は多くの機能の中でも特に、ルーチングとファイアウォール機能を提供する（企業のネットワークは、例えば、ＮＳ１３５の背後で適切に保護されたローカルエリア・ネットワーク（図示せず）の集合であると想定する。）。
【００１２】
遠隔ユーザが、一時的にせよ、国内の、ＩＳＰ ＡのサービスではなくＩＳＰＢのサービスの対象になる部分に位置することがあるのが観察された。さらに、ＩＳＰ ＡがそのＶＰＮ対象範囲を他の範囲に拡大しようとすることがある。従って、本発明の原理によれば、遠隔ユーザは自分のホームＩＳＰ、即ちまたはアンカＩＳＰ(anchor ISP)に加えて訪問中ＩＳＰ、即ちサーブＩＳＰ(serving ISP)を通じてＶＰＮにアクセスすることができる（ＩＳＰ ＡとＩＳＰ Ｂが別のサービス・プロバイダであることが想定されるが、これは必ずしも本発明の概念ではない。例えば、同じＩＳＰの中の別個のネットワークであってもよい）。すなわち、ＰＣ１０５に位置するユーザ（図示せず）は、国内を、例えば、移動しながら企業のネットワークにアクセスすることができる。
【００１３】
この時点で、次の定義が前提となる。
ｍＬ２ＴＰ−K.Hamzeh、T.Kolar、M.Littlewood、G.Singh Pall、J.Taarud、A.J.Valencia、及びW.Vertheinの「レイヤ２トンネルプロトコル”Ｌ２ＴＰ”（Layer Two Tunneling Protocol "L2TP"）」（Internet Draft、1998年3月）で定義され、以下で説明する修正によって定義されるＬ２ＴＰプロトコル。
ＬＡＣ−ｍＬ２ＴＰアクセス制御装置、すなわち、ｍＬ２ＴＰをサポートするＮＡＳ。
ＬＮＳ−ｍＬ２ＴＰをサポートするＮＳ。
アンカＬＡＣ−ＶＰＮサービスを提供するＬＮＳへのトンネルをサポートするＬＡＣ。
サーブＬＡＣ−アンカＬＡＣへのトンネルをサポートするＬＡＣ。
（これらの定義は本発明の概念の例示としての説明を単純化するために使用される。すなわち、当業者が認識するように、本発明の概念はこのように制限されるものではなく、あらゆるトンネル・プロトコルと関連処理機器に適用できる。）
【００１４】
本発明の概念によれば、ＩＳＰ ＡネットワークはアンカＬＡＣ１５５を示し、ＩＳＰ ＢネットワークはサーブＬＡＣ１１５を示す。以下さらに説明されるように、本発明の原理によれば、図１の通信システム１００は多重ホップ・トンネル(multi-hop tunnel)を提供する。図１の例は、２つのホップ・トンネルを示す。１つのホップはＩＳＰ ＢネットワークからＩＳＰ Ａネットワークに至り、もう１つのホップはＩＳＰ Ａネットワークから企業のネットワークに至っている。
【００１５】
ここで図２を参照すると、本発明の原理による方法の高レベルの流れ図が示される（サーブＬＡＣ１１５と他のそれぞれのサーバは、従来のプログラミング技術を使用して以下に説明する方法を実行するよう適切にプログラムされていると考えられるが、ここで使用されるプログラミング技術は周知のものなので説明しない。）。ステップ２０５では、遠隔ユーザがＰＳＴＮ１１０を通じてＩＳＰ ＢへのＰＰＰ（ポイント・ツー・ポイント・プロトコル）接続を開始する。ステップ２１０では、サーブＬＡＣ１１５が（例えば、所定の「ユーザ名」または「パスワード」を使用して）部分的にユーザを認証し、（図１の点線１で表される）接続を承認する（また、ＤＮＩＳ（Ｄialed Ｎumber Ｉdentification Ｓervice：ダイヤル番号識別サービス）、ＣＬＩＤ（Ｃalling Ｌine ＩＤentification：発呼回線識別）または他の同等の形態の識別法が使用されることもある）。明らかに、サーブＬＡＣ１１５がユーザを認証できない場合、接続は承認されない（このステップは図示されていない。）。
【００１６】
（背景として、また当業技術分野で周知のように、遠隔ユーザが新しいＰＰＰセッションの開始を希望する場合、ＰＣ１１０はサーブＬＡＣに対してＰＰＰ ＬＣＰ（Ｌink Ｃontrol Ｐrotocol：リンク制御プロトコル）構成要求を開始する。本発明の概念によれば、サーブＬＡＣは、アンカＬＡＣとの通信を開始する前に、ユーザの機器と、当業技術分野で周知のように、ＰＰＰ ＬＣＰとＰＰＰＰＡＰ／ＣＨＡＰ両方の段階を完了する。（安全なコンジット(Conduits)のために、ＩＥＴＦは、パスワード認証プロトコル（Ｐassword Ａuthentication Ｐrotocol：ＰＡＰ）とチャレンジ−ハンドシェーク認証プロトコル（Ｃhallenge-Ｈandshake Ａuthentication Ｐrotocol：ＣＨＡＰ）という、ＰＰＰ接続のセキュリティのための２つのプロトコルを定義した（例えば、IETF Request for Comment(RFC)1334、「ＰＰＰ認証プロトコル(PPP authentication Protocol)」を参照されたい））
【００１７】
ステップ２１５では、サーブＬＡＣ１１５が、遠隔ユーザがＶＰＮサービスの使用を希望していると判断する（この選択は、特定の「ユーザ名」に直接関連し、および／または、例えば、サービスＬＡＣ１１５が提供するポップアップ「ハイパーテキスト・トランスポート・プロトコル（Ｈyper Ｔext Ｔransport Ｐrotocol：ＨＴＴＰ）フォームによるなどの、ユーザからの個別の要求に関連する」。遠隔ユーザが仮想ダイヤルアップ・サービスを要求しない場合、サーブＬＡＣ１１５はステップ２２０で標準インターネット・アクセスを提供する。しかし、遠隔ユーザがＶＰＮの使用を希望する場合、サーブＬＡＣ１１５はステップ２２５で関連するアンカＬＡＣを特定する（以下説明する）。
【００１８】
サーブＬＡＣ１１５は、例えば、ユーザのＩＤを特定のアンカＬＡＣにアプリオリに関連づけるＶＰＮテーブルを保存している。こうしたテーブルの一部を以下表１に示す。この例では、ＰＣ１１０に関連する遠隔ユーザが、アンカＬＡＣであるＩＳＰＡ．ｃｏｍ、すなわちアンカＬＡＣ１５５に関連している。
【００１９】
【表１】
【００２０】
ステップ２３０では、サーブＬＡＣ１１５が、サーブＬＡＣ１１５自体とアンカＬＡＣ１５５の間にトンネルがあるかを確認する。すなわち、サーブＬＡＣ１１５は、トンネル識別（Ｔunnel ｉｄentification：Ｔｉｄ）値、現在そのトンネルを使用する呼の関連呼識別子（Ｃall ｉｄentifiers：Ｃｉｄ）および関連するアンカＬＡＣのＩＰアドレスによって表される現行トンネルの、以下表２で示されるようなテーブルを保守する。
【００２１】
【表２】
【００２２】
ここで図３を参照すると、アンカＬＡＣ１５５はステップ３０５で要求を受信する。ステップ３１０では、アンカＬＡＣ１５５はさらに（例えば、上記で言及した所定の「ユーザ名」と「パスワード」を使用して）遠隔ユーザの認証を行い、（図１の点線２で表される）接続を承認する（また、サーブＬＡＣと同様、ＤＮＩＳ、ＣＬＩＤまたは他の同等の形態の識別が使用されることもある）。アンカＬＡＣ１５５がユーザを認証できない場合、接続は承認されない（このステップは図示されていない。この場合、サーブＬＡＣ１１５は同様にエラーメッセージを遠隔ユーザ（図示せず）に返送しなければならない）。
【００２３】
アンカＬＡＣ１５５は、例えば、ユーザのＩＤを特定のＬＮＳに先天的(a priori)に関連付けるＶＰＮテーブルを保存している。こうしたテーブルの一部を以下表３に示す。この例では、ＰＣ１１０に関連する遠隔ユーザが、ＩＰアドレスｇ．ｈ．ｉ．ｊによって表されるＬＮＳ１３５に関連している。
【表３】
【００２４】
アンカＬＡＣは、遠隔ユーザとの間に確立された各ＶＰＮセッションについて、各通信方向に関する次の接続テーブルを保守していると想定される。
【表４】
【００２５】
この時点で、連結性はポイント・ツー・ポイントＰＰＰセッションであり、その終端は、一方では（ＰＣ１１０によって表される）遠隔ユーザのネットワーク・アプリケーションであり、もう一方ではこの連結性のＬＮＳ１３５ＰＰＰサポートへの終端である（必要な場合、ＬＮＳと共にサーブＬＡＣ、アンカＬＡＣで課金処理を行えることに留意されたい。すなわち、各構成要素はパケット、オクテット、接続の開始・終了時間をカウントすることができる。）。
【００２６】
上記の多重ホップ仮想ダイヤルアップ・サービスをサポートする目的で、ある形式のＬ２ＴＰ（ｍＬ２ＴＰ）プロトコルが使用されるが、これについて以下に説明する。Ｌ２ＴＰでは、各ＬＡＣ−ＬＮＳペア間の制御メッセージと、同じＬＡＣ−ＬＮＳペア間のペイロード・パケットという所定のトンネルで動作するｍＬ２ＴＰの２つの並列コンポーネントが存在する。後者は、ＬＡＣ−ＬＮＳペア間のユーザ・セッションに関するｍＬ２ＴＰカプセル化ＰＰＰパケットを転送する。Ｌ２ＴＰでは、Ｎｒ（次の受信）およびＮｓ（次の送信）フィールドが常に制御メッセージに表示され、必要に応じてパイロード・パケットに存在する。制御メッセージとペイロード・メッセージは別のシーケンス番号状態を使用する。上記のＬＡＣ／ＬＮＳペアのシナリオでは、（Ｎｒ、Ｎｓ）の保守と使用に関する限りＬ２ＴＰドラフト・プロトコル定義の変更はない。
【００２７】
しかし、サーブＬＡＣとアンカＬＡＣの間の接続では、アンカＬＡＣはサーブＬＡＣが送信する（Ｎｒ、Ｎｓ）値を監視するだけである。すなわち、本発明の概念によれば、アンカＬＡＣは単純にサーブＬＡＣから受信した値をＬＮＳに再送信する。さらに、アンカＬＡＣはここで、サーブＬＡＣが送信したパケットから観察された対応する（Ｎｒ、Ｎｓ）値によって（受信状態、送信状態）値（Ｓｒ、Ｓｓ）を更新する。サーブＬＡＣとアンカＬＡＣの間には疑いなくパケット損失が存在するので、アンカＬＡＣのＳｓ（Ｓｒ）値はサーブＬＡＣのＳｓ（Ｓｒ）値より小さい（小さい）。さらに、アンカＬＡＣは、サーブＬＡＣ／アンカＬＡＣ制御接続に関するものと、アンカＬＡＣ／ＬＮＳ制御接続に関するものとの２組の（Ｓｒ、Ｓｓ）変数を保守する。
【００２８】
ＰＰＰトンネルが形成される前に、本発明の概念によれば、サーブＬＡＣ、アンカＬＡＣおよびＬＮＳの間で制御メッセージを交換しなければならない。制御メッセージは、後にｍＬ２ＴＰ呼制御管理情報が伝えられた場合ペイロード・データの転送に使用されるのと同じトンネルを通じて交換される（後で説明する。）。
【００２９】
本発明の概念によれば、追加の属性値ペア（Ａttribute Ｖalue Ｐairs：ＡＶＰ）（後で説明する）が定義され、Ｌ２ＴＰ制御メッセージ（ひいてはｍＬ２ＴＰ制御メッセージとなる）で使用される。この追加ＡＶＰは上記で説明した多重ホップ機能と呼転送機能をサポートするためのものである。Ｌ２ＴＰの定義では、ＡＶＰはさらに制御信号を指定するためにも使用される。
【００３０】
上記で言及したように、上記で説明したＬＡＣ／ＬＮＳペアの場合、上記で言及したＬ２ＴＰドラフトで説明した手順に変更はない。すなわち、以下説明する追加手順が必要になるのは、多重ホップの場合だけである。
【００３１】
多重ホップ・メッセージの流れの例を図４に示す。図４から観察されるように、サーブＬＡＣとアンカＬＡＣの間にトンネル（Ｔｉｄ値で示される）と呼（Ｃｉｄ値で示される）が確立される。同様に、アンカＬＡＣとＬＮＳの間にトンネルと呼が確立される。図４に示すように、本発明の概念はサーブＬＡＣがアンカＬＡＣへのトンネルを確立することを要求する。本発明では、サーブＬＡＣはアンカＬＡＣをＬＮＳとして扱い、Ｌ２ＴＰ手順が使用されてトンネルを初期設定する。
【００３２】
トンネルが確立されると、多数の制御メッセージ・トランザクションが発生し、本発明の原理によってＰＰＰセッションを設定する。それらは図５乃至図７に示される。これらの図では、様々な制御メッセージの関連フィールドだけが図示される（サーブＬＡＣとアンカＬＡＣ間のトンネルのトンネルｉｄおよび呼ｉｄが、アンカＬＡＣとＬＮＳ間のそれらの数値と異なっている場合、アンカＬＡＣはそれらを何れかの方向に中継する前にパケット・ヘッダの関連フィールドを修正する。）。
【００３３】
図５に示すように、サーブＬＡＣはまず開始制御接続−要求（Start-Control-Connect-Request Message：ＳＣＣＲＱ)メッセージ（Ｌ２ＴＰの定義による）をアンカＬＡＣに送信し、両者間にトンネルを設定する。このメッセージを受信すると、アンカＬＡＣは開始制御接続−応答(Start-control-Connect-Reply Message:ＳＣＣＲＰ)によって応答する（これは上記で説明した何らかの認証に続いて行われる）。サーブＬＡＣは開始制御接続−接続(Start-Control-Connection-Connect：ＳＣＣＣＮ)メッセージによってアンカＬＡＣに対する確認を行う。
【００３４】
図５に示す開始制御接続(Start-Control-Connection)メッセージの交換に続いて、サーブＬＡＣは、図６に示すように、着信呼要求(Incoming-Call-Request：ＩＣＲＱ)メッセージをアンカＬＡＣに送信する。着信呼要求(Incoming-Call-Request)メッセージにはアンカＬＡＣがＬＮＳを識別するのに十分なユーザ・データと信用証明が含まれている。
【００３５】
前に述べたように、アンカＬＡＣとＬＮＳの間にトンネルが存在しない場合、アンカＬＡＣは、Ｌ２ＴＰの定義により、ＬＮＳとのＳＣＣＲ、ＳＣＣＲＰ、ＳＣＣＣＮメッセージ交換を開始する。トンネルが存在する場合、トンネル内の未使用スロットであるＣｉｄがアンカＬＡＣによって割り当てられる。この時点で、本発明の原理によれば、アンカＬＡＣはＩＣＲＱメッセージを（サーブＬＡＣから）中継し、ＬＮＳにこの新しいダイヤルアップ・セッションについて通知する。図６に示すように、アンカＬＡＣはＩＣＲＱメッセージをＬＮＳに中継する前にしかるべく修正する。修正されたフィールド、例えば、割当て呼ＩＤは、“*”によって示される。アンカＬＡＣはまた隠しＡＶＰを追加し、ＬＮＳにサポート可能な受信ウィンドウ・サイズを知らせる（追加ホップの場合、アンカＬＡＣは制御／ペイロード両方の接続について取り決められた最大ウィンドウ・サイズを記録することに留意されたい。また、サーブＬＡＣとアンカＬＡＣ間の制御接続のウィンドウ・サイズがアンカＬＡＣとＬＮＳ間の制御接続のものと異なっており、バッファリングが必要なことがある。バッファリングとシーケンス番号監視の追加を避けるために、アンカＬＡＣは必要に応じて、アンカＬＡＣがアンカＬＡＣからサーブＬＡＣの方向でサポートできるペイロード・セッション用の受信ウィンドウ・サイズをＬＮＳに知らせるＡＶＰを追加する。その結果、ＬＮＳは、ＩＣＲＰ応答の適当な受信ウィンドウ・サイズ値だけを含み、ひいてはＬＮＳ−アンカＬＡＣ−サーブＬＡＣ方向のペイロード・セッションのための１つのウィンドウ・サイズだけを含むことになる。）。
【００３６】
前に述べたように、ＬＮＳは接続を承認または拒否する。拒否は結果状態を含まなければならず、エラー表示を含むことがある。どちらの場合でも、ＬＮＳは、図６に示すように、着信呼応答(Incoming-Call-Reply：ＩＣＲＰ）メッセージをアンカＬＡＣに送信する。本発明によれば、次にアンカＬＡＣはＩＣＲＰメッセージを適当に修正し、サーブＬＡＣに中継する（やはり、修正されたフィールドは図６では“*”で示される）。ＬＮＳから受信されたパケット処理遅延（ＰＰＤ）フィールドにはＬＮＳの処理遅延だけが含まれるので、アンカＬＡＣはこの値にそれ自体のノードの処理遅延を追加する。次に、ＩＣＲＱメッセージがサーブＬＡＣに中継される。
【００３７】
それに応答して、サーブＬＡＣは、図７に示すように、着信呼接続(Incoming-Call-Connected：ＩＣＣＮ）メッセージをアンカＬＡＣに送信する。このメッセージの中で、サーブＬＡＣはすべてのＬＣＰ構成要求(Config Request)情報をプロキシ認証情報(Proxy Authentication Information)と共に伝える。すなわち、サーブＬＡＣはユーザの機器で行われたＬＣＰ構成要求／応答(Config Request/Ack)、ＰＰＰ ＰＡＰ／ＣＨＡＰの結果を転送する。アンカＬＡＣは、受信ＩＣＣＮメッセージのＰＰＤフィールドをＬＮＳに中継する前に修正する（現在、送信接続速度と受信接続速度は使用されない）。図示されていないが、本発明によれば、アンカＬＡＣはＬ２ＴＰで定義されたすべてのSet-Link-Info、HelloおよびWan-Error-Notifyメッセージをも中継する（上記の説明は多重ホップ・パケット・トンネルの概念を示すものであることが観察されるだろう。例えば、図１は２ホップ・パケット・トンネルを表している）。
【００３８】
上記で説明した多重ホップｍＬ２ＴＰトンネルはもっぱらフレーム層で発生することが観察されるだろう。すなわち、どんな目的のＰＰＰプロトコル処理でも、遠隔ユーザはＬＮＳと接続するように見えるので、ＬＮＳによるアドレス管理の実際の方法は上記で説明した仮想ダイヤルアップ・サービスとは無関係である。
【００３９】
＜移動ポイントツーポイント・プロトコル＞
ここで図８を参照すると、本発明の概念の他の実施例が示される。図８は図１と同様である。本発明の概念以外、構成要素は周知であるので、詳細には説明しない。同じ数字は同じ機能を示し、必要な場合以外それ以上説明しない。
過去
図８では、ＰＣ８０５には、パーソナル・コミュニケーション・サービス（Ｐersonal Ｃommunication Ｓervice：ＰＣＳ）無線ネットワーク８１０を通じてインターネットへの無線アクセスを確立するデータ通信機器（図示せず）が含まれる。ＰＣＳ無線ネットワークは当業技術分野で周知であるので詳細には説明しない。ＰＣＳ無線ネットワーク８１０は、要素８１５および８２０で表されるような複数の移動交換センタを備えている。各交換センタはある地理的範囲（図示せず）にサービスを提供する。要素８１５と８２０にはＮＡＳが含まれることが想定され、例えば、サーブＬＡＣは図１のサーブＬＡＣ１１５と同様である。まず、遠隔ユーザが上記で説明した多重ホップ技術を使用して企業のネットワークへのＶＰＮセッションを確立することが想定される。すなわち、遠隔ユーザは、この初期接続が要素８１５を通じて接続８１４と８１６により転送されるような地理的範囲にある。無線ＰＣＳ用の場合、初期ＰＰＰ接続は要素８１５とＰＣ８０５の間で行われる（簡単にするために交換要素の一部として示されているが、ＮＡＳ機能は機器の独立した部分でも行われる。同様に、ローカル・ネットワークやルータといった他の要素も簡単にするために図示しない）。
【００４０】
無線環境では、Ｌ２ＴＰのようなトンネル・プロトコルによっては遠隔ユーザが既存のＰＰＰ接続を１つの交換要素から他の交換要素に変更できないということが認識された。例えば、図８が本発明の概念を実施しないことを想定すると、遠隔ユーザが要素８２０（ひいては異なったＮＡＳ）のサービスの対象となる地理的範囲に移動する場合、ユーザの通信セッションは、当業技術分野で周知のように要素８２０に受け渡される。しかし、すでに述べたように、既存のＰＰＰ接続を１つのＮＡＳから別のＮＡＳに転送することはできないため、既存のＰＰＰ接続（ひいてはＶＰＮセッション）は中断し、復旧しなければならなくなる。この場合、図８の通信システムはこの問題を克服する。
【００４１】
従って、本発明によれば、ＮＡＳまたはＬＡＣは、既存のＮＡＳが既存のＰＰＰ接続を別のＮＡＳにハンドオフできるようにする「ハンドオフ」機能を組み込んでいる。この機能によれば、(ｉ)継続呼要求(Continued Call Request)、(ii)継続呼応答(Continued Call Reply)および(iii)継続呼接続(Continued Call Connect)という３つの新しい制御メッセージが定義される。上記の結果、ユーザは現行のＰＰＰ接続を終了してから新しいＰＰＰ接続を復旧する必要はない。この３つの制御メッセージは、Ｌ２ＴＰ制御メッセージ・ヘッダ、メッセージ識別子（例えば、継続呼要求等）および多数のフィールド（後で説明する）を含んでいる。
【００４２】
本発明の概念による、ハンドオフ・メッセージの流れの例を図９に示す。図９から観察されるように、トンネル（Ｔｉｄ値で示される）と呼（Ｃｉｄ値で示される）がまず要素８１５（ここにはサーブＬＡＣが含まれる）とアンカＬＡＣの間に確立される。同様に、アンカＬＡＣとＬＮＳの間にトンネルと呼が確立される（この初期ＶＰＮセッションを確立する方法は上記で説明済みである。）。図９に示すように、本発明の概念によれば、既存のサーブＬＡＣは既存のＰＰＰ接続を、要素８２０によって表されるような新しいサーブＬＡＣに転送することができる。
【００４３】
ここで、「ハンドオフ機能」を提供する際使用される方法の流れ図の例である図１０を参照されたい。すでに述べたように、ＰＣ８０５と企業のネットワークの間に要素８１５を通じたＶＰＮセッションが存在し、そこにサーブＬＡＣとアンカＬＡＣ１５５が含まれることが想定される。本発明の概念によれば、ＰＣＳ無線ネットワーク８１０は既存の呼状態変数に、各無線呼に関するＰＰＰ接続の存在（または存在しないこと）を示す追加変数を追加し、ＰＰＰ接続が存在する場合、例えば、アンカＬＡＣのＩＰアドレスであるアンカＬＡＣのＩＤを含むＰＰＰ接続情報を追加する。
【００４４】
図１０のステップ４０５では、ＰＣＳ無線ネットワーク８１０は、ＰＣ８０５が要素８１５のサービスの対象になる地理的範囲から別の地理的範囲、例えば、要素８２０のサービスの対象になり、別のサービスＬＡＣが含まれる範囲に移動したためハンドオフが必要になったことを検出する。ステップ４１０では、ＰＣＳ無線システムは要素８２０にハンドオフが迫っていることを通知する（ハンドオフを検出し遂行するために無線システムが使用する方法は当業技術分野で周知であり、本発明の概念には関連しない。従って、それらはここでは説明されず、図８の信号経路８１１で表される）。ここで、呼状態情報にはＰＰＰセッション識別子とＰＰＰ呼情報が含まれているので、（要素８２０の）新しいサーブＬＡＣはステップ４１５でアンカＬＡＣを識別する。ステップ４２０で、（要素８２０の）新しいサーブＬＡＣはそれ自体と識別されたアンカＬＡＣ（ここではアンカＬＡＣ１５５）の間にすでにトンネルがあるかを確認する。
【００４５】
トンネルがない場合、新しいサーブＬＡＣはまずステップ４２５で（前に説明されたように）トンネルを確立する。次に、本発明の概念によれば、新しいサーブＬＡＣはステップ４３０で継続呼要求(Continued-Call-Request：ＣＣＲＱ）メッセージをアンカＬＡＣに送信する。このＣＣＲＱメッセージには、既存のＰＰＰ接続に関連するユーザ名、移転先の（新しい）ＰＰＰセッションで使用されるＴｉｄとＣｉｄの値が含まれる。
【００４６】
ステップ４３５では、アンカＬＡＣは受信したＣＣＲＱメッセージからユーザ名を回復し、この情報を使用して古いサーブＬＡＣのＬＮＳとＩＰアドレスを、例えば、上記の表４で表される接続テーブルから判定する（この回復された情報には対応するユーザ・データグラム・プロトコル（Ｕser Ｄatagram Ｐrotocol：ＵＤＰ）ポート番号が含まれることもある）。このステップでは、アンカＬＡＣは呼切断通知(Call-Disconnect-Notify)メッセージ（例えば、Ｌ２ＴＰ参照）を古いサーブＬＡＣに送信し、かつ、例えば、上記の表４で、古いトンネルｉｄや古い呼ｉｄといった遠隔ユーザへのこのＰＰＰ接続に関連する既存の呼変数を識別する（他方、アンカＬＡＣが継続呼要求(Continued-Call-Request)を拒否した場合、サーブＬＡＣは、既存のＰＰＰセッションが切断され、新しいＰＰＰセッションが開始されるか、または単にＰＰＰセッションが中止されるように信号を返送する（このステップは図示しない））。
【００４７】
ステップ４４０では、アンカＬＡＣが適当な受信ウィンドウ・サイズで継続呼応答(Continued-Call-Reply：ＣＣＲＰ）メッセージによって応答する。ＣＣＲＰメッセージには現行のＮｒとＮｓの値に関する情報が含まれる。ステップ４４５では、（ステップ４３５で識別された）Ｔｉｄ、ＣｉｄおよびサーブＬＡＣのＩＰアドレス・フィールドのエントリを既存のＰＰＰ接続の新しい呼情報に置換することにより、接続テーブル（例えば、上記の表４）を更新する。ステップ４５０では、新しいサーブＬＡＣはＮｒ、ＮｓをＳｒ、Ｓｓ値に保存し、かつ必要な場合受信したＣＣＲＰメッセージから受信ウィンドウ・サイズを保存し、継続呼接続（Continued-Call-Connect：ＣＣＣＮ）メッセージをアンカＬＡＣに送信し、これをもってハンドオフを完了する。
【００４８】
ＰＰＰプロトコルの上記で説明したハンドオフ機能を裏付けるものとして、図１１は本発明の原理による上記で言及した新しい制御メッセージ・トランザクションの例を示す。図１１に示すように、ＣＣＲＱメッセージが識別されたアンカＬＡＣに送信される。
【００４９】
ＣＣＲＱメッセージは次のフィールドを含む。
−割当てＣｉｄ
−呼シリアルナンバー
−ベアラ（bearer:運搬）の種類
−物理チャネルＩＤ
−ダイヤルされた番号
−ダイヤルする番号
−副アドレス
−アンカＬＡＣ
−チャレンジ
−ユーザＡＶＰ
−ユーザ名
−ユーザのＭＩＮ／電話番号
【００５０】
アンカＬＡＣのフィールドは、この情報がハンドオフの際に利用可能であることを想定している（また、ハンドオフ処理がアンカＬＡＣに関する情報を新しいサーブＬＡＣに提供しない場合、ハンドオフ処理は、当業技術分野で周知のように新しいサーブＬＡＣが外部ラディアス・サーバの助けによってアンカＬＡＣ情報を検索する十分なユーザ情報を新しいサーブＬＡＣに提供しなければならない。すなわち、新しいサーブＬＡＣはラディアス・アクセス／応答メッセージにより、ホームラディアスサーバからアンカＬＡＣについて照会する。）。
【００５１】
ユーザＡＶＰ情報には（ユーザ名のような）ユーザ情報と、例えば、多重ホップ仮想ダイヤルアップ・サービス、ユーザのＩＤ（ＭＩＮ）、サービス・プロバイダの電話番号等といった他のユーザの信用証明が含まれる。
【００５２】
ＣＣＲＱメッセージに続いて、アンカＬＡＣは呼切断通知(Call-Disconnect-Notify)メッセージを古いサーブＬＡＣに送信する。次に、アンカＬＡＣは、保守の対象となる現行Ｓｒ、Ｓｓを含む継続呼応答(Continued-Call-Reply:ＣＣＲＰ）メッセージによって応答する。
【００５３】
ＣＣＲＰメッセージは次のフィールドを含む。
−割当てＣｉｄ
−結果コード
−受信ウィンドウ・サイズ
−ＰＰＤ
−Ｎｒ
−Ｎｓ
−チャレンジ
−チャレンジ応答
【００５４】
最後に、新しいサーブＬＡＣが継続呼接続(Continued-Call Connect：ＣＣＣＮ）によって応答する。ＣＣＣＮメッセージは次のフィールドを含む。
−接続速度
−フレーム種類
−受信ウィンドウ・サイズ
−ＰＰＤ
−チャレンジ応答
【００５５】
ここで図１２を参照すると、既存のＰＰＰ接続を１つのＮＡＳから別のＮＡＳに移転し、その際古いＮＡＳがＬＮＳに接続している場合、本発明の概念の他の実施例が示される（この例では、サーブＬＡＣは本質的に存在せず、例えば、もっと簡単に、アンカＬＡＣが既存のＰＰＰ接続を直接サポートする）。図１２は図８と同様である。本発明の概念以外、構成要素は周知であるので、詳細には説明しない。同じ数字は同じ機能を示し、必要な場合以外それ以上説明しない。
【００５６】
図１２では、ＰＣ８０５には、パーソナル・コミュニケーション・サービス（Ｐersonal Ｃommunication Ｓervice ：ＰＣＳ）無線ネットワーク９１０を通じてインターネットへの無線アクセスを確立するデータ通信機器（図示せず）が含まれる。ＰＣＳ無線サービスは当業技術分野で周知であるので詳細には説明しない。ＰＣＳ無線ネットワーク９１０は要素８７５および８８０で表されるような複数の移動交換センタを含む。各交換センタはある地理的範囲（図示せず）にサービスを提供する。要素８７５と８８０には、例えば、図１のアンカＬＡＣ１１５と同様のＬＡＣであるＮＡＳが含まれる。まず、遠隔ユーザが、例えば、Ｌ２ＴＰの該当部分を使用して、当業技術分野で周知のように企業のネットワークへのＶＰＮセッションを確立することが想定される。すなわち、遠隔ユーザはこの最初の接続が要素８７５を通じて接続８７４と８７６によりＬＮＳ９３５に転送されるような地理的範囲にある。無線ＰＣＳ適用業務の場合、初期ＰＰＰ接続は要素８７５とＰＣ８０５の間で行われる（簡単にするために交換要素の一部として示されているが、ＮＡＳ機能は機器の独立した部分でも行われる。同様に、ローカル・ネットワークやルータといった他の要素も簡単にするために図示しない）。
【００５７】
この実施例では、上記で説明したＣＣＲＱ、ＣＣＲＰ、ＣＣＣＮメッセージが新しいＬＡＣとＬＮＳの間で交換される点以外は、同じハンドオフ手順がＬＡＣ／ＬＮＳペアについて実行される。本発明の概念による、ハンドオフ・メッセージの流れの例を図１３に示す。図１３から観察されるように、トンネル（Ｔｉｄ値で示される）と呼（Ｃｉｄ値で示される）がまず要素８７５（ここにはＬＡＣが含まれる）とＬＮＳ９３５の間に確立される。図１３に示すように、本発明の概念は、既存のＬＡＣが既存のＰＰＰ接続を、要素８８０で表される新しいＬＡＣに移転することを可能にする。
【００５８】
ここで、「ハンドオフ機能」を提供する再使用される方法の流れ図の例である図１４を参照されたい。すでに述べたように、ＰＣ８０５と企業のネットワークの間に、ＬＡＣを含む要素８７５を通じてＶＰＮセッションが存在していることが想定される。本発明の概念によれば、ＰＣＳ無線ネットワーク９１０は既存の呼状態変数に、各無線呼に関するＰＰＰ接続の存在（または存在しないこと）を示す状態変数を追加し、ＰＰＰ接続が存在する場合、例えば、ＬＮＳのＩＰアドレスであるＬＮＳのＩＤを含むＰＰＰ接続情報を追加する。
【００５９】
図１４のステップ５０５では、ＰＣＳ無線ネットワーク９１０は、ＰＣ８０５が要素８７５のサービスの対象になる地理的範囲から別の地理的範囲、例えば、要素８８０のサービスの対象になり、別のサービスＬＡＣが含まれる範囲に移動したためハンドオフが必要になったことを検出する。ステップ５１０では、ＰＣＳ無線システムは要素８８０にハンドオフが迫っていることを通知する（ハンドオフを検出し遂行するために無線システムが使用する方法は当業技術分野で周知であり、本発明の概念には関連しない。従って、それらはここでは説明されず、図１２の信号経路９１１で表される）。ここで、呼状態情報にはＰＰＰセッション識別子とＰＰＰ呼情報が含まれているので、（要素８８０の）新しいＬＡＣはステップ５１５でアンカＬＡＣを識別する。ステップ５２０で、（要素８８０の）新しいＬＡＣはそれ自体と識別されたＬＮＳ（ここではＬＮＳ９３５）の間にすでにトンネルがあるかを確認する。
【００６０】
トンネルがない場合、新しいＬＡＣはまずステップ５２５で（前に説明されたように）トンネルを確立する。次に、本発明の概念によれば、新しいＬＡＣはステップ５３０で継続呼要求(Continued-Call-Request:ＣＣＲＱ）メッセージをＬＮＳに送信する。このＣＣＲＱメッセージには、既存のＰＰＰ接続に関連するユーザ名、移動先の（新しい）ＰＰＰセッションで使用されるＴｉｄとＣｉｄの値が含まれる。
【００６１】
ステップ５３５では、ＬＮＳは受信したＣＣＲＱメッセージからユーザ名を回復し、この情報を使用して古いＬＡＣのＩＰアドレスを判定する（この回復された情報には対応するユーザ・データグラム・プロトコル（Ｕser Ｄatagram Ｐrotocol:ＵＤＰ）ポート番号が含まれることもある）。このステップでは、アンカＬＡＣは呼切断通知(Call-Disconnect-Notify)メッセージ（例えば、Ｌ２ＴＰ参照）を古いＬＡＣに送信し、かつ、例えば、上記の表４で示されるものと同様だが、サーブＬＡＣ情報等は除く接続テーブルで、古いトンネルｉｄや古い呼ｉｄといった遠隔ユーザへのこのＰＰＰ接続に関連する既存の呼変数を識別する（他方、ＬＮＳが継続呼要求(Continued-Call-Request)を拒否した場合、新しいＬＡＣは、既存のＰＰＰセッションが切断され、新しいＰＰＰセッションが開始されるか、または単に古いＰＰＰセッションが中止されるように信号を返送する（このステップは図示しない））。
【００６２】
ステップ５４０では、ＬＮＳが適当な受信ウィンドウ・サイズで継続呼応答(Continued-Call-Reply:ＣＣＲＰ）メッセージによって応答する。ＣＣＲＰメッセージには現行のＮｒとＮｓの値に関する情報が含まれる。ステップ５４５では、ＬＮＳは、（ステップ５３５で識別された）Ｔｉｄ、ＣｉｄおよびＬＡＣのＩＰアドレス・フィールドのエントリを既存のＰＰＰ接続の新しい呼情報に置換することにより、接続テーブルを更新する。ステップ５５０では、新しいＬＡＣはＮｒ、Ｎｓを更新し、必要な場合受信したＣＣＲＰメッセージからＮｒ、Ｎｓと受信ウィンドウ・サイズを更新し、継続呼接続(Continued-Call-Connect:ＣＣＣＮ）メッセージをＬＮＳに送信し、これをもってハンドオフを完了する。
【００６３】
ＰＰＰプロトコルの上記で説明したハンドオフ機能を裏付けるものとして、図１５は本発明の原理による新しい制御メッセージ・トランザクションを示す。図１５に示すように、ＣＣＲＱメッセージが識別されたＬＮＳに送信される（また、ハンドオフ処理がＬＮＳに関する情報を新しいＬＡＣに提供しない場合、ハンドオフ処理は、当業技術分野で周知のように新しいＬＡＣが外部ラディアスサーバの助けによってＬＮＳ情報を検索する十分なユーザ情報を新しいＬＡＣに提供しなければならない。すなわち、新しいＬＡＣはラディアスアクセス／応答メッセージにより、ホームラディアスサーバからＬＮＳについて照会する）。ＣＣＲＱメッセージに続いて、ＬＮＳは呼切断通知(Call-Disconnect-Notify)メッセージを古いＬＡＣに送信する。次に、ＬＮＳは、保守の対象となる現行Ｓｒ、Ｓｓを含む継続呼応答(Continued-Call-Reply:ＣＣＲＰ）メッセージによって応答する。最後に、新しいＬＡＣが継続呼接続(Continued-Call Connect:ＣＣＣＮ）によって応答する。
【００６４】
上記で説明したように、ＰＰＰ接続は１つのＮＡＳから別のＮＡＳに移転される。新しく定義されたメッセージを裏付けるものとして、以下図５および図６に示されるように対応するＮＡＳについて追加呼状態が定義される。
【表５】
【００６５】
古いＬＡＣ（またはＮＡＳ）について、確立された状態で呼切断通知(Call-Disconnect-Notify:ＣＤＮ）メッセージが受信されることに留意されたい。それに応答して、古いＬＡＣは呼をクリーンアップして切断し、アイドル状態に戻る。
【表６】
【００６６】
＜ペイロード・メッセージの概観とｍＬ２ＴＰの輻輳制御＞
ｍＬ２ＴＰのペイロード・メッセージに関して、サーブＬＡＣとＬＮＳはＬ２ＴＰ手順を遵守する。アンカＬＡＣはペイロード・パケットについてＴｉｄとＣｉｄをスワップする。また、アンカＬＡＣはサーブＬＡＣが送信する（Ｎｒ、Ｎｓ）値を監視する（サーブＬＡＣとアンカＬＡＣの間にはパケット損失が存在するので、アンカＬＡＣのＳｒおよびＳｓの値はどちらもサーブＬＡＣが保守するこれらの数値より遅れると考えられることに留意されたい。）アンカＬＡＣはどちらの方向でもペイロード・パケットの（Ｎｒ、Ｎｓ）を変更しない。アンカＬＡＣは、継続呼要求(Continued-Call-Request)メッセージを新しいサーブＬＡＣから受信する時それ自体のＳｒ、Ｓｓ値だけを利用する。
【００６７】
輻輳制御に関して、Ｌ２ＴＰは受信ウィンドウ・サイズを維持する時期、Ｎｒ／Ｎｓを送信する時期およびＡＣＫを送信する時期に関するＬ２ＴＰの要求をｍＬ２ＴＰに適用する。さらに、ｍＬ２ＴＰはサーブＬＡＣとアンカＬＡＣについて次の追加要求を有する。
【００６８】
アンカＬＡＣはサーブＬＡＣが送信した（Ｎｒ、Ｎｓ）値の監視が必要である。アンカＬＡＣは、サーブＬＡＣから受信する継続呼接続(Continued-Call-Connect)メッセージに応答する時継続呼応答(Continued-Call-Reply)メッセージの中で保守する（Ｓｒ、Ｓｓ）値を含むべきである。サーブＬＡＣとアンカＬＡＣの間のネットワークは損失が大きいので、アンカＬＡＣが保守するＳｒ値はサーブＬＡＣより遅れることがある。
【００６９】
さらに、サーブＬＡＣは、当業技術分野の用語に従えば、単純なレシーバではなく完全なレシーバである。この要求は、ＰＰＰセッションの継続期間中にサーブＬＡＣの変更がある場合、新しいサーブＬＡＣがシーケンス外や重複したパケットを上部層に伝えないということである。
【００７０】
簡単に図１６を参照すると、代表的なＮＡＳの高レベル・ブロック図が示される。ＮＡＳは蓄積プログラム制御ベース・プロセッサ・アーキテクチャであり、プロセッサ６５０、メモリ６６０（プログラムの命令と、上記で言及した接続テーブル等のデータを保存する）および経路６６６で表されるように１つかそれ以上の通信機能を結合する通信インタフェース６６５を含む。
【００７１】
以上は本発明の原理を例示したものに過ぎず、当業技術分野に熟練した者には、ここで明示的に説明されていなくとも、本発明の原理を実施しその精神と範囲の中にある非常に多くの代替装置が考案できることを認識することができるだろう。例えば、本発明の概念はサーブＮＡＳが着信呼に関する多重ホップ・トンネルの確立を開始する場合で説明されたが、本発明の概念は、例えば、ＬＮＳが発信呼に関する多重ホップ・シーケンスを開始する場合にも等しく適用できる。こうした修正は簡単明瞭であり、図１７及び図１８で示されているのでここでは説明しない。
【図面の簡単な説明】
【図１】本発明の原理による通信システムを示す図である。
【図２】図１の通信システムを使用する例示としての方法の流れ図を示す図である。
【図３】図１の通信システムを使用する例示としての方法の流れ図を示す図である。
【図４】例示としての多重ホップ・メッセージの流れを示す図である。
【図５】例示としての制御メッセージのトランザクションを示す図である。
【図６】例示としての制御メッセージのトランザクションを示す図である。
【図７】例示としての制御メッセージのトランザクションを示す図である。
【図８】本発明の原理による通信システムの他の実施例を示す図である。
【図９】例示としてのハンドオフ・メッセージの流れを示す図である。
【図１０】図８の通信システムで使用される例示としての方法の流れ図を示す図である。
【図１１】例示としての制御メッセージのトランザクションを示す図である。
【図１２】本発明の原理による通信システムの他の実施例を示す図である。
【図１３】例示としてのハンドオフ・メッセージの流れを示す図である。
【図１４】図１２の通信システムで使用される例示としての方法の流れ図を示す図である。
【図１５】例示としての制御メッセージのトランザクションを示す図である。
【図１６】ネットワーク・アクセス・サーバの例示としての高レベル・ブロック図を示す図である。
【図１７】発信呼用の例示としての制御メッセージ・トランザクションを示す図である。
【図１８】発信呼用の例示としての制御メッセージ・トランザクションを示す図である。
Claims (6)
- ポイント−ツー−ポイント（ＰＰＰ）接続を確立するのに用いられるネットワーク・アクセス・サーバで用いられる方法であって、
ＰＰＰ呼を継続することを表すメッセージを受信する段階と、
ＬＡＣとして動作する一のネットワークアクセスサーバからＬＡＣとして動作する他のネットワークサーバへ、ユーザ装置から前記一のネットワークアクセスサーバへの呼を中断することなく、ユーザのＰＰＰ接続を転送する段階とからなり、前記転送する段階は、前記一のネットワークアクセスサーバと前記他のネットワークサーバとの間でトンネルが確立していないときには、前記トンネルを確立する段階と、前記ユーザのＰＰＰ接続からのパケットを前記トンネルを介して前記他のネットワークサーバへ運搬する段階とを含み、該方法はさらに、
呼に対する多重ホップトンネルをサポートする段階とからなり、前記多重ホップトンネルの少なくとも１つのトンネルが修正されたレイヤ２−トンネルプロトコル（Ｌ２ＴＰ）トンネルであることを特徴とする方法。 - 請求項１に記載の方法において、前記メッセージは、Ｌ２ＴＰの継続呼要求メッセージであることを特徴とする方法。
- 請求項１に記載の方法において、前記メッセージは、トンネリングをサポートするプロトコルの継続呼要求メッセージであることを特徴とする方法。
- 請求項１に記載の方法であってさらに、カプセル化パケットを前記他のネットワークアクセスサーバへ通信する段階からなることを特徴とする方法。
- ネットワーク・アクセス・サーバで用いる方法であって、
ＬＡＣとして動作する第１のネットワーク・アクセス・サーバから第２のネットワーク・アクセス・サーバへの第１のトンネルを確立する段階からなり、前記第１のトンネルは前記第１のネットワーク・アクセス・サーバとユーザ装置との間の現存のポイント−ツー−ポイント接続からのパケットを前記第２のネットワーク・アクセス・サーバへ運搬するものであり、該方法はさらに、
新しいＬＡＣとして動作する前記第２のネットワーク・アクセス・サーバからＬＮＳとして動作する第３のネットワーク・アクセス・サーバへ第２のトンネルを確立する段階からなることを特徴とする方法。 - ネットワーク・アクセス・サーバで用いる方法であって、
継続呼を表すメッセージを受信する段階と、
ＬＡＣとして動作する第１のパケット・サーバからＬＡＣとして動作する第２のパケット・サーバへ、ユーザ装置から前記第１のパケットサーバへの呼を中断することなく、ユーザのポイント−ツー−ポイント（ＰＰＰ）接続を転送する段階からなり、前記転送する段階は、前記第１のパケットサーバと第２のパケットサーバとの間でトンネルが確立していないときには、前記トンネルを確立し、そして前記ユーザのＰＰＰ接続からのパケットを前記トンネルを介して前記第２のパケットサーバへ運搬する段階とを含み、該方法はさらに、
前記呼のために、修正されたレイヤ２−トンネルプロトコル（Ｌ２ＴＰ）に基づく多重ホップトンネルをサポートする段階からなり、少なくとも第１のホップは第１のパケットサーバと第２のパケットサーバとの間であり、そして第２のホップは第１のパケットサーバとＬＮＳとして動作する第３のパケットサーバとの間であることを特徴とする方法。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/074582 | 1998-05-08 | ||
| US09/074,582 US6801509B1 (en) | 1998-05-08 | 1998-05-08 | Mobile point-to-point protocol |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH11355271A JPH11355271A (ja) | 1999-12-24 |
| JP3836272B2 true JP3836272B2 (ja) | 2006-10-25 |
Family
ID=22120350
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP12656299A Expired - Fee Related JP3836272B2 (ja) | 1998-05-08 | 1999-05-07 | 移動ポイント・ツー・ポイント・プロトコル |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US6801509B1 (ja) |
| EP (1) | EP0955747A2 (ja) |
| JP (1) | JP3836272B2 (ja) |
| CA (1) | CA2267001A1 (ja) |
Families Citing this family (32)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5835061A (en) | 1995-06-06 | 1998-11-10 | Wayport, Inc. | Method and apparatus for geographic-based communications service |
| US8606851B2 (en) | 1995-06-06 | 2013-12-10 | Wayport, Inc. | Method and apparatus for geographic-based communications service |
| ES2760905T3 (es) | 1998-10-30 | 2020-05-18 | Virnetx Inc | Un protocolo de red agile para comunicaciones seguras con disponibilidad asegurada de sistema |
| US10511573B2 (en) | 1998-10-30 | 2019-12-17 | Virnetx, Inc. | Agile network protocol for secure communications using secure domain names |
| US6826616B2 (en) | 1998-10-30 | 2004-11-30 | Science Applications International Corp. | Method for establishing secure communication link between computers of virtual private network |
| US6502135B1 (en) | 1998-10-30 | 2002-12-31 | Science Applications International Corporation | Agile network protocol for secure communications with assured system availability |
| US7418504B2 (en) | 1998-10-30 | 2008-08-26 | Virnetx, Inc. | Agile network protocol for secure communications using secure domain names |
| GB9913102D0 (en) * | 1999-06-04 | 1999-08-04 | Nokia Telecommunications Oy | An element for a communications system |
| AU773884B2 (en) * | 1999-11-03 | 2004-06-10 | Cisco Technology, Inc. | Distributed network communication system which enables multiple network providers to use a common distributed network infrastructure |
| US20020022483A1 (en) * | 2000-04-18 | 2002-02-21 | Wayport, Inc. | Distributed network communication system which allows multiple wireless service providers to share a common network infrastructure |
| US7193980B2 (en) * | 2000-07-06 | 2007-03-20 | Nortel Networks Limited | Continuation session attribute |
| US20020101859A1 (en) * | 2000-09-12 | 2002-08-01 | Maclean Ian B. | Communicating between nodes in different wireless networks |
| US7054321B1 (en) * | 2000-10-27 | 2006-05-30 | Redback Networks Inc. | Tunneling ethernet |
| US7124189B2 (en) * | 2000-12-20 | 2006-10-17 | Intellisync Corporation | Spontaneous virtual private network between portable device and enterprise network |
| US8266677B2 (en) * | 2000-12-20 | 2012-09-11 | Intellisync Corporation | UDP communication with a programmer interface over wireless networks |
| US7046646B2 (en) * | 2001-01-29 | 2006-05-16 | Ipr Licensing, Inc. | Method and apparatus for simple PPP handoff for mobile users |
| US20030233580A1 (en) * | 2002-05-29 | 2003-12-18 | Keeler James D. | Authorization and authentication of user access to a distributed network communication system with roaming features |
| US7096024B2 (en) * | 2003-01-31 | 2006-08-22 | Qualcomm, Incorporated | Method and apparatus to initiate point-to-point call during shared-channel delivery of broadcast content in a wireless telephone network |
| JP4173517B2 (ja) * | 2003-03-05 | 2008-10-29 | インテリシンク コーポレイション | コンピューティング・ネットワークとリモート装置との間のバーチャル・プライベート・ネットワーク |
| US20050261970A1 (en) | 2004-05-21 | 2005-11-24 | Wayport, Inc. | Method for providing wireless services |
| US7215960B2 (en) * | 2004-12-30 | 2007-05-08 | Lucent Technologies Inc. | Hand-off technique for a wireless network |
| FR2889018B1 (fr) * | 2005-07-20 | 2007-09-21 | Kerlink Sa | Procede et dispositif de connexion optimisee et securisee d'un terminal client de radiocommunication a un autre terminal distant de capture et/ou de mise a disposition d'informations |
| EP2026529A1 (en) | 2007-07-12 | 2009-02-18 | Wayport, Inc. | Device-specific authorization at distributed locations |
| US8639267B2 (en) | 2008-03-14 | 2014-01-28 | William J. Johnson | System and method for location based exchanges of data facilitating distributed locational applications |
| US8566839B2 (en) | 2008-03-14 | 2013-10-22 | William J. Johnson | System and method for automated content presentation objects |
| US8923806B2 (en) | 2008-03-14 | 2014-12-30 | William J. Johnson | System and method for presenting application data by data processing system(s) in a vicinity |
| US8634796B2 (en) | 2008-03-14 | 2014-01-21 | William J. Johnson | System and method for location based exchanges of data facilitating distributed location applications |
| US8761751B2 (en) | 2008-03-14 | 2014-06-24 | William J. Johnson | System and method for targeting data processing system(s) with data |
| US8600341B2 (en) | 2008-03-14 | 2013-12-03 | William J. Johnson | System and method for location based exchanges of data facilitating distributed locational applications |
| WO2013133870A2 (en) | 2012-03-07 | 2013-09-12 | Snap Trends, Inc. | Methods and systems of aggregating information of social networks based on geographical locations via a network |
| US9477991B2 (en) | 2013-08-27 | 2016-10-25 | Snap Trends, Inc. | Methods and systems of aggregating information of geographic context regions of social networks based on geographical locations via a network |
| US9894489B2 (en) | 2013-09-30 | 2018-02-13 | William J. Johnson | System and method for situational proximity observation alerting privileged recipients |
Family Cites Families (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6006090A (en) * | 1993-04-28 | 1999-12-21 | Proxim, Inc. | Providing roaming capability for mobile computers in a standard network |
| US5794149A (en) * | 1995-12-29 | 1998-08-11 | Lucent Technologies Inc. | Base station controlled handoff method and apparatus |
| JP3591996B2 (ja) * | 1996-08-29 | 2004-11-24 | Ｋｄｄｉ株式会社 | 帯域確保型ｖｐｎ構築方法 |
| US6061346A (en) * | 1997-01-17 | 2000-05-09 | Telefonaktiebolaget Lm Ericsson (Publ) | Secure access method, and associated apparatus, for accessing a private IP network |
| US6075783A (en) * | 1997-03-06 | 2000-06-13 | Bell Atlantic Network Services, Inc. | Internet phone to PSTN cellular/PCS system |
| US6137791A (en) * | 1997-03-25 | 2000-10-24 | Ericsson Telefon Ab L M | Communicating packet data with a mobile station roaming within an incompatible mobile network |
| US6026085A (en) * | 1997-04-08 | 2000-02-15 | 3Com Corporation | Architecture to support a single system image across multiple network access servers |
| US5949773A (en) * | 1998-03-31 | 1999-09-07 | Motorola, Inc. | Method for transferring a data signal in a wireless communications system |
| US6052725A (en) * | 1998-07-02 | 2000-04-18 | Lucent Technologies, Inc. | Non-local dynamic internet protocol addressing system and method |
| US6094437A (en) * | 1998-10-09 | 2000-07-25 | Asc - Advanced Switching Communications | Layer two tunneling protocol (L2TP) merging and management |
-
1998
- 1998-05-08 US US09/074,582 patent/US6801509B1/en not_active Expired - Lifetime
-
1999
- 1999-03-24 CA CA002267001A patent/CA2267001A1/en not_active Abandoned
- 1999-04-27 EP EP99303276A patent/EP0955747A2/en not_active Withdrawn
- 1999-05-07 JP JP12656299A patent/JP3836272B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH11355271A (ja) | 1999-12-24 |
| US6801509B1 (en) | 2004-10-05 |
| CA2267001A1 (en) | 1999-11-08 |
| EP0955747A2 (en) | 1999-11-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3836272B2 (ja) | 移動ポイント・ツー・ポイント・プロトコル | |
| JP3470882B2 (ja) | 多重ホップ・ポイント・ツー・ポイント・プロトコル | |
| US6496491B2 (en) | Mobile point-to-point protocol | |
| JP3515983B2 (ja) | インターネットへのダイレクトワイヤレスアクセスを含む、ネットワークアクセス方法 | |
| US6061650A (en) | Method and apparatus for transparently providing mobile network functionality | |
| US7734789B2 (en) | Method and device for tunnel switching | |
| US6947400B2 (en) | Achieving PPP mobility via the mobile IP infrastructure | |
| US6456603B1 (en) | Method of supporting communications mobility in a telecommunications system | |
| US20020085549A1 (en) | Application-level mobility support in communications network | |
| JPH11275154A (ja) | メッセージ配信シーケンス | |
| JPH11289353A (ja) | ネットワークにおける会計システム | |
| JP2000022758A (ja) | ネットワークにおけるインターワーキング機能選択システム | |
| US8396027B2 (en) | Communication control system, communication system and communication control method | |
| JPH11331276A (ja) | ネットワークのための登録方法 | |
| JPH11275155A (ja) | ネットワークにおけるメッセージおよび通信システム | |
| JPH11252183A (ja) | イーサネット（登録商標）フレームにおけるポイント・ツー・ポイント・プロトコルのカプセル化 | |
| JPH11275156A (ja) | ピア・ツー・ピア プロトコルサーバを用いた通信 | |
| US7225236B1 (en) | Load balancing between LNSs using virtual LNS with minimal LAC configuration | |
| US8254408B2 (en) | Modular implementation of a protocol in a network device | |
| Cisco | Configuring PPP for Wide-Area Networking | |
| Cisco | Configuring PPP for Wide-Area Networking | |
| Cisco | Configuring PPP for Wide-Area Networking | |
| JP3609677B2 (ja) | モバイルパケットｌａｎ接続システム、パケット交換装置およびｌａｎ側接続装置 | |
| JP2001285354A (ja) | 通信路設定方法 | |
| WO2006079954A1 (en) | Method and terminal for selecting a communication path depending on the presence of nat devices |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20040216 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040616 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20040730 |
|
| A912 | Re-examination (zenchi) completed and case transferred to appeal board |
Free format text: JAPANESE INTERMEDIATE CODE: A912 Effective date: 20040827 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060726 |
|
| 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: 20090804 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100804 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110804 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110804 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120804 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120804 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130804 Year of fee payment: 7 |
|
| 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 |
|
| LAPS | Cancellation because of no payment of annual fees |