JP4625081B2 - ネットワーク・アクセスのための早いリンク確立 - Google Patents

Description

特許に関する本出願は、米国特許仮出願番号第６０／５９２，４７０号、名称“早いパケット・データ・セッション確立のための方法及び装置（Method and Apparatus for Fast Packet Data Session Establishment）”、２００４年７月３０日出願、に優先権を主張し、本発明の譲受人に譲渡されそして本明細書中に引用によって特に取り込まれている。

本発明は、一般にパケット・データ通信に係り、そして特に、ネットワーク・アクセスのためにパケット・データ通信を確立する前の初期通信セッションに関する。

ネットワークを相互接続することは、情報が地理的な距離に無関係に迅速にアクセスされることをグローバルに可能にする。図１は、ネットワークのグローバルな接続の単純化した概要図を示し、インターネットとして一般的に呼ばれ参照番号２０によって表示される。インターネット２０は、本質において一緒にリンクされた異なるレベルの階層を有する複数のネットワークである。インターネット２０は、ＩＥＴＦ（Internet Engineering Task Force：インターネット技術タスク・フォース）によって公表されたＩＰ（Internet Protocol；インターネット・プロトコル）の下で管理される。ＩＰの詳細は、ＩＥＴＦによって発行されたＲＦＣ（Request for Comments：コメントの要請）７９１の中に見出されることができる。

インターネット２０に接続されたものは、各種のそれぞれのネットワークであり、ネットワークのサイズに応じてＬＡＮ（Local Area Network：ローカル・エリア・ネットワーク）又はＷＡＮ（Wide Area Network：広域ネットワーク）と時に呼ばれる。図１に示されたものは、複数のそのようなネットワーク２２，２４及び２６である。

各々のネットワーク２２，２４及び２６の内部に、互いに接続されそして通信している装置の種々の部品がある。例は、少しだけ名前を上げると、コンピュータ、プリンタ、及びサーバであり、それらは一般にノードと呼ばれる。ノードがインターネット２０を介して自分自身のネットワークを超えて通信する場合に、ＩＰアドレスがノードに対して指定される必要がある。ＩＰアドレスの指定は、手動で又は自動であり得る。ＩＰアドレスの手動の指定は、例えば、ネットワーク管理者によって実行されることができる。より頻繁に、ＩＰアドレスは、例えば、ＬＡＮ内の専用のサーバによって自動的に指定される。

説明のために一例を挙げる。ネットワーク２２内のノード３０がネットワーク２４内の別の１つのノード３４’にデータ・パケットを送ろうと試みと仮定する。ＩＰの下で、各データ・パケットは、ソース・アドレス及び宛て先アドレスを有することを必要とする。このケースでは、ソース・アドレスは、ネットワーク２２内のノード３０のアドレスである。宛て先アドレスは、ネットワーク２４内のノード３４’のアドレスである。

非常に頻繁に、ノードからノードへの通信は、インターネット２０のような、ネットワーク・アクセスの前に要求される。例えば、ネットワーク２２内のノード３０が、ラップトップ・コンピュータであると仮定する。ラップトップ・コンピュータ・ノード３０は、ネットワーク２２に直接アクセスを持たない。それにも拘らず、ラップトップ・コンピュータ・ノード３０は、例えば、電話回線を経由して有線モデムをダイアル呼び出しすることによるような、ある種の別の手段を介してネットワーク２２内のＮＡＳ（Network Access Server：ネットワーク・アクセス・サーバ）３２に連絡できる。そのケースでは、ノード３０は、一般的にネットワーク２２内のＮＡＳ（ネットワーク・アクセス・サーバ）３２とＰＰＰ（Point-to-Point Protocol：２点間プロトコル）セッションを確立する。ノード３０とネットワーク２２との間でその後に確立される又はインターネット２０を介していずれかの別のネットワークとの間でその後に確立されるパケット・データ通信は、有線モデム及び電話回線を経由して交換されることができる。もし、モデムが電話回線を経由して信号をシリアルにそして非同期的に伝送しそして受け取るのであれば、電話回線を介して交換されたデータ・パケットは、同様にフレーム化される必要があり、それに応じてシリアルなそして非同期的なモデム・リンクに適応する。

無線技術の到来は、ノードが最初に登録したネットワークから別の１つのネットワークに動いて離れることを可能にする。例えば、図１に戻って参照して、ネットワーク２２に恒久的に配線される代わりに、ノード３０は、ＰＤＡ（Personal Device Assistant：個人デバイス・アシスタント）、セルラ電話機、又は携帯型コンピュータのような、無線デバイスであり得る。無線ノード３０は、自身のホーム・ネットワーク２２の境界を越えて移動できる。したがって、ノード３０は、ホーム・ネットワーク２２から他のネットワーク２６に移動して離れることができる。ネットワーク２６のアクセスを得るために、又はインターネット２０を介して別のネットワークに接続されるようにするために、ノード３０は、同様に、ネットワーク２６内のＮＡＳ（ネットワーク・アクセス・サーバ）３３とＰＰＰセッションを一般的に確立する。このケースでは、ノード３０とＮＡＳ３３との間の通信は、無線リンクを経由する。再び、ノード３０と無線ネットワークとの間で交換されるデータ・パケットは、そのうえ、あるフォーマットに適するようにフレーム化される必要があり、そのフォーマットは、無線リンクを介してノード３０とＮＡＳ３３との間でＰＰＰセッションのあいだに取り決められる。

ＰＰＰの大部分は、ＩＥＴＦによって発行されたＲＦＣ１６６１及び１６６２に中に記載されている。ＰＰＰは、ピアー・トゥ・ピアー・プロトコルであり、その中では２つのノードはピアー（peer：同等）である。すなわち、いずれのパーティもクライアントでもないしサーバでもない。どちらのパーティも他のものからのアクションを要請できる又は他のものにアクションを実行できる。本質的に、ＰＰＰは、複数のノード間の予備的なそして取り決めを行うセッションであり、そのセッションの間に、そのノードは、いずれかのネットワーク・トラフィック・フローの前に、能力及び利用可能性に関して互いのリソースを見つけ出し、そして最終的に相互に受け入れることができるパラメータ・オプションのセットに対する適用範囲を見つけ出す。

図２は、具体例のＰＰＰ通信セッション３４のシーケンス・フロー図を示し、そこでは、ネットワーク２６内のノード３０がインターネット２０へのアクセスを得るためにＮＡＳ３２とのリンクを確立しようとしている。

ＰＰＰは、複数のプロトコル構成要素を有する。図２に示された具体例のＰＰＰセッションでは、ＰＰＰは、構成要素としてＬＣＰ（Link Control Protocol：リンク制御プロトコル）３６、ＣＨＡＰ（Challenge/Handshake Authentication Protocol：チャレンジ（呼び出し）／ハンドシェーク認証プロトコル）３８、及びＩＰＣＰ（Internet Protocol Configuration Protocol：インターネット・プロトコル設定プロトコル）４０を有する。

先ず、物理リンクの完了で、すなわち、ノード３０及びＮＡＳ３３は、ハードウェア・レベルで互いに連絡を取ることができる、例えば、ＬＣＰ３６を全部行う必要がある。ＬＣＰ３６は、ノード３０とＮＡＳ３３との間の基本的な通信リンクを確立する目的で機能する。ＬＣＰ３６の間に、ノード３０とＮＡＳ３３は、必須の通信パラメータ・オプションを互いに交換しそして取り決める。このオプションは、リンクを経由するデータ・パケットの最大サイズ、品質制御に関係するパラメータ、使用するＨＤＬＣ（High Level Data Link Control：高レベル・データ・リンク制御）ヘッダ・フィールド圧縮体系、及びピアーが認証されることを望んでいるかどうか、を含むことができる。

ＬＣＰ３６に関するプロセスは、ハンドシェークの方式の下で多かれ少なかれ実行される。最初に、要請するパーティは、Configure Request（設定要請）メッセージを送ることによって１又はそれより多くのパラメータを提案する。もし、いずれかのパラメータが受け取るパーティによって認識されなければ、受け取るパーティは、Configure Reject（設定拒絶）メッセージを応答して返す。もし、拒絶されたパラメータが得ようとしているリンクに対して致命的であれば、要請しているパーティは、その時は、ＰＰＰセッションを終了させなければならない。

一方で、もしパラメータが認識されるが、パラメータに関係するオプションが受け入れ可能でなければ、応答しているパーティは、Configure Nak（設定否定的受領通知）メッセージを送り返す。要請しているパーティは、再びＰＰＰセッションを終了させるか、又は同じパラメータに関する別のオプションを有する別の１つのConfigure Requestメッセージを送るかのどちらかをすることができる。

前に述べたように、ＰＰＰは、ピアー・トゥ・ピアー・プロトコルである。ノード３０又はＮＡＳ３３のどちらかは、要請しているパーティであり得る。同じことが応答しているパーティの役割についてもあてはまる。関係するオプションを有する全てのパラメータは、上記した様な方法で取り決められる必要がありそして決定される必要がある。取り決めの複数のラウンドが、図２に示されたように要求されることがある。全体の取り決め体系は、基本的に単純なプロセスである。もし、要請しているパーティが必要としているパラメータの全てが応答しているパーティにとって受け入れられる必要があれば、要請しているパーティは、応答しているパーティに最終的なConfigure Ack（設定受領通知）メッセージを送る。一旦、両方のパーティが、Configure Ackメッセージを送ると、それらは、認証段階に移行する。

パーティが認可されることを確実にするために、認証が実施される必要がある。認証を実行する１つの方法は、別のＰＰＰ構成要素ＣＨＡＰ３８を使用することである。ＣＨＡＰ３８を開始するＮＡＳ３３がノード３０の身元を検証することが、一般的である。ＣＨＡＰ３８の間に、ＮＡＳ３３は、チャレンジ・メッセージと呼ばれるメッセージをノード３０に送る。ＣＨＡＰの下で、チャレンジ・メッセージとともに使用される共有の秘密事項があり、それは事前に合意されたアルゴリズムを使用して応答メッセージを計算するために使用される。ノード３０は、その後、秘密アルゴリズムにより発生された応答メッセージをＮＡＳ３３に送る。ＮＡＳ３３は、その後で、ＮＡＳ３３自身により計算されたメッセージと受け取った応答メッセージを比較する。もし、比較が一致すれば、ノード３０は、ＣＨＡＰ３８を通過するといわれ、そこでは、ＮＡＳ３３は、ＣＨＡＰ Success（成功）メッセージをノード３０に送る。そうでなければ、ＣＨＡＰ Failure（失敗）メッセージがＮＡＳ３３によって送られる。

あるいは、ＣＨＡＰ３８の代わりに、認証は、ＰＡＰ（Password Authentication Protocol：パスワード認証プロトコル）を通ることによって実現されることができる。ＰＡＰでは、ノードは、検証のためにユーザネームとパスワードをＮＡＳ３３に単に送るだけである。もし検証されるのであれば、ノード３０はＰＡＰを通ったと言われる。

もしノード３０がＩＰアクセスを必要とするのであれば、ＩＰに関係する情報は、再び交換されそして取り決められる必要がある。例えば、他のものの中で、ノード３０は、ＩＰにしたがってインターネット２０（図１）をアクセスするためにＩＰアドレスの指定を受ける必要であり得る。この目的を達成するために、ＩＰＣＰ４０の下でパラメータ・オプションの取り決め及び交換を開始する。具体例のＰＰＰセッション３４では、ノード３０は、最初にＮＡＳ３３からＩＰアドレス０．０．０．０を要請する。応答では、ＮＡＳ３３は、Configure Nakメッセージを送り、ノード３０がＩＰアドレスａ．ｂ．ｃ．ｄを使用することを提案する。もし受理されるのであれば、ノード３０は、受領通知の代わりに別の１つのメッセージをＮＡＳ３３に送ることによってＩＰアドレスａ．ｂ．ｃ．ｄの使用を確認する。

最終的に、ノード３０がＩＰＣＰ４０の間に取り決められた全てのパラメータに同意する場合に、ノード３０は、受領通知メッセージをＮＡＳ３３に送る。ネットワーク・アクセス・セッションのユーザ・データは、その後で交換される。ネットワーク・トラフィックのＩＰデータ・パケットは、パラメータとともにＰＰＰフレームの中にカプセル化されそして前のＬＣＰ３６の間に取り決められる。

ネットワーク・アクセスの終わりに、ノード３０又はＮＡＳ３３のいずれかは、他のものにTerminate Request（終了要請）メッセージを送ることができる、それは、その後で、Terminate Ack（終了受領通知）メッセージを用いて応答して返されそして通信セッションを終わらせる。

図２に見られそして上に説明されたように、ＰＰＰセッション３４の間にノード３０とＮＡＳ３３との間で交換される非常に多くのメッセージがある。その意味で、かなりの時間の期間が含まれている。もしＰＰＰセッション３４が高データ遅延の遅いリンクを介して取り決められるのであれば、これは特に本質的である。

したがって、いずれかの次のレベルのデータ・トラフィックの前に初期通信リンクを確立するより早くそしてより効率的な方法を提供する必要性がある。
ＲＦＣ７９１、ＩＥＴＦ発行 ＲＦＣ１６６１、ＩＥＴＦ発行 ＲＦＣ１６６２、ＩＥＴＦ発行

［サマリー］
ネットワーク・アクセスを得ようとしているノードとＮＡＳ（Network Access Server）との間の通信セッションは、２，３のメッセージだけの交換を行うことによって確立される。最初に、ノードとＮＡＳとの間に物理リンクを設定するとともに、ＮＡＳは、すぐに認証要請メッセージをノードに送る。応答して、ノードは、認証応答に加えてリンク設定及びネットワーク・アクセス制御のための全ての他のパラメータ・オプションを含む要請メッセージを送る。ＮＡＳは、その後、多数のものの中からパラメータ・オプションのセットを取り出しそして選択する、そしてその後で、回答メッセージの中で選択されたオプションをノードに送り返す。もし回答メッセージ中で選択されたオプションがしきい値を満足するのであれば、ノードは、ＮＡＳを介してネットワーク・アクセスのためのユーザ・データを直接伝送する。

その上、フェール・オーバー・フィーチャ（fail-over feature）が、与えられることがあり、そこでは本発明の具体例の実施形態にしたがった通信セッションが確立され得ないのであれば、従来のＰＰＰ（２点間プロトコル）は、通信セッションを継続するために肩代わりできる。

本発明の１態様にしたがえば、開示されたものは、その中でノードがネットワーク・アクセスを得ようとしている方法、装置、及び媒体であり、メッセージ中に認証、リンク設定、及びネットワーク・アクセスのためのパラメータ・オプションのセットを与えるため、及びネットワーク・アクセス・ノードにメッセージを送るための工程又は手段を具備する。

本発明の別の１態様にしたがえば、開示されたものは、ネットワーク・アクセス・ノードのための別の１つの方法、装置、及び媒体であり、認証、リンク設定、及びネットワーク・アクセスのためのパラメータ・オプションのセットを含んでいるメッセージをネットワーク・アクセスを得ようとしているノードから受け取るため、及びパラメータ・オプションのセットの認可に関係する別の１つのメッセージをネットワーク・アクセスを得ようとしているノードに送るための工程又は手段を具備する。

これらの特徴及び他の特徴並びに利点は、添付した図面を考慮して以下の詳細な説明から当業者に明確になるであろう。図面では、類似の参照番号は、類似の部分を呼ぶ。

［詳細な説明］
以下の説明は、この技術に知識のあるいかなる者でも本発明を製作しそして使用することを可能にするために提示される。詳細は、説明の目的で以下の説明において述べられる。本発明がこれらの具体的な詳細を使用せずに実行され得ることを、当業者が理解するはずであることは、評価されるはずである。別の例では、周知の構造及びプロセスは、不必要な詳細で本発明の記載を不明瞭にしないために詳細に説明されない。それゆえ、本発明は、示された実施形態によって限定されるように意図されるのではなく、本明細書中に開示された原理及び特徴と整合する最も広い範囲に一致される。

図３は、本発明の具体例の実施形態に含まれるノードの単純化した概要図である。全体の通信システムは、参照番号４２によって示される。この実施形態では、通信システム４２は、バックボーン・ネットワーク５０に接続されたネットワーク４８を含み、バックボーン・ネットワーク５０はイントラネット又はインターネットであり得る。ネットワーク４８内に配置されたものは、ネットワーク・アクセスを得ようとしている任意のノードとネットワーク４８との間のゲートウェイとして機能するＮＡＳ（Network Access Server：ネットワーク・アクセス・サーバ）である。システム４２内で想定すると、バックボーン・ネットワーク５０を介してネットワーク４８又は他のネットワーク（図示されず）のいずれかについてのアクセスを探しているそのようなノード４４がある。ノード４４は、通信リンク４５を経由してＮＡＳ４６と通信する。

リンク４５は、様々な形式をとるリンクであり得る。例えば、リンク４５は、少しだけ名前をあげると、従来の電話線回路、同軸ケーブル・リンク、又は光ケーブル・リンクのような有線リンクであり得る。その上に、リンク４５は、同様に無線リンクであり得る。そのケースでは、リンク４５は、無線インターフェースである。

リンク４５が無線インターフェースであると、この実施形態では仮定する。ノード４４は、ＮＡＳ４６と無線で通信する移動デバイスである。ネットワーク４８は、無線技術、例えば、ＴＩＡ／ＥＩＡ（Telecommunications Industry Associations/Electronic Industries Associations：電気通信工業協会／電子工業協会）によって発表されたｃｄｍａ２０００規格、をサポートする。この事例ではＮＡＳ４６は、ＲＡＮ（Radio Access Network：無線アクセス・ネットワーク）と接続されたＰＤＳＮ（Packet Data Serving node：パケット・データ・サービング・ノード）であり、ＲＡＮは、無線リンク４５を経由してＲＦ（Radio Frequency：無線周波数）信号を介してノード４４と通信する。ＰＤＳＮ及びＲＡＮは、本技術では公知であり、そして明確化及び簡潔さの理由で図３には示されない。

通信システム４２の動作上の詳細を記述する前に、異なるレベルの階層を有する種々のタイプのプロトコル及びそれらの相互の関係を初めに説明することは、役に立つ。

ネットワーク通信の技術では、プロトコルは、ＩＳＯ（International Organization for Standardization：標準化国際機構）及びＩＴＵ−Ｔ（International Telecommunication Union-Telecommunications Standards Sector：国際電気通信組合−電気通信規格部門）によって発表されたような、ＯＳＩ（Open System Interconnection：相互接続開放システム）モデルにしたがって階層化される。その目的は、複数の会社の装置の相互運用性を容易にするためである。すなわち、プロトコル階層の各レベルは、それ自身の仕様を有する。その意味で、個々の階層レベルの仕様が満足される限り、そのレベルでの製品の開発は、他のレベルの別の製品と互換性があることが保証される。

図３のシステム４２がＩＰ（Internet Protocol：インターネット・プロトコル）をサポートすると仮定する。図４は、階層分類上の順番にプロトコルのスタックを示す概要図であり、一般に“プロトコル・スタック”と呼ばれ、そして参照番号５２によって一般的に表示される。ＩＰプロトコル・スタック５２は、ＩＥＴＦ（International Engineering Task Force：国際工学技術タスク・フォース）モデルにしたがって構造化される、それはＯＳＩモデルと類似するが、厳密には同じでない。ＩＥＴＦモデルにしたがって、ＩＰプロトコル・スタック５２は、レイヤ１から始まりレイヤ５までの、５つのレイヤを有する。それゆえ、図３のノード４４又は４６のようなノードによって送られるデータ・パケットは、プロトコル・スタック５２を経由して処理される必要がある。プロトコルのスタック５２は、ソフトウェアの形式又はハードウェアの形式で、若しくはこれらの組み合わせでノード内に構築される。同様に、同じノードによって受け取られたデータ・パケットは、逆の順序であるがプロトコル・スタック５２を経由して処理される必要がある。

説明のために一例をあげる。データ・パケットがノード４４又は４６（図３）のようなノードから送られるために処理されると仮定すると、データ・パケットは、アプリケーション・レイヤ、すなわち、レイヤ５、内のプロトコルのうちの１つにしたがって初めに生成される。レイヤ５は、ＨＴＴＰ（Hyper Text Transfer Protocol：ハイパー・テキスト変換プロトコル）、ＳＭＴＰ（Service Mail Transfer Protocol：サービス・メール変換プロトコル）、ＦＴＰ（File transfer Protocol：ファイル変換プロトコル）及びＲＴＰ（Real Time Transfer Protocol：リアル・タイム変換プロトコル）を含む。さらに、データ・パケットがＶｏＩＰ（Voice over Internet Protocol：インターネットを介した音声プロトコル）セッションの生成物（product）であると仮定する。データ・パケットは、そのようにレイヤ５内のＲＴＰにしたがってフォーマット化される必要がある。

レイヤ５内のＲＴＰプロトコルからの結果のデータ・パケットのような、時間に敏感なデータ・パケットは、リアル・タイムで処理される必要がある。具体的に、不完全なパケットは、通常再び送られないが、その代わりに別の新たなデータ・パケットの伝送を妨害しないように単純に落とされる。ＲＴＰデータ・パケットは、それゆえ通常レイヤ４、移動レイヤ（transport layer）、内のＵＤＰ（User Data packet Protocol：ユーザ・データ・パケット・プロトコル）を介して搬送される。したがって、レイヤ５内のＲＴＰからのデータ・パケットは、レイヤ４内のＵＤＰにしたがってさらに定式化される必要がある。

一方で、もし、データ・パケットがレイヤ５内のＦＴＰのような別のプロトコルから始まるのであれば、データ・パケットは、通常レイヤ４内のＴＣＰ（Transport Control Protocol：移動制御プロトコル）を介して送られる。ＴＣＰの下で、データ・パケットの正確な配信は、非常に重要なものである。それはそうとして、不完全なパケットは、全体のデータ伝送プロセスを遅くさせる可能性があるにも拘らず、常に再度送られる。

この移動レイヤ、レイヤ４、を通った後でデータ・パケットは、ソース・ポート番号及び宛て先ポート番号のような情報を加えられる。

移動レイヤ、レイヤ４、を通った後でデータ・パケットは、次の処理のためにネットワーク・レイヤ、レヤ３、に送られる。この特定のケースでは、レイヤ４からの結果としてのデータ・パケットは、ＩＰ、例えば、加えられたそのデータ・パケットのソース・アドレス及び宛て先アドレスにしたがって再度フォーマット化される必要がある。

簡潔さの理由のために、レイヤ３内にはＩＰだけが図４に示されている。ＩＰを補助する機能を実行する他のプロトコルもレイヤ３内に同様に存在する。一例は、ＩＣＭＰ（Internet Control Message Protocol：インターネット制御メッセージ・プロトコル）であり、それは配信できないデータ・パケットに対するエラー・メッセージを送る目的を機能する。

その後で、データ・パケットは、ネットワーク・インターフェース・レイヤ、レイヤ２、に適用可能であるどんなプロトコルであっても適応するようにフレーム化される必要がある。前に説明したＰＰＰ（Point-to-Point Protocol：２点間プロトコル）は、レイヤ２プロトコルに分類される。本発明の具体例の実施形態にしたがったネットワーク・アクセスに先立つ通信プロトコル・セッションは、同様にネットワーク・インターフェース・レイヤにも関係する。

図４のプロトコル・スタック５２の最も基底にあるレイヤは、物理レイヤ、レイヤ１であり、それはデータ・パケットに関する伝送の物理的な実行を取り扱う。例えば、もし通信リンク４５（図３）が従来の有線リンクであるならば、物理レイヤ、レイヤ１、は、リンク４５を形成する導電体配線を通り信号を駆動する２つのノード４４及び４６（図３）のハードウェア回路に関係する。もし通信リンク４５が無線インターフェースであるならば、物理レイヤ、レイヤ１、は、無線空間に関係しそしてその無線空間を介して信号を送受信する２つのノード４４及び４６（図３）のハードウェア回路に関係する。

ノード４４及び４６（図３）のようなノードによって受け取られたデータ・パケットに関して、データ・パケットは、逆の順番であるが同じプロトコル・スタック５２を通って、すなわち、レイヤ１からレイヤ５へ、処理される必要がある。

参照は、ここで図３に戻る。ノード４４がＮＡＳ４６を介してネットワーク・アクセスを得ようとしていると、この例では仮定する。メッセージのいずれかの交換の前に、物理リンク４５は、信号を搬送する準備ができている必要がある。別の言葉で言うと、ノード４４及び４５の物理レイヤ、レイヤ１は、物理的に存在し、そして確立されている必要がある。

この実施形態では、前に述べたように、通信リンク４５は、無線インターフェースであり、そしてネットワーク４８によってサポートされる無線技術は、ｃｄｍａ２０００である。物理レイヤは、ノード４４内の無線回路、及びＮＡＳ４６内部のＲＡＮに関係する。ＲＡＮは、少なくとも１つのＢＳＣ（Base Station Controller：基地局コントローラ）及び複数のＢＳ（Base Station：基地局）を含むことができる。ＲＡＮ、ＢＳＣ及びＢＳは、図３には示されていない。

この実施形態にしたがって、一旦物理レイヤ、レイヤ１が確立されると、すなわち、両方のノード４４及び４６が互いに相互の物理的存在を検出すると、ＮＡＳ４６は、すぐにノード４４に最初のメッセージを送る。

図５は、ノード４４とＮＡＳ４６との間のメッセージの通信シーケンスを示すフロー図である。全体のフロー・プロセスは、参照番号５４によって表示される。

最初のメッセージは、Sync（同期）メッセージと呼ばれ、参照番号５６によって示される。Syncメッセージ５６は、ノード４４がそこから選択するための全ての可能性のある認証オプションを含む。オプションは、ＣＨＡＰ（チャレンジ認証プロトコル）の下でのチャレンジ・メッセージ、及びＰＡＰ（パスワード認証プロトコル）によって要求されるパスワードの要請とユーザネームを含むことができる。ＣＨＡＰ及びＰＡＰの他に、Syncメッセージ５６内に、ＰＰＰで規定される又はサポートされる他の認証プロトコルが含まれるはずである。

Syncメッセージ５６を受け取ると、図５に示されたように、ノード４４は、Request （要請）メッセージ５８で応答する。

Requestメッセージ５８内では、ノード４４は、Syncメッセージ５６で述べられたような要請に応答して必要な認証情報を含む。その上に、ノード４４は、同様にＮＡＳ４６を介した引き続くネットワーク・アクセスのためにノード４４に対するリンクを確立するために必要な全てのパラメータ・オプションをRequestメッセージ５８内に含む。関係するオプションを有するパラメータがリンク設定に関係するか、認証に関係するか、又はネットワーク・アクセス制御に関係するかどうかは問題ではない。すなわち、ＰＰＰに関して前に説明したように、ＬＣＰ（リンク制御プロトコル）、ＣＨＡＰ（チャレンジ・ハンドシェーク認証プロトコル）及びＩＰＣＰ（Internet Protocol Control Protocol：インターネット・プロトコル制御プロトコル）のようなプロトコル構成要素の機能にしたがってパラメータを分類する代わりに、本実施形態のRequestメッセージ５８では、オプションを有する全てのパラメータは、機能に無関係に含まれる。より詳しくは、Requestメッセージ５８中のオプションを有するパラメータは、チャレンジ・メッセージへの応答、又はもし適用できるのであればユーザネーム及びパスワード、データグラム・サイズ及びＨＤＬＣ（高レベル・データ・リンク制御）ヘッダ・フィールド圧縮体系のようなリンク４５のリンク設定パラメータ、同様に、ＩＰアドレス、ＤＮＳ（Domain Name System：ドメイン名システム）設定、及びもし適用できるのであればＩＰヘッダ圧縮プロトコル、及び等々のようなネットワーク・アクセスのためのパラメータを含むことができる。

ＮＡＳ４６が両方のノード３０及び４６によってサポートされるオプションを選択することを可能にするために選択の点から意図的な冗長度を用いてRequestメッセージ５８が好ましくはフォーマット化される、それによって両方のノード４４及び４６が迅速に初期リンク確立の全体プロセスを終わらせることを可能にすることが、注目されるべきである。種々の選択のうちで、ＮＡＳ４６は、良好なリンクの機会を増加させる目的を明確にサポートする関係するオプションを有するパラメータを選択的に選択することができ、それによって設定時間を短縮する。別の言葉で言うと、Requestメッセージ５８は、本質的にノード４４によってサポートされる全ての利用可能なパラメータ・オプションを有する通知（advertisement）メッセージとして動作する。そこでは、ＮＡＳ４６によりオプションのサブセットを選択することが、リンク・プロセスの終了を可能にするはずである。

したがって、図５に示されたように、ＮＡＳ４６は、Requestメッセージ５８を受け取るとReply（回答）メッセージ６０で応答する。Replyメッセージ６０では、ＮＡＳ４６は、種々の選択肢の中からオプションを選択する。Replyメッセージ６０は、選択されたパラメータ・オプションをそれらに関係する設定値とともに含む。多くの場合、Replyメッセージ６０は、ノード４４によるネットワーク・トラフィックの開始の前に必要とされる最後のメッセージである。

前に説明されたピアー・トゥ・ピアーＰＰＰプロトコルのような他のプロトコル方法とは異なり、本実施形態にしたがって、肯定的受領通知又は否定的受領通知に対してどんな確認メッセージの必要性もない。それなりに、いずれかのメッセージに応答して、それはSyncメッセージ５６、Requestメッセージ５８、又はReplyメッセージ６０であっても、どちらのAck（肯定的受領通知）メッセージ又はNak（否定的受領通知）メッセージも、要求されない。いずれかの特定の要請された事項に応答がないことは、そのような事項が利用できない又はサポートされないことを意味する。

図５に戻って、Replyメッセージ６０を受け取ると、もしＮＡＳ４６によって選択されたオプションがある種のしきい値を満たすのであれば、例えば、ネットワーク・アクセスのための通信リンクをノード４４が確立することを全ての選択されたオプションが認めるのであれば、ノード４４は、ＮＡＳ４６にユーザ・データ６２を直接伝送することを実行する。再び、受領通知メッセージは、ノード４４によって送られない。

ネットワーク・アクセスの最後に、ノード４４又はＮＡＳ４６のどちらかは、相手にTerminate Request（終了要請）メッセージ６４を送ることができ、それはその後で、Terminate Acknowledge（終了受領通知）メッセージ６６で応答して戻され、そして通信セッションを終了する。

滅多に起きない場合では、ノード４４により得られようとしているネットワーク・アクセスのためのリンクを確立するためにＮＡＳ４６に対するRequestメッセージ５８中の設定オプションが不十分であることがあり得る。すなわち、Replyメッセージ６０でＮＡＳ４６によって選択されたオプションが、ネットワーク・アクセス・リンクを確立するためにノード４４にとって要求されるしきい値を満たすために不十分であることがあり得る。ＮＡＳ４６は、それにも拘らず受け入れられたオプションだけを用いてReplyメッセージ６０を送るが、受け入れられなかったオプションは無視される。再び、Nakメッセージは、必要ない。前に述べたように、Requestメッセージ５８中に含まれたがReplyメッセージ６０中で無視された提案済のオプションは、無視されたオプションに対するサポートの欠如を暗に示している。このケースでは、ＮＡＳ４６は、ネットワーク・トラフィックを確立できず、ノード４４が新たなRequestメッセージを送ることを待機する。

ノード４４に関して、もしそれがReplyメッセージ６０中でのサポートの欠如のために無視されたパラメータ・オプションにも拘らず、例えば、無視されたオプションが致命的でなければ、そのリンクを選ぶのであれば、ノード４４はネットワーク・トラフィックを伝送し始めることができる。一方で、もし無視されたパラメータがネットワーク・アクセス・リンクを確立するために絶対的に必要であるならば、例えば、ノード４４によって要請されたＩＰアドレスがReplyメッセージ６０中で無視されるのであれば、ネットワーク・トラフィックは、確立されることができず、そしてリンクはできなかったと言われる。

全体のプロセス５４は、同様に図６のフローチャートに示される。

本発明のリンク確立プロセスは、別のリンク・プロトコルへのフェール・オーバー・フィーチャを有するように同様に構成される。この実施形態では、もし、図５及び図６に示されたリンク・プロセス５４がどちらかのノード４４又はＮＡＳ４６（図３）でサポートされないのであれば、従来のＰＰＰは、ノード４４により求められている最終のネットワーク・アクセスに導くリンク・プロセスを続けるために代替プロトコルとして介入する。

本質において、２つの可能性があり、それぞれ以下に説明される。

第１のシナリオは、ノード４４がリンク・プロセス５４をサポートするが、ＮＡＳ４６がサポートしない場合に発生する。参照は、ここで図３と関連して図７に向けられる。図７は、このシナリオの下でのノード４４とＮＡＳ４６との間のメッセージの通信シーケンスを示すフロー図である。メッセージの全体のフローは、参照番号６８によって表示される。ノード４４がリンク・プロセス５４をサポートすると仮定するので、ノード４４と４６との間に物理レイヤ、レイヤ１、を設定すると、ノード４４はSyncメッセージ５６を待機する。しかしながら、ＮＡＳ４６がリンク・プロセス５４をサポートしないことが同様に仮定されるために、ＮＡＳ４６は、Syncメッセージ５６を送らない。その代わりに、ノード４４にＰＰＰの下でＬＣＰ Configuration Request（設定要請）メッセージ７０を送る。

ＬＣＰ Configuration Requestメッセージ７０を受け取ると、ノード４４は、ＮＡＳ４６がリンク・プロセス５４をサポートしないことを直ちに知り、そして従来のＰＰＰを介してＮＡＳ４６と通信するためのアクションを速やかに取る。具体的に、ＬＣＰ Configuration Requestメッセージ７０に応答して、ノード４４は、図７に示されたように、ＬＣＰ Configure Ack（設定受領通知）メッセージ７２を送る。あるいは、ノードは、もしConfiguration Requestメッセージ７０中に提案されたオプションが望ましくないのであれば、従来のＰＰＰと同様な方法でConfigure Nak（設定否定的受領通知）メッセージを送ることができる。

この実施形態では、受け取られたメッセージがＰＰＰメッセージであるか非ＰＰＰメッセージであるかどうかを、ノード４４又はノード４６のいずれかが、認識することに注目すべきである。後で説明されるように、この実施形態で使用されるデータ・フレーム・フォーマットは、ＰＰＰに対して使用されるものと同じであり、それによって迅速なメッセージ認識及び弁別を可能にする。

プロセスの残りは、図２に示されたプロセス３４と実質的に同じである。すなわち、良好に接続した後で、データ・トラフィック７４が、ノード４４とＮＡＳ４６との間に確立される。ネットワーク・アクセスの最後に、ノード４４又はＮＡＳ４６のどちらかが、相手にTerminate Request（終了要請）メッセージ７６を送ることができ、それはその後で、Terminate Acknowledge（終了受領通知）メッセージ７８で応答して戻し、そして通信セッション６８を終了する。

プロセス６８に対応するフローチャートは、図８に示される。従来のＰＰＰステップは、簡潔さの目的のために図８に示されない。

第２のシナリオは、ＮＡＳ４６がリンク・プロセス５４をサポートするが、ノード４４がサポートしない時に生じる。参照は、ここで図３と関連して図９に向けられる。図９は、このシナリオの下でのノード４４とＮＡＳ４６との間のメッセージの通信シーケンスを示すフロー図である。メッセージの全体のフローは、参照番号７０’によって表示される。ＮＡＳ４６がリンク・プロセス５４をサポートすると仮定するので、ノード４４と４６との間に物理レイヤ、レイヤ１、を確立すると、ＮＡＳ４６はSyncメッセージ５６をノード４４に直ぐに送る。ノード４４がリンク・プロセス５４をサポートしないことが同様に仮定されるために、Syncメッセージ５６を受け取ると、ノード４４は、Syncメッセージ５６を認識しない。上に述べられたようにそしてさらに以下に説明されるように、ノード４４は、ＰＰＰメッセージと非ＰＰＰメッセージとを区別できる。それゆえ、正当に認識されなかったSyncメッセージ５６で、ノード４４は、標準のＰＰＰ手順を使用して正当に認識されなかったSyncメッセージ５６を拒絶する。その代わりに、ノード４４は、ノード４４とＮＡＳ４６との間に物理リンクが確立されるとＬＣＰConfiguration Request（設定要請）メッセージ７２’を送る。

もし、ＮＡＳ４６がＬＣＰ Configuration Requestメッセージ７２’又はSyncメッセージ５６のＰＰＰ拒絶を受け取るのであれば、ＮＡＳ４６は、リンク・プロセス５４（図５及び図６）に関係する全てのフィーチャ（feature）をディスエーブルし、そして図２に示され前に説明されたように従来のＰＰＰプロセス３４を通る。

良好に接続した後で、データ・トラフィック７４は、ノード４４とＮＡＳ４６との間で交換されることができる。ネットワーク・アクセスの最後に、ノード４４又はＮＡＳ４６のどちらかが、相手にTerminate Request（終了要請）メッセージ７６を送ることができ、それはその後で、Terminate Acknowledge（終了受領通知）メッセージ７８で応答して戻し、そして通信セッション７０’を終了する。

図１０は、プロセス７０’に関する対応するフローチャートを示す。従来のＰＰＰステップは、簡潔さそして明確化のために図１０には示されない。

図１１は、フロー・プロセス５４（図５）において使用されるデータ・フレーム・フォーマットを示す。プロセス５４のデータ・パケットに対するフレーム・テンプレートは、参照番号８０によって表示される。本質において、テンプレート８０は、ＲＦＣ１６６２の下で述べられたようにＰＰＰによって使用される対応するデータ・パケット・テンプレートに類似する。特に、データ・フレーム８０は、フラッグ・フィールド８２、アドレス・フィールド８４、制御フィールド８６、プロトコル番号フィールド８８、データ・フィールド９０、及びＦＣＳ（Frame Check Sequence：フレーム検査系列）フィールド９２を含む。

フラッグ・フィールド８２は、１バイト長でありそしてデータ・パケット・フレームの開始を指示する。フラッグ・フィールド８２は、１６進値の７Ｅを常に仮定し、そしてＲＦＣ１６６２によって要求されるように、リンク・プロセス５４及びＰＰＰに対して使用される同じ値である。

アドレス・フィールド８４は、同様に１バイト長であり、そして同様にＲＦＣ１６６２に述べられているように、１６進値のＦＦに常に設定される。

制御フィールド８６は、１バイト長であり、そして同様にＲＦＣ１６６２に指定されているように、１６進値の０３に固定される。

プロトコル番号フィールド８８では、このフィールド中の値は、データ・パケット８０が何であるかを指示する。プロトコル番号フィールド８８は、長さが２バイトである。例えば、ＲＦＣ１６６１及び１６６２に規定されたように、Configuration Requestメッセージ７０のような各々のＬＣＰメッセージは、１６進値のＣ０２１を有する。この実施形態では、リンク・プロセス５４（図５）において使用されるSyncメッセージ５６、Requestメッセージ５８又はReplyメッセージ６０のような各々のメッセージは、ＰＰＰにおいて使用されるいずれかのプロトコル値とは異なる固有のプロトコル値を有する。それなりに、データ・パケット８０がＰＰＰパケットであるかＰＰＰパケットでないかどうかは、容易に区別されることができる。

データ・フィールド９０は、ゼロからペイロードのバイト数より大きい範囲の長さを有し、ペイロードはデータ又は制御情報のいずれかを含んでいる。例えば、もし、データ・パケット８０がRequestメッセージ５８であることを指示する値をプロトコル番号フィールド８８内の値が有するのであれば、データ・フィールドは、上記のようなパラメータ・オプションに関係する全ての情報含む。別の１つの例として、もし、データ・パケット８０がユーザ・データ６２（図５）であることを指示する値をプロトコル番号フィールド８８内の値が有するのであれば、レイヤ３から発生されるＩＰデータ・パケットは、データ・フィールド９０の中へと全体がカプセル化される。

ＦＣＳフィールド９２は、長さが２から４バイトの範囲であり、そして伝送の間のエラーに対する基本的な保護を提供するためにフレーム８０についての、ＣＲＣ（Cyclic Redundancy Code：巡回冗長コード）のようなコードを含む。

上に述べたように（例えば、図５参照）、Syncメッセージ５６、Replyメッセージ６０、Terminate Requestメッセージ６４、及びTerminate Ackメッセージに加えて、別のタイプのメッセージは、リンク確立プロセス５４の中で同様に実行されることができる。図１２は、いくつかの例を示す。

参照は、ここで図１２と関連して図３に向けられる。例えば、図１２に参照番号９４によって表示されたアクティブでない通信の延長された期間の後で、いずれかのノード４４又はＮＡＳ４６は、別のパーティにEcho Request（エコー要請）メッセージ９６を送ることができ、そのパーティ又はリンク４５の状態に関して問い合わせることができる。例えば、もし電源異常に起因してリンク４５のために確立された物理リンクがないのであれば、送る側のパーティは、Echo Requestメッセージ４５から何の応答も受け取らないはずである。したがって、送る側のパーティは、通信セッション５４を終了させることを望むことができる。一方で、もしリンク４５がまだ物理的に接続されているのであれば、受け取る側のパーティは、Echo Reply（エコー応答）メッセージ９８を送ることによってEcho Requestメッセージ９６に応答することができる。送る側のパーティは、その後で、通信セッション５４を終了させるための判断に進むことができる。タイム・ピリオド９４の期間は、予め決められることができる。

ユーザ・データ６２の交換の最中に、ＮＡＳ４６は、その後の認証のための情報を要請しているノード４４にAuthenticate（認証）メッセージ９９を送ることができる。例えば、通常のデータ・トラフィックの間に、ノード４４は、あるユーザによってだけ手に入れることができる取り扱いに注意を要する情報をアクセスする必要があり得る。それなりに、ＮＡＳ４６は、その後の認証のためにノード４４にAuthenticateメッセージ９９を送ることができる。上に述べたようにＰＡＰ及びＣＨＡＰのような認証プロトコルに加えて、この技術において公知の他のさらに複雑なプロトコル体系が同様に使用されることができる。一例は、認証のためにネットワーク４８の内部に又は外部のいずれかに置かれたＡＡＡ（Authentication, Authorization, and Accounting：認証、認可、及びアカウンティング）サーバのような、外部のサーバを採用するＥＡＰ（Extended Authentication Protocol：拡張認証プロトコル）であり得る。

図１３は、本発明の具体例の実施形態にしたがって参照番号１００によって表示された、図３に示されたノード４４のような装置のハードウェア・インプリメンテーションの一部を模式的に示す。装置１００は、例えば、ラップトップ・コンピュータ、ＰＤＡ、又はセルラ電話機のような、種々の形式で構築されることができそして取り込まれることができる。

装置１００は、複数の回路を一緒にリンクさせる中央データ・バス１０２を備える。回路は、ＣＰＵ（Central Processing Unit：中央処理装置）又はコントローラ１０４、受信回路１０６、送信回路１０８、及びメモリ・ユニット１１０を含む。

もし、装置１００が無線デバイスであれば、受信回路及び送信回路１０６及び１０８は、図には示されていないがＲＦ（Radio Frequency：無線周波数）回路に接続されることができる。受信回路１０６は、受信した信号をデータ・バス１０２に送る前に処理しそしてバッファする。一方で、送信回路１０８は、デバイス１００から外に送る前にデータ・バス１０２からのデータを処理しそしてバッファする。ＣＰＵ／コントローラ１０４は、データ・バス１０２のデータ管理の機能を、そしてさらにメモリ・ユニット１１０内の命令的なコンテントを実行することを含む一般的なデータ処理の機能を実行する。

図１３に示されたように別々に配置される代わりに、代案として、送信回路１０８及び受信回路１０６は、ＣＰＵ／コントローラ１０４の一部であることができる。

メモリ・ユニット１１０は、参照番号１１２によって一般的に表示される命令のセットを含む。この実施形態では、命令は、他のものの中で、プロトコル・スタック機能１１４、リンク確立クライアント１１６、ＰＰＰ機能１１８のような部分を含む。プロトコル・スタック機能１１４は、前に図４に示されそして説明されたように、スタック５２に類似のプロトコル・スタックをランする。リンク確立クライアント１１６は、上に説明された図５−１０に記載されたプロセスのようなプロセスにしたがった命令的なセットを含む。ＰＰＰ機能１１８は、装置１０２がＰＰＰプロセスを実行することを可能にするための命令のセットを含む。ＰＰＰ機能１１８は、同様に前に説明されたように、独立して使用されることができる、又はリンク確立クライアント１１６からの代替として使用されることができる。

この実施形態では、メモリ・ユニット１１０は、ＲＡＭ（Random Access Memory：ランダム・アクセス・メモリ）回路である。具体例の命令部分１１４，１１６及び１１８は、ソフトウェア・ルーチン又はソフトウェア・モジュールである。メモリ・ユニット１１０は、別の１つのメモリ・ユニット（図示せず）に結合されることができ、それは、揮発性タイプ又は不揮発性タイプのどちらかであり得る。代案として、メモリ・ユニット１１０は、別の回路タイプ、例えば、ＥＥＰＲＯＭ（Electrically Erasable Programmable Read Only Memory：電気的消去プログラム可能な読み出し専用メモリ）、ＥＰＲＯＭ（Electrically Programmable Read Only Memory：電気的プログラム可能な読み出し専用メモリ）、ＲＯＭ（Read Only Memory：読み出し専用メモリ）、ＡＳＩＣ（Application Specific Integrated Circuit：特定用途集積回路）、磁気ディスク、光ディスク、及びこの分野において周知の別のものからなることができる。

図１４は、本発明にしたがった、図３に示されたＮＡＳ４６のような別の１つの装置のハードウェア・インプリメンテーションの一部を模式的に示し、そして、参照番号１２０によって表示される。装置１２０は、複数の回路を一緒にリンクさせる中央データ・バス１２２を備える。回路は、ＣＰＵ（中央処理装置）又はコントローラ１２４、受信回路１２６、送信回路１２８、及びメモリ・ユニット１３０を含む。

受信回路及び送信回路１２６及び１２８は、そこに装置１２０がリンクされているネットワーク・データ・バス（図示せず）に接続されることができる。受信回路１２６は、内部データ・バス１２２に転送する前に、ネットワーク・データ・バス（図示せず）から受け取った信号を処理しそしてバッファする。送信回路１２８は、装置１２０から外に送る前にデータ・バス１２２からのデータを処理しそしてバッファする。ＣＰＵ／コントローラ１２４は、データ・バス１２２のデータ管理及びメモリ・ユニット１３０の命令コンテントを実行することを含む総合的なデータ処理の機能に関する責務を実行する。

再び、図１４に示されたように別々に配置される代わりに、送信回路１２８及び受信回路１２６は、ＣＰＵ／コントローラ１２４の一部であることができる。

メモリ・ユニット１３０は、参照番号１３４によって一般的に表示された命令のセットを含む。この実施形態では、命令は、他のものの中で、プロトコル・スタック機能１３６、リンク確立サーバ１３８、及びＰＰＰ機能１４０の部分を含む。プロトコル・スタック機能１３６は、前に図４に示されそして説明されたように、スタック５２に類似のプロトコル・スタックをランする。リンク確立サーバ１３８は、図５−１０に示されそして上に説明されたプロセスのようなプロセスにしたがった命令的なセットを含む。ＰＰＰ機能１４０は、装置１２０がＰＰＰプロセスを実行することを可能にするための命令のセットを含む。ＰＰＰ機能１４０は、同様に前に説明されたように、独立して実行されることができる、又はリンク確立サーバ１３８からの代替として実行されることができる。

メモリ・ユニットは、上に述べたようなタイプのメモリ回路からなることができ、そしてさらに繰り返されない。

図５−１０に示されそして説明されたプロセス５４，６８，７０’は、同様に、この技術において公知のいずれかのコンピュータ読み取り可能な媒体上に記憶される又は伝送されることができる。この明細書及び添付された特許請求の範囲において、用語“コンピュータ読み取り可能な媒体”は、実行のためにそれぞれ図１２及び図１３に示されそして説明されたＣＰＵ／コントローラ１０４及び１２４に命令を提供する際に関係するいずれかの媒体を呼ぶ。もし記憶装置タイプであればそのようなコンピュータ読み取り可能な媒体は、同様に前に説明されたように、メモリ・ユニット１１０及び１３０に関する回路形式と同じ揮発性記憶媒体又は不揮発性記憶媒体の形式を取ることができる。もし伝送タイプであればそのようなコンピュータ読み取り可能な媒体は、例えば、同軸ケーブル、金属電線、光ケーブル、及び機械又はコンピュータによって読み取り可能な信号を搬送できる音響波又は電磁波を搬送する無線インターフェースを含むことができる。

最後に、本実施形態に記載されたものは、レイヤ３プロトコルが、ＩＰとして説明されている。ＩＰは、ＩＰｖ４（Internet Protocol version 4：インターネット・プロトコル第４版）及びＩＰｖ６（Internet Protocol version 6：インターネット・プロトコル第６版）のような、異なるバージョンであり得る。その上、別のレイヤ３プロトコルが同等に適用可能であることが、注目されるべきである。例えば、レイヤ３プロトコルは、ＩＰＸ（Internetworking Packet Exchange Protocol：インターネット上で動作するパケット交換プロトコル）アップル・トーク（Apple-Talk）及び別のバージョンの各種の他のネットワーク・プロトコルであり得る。その上、具体例の実施形態では、ノード４４は、ＮＡＳ４６と無線で通信する移動デバイスとして図示されている。ノード６０が固定であり得ることが理解されるはずである。それに加えて、リンク４５は、無線リンクである必要がない。代わりにリンク４５は、有線リンクであり得る。その上、本実施形態に関連して記載されたいずれかの論理ブロック、回路、及びアルゴリズム・ステップは、ハードウェア、ソフトウェア、ファームウェア、又はその組み合わせで与えられることができる。形状及び詳細における論理の変更及びその他の変更が本発明の範囲及び精神から逸脱することなくその中で行われ得ることが、当業者によって理解されるはずである。

図１は、ネットワークの全体的な接続の概略図である。 図２は、従来のプロトコルの通信セッションの通信シーケンス図である。 図３は、本発明の具体例の実施形態に含まれるノードの概要図である。 図４は、階層分類上の順番にプロトコルのスタックを示す概要図である。 図５は、本発明の具体例の実施形態にしたがった通信セッションの通信シーケンス図である。 図６は、本発明の具体例の実施形態にしたがって含まれるステップを示すフローチャートである。 図７は、従来のプロトコルにフェール・オーバー・フィーチャを用いて実行される具体例の実施形態を示す通信シーケンス図である。 図８は、図７の通信シーケンス図に対応するフローチャートである。 図９は、従来のプロトコルに別の１つのフェール・オーバー・フィーチャを用いて実行される具体例の実施形態を示す別の１つの通信シーケンス図である。 図１０は、図９の通信シーケンス図に対応するフローチャートである。 図１１は、具体例の実施形態にしたがってネットワーク・アクセスを得ようとしているノードの回路の一部の概要図である。 図１２は、追加のメッセージ・タイプを用いて実行される図１の通信セッションの通信シーケンス図である。 図１３は、具体例の実施形態にしたがってネットワーク・アクセスを得ようとしているノードの回路の一部の概要図である。 図１４は、具体例の実施形態にしたがったネットワーク・アクセス・ノードの回路の一部の概要図である。

符号の説明

３０，３４’…ノード，３４…ＰＰＰ通信セッション，４２…通信システム，４４…ノード，４５…リンク，５０…バックボーン・ネットワーク，５２…ＩＰプロトコル・スタック８０…フレーム・テンプレート，１０２…中央データ・バス，１１０…メモリ，１２２…中央データ・バス，１３０…メモリ。

Claims (49)

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. 請求項２４の装置、該装置は、前記物理リンクを確立した後の前記物理リンクを介して受け取った、前記ノードからのＰＰＰ（２点間プロトコル）メッセージをさらに含み、前記メモリ・ユニットは、前記ＰＰＰメッセージに応答して該ＰＰＰメッセージとは異なるＰＰＰメッセージを送ることによって前記ノードと通信するためのコンピュータ読み取り可能な命令をさらに含む。
28. 請求項２７の装置、ここにおいて、該メモリ・ユニットは、前記ＰＰＰメッセージの対応するデータ・パケット・フォーマットと同じデータ・パケット・フォーマットを有するデータ・パケットを第２のメッセージに与えるためのコンピュータ読み取り可能な命令、をさらに備える。
29. 請求項２４の装置、ここにおいて、前記複数の設定は、それぞれのパラメータを有する各設定をさらに含み、前記複数の設定の少なくとも一部は、前記それぞれのパラメータの少なくとも一部に冗長度を有する。
30. 請求項２４の装置、ここにおいて、前記同期メッセージは、前記ノードから選択するために、前記ノードのための複数の可能な認証オプションをさらに含む。
31. ネットワーク・アクセス・ノードを介したネットワーク・アクセスに対する通信セッションのための方法、該方法は下記を具備する：
    ノードによって、認証のための少なくとも一つのパラメータ・オプション、リンク設定のための複数のパラメータ・オプション、及びネットワーク・アクセスのための複数のパラメータ・オプションを含み、ネットワーク・アクセスを確立するため前記装置によってサポートされる複数の設定を定義する、パラメータ・オプションのセットを含んでいる第１のメッセージを提供すること；
    前記ネットワーク・アクセス・ノードに前記第１のメッセージを送ること；及び
    前記ネットワーク・アクセス・ノードによってサポートされたオプションに対応するパラメータ・オプションのセットの選択されたサブセットを含む、前記ネットワーク・アクセス・ノードから前記ネットワーク・アクセスを確立するための第２のメッセージを受け取ること。
32. 請求項３１の方法、該方法は、前記パラメータ・オプションのセットの選択されたサブセットが前記ネットワーク・アクセスを確立するための該装置のためのしきい値を満足する場合に前記ネットワーク・アクセスを開始することをさらに備える。
33. 請求項３１の方法、該方法は、前記パラメータ・オプションのセットの選択されたサブセットが前記ネットワーク・アクセスを確立するために該装置のためのしきい値を満足しない場合に前記第１のメッセージ中のパラメータ・オプションのセットとは異なるパラメータ・オプションの第２のセットを有する第３のメッセージを前記ネットワーク・アクセス・ノードに送るたことをさらに備える。
34. 請求項３１の方法、該方法は、前記物理リンクを確立した後、前記ネットワーク・アクセス・ノードから受け取ったＰＰＰ（２点間プロトコル）メッセージを受け取ること、及び、前記ＰＰＰメッセージに応答して該ＰＰＰメッセージとは異なるＰＰＰメッセージを送ることを介して前記ネットワーク・アクセス・ノードと通信すること、をさらに含む。
35. 請求項３１の方法、ここにおいて、前記複数の設定は、それぞれのパラメータを有する各設定をさらに含み、前記複数の設定の少なくとも一部は、前記それぞれのパラメータの少なくとも一部に冗長度を有する。
36. 請求項３１の方法、ここにおいて、前記パラメータ・オプションのセットは、リンク設定のための全ての利用可能なパラメータ・オプションと、ネットワーク・アクセスのための全ての利用可能なパラメータ・オプションと、を含む。
37. 請求項３１の方法、該方法は、前記ノードから選択するために、前記ノードのための複数の可能な認証オプションを同期メッセージとして受け取ることと、前記複数の可能な認証オプションのうちの一つを、前記第１のメッセージに含めるための前記認証のための少なくとも一つのパラメータ・オプションとして選択することと、をさらに備える。
38. ネットワーク・アクセス・ノードを介したネットワーク・アクセスに対する通信セッションのための装置、該装置は下記を具備する：
    認証のための少なくとも一つのパラメータ・オプション、リンク設定のための複数のパラメータ・オプション、及びネットワーク・アクセスのための複数のパラメータ・オプションを含み、ネットワーク・アクセスを確立するため前記装置によってサポートされる複数の設定を定義する、パラメータ・オプションのセットを含んでいる第１のメッセージを提供するための手段；
    前記ネットワーク・アクセス・ノードに前記第１のメッセージを送るための手段；及び、
    前記ネットワーク・アクセス・ノードによってサポートされたオプションに対応するパラメータ・オプションのセットの選択されたサブセットを含む、前記ネットワーク・アクセス・ノードから前記ネットワーク・アクセスを確立するための第２のメッセージを受け取るための手段。
39. 請求項３８の装置、該装置は、前記パラメータ・オプションのセットの選択されたサブセットが前記ネットワーク・アクセスを確立するための該装置のためのしきい値を満足する場合に前記ネットワーク・アクセスを開始するための手段をさらに備える。
40. 請求項３８の装置、ここにおいて、前記複数の設定は、それぞれのパラメータを有する各設定をさらに含み、前記複数の設定の少なくとも一部は、前記それぞれのパラメータの少なくとも一部に冗長度を有する。
41. 請求項３８の装置、該装置は、前記ノードから選択するために、前記ノードのための複数の可能な認証オプションを同期メッセージとして受け取るための手段と、前記複数の可能な認証オプションのうちの一つを、前記第１のメッセージに含めるための前記認証のための少なくとも一つのパラメータ・オプションとして選択するための手段と、をさらに備える。
42. ネットワーク・アクセス・ノードを介したネットワーク・アクセスに対する通信セッションにおける装置による使用のためのコンピュータ読み取り可能な記憶媒体、該コンピュータ読み取り可能な記憶媒体は下記を具備する：
    認証のための少なくとも一つのパラメータ・オプション、リンク設定のための複数のパラメータ・オプション、及びネットワーク・アクセスのための複数のパラメータ・オプションを含み、ネットワーク・アクセスを確立するため前記装置によってサポートされる複数の設定を定義する、パラメータ・オプションのセットを含んでいる第１のメッセージを提供するための少なくとも一つの命令；
    前記ネットワーク・アクセス・ノードに前記第１のメッセージを送るための少なくとも一つの命令；及び
    前記ネットワーク・アクセス・ノードによってサポートされたオプションに対応するパラメータ・オプションのセットの選択されたサブセットを含む、前記ネットワーク・アクセス・ノードから前記ネットワーク・アクセスを確立するための第２のメッセージを受け取るための少なくとも一つの命令。
43. 請求項４２のコンピュータ読み取り可能な記憶媒体、該コンピュータ読み取り可能な記憶媒体は、前記パラメータ・オプションのセットの選択されたサブセットが前記ネットワーク・アクセスを確立するための該装置のためのしきい値を満足する場合に前記ネットワーク・アクセスを開始するための少なくとも一つの命令をさらに備える。
44. 請求項４２のコンピュータ読み取り可能な記憶媒体、ここにおいて、前記複数の設定は、それぞれのパラメータを有する各設定をさらに含み、前記複数の設定の少なくとも一部は、前記それぞれのパラメータの少なくとも一部に冗長度を有する。
45. 請求項４２のコンピュータ読み取り可能な記憶媒体、該コンピュータ読み取り可能な記憶媒体は、前記ノードから選択するために、前記ノードのための複数の可能な認証オプションを同期メッセージとして受け取るための少なくとも一つの命令と、前記複数の可能な認証オプションのうちの一つを、前記第１のメッセージに含めるための前記認証のための少なくとも一つのパラメータ・オプションとして選択するための少なくとも一つの命令と、をさらに備える。
46. ネットワーク・アクセスを得ようとしているノードとの通信セッションにおけるネットワーク・アクセス・ノードによる使用のためのコンピュータ読み取り可能な記憶媒体、該コンピュータ読み取り可能な記憶媒体は下記を具備する：
    認証のための少なくとも一つのパラメータ・オプション、リンク設定のための複数のパラメータ・オプション、及びネットワーク・アクセスのための複数のパラメータ・オプションを含み、ネットワーク・アクセスを確立するため前記ノードによってサポートされる複数の設定を定義する、パラメータ・オプションのセットを含んでいる第１のメッセージを前記ノードから受け取るため少なくとも一つの命令；
    前記ノードにネットワーク・アクセスを提供するためのパラメータ・オプションのセットから、該装置によってサポートされるオプションに対応するサブセットを選択するための少なくとも一つの命令；及び
    該装置によってサポートされたオプションに対応するパラメータ・オプションのセットの選択されたサブセットを含む、前記ネットワーク・アクセスを確立するための第２のメッセージを前記ノードに送るための少なくとも一つの命令。
47. 請求項４６のコンピュータ読み取り可能な記憶媒体、該コンピュータ読み取り可能な記憶媒体は、前記パラメータ・オプションのセットの選択されたサブセットが前記ネットワーク・アクセスを確立するための前記ノードのためのしきい値を満足すると前記ノードが判断した場合に前記ノードから送られる前記ネットワーク・アクセスのためのユーザ・データを前記ノードから受け取るための少なくとも一つの命令をさらに含む。
48. 請求項４６のコンピュータ読み取り可能な記憶媒体、ここにおいて、前記複数の設定は、それぞれのパラメータを有する各設定をさらに含み、前記複数の設定の少なくとも一部は、前記それぞれのパラメータの少なくとも一部に冗長度を有する。
49. 請求項４６のコンピュータ読み取り可能な記憶媒体、該コンピュータ読み取り可能な記憶媒体は、前記ノードから選択するために、前記ノードのための複数の可能な認証オプションを同期メッセージとして前記ノードに送るための少なくとも一つの命令をさらに含む。

Images