JP2005045791A - 移動ポイント・ツー・ポイント・プロトコル - Google Patents

Abstract

【課題】 本発明は、パケット通信システムに関する。
【解決手段】 パケット・データを転送するための装置が、既存のＰＰＰ接続を１つのパケット・サーバから別のパケット・サーバへ移すことができる「ハンドオフ」の機能を組み込んでいる。そのようなハンドオフ制御メッセージまたは呼継続トランザクションは、そのトランザクションに関与している任意のサーバから起動することができる。たとえば、ユーザが第１のパケット・サーバによってサービスされている領域から出て、第３のパケット・サーバ（たとえば、第２のサービス中のＬＡＣ）によってサービスされている領域の中へ移動した場合、本発明によるハンドオフ制御メッセージ・トランザクションが起動される。第２のサービス中のＬＡＣまたはアンカーＬＡＣがその呼継続トランザクションを起動することができる。
【選択図】 図１

Description

本発明は、概して、通信に関し、特にパケット通信システムに関する。

＜関連出願に対する相互参照＞
本発明は、１９９８年５月８日付けの同時係属米国特許出願第０９／０７４，５８２号の一部継続出願である。

通信手段としてのインターネットの１つの使用は、「仮想プライベート・ネットワーク」（ＶＰＮ）と呼ばれるものを提供するために、ワークグループを一緒に結合するための高度化されたデータ・バックボーンである。ＶＰＮの１つの応用は企業環境における応用であり、たとえば、家にいる従業員が、インターネットを経由して企業のデータ・ネットワークにリモートにアクセスできるような環境における応用である。ＶＰＮは公共の施設を使っているにもかかわらず、閉じられたユーザ・グループを結合するために、リモートのユーザに対してセキュリティおよび認証を提供する。実際に、ＶＰＮの使用は企業およびその従業員に対してＷＡＮに似た手段を提供する。（企業ネットワークは直接リモート・アクセスすること、たとえば、ユーザが企業ネットワークの中に直接ダイアルすることもできるが、ＶＰＮを使う方が経済的に有利である）

ＶＰＮを提供するために、「ポイント・ツー・ポイントのトンネリング・プロトコル」（ＰＰＴＰ）や「レイヤー２転送」（Ｌ２Ｆ）プロトコルなどのトンネリング・プロトコルが使われる。一般的に言うと、トンネリング・プロトコルによって、１つのパケットを別のパケットの内側に入れることによって、公共のネットワークを経由してプライベートなデータ・ストリームを生成することができる。ＶＰＮの場合においては、ＩＰパケットが別のＩＰパケットの内部に入れられる。業界標準を開発しようとする試みの中で、Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ（インターネット・エンジニアリング・タスク・フォース）（ＩＥＴＦ）が“Ｌａｙｅｒ ２ Ｔｕｎｎｅｌｉｎｇ Ｐｒｏｔｏｃｏｌ”（レイヤー２のトンネリング・プロトコル）（Ｌ２ＴＰ）を開発中であり、それはＰＰＴＰとＬ２Ｆプロトコルのハイブリッドである（たとえば、Ｋ．ハムゼー（Ｈａｍｚｅｈ）、Ｔ．コラール（Ｋｏｌａｒ）、Ｍ．リトルウッド（Ｌｉｔｔｌｅｗｏｏｄ）、Ｇ．サイン・ポール（Ｓｉｎｇｈ Ｐａｌｌ）、Ｊ．タールッド（Ｔａａｒｕｄ）、Ａ．Ｊ．ヴァレンシア（Ｖａｌｅｎｃｉａ）、Ｗ．ヴェルザイン（Ｖｅｒｔｈｅｉｎ）のＬａｙｅｒ ２ Ｔｕｎｎｅｌｉｎｇ Ｐｒｏｔｏｃｏｌ“Ｌ２ＴＰ”（レイヤー２のトンネリング・プロトコル）（Ｌ２ＴＰ）；Ｉｎｔｅｒｎｅｔ ｄｒａｆｔ、１９９８年３月を参照されたい）。
リモートのユーザの場合、ＶＰＮに対するアクセスの代表的な形式は、ＶＰＮサービスを提供する「インターネット・サービス・プロバイダ」（ＩＳＰ）に対して「在来型の電話サービス」（ＰＯＴＳ）の接続を経由する形式である。たとえば、ユーザはアナログのモデムをパーソナル・コンピュータまたはそれと等価な装置の中に組み込み、ここで「ホーム」ＩＳＰと呼ばれる特定のＩＳＰについて顧客の口座を有する。（また、そのユーザのパーソナル・コンピュータは上記トンネリング・プロトコルの１つをサポートするように適切に構成されていることが仮定されている。）そのユーザはホームＩＳＰに対してデータ呼出しを単純に行うことによって、たとえば、「ホーム」ＩＳＰに関連付けられている電話番号をダイアルし、ＶＰＮに対して「ログイン」することによって、ＶＰＮにアクセスする。

ＩＳＰに対するアクセスは、ネットワーク・アクセス・サーバ（ＮＡＳ）経由で行われる。筆者等は、個人通信サービス（ＰＣＳ）無線環境においては、上記トンネリング・プロトコルはリモートのユーザが既存の呼出しにおいて、アクセスを提供しているＮＡＳをＶＰＮに変更することを許さないことを実感している。したがって、ユーザが物理的に移動することによって、そのユーザが既存のＶＰＮ接続から切り離されるか、あるいはドロップされる可能性がある。

したがって、本発明の１つの態様によれば、パケット・データを転送するための装置および方法が、既存のポイント・ツー・ポイント（ＰＰＰ）接続を１つのパケット・サーバから別のパケット・サーバへ移すことを許す「ハンドオフ」機能を提供する。

本発明の１つの実施形態においては、３つの新しいハンドオフ制御メッセージがパケット・サーバで使うために定義されている。すなわち、（ｉ）Ｃｏｎｔｉｎｕｅｄ Ｃａｌｌ Ｒｅｑｕｅｓｔ（継続型の呼要求）、（ii）Ｃｏｎｔｉｎｕｅｄ Ｃａｌｌ Ｒｅｐｌｙ（継続型の呼応答）、および（iii）Ｃｏｎｔｉｎｕｅｄ Ｃａｌｌ Ｃｏｎｎｅｃｔ（継続型の呼接続）である。これらの新しい３つの制御メッセージはＬ２ＴＰ制御メッセージ・ヘッダ、メッセージ識別子（たとえば、Ｃｏｎｔｉｎｕｅｄ Ｃａｌｌ Ｒｅｑｕｅｓｔなど）、およびいくつかのフィールドを含む。結果として、ユーザは現在のＰＰＰ接続をターミネートしてから新しいＰＰＰ接続を再確立する必要はない。

有利なこととして、そのようなハンドオフ制御メッセージまたは呼継続トランザクションを、ハンドオフのシナリオに関与する任意のサーバから起動することができる。たとえば、ポイント・ツー・ポイントの呼がセットアップされていて、第１のパケット・サーバ（たとえば、第１のサービス中のＬＡＣ）と第２のパケット・サーバ（たとえば、アンカーＬＡＣ）とを経由してユーザとプライベート・ネットワークとの間で進行中である初期装置を仮定する。たとえば、ユーザが第１のパケット・サーバによってサービスされている領域から移動し、第３のパケット・サーバ（たとえば、第２のサービス中のＬＡＣ）によってサービスされる領域へ入った場合、本発明によるハンドオフ制御メッセージ・トランザクションが起動される。本発明によると、第２のサービス中のＬＡＣが呼継続トランザクションを起動することができ、あるいはアンカーＬＡＣが呼継続トランザクションを起動することができる。代わりに、本発明のもう１つの態様によれば、その呼継続トランザクションを実行するために、それらのパケット・サーバにそれぞれ関連付けられている区域サーバ（Ｒａｄｉｕｓサーバ）を採用することができる。

本発明のもう１つの態様においては、通信径路が第２のパケット・サーバ（たとえば、アンカーＬＡＣ）と第３のパケット・サーバ（たとえば、第２のサービス中のＬＡＣ）との間にまだ設立されていないと仮定して、通信径路（たとえば、トンネル）セットアップ制御メッセージ・トランザクションを呼継続トランザクションと同時並行的に実行することができる。

さらに、本発明のさらに他の態様においては、少なくとも１つのパケット・サーバ（たとえば、アンカーＬＡＣ）がそこからパケット・データを受信するパケット・サーバ（たとえば、第２のサービス中のＬＡＣおよびプライベート・ネットワーク）に関連付けられている状態変数を監視する。

参照し易いように、以下の詳細説明は３つのトピック・セクション、すなわち、マルチホップ・ポイント・ツー・ポイント・プロトコル、移動ポイント・ツー・ポイント・プロトコル、およびｍＬ２ＴＰに対するペイロード・メッセージの概要および混雑制御に分割されている。

＜マルチホップ・ポイント・ツー・ポイント・プロトコル＞
図１は本発明の原理による例示としての通信システム１００を示している。本発明の概念は別として、その構成要素はよく知られており、詳細には説明されない。たとえば、パーソナル・コンピュータ（ＰＣ）１１０はインターネットの接続を設立するためのＩＳＰ Ｂに対して公衆電話網（ＰＳＴＮ）を経由してダイアルアップ・アクセスのためのデータ通信機器（図示せず）を含んでいる。同様に、通信システム１００の構成要素間の実線はそれぞれの終端点間のよく知られている通信機能を表しており、たとえば、ＰＣ １１０とＰＳＴＮ １１０との間の接続はローカル・ループ接続の代表であり、ＩＳＰ Ｂとインターネット１２０との間の接続は同期光ネットワーク（ＳＯＮＥＴ）上での非同期転送モード（ＡＴＭ）によってサポートされている。さらに、読者は上記Ｌ２ＴＰプロトコルについてよく知っていると仮定される。

図１から観察できるように、通信システム１００は２つのＩＳＰ、すなわち、ＩＳＰ Ａネットワークによって表されるＩＳＰ Ａ、およびＩＳＰ Ｂネットワークによって表されるＩＳＰ Ｂを含む。ＩＳＰ Ｂネットワークはネットワーク・アクセス・サーバ（ＮＡＳ）１１５を含み、ＮＡＳ １１５はこの分野の技術において知られているような接続点（ＰＯＰ：ｐｏｉｎｔ−ｏｆ−ｐｒｅｓｅｎｃｅ）ルータ（図示せず）、ローカル・ネットワーク１２０、およびルータ１２５を含む。同様に、ＩＳＰ ＡネットワークはＮＡＳ １５５、ローカル・ネットワーク１６０、およびルータ１６５を含む。ＩＳＰ Ａはネットワーク・サーバ（ＮＳ）１３５を経由して例示としての企業ネットワークにアクセスするために、離れた場所にいる従業員に対してＶＰＮサービスを提供し、ＮＳ １３５は他の機能以外に特にルーティングおよびファイアウォールの機能を提供する。（その企業ネットワークは、たとえば、ＮＳ １３５の背後に適切に保護されているローカル・エリア・ネットワーク（図示せず）の集合であると仮定されている。

リモートのユーザは、たとえ一時的であってもＩＳＰ Ａによってサービスされず、代わりにＩＳＰ Ｂによってサービスされる領域の一部分にいる可能性があることを筆者らは観察している。したがって、本発明の原理によって、リモートのユーザにはそれぞれのホーム、またはアンカーのＩＳＰの他に訪問中のあるいはサービス中のＩＳＰを経由してＶＰＮにアクセスすることが許される。（ＩＳＰ ＡとＩＳＰ Ｂとは異なるサービス・プロバイダであることが仮定されているが、これは本発明の概念に対しては不要であり、たとえば、それらは単に同じＩＳＰの内部の別のネットワークであってもよい。）したがって、ＰＣ １０５の場所にいるユーザ（図示せず）は、たとえば、その領域の中を移動しながら、企業ネットワークにアクセスすることができる。

ここで、以下の定義が仮定される。
ｍＬ２ＴＰ−Ｋ．ハムゼー（Ｈａｍｚｅｈ）、Ｔ．コラール（Ｋｏｌａｒ）、Ｍ．リトルウッド（Ｌｉｔｔｌｅｗｏｏｄ）、Ｇ．サイン・ポール（Ｓｉｎｇｈ Ｐａｌｌ）、Ｊ．タールッド（Ｔａａｒｕｄ）、Ａ．Ｊ．ヴァレンシア（Ｖａｌｅｎｃｉａ）、Ｗ．ヴェルザイン（Ｖｅｒｔｈｅｉｎ）のＬａｙｅｒ ２ Ｔｕｎｎｅｌｉｎｇ Ｐｒｏｔｏｃｏｌ“Ｌ２ＴＰ”（レイヤー２のトンネリング・プロトコル）（Ｌ２ＴＰ）；Ｉｎｔｅｒｎｅｔ ｄｒａｆｔ，１９９８年３月、の中で定義されているＬ２ＴＰプロトコルに、ここで記述されているような変更を加えたもの
ＬＡＣ−ｍＬ２ＴＰのアクセス制御、すなわち、ｍＬ２ＴＰをサポートするＮＡＳ
ＬＮＳ−ｍＬ２ＴＰをサポートするＮＳ
アンカーＬＡＣ‐ＶＰＮサービスを提供するためにＬＮＳに対するトンネリングをサポートするＬＡＣ
サービス中のＬＡＣ−別のＬＡＣに対するトンネリングをサポートするＬＡＣ
これらの定義は本発明の概念の一例を単純に記述するために使われる。したがって、この技術分野の人であれば、本発明の概念はそれによって限定されるものではなく、任意のトンネリング・プロトコルおよびそれに関連付けられる処理装置に対して適用できることが分かるだろう。

本発明の概念によると、ＩＳＰ ＡネットワークはアンカーＬＡＣ １５５を示し、ＩＳＰ Ｂネットワークはサービス中のＬＡＣ １５５を示している。以下にさらに説明されるように、そして本発明の概念に従って、図１のシステム１００はマルチホップ・トンネルを提供する。図１の例は、２ホップのトンネルを示している。１つのホップは、ＩＳＰ ＢネットワークからＩＳＰ Ａネットワークへのホップであり、他のホップは、ＩＳＰ Ａネットワークから企業ネットワークへのホップである。

ここで図２を参照すると、本発明の概念による方法の例示としての高レベルのフローチャートを示している（サービス中のＬＡＣ １１５および他のそれぞれのサーバは以下に説明される方法を従来のプログラミング技法（ここでは説明されない）を使って実行するように適切にプログラムされていることが仮定されている）。ステップ２０５において、リモートのユーザはＰＳＴＮ １１０を経由してＩＳＰ Ｂに対するＰＰＰ（ポイント・ツー・ポイント・プロトコル）の接続を起動する。ステップ２１０において、サービス中のＬＡＣ １１５はそのユーザを部分的に認証し（たとえば、あらかじめ定義されている「ユーザ名」および「パスワード」を使って）、そしてその接続（図１の点線１によって表されている）を受け入れる。（代わりに、ＤＮＩＳ（ダイアル番号識別サービス）、ＣＬＩＤ（呼回線識別）または他の等価な形式の識別を使うことができる。）明らかに、サービス中のＬＡＣ １１５はユーザを認証することができず、その接続は受け付けられない（このステップは図には示されていない）。

背景として、そしてこの分野の技術で知られているように、リモートのユーザが新しいＰＰＰセッションを確立したい時、ＰＣ １１０はサービス中のＬＡＣに対してＰＰＰ ＬＣＰ（リンク制御プロトコル）のＣｏｎｆｉｇ Ｒｅｑｕｅｓｔを起動する。サービス中のＬＡＣは本発明の概念に従って、アンカーＬＡＣとの通信を開始する前に、そのユーザの機器によってこの分野の技術において知られているように、ＰＰＰ ＬＣＰおよびＰＰＰ ＰＡＰ／ＣＨＡＰのフェーズの両方を完了する（安全なコンジット（Ｃｏｎｄｕｉｔｓ）のために、ＩＥＴＦはＰＰＰの接続上でのセキュリティのために２つのプロトコル、すなわち、パスワード認証プロトコル（ＰＡＰ）およびチャレンジ・ハンドシェイク認証プロトコル（ＣＨＡＰ）（ＩＥＴＦのコメントに対する要求（ＲＦＣ）１３３４、「ＰＰＰ認証プロトコル」を参照されたい）を定義している。

ステップ２１５において、サービス中のＬＡＣ １１５はリモートのユーザがＶＰＮサービスを使いたいかどうかを判定する。この選択は、たとえば、特定の「ユーザ名」に直接に関連付けられるか、そして／またはサービス中のＬＡＣ １１５によって提供されるポップアップ「ハイパーテキスト・トランスポート・プロトコル」（ｈｔｔｐ）の形式によって、ユーザからの別の要求に関連付けられるようにすることができる。リモートのユーザが仮想ダイアルアップ・サービスを要求しなかった場合、サービス中のＬＡＣ １１５は標準のインターネット・アクセスをステップ２２０において提供する。しかし、リモートのユーザがＶＰＮを使いたかった場合、サービス中のＬＡＣ １１５はステップ２２５において関連付けられたアンカーＬＡＣとして識別する（下記）。

サービス中のＬＡＣ １１５は、たとえば、ユーザの識別を特定のアンカーＬＡＣと先験的に関連付けるＶＰＮテーブルを格納している。そのようなテーブルの一部分が下記の表１に示されている。この例においては、ＰＣ １１０に関連付けられているリモートのユーザがアンカーＬＡＣ ＩＳＰＡ．ｃｏｍ、すなわち、アンカーＬＡＣ １５５に関連付けられている。

等価な構造または操作が使えることに注意する必要がある。たとえば、「ｕｓｅｒｎａｍｅ＠ＩＳＰＡ．ｃｏｍ」のようなフォーマットのフィールドのリストを単純に維持することができる。ここで「＠」の記号の後の部分はアンカーＬＡＣを示す。代わりに、ＩＳＰ Ｂはユーザをサービスに対してマップしているデータベースを維持することができる。仮想ダイアルアップのケースにおいては、すなわち、リモートのユーザの識別がＶＰＮサービスに関連付けられている場合、そのマッピングはそのアンカーＬＡＣをさらに識別する。代わりに、サービス中のＬＡＣはこの分野の技術において知られているように、このタスクに対する自分のローカルＲａｄｉｕｓサーバによるＲａｄｉｕｓアクセス要求／応答のトランザクションを利用することができる。

ステップ２３０において、サービス中のＬＡＣ １１５は自分自身とアンカーＬＡＣ １５５との間にトンネルが存在するかどうかを知るためにチェックする。したがって、サービス中のＬＡＣ １１５は現在のトンネルについての以下の表２に示されているようなテーブルを維持する。この表はトンネル識別子（Ｔｉｄ）の値、そのトンネルを現在使っている呼の関連付けられた呼識別子（Ｃｉｄ）、および関連付けられているアンカーＬＡＣのＩＰアドレスによって表されている。

サービス中のＬＡＣとアンカーＬＡＣとの間にトンネル接続が現在存在しない場合、ステップ２３５においてアンカーＬＡＣに対して１つのトンネルがサービス中のＬＡＣ １１５によって起動される（下記）。サービス中のＬＡＣとアンカーＬＡＣとの間にトンネルが存在すると、サービス中のＬＡＣ １１５はステップ２４０において、新しいＣｉｄを割り当て、テーブル２を更新し、ローカル・ネットワーク１２０、ルータ１２５、インターネット１３０、ルータ１６５、およびローカル・ネットワーク１６０を経由してアンカーＬＡＣ １５５に対してＶＰＮ要求を転送することによって、アンカーＬＡＣ １５５との１つのセッションを起動する（以下にさらに説明される）。この要求の中でサービス中のＬＡＣ １１５はユーザの識別情報をアンカーＬＡＣ １５５へ伝える。

ここで図３を参照すると、アンカーＬＡＣ １５５はステップ３０５においてその要求を受け取る。ステップ３１０において、アンカーＬＡＣ １５５はそのリモートのユーザの認証も実行し（たとえば、上記のように所定の「ユーザ名」および「パスワード」を使って）、そしてその接続（図１の点線２によって表されている）を受け入れる。（代わりに、そのサービス中のＬＡＣと同様に、ＤＮＩＳ ＣＬＩＤ、または他の等価な識別の形式を使うことができる。）アンカーＬＡＣ １５５がそのユーザを認証することができない場合、その接続は受け付けられない（このステップは示されていない）。この場合、サービス中のＬＡＣ １１５はエラー・メッセージをそのリモートのユーザ（図示せず）に対して同様に送り返さなければならない。

アンカーＬＡＣ １５５は、たとえば、ユーザの識別情報を特定のＬＮＳと先験的に関係付けるＶＰＮテーブルを格納している。そのようなテーブルの一部分が下記の表３に示されている。この例においては、ＰＣ １１０に関連付けられているリモートのユーザが、ＩＰアドレスｇ．ｈ．ｉ．ｊ．によって表されているＬＮＳ １３５と関連付けられている。

サービス中のＬＡＣ １１５と同様に、等価な構造または操作を使うことができることに注意する必要がある。たとえば、アンカーＬＡＣはホームＲａｄｉｕｓサーバによってＲａｄｉｕｓのアクセス要求／応答メッセージ経由で、この機能を実行することもできる。ステップ３１５において、アンカーＬＡＣ １５５は表３を使って、これが有効なＶＰＮ要求であるかどうかをチェックする。これが有効な要求でなかった場合、アンカーＬＡＣ １５５はステップ３２０においてその要求を拒否する。これが有効な要求であった場合、アンカーＬＡＣ １５５はステップ３２５において、表３から関連付けられたＬＮＳを識別する。

アンカーＬＡＣはリモートのユーザとの確立された各ＶＰＮセッションに対して通信の各方向について以下の接続テーブルを維持すると仮定されている。

アンカーＬＡＣは各ＶＰＮセッションと１つの接続番号とを関係付ける。さらに、この接続番号はそれぞれのユーザに対してマップされている。このテーブルは接続番号によって、サービス中のＬＡＣのＩＰアドレス（そのホップに対する関連付け付けられたトンネルＩＤおよび呼ＩＤの値を伴う）、および関連付けられたＬＮＳのＩＰアドレス（その関連付けられたホップに対する関連付けられたトンネルＩＤおよび呼ＩＤの値を伴う）をリストする。ステップ３３０において、アンカーＬＡＣ １５５はＶＰＮセッションを確立する（認証のチェックなどを実行する）。（ふたたび、ＬＮＳ １３５はそのＶＰＮ要求を拒否する必要があり（たとえば、リモートのユーザの不認可または容量がないことのために）、適切なエラー・メッセージがアンカーＬＡＣおよびサービス中のＬＡＣによって発生される）。本発明の概念以外に、ＬＮＳ １３５によるＶＰＮのセッションが従来の技術におけるように確立される。たとえば、そして本発明の原理に従って、新しいＶＰＮセッションを確立する際、アンカーＬＡＣ １５５は新しいＣｉｄを割り当て、テーブル４を更新し、たとえば、新しい接続を追加する。この最後の接続が図１の点線３で表されている。

この点で、その接続性はポイント・ツー・ポイントのＰＰＰセッションであり、その端点は、一端においてはＰＣ １０５によって表されているような、そのリモートのユーザのネットワーキング・アプリケーションであり、そして他端においては情報の他のものにおけるＬＮＳ １３５のＰＰＰサポートへのこの接続性の終了である。必要な場合、ＬＮＳ以外に、サービス中のＬＡＣ、アンカーＬＡＣにおいてアカウンティングが実行できること、すなわち、各構成要素がパケット数、オクテット数および接続の開始および停止の時刻をカウントすることができることに留意されたい。

上記マルチホップ仮想ダイアルアップ・サービスのサポートにおいて、Ｌ２ＴＰ（ｍＬ２ＴＰ）プロトコルの一形式が使われ、以下にさらに説明される。Ｌ２ＴＰの場合のように、与えられたトンネル上で動作するｍＬ２ＴＰの２つの並列コンポーネント、すなわち、各ＬＡＣ−ＬＮＳペア間の制御メッセージおよび、同じＬＡＣ−ＬＮＳ間のペイロード・パケットがある。後者はＬＡＣ−ＬＮＳ間のユーザ・セッションに対してＬ２ＴＰのカプセル化されたＰＰＰパケットを転送するために使われる。Ｌ２ＴＰの場合のように、Ｎｒ（次の受信）およびＮｓ（次の送信）のフィールドは、制御メッセージの中に常に存在し、そしてペイロード・パケットの中にはオプション的に存在する。制御メッセージおよびペイロード・メッセージは異なるシーケンス番号状態を使用する。上記ＬＡＣ／ＬＮＳペアのシナリオの場合、（Ｎｒ、Ｎｓ）のメンテナンスおよび使用に関する限り、Ｌ２ＴＰのドラフト・プロトコルの定義に対する変更はない。

しかし、サービス中のＬＡＣとアンカーＬＡＣとの間の接続のように、サービス中のＬＡＣから送られた（Ｎｒ、Ｎｓ）の値を単に監視するだけである。すなわち、本発明の概念に従って、アンカーＬＡＣはサービス中のＬＡＣから受信された値をＬＮＳに対して単純に送信する。さらに、ここでアンカーＬＡＣはその（受信された状態、送信された状態）の値（Ｓｒ、Ｓｓ）を、サービス中のＬＡＣから送られたパケットから観察した対応している値（Ｎｒ、Ｎｓ）で更新する。サービス中のＬＡＣとアンカーＬＡＣとの間で、パケットの消失が間違いなくあるので、アンカーＬＡＣにおけるＳｓ（Ｓｒ）の値はサービス中のＬＡＣにおけるＳｓ（Ｓｒ）の値より小さい可能性がある。さらに、アンカーＬＡＣは二組の（Ｓｒ、Ｓｓ）の変数、すなわち、１つはサービス中のＬＡＣ／アンカーＬＡＣの制御接続に対するもの、そしてもう１つはアンカーＬＡＣ／ＬＮＳの制御接続に対するものを維持する。

ＰＰＰのトンネリングを発生させることができるより前に、本発明の概念に従って、サービス中のＬＡＣ、アンカーＬＡＣ、およびＬＮＳの間で、制御メッセージが交換されなければならない。制御メッセージはｍＬ２ＴＰの呼制御およびマネージメント情報が渡された時、ペイロード・データを転送するためにそれ以降で使われるのと同じトンネル上で交換される。

本発明の概念によると、追加の属性値ペア（ＡＶＰ）（下記）がＬ２ＴＰの制御メッセージの中で使うために定義される（したがって、ｍＬ２ＴＰ制御メッセージとなる）。これらの追加のＡＶＰは上記マルチホップの機能および呼転送機能をサポートするためのものである。Ｌ２ＴＰにおいて定義されているように、ＡＶＰは制御シグナリングをさらに規定するために使われる。

上で注記されたように、上記ＬＡＣ／ＬＮＳペアの場合、上記Ｌ２ＴＰの草案において記述されている手順には変更がない。したがって、マルチ・ホップのケースだけが下記の追加の手順を必要とする。

例示としてのマルチホップ・メッセージのフローが図４に示されている。図４から分かるように、トンネル（Ｔｉｄの値によって識別される）および呼（Ｃｉｄの値によって識別される）がサービス中のＬＡＣとアンカーＬＡＣとの間に確立される。同様に、トンネルおよび呼がアンカーＬＡＣとＬＮＳとの間に確立される。図４に示されているように、本発明の概念はサービス中のＬＡＣがアンカーＬＡＣに対するトンネルを確立することを要求する。本発明の場合においては、サービス中のＬＡＣはアンカーＬＡＣを１つのＬＮＳとして扱い、Ｌ２ＴＰの手順がそのトンネルを最初にセットアップするために使われる。

トンネルが確立されると、本発明の原理に従ってＰＰＰセッションをセットアップするためにいくつかの制御メッセージ・トランザクションが発生する。これらは図５−図７に示されている。これらの図において、各種の制御メッセージに対する関連のフィールドだけが示されている。サービス中のＬＡＣとアンカーＬＡＣとの間のトンネルに対するトンネルのｉｄおよび呼のｉｄが、アンカーＬＡＣとＬＮＳとの間のトンネルに対するそれらの値と異なっていた場合、アンカーＬＡＣはそれらをいずれかの方向に中継するより前に、そのパケット・ヘッダの中の関連のフィールドを修正する。

図５に示されているように、サービス中のＬＡＣは先ず最初にＳｔａｒｔ−Ｃｏｎｔｒｏｌ−Ｃｏｎｎｅｃｔ Ｒｅｑｕｅｓｔ Ｍｅｓｓａａｇｅ（ＳＣＣＲＱ）メッセージ（Ｌ２ＴＰの中で定義されているような）をアンカーＬＡＣに対して送信し、それらの間のトンネルを構成する。このメッセージを受信すると、アンカーＬＡＣはＳｔａｒｔ−Ｃｏｎｔｒｏｌ−Ｃｏｎｎｅｃｔ−Ｒｅｐｌｙ Ｍｅｓｓａｇｅ（ＳＣＣＲＰ）メッセージ（これは任意の上記認証に続いて発生する）で応答する。サービス中のＬＡＣはアンカーＬＡＣに対するＳｔａｒｔ−Ｃｏｎｔｒｏｌ−Ｃｏｎｎｅｃｔｉｏｎ‐Ｃｏｎｎｅｃｔ（ＳＣＣＣＮ）メッセージによって確認する。

図５に示されている制御接続開始メッセージの交換に続いて、サービス中のＬＡＣはＩｎｃｏｍｉｎｇ−Ｃａｌｌ−Ｒｅｑｕｅｓｔ（ＩＣＲＱ）メッセージを、図６に示されているようにアンカーＬＡＣに対して送信する。Ｉｎｃｏｍｉｎｇ−Ｃａｌｌ−ＲｅｑｕｅｓｔメッセージはアンカーＬＡＣがＬＮＳを識別することができるのに十分なユーザ・データおよび信用証明情報を含んでいる。

以前に注記されたように、アンカーＬＡＣとＬＮＳとの間にトンネルが存在しなかった場合、アンカーＬＡＣはＬ２ＴＰにおいて定義されているように、ＬＮＳとのＳＣＣＲ、ＳＣＣＲＰ、ＳＣＣＣＮメッセージの交換を先ず最初に開始する。トンネルが存在すると、そのトンネルの中の中の不使用の１つのスロット、１つのＣｉｄがアンカーＬＡＣによって割り当てられる。この点において、そして本発明の原理に従って、アンカーＬＡＣはこの新しいダイアルアップ・セッションのＬＮＳを通知するために、そのＩＣＲＱメッセージ（サービス中のＬＡＣからの）を中継する。図６に示されているように、アンカーＬＡＣはそれに従ってＩＣＲＱメッセージをＩＮＳに対して中継する前に修正する。その修正されたフィールドは「＊」、たとえば、割り当てられた呼のＩＤによって示される。また、アンカーＬＡＣは隠されたＡＶＰも追加して、どんな受信ウィンドウ・サイズをそれがサポートすることができるかをＬＮＳに知らせる（追加のホップで、アンカーＬＡＣは制御／ペイロードの接続の両方に対してネゴシエートされた最大のウィンドウ・サイズを記録することに留意されたい）。また、サービス中のＬＡＣとアンカーＬＡＣとの間の制御接続に対するウィンドウ・サイズはアンカーＬＡＣとＬＮＳとの間の制御接続のためのウィンドウ・サイズとは異なっている可能性があり、バッファリングが必要となる可能性がある。追加のバッファリングおよびシーケンス番号の監視をなくすために、アンカーＬＡＣはオプションとして１つのＡＶＰを追加してアンカーＬＡＣ‐サービス中のＬＡＣの方向において、アンカーＬＡＣがそのペイロード・セッションに対してどんなウィンドウ・サイズをサポートできるかをＬＮＳに対して知らせる。結果として、ＬＮＳはそのＩＣＲＰ応答における適切な受信ウィンドウ・サイズの値だけを含むことになり、したがって、ＬＮＳ−アンカーＬＡＣ−サービス中のＬＡＣの方向においてペイロード・セッションに対する１つのウィンドウ・サイズだけを含むことになる。

以前に注記されたように、ＬＮＳはその接続を受け入れるか、あるいはそれを拒否する。リジェクションは結果の状態を含まなければならず、そしてエラー指示を含むことができる。いずれの場合においても、図６に示されているように、ＬＮＳはＩｎｃｏｍｉｎｇ−Ｃａｌｌ−Ｒｅｐｌｙ（ＩＣＲＰ）メッセージをアンカーＬＡＣに対して送信する。次に、アンカーＬＡＣはそのＩＣＲＰメッセージを適当に修正し、それを本発明に従ってサービス中のＬＡＣに対して中継する（ふたたび、修正されたフィールドは図６において「＊」によって示されている）。ＬＮＳから受信されるパケット処理遅延（ＰＰＤ）フィールドは、ＬＮＳにおける処理遅延だけしか含んでいないので、アンカーＬＡＣは、この値に自分自身のノードにおける処理遅延を加算する。次に、ＩＣＲＱメッセージがサービス中のＬＡＣに対して中継される。

応答において、サービス中のＬＡＣは図７に示されているように、Ｉｎｃｏｍｉｎｇ−Ｃａｌｌ−Ｃｏｎｎｅｃｔｅｄ（ＩＣＣＮ）メッセージをアンカーＬＡＣに対して送信する。このメッセージの内部で、サービス中のＬＡＣはプロキシ認証情報以外に、すべてのＬＣＰ構成要求情報を渡す。すなわち、サービス中のＬＡＣはそのユーザの装置によって実行されたＬＣＰ Ｃｏｎｆｉｇ Ｒｅｑｕｅｓｔ／Ａｃｋ，ＰＰＰ ＰＡＰ／ＣＨＡＰの結果を転送している。アンカーＬＡＣはその受信されたＩＣＣＮメッセージのＰＰＰフィールドを変更した後、それをＬＮＳに対して中継する。現在、ｔｘ（送信）接続速度およびｒｘ（受信）接続速度は使われない。図には示されていはいないが、そして本発明に従って、アンカーＬＡＣはＬ２ＴＰにおいて定義されているすべてのＳｅｔ−Ｌｉｎｋ−Ｉｎｆｏ、ＨｅｌｌｏおよびＷａｎ−Ｅｒｒｏｒ−Ｎｏｔｉｆｙメッセージをも中継する。（上記はマルチホップのパケット・トンネルの概念を示していることに注意されたい。たとえば、図１は２ホップのパケット・トンネルを表している。）

上記マルチホップｍＬ２ＴＰトンネルはフレーム層においてのみ発生することに留意されたい。したがって、ＬＮＳによるアドレス管理の実際のポリシーは上記仮想ダイアルアップ・サービスには無関係である。というのは、ＰＰＰプロトコル処理のすべての目的に対して、リモートのユーザはそのＬＮＳに接続されているように見えるからである。

＜移動ポイント・ツー・ポイント・プロトコル＞
ここで図８を参照すると、本発明の概念の他の実施形態が示されている。図８は図１に似ている。本発明の概念は別として、その構成要素はよく知られており、詳細には説明されない。類似の番号は類似の機能を示し、必要な場合以外はさらには説明されない。

図８において、ＰＣ ８０５は個人通信サービス（ＰＣＳ）の無線ネットワーク８１０を通じてインターネットに対する無線アクセスを確立するためのデータ通信装置（図示せず）を含んでいる。ＰＣＳの無線サービスはこの分野の技術において知られており、したがって、詳細には説明されない。ＰＣＳの無線ネットワーク８１０は構成要素８１５および８２０によって表されている複数の移動交換センタを含む。各移動交換センタは１つの地理的領域（図示せず）にサービスする。構成要素８１５および８２０は１つのＮＡＳ、たとえば、図１のサービス中のＬＡＣ １１５に似たサービス中のＬＡＣを含むと仮定されている。最初に、リモートのユーザが上記マルチホップ技法を使って企業ネットワークに対するＶＰＮセッションを確立すると仮定される。特に、リモートのユーザはこの初期接続が接続８１４および８１６を経由して構成要素８１５を通して回送されるような地理的領域の中にいる。無線ＰＣＳアプリケーションの場合において、最初のＰＰＰ接続は構成要素８１５とＰＣ ８０５との間にある。簡単のために交換機要素の一部として示されているが、ＮＡＳの機能は別の装置において実行されるようにすることもできる。同様に、ローカル・ネットワークおよびルータなどの他の構成要素は簡単のためにここでは示されていない。

Ｌ２ＴＰなどの無線環境のトンネリング・プロトコルにおいて、リモートのユーザが既存のＰＰＰ接続を１つの交換機要素から別の交換機要素へ変更することはできないことを知っている。たとえば、図８はリモートのユーザが構成要素８２０（したがって、異なるＮＡＳ）に対して、たとえば、動き回る（ｒｏａｍ）時、そのユーザの通信セッションはこの分野の技術において知られているように、構成要素８２０に対してハンドオフされるとしばらくの間仮定する。しかし、既存のＰＰＰ接続（したがって、そのＶＰＮセッション）はドロップされ、そして再確立されなければならない。というのは、注記されたように、既存のＰＰＰ接続を１つのＮＡＳから別のＮＡＳへ移すための能力がないからである。この場合において、図８の通信システムはこの問題を解決する。

したがって、そして本発明に従って、ＮＡＳまたはＬＡＣは既存のＮＡＳが既存のＰＰＰ接続を別のＮＡＳに対してハンドオフすることができる「ハンドオフ」機能を組み込んでいる。この機能に従って、３つの新しい制御メッセージ、すなわち、（ｉ）Ｃｏｎｔｉｎｕｅｄ Ｃａｌｌ Ｒｅｑｕｅｓｔ、（ii）Ｃｏｎｔｉｎｕｅｄ Ｃａｌｌ Ｒｅｐｌｙ、および（iii）Ｃｏｎｔｉｎｕｅｄ Ｃａｌｌ Ｃｏｎｎｅｃｔが定義されている。上記の結果として、ユーザは現在のＰＰＰ接続を終了してから新しいＰＰＰ接続を再確立する必要はない。これらの新しい３つの制御メッセージはＬ２ＴＰの制御メッセージ・ヘッダ、メッセージ識別子（たとえば、ｃｏｎｔｉｎｕｅｄ ｃａｌｌ ｒｅｑｕｅｓｔなど）およびフィールドの番号（下記）を含む。

本発明の概念に従って、例示としてのハンドオフ・メッセージ・フローが図９に示されている。図９から観察できるように、トンネル（Ｔｉｄの値によって識別される）および呼（Ｃｉｄの値によって識別される）が最初に構成要素８１５（サービス中のＬＡＣを含む）とアンカーＬＡＣとの間に確立される。同様に、１つのトンネルと１つの呼がアンカーＬＡＣとＬＮＳとの間に確立される。（この初期ＶＰＮセッションを確立するための方法については上で説明された。）図９に示されているように、本発明の概念によって、既存のサービス中のＬＡＣが既存のＰＰＰ接続を、構成要素８２０によって表されているような新しいサービス中のＬＡＣに対して移すことができる。

ここで図１０を参照されたい。この図は「ハンドオフ機能」を提供する際に使うための方法の例示としてのフローチャートである。注記されたように、ＶＰＮセッションがＰＣ ８０５と企業ネットワークとの間に構成要素８１５を経由して存在している。それはサービス中のＬＡＣおよびアンカーＬＡＣ １５５を含む。本発明の概念に従って、ＰＣＳ無線ネットワーク８１０は既存の呼状態変数に対して各無線呼に対するＰＰＰ接続の存在（またはその欠如）を示している追加の変数を加え、そしてＰＰＰ接続が存在していた場合、アンカーＬＡＣの識別情報、たとえば、そのアンカーＬＡＣのＩＰアドレスを含むＰＰＰ接続情報を含む。

図１０のステップ４０５において、ＰＣＳ無線ネットワーク８１０はハンドオフが必要であることを検出する。というのは、ＰＣ ８０５が構成要素８１５によってサービスされている地理的領域から別の地理的領域、たとえば、構成要素８２０（別のサービス中のＬＡＣを含む）によってサービスされている領域へ移動したからである。ステップ４１０において、ＰＣＳ無線システムは差し迫っているハンドオフの通知を構成要素８２０に提供する。（ハンドオフを検出して実行するために無線システムによって使われる方法（複数の場合もある）はこの分野の技術において知られており、そして本発明の概念とは無関係である。したがって、それらはここでは説明されず、図８のシグナリング径路８１１によって表されている。）ここで呼状態情報がＰＰＰセッションの指示子およびＰＰＰ呼情報を含んでいるので、新しいサービス中のＬＡＣ（構成要素８２０の）はステップ４１５においてアンカーＬＡＣを識別する。ステップ４２０において、新しいサービス中のＬＡＣ（構成要素８２０の）は自分自身とその識別されたアンカーＬＡＣ（ここではアンカーＬＡＣ １５５）との間に既存のトンネルがあるかどうかを知るためにチェックする。

トンネルが存在しなかった場合、新しいサービス中のＬＡＣは先ず最初にステップ４２５において（前に説明されたような）１つのトンネルを確立する。次に、そして本発明の概念に従って、その新しいサービス中のＬＡＣはステップ４３０においてＣｏｎｔｉｎｕｅｄ−Ｃａｌｌ−Ｒｅｑｕｅｓｔ（ＣＣＲＱ）メッセージをアンカーＬＡＣに対して送信する。このＣＣＲＱメッセージはその既存のＰＰＰ接続に関連付けられているユーザの名前、移行された（新しい）ＰＰＰセッションのために使われるべきＴｉｄおよびＣｉｄの値を含む。

ステップ４３５において、アンカーＬＡＣは受信されたＣＣＲＱメッセージからユーザの名前を復元し、そしてこの情報を使って前のサービス中のＬＡＣのＬＮＳおよびＩＰアドレスを、たとえば、上記の表４によって表されている接続テーブルから決定する（また、この復元された情報はそれぞれのユーザ・データグラム・プロトコル（ＵＤＰ）のポート番号も含む場合がある）。このステップにおいて、アンカーＬＡＣはＣａｌｌ−Ｄｉｓｃｏｎｎｅｃｔ−Ｎｏｔｉｆｙメッセージ（たとえば、Ｌ２ＴＰ参照）を前のサービス中のＬＡＣに対して送信し、そしてたとえば、上記の表４において、そのリモートのユーザに対するこのＰＰＰ接続に関連付けられている既存の呼変数、たとえば、前のトンネルｉｄおよび前の呼ｉｄをも識別する。他方、アンカーＬＡＣがそのＣｏｎｔｉｎｕｅｄ−Ｃａｌｌ−Ｒｅｑｕｅｓｔを拒否した場合、サービス中のＬＡＣは既存のＰＰＰセッションを破棄して、新しいＰＰＰセッションを起動することができるようにそのユーザに対して信号を送り返すか、あるいはそのＰＰＰセッションが単純にドロップされる（そのステップは図には示されていない）。

ステップ４４０において、アンカーＬＡＣは適切な受信ウィンドウ・サイズを伴うＣｏｎｔｉｎｕｅｄ−Ｃａｌｌ−Ｒｅｐｌｙ（ＣＣＲＰ）メッセージで応答する。ＣＣＲＰメッセージは現在のＮｒおよびＮｓの値に関する情報を含む。ステップ４４５において、アンカーＬＡＣは自分の接続テーブル、たとえば、上記の表４を、Ｔｉｄ、Ｃｉｄ、およびサービス中のＬＡＣのＩＰアドレスのフィールドに対するエントリー（ステップ４３５において識別された）を、その既存のＰＰＰ接続に対する新しい呼情報で置き換えることによって更新する。ステップ４５０において、新しいサービス中のＬＡＣはそのＮｒ、Ｎｓを自分のＳｒ、Ｓｓの値の中に格納し、そして必要であれば受信されたＣＣＲＰメッセージから受信ウィンドウ・サイズをも格納し、そしてＣｏｎｔｉｎｕｅｄ−Ｃａｌｌ−Ｃｏｎｎｅｃｔ（ＣＣＣＮ）メッセージをアンカーＬＡＣに対して送信し、これによってハンドオフが完了する。

ＰＰＰプロトコルに対する上記ハンドオフ機能のサポートにおいて、図１１は本発明の原理による上記の新しい制御メッセージのトランザクションを示している。図１１に示されているように、ＣＣＲＱメッセージが識別されたアンカーＬＡＣに対して送信される。

この実施形態においてはＣＣＲＱメッセージは以下のフィールドを含むことが好ましい。
‐割り当てられたＣｉｄ
‐呼のシリアル番号
‐ベアラ（ｂｅａｒｅｒ）のタイプ
‐物理的チャネルＩＤ
‐ダイアルされた番号
‐ダイアル中の番号
‐サブアドレス
‐アンカーＬＡＣ
‐チャレンジ
‐ユーザＡＶＰ
‐ユーザ名
‐ユーザのＭＩＮ／電話機
アンカーＬＡＣのフィールドは、この情報がハンドオフの間に利用できると仮定している。代わりに、ハンドオフのプロセスが新しいサービス中のＬＡＣに対してアンカーＬＡＣに関する情報を提供しなかった場合、そのハンドオフ・プロセスは、この分野の技術において知られているように、フォーリン（Ｆｏｒｅｉｇｎ）Ｒａｄｉｕｓサーバからのヘルプを使ってアンカーＬＡＣ情報をその新しいサービス中のＬＡＣがサーチできるように、その新しいサービス中のＬＡＣに対して十分なユーザ情報を提供しなければならない。すなわち、新しいサービス中のＬＡＣはＲａｄｉｕｓのアクセス／応答メッセージ経由でホームＲａｄｉｕｓサーバからアンカーＬＡＣに関して問い合わせる。

ユーザのＡＶＰ情報はユーザ情報（ユーザの名前など）および他のユーザ信用証明情報、たとえば、マルチホップの仮想ダイアルアップ・サービス、ユーザのアイデンティティ（ＭＩＮ）、サービス・プロバイダの電話番号などを含む。

ＣＣＲＱメッセージに続いて、アンカーＬＡＣはＣａｌｌ−Ｄｉｓｃｏｎｎｅｃｔ−Ｎｏｔｉｆｙメッセージを前のサービス中のＬＡＣに対して送信する。次に、アンカーＬＡＣは自分が維持している現在のＳｒ、Ｓｓを含むＣｏｎｔｉｎｕｅｄ−Ｃａｌｌ−Ｒｅｐｌｙ（ＣＣＲＰ）メッセージで応答する。

この実施形態においては、ＣＣＲＰメッセージは以下のフィールドを含むことが好ましい。
‐割り当てられたＣｉｄ
‐呼のシリアル番号
‐結果のコード
‐受信ウィンドウ・サイズ
‐ＰＰＤ
‐シーケンス番号ＡＶＰ；Ｎｒ、Ｎｓ
‐ＡＣＣＭ ＡＶＰ
‐最後に送信されたＬＣＰ Ｃｏｎｆｉｇ．Ｒｅｑｕｅｓｔ
‐最後に受信されたＬＣＰ Ｃｏｎｆｉｇ．Ｒｅｑｕｅｓｔ
‐チャレンジ
‐チャレンジの応答
最後に、新しいサービス中のＬＡＣはＣｏｎｔｉｎｕｅｄ‐Ｃａｌｌ Ｃｏｎｎｅｃｔ（ＣＣＣＮ）メッセージで応答する。この実施形態においては、ＣＣＣＮメッセージは以下のフィールドを含むことが好ましい。
‐接続速度
‐フレーミングのタイプ
‐変更されたウィンドウ・サイズ ＡＶＰ
‐ＰＰＤ
‐チャレンジ応答
本発明による制御メッセージ・トランザクションに関しての他の実施形態が図１９に示されている。そのような実施形態においては、ハンドオフ制御メッセージ（ＣＣＲＱ、ＣＣＲＰ、およびＣＣＣＮ）はトンネル・コンフィギュレーション（確立）制御メッセージ（ＳＣＣＲＱ、ＳＣＣＲＰ、およびＳＣＣＣＮ）と組み合わされていることが有利であり、そしてそれぞれ同時並行的にＬＡＣ間で送信されることが好ましい。このようにして、新しいサービス中のＬＡＣとアンカーＬＡＣとの間の移行の待ち時間が大幅に改善される。

この場合、既存のＰＰＰ接続またはセッションが既に、たとえば、ＰＣ ８０５、サービス中のＬＡＣ ８１５、アンカーＬＡＣ １５５およびＮＳ １３５（図８）の間で進行中であると仮定されている。次に、ユーザのモビリティに従って、ＰＣ８０５は別のサービス中のＬＡＣ、たとえば、サービス中のＬＡＣ ８２０のカバレージ領域の中に移動する。前に述べたように、従来の方法を使うことによってＰＰＰの接続がドロップされ、したがって、その呼を再確立する必要がある結果になる。しかし、本発明によると、その呼はユーザの見通しから中断されずに新しいサービス中のＬＡＣに対してハンドオフされる。前の実施形態においては、新しいサービス中のＬＡＣとアンカーＬＡＣとの間に既存のトンネルがないと仮定して、たとえば、図５に示されているようなトンネルを確立するためのプロセスが、たとえば、図１１に示されているようにハンドオフ・メッセージの交換に先立って実行されなければならない。しかし、図１９に示されている実施形態によると、トンネルの確立のプロセスおよびハンドオフのプロセスは同時並行的に実行される。有利なこととして、新しいサービス中のＬＡＣとアンカーＬＡＣとの間の通信に関連付けられる待ち時間が大幅に減少する。

したがって、トンネルの確立と呼のハンドオフを同時並行的に実行するためには、新しいサービス中のＬＡＣ（たとえば、図８の中の８２０）はＣＣＲＱメッセージにＳＣＣＲＱメッセージを付加した後、そのＣＣＲＱメッセージをアンカーＬＡＣへ送信する。次に、上記のように、アンカーＬＡＣはそのユーザの情報を使って前のＴｉｄ値、前のＣｉｄ値、および前のＩＰ／ＵＤＰポートを決定し、そしてＣａｌｌ−Ｄｉｓｃｏｎｎｅｃｔ−Ｎｏｔｉｆｙ（ＣＤＮ）メッセージを前のサービス中のＬＡＣに対して送信する。次に、アンカーＬＡＣは新しいサービス中のＬＡＣに対して、ＣＣＲＰメッセージに付加されたＳＣＣＲＰメッセージで応答する。新しいサービス中のＬＡＣはその組み合わされたＣＣＣＮとＳＣＣＣＮのメッセージをアンカーＬＡＣに対して送信する。トンネル確立制御メッセージがハンドオフ制御メッセージに対して付加されるが、その中に含まれている個々の機能および情報は上で詳細に説明されたように、不変のままに残っていることを理解されたい。

また、図１９はハンドオフ制御メッセージを含んでいるようなある種のフィールドを示しているが、そのようなメッセージは図１１に示されているメッセージの中にあるのと同じか、あるいは類似のフィールドを含んでいる可能性がある。さらに、図１９、図２０および図２１の場合において、ＣＣＲＱ、ＣＣＲＰ、およびＣＣＣＮに関して示されているどのフィールドも、図１１の同じメッセージの中に存在する可能性があること、およびその逆も言えることを理解されたい。また、これらの実施形態は、説明的な性質のものであるので、ここに記述されているメッセージのどれもが必ずしも示されているフィールドに限定されるものではない。

「ＡＶＰ」という用語はＰＰＰの動作において知られているようにＡｔｔｒｉｂｕｔｅ Ｖａｌｕｅ Ｐａｉｒ（属性値ペア）を指すことを理解されたい。そのようなＡＶＰは特に、受信者の装置に関連の情報を提供するメッセージの特定のフィールドの中に含まれている情報である。たとえば、ウィンドウ・サイズのＡＶＰおよび修正されたウィンドウ・サイズのＡＶＰは、それぞれ受信者に対して送信者のウィンドウの容量およびそのウィンドウ・サイズを修正するための通知を示すフィールドである。また、ＡＣＣＭのＡＶＰは非同期制御文字のマップのＡＶＰを指す。これは００（ｈｅｘ）からｉＦ（ｈｅｘ）までの範囲内の３２個のＡＳＣＩＩ制御文字に対する文字のエスケープをイネーブル／ディスエーブルする４オクテットのビット・マップである。さらに、シーケンス番号のＡＶＰはサーバ間で状態変数ＮｒおよびＮｓを送信するために使われるフィールドである。またさらに、「Ｌａｓｔ Ｓｅｎｔ ＬＣＰ（Ｌｉｎｋ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）Ｃｏｎｆｉｇ．Ｒｅｑｕｅｓｔ」および「Ｌａｓｔ Ｒｃｖ ＬＣＰ（Ｌｉｎｋ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）Ｃｏｎｆｉｇ．Ｒｅｑｕｅｓｔ」はこの分野の技術において知られているように、ＰＰＰセッションのセットアップに関連付けられたＬＣＰフェーズの間にサーバ間でネゴシエートされるＬＣＰオプションである。

ここで図２０を参照すると、ハンドオフ制御メッセージのトランザクションを実行するためのさらに他の実施形態が示されている。そのような実施形態においては、新しいサービス中のＬＡＣではなく、アンカーＬＡＣが新しいサービス中のＬＡＣとのハンドオフ制御メッセージ・トランザクションを有利に開始することを理解されたい。すなわち、図８および図９に示されている装置に関して、ＰＣ ８０５がサービス中のＬＡＣ ８１５によってカバーされている領域からサービス中のＬＡＣ ８２０によってカバーされている領域へ移動したことの指示をＰＣＳ ８１０から（無線リンク層を経由して）受信すると、新しいサービス中のＬＡＣ ８２０がそのハンドオフ制御メッセージ・トランザクションを起動するのではなく、アンカーＬＡＣがそのトランザクションを起動する。したがって、図２０に示されているように、アンカーＬＡＣはＣＣＲＱメッセージを新しいサービス中のＬＡＣに対して送信し、新しいサービス中のＬＡＣはＣＣＲＰメッセージを返し、そしてアンカーＬＡＣはＣＣＣＮメッセージで応答する。各メッセージの中に含まれている情報、およびその機能は前に説明されたものと類似していることを理解されたい。したがって、ここでは繰り返されない。しかし、図２０においてはアンカーＬＡＣがトランザクションを起動するので、アンカーＬＡＣによって送信される図２０のＣＣＲＱメッセージの中のフィールドは、アンカーＬＡＣによって送信される図１９の中のＣＣＲＰメッセージの中のフィールドと類似している。これはアンカーＬＡＣがこの情報を持っていて、誰がそのトランザクションを起動するかには無関係に、サービス中のＬＡＣに対してそれを送信するためである。

また、図１９に関して示されている実施形態の場合のように、トンネル確立制御メッセージ・トランザクションはアンカーＬＡＣによっても起動され、したがって、制御メッセージＳＣＣＲＱ、ＳＣＣＲＰ、およびＳＣＣＣＮはそれぞれハンドオフの制御メッセージＣＣＲＱ、ＣＣＲＰおよびＣＣＣＮとそれぞれ組み合わされて同時並行的に送信され得ることを理解されたい。

ここで図１２を参照すると、前のＮＡＳがＬＮＳに対する接続を備えている場合の、１つのＮＡＳから別のＮＡＳに対して既存のＰＰＰ接続を移すことの場合において、本発明の概念のもう１つの実施形態が示されている。この例においては、サービス中のＬＡＣそれ自体が存在せず、単純に、たとえば、既存のＰＰＰ接続を直接サポートしているアンカーＬＡＣがある。図１２は図８に似ている。本発明の概念は別として、その構成要素はよく知られており、詳細には説明されない。類似の番号は類似の機能を示し、必要な場合以外はさらには説明されない。

図１２において、ＰＣ ８０５は、個人通信サービス（ＰＣＳ）無線ネットワーク９１０を通じてインターネットに対する無線のアクセスを確立するためのデータ通信装置（図示せず）を含む。ＰＣＳの無線サービスはこの分野の技術において知られており、詳細には説明されない。ＰＣＳ無線ネットワーク９１０は構成要素８７５および８８８によって表されているような複数の移動交換センタを含む。各移動交換センタは１つの地理的領域（図示せず）にサービスする。構成要素８７５および８８０はＮＡＳ（たとえば、図１のアンカーＬＡＣ １１５と同様なＬＡＣ）を含むことが仮定されている。最初に、リモートのユーザがこの分野の技術において知られているように、たとえば、Ｌ２ＴＰのその部分を使って企業ネットワークに対するＶＰＮセッションを確立すると仮定されている。特に、リモートのユーザはこの初期接続が接続８７４および８７６を経由して構成要素８７５を通じてＬＮＳ ９３５へ回送されるような地理的領域の中にいる。無線ＰＣＳのアプリケーションの場合において、初期ＰＰＰ接続は構成要素８７５とＰＣ ８０５との間にある。簡単のために交換機要素の一部として示されているが、ＮＡＳの機能は別の装置の中で実行することもできる。同様に、簡単のためにローカル・ネットワークやルータなどの他の構成要素も示されていない。

この実施形態においては、上記ＣＣＲＱ、ＣＣＲＰ、ＣＣＣＮのメッセージが新しいＬＡＣとＬＮＳとの間で交換されること以外は、同じハンドオフの手順がＬＡＣ／ＬＮＳペアに対して実行される。本発明の概念に従って、例示としてのハンドオフのメッセージ・フローが図１３に示されている。図１３から観察されるように、トンネル（Ｔｉｄの値によって識別される）および呼（Ｃｉｄの値によって識別される）が、最初に構成要素８７５（１つのＬＡＣを含む）とＬＮＳ ９３５との間に確立される。図１３に示されているように、本発明の概念によって既存のＬＡＣが既存のＰＰＰ接続を、構成要素８８０によって表されているような新しいＬＡＣに対して移すことができる。

ここで図１４を参照されたい。図１４は「ハンドオフ機能」の提供において使うための方法の例示としてのフローチャートである。注記されたように、ＶＰＮセッションがＰＣ ８０５と企業ネットワークとの間に構成要素８７５（１つのＬＡＣを含む）を経由して存在していると仮定される。本発明の概念に従って、ＰＣＳ無線ネットワーク９１０は既存の呼状態変数に対して、各無線呼に対するＰＰＰ接続の存在（あるいはその欠如）を示している追加の変数を加え、そしてＰＰＰ接続が存在する場合、ＬＮＳの識別情報、たとえば、そのＬＮＳのＩＰアドレスを含むＰＰＰ接続の情報を加える。

図１４のステップ５０５において、ＰＣＳ無線ネットワーク９１０はハンドオフのための必要性を検出する。というのは、ＰＣ ８０５が構成要素８７５によってサービスされている地理的領域から別の地理的領域、たとえば、構成要素８８０（別のＬＡＣを含む）によってサービスされている領域へ移動したからである。ステップ５１０において、ＰＣＳ無線システムは構成要素８８０に対して差し迫っているハンドオフの通知を提供する。（ハンドオフを検出して実行するために無線システムによって使われる方法はこの技術分野において知られており、本発明の概念とは無関係である。したがって、それらはここでは説明されず、図１２のシグナリング径路９１１によって表されている。）呼状態の情報は、ここではＰＰＰセッションの指示子およびＰＰＰ呼情報を含むので、新しいＬＡＣ（構成要素８８０の）はステップ５１５においてそのＬＮＳを識別する。ステップ５２０において、新しいＬＡＣ（構成要素８８０の）は自分自身とその識別されたＬＮＳ（ここではＬＮＳ ９３５）との間に既存のトンネルが存在するかどうかをチェックして調べる。

トンネルが存在していなかった場合、新しいＬＡＣは先ず最初にステップ５２５において、１つのトンネルを確立する（前に説明されたように）。次に、本発明の概念に従って、新しいＬＡＣはＣｏｎｔｉｎｕｅｄ‐Ｃａｌｌ‐Ｒｅｑｕｅｓｔ（ＣＣＲＱ）メッセージをステップ５３０においてＬＮＳに対して送信する。このＣＣＲＯメッセージはその既存のＰＰＰ接続に関連付けられているユーザの名前、移行された（新しい）ＰＰＰセッションに対して使われるべきＴｉｄおよびＣｉｄの値を含む。

ステップ５３５において、ＬＮＳは受信されたＣＣＲＱメッセージからそのユーザの名前を復元し、そしてこの情報を使って前のＬＡＣのＩＰアドレスを決定する（この復元された情報はそれぞれのユーザ・データグラム・プロトコル（ＵＤＰ）のポート番号も含むことができる）。このステップにおいて、ＬＮＳはＣａｌｌ−Ｄｉｓｃｏｎｎｅｃｔ−Ｎｏｔｉｆｙメッセージ（たとえば、Ｌ２ＴＰ参照）を前のＬＡＣに対して送信し、そしてまた、上記の表４の中に示されているものと似ている接続テーブルの中で、しかし、サービス中のＬＡＣ情報などなしで、そのリモートのユーザに対するこのＰＰＰ接続に関連付けられている既存の呼変数、たとえば、前のトンネルＩＤ、および前の呼ＩＤを識別する。他方、ＬＮＳがＣｏｎｔｉｎｕｅｄ−Ｃａｌｌ−Ｒｅｑｕｅｓｔを拒否すべきである場合、新しいＬＡＣは既存のＰＰＰセッションを破棄することができ、そして新しいＰＰＰセッションを起動することができるようにユーザに対して信号を送り返すか、あるいはそのＰＰＰセッションは単純にドロップされる（そのステップは図には示されていない）。

ステップ５４０において、ＬＮＳは適切な受信ウィンドウ・サイズを伴うＣｏｎｔｉｎｕｅｄ−Ｃａｌｌ−Ｒｅｐｌｙ（ＣＣＲＰ）メッセージで応答する。そのＣＣＲＰメッセージは現在のＮｒおよびＮｓの値についての情報を含む。ステップ５４５において、ＬＮＳはＴｉｄ、Ｃｉｄ、およびＬＡＣ ＩＰアドレス・フィールド（ステップ５３５において識別された）を、その既存のＰＰＰ接続に対する新しい呼情報で置き換えることによって、その接続テーブルを更新する。ステップ５５０において、新しいＬＡＣは必要に応じて受信されたＣＣＲＰメッセージからＮｒ、Ｎｓ、および受信ウィンドウ・サイズを更新し、そしてＣｏｎｔｉｎｕｅｄ−Ｃａｌｌ−Ｃｏｎｎｅｃｔ（ＣＣＣＮ）メッセージをＬＮＳに対して送信し、それによってハンドオフが完了する。

ＰＰＰプロトコルに対する上記ハンドオフ機能のサポートにおいて、図１５は本発明の原理による上記の新しい制御メッセージ・トランザクションを示している。図１５に示されているように、ＣＣＲＱメッセージが識別されたＬＮＳに対して送信される。代わりに、ハンドオフのプロセスがＬＮＳに関する情報を新しいＬＡＣに対して提供しなかった場合、そのハンドオフ・プロセスは、この分野の技術において知られているように、フォーリンＲａｄｉｕｓサーバからの支援を使ってＬＮＳ情報を新しいＬＡＣがサーチできるように、新しいＬＡＣに対して十分なユーザ情報を提供しなければならない。すなわち、新しいＬＡＣはＲａｄｉｕｓのアクセス／応答メッセージを経由してホームＲａｄｉｕｓサーバからＬＮＳに関する情報を尋ね出す。ＣＣＲＱメッセージに続いて、ＬＮＳはＣｏｎｔｉｎｕｅｄ‐Ｄｉｓｃｏｎｎｅｃｔ−Ｎｏｔｉｆｙメッセージを前のＬＡＣに対して送信する。次に、ＬＮＳはＣｏｎｔｉｎｕｅｄ−Ｃａｌｌ−Ｒｅｐｌｙ（ＣＣＲＰ）メッセージで応答する。このメッセージはＬＮＳが維持している現在のＳｒ、Ｓｓの値を含む。最後に、新しいＬＡＣはＣｏｎｔｉｎｕｅｄ‐Ｃａｌｌ Ｃｏｎｎｅｃｔ（ＣＣＣＮ）メッセージで応答する。

上記のように、ＰＰＰ接続が１つのＮＡＳから別のＮＡＳへ移される。新しく定義されたメッセージのサポートにおいて、追加の呼状態が以下の表５および６に示されているように、それぞれのＮＡＳに対して定義されている。

観察できるように、追加の、あるいは新しい、継続される呼に対する新しいＬＡＣ（またはＮＡＳ）に関連付けられたｍＬ２ＴＰに対する呼の状態は、ＣＣＲＰ応答の待機状態である。

ここで図２１を参照すると、ハンドオフの制御メッセージのトランザクションを実行するための、さらにもう１つの他の実施形態が示されている。そのような実施形態においては、新しいサービス中のＬＡＣではなく、ＬＮＳが新しいサービス中のＬＡＣとのハンドオフ制御メッセージ・トランザクションを起動することを理解されたい。すなわち、図１２および図１３へ示されている装置に関して、新しいサービス中のＬＡＣ ８８０がハンドオフ制御メッセージ・トランザクションを起動するのではなく、ＰＣ ８０５がサービス中のＬＡＣ ８７５によってカバーされている領域からサービス中のＬＡＣ ８８０によってカバーされている領域へ移動したことの指示を、ＬＮＳがＰＣＳ ９１０から（無線リンク層を経由して）受信した時、そのトランザクションを起動する。したがって、図２１に示されているように、ＬＮＳがＣＣＲＱメッセージを新しいサービス中のＬＡＣに対して送信し、新しいサービス中のＬＡＣはＣＣＲＰメッセージを返し、そしてＬＮＳがＣＣＣＮメッセージで応答する。各メッセージの中に含まれている情報およびその機能は前に説明されたものと同様であることが分かるはずであり、したがって、ここでは繰り返されない。また、図１９に関して示されている実施形態の場合ように、トンネル確立制御メッセージ・トランザクションはＬＮＳによって起動される可能性もあり、したがって、制御メッセージＳＳＣＲＱ、ＳＣＣＲＰ、およびＳＣＣＣＮはそれぞれハンドオフの制御メッセージＣＣＲＱ、ＣＣＲＰ、およびＣＣＣＮと組み合わされて、同時並行的に送信される可能性がある。

ここで図２２および図２３を参照すると、Ｒａｄｉｕｓサーバを採用することによって、本発明に従って、ハンドオフの制御メッセージ・トランザクションを実行するためのそれぞれの他の実施形態が示されている。特に、図２２は図８および図９に示されている装置に類似した装置を示し、一方、図２３は図１２および図１３に示されている装置に類似した装置を示している。前に述べられたように、Ｒａｄｉｕｓサーバは、この分野の技術において知られているように、通信機能を実行するために必要な特定の情報を識別および／または確認することを支援するために、通信径路の中で採用されている他のサーバ（たとえば、サービス中のＬＡＣアンカーＬＡＣ、ＬＮＳ）によって使われる可能性がある。たとえば、説明されたように、Ｒａｄｉｕｓサーバはサービス中のＬＡＣに対して動作できるように結合されており、特定のユーザを特定のアンカーＬＡＣと関連付けるデータベースを含むことができる。このようにして、サービス中のＬＡＣは自分のＲａｄｉｕｓサーバと相談してそのような情報を求める。同様に、アンカーＬＡＣはそれに対して動作可能なように結合されているＲａｄｉｕｓサーバ（ホーム）と相談して、ユーザおよびユーザが関連付けられているＮＡＳに関する同様な情報を知ることができる。

しかし、本発明によると、Ｒａｄｉｕｓサーバはそれらの間でのハンドオフの制御メッセージ・トランザクションを実行するためにも利用されるのが有利である可能性がある。すなわち、サービス中のＬＡＣとアンカーＬＡＣまたはサービス中のＬＡＣとＬＮＳがそのトランザクションを実行するのではなく、それに対して動作可能なように結合され、互いに結合されているそれぞれのＲａｄｉｕｓサーバがこれらの制御メッセージを転送するために使われる。そのような場合、サービス中のＬＡＣ、アンカーＬＡＣ、およびＬＮＳは単にこれらのメッセージによって生じた追加の処理を実行するだけである。

図２２はアンカーＬＡＣに関連して、前のサービス中のＬＡＣ ８１５から新しいサービス中のＬＡＣ ８２０への、ＰＰＰ接続のハンドオフの場合におけるそのような装置を示している。新しいサービス中のＬＡＣ８２０に関連付けられているＲａｄｉｕｓサーバ８２２は、アンカーＬＡＣに関連付けられているＲａｄｉｕｓサーバ８２４と通信する。したがって、本発明によると、ハンドオフの通知がＰＣＳ ８１０（図８）から受信されると、Ｒａｄｉｕｓサーバ８２２および８２４は制御メッセージ、ＣＣＲＱ、ＣＣＲＰ、およびＣＣＣＮをそれらの間で直接転送する。本発明によると、いずれのＲａｄｉｕｓサーバもその転送を起動することができる。

同様に、図２３はＬＮＳ ９３５に関して、前のサービス中のＬＡＣ ８７５から新しいサービス中のＬＡＣ ８８０への、ＰＰＰ接続のアプリケーションの場合におけるそのような装置を示している。新しいサービス中のＬＡＣ ８８０に関連付けられているＲａｄｉｕｓサーバ９２２が、ＬＮＳに関係付けられているＲａｄｉｕｓサーバ９２４と通信している。したがって、本発明によると、ハンドオフの通知がＰＣＳ ９１０（図１２）から受信されると、Ｒａｄｉｕｓサーバ９２２および９２４は制御メッセージ、ＣＣＲＱ、ＣＣＲＰ、およびＣＣＣＮをそれらの間で直接転送する。本発明によると、いずれのＲａｄｉｕｓサーバもその転送を起動することができる。

＜Ｌ２ＴＰに対するペイロード・メッセージの概要および混雑制御＞
ｍＬ２ＴＰに対するペイロード・メッセージに関して、サービス中のＬＡＣおよびＬＮＳはＬ２ＴＰの手順に従う。アンカーＬＡＣはそのペイロード・パケットに対するＴｉｄおよびＣｉｄをスワップする。また、アンカーＬＡＣはサービス中のＬＡＣから送られた（Ｎｒ、Ｎｓ）の値を監視する。（サービス中のＬＡＣとアンカーＬＡＣとの間でパケットの消失があり得るので、アンカーＬＡＣにおけるＳｒおよびＳｓの値は両方とも、サービス中のＬＡＣにおいて維持されているそれらの値の後に遅れる可能性があることが予期されることに注意されたい。）アンカーＬＡＣはいずれの方向においてもペイロード・パケットの（Ｎｒ、Ｎｓ）を変更しない。アンカーＬＡＣがそれ自身のＳｒ、Ｓｓの値を使うのは、アンカーＬＡＣが新しいサービス中のＬＡＣからＣｏｎｔｉｎｕｅｄ−Ｃａｌｌ−Ｒｅｑｕｅｓｔメッセージを受信した時だけである。

混雑制御に関して、ウィンドウ・サイズをいつ受信するか、Ｎｒ／Ｎｓをいつ受信するか、そしてＡＣＫをいつ送信するかについてのＬ２ＴＰの条件がｍＬ２ＴＰに適用される。さらに、ｍＬ２ＴＰはサービス中のＬＡＣおよびアンカーＬＡＣに対する以下の追加の条件も有する。

アンカーＬＡＣはサービス中のＬＡＣから送信された（Ｎｒ、Ｎｓ）の値を監視する必要がある。アンカーＬＡＣはサービス中のＬＡＣから受信したＣｏｎｔｉｎｕｅｄ−Ｃａｌｌ−Ｃｏｎｎｅｃｔメッセージに応答する時、自分が維持する（Ｓｒ、Ｓｓ）の値をＣｏｎｔｉｎｕｅｄ−Ｃａｌｌ−Ｒｅｐｌｙメッセージの中に含める必要がある。サービス中のＬＡＣとアンカーＬＡＣとの間のネットワークは消失の可能性が大きいので、アンカーＬＡＣによって維持されているＳｒの値がサービス中のＬＡＣの背後に遅れている可能性がある。

本発明のマルチホップ・ポイント・ツー・ポイント・プロトコルによって影響される、ｍＬ２ＴＰに関連付けられたペイロード処理規則について以下に詳細に説明される。前に説明されたように、マルチホップのシナリオの場合、アンカーＬＡＣがペイロード・パケットに対するＴｉｄおよびＣｉｄの値のスワッピングを実行する。さらに、アンカーＬＡＣはｎＬ２ＴＰのペイロード・パケットに対して四組の状態変数（ＳｒＳ 、ＳｓＳ 、ＳｒＬ 、ＳｓＬ ）を維持する。アンカーＬＡＣはサービス中のＬＡＣから送られた（Ｎｒ、Ｎｓ）の値を（ＳｒＳ 、ＳｓＳ ）の中に格納し、そしてＬＮＳからの（Ｎｒ、Ｎｓ）の値を（ＳｒＬ 、ＳｓＬ ）の中に格納する。

サービス中のＬＡＣとアンカーＬＡＣとの間でパケットの消失および／または遅延があり得るので、ＳｒＳ ＜ＳｒおよびＳｓＳ ＜Ｓｓであることが予期される。ここでＳｒおよびＳｓはサービス中のＬＡＣにおいて維持されている状態変数である。同様に、パケットの消失および／または遅延がアンカーＬＡＣとＬＮＳとの間にもあるので、ＳｒＬ ＜ＳｒそしてＳｓＬ ＜Ｓｓであることが予期される。ここで、ＳｒおよびＳｓはＬＮＳにおいて維持されている状態変数である。アンカーＬＡＣはいずれの方向においてもペイロード・パケットの（Ｎｒ、Ｎｓ）の値を変更しないことを理解されたい。本発明による状態変数の監視がどのように行われるかについての３つの例が以下に示される。

第１の監視の例は１ホップの装置から２ホップの装置へ通信のシナリオが変わる場合に関するものである。１ホップの装置は、たとえば、ＰＣ、アンカーＬＡＣおよびＬＮＳの間の通信リンクを含むことを理解されたい。２ホップの装置は、たとえば、ＰＣ、サービス中のＬＡＣ、アンカーＬＡＣ、およびＬＮＳの間の通信リンクを含む。アンカーＬＡＣが以前に１つのＰＰＰセッションに対して二組の状態変数を維持し、そしてＣＣＲＱメッセージを受け取った場合、アンカーＬＡＣは自分が１ホップのセッションから２ホップのセッションへ変わる必要があることを知る。アンカーＬＡＣは先ず最初に自分の現在の二組の状態変数（Ｓｒ、Ｓｓ）を使ってＣＣＲＰメッセージの中でＮｒ＝Ｓｒ、そしてＭｓ＝Ｓｓに設定する。次に、アンカーＬＡＣはその状態変数を四組に変更し、ＳｒＳ ＝Ｓｒ、ＳｓＳ ＝Ｓｓ、ＳｒＬ ＝ｘ、そしてＳｒＬ ＝ｘに設定する。アンカーＬＡＣがハンドオーバの後で第１のパケットをＬＮＳから受信した時、それはそのＳｓＬ およびＳｒＬ の変数を観察された（Ｎｒ、Ｎｓ）の値で更新する。たとえば、前のＬＡＣがＳｓ＝１３およびＳｒ＝６を有し、そしてＬＮＳがＳｓ＝７そしてＳｒ＝１０を有していると仮定する。現在はアンカーＬＡＣである前のＬＡＣがＣＣＲＰメッセージの中でＮｒ＝ＳｒそしてＮｓ＝Ｓｓに設定する。ハンドオーバの後、新しいサービス中のＬＡＣはＳｓ＝１３そしてＳｒ＝６を有し、ＬＮＳはＳｓ＝７＋そしてＳｒ＝１０＋を有し、そしてアンカーＬＡＣ（前のＬＡＣ）はＳｓＳ＝１３、ＳｒＳ ＝６、ＳｓＬ ＝７＋、そしてＳｒＬ ＝１０＋を有する。ある種の値におけるプラスの記号（＋）はハンドオフのプロセスの間にシーケンス番号が更新されているかどうかに依存して、その値が大きくなり得ることを意味する。

第２の監視の例は通信のシナリオが２ホップの装置から１ホップの装置へ変わる場合に関する例である。ふたたび、１ホップの装置は、たとえば、ＰＣ、アンカーＬＡＣ、およびＬＮＳの間の通信リンクを含み、一方、２ホップの装置は、たとえば、ＰＣ、サービス中のＬＡＣ、アンカーＬＡＣ、およびＬＮＳの間の通信リンクを含むことを理解されたい。２ホップのＰＰＰセッションが１ホップのセッションに変えられること（たとえば、ｍＬ２ＴＰのＣＣＲＱメッセージではなく、リンク層のハンドオーバ・メッセージを受信して）の指示を受信した場合、アンカーＬＡＣは四組の状態変数を二組の状態変数に変換し、Ｓｓ＝ＳｓＳ 、そしてＳｒ＝ＳｓＬ に設定する。たとえば、新しいサービス中のＬＡＣがＳｓ＝１３、そしてＳｒ＝５を有し、ＬＮＳがＳｓ＝７、そしてＳｒ＝１０を有し、そしてアンカーＬＡＣがＳｓＳ ＝１２、ＳｒＳ ＝４、ＳｓＬ ＝６、そしてＳｒＬ ＝９を有していると仮定する。その時、２ホップの装置から１ホップの装置への変換後、アンカーＬＡＣはＳｓ＝１２、そしてＳｒ＝６を有し、そしてＬＮＳはＳｓ＝７＋、そしてＳｒ＝１０＋を有する。

第３の監視例は通信のシナリオが、たとえば、図９に示されているように、２ホップの装置から別の２ホップの装置へ変わる場合に関する例である。アンカーＬＡＣがＣＣＲＱメッセージを受信し、そしてＰＰＰセッションが既に２ホップであった場合、アンカーＬＡＣはサービス中のＬＡＣの変化があることを知る。その時、アンカーＬＡＣはＣＣＲＰメッセージの中でＮｒ＝ＳｓＬ およびＮｓ＝ＳｓＳ に設定する。また、アンカーＬＡＣはＳｒＳ をＳｒＳ ＝ＳｓＬ に更新する。たとえば、前のサービス中のＬＡＣがＳｓ＝１８、そしてＳｒ＝５を有し、ＬＮＳがＳｓ＝７、そしてＳｒ＝１０を有し、そしてアンカーＬＡＣＬＡＣがＳｓ＝１２、ＳｒＳ ＝４、ＳｓＬ ＝６、そしてＳｒＬ ＝９を有していると仮定する。その時、アンカーＬＡＣは新しいサービス中のＬＡＣに対して送られるＣＣＲＰメッセージの中で、Ｎｓ＝ＳｓＳ 、そしてＮｒ＝ＳｓＬ に設定する。そのハンドオーバの後、新しいサービス中のＬＡＣはＳｓ＝１２、そしてＳｒ＝６を有し、ＬＮＳはＳｓ＝７＋、そしてＳｒ＝１０＋を有し、そしてアンカーＬＡＣはＳｓＳ＝１２、ＳｒＳ ＝４、ＳｓＬ ＝６＋、そしてＳｒＬ ＝９＋を有する。

さらに、サービス中のＬＡＣはこの分野の技術において呼ばれているように、単純な受信機ではなく、完全な受信機を実装している。この条件は新しいサービス中のＬＡＣがＰＰＰセッションの寿命期間の間にサービス中のＬＡＣの変化があった時に上部層に対してシーケンスから外れた、あるいは複製のパケットを渡すことを禁止する。

図１６を簡単に参照すると、代表的なＮＡＳの高レベルのブロック図が示されている。ＮＡＳはストアード・プログラムの制御ベースのプロセッサ・アーキテクチャであり、プロセッサ６５０、プログラム命令およびデータを格納するためのメモリ６６０（たとえば、上記接続テーブルなど）および径路６６６によって表されているような１つまたはそれ以上の通信施設に対して結合するための通信インターフェース６６５を含む。

上記は本発明の原理を単に示しているだけであり、そしてこの分野の技術に熟達した人であれば、ここには明示的には記述されていないが、本発明の原理を具体化し、そしてその精神および範囲内にある数多くの代替装置を工夫することができることを理解されたい。たとえば、本発明の概念は入接続呼に対するマルチホップ・トンネルの確立を、サービス中のＮＡＳが起動する場合において記述されたが、本発明の概念は、たとえば、出接続呼に対してマルチホップ・シーケンスの確立を、ＬＮＳが起動するように等しく適用できる。そのような変更は直接的であり、図１７−図１８によってここで例示されているように、説明されない。

本発明の原理による通信システムを示す図である。 図１の通信システムにおいて使うための例示としての方法のフローチャートを示す図である。 図１の通信システムにおいて使うための例示としての方法のフローチャートを示す図である。 例示としてのマルチホップ・メッセージ・フローを示す図である。 例示としての制御メッセージ・トランザクションを示す図である。 例示としての制御メッセージ・トランザクションを示す図である。 例示としての制御メッセージ・トランザクションを示す図である。 本発明の原理による通信システムのもう１つの実施形態を示す図である。 例示としてのハンドオフ・メッセージ・フローを示す図である。 図８の通信システムにおいて使うための例示としての方法のフローチャートを示す図である。 例示としての制御メッセージ・トランザクションを示す図である。 本発明の原理による通信システムの他の実施形態を示す図である。 例示としてのハンドオフ・メッセージ・フローを示す図である。 図１２の通信システムにおいて使うための例示としての方法のフローチャートを示す図である。 例示としての制御メッセージ・トランザクションを示す図である。 例示としてのネットワーク・アクセス・サーバの高レベルのブロック図を示す図である。 出接続呼に対する例示としての制御メッセージ・トランザクションを示す図である。 出接続呼に対する例示としての制御メッセージ・トランザクションを示す図である。 他の例示としての制御メッセージ・トランザクションを示す図である。 さらに他の例示としての制御メッセージ・トランザクションを示す図である。 さらに他の例示としての制御メッセージ・トランザクションを示す図である。 制御メッセージ・トランザクションを実行するためのＲａｄｉｕｓサーバを採用している実施形態を示す図である。 制御メッセージ・トランザクションを実行するためにＲａｄｉｕｓサーバを採用している他の実施形態を示す図である。

Claims (27)

1. ポイント−ツー−ポイントプロトコル接続と関連する既存の無線データ呼と関連するハンド−オフ通知に応答して、パケットサーバに対して、該既存の無線データ呼についての該パケットサーバとの通信経路をトンネルプロトコルに従って確立するための通信経路設定要求および継続呼要求を含むメッセージ信号を送信するよう構成されたパケット装置を含む装置。
2. 請求項１に記載の装置において、
   該パケット装置が、ネットワークアクセスサーバである装置。
3. 請求項１に記載の装置において、該パケット装置が、該パケットサーバから、該通信経路設定要求および継続呼要求に応答するメッセージ信号を受信するよう構成されている装置。
4. 請求項３に記載の装置において、
   該パケット装置が、該パケットサーバから受信されるメッセージ信号に応答する第２のメッセージ信号を、該パケットサーバに対して送信するよう構成されている装置。
5. 第１のパケットサーバとの既存のポイント−ツー−ポイント接続を第２のパケットサーバに転送させるよう構成され、該既存のポイント−ツー−ポイント接続と関連するハンドオフ通知に応答して該転送を開始するパケット装置であって、さらに該第１のパケットサーバと該パケット装置の間に確立されたトンネルを越えて前にパケットを搬送したソースからパケットを搬送するために該第２のパケットサーバに対してトンネルを確立するよう構成されたパケット装置を含む装置。
6. 請求項５に記載の装置において、
   該パケット装置が、該第２のパケットサーバから受信された信号法に応答するよう構成されている装置。
7. 請求項６７に記載の装置において、
   該パケット装置が、該第２のパケットサーバから受信された信号法を送信するよう構成されている装置。
8. 請求項５に記載の装置において、
   該パケットが、別のパケットに包含されている装置。
9. 請求項５に記載の装置において、
   該パケット装置が、該既存のポイント−ツー−ポイント接続についての該第２のパケットサーバとの通信経路を確立するための通信経路設定要求および継続呼要求を含むメッセージ信号を該第２のパケットサーバに対して送信するよう構成されている装置。
10. 第１の区域サーバと関連するパケット装置であって、ポイント−ツー−ポイントプロトコル接続の既存の無線データ呼と関連するハンドオフ通知に応答して、該第１の区域サーバに作動的に結合された第１のパケットサーバと第２の区域サーバに作動的に結合された第２のパケットサーバの間の通信経路をトンネルプロトコルに従って確立するための継続呼要求を含むメッセージ信号を、該第２の区域サーバと関連するパケット装置に対して送信するよう構成されたパケット装置を含む装置。
11. 請求項１０に記載の装置において、
    該第１の区域サーバと関連する該パケット装置が、該第２の区域サーバと関連する該パケット装置からの該継続呼要求に応答するメッセージ信号を受信するよう構成されている装置。
12. 請求項１１に記載の装置において、
    該第１の区域サーバと関連する該パケット装置が、該第２の区域サーバと関連する該パケット装置から受信された該メッセージ信号に応答する第２のメッセージ信号を、該第２の区域サーバと関連する該パケット装置に対して送信するよう構成されている装置。
13. パケットデータを転送するための装置であって、
    第１のパケットサーバとで確立される無線ポイント−ツー−ポイントプロトコル接続を維持し、ハンドオフ通知の受信に応答して第２のパケットサーバに対して継続接続要求を含むメッセージ信号を送信し、パケットサーバと該第１のパケットサーバの間の該ポイント−ツー−ポイントプロトコル接続が切り離されるべきであるという通知を含むメッセージ信号を該第１のパケットサーバに対して送信し、及び該第２のパケットサーバに対して該ポイント−ツー−ポイントプロトコル接続を転送するよう構成され、該サーバ間のポイント−ツー−ポイントプロトコル接続がトンネルプロトコルに従って確立されているパケットサーバを含む装置。
14. パケットデータを転送するための装置であって、
    第１のパケットサーバとで確立される無線ポイント−ツー−ポイントプロトコル接続を維持し、ハンドオフ通知の受信に応答して接続設定要求および継続接続要求を含むメッセージ信号を第２のパケットサーバから受信し、パケットサーバと該第１のパケットサーバの間の該ポイント−ツー−ポイントプロトコル接続が切り離されるべきであるという通知を含むメッセージ信号を該第１のパケットサーバに対して送信し、および該ポイント−ツー−ポイントプロトコル接続を該第２のパケットサーバに対して転送するよう構成され、該サーバ間のポイント−ツー−ポイントプロトコル接続がトンネルプロトコルに従って確立されているパケットサーバを含む装置。
15. パケットサーバにて用いる方法であって、
    第１のパケットサーバに対するポイント−ツー−ポイントプロトコル接続と関連する無線呼についてのハンドオフ通知を受信するステップと、
    第２のパケットサーバに対して、該第２のパケットサーバとの通信経路をトンネルプロトコルに従って確立するための通信経路設定要求および継続呼要求を含む、メッセージ信号を送信するステップと、
    該ワイヤレス呼が脱落しないように該第２のパケットサーバに対してパケットを引き続いて送信することによって該ワイヤレス呼についての該ハンドオフを完了するステップとを含む方法。
16. 請求項１５に記載の方法において、さらに
    該通信経路設定要求および該継続呼要求に応答するメッセージ信号を、該第２のパケットサーバから受信するステップを含む方法。
17. 請求項１６に記載の方法において、さらに
    該第２のパケットサーバから受信されるメッセージ信号に応答する第２のメッセージ信号を該第２のパケットサーバに対して送信するステップを含む方法。
18. パケットサーバにて用いる方法であって、
    第１のパケットサーバへポイント−ツー−ポイントプロトコル接続と関連する無線呼を確立して該第１のパケットサーバとパケットを通信するためのステップと、
    該呼と関連するハンド−オフ通知信号に応答して、第２のパケットサーバに対して継続呼要求信号を送信するステップと、
    パケットが該第２のパケットサーバと今すぐに通信されるように、該呼を該第２のパケットサーバに対して転送するステップとを含むみ、
    サーバ間の通信がトンネルプロトコルに従って確立されている方法。
19. 請求項１８に記載の方法において、さらに
    該継続呼要求信号に応答するメッセージ信号を該第２のパケットサーバから受信するステップを含む方法。
20. 請求項１９に記載の方法において、さらに
    該第２のパケットサーバから受信されるメッセージ信号に応答する第２の信号を該第２のパケットサーバに対して送信するステップを含む方法。
21. パケットサーバにて用いる方法であって、
    第１のパケットサーバに対するポイント−ツー−ポイントプロトコル接続と関連する無線呼についてのハンド−オフ通知を受信するステップと、
    第２のパケットサーバとの通信経路をトンネルプロトコルに従って確立するための継続呼要求を含むメッセージ信号を送信するために、該パケットサーバに作動的に結合された地域サーバを該第２のパケットサーバに作動的に結合された区域サーバに方路づけるステップと、
    該ワイヤレス呼が脱落しないように該第２のパケットサーバに対してパケットを引き続き送信することによって該ワイヤレス呼についての該ハンド−オフを完了するステップとを含む方法。
22. パケットサーバにおいて用いる方法であって、
    第１のパケットサーバと第２のパケットサーバにてポイント−ツー−ポイントプロトコル接続を確立するステップと、
    該第１のパケットサーバと該第２のパケットサーバの間で伝送されるパケット・データと関連する状態変数を監視するステップと、
    ｎ個の状態変数セットであって、ｎ／２個の状態変数が該第１のパケットサーバと関連し、およびｎ／２個の状態変数が該第２のパケットサーバと関連しているようなｎ個の状態変数を記憶するステップとを含む方法。
23. 請求項２２に記載の方法において、
    該ポイント−ツー−ポイントプロトコル接続を確立するためにトンネルプロトコルが用いられる方法。
24. 装置であって、
    （ｉ）第１のパケットサーバおよび第２のパケットサーバとのポイント−ツー−ポイントプロトコル接続に関与し、（ｉｉ）該第１のパケットサーバと第２のパケットサーバの間で送信されるパケットデータと関連する状態変数を監視し、および（ｉｉｉ）ｎ／２個の状態変数が該第１のパケットサーバと関連し、ｎ／２個の状態変数が該第２のパケットサーバと関連しているようなｎ個の状態変数のセットを記憶する、よう構成されたパケット装置を含む装置。
25. 請求項２４に記載の装置において、
    該ポイント−ツー−ポイントプロトコル接続を確立するためにトンネルプロトコルが用いられる装置。
26. 請求項２４に記載の装置において、
    該第１のパケットサーバが、私的ネットワークである装置。
27. 請求項２４に記載の装置において、
    該第２のパケットサーバが、マルチ−ホップ通信経路がソースと該私的ネットワークの間に確立されるように該ソースに結合されている装置。
    

Images