JP2011072008A - 異なるリンク確立プロトコルを有するネットワークのためのハンドオフサポート - Google Patents

Abstract

【課題】ローミングしているノードが、異なるネットワークインタフェースレイヤプロトコルを用いて実現される異なるネットワークからネットワークアクセスを探索する通信システムにおけるハンドオフスキームを提供する。
【解決手段】ノード５６は、ネットワークアクセスに対し低い中断レベルで、１つのネットワークから別のネットワークへと自由に移動する。ハンドオフの開始時、ノードは、ハンドオフのための指示を受ける。この指示は、例えば、ＳＩＤ、ＮＩＤ、又はＰＺＩＤの変更を示す信号メッセージのような様々な形式で具体化されうる。その指示は、ハンドオフに先立ってローミングノードに送られるデータパケットに率直に含まれる情報の形態とすることができる。代案として、この指示は、ノードに送られる識別可能なメッセージパターンとして実現されうる。
【選択図】図４

Description

優先権の主張

本特許出願は、本明細書の譲受人に譲渡され、参照によって本明細書に明確に組み込まれる２００４年９月２８日出願の"A Method and Apparatus for Handoff Support Fast Link Establishment Protocol"と題された米国仮出願６０／６１４，２１５号の優先権を主張する。

本発明は、一般に、パケットデータ通信に関し、特に、ネットワーク間の何れかのパケットデータ通信前に実行することがしばしば必要とされる異なるリンク確立プロトコルを有するネットワークのためのハンドオフサポートに関する。

ネットワークをグローバルに相互接続することにより、情報は、地理的な距離に関係なく速やかにアクセスされるようになる。図１は、一般に、参照番号２０によって示されるインターネットと称されるグローバル接続ネットワークの簡略概略図を示す。インターネット２０は、本質的には、共にリンクしている異なる階層レベルを持つ多くのネットワークの中にある。インターネット２０は、ＩＥＴＦ（インターネット技術特別調査委員会）によって発布されたＩＰ（インターネットプロトコル）の下で操作される。ＩＰの詳細は、ＩＥＴＦによって公表されたＲＦＣ（Request For Comments）７９１で見られる。

インターネット２０には、ネットワークサイズに依存してＬＡＮ（ローカルエリアネットワーク）又はＷＡＮ（ワイドエリアネットワーク）と呼ばれる様々な個別のネットワークが接続されている。図１には、そのようなネットワーク２２，２４，２６，２８のうちの幾つかが示されている。

ネットワーク２２，２４，２６，２８の各々には、接続され、互いに通信する様々な機器が存在する。ほんの２〜３の例であるが、具体的には、コンピュータ、プリンタ、及びサーバである。これらは一般にノードと呼ばれる。ノードが、インターネット２０を経由して、自己のネットワークを越えて通信する場合、ノードにＩＰアドレスを割り当てる必要がある。ＩＰアドレスの割り当ては、マニュアル又は自動でなされる。例えば、ＩＰアドレスのマニュアル割り当ては、ネットワーク管理者によってなされうる。ほとんどの場合、ＩＰアドレスは、例えば、ＬＡＮ又はＷＡＮ内の専用サーバによって自動的に割り当てられる。

実例を挙げてみる。ネットワーク２２内のノード３０が、ネットワーク２４内の別のノード３７へデータパケットを送ろうとしていると仮定する。ＩＰの下では、データパケットはそれぞれソースアドレスと宛先アドレスとを持つ必要がある。この場合、ソースアドレスは、ネットワーク２２内のノード３０のアドレスである。宛先アドレスは、ネットワーク２４内のノード３７のアドレスである。

しばしば、ノード対ノードの通信は、インターネット２０を経由した他のネットワークへのアクセスのようなネットワークアクセスに先立って必要とされる。別の例を挙げてみる。ネットワーク２２内のノード３０が、ラップトップコンピュータであると仮定する。このラップトップコンピュータノード３０は、ネットワーク２２に対する直接的なアクセスを持たない。しかしながら、このラップトップコンピュータノード３０は、例えば、電話回線を通じて有線モデムをダイアルアップすることによってなど、別の手段を使ってネットワーク２２内のＮＡＳ（ネットワークアクセスサーバ）３２に到達しうる。この場合、ノード３０は一般に、ネットワーク２２内のＮＡＳ（ネットワークアクセスサーバ）３２とＰＰＰ（ポイントトゥポイントプロトコル）を確立する。その後、ノード３０とネットワーク２２との間に確立されたパケットデータ通信、又はインターネット２０を経由したその他任意のネットワークは、有線モデム及び電話回線を介して交換される。モデムが、電話回線を通して信号をシリアルかつ非同期に送受信する場合、電話回線を介して交換されるデータパケットもまたシリアルかつ非同期なモデムに適応するように構成されねばならない。

無線技術の進歩によって、ノードは、元々登録したネットワークから別のネットワークへと移動することが可能となった。例えば、図１に示すように、ノード３０は、ネットワーク２２に恒久的に接続されるのではなく、例えばＰＤＡ（パーソナルデジタルアシスタント）、セルラ電話、又はモバイルコンピュータのような無線デバイスでありうる。この無線ノード３０は、そのホームネットワーク２２の境界を越えて移動することができる。したがって、ノード３０は、そのホームネットワーク２２から外部のネットワーク２８までローミングすることができる。ネットワーク２８のアクセスを取得するため、あるいはインターネット２０経由で他のネットワークに接続されるために、ノード３０はまた、一般に、ネットワーク２８内のＮＡＳ３３とのＰＰＰセッションを確立する。ノード３０とＮＡＳ３３との間の通信は、この場合、エアリンクを介する。更に、このエアリンクを介して交換されるデータパケットは、ノード３０とＮＡＳ３３との間のＰＰＰセッション中にネゴシエートされるフォーマットに適するように構成される必要がある。

ＰＰＰの大部分は、ＩＥＴＦによって公表されたＲＦＣ１６６１，１６６２に記述されている。ＰＰＰは、本質的に、ノード間の探索的でかつネゴシエートするセッションである。このセッション中、ノードは、機能及び利用可能性の観点から互いのリソースから見つけ出し、最終的に、あらゆるネットワークトラフィックフローに先立って、相互に許容可能なパラメータオプションのセットに収束する。ＰＰＰセッションは、しばしば、ネットワークアクセスに先立って確立される必要があるので、ＰＰＰは、「ネットワークインターフェイスレイヤプロトコル（network interface layer protocol）」とも呼ばれる。しかしながら、「リンク確立プロトコル（link establishment protocol）」及び「レイヤ２プロトコル（Layer-2 protocol）」を含む他の類似の用語もまた一般に使用される。以下では、用語「ネットワークインタフェースレイヤプロトコル」、「リンク確立プロトコル」、及び「レイヤ２プロトコル」は、置換可能に使用される。

図２は、ネットワーク２８内のノード３０がインターネット２０へのアクセスを取得するために、ＮＡＳ３３との通信リンクの確立を試みる典型的ＰＰＰ通信セッション３４のシーケンスフロー図を示す。

ＰＰＰは、多くのプロトコルコンポーネントを有する。図２に示す典型的なＰＰＰセッションでは、ＰＰＰは、コンポーネントとしてＬＣＰ（リンク制御プロトコル（Link Control Protocol））３６、ＣＨＡＰ（チャレンジ／ハンドシェーク認証プロトコル（Challenge/Handshake Authentication Protocol））３８、及びＩＰＣＰ（インターネットプロトコル設定プロトコル（Internet Protocol Configuration Protocol））４０を有する。

先ず、物理リンクが完成すると、すなわち、ノード３０とＮＡＳ３３とが互いにハードウェアレベルで接続することができると、ＬＣＰ３６を介する必要がある。ＬＣＰ３６は、ノード３０とＮＡＳ３３との間の基礎的な通信リンクを確立するのに役立つ。ＬＣＰ３６を介して、ノード３０とＮＡＳ３３とは互いに不可欠な通信パラメータオプションを交換しネゴシエートする。このオプションは、リンクを介したデータパケットの最大サイズ、品質管理に関するパラメータ、使用されるＨＤＬＣ（ハイレベルデータリンク制御）ヘッダフィールド圧縮スキーム、及び、ピアが認証されることを望んでいるか、を含むことができる。

ＬＣＰ３６の処理は、多かれ少なかれ、ハンドシェイクエチケットの下で操作される。まず、要求側パーティは、設定要求メッセージを送ることによって１又は複数のパラメータを提案する。何れのパラメータも受信側パーティによって認識されない場合、受信側パーティは、チャレンジ拒否メッセージで返答する。この拒否されたパラメータが、要求されたリンクにとって致命的である場合、要求側パーティは、ＰＰＰセッションを終了しなければならない。

一方、パラメータは認識されるが、パラメータに関連するオプションが受け入れられない場合、応答側パーティは、設定Ｎａｋメッセージを送り返す。要求側パーティは再びＰＰＰセッションを終了するか、同じパラメータで別のオプションを持つ別の設定要求メッセージを送ることができる。

関連するオプションを備えたパラメータは、全てネゴシエートされ、かつ上述したような方法で設定されねばならない。図２に示すように、数回のネゴシエーションが必要かもしれない。必要とされる全てのパラメータが応答側パーティに受け入れ可能であると要求側パーティが判定すると、要求側パーティは、最後の設定Ａｃｋメッセージを応答側パーティへ送る。両パーティが設定Ａｃｋメッセージを一旦送ると、認証フェーズへ移る。

これらパーティが許可されることを保証するために、認証を実行しなければならない。認証を行なう１つの方法は、他のＰＰＰコンポーネントＣＨＡＰ３８を使用することである。ノード３０の身元を確認するためにＣＨＡＰ３８を起動させるのは一般にＮＡＳ３３である。ＣＨＡＰ３８の間、ＮＡＳ３３は、チャンレンジメッセージと呼ばれるメッセージをノード３０に送る。ＣＨＡＰの下では、アルゴリズムに関する事前合意を用いて応答メッセージを計算するために使用されるチャレンジメッセージとともに使用される共有される秘密がある。そして、ノード３０は、この秘密アルゴリズムによって生成された応答メッセージをＮＡＳ３３に送る。ＮＡＳ３３はその後、この受信した応答メッセージを、ＮＡＳ３３自身によって計算されたメッセージと比較する。この比較が一致する場合、ノード３０はＣＨＡＰ３８を合格したと言われる。そして、ＮＡＳ３３は、ＣＨＡＰ成功メッセージをノード３０に送る。そうでない場合、ＮＡＳ３３によってＣＨＡＰ失敗メッセージが送られる。

あるいは、ＣＨＡＰ３８の代わりに、ＰＡＰ（パスワード認証プロトコル（Password Authentication Protocol））によって認証を行うこともできる。ＰＡＰでは、ノード３０は単にＮＡＳ３３に検証用のユーザ名とパスワードとを送る。もし検証されれば、ノード３０はＰＡＰを合格したと言われる。

ノード３０がＩＰアクセスを必要とする場合、ＩＰに関連する情報を再度交換しネゴシエートする必要がある。とりわけ、例えば、ノード３０は、ＩＰに従ってインターネット２０（図１）にアクセスするために、ＩＰアドレスの割り当てを持つ必要がありうる。これを行うために、ＩＰＣＰ４０の下のパラメータオプションのネゴシエート及び交換が開始される。典型的なＰＰＰセッション３４では、ノード３０は、初めは、ＮＡＳ３３からＩＰアドレス０．０．０．０を要求する。これを受けて、ＮＡＳ３３は、設定Ｎａｋメッセージを送り、ノード３０がＩＰアドレスａ．ｂ．ｃ．ｄを使用することを提案する。これが受け入れられれば、ノード３０は、アクノレッジメントのための別のメッセージをＮＡＳ３３に送ることにより、ＩＰアドレスａ．ｂ．ｃ．ｄの使用を確認する。

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

ネットワークアクセスの終わりに、ノード３０又はＮＡＳ３３の何れかは、他方に対して終了要求メッセージを送信しうる。受け取った側は、その後、終了Ａｃｋメッセージで返答し、通信セッションを終える。

図２を見て分かるように、そして、上述したように、ＰＰＰセッション３４の間、ノード３０とＮＡＳ３３の間で交換される極めて多くのメッセージがある。それには、相当な接続時間が含まれる。ＰＰＰセッション３４が、高データレイテンシの遅いリンクを介してネゴシエートされる場合、これは正に現実である。

ノード３０とＮＡＳ３３の間の最初のリンク確立処理を促進するために、ＰＰＰ以外の様々なプロトコルが提案された。そのようなプロトコルの一例は、２００５年７月２８日に出願され、"Fast Link Establishment for Network Access"と題されたた米国特許出願１１／１９３，０６８号（特許出願１）（以降、「０６８」特許出願と称する）で教示されている。本明細書の譲受人に譲渡されている「０６８」特許出願は、その全体が本明細書に参照によって明確に組み込まれている。以下に、ＰＰＰ以外のあらゆるリンク確立プロトコルを、非ＰＰＰと呼ぶ。

しかしながら、あるネットワークが非ＰＰＰをサポートし、他方がサポートしない通信ネットワークでは問題が生じる。更に、モバイルノードが、異なるリンク確立プロトコルを持つ別のネットワークの周囲をローミングする場合、この問題は悪化する。

説明のために別の例を挙げる。再び図１を参照されたい。ノード３０は、ネットワーク２８へ移動した後に、非ＰＰＰセッションによってＮＡＳ３３との通信リンクを確立すると仮定する。その後、ユーザデータが、ノード３０とＮＡＳ３３との間で交換される。更に、ユーザデータの交換の最中に、ノード３０が、例えばネットワーク２６のような更に別のネットワークに移動すると仮定する。ネットワークインタフェースレイヤプロトコル実装を含むプロトコル実装、及び物理実装に関する全ての局面において、ネットワーク２６がネットワーク２８に類似している場合、ストリームラインハンドオフスキームを考えることができる。ネットワーク２６の領域に到着した後、ネットワーク２８は、ネットワーク２６にデータ処理デューティをハンドオーバすることができる。そして、ネットワーク２６は、ネットワーク２８によって以前に保持されていたパケットデータ通信機能を引き継ぐことができる。

しかしながら、ネットワーク２８及びネットワーク２６は、多くの場合、ハードウェア及びリンクレイヤ実装において類似していない。例えば、ネットワーク２８が、ネットワークインタフェースレイヤプロトコルのようなＰＰＰのみならず他の非ＰＰＰもまたサポートするものと仮定する。他方、ネットワーク２６は、ネットワークインタフェースレイヤプロトコルのようなＰＰＰのみをサポートし、他の何れをもサポートしないと仮定する。ノード３０は、ネットワーク２８からネットワーク２６に移動した後、ネットワークアクセスを継続するためには先ず、ネットワーク２６のＮＡＳ３５と別のネットワークインタフェースレイヤプロトコルセッションを確立する必要がある。これによって、その後確立されるパケットデータ通信が、ネットワーク２６内のＮＡＳ３５とノード３０との間に確立される物理リンクに準拠できるようになる。ノード３０が、ネットワーク２６によって要求される従来のＰＰＰをスムーズに起動するように適合していないのであれば、ノード３０は、ネットワークアクセスから完全に切られてしまう。

従って、異なるネットワークインタフェースレイヤプロトコルをサポートする異なるネットワークの中からネットワークアクセスを探索する移動ノードに対する信頼性の高いハンドオフ処理を提供する必要がある。

米国特許出願１１／１９３，０６８号

"Interoperability Specification (IOS) for CDMA 2000 Access Network Interfaces," TIA-2001-D, Feb. 2005

複数のネットワークを備えた通信システムでは、前記通信システムにおけるネットワークアクセスを探索するノードは、１つのネットワークから別のネットワークへ移動するハンドオフ処理を介しなければならない。異なるネットワークが、異なるネットワークインタフェースレイヤプロトコルで実施される場合、特別なチャレンジが発生する。本発明の典型的な実施形態に従うと、ハンドオフスキームが確立される。これによって、ノードは、ネットワークアクセスに対し少ない中断で、１つのネットワークから別のネットワークへローミングすることができる。ハンドオフに先立って、ノードは、ハンドオフのための指示を受信する。その指示は、ＳＩＤ（System Identification：システム識別情報）、ＮＩＤ（Network Identification：ネットワーク識別情報）、ＰＺＩＤ（Packet Zone Identification：パケットゾーン識別情報）、又はこれらの組み合わせの変更形態かもしれない。代案として、その指示は、ハンドオフ中のノードに送られるデータパケットに直接含まれうる。更なる代案として、その指示は、異なるメッセージパターンが、異なるネットワークインタフェースレイヤプロトコルをサポートする異なるネットワークによって送られるノードに送られたメッセージパターンの形態でもありうる。

本発明の１つの局面に従って、ネットワークアクセスを要求するノードが介する方法が開示される。この方法は、サービス提供ノードと第１のネットワークインタフェースレイヤプロトコルを確立することと、ハンドオフのための指示を受信することと、目標ノードと第２のネットワークインタフェースレイヤプロトコルを確立することとからなる各ステップを含む。

本発明の別の局面に従って、上述した方法の各ステップを実行するハードウェア実装を有する装置が示される。

また、本発明の更に別の局面に従って、上述した方法の各ステップを実行するためのコンピュータ読取可能命令を有するコンピュータ読取可能媒体が開示される。

これら特徴及び他の特徴、ならびに利点は、同一符号が同一部分を参照する添付図面とあわせることにより、以下の詳細記述から当業者に明らかになるであろう。

図１は、ネットワークのグローバルな接続の概略図である。 図２は、従来のネットワークインタフェースレイヤプロトコルの通信セッションの通信シーケンス図である。 図３は、本発明の一般的実施形態に含まれるノード及びネットワークの概略図である。 図４は、無線技術をサポートする本発明の典型的な実施形態に含まれるノード及びネットワークの概略図である。 図５は、階層順のプロトコルスタックを示す概略図である。 図６は、図２に示す従来のネットワークインタフェースレイヤプロトコルとは異なる典型的なネットワークインタフェースレイヤプロトコルの通信セッションの通信シーケンス図である。 図７は、本発明の典型的な実施形態で使用される第１のハンドオフスキームに従って含まれるステップを示す通信シーケンス図である。 図８は、図７に示される通信シーケンス図のハンドオフスキームのフローチャートである。 図９は、本発明の典型的な実施形態で使用される第２のハンドオフスキームに従って含まれるステップを示す通信シーケンス図である。 図１０は、図２及び図６のネットワークインタフェースレイヤプロトコルで使用されるデータフレームフォーマットの概略図である。 図１１は、図９に示す通信シーケンス図のハンドオフスキームのフローチャートである。 図１１Ａは、図７に示す通信シーケンス図のハンドオフスキームの変形のフローチャートである。 図１２は、本発明の典型的な実施形態で使用される第３のハンドオフスキームに従って含まれるステップを示す通信シーケンス図である。 図１３は、図１２で示される通信シーケンス図のハンドオフスキームフローチャートである。 図１４は、典型的な実施形態に従ってネットワークアクセスを探索するノードの回路の一部の概略図である。 図１５は、サービス提供ネットワークとのネットワークインタフェースレイヤプロトコルセッションを確立している最中に、目標ネットワークへのハンドオフが起こるステップを示す通信シーケンス図である。 図１６は、図１５に示す通信シーケンス図に例示するハンドオフ処理の流れ図である。

以下の説明は、いかなる当業者も、本発明を実行し、利用することを可能にするために示される。説明の目的のために、以下の記載で詳細が述べられる。当業者のうちの何れかは、本発明がこれら具体的な詳細を利用することなく実現されうることを理解することが認識されるべきである。他の実例では、よく知られた構成及び処理は、本発明の詳細を、不必要な詳細によって不明瞭にしないために詳しくは説明していない。従って、本発明は、示された実施形態によって限定されると意図されておらず、本明細書で開示された原理及び特徴に一致する最も広い範囲が与えられることになっている。

図３は、本発明の一般的な実施形態に含まれるノードとネットワークの簡略概略図を示す。この通信システムは、参照番号４２によって全体的に示され、バックボーンネットワーク４９に接続されたネットワーク４５及びネットワーク４７を含む。バックボーンネットワーク４９はイントラネット又はインターネットでありうる。バックボーンネットワーク４９に接続される他のネットワークも存在しうるが、明瞭さと簡潔さの理由で図３に示していない。

ネットワーク４５，４７にはそれぞれＮＡＳ（Network Access Server）５１，５３が配置されている。これらは、ネットワークアクセスを要求する任意のノードのためのゲートウェイとして役立つ。システム４２では、バックボーンネットワーク４９経由で、ネットワーク４５又は他のネットワークのうちの何れかのアクセスを探索するノード５５が存在すると仮定する。ノード５５は、ネットワーク４５に対して直接的なアクセスを持たないが、通信リンク５７によってＮＡＳ５１と通信することができる。ノード５５とＮＡＳ５１の間の通信設定は、「リンク確立」と呼ばれる処理を経る。

ノード５５は、例えばネットワーク４５のようなそのオリジナルのネットワークに制限されず、例えばネットワーク４７のような他のネットワークに移動できると仮定する。

この場合、ノード５５がネットワークアクセスを得るために、ネットワーク４５を離れ、ネットワーク４７に移る際、ノード５５は、別の通信リンク介して、ネットワーク４７内のＮＡＳ５３との別のリンク確立セッションを確立しなければならない。

ＮＡＳ５１とノード５５との間のリンク５７は、様々な形式を仮定するリンクになりえる。例えば、リンク５７は、２〜３名前を挙げると、従来の電話回線接続、同軸ケーブルリンク、又は光ケーブルリンクのような有線リンクになりえる。更に、リンク５７は、例えば電磁気又はアコースティック信号を搬送できるエアインタフェースのような無線リンクになりえる。

図４は、無線技術をサポートする通信システム４２のより具体的な実装を示す。この場合、システム全体は、参照番号４４によって一般に示される。ノード間の無線通信は、図４に示すように、例えばエアインタフェースリンク５８，９０のようなエアインタフェースの形態のリンクを経由して搬送されうる。この実施形態では、説明上の一貫性及び明瞭さの目的のために、ネットワーク４４は、米国のＴＩＡ／ＥＩＡ（米国電気通信工業会／電子工業企業体協会）を含む幾つかの国際規格団体のコンソーシアムである３ＧＰＰ２（第三世代パートナシップ計画２）で述べられているｃｄｍａ２０００規格のような無線技術をサポートするとして示される。

システム４４では、他のネットワークへローミング可能なノード５６は、２〜３名前を挙げると、ＰＤＡ（パーソナルデジタルアシスタント）、モバイルコンピュータ、又はセルラ電話のような様々な形態で具体化することができる。

ネットワーク４６には、ＮＡＳ５２の機能を提供するＰＤＳＮ（パケットデータサービングノード）６０が実装されている。ノード５６は、参照数字６２によって一般に示されるＲＡＮ（ラジオアクセスネットワーク）によってＰＤＳＮ６０と通信する。ＲＡＮ６２は、複数のＢＳ（基地局）６５Ａ〜６５Ｎに接続されたＢＳＣ／ＰＣＦ（基地局コントローラ／パケットデータ制御機能）６４を含んでいる。

同様に、ネットワーク４８には、別のＮＡＳ５４の役割を負う別のＰＤＳＮ（パケットデータサービングノード）６６が配置される。ネットワークアクセスを要求する何れのノードも、この別のＲＡＮ６８を経由してＰＤＳＮ６６と通信する。ＲＡＮ６８は、複数のＢＳ７２Ａ〜７２Ｍに接続されたＢＳＣ／ＰＣＦ７０を含む。

ネットワーク４６，４８は、音声又はデータ情報を搬送するデータパケットを処理することができる。無線可能なネットワーク４６，４８のアーキテクチャ上の詳細は、３ＧＰＰ２によって発行された文献 "Interoperability Specification (IOS) for CDMA 2000 Access Network Interfaces," TIA-2001-D, Feb. 2005で見ることができる。

通信システム４２の運用上の詳細について記述する前に先ず、一般に、異なる階層及び相互関係からなる様々なプロトコルレベルによるパケットデータ通信間のデータパケットの処理を説明することが役立つ。

ネットワーク通信の当該技術では、ＩＳＯ（国際標準化機構）によって述べられているように、プロトコルは、ＯＳＩ（Open System Interconnection：開放型システム間相互接続）モデル及びＩＴＵ−Ｔ（国際電気通信連合−電気通信規格セクタ）に従って階層化される。その目的は、マルチベンダ機器相互運用を容易にすることである。すなわち、各レベルのプロトコル階層は、それ自身の仕様を持っている。そのため、独自の階層レベルの仕様を満足する限り、そのレベルでの製品開発は、他のレベルの他の製品との互換性を持つことが保証される。

図４のシステム４４は、ＩＰ（インターネットプロトコル）をサポートすると仮定する。図５は、一般に「プロトコルスタック」と称され、参照番号７４によって一般に示される階層順のプロトコルスタックを概略的に示す。ＩＰプロトコルスタック７４は、ＯＳＩモデルと類似しているが、正確には同じではないＩＥＴＦ（インターネット技術特別調査委員会）モデルに準拠して構築される。ＩＥＴＦモデルに従って、ＩＰプロトコルスタック７４は、レイヤ１から始まってレイヤ５までの５つのレイヤを持っている。したがって、図４で示されるようなノード５６，６０及び６６の各々のようなノードによって送られるデータパケットは、プロトコルスタック７４によって処理されねばならない。プロトコルスタック７４は、ソフトウェア又はハードウェア、あるいはそれらの結合の形態でノード内に構築される。同様に、同じプロトコルスタック７４によって受信されたデータパケットは、逆の順序であるが、同じプロトコルスタック７４によって処理されねばならない。

例を挙げてみる。データパケットが、例えばノード５６（図４）のようなノードから送られるために処理されるのであれば、データパケットは先ず、アプリケーションレイヤ、すなわちレイヤ５におけるプロトコルのうちの１つに従って生成される。レイヤ５は、ＨＴＴＰ（ハイパーテキスト転送プロトコル）、ＳＭＴＰ（サービスメール転送プロトコル）、ＦＴＰ（ファイル転送プロトコル）、およびＲＴＰ（実時間転送プロトコル）を含んでいる。更に、データパケットは、ＶｏＩＰ（ボイスオーバインターネットプロトコル）セッションの製品であると仮定する。従って、データパケットは、レイヤ５内のＲＴＰに従ってフォーマットされねばならない。

レイヤ５内のＲＴＰから生じたデータパケットのような時間に敏感なデータパケットは、実時間で処理される必要がある。具体的には、欠陥のあるパケットは、到来する他のデータパケットの送信を妨害しないように、通常は再送信されず、単に破棄される。したがって、ＲＴＰデータパケットは、通常は、レイヤ４の伝送レイヤ内のＵＤＰ（ユーザデータパケットプロトコル）を経由して搬送される。従って、レイヤ５のＲＴＰからのデータパケットは更に、レイヤ４内のＵＤＰに従って公式化されねばならない。

一方、例えばＦＴＰのようなレイヤ５内の他のプロトコルからデータパケットが生じるのであれば、データパケットは通常は、レイヤ４内のＴＣＰ（伝送制御プロトコル）を経由して送られる。ＴＣＰの下では、データパケットの正確な配信が第１に重要である。そのため、欠陥のあるパケットは、常に再送信される。その結果、データ送信処理の全体速度を落とす。

伝送レイヤであるレイヤ４を通過した後のデータパケットは、ソースポート番号及び宛先ポート番号のような情報が追加される。

伝送レイヤであるレイヤ４を通った後のデータパケットは、その後、処理のためにネットワークレイヤであるレイヤ３に送られる。この特定のケースでは、結果として得られるレイヤ４からのデータパケットは、例えば、追加されたデータパケットのソースアドレス及び宛先アドレスを用いて、ＩＰに従って再びフォーマットされねばならない。

簡潔さの理由で、レイヤ３内ではＩＰだけが図５に示されていることが注目されるべきである。レイヤ３において更に現存のＩＰへの補足機能を実行する他のプロトコルがある。例は、配信できないデータパケットのためにエラーメッセージを送る目的に役立つＩＣＭＰ（インターネットコントロールメッセージプロトコル）である。

その後、リンクレイヤであるレイヤ２において適用可能なあらゆるプロトコルに適合するためにデータパケットを作成しなければならない。既に説明したＰＰＰ（ポイントトゥポイントプロトコル）は、レイヤ２プロトコルとして分類される。前述したように、ネットワークインタフェースレイヤプロトコルとしてＰＰＰに代わるネットワークによって使用される他の非ＰＰＰが存在する。

図５におけるプロトコルスタック７４の最下部レイヤは、データパケットの送信の物理的実施を取り扱う物理レイヤであるレイヤ１である。例えば、図３において、通信リンク５７が、従来の有線リンクである場合、物理レイヤであるレイヤ１は、リンク５７を構成する電導線を通じて信号を駆動するノード５５とノード５１両方のハードウェア回路と関わりを持つ。別の例として、図４では、通信リンク５８がエアインタフェースであり、物理レイヤであるレイヤ１は、エア空間と、このエア空間を介して信号を交信するＲＡＮ６２のハードウェア回路と関連する。

再び図４に戻る。典型的なノード５６によって受信されるデータパケットに関し、逆の順、すなわちレイヤ１からレイヤ５であるが、データパケットは、同じプロトコルスタック７２（図５）によって処理されねばならない。

この例では、ノード５６は先ずＰＤＳＮ６０を経由してネットワークアクセスを要求すると仮定する。更に、ノード５６はネットワーク４６に対して直接的なアクセスを持たないと仮定する。

従来通り、ノード５６は先ず、ＰＤＳＮ６０とのＰＰＰセッションを確立することによってネットワークアクセス処理を開始しうる。しかしながら、既に説明したように、ネットワークアクセスに先立ってリンク処理を合理化するために、他のネットワークインタフェースレイヤプロトコルが提案されている。そのようなプロトコルのうちの１つは、前に述べた‘０６８特許出願によって教示されている。

次の記載では、説明を簡単にするために、‘０６８特許出願で開示されたプロトコルが、典型的な実施形態の運用上の記載と共に示される。しかしながら、本発明の実現には必要ではなく、そのように限定されるべきではないことに注目されるべきである。‘０６８特許出願に記載されたプロトコル以外の他のネットワークインターフェイスレイヤプロトコルも確実に適用可能である。

再び図４に示すように、物理リンク５８は、あらゆるメッセージの交換前に、信号を搬送する準備をしなくてはならない。言い換えれば、ノード５６とＢＳ６５Ａとの間の物理レイヤ、すなわちレイヤ１が、まず物理的に存在し、確立されねばならない。

一旦物理レイヤが確立されれば、すなわち、ノード５６とＰＤＳＮ６０との両方が、ＲＡＮ６２を経由して互いの相互の物理的な存在を検知すれば、ＰＤＳＮ６０は直ちにノード５６に第１のメッセージを送る。

図６は、ノード５６とＰＤＳＮ６０の間のメッセージの通信シーケンスを示すフロー図である。フロー全体の処理は、参照番号７５によって明示される。このフロー処理７５は、‘０６８特許出願に詳述されているが、以下の通り簡潔に説明する。

ＰＤＳＮ６０は、許可されたノードのネットワークアクセスをのみを受諾する。

この第１のメッセージは、ＰＤＳＮ６０によって送り出され、参照番号７６によって示される同期メッセージと呼ばれる。同期メッセージ７６は、ノード５６がそこから選択するための全ての可能な認証オプションを含んでいる。このオプションは、ＣＨＡＰ（チャレンジ認証プロトコル）の下のチャレンジメッセージ、ＰＡＰ（パスワード認証プロトコル）によって要求されるパスワード及びユーザ名に対する要求、適用可能なその他任意の認証プロトコルを含みうる。

図６に示すように、同期メッセージ７６を受け取ると、ノード５６は要求メッセージ７８で応答する。

同期メッセージ７６に記載されたような要求に応じて、ノード５６は、要求メッセージ７８の中に、必要な認証情報を含める。更にノード５６は、ノード５６がＰＤＳＮ６０を経由した次のネットワークアクセスのためのリンクの確立に必要な全てのパラメータオプションを、要求メッセージ７８に含める。関連するオプションのパラメータが、リンク構成、認証、又はネットワークアクセス制御と関連していても、いなくても違いはない。すなわち、要求メッセージ７８内において、ＰＰＰに関連して前に説明したＬＣＰ（リンク制御プロトコル）、ＣＨＡＰ（チャンレンジハンドシェイク認証プロトコル）、及びＩＰＣＰ（インターネットプロトコル制御プロトコル）のようなプロトコル要素の機能に従ってパラメータを分類する代わりに、オプションの全てのパラメータが、機能に関係なく含まれている。より具体的には、要求メッセージ７８内のオプションのパラメータは、チャレンジメッセージに対する応答、あるいは適用可能であればユーザ名及びパスワード、データグラムサイズ及びＨＤＬＣ（ハイレベルデータリンク制御）ヘッダフィールド圧縮スキームのようなリンクコンフィグレーションパラメータを、例えばＩＰアドレス、ＤＮＳ（ドメイン名システム）コンフィグレーション、及び適用可能な場合にはＩＰヘッダ圧縮プロトコル等のようなネットワークアクセス用のパラメータと同様に含むことができる。

要求メッセージ７８は、ＰＤＳＮ６０が、ノード５６及びノード６０の両方によってサポートされているオプションを選択することができるように、基本的には、選択の観点からわざと冗長にフォーマットされる。これによって、ノード５６とノード６０の両方は、レイヤ２リンクの全体を迅速に終えることが可能となる。様々な選択から、ＰＤＳＮ６０は、リンク成功の機会を高める目的で明らかにサポートされている関連オプションのパラメータを選択的に選ぶことができる。これによって、リンク時間の全体を短縮することができる。

図６に示すように、要求メッセージ７８に応答して、ＰＤＳＮ６０は応答メッセージ８０を送る。応答メッセージ８０では、ＰＤＳＮ６０は、様々な選択からオプションを選択する。応答メッセージ８０は、それらの関連する設定値とともに、選択されたパラメータオプションを含んでいる。非常に多くの場合、応答メッセージ８０は、ノード５６によるユーザデータ８２形式でのネットワークトラフィックの開始前に必要な最後のメッセージである。ネットワークアクセスの終わりでは、ノード５６又はＰＤＳＮ６０の何れか一方が、他方に対して終了要求メッセージ８４を送る。他方は、その後、終了アクノレッジメッセージ８６を送り返し、通信セッションを終了させる。

見てわかるように、既に記載したＰＰＰのような他のプロトコルと異なり、リンク処理７５は、ユーザデータ８２の開始前には、実質的に少ないメッセージ交換数を持つ。従って、リンクレイヤ、すなわちレイヤ２のリンク確立は、そのためにより速く遂行することができる。

この例では、ネットワーク４６内のＰＤＳＮ６０とユーザデータ８２を交換している最中において、ノード５６は、例えばネットワーク４８のような別のネットワークへの移動を開始するものと仮定する。この移動経路は、図４に示す参照番号８８によって示される。

このシナリオの下では、ノード５６は、基本的に、一般に「ハンドオフ」と呼ばれる処理を経る。更に詳しくは、ノード５６は、ネットワーク４６内のＲＡＮ６２を介したＰＤＳＮ６０から、ネットワーク４８内のＲＡＮ６８を介したＰＤＳＮ６６へと通信パーティを切り換える。この実施形態に従うと、ハンドオフ前にノード５６は先ず、ハンドオフのための指示を受け取る必要がある。ハンドオフのための指示は、異なるスキームで実施される様々な形式で明示することができる。

図７は、参照番号９２によって一般に示されるそのような１つのスキームを示す。図７を図４と共に参照されたい。

ハンドオフに先立ち、ノード５６が先ず、任意のネットワークアクセスより前に、ＲＡＮ６２を経由してＰＤＳＮ６０との非ＰＰＰリンクセッション９４を受けると仮定する。図示するセッション９４は、図６に示すようなリンク確立処理７５でありうる。非ＰＰＰリンク確立セッション９４は、例えば、時間ｔ１〜ｔ４継続する。

時間ｔ２では、非ＰＰＰリンクセッションの最中に、ＰＤＳＮ６０が、ＰＰＰメッセージであるＬＣＰ設定要求メッセージ９６を送り出すことが注目されるべきである。その理由は、ＰＤＳＮ６０は初めは、ノード５６が従来式のＰＰＰをサポートするのか、あるいは非ＰＰＰをサポートするのかを知らないからである。ノード５６をリンクする見込みを増加させるため、リンク確立処理７５（図６）に従う同期メッセージ７６と、ＰＰＰの下のＬＣＰ設定要求メッセージ９６との両方が送り出される。この場合、ノード５６は、リンク確立処理７５をサポートする。そのため、ネットワークインタフェースレイヤプロトコルセッション９４が、リンク確立処理７５に従って実行される。

ネットワークインタフェースレイヤプロトコルセッション９４が成功裡に確立された後、ユーザデータ８２は、その後、時間ｔ５において交換することができる。この時点において、ノード５６は、ネットワーク４６からネットワーク４８へと移動を開始すると仮定する。

ｃｄｍａ２０００規格に従って、例えばネットワーク４６，４８のような無線可能ネットワークは、自身の身元の識別のためにメッセージをコンスタントにブロードキャストする。このブロードキャストメッセージは、「システムパラメータメッセージ」の形態になり、ネットワークの順方向制御チャネルのうちの１つであるＦ−ＢＣＣＨ（順方向ブロードキャスト制御チャネル）を引き継ぐ（carried over）「拡張システムパラメータメッセージ」の形態になりうる。そのため、ノード５６のようなノードは、ネットワークからのブロードキャストメッセージを検出することにより、その行方を常に見つけ出すことができる。

システムパラメータメッセージでは、とりわけ、ＳＩＤ（システム識別情報）及びＮＩＤ（ネットワーク識別情報）を見つけることができる。ＳＩＤは、例えばネットワーク４６，４８のようなネットワークの特定の無線オペレータに割り当てられた番号である。一方、ＮＩＤは、システム４４のような通信システム内の特定のネットワークをユニークに識別する番号である。

拡張システムパラメータメッセージでは、図４に示すＢＳＣ／ＰＣＦ６４又はＢＳＣ／ＰＣＦ７０のようなＰＣＦの有効領域エリアを識別するＰＺＩＤ（パケットゾーン識別情報）を含む。システム４４のような通信システムが、ＣＤＭＡ（符号分割多元接続）ベースの無線データ技術であり、一般に１ｘ ＥＶ−ＤＯとして知られているＨＲＰＤ（高レートパケットデータ）をサポートする場合、「セクタパラメータメッセージ」と呼ばれる別のブロードキャストメッセージ内のサブネットマスク及びセクタＩＤから、ＰＺＩＤの代わりにサブネットＩＤ（識別情報）が見つけ出される。

図４及び図７に再び示すように、ノード５６がネットワーク５８の領域に到達した場合、ノード５６は、ネットワーク５８からブロードキャストメッセージを受け取ると仮定する。このブロードキャストメッセージから、新たなＮＩＤが示される。この新たなＮＩＤは、前のものとは異なる。このＮＩＤの変更によって、ノード５６は、自分が別のネットワークに移動したことを知る。この例では、ネットワーク４８は、そのレイヤ２プロトコルとして何れの非ＰＰＰをもサポートしないと仮定する。そのため、ネットワーク４８内のＰＤＳＮ６６は、ＬＣＰ設定要求メッセージ９８を送り出す。ノード５６は、この時点で、ＬＣＰ設定要求メッセージ９８に対して応答する。この理由は、ＮＩＤの変更のために、ノード５６は、新たなネットワークへのエントリを仮定できるからである。しかし、同期メッセージ７６のような非ＰＰＰメッセージは受信されない。代わりに、ＰＰＰメッセージであるＬＣＰ設定要求メッセージ９８が受信される。ノード５６は、ネットワーク４８のような新たに到来したネットワークが、従来式ではない何れのレイヤ２プロトコルをもサポートしないことを直ちに知る。これによって、ノード５６は、時間ｔ８において、ＰＰＰネゴシエーションセッション１００を経由してＰＤＳＮ６６とネゴシエートするように素早く自己を適応させる。これが成功すると、その後、図７に示すように、時間ｔ９において、ユーザデータ１０２が交換される。

ノード５６は、時間ｔ７におけるネットワーク４８からのＬＣＰ設定要求メッセージ９８に対して応答するが、時間ｔ２におけるネットワーク４６からのＬＣＰ設定要求メッセージ９６に対しては応答しないことが注目されるべきである。以前に言及したように、それは、ノード５６は、時間ｔ７の前の時間ｔ６においてＳＩＤ、ＮＩＤ、又はＰＺＩＤの変更を知るからである。

ＰＰＰネゴシエーションセッション１００の実行に成功した後、ユーザデータ１０２が確立される。ユーザデータ１０２の最後に、ノード３０又はＮＡＳ３３の何れか一方が、他方へ終了要求メッセージ１０４を送る。他方はその後、時間ｔ１０及びｔ１１において、終了Ａｃｋメッセージ１０６とともに返答し、通信セッション９２を終える。

本実施形態に従う第１のハンドオフスキームの関連ステップを図８のフローチャートに示す。

図９は、参照番号１０８によって一般に示される第２のスキームを示す。図９とともに図４を参照されたい。前述したように、ノード５６は先ず、サービス提供しているＰＤＳＮ６０を経由したネットワークアクセスの前に、リンクプロトコルセッション９４を経る。そして、ノード５６をリンクする良い機会を保証するために、前述したように、セッション９４中に、時間ｔ２において、ＬＣＰ設定要求メッセージ９６がＰＤＳＮ６０によって送られる。非ＰＰＰネットワークインタフェースレイヤプロトコルセッション９４の実行が成功すると、図９に示すように、ユーザデータ８２は時間ｔ４において交換される。また、ユーザデータ８２の流れの最中に、ノード５６が、ネットワーク４６からネットワーク４８へローミングすると仮定する。この例では、ノード５６は、ハンドオフのための指示を受信する。その指示は、前の例のものとは異なる。

特に、ノード５６がネットワーク４８の領域に到着した場合、ノード５６は、図９に示すように、時間ｔ５において別のＬＣＰ設定要求メッセージ１１０を受信する。この時、後述するように、メッセージ１１０内の異なるメッセージＩＤ（識別表示）に基づいて、ノード５６は、時間ｔ５におけるＬＣＰ設定要求メッセージ１１０の起源と、時間ｔ２におけるＬＣＰ設定要求メッセージ９６の起源とを区別することができる。

ここは、ＰＰＰメッセージのデータフレームフォーマットの説明に役立つ。

図１０は、フレーミングのようなＨＤＬＣ（高レベルデータリンク制御）を有し、ＰＰＰで使用されるデータフレームフォーマットを示す。

データパケット用のフレームテンプレートは、参照番号１１２によって一般に示される。これは、基本的には、ＰＰＰのためにＲＦＣ１６６２で指定されたようなパケットテンプレートである。更に詳しくは、データフレーム１１２は、フラグフィールド１１４、アドレスフィールド１１６、制御フィールド１１８、プロトコル番号フィールド１２０、データフィールド１２２、及びＦＣＳ（フレームチェックシーケンス）フィールド１２４を含んでいる。

ＰＰＰとの下位互換性のために、ＰＰＰを交換したいほとんどのネットワークインタフェースレイヤプロトコルはまた、ＰＰＰ用のフレームフォーマット１１２に幾分類似したフレームフォーマットで設計される。例えば、図６で示され、‘０６８特許出願で開示されたリンクプロトコル７５は、ＰＰＰのそれに類似したフレームフォーマットを採用しうる。

さて図１０に戻る。

フラグフィールド１１４は、長さ１バイトで、データパケットフレームの開始を示す。フラグフィールド１１４は常に、１６進数の値７Ｅと見なされ、ＲＦＣ１６６２によって要求されるように、リンク処理５４及びＰＰＰのために使用されるものと同じ値である。

アドレスフィールド１１６もまた、ＲＦＣ１６６２で述べられているように、長さ１バイトであり、常に１６進数の値ＦＦに設定される。

制御フィールド１１８もまたＲＦＣ１６６２で規定されているように、長さ１バイトであり、１６進数の値０３に固定される。

プロトコル番号フィールド１２０では、このフィールドにおける値は、データパケット１１２が何であるかを示す。プロトコル番号フィールド１２０は、長さ２バイトである。例えば、ＲＦＣ１６６１，１６６２で定義されているように、例えばＬＣＰ設定要求メッセージ（図２）のようなＬＣＰメッセージの各々は、１６進数の値Ｃ０２１を有する。１つのＰＰＰメッセージを、例えばＬＣＰ設定要求メッセージ及びＬＣＰ設定Ｎａｋメッセージ（図２）のような他のものと区別するために、後述するように、異なるメッセージＩＤがデータフィールド１２２に含まれる。図６に示す‘０６８特許出願で開示されたプロトコル７５のように、ＰＰＰにとって代わるために設計された他のリンクプロトコルに関し、他のＰＰＰメッセージと区別できるように、異なるプロトコル番号１２０が使用される。例えば、図６に示されるリンク処理７５では、リンク処理７５で使用される同期メッセージ７６、要求メッセージ７８、又は応答メッセージ８０（図６）は、ＰＰＰで使用されるプロトコル値の何れのものとも異なるユニークなプロトコル値を有する。そのため、データパケット１１２がＰＰＰパケットであるか非ＰＰＰパケットであるかを容易に区別することができる。

データフィールド１２２は、０バイトからそれ以上のバイトからなり、データ又は制御情報を含むペイロード長さを有する。例えば、プロトコル番号フィールド１２０の値が、データパケット１１２がＬＣＰ設定要求メッセージ９６又は１００（図９）であることを示す値を伴う場合、このデータフィールド１２２は、リンク５８又はリンク９０の確立にそれぞれ関連した不可欠な通信パラメータオプションを全て含んでいる。別の例として、プロトコル番号フィールド１２０の値が、データパケット１１２がユーザデータ８２又は１００（図９）であることを示す値を有する場合、レイヤ３から生成されたＩＰデータパケットが、データフィールド１２２へ完全にカプセル化される。

ＦＣＳフィールド１２４は長さが２バイトから４バイトまで変動し、フレーム１１２が送信中のエラーに対する基本的なプロテクトを提供するために、例えばＣＲＣ（周期的冗長符号）のような符号を含んでいる。

図９を参照されたい。前述したように、データフィールド１２２は、ＲＦＣ１６６１において「コード」と称されるメッセージＩＤを含み、例えばＬＣＰ設定要求とＬＣＰ設定Ａｃｋメッセージ（図２）とを区別するように、１つのＰＰＰメッセージタイプを他のものと区別する。例えば、ＲＦＣ１６６１において「識別子」と称されるサブＩＤを付加することにより、同一メッセージタイプでのメッセージＩＤにおいて更に区別することも可能である。例えば、図９に示す処理１０８におけるＬＣＰ設定要求メッセージ９６及びＬＣＰ設定要求メッセージ１１０は、異なるコードで実現することができる。あるいは、同じコードであるが、ネットワークにおける異なる識別子特性で実現することができる。そのため、ネットワーク４８及びネットワーク４６は、データパケット１１２のデータフィールド１２２（図１０）に埋め込まれた異なるコード又は識別子を含めることによって、別々のＬＣＰ設定メッセージ９６，１００をそれぞれ送り出すことができる。従って、この例では、ノード５６が、ネットワーク４６からネットワーク４８へ移動する場合、ネットワーク４８のものとは異なる識別子でＬＣＰ設定要求メッセージを認識することによって、ノード５６は、自分がネットワーク４８の領域内にいることを知る。

ネットワーク４８内にいる間、ノード５６は非ＰＰＰメッセージを受信しないが、代わりに、ＰＰＰメッセージであるＬＣＰ設定要求メッセージ１１０を受信し、ノード５６は、ＬＣＰ設定要求メッセージ９６のものとは異なる識別子によって、ネットワーク４８が、そのリンク確立プロトコルとして何れの非ＰＰＰもサポートしていないことを知る。ノード５６は速やかに、自己を、ＬＣＰ設定要求メッセージ１１０に対し応答するように順応する。その後、図９に示すようなＰＰＰネゴシエーション１００が実行される。この処理１０８の残りは、実質的には、前述した図７に示す処理９２に類似しているので、繰り返さない。

本実施形態に従った第２のハンドオフスキームに関連するステップは、図１１のフローチャートに示される。

代案として、バージョン／機能識別パケットを、データパケット１１２のデータフィールド１２２内に挿入することができる。３ＧＰＰ２によって発表されたｃｄｍａ２０００規格では、"Wireless EP Network Standard"と題され、３ＧＰＰ２による文書ＴＩＡ−８３５Ｄで特定されたバージョン／機能識別パケットを含めることができる。バージョン／機能識別パケットは、基本的にはベンダ特有のパケットであり、名前が意味するように、例えば図４のノード５６、あるいはＰＤＳＮ６０又は６６のようなベンダ特有のノードの関連情報を識別する。バージョン／機能識別パケットは、主に、ＰＰＰセッションのＬＣＰフェーズ中に交換される。バージョン／機能識別パケットの交換の目的は、ネゴシエートしているノードが、ネゴシエーション処理の初期において、そのバージョンと機能とを一旦特定すると、何れかのノードによってサポートされていない特性に関するＰＰＰセッション中の不必要なネゴシエーションステップを回避するためである。

一例として、図９の時間ｔ２において、ノード５６は、何れの非ＰＰＰの使用も認めない情報を含むバージョン／機能識別パケットとともにＬＣＰ設定要求メッセージ９６を受信し、もって、ノード５６は、時間ｔ３において、リンク確立のためにＰＰＰを用いることに頼らないと仮定する。その代わり、ノード５６は、時間ｔ３において、非ＰＰＰリンク確立処理９４を継続する。一方、ノード５６が時間ｔ５において、ＰＰＰの使用のみを許可する情報を有するバージョン／機能識別パケットを備えたＬＣＰ設定要求メッセージ１１０を受信すると、ノード５６は速やかに、自己を、時間ｔ６において、ＰＰＰによって目標ノード６６とネゴシエートするように順応する。

あるいは、ＬＣＰ設定要求メッセージ９６又は１００の前に、個別のバージョン／機能識別パケットが送り出されうる。従って、例えば、時間ｔ５において、目標ＰＤＳＮ６６によって２つのメッセージが送り出されるかもしれない。この第１のメッセージは、上述したように、データパケット１１２のデータフィールド１２２に含まれるベンダ特有情報を備えたバージョン／機能識別パケットである。また、第２のメッセージは、例えば、図２に示すＰＰＰセッション３４のＬＣＰネゴシエーションフェーズ３６中の第１のＬＣＰ設定要求メッセージのような、普通のＬＣＰ設定要求メッセージでありうる。

上述したようなハンドオフスキームの関連するステップを、図１１Ａのフローチャートに示す。

図１２は、参照番号１３０によって一般に示された別のハンドオフスキームを示す。図１２を図４と共に参照されたい。前述したスキームのように、ネットワーク４６にいる間、ノード５６はネットワークアクセスに先立ってＰＤＳＮ６０とリンク確立セッション９４を行う必要がある。そして、ノード５６をリンクする良い機会を保証するために、前述したように、セッション９４中に、時間ｔ２において、ＬＣＰ設定要求メッセージ９６が、ネットワーク４６内のＰＤＳＮ６０によって送られる。この時、ＬＣＰ設定要求メッセージ９６は、リンク確立セッション９４の他の非ＰＰＰメッセージの最中に送り出されることが注目されるべきである。非ＰＰＰネットワークインタフェースレイヤプロトコルセッション９４が成功すると、ユーザデータ８２が、既に記述され、図１２に示されたものと同様に時間ｔ４において交換される。また、ユーザデータ８２の交換の最中に、ノード５６が、ネットワーク４６からネットワーク４８への移動を開始すると仮定する。

ノード５６がネットワーク４８の領域に到着すると、今度は、ノード５６は、図１２に示すように、時間ｔ７において、複数のＬＣＰ設定要求メッセージ１３２Ａ〜１３２Ｎを受信する。この例では、ノード５６は、メッセージ送信パターンに基づいて、時間ｔ２におけるネットワーク４６からのＬＣＰ設定要求メッセージ９６の起源と、時間ｔ７におけるネットワーク４８からのＬＣＰ設定要求メッセージ１３２Ａ〜１３２Ｎの起源とを区別することができる。更に詳しくは、時間ｔ２において、ノード５６が、リンク確立セッション９４の他の非ＰＰＰメッセージの最中に、１つのＬＣＰ設定メッセージ９６を受信する。一方、時間ｔ７では、ノード５６は、複数のＬＣＰ設定メッセージ１３２Ａ〜１３２Ｎを受信する。

従って、ＬＣＰ設定要求メッセージの受信パターンに依存して、ノード５６は、ノード５６が現存するネットワークが、非ＰＰＰをサポートするか否かを知る。例えば、ノード５６は、連続した２つのＬＣＰ設定要求メッセージのみに応答するようにプログラムされうる。従って、この場合、時間ｔ２において、ノード５６がＬＣＰ設定要求メッセージを受信すると、ノード５６は、次の到来メッセージを待つ。次の到来メッセージが、ＬＣＰ設定要求メッセージ９６の反復ではない場合、ノード５６は、前述したように、このネットワーク４６が、ＰＰＰ以外の他の非ＰＰＰをサポートし、時間ｔ２においてＬＣＰ設定要求メッセージ９６を単に無視し、非ＰＰＰリンクセッション９４を継続することを知る。

一方、例えば、ノード５６が、時間ｔ７の間、複数の連続するＬＣＰ設定要求メッセージ１３２Ａ〜１３２Ｎを受信する場合、ノード５６は、この場合ネットワーク４８であるメッセージを送り出すネットワークが、ＰＰＰのみをサポートし、他のネットワークインタフェースレイヤプロトコルをサポートしないことを知る。図１２に示すように、ノード５６は、ＰＰＰ経由で、ネットワーク４８内のＲＡＮ６８を介して目標ＰＤＳＮ６６と通信することに頼る。この処理１３０の残りは、前述した図７及び図９にそれぞれ示す処理９２及び１０８に本質的に類似しているので、重複説明を避ける。

ノード５６によって応答されるＬＣＰ設定要求メッセージ１３２Ａ〜１３２Ｎの数は、設定可能であるべきであることが注目されるべきである。例えば、上述した例で記載したように、第２のＬＣＰ設定要求メッセージ１３２Ｂの後に、ノード５６による目標ＰＤＳＮ６６とのＰＰＰネゴシエーション１００を開始する代わりに、ノード５６は、ｉ番目のＬＣＰ設定要求メッセージ１３２ｉの後にＰＰＰネゴシエーション１００を始めることができる。ここでｉは、２〜Ｎであり、Ｎは２を越える整数である。

本実施形態に従う第３のハンドオフスキームに関連するステップが、図１３のフローチャートに示される。

図１４は、本発明の典型的な実施形態に従って、参照番号１４０で示すように、図４のノード５６のような装置のハードウェア実装の一部を概略的に示す。この装置１４０は、２〜３名前を挙げると、例えばラップトップコンピュータ、ＰＤＡ、又はセルラ電話のような様々な形態で構築され、組み込まれることが可能である。

装置１４０は、幾つかの回路を共に結合する中央データバス１４２を含む。この回路は、ＣＰＵ（中央処理装置）あるいはコントローラ１４４、受信回路１４６、送信回路１４８、及び記憶装置１５０を含む。

装置１４０が無線デバイスの一部である場合、受信回路１４６及び送信回路１４８は、ＲＦ（無線周波数）回路に接続されるが、図示していない。受信回路１４６は、受信した信号をデータバス１４２へ送り出す前に処理し、バッファする。一方、送信回路１４８は、データバス１４２からのデータを、デバイス１４０へ送り出す前に処理し、バッファする。ＣＰＵ／コントローラ１４４は、データバス１４２のデータ管理の機能と、更に、一般的なデータ処理の機能とを実行する。これは、記憶装置１５０の命令コンテンツの実行を含む。

図１４に示すように、個別に配置されるのではなく、その代わりに、送信回路１４８と受信回路１４６とは、ＣＰＵ／コントローラ１４４の一部ともなりえる。

記憶装置１５０は、参照番号１５２によって一般に示される１セットの命令を含んでいる。この実施形態では、これら命令は、プロトコルスタック機能１５４、リンク確立クライアント１５６、リンクハンドオフ機能１５８、及びＰＰＰ機能１６０のような部分を含んでいる。プロトコルスタック機能１５４は、図５に示し説明したスタック７４に類似したプロトコルスタックを実行する。リンク確立クライアント１５６は、図７、図９、及び図１２に示した処理９４のように、ＰＰＰリンク処理以外の１又は複数のリンク処理を確立するための命令設定を含む。ＰＰＰ機能１６０は、装置１４０がＰＰＰ処理を実行できるようにするための命令セットを含む。リンクハンドオフ機能１５８は、関連する図７〜１３で記述し示した処理９２，１０８，１３０のようなハンドオフ処理を実行するための命令セットを含む。ＰＰＰ機能１６０は、ＰＰＰリンク処理又は非ＰＰＰリンク処理の両方をサポートするネットワークのために独立して使用することができる。あるいは、ネットワークが、他の非ＰＰＰリンク処理をサポートしない事象における備え（fallback）として使用することができる。

本実施形態では、記憶装置１５０はＲＡＭ（ランダムアクセスメモリ）回路である。典型的な命令部分１５４，１５６，１５８及び１６０は、ソフトウェアルーチン又はモジュールである。記憶装置１５０は、揮発性又は不揮発性の何れかのタイプになりえる他のメモリ回路（図示せず）と結合することができる。代案として、記憶装置１５０は、例えば、ＥＥＰＲＯＭ（電気的消去可能プログラム可能読取専用メモリ）、ＥＰＲＯＭ（電気的プログラム可能読取専用メモリ）、ＲＯＭ（読取専用メモリ）、ＡＳＩＣ（特定用途向けＩＣ）、磁気ディスク、光ディスク、及び当該技術で周知な他のもののような他の回路で構成されうる。

図７乃至１３，１５及び１６で示し説明した処理９２，１０８，１３０はまた、当該技術で周知の任意のコンピュータ読取可能媒体で実行されるコンピュータ読取可能命令としてコード化されうることが更に注目されるべきである。本明細書及び特許請求の範囲において、用語「コンピュータ読取可能媒体」は、実行のために、例えば図１４で示し説明したＣＰＵ／コントローラ１４４のような任意のプロセッサに対して命令を提供することに資する任意の媒体を称する。そのような媒体はストレージタイプでもよく、例えば図１４の記憶装置１５０として説明したような揮発性又は非揮発性のストレージ媒体の形式をとりうる。そのような媒体は更に、伝送タイプでもよく、計算機又はコンピュータによって読取可能な信号を搬送することができる音響波又は電磁波を搬送するエアインタフェース、光ケーブル、銅線、同軸ケーブルを含みうる。

最後に、実施形態に記載したように、ハンドオフ手順は、ユーザデータ８２の交換の最中に実施されるとして示されている（例えば、図７，９及び１２参照）。しかし、これは、そうである必要はない。ノード５６が、ネットワークインタフェースレイヤプロトコルセッション９４を確立している最中にハンドオフが起こることがありえる。図１５は、そのようなシナリオを示しており、ここでは、図７に示し説明したようなリンク処理９２が強調され、関連する幾つかのステップが、説明のために繰り返される。図示するように、時間ｔ４では、リンク確立処理９４が完了する前に、ノード５６はネットワーク４８へ移動している過程にあり、時間ｔ４において、ＳＩＤ、ＮＩＤ、ＰＺＩＤ、又はサブネットＩＤの変化を検知する。そのため、ノード５６は、移動中に、ネットワーク４６内のＰＤＳＮ６０からの応答メッセージ８０を受信しない恐れがある。しかしながら、ノード５６が時間ｔ５においてＬＣＰ設定要求メッセージ９８を受信した場合、ノード５６は、自分がネットワーク４８の領域内にいて、上述したものと同様な方法によってＰＰＰネゴシエーション処理１００を直ちに開始して良いことを知る。更に、同じことは、図９及び図１２に示し説明した処理１０８及び処理１３０に対してもそれぞれ当てはまる。すなわち、本発明の典型的な実施形態に従ったこのハンドオフ処理は、ユーザデータの交換中にのみ起こる必要は必ずしもない。更に、システム４４は、ｃｄｍａ２０００規格をサポートするものとして記載された。しかしながら、他の規格にも明らかに適用可能である。他の規格の一例は、３ＧＰＰ（第三世代パートナシッププロジェクト）によって発行されたＷＣＤＭＡ（広帯域符号分割多元接続）である。更に、典型的な実施形態では、レイヤ３プロトコルは、ＩＰとして記載されている。ＩＰは、例えばＩＰｖ４（インターネットプロトコルバージョン４）及びＩＰｖ６（インターネットプロトコルバージョン６）のような異なるバージョンからなりうる。更に、他のレイヤ３プロトコルもまた等しく適用可能であることが注目されるべきである。例えば、レイヤ３プロトコルは、ＩＰＸ（インターネットワーキングパケット交換プロトコル）、アップルトーク、及び別バージョンからなる様々な他のネットワークプロトコルになりえる。更に、本実施形態に関して記載された何れの論理ブロック、回路、及びアルゴリズムステップも、ハードウェア、ソフトウェア、ファームウェア、又はこれらの組み合わせとして実現することが可能である。形式及び詳細におけるこれらの変更及びその他の変更は、本発明の範囲及び精神から逸脱することなくなされうることが当業者によって理解されるであろう。

Claims (55)

1. 通信システムにおけるサービス提供ノードから目標ノードへのハンドオフのための方法であって、
   第１のネットワークインタフェースレイヤプロトコルによって前記サービス提供ノードにアクセスすることと、
   前記ハンドオフのための指示を受信することと、
   第２のネットワークインターフェースレイヤプロトコルによって前記目標ノードにアクセスすることと
   を含む方法。
2. 前記指示を受信することは、前記目標ノードを識別する識別情報を有するメッセージを受信することを含む請求項１の方法。
3. 前記指示を受信することは、前記目標ノードを識別するメッセージ識別情報をデータパケットのデータフィールド内に有するデータパケットを受信することを含む請求項１の方法。
4. 前記指示を受信することは、前記目標ノードを識別するバージョン／機能識別パケットをデータパケットのデータフィールド内に有するデータパケットを受信することを含む請求項１の方法。
5. 前記指示を受信することは、前記第２のネットワークインタフェースレイヤプロトコルの複数の要求メッセージを前記目標ノードから受信することを含む請求項１の方法。
6. 前記サービス提供ノードにアクセスすることの後に、前記サービス提供ノードとユーザデータを交換することを更に含み、前記ハンドオフのための指示は、前記ユーザデータの交換中に受信される請求項１の方法。
7. 前記ハンドオフのための指示は、前記第１のネットワークインタフェースレイヤプロトコルによって前記サービス提供ノードにアクセスしている最中に受信される請求項１の方法。
8. 前記第１のネットワークインタフェースレイヤプロトコルによって前記サービス提供ノードにアクセスすることは、認証、リンク設定、及びネットワークアクセスのためのパラメータオプションのセットを１つのメッセージで前記サービス提供ノードに提供することを含む請求項１の方法。
9. ＩＰ（インターネットプロトコル）をサポートする通信システムにおける第１のノードから第２のノードへのハンドオフの方法であって、
   ＰＰＰ（ポイントトゥポイントプロトコル）以外のネットワークインタフェースレイヤプロトコルによって前記第１のノードにアクセスすることと、
   前記ハンドオフのための指示を受信することと、
   前記ＰＰＰによって前記第２のノードにアクセスすることと
   を含む方法。
10. 前記ＰＰＰ以外のネットワークインタフェースレイヤプロトコルによって前記第１のノードにアクセスすることは、認証、リンク設定、及びネットワークアクセスのためのパラメータオプションのセットをメッセージで前記第２のノードに提供することを含む請求項９の方法。
11. 前記指示を受信することは、前記第２のノードを識別するメッセージ識別情報を有するメッセージを受信することを含み、前記メッセージ識別情報は、前記第２のノードに関連するＮＩＤ（Network Identification：ネットワーク識別情報）、ＳＩＤ（System Identification：システム識別情報）、ＰＺＩＤ（Packet Zone Identification：パケットゾーン識別情報）、及びサブネットＩＤ（Subnet Identification：サブネット識別情報）からなるグループから選択される請求項９の方法。
12. 前記指示を受信することは、データパケットのデータフィールド内に含まれ、前記第２のノードを識別する符号又は識別子を有するデータパケットを受信することを含む請求項９の方法。
13. 前記指示を受信することは、データパケットのデータフィールド内に含まれ、前記第２のノードを識別するバージョン／機能識別パケットを有するデータパケットを受信することを含む請求項９の方法。
14. 前記指示を受信することは、前記ＰＰＰの複数のＬＣＰ（リンク制御プロトコル）設定要求メッセージを前記第２のノードから受信することを含む請求項９の方法。
15. 通信システムにおける装置であって、
    第１のネットワークインタフェースレイヤプロトコルによってサービス提供ノードにアクセスする手段と、
    ハンドオフのための指示を受信する手段と、
    第２のネットワークインターフェースレイヤプロトコルによって目標ノードにアクセスする手段と
    を備える装置。
16. 前記指示は、前記目標ノードを識別する識別情報を含む請求項１５の装置。
17. 前記指示は、前記目標ノードを識別するメッセージ識別情報を、データパケットのデータフィールド内に含む請求項１５の装置。
18. 前記指示は、前記目標ノードを識別するバージョン／機能識別パケットを、データパケットのデータフィールド内に含む請求項１５の装置。
19. 前記指示は、前記目標ノードからの、前記第２のネットワークインタフェースレイヤプロトコルの複数の要求メッセージを含む請求項１５の装置。
20. 前記サービス提供ノードにアクセスする手段は、認証、リンク設定、及びネットワークアクセスのためのパラメータオプションのセットを１つのメッセージで前記サービス提供ノードに提供する手段を含む請求項１５の装置。
21. ＩＰ（インターネットプロトコル）をサポートする通信システムにおける装置であって、
    ＰＰＰ（ポイントトゥポイントプロトコル）以外のネットワークインタフェースレイヤプロトコルによって第１のノードにアクセスする手段と、
    ハンドオフのための指示を受信する手段と、
    前記ＰＰＰによって第２のノードにアクセスする手段と
    を備える装置。
22. 前記第１のノードにアクセスする手段は、認証、リンク設定、及びネットワークアクセスのためのパラメータオプションのセットをメッセージによって前記第２のノードに提供する手段を含む請求項２１の装置。
23. 前記指示は、前記第２のノードを識別するメッセージ識別情報を有するメッセージを含み、前記メッセージ識別情報は、前記第２のノードに関連するＮＩＤ（Network Identification：ネットワーク識別情報）、ＳＩＤ（System Identification：システム識別情報）、ＰＺＩＤ（Packet Zone Identification：パケットゾーン識別情報）、及びサブネットＩＤ（Subnet Identification：サブネット識別情報）からなるグループから選択される請求項２１の装置。
24. 前記指示は、データパケットのデータフィールド内に含まれ、前記第２のノードを識別する符号又は識別子を有するデータパケットを含む請求項２１の装置。
25. 前記指示は、データパケットのデータフィールド内に含まれ、前記第２のノードを識別するバージョン／機能識別パケットを有するデータパケットを含む請求項２１の装置。
26. 前記指示は、前記第２のノードからの、前記ＰＰＰの複数のＬＣＰ（リンク制御プロトコル）設定要求メッセージを含む請求項２１の装置。
27. 通信システムにおける装置であって、
    第１のネットワークインタフェースレイヤプロトコルによって前記通信システムのサービス提供ノードにアクセスし、
    ハンドオフのための指示を受信し、
    第２のネットワークインターフェースレイヤプロトコルによって前記通信システムの目標ノードにアクセスする
    ためのコンピュータ読取可能命令を含むメモリユニットと、
    前記メモリユニットに接続され、前記コンピュータ読取可能命令を処理するプロセッサ回路と
    を備える装置。
28. 前記指示は、前記目標ノードを識別する識別情報を有するメッセージを含む請求項２７の装置。
29. 前記指示は、前記目標ノードを識別するメッセージ識別情報を、データパケットのデータフィールド内に有するデータパケットを含む請求項２７の装置。
30. 前記指示は、前記目標ノードを識別するバージョン／機能識別パケットを、データパケットのデータフィールド内に有するデータパケットを含む請求項２７の装置。
31. 前記指示は、前記目標ノードからの、前記第２のネットワークインタフェースレイヤプロトコルの複数の要求メッセージを含む請求項２７の装置。
32. 前記メモリユニットは、前記サービス提供ノードにアクセスすることの後に、前記サービス提供ノードとユーザデータを交換し、前記ユーザデータの交換中に前記指示が受信されている間に、前記ハンドオフを開始するためのコンピュータ読取可能命令を更に含む請求項２７の装置。
33. 前記メモリユニットは、前記第１のネットワークインタフェースレイヤプロトコルによる前記サービス提供ノードへのアクセス中に前記指示が受信されている間に、前記ハンドオフを開始するためのコンピュータ読取可能命令を更に含む請求項２７の装置。
34. 欠番。
35. 前記メモリユニットは、前記サービス提供ノードにアクセスしている間に、認証、リンク設定、及びネットワークアクセスのためのパラメータオプションのセットをメッセージで提供するためのコンピュータ読取可能命令を更に含む請求項２７の装置。
36. ＩＰ（インターネットプロトコル）をサポートする通信システムにおける装置であって、
    ＰＰＰ（ポイントトゥポイントプロトコル）以外のネットワークインタフェースレイヤプロトコルによって第１のノードにアクセスし、
    ハンドオフのための指示を受信し、
    前記ＰＰＰによって第２のノードにアクセスする
    ためのコンピュータ読取可能媒体を含むメモリユニットと、
    前記メモリユニットに接続され、前記コンピュータ読取可能媒体を処理するプロセッサ回路と、
    を備える装置。
37. 前記メモリユニットは、認証、リンク設定、及びネットワークアクセスのためのパラメータオプションのセットをメッセージで前記アクセス中に前記第２のノードへ提供するためのコンピュータ読取可能命令を更に含む請求項３６の装置。
38. 前記指示は、前記第２のノードを識別するメッセージ識別情報を有するメッセージを含み、前記メッセージ識別情報は、前記第２のノードに関連するＮＩＤ（Network Identification：ネットワーク識別）、ＳＩＤ（System Identification：システム識別）、ＰＺＩＤ（Packet Zone Identification：パケットゾーン識別）、及びサブネットＩＤ（Subnet Identification：サブネット識別）からなるグループから選択される請求項３６の装置。
39. 前記指示は、データパケットのデータフィールド内に含まれ、前記第２のノードを識別する符号又は識別子を有するデータパケットを受信することを含む請求項３６の装置。
40. 前記指示は、データパケットのデータフィールド内に含まれ、前記第２のノードを識別するバージョン／機能識別パケットを有するデータパケットを含む請求項３６の装置。
41. 前記指示は、前記ＰＰＰの複数のＬＣＰ（リンク制御プロトコル）設定要求メッセージを前記第２のノードから受信することを含む請求項３６の装置。
42. 第１のネットワークインタフェースレイヤプロトコルによってサービス提供ノードにアクセスし、
    ハンドオフのための指示を受信し、
    第２のネットワークインターフェースレイヤプロトコルによって目標ノードにアクセスする
    ためのコンピュータ読取可能命令を含むコンピュータ読取可能媒体。
43. 前記指示は、前記目標ノードを識別するメッセージ識別情報を有するメッセージを含む請求項４２のコンピュータ読取可能媒体。
44. 前記指示は、前記目標ノードを識別するメッセージ識別情報を、データパケットのデータフィールド内に有するデータパケットを含む請求項４２のコンピュータ読取可能媒体。
45. 前記指示は、前記目標ノードを識別するバージョン／機能識別パケットを、データパケットのデータフィールド内に有するデータパケットを含む請求項４２のコンピュータ読取可能媒体。
46. 前記指示は、前記目標ノードからの、前記第２のネットワークインタフェースレイヤプロトコルの複数の要求メッセージを含む請求項４２のコンピュータ読取可能媒体。
47. 前記サービス提供ノードにアクセスすることの後に、前記サービス提供ノードとユーザデータを交換し、
    前記ユーザデータの交換中に前記指示が受信されている間に、前記ハンドオフを開始する
    ためのコンピュータ読取可能命令を更に含む請求項４２のコンピュータ読取可能媒体。
48. 前記第１のネットワークインタフェースレイヤプロトコルによる前記サービス提供ノードへのアクセス中に前記指示が受信されている間に、前記ハンドオフを開始するためのコンピュータ読取可能媒体を更に含む請求項４２のコンピュータ読取可能媒体。
49. 前記サービス提供ノードにアクセスしている間に、認証、リンク設定、及びネットワークアクセスのためのパラメータオプションのセットを１つのメッセージで提供するためのコンピュータ読取可能命令を更に含む請求項４２のコンピュータ読取可能媒体。
50. ＰＰＰ（ポイントトゥポイントプロトコル）以外のネットワークインタフェースレイヤプロトコルによって第１のノードにアクセスし、
    ハンドオフのための指示を受信し、
    前記ＰＰＰによって第２のノードにアクセスする
    ためのコンピュータ読取可能命令を含むコンピュータ読取可能媒体。
51. 前記第２のノードにアクセスしている間に、認証、リンク設定、及びネットワークアクセスのためのパラメータオプションのセットをメッセージで提供するためのコンピュータ読取可能命令を更に含む請求項５０のコンピュータ読取可能媒体。
52. 前記指示は、前記第２のノードを識別するメッセージ識別情報を有するメッセージを含み、前記メッセージ識別情報は、前記第２のノードに関連するＮＩＤ（Network Identification：ネットワーク識別）、ＳＩＤ（System Identification：システム識別）、ＰＺＩＤ（Packet Zone Identification：パケットゾーン識別）、及びサブネットＩＤ（Subnet Identification：サブネット識別）からなるグループから選択される請求項５０のコンピュータ読取可能媒体。
53. 前記指示は、データパケットのデータフィールド内に含まれ、前記第２のノードを識別する符号又は識別子を有するデータパケットを含む請求項５０のコンピュータ読取可能媒体。
54. 前記指示は、データパケットのデータフィールド内に含まれ、前記第２のノードを識別するバージョン／機能識別パケットを有するデータパケットを含む請求項５０のコンピュータ読取可能媒体。
55. 前記指示は、前記第２のノードからの、前記ＰＰＰの複数のＬＣＰ（リンク制御プロトコル）設定要求メッセージを含む請求項５０のコンピュータ読取可能媒体。

Images