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

ネットワーク・アクセスのための早いリンク確立 Download PDF

Info

Publication number
JP2008508813A
JP2008508813A JP2007523860A JP2007523860A JP2008508813A JP 2008508813 A JP2008508813 A JP 2008508813A JP 2007523860 A JP2007523860 A JP 2007523860A JP 2007523860 A JP2007523860 A JP 2007523860A JP 2008508813 A JP2008508813 A JP 2008508813A
Authority
JP
Japan
Prior art keywords
message
node
network access
parameter options
authentication
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2007523860A
Other languages
English (en)
Other versions
JP4625081B2 (ja
Inventor
リオイ、マルセロ
ワン、ジュン
雅一 城田
シュ、レイモンド・ター−シェン
ビーレパリ、シバラマクリシュナ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Publication of JP2008508813A publication Critical patent/JP2008508813A/ja
Application granted granted Critical
Publication of JP4625081B2 publication Critical patent/JP4625081B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40Support for services or applications
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/16Implementing security features at a particular protocol layer
    • H04L63/162Implementing security features at a particular protocol layer at the data link layer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/14Session management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/324Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)
  • Communication Control (AREA)

Abstract

【課題】ネットワーク・アクセスのための早いリンク設定。
【解決手段】ネットワーク・アクセスを得ようとしているノードとNAS(Network Access Server)との間の通信セッションは、2,3のメッセージ交換だけを行うことによって設定される。ノードとNASとの間に物理リンクが検出されると、NASは、すぐに認証要請メッセージをノードに送る。応答して、ノードは、要請メッセージを送る。それは認証要請メッセージに応答することに加えて、リンク設定及びネットワーク・アクセス制御のための全てのパラメータ・オプションを含む。NASは、その後、パラメータ・オプションを取り出しそして選択する、そしてノードに回答メッセージの中で選択されたオプションを送り返す。回答メッセージ中の選択されたオプションがしきい値を満たすのであれば、ノードは、NASを介してネットワーク・アクセスのためのユーザ・データを直接伝送する。
【選択図】図5

Description

特許に関する本出願は、米国特許仮出願番号第60/592,470号、名称“早いパケット・データ・セッション確立のための方法及び装置(Method and Apparatus for Fast Packet Data Session Establishment)”、2004年7月30日出願、に優先権を主張し、本発明の譲受人に譲渡されそして本明細書中に引用によって特に取り込まれている。
本発明は、一般にパケット・データ通信に係り、そして特に、ネットワーク・アクセスのためにパケット・データ通信を確立する前の初期通信セッションに関する。
ネットワークを相互接続することは、情報が地理的な距離に無関係に迅速にアクセスされることをグローバルに可能にする。図1は、ネットワークのグローバルな接続の単純化した概要図を示し、インターネットとして一般的に呼ばれ参照番号20によって表示される。インターネット20は、本質において一緒にリンクされた異なるレベルの階層を有する複数のネットワークである。インターネット20は、IETF(Internet Engineering Task Force:インターネット技術タスク・フォース)によって公表されたIP(Internet Protocol;インターネット・プロトコル)の下で管理される。IPの詳細は、IETFによって発行されたRFC(Request for Comments:コメントの要請)791の中に見出されることができる。
インターネット20に接続されたものは、各種のそれぞれのネットワークであり、ネットワークのサイズに応じてLAN(Local Area Network:ローカル・エリア・ネットワーク)又はWAN(Wide Area Network:広域ネットワーク)と時に呼ばれる。図1に示されたものは、複数のそのようなネットワーク22,24及び26である。
各々のネットワーク22,24及び26の内部に、互いに接続されそして通信している装置の種々の部品がある。例は、少しだけ名前を上げると、コンピュータ、プリンタ、及びサーバであり、それらは一般にノードと呼ばれる。ノードがインターネット20を介して自分自身のネットワークを超えて通信する場合に、IPアドレスがノードに対して指定される必要がある。IPアドレスの指定は、手動で又は自動であり得る。IPアドレスの手動の指定は、例えば、ネットワーク管理者によって実行されることができる。より頻繁に、IPアドレスは、例えば、LAN内の専用のサーバによって自動的に指定される。
説明のために一例を挙げる。ネットワーク22内のノード30がネットワーク24内の別の1つのノード34’にデータ・パケットを送ろうと試みと仮定する。IPの下で、各データ・パケットは、ソース・アドレス及び宛て先アドレスを有することを必要とする。このケースでは、ソース・アドレスは、ネットワーク22内のノード30のアドレスである。宛て先アドレスは、ネットワーク24内のノード34’のアドレスである。
非常に頻繁に、ノードからノードへの通信は、インターネット20のような、ネットワーク・アクセスの前に要求される。例えば、ネットワーク22内のノード30が、ラップトップ・コンピュータであると仮定する。ラップトップ・コンピュータ・ノード30は、ネットワーク22に直接アクセスを持たない。それにも拘らず、ラップトップ・コンピュータ・ノード30は、例えば、電話回線を経由して有線モデムをダイアル呼び出しすることによるような、ある種の別の手段を介してネットワーク22内のNAS(Network Access Server:ネットワーク・アクセス・サーバ)32に連絡できる。そのケースでは、ノード30は、一般的にネットワーク22内のNAS(ネットワーク・アクセス・サーバ)32とPPP(Point-to-Point Protocol:2点間プロトコル)セッションを確立する。ノード30とネットワーク22との間でその後に確立される又はインターネット20を介していずれかの別のネットワークとの間でその後に確立されるパケット・データ通信は、有線モデム及び電話回線を経由して交換されることができる。もし、モデムが電話回線を経由して信号をシリアルにそして非同期的に伝送しそして受け取るのであれば、電話回線を介して交換されたデータ・パケットは、同様にフレーム化される必要があり、それに応じてシリアルなそして非同期的なモデム・リンクに適応する。
無線技術の到来は、ノードが最初に登録したネットワークから別の1つのネットワークに動いて離れることを可能にする。例えば、図1に戻って参照して、ネットワーク22に恒久的に配線される代わりに、ノード30は、PDA(Personal Device Assistant:個人デバイス・アシスタント)、セルラ電話機、又は携帯型コンピュータのような、無線デバイスであり得る。無線ノード30は、自身のホーム・ネットワーク22の境界を越えて移動できる。したがって、ノード30は、ホーム・ネットワーク22から他のネットワーク26に移動して離れることができる。ネットワーク26のアクセスを得るために、又はインターネット20を介して別のネットワークに接続されるようにするために、ノード30は、同様に、ネットワーク26内のNAS(ネットワーク・アクセス・サーバ)33とPPPセッションを一般的に確立する。このケースでは、ノード30とNAS33との間の通信は、無線リンクを経由する。再び、ノード30と無線ネットワークとの間で交換されるデータ・パケットは、そのうえ、あるフォーマットに適するようにフレーム化される必要があり、そのフォーマットは、無線リンクを介してノード30とNAS33との間でPPPセッションのあいだに取り決められる。
PPPの大部分は、IETFによって発行されたRFC1661及び1662に中に記載されている。PPPは、ピアー・トゥ・ピアー・プロトコルであり、その中では2つのノードはピアー(peer:同等)である。すなわち、いずれのパーティもクライアントでもないしサーバでもない。どちらのパーティも他のものからのアクションを要請できる又は他のものにアクションを実行できる。本質的に、PPPは、複数のノード間の予備的なそして取り決めを行うセッションであり、そのセッションの間に、そのノードは、いずれかのネットワーク・トラフィック・フローの前に、能力及び利用可能性に関して互いのリソースを見つけ出し、そして最終的に相互に受け入れることができるパラメータ・オプションのセットに対する適用範囲を見つけ出す。
図2は、具体例のPPP通信セッション34のシーケンス・フロー図を示し、そこでは、ネットワーク26内のノード30がインターネット20へのアクセスを得るためにNAS32とのリンクを確立しようとしている。
PPPは、複数のプロトコル構成要素を有する。図2に示された具体例のPPPセッションでは、PPPは、構成要素としてLCP(Link Control Protocol:リンク制御プロトコル)36、CHAP(Challenge/Handshake Authentication Protocol:チャレンジ(呼び出し)/ハンドシェーク認証プロトコル)38、及びIPCP(Internet Protocol Configuration Protocol:インターネット・プロトコル設定プロトコル)40を有する。
先ず、物理リンクの完了で、すなわち、ノード30及びNAS33は、ハードウェア・レベルで互いに連絡を取ることができる、例えば、LCP36を全部行う必要がある。LCP36は、ノード30とNAS33との間の基本的な通信リンクを確立する目的で機能する。LCP36の間に、ノード30とNAS33は、必須の通信パラメータ・オプションを互いに交換しそして取り決める。このオプションは、リンクを経由するデータ・パケットの最大サイズ、品質制御に関係するパラメータ、使用するHDLC(High Level Data Link Control:高レベル・データ・リンク制御)ヘッダ・フィールド圧縮体系、及びピアーが認証されることを望んでいるかどうか、を含むことができる。
LCP36に関するプロセスは、ハンドシェークの方式の下で多かれ少なかれ実行される。最初に、要請するパーティは、Configure Request(設定要請)メッセージを送ることによって1又はそれより多くのパラメータを提案する。もし、いずれかのパラメータが受け取るパーティによって認識されなければ、受け取るパーティは、Configure Reject(設定拒絶)メッセージを応答して返す。もし、拒絶されたパラメータが得ようとしているリンクに対して致命的であれば、要請しているパーティは、その時は、PPPセッションを終了させなければならない。
一方で、もしパラメータが認識されるが、パラメータに関係するオプションが受け入れ可能でなければ、応答しているパーティは、Configure Nak(設定否定的受領通知)メッセージを送り返す。要請しているパーティは、再びPPPセッションを終了させるか、又は同じパラメータに関する別のオプションを有する別の1つのConfigure Requestメッセージを送るかのどちらかをすることができる。
前に述べたように、PPPは、ピアー・トゥ・ピアー・プロトコルである。ノード30又はNAS33のどちらかは、要請しているパーティであり得る。同じことが応答しているパーティの役割についてもあてはまる。関係するオプションを有する全てのパラメータは、上記した様な方法で取り決められる必要がありそして決定される必要がある。取り決めの複数のラウンドが、図2に示されたように要求されることがある。全体の取り決め体系は、基本的に単純なプロセスである。もし、要請しているパーティが必要としているパラメータの全てが応答しているパーティにとって受け入れられる必要があれば、要請しているパーティは、応答しているパーティに最終的なConfigure Ack(設定受領通知)メッセージを送る。一旦、両方のパーティが、Configure Ackメッセージを送ると、それらは、認証段階に移行する。
パーティが認可されることを確実にするために、認証が実施される必要がある。認証を実行する1つの方法は、別のPPP構成要素CHAP38を使用することである。CHAP38を開始するNAS33がノード30の身元を検証することが、一般的である。CHAP38の間に、NAS33は、チャレンジ・メッセージと呼ばれるメッセージをノード30に送る。CHAPの下で、チャレンジ・メッセージとともに使用される共有の秘密事項があり、それは事前に合意されたアルゴリズムを使用して応答メッセージを計算するために使用される。ノード30は、その後、秘密アルゴリズムにより発生された応答メッセージをNAS33に送る。NAS33は、その後で、NAS33自身により計算されたメッセージと受け取った応答メッセージを比較する。もし、比較が一致すれば、ノード30は、CHAP38を通過するといわれ、そこでは、NAS33は、CHAP Success(成功)メッセージをノード30に送る。そうでなければ、CHAP Failure(失敗)メッセージがNAS33によって送られる。
あるいは、CHAP38の代わりに、認証は、PAP(Password Authentication Protocol:パスワード認証プロトコル)を通ることによって実現されることができる。PAPでは、ノードは、検証のためにユーザネームとパスワードをNAS33に単に送るだけである。もし検証されるのであれば、ノード30はPAPを通ったと言われる。
もしノード30がIPアクセスを必要とするのであれば、IPに関係する情報は、再び交換されそして取り決められる必要がある。例えば、他のものの中で、ノード30は、IPにしたがってインターネット20(図1)をアクセスするためにIPアドレスの指定を受ける必要であり得る。この目的を達成するために、IPCP40の下でパラメータ・オプションの取り決め及び交換を開始する。具体例のPPPセッション34では、ノード30は、最初にNAS33からIPアドレス0.0.0.0を要請する。応答では、NAS33は、Configure Nakメッセージを送り、ノード30がIPアドレスa.b.c.dを使用することを提案する。もし受理されるのであれば、ノード30は、受領通知の代わりに別の1つのメッセージをNAS33に送ることによってIPアドレスa.b.c.dの使用を確認する。
最終的に、ノード30がIPCP40の間に取り決められた全てのパラメータに同意する場合に、ノード30は、受領通知メッセージをNAS33に送る。ネットワーク・アクセス・セッションのユーザ・データは、その後で交換される。ネットワーク・トラフィックのIPデータ・パケットは、パラメータとともにPPPフレームの中にカプセル化されそして前のLCP36の間に取り決められる。
ネットワーク・アクセスの終わりに、ノード30又はNAS33のいずれかは、他のものにTerminate Request(終了要請)メッセージを送ることができる、それは、その後で、Terminate Ack(終了受領通知)メッセージを用いて応答して返されそして通信セッションを終わらせる。
図2に見られそして上に説明されたように、PPPセッション34の間にノード30とNAS33との間で交換される非常に多くのメッセージがある。その意味で、かなりの時間の期間が含まれている。もしPPPセッション34が高データ遅延の遅いリンクを介して取り決められるのであれば、これは特に本質的である。
したがって、いずれかの次のレベルのデータ・トラフィックの前に初期通信リンクを確立するより早くそしてより効率的な方法を提供する必要性がある。
RFC791、IETF発行 RFC1661、IETF発行 RFC1662、IETF発行
[サマリー]
ネットワーク・アクセスを得ようとしているノードとNAS(Network Access Server)との間の通信セッションは、2,3のメッセージだけの交換を行うことによって確立される。最初に、ノードとNASとの間に物理リンクを設定するとともに、NASは、すぐに認証要請メッセージをノードに送る。応答して、ノードは、認証応答に加えてリンク設定及びネットワーク・アクセス制御のための全ての他のパラメータ・オプションを含む要請メッセージを送る。NASは、その後、多数のものの中からパラメータ・オプションのセットを取り出しそして選択する、そしてその後で、回答メッセージの中で選択されたオプションをノードに送り返す。もし回答メッセージ中で選択されたオプションがしきい値を満足するのであれば、ノードは、NASを介してネットワーク・アクセスのためのユーザ・データを直接伝送する。
その上、フェール・オーバー・フィーチャ(fail-over feature)が、与えられることがあり、そこでは本発明の具体例の実施形態にしたがった通信セッションが確立され得ないのであれば、従来のPPP(2点間プロトコル)は、通信セッションを継続するために肩代わりできる。
本発明の1態様にしたがえば、開示されたものは、その中でノードがネットワーク・アクセスを得ようとしている方法、装置、及び媒体であり、メッセージ中に認証、リンク設定、及びネットワーク・アクセスのためのパラメータ・オプションのセットを与えるため、及びネットワーク・アクセス・ノードにメッセージを送るための工程又は手段を具備する。
本発明の別の1態様にしたがえば、開示されたものは、ネットワーク・アクセス・ノードのための別の1つの方法、装置、及び媒体であり、認証、リンク設定、及びネットワーク・アクセスのためのパラメータ・オプションのセットを含んでいるメッセージをネットワーク・アクセスを得ようとしているノードから受け取るため、及びパラメータ・オプションのセットの認可に関係する別の1つのメッセージをネットワーク・アクセスを得ようとしているノードに送るための工程又は手段を具備する。
これらの特徴及び他の特徴並びに利点は、添付した図面を考慮して以下の詳細な説明から当業者に明確になるであろう。図面では、類似の参照番号は、類似の部分を呼ぶ。
[詳細な説明]
以下の説明は、この技術に知識のあるいかなる者でも本発明を製作しそして使用することを可能にするために提示される。詳細は、説明の目的で以下の説明において述べられる。本発明がこれらの具体的な詳細を使用せずに実行され得ることを、当業者が理解するはずであることは、評価されるはずである。別の例では、周知の構造及びプロセスは、不必要な詳細で本発明の記載を不明瞭にしないために詳細に説明されない。それゆえ、本発明は、示された実施形態によって限定されるように意図されるのではなく、本明細書中に開示された原理及び特徴と整合する最も広い範囲に一致される。
図3は、本発明の具体例の実施形態に含まれるノードの単純化した概要図である。全体の通信システムは、参照番号42によって示される。この実施形態では、通信システム42は、バックボーン・ネットワーク50に接続されたネットワーク48を含み、バックボーン・ネットワーク50はイントラネット又はインターネットであり得る。ネットワーク48内に配置されたものは、ネットワーク・アクセスを得ようとしている任意のノードとネットワーク48との間のゲートウェイとして機能するNAS(Network Access Server:ネットワーク・アクセス・サーバ)である。システム42内で想定すると、バックボーン・ネットワーク50を介してネットワーク48又は他のネットワーク(図示されず)のいずれかについてのアクセスを探しているそのようなノード44がある。ノード44は、通信リンク45を経由してNAS46と通信する。
リンク44は、様々な形式をとるリンクであり得る。例えば、リンク44は、少しだけ名前をあげると、従来の電話線回路、同軸ケーブル・リンク、又は光ケーブル・リンクのような有線リンクであり得る。その上に、リンク45は、同様に無線リンクであり得る。そのケースでは、リンク45は、無線インターフェースである。
リンク45が無線インターフェースであると、この実施形態では仮定する。ノード44は、NAS46と無線で通信する移動デバイスである。ネットワーク48は、無線技術、例えば、TIA/EIA(Telecommunications Industry Associations/Electronic Industries Associations:電気通信工業協会/電子工業協会)によって発表されたcdma2000規格、をサポートする。この事例ではNAS46は、RAN(Radio Access Network:無線アクセス・ネットワーク)と接続されたPDSN(Packet Data Serving node:パケット・データ・サービング・ノード)であり、RANは、無線リンク45を経由してRF(Radio Frequency:無線周波数)信号を介してノード44と通信する。PDSN及びRANは、本技術では公知であり、そして明確化及び簡潔さの理由で図3には示されない。
通信システム42の動作上の詳細を記述する前に、異なるレベルの階層を有する種々のタイプのプロトコル及びそれらの相互の関係を初めに説明することは、役に立つ。
ネットワーク通信の技術では、プロトコルは、ISO(International Organization for Standardization:標準化国際機構)及びITU−T(International Telecommunication Union-Telecommunications Standards Sector:国際電気通信組合−電気通信規格部門)によって発表されたような、OSI(Open System Interconnection:相互接続開放システム)モデルにしたがって階層化される。その目的は、複数の会社の装置の相互運用性を容易にするためである。すなわち、プロトコル階層の各レベルは、それ自身の仕様を有する。その意味で、個々の階層レベルの仕様が満足される限り、そのレベルでの製品の開発は、他のレベルの別の製品と互換性があることが保証される。
図3のシステム42がIP(Internet Protocol:インターネット・プロトコル)をサポートすると仮定する。図4は、階層分類上の順番にプロトコルのスタックを示す概要図であり、一般に“プロトコル・スタック”と呼ばれ、そして参照番号52によって一般的に表示される。IPプロトコル・スタック52は、IETF(International Engineering Task Force:国際工学技術タスク・フォース)モデルにしたがって構造化される、それはOSIモデルと類似するが、厳密には同じでない。IETFモデルにしたがって、IPプロトコル・スタック52は、レイヤ1から始まりレイヤ5までの、5つのレイヤを有する。それゆえ、図3のノード44又は46のようなノードによって送られるデータ・パケットは、プロトコル・スタック52を経由して処理される必要がある。プロトコルのスタック52は、ソフトウェアの形式又はハードウェアの形式で、若しくはこれらの組み合わせでノード内に構築される。同様に、同じノードによって受け取られたデータ・パケットは、逆の順序であるがプロトコル・スタック52を経由して処理される必要がある。
説明のために一例をあげる。データ・パケットがノード44又は46(図3)のようなノードから送られるために処理されると仮定すると、データ・パケットは、アプリケーション・レイヤ、すなわち、レイヤ5、内のプロトコルのうちの1つにしたがって初めに生成される。レイヤ5は、HTTP(Hyper Text Transfer Protocol:ハイパー・テキスト変換プロトコル)、SMTP(Service Mail Transfer Protocol:サービス・メール変換プロトコル)、FTP(File transfer Protocol:ファイル変換プロトコル)及びRTP(Real Time Transfer Protocol:リアル・タイム変換プロトコル)を含む。さらに、データ・パケットがVoIP(Voice over Internet Protocol:インターネットを介した音声プロトコル)セッションの生成物(product)であると仮定する。データ・パケットは、そのようにレイヤ5内のRTPにしたがってフォーマット化される必要がある。
レイヤ5内のRTPプロトコルからの結果のデータ・パケットのような、時間に敏感なデータ・パケットは、リアル・タイムで処理される必要がある。具体的に、不完全なパケットは、通常再び送られないが、その代わりに別の新たなデータ・パケットの伝送を妨害しないように単純に落とされる。RTPデータ・パケットは、それゆえ通常レイヤ4、移動レイヤ(transport layer)、内のUDP(User Data packet Protocol:ユーザ・データ・パケット・プロトコル)を介して搬送される。したがって、レイヤ5内のRTPからのデータ・パケットは、レイヤ4内のUDPにしたがってさらに定式化される必要がある。
一方で、もし、データ・パケットがレイヤ5内のFTPのような別のプロトコルから始まるのであれば、データ・パケットは、通常レイヤ4内のTCP(Transport Control Protocol:移動制御プロトコル)を介して送られる。TCPの下で、データ・パケットの正確な配信は、非常に重要なものである。それはそうとして、不完全なパケットは、全体のデータ伝送プロセスを遅くさせる可能性があるにも拘らず、常に再度送られる。
この移動レイヤ、レイヤ4、を通った後でデータ・パケットは、ソース・ポート番号及び宛て先ポート番号のような情報を加えられる。
移動レイヤ、レイヤ4、を通った後でデータ・パケットは、次の処理のためにネットワーク・レイヤ、レヤ3、に送られる。この特定のケースでは、レイヤ4からの結果としてのデータ・パケットは、IP、例えば、加えられたそのデータ・パケットのソース・アドレス及び宛て先アドレスにしたがって再度フォーマット化される必要がある。
簡潔さの理由のために、レイヤ3内にはIPだけが図4に示されている。IPを補助する機能を実行する他のプロトコルもレイヤ3内に同様に存在する。一例は、ICMP(Internet Control Message Protocol:インターネット制御メッセージ・プロトコル)であり、それは配信できないデータ・パケットに対するエラー・メッセージを送る目的を機能する。
その後で、データ・パケットは、ネットワーク・インターフェース・レイヤ、レイヤ2、に適用可能であるどんなプロトコルであっても適応するようにフレーム化される必要がある。前に説明したPPP(Point-to-Point Protocol:2点間プロトコル)は、レイヤ2プロトコルに分類される。本発明の具体例の実施形態にしたがったネットワーク・アクセスに先立つ通信プロトコル・セッションは、同様にネットワーク・インターフェース・レイヤにも関係する。
図4のプロトコル・スタック52の最も基底にあるレイヤは、物理レイヤ、レイヤ1であり、それはデータ・パケットに関する伝送の物理的な実行を取り扱う。例えば、もし通信リンク45(図3)が従来の有線リンクであるならば、物理レイヤ、レイヤ1、は、リンク45を形成する導電体配線を通り信号を駆動する2つのノード44及び46(図3)のハードウェア回路に関係する。もし通信リンク45が無線インターフェースであるならば、物理レイヤ、レイヤ1、は、無線空間に関係しそしてその無線空間を介して信号を送受信する2つのノード44及び46(図3)のハードウェア回路に関係する。
ノード44及び46(図3)のようなノードによって受け取られたデータ・パケットに関して、データ・パケットは、逆の順番であるが同じプロトコル・スタック52を通って、すなわち、レイヤ1からレイヤ5へ、処理される必要がある。
参照は、ここで図3に戻る。ノード44がNAS46を介してネットワーク・アクセスを得ようとしていると、この例では仮定する。メッセージのいずれかの交換の前に、物理リンク45は、信号を搬送する準備ができている必要がある。別の言葉で言うと、ノード44及び45の物理レイヤ、レイヤ1は、物理的に存在し、そして確立されている必要がある。
この実施形態では、前に述べたように、通信リンク45は、無線インターフェースであり、そしてネットワーク48によってサポートされる無線技術は、cdma2000である。物理レイヤは、ノード44内の無線回路、及びNAS46内部のRANに関係する。RANは、少なくとも1つのBSC(Base Station Controller:基地局コントローラ)及び複数のBS(Base Station:基地局)を含むことができる。RAN、BSC及びBSは、図3には示されていない。
この実施形態にしたがって、一旦物理レイヤ、レイヤ1が確立されると、すなわち、両方のノード44及び46が互いに相互の物理的存在を検出すると、NAS46は、すぐにノード44に最初のメッセージを送る。
図5は、ノード44とNAS46との間のメッセージの通信シーケンスを示すフロー図である。全体のフロー・プロセスは、参照番号54によって表示される。
最初のメッセージは、Sync(同期)メッセージと呼ばれ、参照番号56によって示される。Syncメッセージ56は、ノード44がそこから選択するための全ての可能性のある認証オプションを含む。オプションは、CHAP(チャレンジ認証プロトコル)の下でのチャレンジ・メッセージ、及びPAP(パスワード認証プロトコル)によって要求されるパスワードの要請とユーザネームを含むことができる。CHAP及びPAPの他に、Syncメッセージ56内に、PPPで規定される又はサポートされる他の認証プロトコルが含まれるはずである。
Syncメッセージ56を受け取ると、図5に示されたように、ノード44は、Request (要請)メッセージ58で応答する。
Requestメッセージ58内では、ノード44は、Syncメッセージ56で述べられたような要請に応答して必要な認証情報を含む。その上に、ノード44は、同様にNAS46を介した引き続くネットワーク・アクセスのためにノード44に対するリンクを確立するために必要な全てのパラメータ・オプションをRequestメッセージ58内に含む。関係するオプションを有するパラメータがリンク設定に関係するか、認証に関係するか、又はネットワーク・アクセス制御に関係するかどうかは問題ではない。すなわち、PPPに関して前に説明したように、LCP(リンク制御プロトコル)、CHAP(チャレンジ・ハンドシェーク認証プロトコル)及びIPCP(Internet Protocol Control Protocol:インターネット・プロトコル制御プロトコル)のようなプロトコル構成要素の機能にしたがってパラメータを分類する代わりに、本実施形態のRequestメッセージ58では、オプションを有する全てのパラメータは、機能に無関係に含まれる。より詳しくは、Requestメッセージ58中のオプションを有するパラメータは、チャレンジ・メッセージへの応答、又はもし適用できるのであればユーザネーム及びパスワード、データグラム・サイズ及びHDLC(高レベル・データ・リンク制御)ヘッダ・フィールド圧縮体系のようなリンク45のリンク設定パラメータ、同様に、IPアドレス、DNS(Domain Name System:ドメイン名システム)設定、及びもし適用できるのであればIPヘッダ圧縮プロトコル、及び等々のようなネットワーク・アクセスのためのパラメータを含むことができる。
NAS46が両方のノード30及び46によってサポートされるオプションを選択することを可能にするために選択の点から意図的な冗長度を用いてRequestメッセージ58が好ましくはフォーマット化される、それによって両方のノード44及び46が迅速に初期リンク確立の全体プロセスを終わらせることを可能にすることが、注目されるべきである。種々の選択のうちで、NAS46は、良好なリンクの機会を増加させる目的を明確にサポートする関係するオプションを有するパラメータを選択的に選択することができ、それによって設定時間を短縮する。別の言葉で言うと、Requestメッセージ58は、本質的にノード44によってサポートされる全ての利用可能なパラメータ・オプションを有する通知(advertisement)メッセージとして動作する。そこでは、NAS46によりオプションのサブセットを選択することが、リンク・プロセスの終了を可能にするはずである。
したがって、図5に示されたように、NAS46は、Requestメッセージ58を受け取るとReply(回答)メッセージ60で応答する。Replyメッセージ60では、NAS46は、種々の選択肢の中からオプションを選択する。Replyメッセージ60は、選択されたパラメータ・オプションをそれらに関係する設定値とともに含む。多くの場合、Replyメッセージ60は、ノード44によるネットワーク・トラフィックの開始の前に必要とされる最後のメッセージである。
前に説明されたピアー・トゥ・ピアーPPPプロトコルのような他のプロトコル方法とは異なり、本実施形態にしたがって、肯定的受領通知又は否定的受領通知に対してどんな確認メッセージの必要性もない。それなりに、いずれかのメッセージに応答して、それはSyncメッセージ56、Requestメッセージ58、又はReplyメッセージ60であっても、どちらのAck(肯定的受領通知)メッセージ又はNak(否定的受領通知)メッセージも、要求されない。いずれかの特定の要請された事項に応答がないことは、そのような事項が利用できない又はサポートされないことを意味する。
図5に戻って、Replyメッセージ60を受け取ると、もしNAS46によって選択されたオプションがある種のしきい値を満たすのであれば、例えば、ネットワーク・アクセスのための通信リンクをノード44が確立することを全ての選択されたオプションが認めるのであれば、ノード44は、NAS46にユーザ・データ62を直接伝送することを実行する。再び、受領通知メッセージは、ノード44によって送られない。
ネットワーク・アクセスの最後に、ノード44又はNAS46のどちらかは、相手にTerminate Request(終了要請)メッセージ64を送ることができ、それはその後で、Terminate Acknowledge(終了受領通知)メッセージ66で応答して戻され、そして通信セッションを終了する。
滅多に起きない場合では、ノード44により得られようとしているネットワーク・アクセスのためのリンクを確立するためにNAS46に対するRequestメッセージ58中の設定オプションが不十分であることがあり得る。すなわち、Replyメッセージ60でNAS46によって選択されたオプションが、ネットワーク・アクセス・リンクを確立するためにノード44にとって要求されるしきい値を満たすために不十分であることがあり得る。NAS46は、それにも拘らず受け入れられたオプションだけを用いてReplyメッセージ58送るが、受け入れられなかったオプションは無視される。再び、Nakメッセージは、必要ない。前に述べたように、Requestメッセージ58中に含まれたがReplyメッセージ60中で無視された提案済のオプションは、無視されたオプションに対するサポートの欠如を暗に示している。このケースでは、NAS46は、ネットワーク・トラフィックを確立できず、ノード44が新たなRequestメッセージを送ることを待機する。
ノード44に関して、もしそれがReplyメッセージ60中でのサポートの欠如のために無視されたパラメータ・オプションにも拘らず、例えば、無視されたオプションが致命的でなければ、そのリンクを選ぶのであれば、ノード44はネットワーク・トラフィックを伝送し始めることができる。一方で、もし無視されたパラメータがネットワーク・アクセス・リンクを確立するために絶対的に必要であるならば、例えば、ノード44によって要請されたIPアドレスがReplyメッセージ60中で無視されるのであれば、ネットワーク・トラフィックは、確立されることができず、そしてリンクはできなかったと言われる。
全体のプロセス54は、同様に図6のフローチャートに示される。
本発明のリンク確立プロセスは、別のリンク・プロトコルへのフェール・オーバー・フィーチャを有するように同様に構成される。この実施形態では、もし、図5及び図6に示されたリンク・プロセス54がどちらかのノード44又はNAS46(図3)でサポートされないのであれば、従来のPPPは、ノード44により求められている最終のネットワーク・アクセスに導くリンク・プロセスを続けるために代替プロトコルとして介入する。
本質において、2つの可能性があり、それぞれ以下に説明される。
第1のシナリオは、ノード44がリンク・プロセス54をサポートするが、NAS46がサポートしない場合に発生する。参照は、ここで図3と関連して図7に向けられる。図7は、このシナリオの下でのノード44とNAS46との間のメッセージの通信シーケンスを示すフロー図である。メッセージの全体のフローは、参照番号68によって表示される。ノード44がリンク・プロセス54をサポートすると仮定するので、ノード44と46との間に物理レイヤ、レイヤ1、を設定すると、ノード44はSyncメッセージ56を待機する。しかしながら、NAS46がリンク・プロセス54をサポートしないことが同様に仮定されるために、NAS46は、Syncメッセージ56を送らない。その代わりに、ノード44にPPPの下でLCP Configuration Request(設定要請)メッセージ70を送る。
LCP Configuration Requestメッセージ70を受け取ると、ノード44は、NAS46がリンク・プロセス54をサポートしないことを直ちに知り、そして従来のPPPを介してNAS46と通信するためのアクションを速やかに取る。具体的に、LCP Configuration Requestメッセージ70に応答して、ノード44は、図7に示されたように、LCP Configure Ack(設定受領通知)メッセージ72を送る。あるいは、ノードは、もしConfiguration Requestメッセージ70中に提案されたオプションが望ましくないのであれば、従来のPPPと同様な方法でConfigure Nak(設定否定的受領通知)メッセージを送ることができる。
この実施形態では、受け取られたメッセージがPPPメッセージであるか非PPPメッセージであるかどうかを、ノード44又はノード46のいずれかが、認識することに注目すべきである。後で説明されるように、この実施形態で使用されるデータ・フレーム・フォーマットは、PPPに対して使用されるものと同じであり、それによって迅速なメッセージ認識及び弁別を可能にする。
プロセスの残りは、図2に示されたプロセス34と実質的に同じである。すなわち、良好に接続した後で、データ・トラフィック74が、ノード44とNAS46との間に確立される。ネットワーク・アクセスの最後に、ノード44又はNAS46のどちらかが、相手にTerminate Request(終了要請)メッセージ76を送ることができ、それはその後で、Terminate Acknowledge(終了受領通知)メッセージ78で応答して戻し、そして通信セッション68を終了する。
プロセス68に対応するフローチャートは、図8に示される。従来のPPPステップは、簡潔さの目的のために図8に示されない。
第2のシナリオは、NAS46がリンク・プロセス54をサポートするが、ノード44がサポートしない時に生じる。参照は、ここで図3と関連して図9に向けられる。図9は、このシナリオの下でのノード44とNAS46との間のメッセージの通信シーケンスを示すフロー図である。メッセージの全体のフローは、参照番号70’によって表示される。NAS46がリンク・プロセス54をサポートすると仮定するので、ノード44と46との間に物理レイヤ、レイヤ1、を確立すると、NAS46はSyncメッセージ56をノード44に直ぐに送る。ノード44がリンク・プロセス54をサポートしないことが同様に仮定されるために、Syncメッセージ56を受け取ると、ノード44は、Syncメッセージ56を認識しない。上に述べられたようにそしてさらに以下に説明されるように、ノード44は、PPPメッセージと非PPPメッセージとを区別できる。それゆえ、正当に認識されなかったSyncメッセージ56で、ノード44は、標準のPPP手順を使用して正当に認識されなかったSyncメッセージ56を拒絶する。その代わりに、ノード44は、ノード44とNAS46との間に物理リンクが確立されるとLCPConfiguration Request(設定要請)メッセージ72’を送る。
もし、NAS46がLCP Configuration Requestメッセージ72’又はSyncメッセージ56のPPP拒絶を受け取るのであれば、NAS46は、リンク・プロセス54(図5及び図6)に関係する全てのフィーチャ(feature)をディスエーブルし、そして図2に示され前に説明されたように従来のPPPプロセス34を通る。
良好に接続した後で、データ・トラフィック74は、ノード44とNAS46との間で交換されることができる。ネットワーク・アクセスの最後に、ノード44又はNAS46のどちらかが、相手にTerminate Request(終了要請)メッセージ76を送ることができ、それはその後で、Terminate Acknowledge(終了受領通知)メッセージ78で応答して戻し、そして通信セッション70’を終了する。
図10は、プロセス70’に関する対応するフローチャートを示す。従来のPPPステップは、簡潔さそして明確化のために図10には示されない。
図11は、フロー・プロセス54(図5)において使用されるデータ・フレーム・フォーマットを示す。プロセス54のデータ・パケットに対するフレーム・テンプレートは、参照番号80によって表示される。本質において、テンプレート80は、RFC1662の下で述べられたようにPPPによって使用される対応するデータ・パケット・テンプレートに類似する。特に、データ・フレーム80は、フラッグ・フィールド82、アドレス・フィールド84、制御フィールド86、プロトコル番号フィールド88、データ・フィールド90、及びFCS(Frame Check Sequence:フレーム検査系列)フィールド92を含む。
フラッグ・フィールド82は、1バイト長でありそしてデータ・パケット・フレームの開始を指示する。フラッグ・フィールド82は、16進値の7Eを常に仮定し、そしてRFC1662によって要求されるように、リンク・プロセス54及びPPPに対して使用される同じ値である。
アドレス・フィールド84は、同様に1バイト長であり、そして同様にRFC1662に述べられているように、16進値のFFに常に設定される。
制御フィールド86は、1バイト長であり、そして同様にRFC1662に指定されているように、16進値の03に固定される。
プロトコル番号フィールド88では、このフィールド中の値は、データ・パケット80が何であるかを指示する。プロトコル番号フィールド88は、長さが2バイトである。例えば、RFC1661及び1662に規定されたように、Configuration Requestメッセージ70のような各々のLCPメッセージは、16進値のC021を有する。この実施形態では、リンク・プロセス54(図5)において使用されるSyncメッセージ56、Requestメッセージ58又はReplyメッセージ60のような各々のメッセージは、PPPにおいて使用されるいずれかのプロトコル値とは異なる固有のプロトコル値を有する。それなりに、データ・パケット80がPPPパケットであるかPPPパケットでないかどうかは、容易に区別されることができる。
データ・フィールド90は、ゼロからペイロードのバイト数より大きい範囲の長さを有し、ペイロードはデータ又は制御情報のいずれかを含んでいる。例えば、もし、データ・パケット80がRequestメッセージ58であることを指示する値をプロトコル番号フィールド88内の値が有するのであれば、データ・フィールドは、上記のようなパラメータ・オプションに関係する全ての情報含む。別の1つの例として、もし、データ・パケット80がユーザ・データ62(図5)であることを指示する値をプロトコル番号フィールド88内の値が有するのであれば、レイヤ3から発生されるIPデータ・パケットは、データ・フィールド90の中へと全体がカプセル化される。
FCSフィールド92は、長さが2から4バイトの範囲であり、そして伝送の間のエラーに対する基本的な保護を提供するためにフレーム80についての、CRC(Cyclic Redundancy Code:巡回冗長コード)のようなコードを含む。
上に述べたように(例えば、図5参照)、Syncメッセージ56、Replyメッセージ60、Terminate Requestメッセージ64、及びTerminate Ackメッセージに加えて、別のタイプのメッセージは、リンク確立プロセス54の中で同様に実行されることができる。図12は、いくつかの例を示す。
参照は、ここで図12と関連して図3に向けられる。例えば、図12に参照番号94によって表示されたアクティブでない通信の延長された期間の後で、いずれかのノード44又はNAS46は、別のパーティにEcho Request(エコー要請)メッセージ96を送ることができ、そのパーティ又はリンク45の状態に関して問い合わせることができる。例えば、もし電源異常に起因してリンク45のために確立された物理リンクがないのであれば、送る側のパーティは、Echo Requestメッセージ45から何の応答も受け取らないはずである。したがって、送る側のパーティは、通信セッション54を終了させることを望むことができる。一方で、もしリンク45がまだ物理的に接続されているのであれば、受け取る側のパーティは、Echo Reply(エコー応答)メッセージ98を送ることによってEcho Requestメッセージ96に応答することができる。送る側のパーティは、その後で、通信セッション54を終了させるための判断に進むことができる。タイム・ピリオド94の期間は、予め決められることができる。
ユーザ・データ62の交換の最中に、NAS46は、その後の認証のための情報を要請しているノード44にAuthenticate(認証)メッセージ98を送ることができる。例えば、通常のデータ・トラフィックの間に、ノード44は、あるユーザによってだけ手に入れることができる取り扱いに注意を要する情報をアクセスする必要があり得る。それなりに、NAS46は、その後の認証のためにノード44にAuthenticateメッセージ99を送ることができる。上に述べたようにPAP及びCHAPのような認証プロトコルに加えて、この技術において公知の他のさらに複雑なプロトコル体系が同様に使用されることができる。一例は、認証のためにネットワーク48の内部に又は外部のいずれかに置かれたAAA(Authentication, Authorization, and Accounting:認証、認可、及びアカウンティング)サーバのような、外部のサーバを採用するEAP(Extended Authentication Protocol:拡張認証プロトコル)であり得る。
図13は、本発明の具体例の実施形態にしたがって参照番号100によって表示された、図3に示されたノード44のような装置のハードウェア・インプリメンテーションの一部を模式的に示す。装置100は、例えば、ラップトップ・コンピュータ、PDA、又はセルラ電話機のような、種々の形式で構築されることができそして取り込まれることができる。
装置100は、複数の回路を一緒にリンクさせる中央データ・バス102を備える。回路は、CPU(Central Processing Unit:中央処理装置)又はコントローラ104、受信回路106、送信回路108、及びメモリ・ユニット110を含む。
もし、装置100が無線デバイスであれば、受信回路及び送信回路106及び108は、図には示されていないがRF(Radio Frequency:無線周波数)回路に接続されることができる。受信回路106は、受信した信号をデータ・バス102に送る前に処理しそしてバッファする。一方で、送信回路108は、デバイス100から外に送る前にデータ・バス102からのデータを処理しそしてバッファする。CPU/コントローラ104は、データ・バス102のデータ管理の機能を、そしてさらにメモリ・ユニット110内の命令的なコンテントを実行することを含む一般的なデータ処理の機能を実行する。
図13に示されたように別々に配置される代わりに、代案として、送信回路108及び受信回路106は、CPU/コントローラ104の一部であることができる。
メモリ・ユニット110は、参照番号112によって一般的に表示される命令のセットを含む。この実施形態では、命令は、他のものの中で、プロトコル・スタック機能114、リンク確立クライアント116、PPP機能118のような部分を含む。プロトコル・スタック機能114は、前に図4に示されそして説明されたように、スタック52に類似のプロトコル・スタックをランする。リンク確立クライアント116は、上に説明された図5−10に記載されたプロセスのようなプロセスにしたがった命令的なセットを含む。PPP機能118は、装置102がPPPプロセスを実行することを可能にするための命令のセットを含む。PPP機能118は、同様に前に説明されたように、独立して使用されることができる、又はリンク確立クライアント116からの代替として使用されることができる。
この実施形態では、メモリ・ユニット110は、RAM(Random Access Memory:ランダム・アクセス・メモリ)回路である。具体例の命令部分114,116及び118は、ソフトウェア・ルーチン又はソフトウェア・モジュールである。メモリ・ユニット110は、別の1つのメモリ・ユニット(図示せず)に結合されることができ、それは、揮発性タイプ又は不揮発性タイプのどちらかであり得る。代案として、メモリ・ユニット110は、別の回路タイプ、例えば、EEPROM(Electrically Erasable Programmable Read Only Memory:電気的消去プログラム可能な読み出し専用メモリ)、EPROM(Electrically Programmable Read Only Memory:電気的プログラム可能な読み出し専用メモリ)、ROM(Read Only Memory:読み出し専用メモリ)、ASIC(Application Specific Integrated Circuit:特定用途集積回路)、磁気ディスク、光ディスク、及びこの分野において周知の別のものからなることができる。
図14は、本発明にしたがった、図3に示されたNAS46のような別の1つの装置のハードウェア・インプリメンテーションの一部を模式的に示し、そして、参照番号120によって表示される。装置120は、複数の回路を一緒にリンクさせる中央データ・バス122を備える。回路は、CPU(中央処理装置)又はコントローラ124、受信回路126、送信回路128、及びメモリ・ユニット130を含む。
受信回路及び送信回路126及び128は、そこに装置120がリンクされているネットワーク・データ・バス(図示せず)に接続されることができる。受信回路126は、内部データ・バス122に転送する前に、ネットワーク・データ・バス(図示せず)から受け取った信号を処理しそしてバッファする。送信回路128は、装置120から外に送る前にデータ・バス122からのデータを処理しそしてバッファする。CPU/コントローラ124は、データ・バス122のデータ管理及びメモリ・ユニット130の命令コンテントを実行することを含む総合的なデータ処理の機能に関する責務を実行する。
再び、図14に示されたように別々に配置される代わりに、送信回路128及び受信回路126は、CPU/コントローラ124の一部であることができる。
メモリ・ユニット130は、参照番号134によって一般的に表示された命令のセットを含む。この実施形態では、命令は、他のものの中で、プロトコル・スタック機能136、リンク確立サーバ138、及びPPP機能140の部分を含む。プロトコル・スタック機能136は、前に図4に示されそして説明されたように、スタック52に類似のプロトコル・スタックをランする。リンク確立サーバ138は、図5−10に示されそして上に説明されたプロセスのようなプロセスにしたがった命令的なセットを含む。PPP機能140は、装置120がPPPプロセスを実行することを可能にするための命令のセットを含む。PPP機能140は、同様に前に説明されたように、独立して実行されることができる、又はリンク確立サーバ138からの代替として実行されることができる。
メモリ・ユニットは、上に述べたようなタイプのメモリ回路からなることができ、そしてさらに繰り返されない。
図5−10に示されそして説明されたプロセス54,68,70’は、同様に、この技術において公知のいずれかのコンピュータ読み取り可能な媒体上に記憶される又は伝送されることができる。この明細書及び添付された特許請求の範囲において、用語“コンピュータ読み取り可能な媒体”は、実行のためにそれぞれ図12及び図13に示されそして説明されたCPU/コントローラ104及び124に命令を提供する際に関係するいずれかの媒体を呼ぶ。もし記憶装置タイプであればそのようなコンピュータ読み取り可能な媒体は、同様に前に説明されたように、メモリ・ユニット110及び130に関する回路形式と同じ揮発性記憶媒体又は不揮発性記憶媒体の形式を取ることができる。もし伝送タイプであればそのようなコンピュータ読み取り可能な媒体は、例えば、同軸ケーブル、金属電線、光ケーブル、及び機械又はコンピュータによって読み取り可能な信号を搬送できる音響波又は電磁波を搬送する無線インターフェースを含むことができる。
最後に、本実施形態に記載されたものは、レイヤ3プロトコルが、IPとして説明されている。IPは、IPv4(Internet Protocol version 4:インターネット・プロトコル第4版)及びIPv6(Internet Protocol version 6:インターネット・プロトコル第6版)のような、異なるバージョンであり得る。その上、別のレイヤ3プロトコルが同等に適用可能であることが、注目されるべきである。例えば、レイヤ3プロトコルは、IPX(Internetworking Packet Exchange Protocol:インターネット上で動作するパケット交換プロトコル)アップル・トーク(Apple-Talk)及び別のバージョンの各種の他のネットワーク・プロトコルであり得る。その上、具体例の実施形態では、ノード44は、NAS46と無線で通信する移動デバイスとして図示されている。ノード60が固定であり得ることが理解されるはずである。それに加えて、リンク45は、無線リンクである必要がない。代わりにリンク45は、有線リンクであり得る。その上、本実施形態に関連して記載されたいずれかの論理ブロック、回路、及びアルゴリズム・ステップは、ハードウェア、ソフトウェア、ファームウェア、又はその組み合わせで与えられることができる。形状及び詳細における論理の変更及びその他の変更が本発明の範囲及び精神から逸脱することなくその中で行われ得ることが、当業者によって理解されるはずである。
図1は、ネットワークの全体的な接続の概略図である。 図2は、従来のプロトコルの通信セッションの通信シーケンス図である。 図3は、本発明の具体例の実施形態に含まれるノードの概要図である。 図4は、階層分類上の順番にプロトコルのスタックを示す概要図である。 図5は、本発明の具体例の実施形態にしたがった通信セッションの通信シーケンス図である。 図6は、本発明の具体例の実施形態にしたがって含まれるステップを示すフローチャートである。 図7は、従来のプロトコルにフェール・オーバー・フィーチャを用いて実行される具体例の実施形態を示す通信シーケンス図である。 図8は、図7の通信シーケンス図に対応するフローチャートである。 図9は、従来のプロトコルに別の1つのフェール・オーバー・フィーチャを用いて実行される具体例の実施形態を示す別の1つの通信シーケンス図である。 図10は、図9の通信シーケンス図に対応するフローチャートである。 図11は、具体例の実施形態にしたがってネットワーク・アクセスを得ようとしているノードの回路の一部の概要図である。 図12は、追加のメッセージ・タイプを用いて実行される図1の通信セッションの通信シーケンス図である。 図13は、具体例の実施形態にしたがってネットワーク・アクセスを得ようとしているノードの回路の一部の概要図である。 図14は、具体例の実施形態にしたがったネットワーク・アクセス・ノードの回路の一部の概要図である。
符号の説明
30,34’…ノード,34…PPP通信セッション,42…通信システム,44…ノード,45…リンク,50…バックボーン・ネットワーク,52…IPプロトコル・スタック80…フレーム・テンプレート,102…中央データ・バス,110…メモリ,122…中央データ・バス,130…メモリ。

Claims (51)

  1. ネットワーク・アクセス・ノードを介したネットワーク・アクセスに対する通信セッションのための方法、該方法は下記を具備する:
    メッセージの中に認証、リンク設定、及びネットワーク・アクセスのためのパラメータ・オプションのセットを与えること;及び
    前記ネットワーク・アクセス・ノードに前記メッセージを送ること。
  2. 請求項1の方法、ここにおいて、前記メッセージは第1のメッセージであり、前記方法は、前記第1のメッセージの前記パラメータ・オプションのセットの認証に関係する第2のメッセージを前記ネットワーク・アクセス・ノードから受け取ること、及び前記パラメータ・オプションのセットの前記認証がしきい値を満足する場合に前記ネットワーク・アクセスを開始すること、をさらに備える。
  3. 請求項1の方法、ここにおいて、前記メッセージは第1のメッセージであり、ここにおいて、前記パラメータ・オプションのセットはパラメータ・オプションの第1のセットであり、ここにおいて、前記方法は、前記第1のメッセージの前記パラメータ・オプションのセットの認証に関係する第2のメッセージを前記ネットワーク・アクセス・ノードから受け取ること、及び前記パラメータ・オプションのセットの前記認証がしきい値を満足しない場合に前記パラメータ・オプションの第1のセットとは異なるパラメータ・オプションの第2のセットを有する第3のメッセージを前記ネットワーク・アクセス・ノードに送ること、をさらに備える。
  4. 請求項1の方法、ここにおいて、前記メッセージは第2のメッセージであり、ここにおいて、前記第2のメッセージの前記送ることの前に前記方法は、前記ネットワーク・アクセス・ノードと物理リンクを確立すると前記ネットワーク・アクセス・ノードから認証の要請を含む第1のメッセージを受け取ること、をさらに含む。
  5. 請求項1の方法、ここにおいて、前記送ることに前に前記パラメータ・オプションのセットが前記ネットワーク・アクセス・ノードからPPP(2点間プロトコル)メッセージを受け取るのであれば、該方法は、前記PPPメッセージに応答して別の1つのPPPメッセージを送ることによって前記ネットワーク・アクセス・ノードと通信することを直ちに再ソートする(resort)こと、をさらに含む。
  6. 請求項5の方法、該方法は、前記PPPメッセージの対応するデータ・パケット・フォーマットに実質的に同じデータ・パケット・フォーマットを有する前記メッセージに対してデータ・パケットを与えること、をさらに備える。
  7. 請求項1の方法、該方法は、前記ネットワーク・アクセス・ノードとの予め決められた期間のインアクティブな通信の後で前記ネットワーク・アクセス・ノードとエコー・メッセージを交換すること、をさらに含む。
  8. 請求項1の方法、該方法は、前記ネットワーク・アクセスのためのユーザ・データを前記ネットワーク・アクセス・ノードと通信すること、及び前記ネットワーク・アクセスの最中に前記ネットワーク・アクセス・ノードから認証メッセージを受け取ること、をさらに含む。
  9. IP(インターネット・プロトコル)をサポートする通信システムにおけるネットワーク・アクセス・ノードを介したネットワーク・アクセスに対する通信セッションのための方法、該方法は、下記を具備する:
    前記ネットワーク・アクセス・ノードと物理リンクを確立すること;
    認証の要請を含む同期メッセージを前記物理リンクを介して前記ネットワーク・アクセス・ノードから受け取ること;
    要請メッセージの中に前記認証の要請に応答するため、リンク設定、及びネットワーク・アクセスのためのパラメータ・オプションのセットを与えること;
    前記物理リンクを介して前記ネットワーク・アクセス・ノードに前記要請メッセージを送ること;
    前記要請メッセージの前記パラメータ・オプションのセットの認可に関係する回答メッセージを前記物理リンクを介して前記ネットワーク・アクセス・ノードから受け取ること;及び
    前記認可の前記パラメータ・オプションのセットがしきい値を満足する場合に前記物理リンクを介して前記ネットワーク・アクセスを開始すること。
  10. ネットワーク・アクセスを得ようとしているノードとの通信セッションのための方法、該方法は下記を具備する:
    認証、リンク設定、及びネットワーク・アクセスのためのパラメータ・オプションのセットを含んでいる第1のメッセージを前記ノードから受け取ること、及び
    前記パラメータ・オプションのセットの認可に関係する第2のメッセージを前記ノードに送ること。
  11. 請求項10の方法、ここにおいて、前記方法は、前記認可の前記パラメータ・オプションの第1のセットがしきい値を満足する場合に前記ノードから前記ネットワーク・アクセスのためのユーザ・データを受け取ること、及び前記認可の前記パラメータ・オプションの第1のセットが前記しきい値を満足しない場合に前記パラメータ・オプションの第1のセットとは異なるパラメータ・オプションの第2のセットを含んでいる第3のメッセージを前記ノードから受け取ること、をさらに含む。
  12. 請求項10の方法、該方法は、前記第1のメッセージを前記ノードから受け取る前に前記ノードと物理リンクを確立すると前記ノードから前記認証の要請を含む同期メッセージを送ること、をさらに含む。
  13. 請求項12の方法、ここにおいて、前記確立した後で前記物理リンクが前記ノードからPPP(2点間プロトコル)メッセージを受け取るのであれば、前記方法は、前記PPPメッセージに応答して別の1つのPPPメッセージを送ることによって前記ノードと通信することを直ちに再ソートすること、をさらに含む。
  14. 請求項13の方法、該方法は、前記PPPメッセージの対応するデータ・パケットに実質的に同じデータ・パケット・フォーマットを有する前記第2のメッセージに対してデータ・パケットを与えること、をさらに備える。
  15. 請求項10の方法、該方法は、前記ノードとの予め決められた期間のインアクティブな通信の後で前記ノードとエコー・メッセージを交換すること、をさらに含む。
  16. 請求項10の方法、該方法は、前記ネットワーク・アクセスのためのユーザ・データを前記ノードと通信すること、及び前記ネットワーク・アクセスの最中に前記ノードに認証メッセージを送ること、をさらに含む。
  17. IP(インターネット・プロトコル)をサポートする通信システムにおけるネットワーク・アクセスを得ようとしているノードとの通信セッションのための方法、該方法は、下記を具備する:
    前記ノードと物理リンクを確立すると前記ノードから認証の要請を含む同期メッセージを送ること;
    前記認証の要請に応答するため、リンク設定、及びネットワーク・アクセスのためのパラメータ・オプションを含む要請メッセージを前記物理リンクを介して前記ノードから受け取ること;
    前記要請メッセージの前記パラメータ・オプションのセットの認可に関係する回答メッセージを前記物理リンクを介して送ること;及び
    前記ノードが前記パラメータ・オプションのセットの前記認可を受理する場合に前記物理リンクを介して前記ノードから前記ネットワーク・アクセスのためのデータを受け取ること。
  18. ネットワーク・アクセス・ノードを介したネットワーク・アクセスに対する通信セッションのための装置、該装置は下記を具備する:
    メッセージの中に認証、リンク設定、及びネットワーク・アクセスのためのパラメータ・オプションのセットを与えるための手段;及び
    前記ネットワーク・アクセス・ノードに前記メッセージを送るための手段。
  19. 請求項18の装置、ここにおいて、前記メッセージは第1のメッセージであり、前記装置は、前記第1のメッセージの前記パラメータ・オプションのセットの認可に関係する第2のメッセージを前記ネットワーク・アクセス・ノードから受け取るための手段、及び前記認可の前記パラメータ・オプションのセットがしきい値を満足する場合に前記ネットワーク・アクセスを開始するための手段、をさらに備える。
  20. 請求項18の装置、ここにおいて、前記メッセージは第1のメッセージであり、前記パラメータ・オプションのセットはパラメータ・オプションの第1のセットであり、前記装置は、前記第1のメッセージの前記パラメータ・オプションの第1のセットの認可に関係する第2のメッセージを前記ネットワーク・アクセス・ノードから受け取るための手段、及び前記認可の前記パラメータ・オプションの第1のセットがしきい値を満足しない場合に前記パラメータ・オプションの第1のセットとは異なるパラメータ・オプションの第2のセットを有する第3のメッセージを前記ネットワーク・アクセス・ノードに送るための手段、をさらに備える。
  21. 請求項18の装置、ここにおいて、前記メッセージは第2のメッセージであり、前記装置は、前記第2のメッセージの前に前記ネットワーク・アクセス・ノードと物理リンクを確立すると前記ネットワーク・アクセス・ノードから認証の要請を含む第1のメッセージを受け取るための手段、をさらに含む。
  22. 請求項18の装置、ここにおいて、前記与える手段によって与えられた前記パラメータ・オプションのセットの前に前記ネットワーク・アクセス・ノードからPPP(2点間プロトコル)メッセージを受け取るのであれば、該装置は、前記PPPメッセージに応答して別の1つのPPPメッセージを前記送る手段を介して前記ネットワーク・アクセス・ノードと通信することを直ちに再ソートするための手段、をさらに含む。
  23. 請求項22の装置、該装置は、前記PPPメッセージの対応するデータ・パケット・フォーマットに実質的に同じデータ・パケット・フォーマットを有する前記メッセージに対してデータ・パケットを与えるための手段、をさらに備える。
  24. 請求項18の装置、該装置は、前記ネットワーク・アクセス・ノードとの予め決められた期間のインアクティブな通信の後で前記ネットワーク・アクセス・ノードとエコー・メッセージを交換するための手段、をさらに含む。
  25. 請求項18の装置、該装置は、前記ネットワーク・アクセス・ノードと前記ネットワーク・アクセスのためのユーザ・データを通信するための手段、及び前記ネットワーク・アクセスの最中に前記ネットワーク・アクセス・ノードから認証メッセージを受け取るための手段、をさらに含む。
  26. IP(インターネット・プロトコル)をサポートする通信システムにおけるネットワーク・アクセス・ノードを介したネットワーク・アクセスに対する通信セッションのための装置、該装置は、下記を具備する:
    前記ネットワーク・アクセス・ノードと物理リンクを確立するための手段;
    認証の要請を含む同期メッセージを前記物理リンクを介して前記ネットワーク・アクセス・ノードから受け取るための手段;
    要請メッセージの中に前記認証の要請に応答するため、リンク設定、及びネットワーク・アクセスのためのパラメータ・オプションのセットを与えるための手段;
    前記物理リンクを介して前記ネットワーク・アクセス・ノードに前記要請メッセージを送るための手段;
    前記要請メッセージの前記パラメータ・オプションのセットの認可に関係する回答メッセージを前記物理リンクを介して前記ネットワーク・アクセス・ノードから受け取るための手段;
    前記認可の前記パラメータ・オプションのセットがしきい値を満足する場合に前記物理リンクを介して前記ネットワーク・アクセスを開始するための手段;及び
    前記認可の前記パラメータ・オプションのセットが前記しきい値を満足しない場合に前記パラメータ・オプションのセットとは異なる別の1つのパラメータ・オプションのセットを有する別の1つの要請メッセージを前記物理リンクを介して送るための手段。
  27. ネットワーク・アクセスを得ようとしているノードとの通信セッションのための装置、該装置は下記を具備する:
    認証、リンク設定、及びネットワーク・アクセスのためのパラメータ・オプションのセットを含んでいる第1のメッセージを前記ノードから受け取るための手段、及び
    前記パラメータ・オプションのセットの認可に関係する第2のメッセージを前記ノードに送るための手段。
  28. 請求項27の装置、ここにおいて、該装置は、前記認可の前記パラメータ・オプションの第1のセットがしきい値を満足する場合に前記ノードから前記ネットワーク・アクセスのためのユーザ・データを受け取るための手段、及び前記認可の前記パラメータ・オプションの第1のセットが前記しきい値を満足しない場合に前記パラメータ・オプションの第1のセットとは異なるパラメータ・オプションの第2のセットを含んでいる第3のメッセージを前記ノードから受け取るための手段、をさらに含む。
  29. 請求項27の装置、該装置は、前記第1のメッセージを前記ノードから受け取る前に前記ノードと物理リンクを確立すると前記ノードから認証の要請を含む同期メッセージを送るための手段、をさらに含む。
  30. 請求項27の装置、ここにおいて、前記確立した後で前記物理リンクが前記ノードからPPP(2点間プロトコル)メッセージを受け取るのであれば、前記装置は、前記PPPメッセージに応答して別の1つのPPPメッセージを送ることによって前記ノードと通信することを直ちに再ソートするための手段、をさらに含む。
  31. 請求項30の装置、該装置は、前記PPPメッセージの対応するデータ・パケットに実質的に同じデータ・パケット・フォーマットを有する前記第2のメッセージに対してデータ・パケットを与えるための手段、をさらに備える。
  32. 請求項27の装置、該装置は、前記ノードとの予め決められた期間のインアクティブな通信の後で前記ノードとエコー・メッセージを交換するための手段、をさらに含む。
  33. 請求項27の装置、ここにおいて、該装置は、前記ノードと前記ネットワーク・アクセスのためのユーザ・データを通信するための手段、及び前記ネットワーク・アクセスの最中に前記ノードに認証メッセージを送るための手段、をさらに含む。
  34. IP(インターネット・プロトコル)をサポートする通信システムにおけるネットワーク・アクセスを得ようとしているノードとの通信セッションのための装置、該装置は、下記を具備する:
    前記ノードと物理リンクを確立すると前記ノードから認証の要請を含む同期メッセージを送るための手段;
    前記認証の要請に応答するため、リンク設定、及びネットワーク・アクセスのためのパラメータ・オプションを含む要請メッセージを前記物理リンクを介して前記ノードから受け取るための手段;
    前記要請メッセージの前記パラメータ・オプションのセットの認可に関係する回答メッセージを前記物理リンクを介して送るための手段;
    前記ノードが前記パラメータ・オプションのセットの前記認可を受理する場合に前記物理リンクを介して前記ノードから前記ネットワーク・アクセスのためのデータを受け取るための手段;及び
    前記ノードが前記パラメータ・オプションのセットの前記認可を受理しない場合に前記パラメータ・オプションのセットとは異なる別の1つのパラメータ・オプションのセットを有する別の1つの要請メッセージを前記物理リンクを介して前記ノードから受け取るための手段。
  35. ネットワーク・アクセス・ノードを介したネットワーク・アクセスに対する通信セッションのための装置、該装置は下記を具備する:
    メッセージの中に認証、リンク設定、及びネットワーク・アクセスのためのパラメータ・オプションのセットを与えるための、及び前記ネットワーク・アクセス・ノードに前記メッセージを送るためのコンピュータ読み取り可能な命令を含むメモリ・ユニット;及び
    前記コンピュータ読み取り可能な命令を処理するために前記メモリ・ユニットに接続されたプロセッサ回路。
  36. 請求項35の装置、ここにおいて、前記メッセージは第1のメッセージであり、前記メモリ・ユニットは、前記第1のメッセージの前記パラメータ・オプションのセットの認可に関係する第2のメッセージを前記ネットワーク・アクセス・ノードから受け取るための、及び前記認可の前記パラメータ・オプションのセットがしきい値を満足する場合に前記ネットワーク・アクセスを開始するためのコンピュータ読み取り可能な命令、をさらに備える。
  37. 請求項35の装置、ここにおいて、前記メッセージは第1のメッセージであり、前記パラメータ・オプションのセットはパラメータ・オプションの第1のセットであり、前記メモリ・ユニットは、前記第1のメッセージの前記パラメータ・オプションの第1のセットの認可に関係する第2のメッセージを前記ネットワーク・アクセス・ノードから受け取るための、及び前記認可の前記パラメータ・オプションの第1のセットがしきい値を満足しない場合に前記パラメータ・オプションの第1のセットとは異なるパラメータ・オプションの第2のセットを有する第3のメッセージを前記ネットワーク・アクセス・ノードに送るためのコンピュータ読み取り可能な命令、をさらに備える。
  38. 請求項35の方法、ここにおいて、前記メッセージは第2のメッセージであり、前記装置は、前記第2のメッセージの前に前記ネットワーク・アクセス・ノードと物理リンクを確立すると前記ネットワーク・アクセス・ノードから認証の要請を含む第1のメッセージを受け取るために前記メモリ・ユニット中にコンピュータ読み取り可能な命令をさらに含む。
  39. 請求項35の装置、ここにおいて、前記コンピュータ読み取り可能な命令によって与えられた前記パラメータ・オプションのセットの前に前記ネットワーク・アクセス・ノードからPPP(2点間プロトコル)メッセージを受け取るのであれば、該メモリ・ユニットは、前記PPPメッセージに応答して別の1つのPPPメッセージを送ることを介して前記ネットワーク・アクセス・ノードと通信することを直ちに再ソートするためのコンピュータ読み取り可能な命令をさらに含む。
  40. 請求項39の装置、ここにおいて、該メモリ・ユニットは、前記PPPメッセージの対応するデータ・パケット・フォーマットに実質的に同じデータ・パケット・フォーマットを有する前記メッセージに対してデータ・パケットを与えるためのコンピュータ読み取り可能な命令、をさらに備える。
  41. IP(インターネット・プロトコル)をサポートする通信システムにおけるネットワーク・アクセス・ノードを介したネットワーク・アクセスに対する通信セッションのための装置、該装置は、下記を具備する:
    前記ネットワーク・アクセス・ノードと物理リンクを確立するため、認証の要請を含む同期メッセージを前記物理リンクを介して前記ネットワーク・アクセス・ノードから受け取るため、要請メッセージの中に前記認証の要請に応答するため、リンク設定、及びネットワーク・アクセスのためのパラメータ・オプションのセットを与えるため、前記物理リンクを介して前記ネットワーク・アクセス・ノードに前記要請メッセージを送るため、前記要請メッセージの前記パラメータ・オプションのセットの認可に関係する回答メッセージを前記物理リンクを介して前記ネットワーク・アクセス・ノードから受け取るため、及び前記認可の前記パラメータ・オプションのセットがしきい値を満足する場合に前記物理リンクを介して前記ネットワーク・アクセスを開始するためのコンピュータ読み取り可能な命令を含むメモリ・ユニット;及び
    前記コンピュータ読み取り可能な命令を処理するために前記メモリ・ユニットに接続されたプロセッサ回路。
  42. ネットワーク・アクセスを得ようとしているノードとの通信セッションのための装置、該装置は下記を具備する:
    認証、リンク設定、及びネットワーク・アクセスのためのパラメータ・オプションのセットを含んでいる第1のメッセージを前記ノードから受け取るため、及び前記パラメータ・オプションのセットの認可に関係する第2のメッセージを前記ノードに送るためのコンピュータ読み取り可能な命令を含んでいるメモリ・ユニット;及び
    前記コンピュータ読み取り可能な命令を処理するために前記メモリ・ユニットに接続されたプロセッサ回路。
  43. 請求項42の装置、ここにおいて、前記メモリ・ユニットは、前記認可の前記パラメータ・オプションのセットがしきい値を満足する場合に前記ノードから前記ネットワーク・アクセスのためのデータを受け取るため、及び前記認可の前記パラメータ・オプションの第1のセットがしきい値を満足しない場合に前記パラメータ・オプションの第1のセットとは異なるパラメータ・オプションの第2のセットを含んでいる第3のメッセージを前記ノードから受け取るためのコンピュータ読み取り可能な命令さらに含む。
  44. 請求項42の装置、ここにおいて、前記メモリ・ユニットは、前記第1のメッセージを前記ノードから受け取る前に前記ノードと物理リンクを確立すると前記ノードから認証の要請を含む同期メッセージを送るためのコンピュータ読み取り可能な命令をさらに含む。
  45. 請求項42の装置、ここにおいて、前記物理リンクを前記確立した後で、前記装置が前記ノードからPPP(2点間プロトコル)メッセージを受け取るのであれば、前記メモリ・ユニットは、前記PPPメッセージに応答して別の1つのPPPメッセージを送ることによって前記ノードと通信することを直ちに再ソートするためのコンピュータ読み取り可能な命令をさらに含む。
  46. 請求項45の装置、ここにおいて、該メモリ・ユニットは、前記PPPメッセージの対応するデータ・パケット・フォーマットに実質的に同じデータ・パケット・フォーマットを有する前記第2のメッセージに対してデータ・パケットを与えるためのコンピュータ読み取り可能な命令、をさらに備える。
  47. IP(インターネット・プロトコル)をサポートする通信システムにおけるネットワーク・アクセスを得ようとしているノードとの通信セッションのための装置、該装置は、下記を具備する:
    前記ノードと物理リンクを確立すると前記ノードから認証の要請を含む同期メッセージを送るため、前記認証の要請に応答するため、リンク設定、及びネットワーク・アクセスのためのパラメータ・オプションを含む要請メッセージを前記物理リンクを介して前記ノードから受け取るため、前記要請メッセージの前記パラメータ・オプションのセットの認可に関係する回答メッセージを前記物理リンクを介して送るため、前記ノードが前記パラメータ・オプションのセットの前記認可を受理する場合に前記物理リンクを介して前記ノードから前記ネットワーク・アクセスのためのデータを受け取るためのコンピュータ読み取り可能な命令を有するメモリ・ユニット;及び
    前記コンピュータ読み取り可能な命令を処理するために前記メモリ・ユニットに接続されたプロセッサ回路。
  48. コンピュータ読み取り可能な命令を含むコンピュータ読み取り可能な媒体、該コンピュータ読み取り可能な命令は下記を実行する:
    ネットワーク・アクセスの前に通信セッションのためのメッセージ中に認証、リンク設定、及びネットワーク・アクセスのためのパラメータ・オプションのセットを与えること;及び
    ネットワーク・アクセス・ノードに前記メッセージを送ること。
  49. コンピュータ読み取り可能な命令を含むコンピュータ読み取り可能な媒体、該コンピュータ読み取り可能な命令は下記を実行する:
    ネットワーク・アクセス・ノードと物理リンクを確立すること;
    認証の要請を含む同期メッセージを物理リンクを介して前記ネットワーク・アクセス・ノードから受け取ること;
    要請メッセージの中に前記認証の要請に応答するため、リンク設定、及びネットワーク・アクセスのためのパラメータ・オプションのセットを与えること;
    前記物理リンクを介して前記ネットワーク・アクセス・ノードに前記要請メッセージを送ること;
    前記要請メッセージの前記パラメータ・オプションのセットの認可に関係する回答メッセージを前記物理リンクを介して前記ネットワーク・アクセス・ノードから受け取ること;及び
    前記認可の前記パラメータ・オプションのセットがしきい値を満足する場合に前記物理リンクを介して前記ネットワーク・アクセスを開始すること。
  50. コンピュータ読み取り可能な命令を含むコンピュータ読み取り可能な媒体、該コンピュータ読み取り可能な命令は下記を実行する:
    認証、リンク設定、及びネットワーク・アクセスのためのパラメータ・オプションのセットを含んでいる第1のメッセージをネットワーク・アクセスを得ようとしているノードから受け取ること;及び
    前記パラメータ・オプションのセットの認可に関係する第2のメッセージを前記ノードに送ること。
  51. コンピュータ読み取り可能な命令を含むコンピュータ読み取り可能な媒体、該コンピュータ読み取り可能な命令は下記を実行する:
    当該ノードと物理リンクを確立するとネットワーク・アクセスを得ようとしている前記ノードのための認証の要請を含む同期メッセージを送ること;
    前記認証の要請に応答するため、リンク設定、及びネットワーク・アクセスのためのパラメータ・オプションを含む要請メッセージを前記物理リンクを介して前記ノードから受け取ること;
    前記要請メッセージの前記パラメータ・オプションのセットの認可に関係する回答メッセージを前記物理リンクを介して送ること;及び
    前記ノードが前記パラメータ・オプションのセットの前記認可を受理する場合に前記物理リンクを介して前記ノードから前記ネットワーク・アクセスのためのデータを受け取ること。
JP2007523860A 2004-07-30 2005-07-29 ネットワーク・アクセスのための早いリンク確立 Expired - Fee Related JP4625081B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US59247004P 2004-07-30 2004-07-30
US11/193,068 US9032065B2 (en) 2004-07-30 2005-07-28 Fast link establishment for network access
PCT/US2005/027069 WO2006015253A1 (en) 2004-07-30 2005-07-29 Fast link establishment for network access

Publications (2)

Publication Number Publication Date
JP2008508813A true JP2008508813A (ja) 2008-03-21
JP4625081B2 JP4625081B2 (ja) 2011-02-02

Family

ID=35376936

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007523860A Expired - Fee Related JP4625081B2 (ja) 2004-07-30 2005-07-29 ネットワーク・アクセスのための早いリンク確立

Country Status (10)

Country Link
US (1) US9032065B2 (ja)
EP (2) EP1779631B1 (ja)
JP (1) JP4625081B2 (ja)
KR (1) KR100919142B1 (ja)
AU (2) AU2005267792A1 (ja)
BR (1) BRPI0513886A (ja)
CA (1) CA2575233A1 (ja)
MX (1) MX2007001165A (ja)
RU (1) RU2351082C2 (ja)
WO (1) WO2006015253A1 (ja)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050141557A1 (en) * 2003-12-24 2005-06-30 Bradac Mark G. Method and apparatus for parallel processing of communication protocols
US7681007B2 (en) * 2004-04-15 2010-03-16 Broadcom Corporation Automatic expansion of hard disk drive capacity in a storage device
US20050231849A1 (en) * 2004-04-15 2005-10-20 Viresh Rustagi Graphical user interface for hard disk drive management in a data storage system
US20050235063A1 (en) * 2004-04-15 2005-10-20 Wilson Christopher S Automatic discovery of a networked device
US20050235364A1 (en) * 2004-04-15 2005-10-20 Wilson Christopher S Authentication mechanism permitting access to data stored in a data processing device
US9032065B2 (en) 2004-07-30 2015-05-12 Qualcomm Incorporated Fast link establishment for network access
KR100606005B1 (ko) * 2004-09-23 2006-07-28 삼성전자주식회사 Ipc를 위한 아이피 주소 관리 방법
US8233416B2 (en) * 2004-09-28 2012-07-31 Qualcomm Incorporated Handoff supports for networks having different link establishment protocols
US20060248252A1 (en) * 2005-04-27 2006-11-02 Kharwa Bhupesh D Automatic detection of data storage functionality within a docking station
JP4731603B2 (ja) * 2005-06-20 2011-07-27 エスケーテレコム株式会社 Cdma2000網における接続時間短縮のための高速データ呼接続方法
EP2061205A3 (en) 2007-11-16 2009-06-17 Hewlett-Packard Development Company, L.P. Method and apparatus for accessing a network
US8498666B2 (en) * 2010-05-05 2013-07-30 Nokia Siemens Networks Oy Carrier aggregation for two radio systems
US11128663B2 (en) * 2018-10-16 2021-09-21 Cisco Technology, Inc. Synchronizing link and event detection mechanisms with a secure session associated with the link

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001086156A (ja) * 1999-09-10 2001-03-30 Fujitsu Ltd 拡張pppフレームを用いた通信システム
JP2002501331A (ja) * 1998-01-12 2002-01-15 テレフオンアクチーボラゲツト エル エム エリクソン(パブル) リンク構成方法および装置
JP2004201087A (ja) * 2002-12-19 2004-07-15 Nec Corp 携帯電話機によるダイヤルアップ接続方法
JP2005244388A (ja) * 2004-02-25 2005-09-08 Hitachi Communication Technologies Ltd 通信端末装置及び通信接続装置
JP2006019934A (ja) * 2004-06-30 2006-01-19 Kddi Corp パケット交換網の呼設定方法

Family Cites Families (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6389010B1 (en) * 1995-10-05 2002-05-14 Intermec Ip Corp. Hierarchical data collection network supporting packetized voice communications among wireless terminals and telephones
JPH05502539A (ja) 1990-09-19 1993-04-28 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ 主データファイル及び制御ファイルが記録された記録担体、その記録方法及び装置、及びその読取装置
US5764903A (en) * 1994-09-26 1998-06-09 Acer America Corporation High availability network disk mirroring system
KR100243225B1 (ko) 1997-07-16 2000-02-01 윤종용 블록화효과 및 링잉잡음 감소를 위한 신호적응필터링방법 및신호적응필터
US6044271A (en) 1997-12-23 2000-03-28 Ericsson Inc. System and method for handing off a cellular call with system and capability change indication
AU6274099A (en) * 1998-09-30 2000-04-17 Netscout Service Level Corporation Managing computer resources
US6651105B1 (en) * 1998-11-12 2003-11-18 International Business Machines Corporation Method for seamless networking support for mobile devices using serial communications
US6370118B1 (en) * 1999-02-24 2002-04-09 Qualcomm Incorporated Simultaneous set up of PPP on AUM and a RM interface
KR100298371B1 (ko) 1999-06-09 2001-11-01 서평원 패킷 이동 통신망의 핸드 오버 수행 방법
US6614803B1 (en) * 2000-01-14 2003-09-02 Adtran Inc. Mechanism for conducting in-band communications between terminal adapter and digital terminal device during internet session
US7054291B2 (en) 2001-01-22 2006-05-30 Telefonaktiebolaget Lm Ericsson (Publ) Method of and system for mobile station abbreviated point-to-point protocol negotiation
JP2002291011A (ja) 2001-03-23 2002-10-04 Toshiba Corp 無線装置及び無線装置のハンドオーバ制御方法
US7447182B2 (en) * 2001-04-06 2008-11-04 Nortel Networks Limited Discovering an address of a name server
KR100471615B1 (ko) 2001-11-07 2005-03-08 유티스타콤코리아 유한회사 Radius 서버를 이용한 인터넷 서비스 프로바이더가입자의 아이피 주소 관리 시스템 및 그 방법
US6822952B2 (en) * 2001-11-26 2004-11-23 Qualcomm Incorporated Maintaining packet data connectivity in a wireless communications network
KR100807042B1 (ko) 2001-12-19 2008-02-25 주식회사 케이티 인터넷프로토콜망과 접속하는 무선접속망에서의 핸드오프방법
EP1472850B1 (en) 2002-01-29 2017-05-03 Koninklijke Philips N.V. A method and system for connecting mobile client devices to the internet
US6909899B2 (en) * 2002-03-11 2005-06-21 Qualcomm, Incoporated Method and apparatus for handoff in a communication system supporting multiple service instances
WO2003101025A2 (en) * 2002-05-28 2003-12-04 Zte San Diego, Inc. Interworking mechanism between cdma2000 and wlan
US7453844B1 (en) * 2002-10-22 2008-11-18 Hong Kong Applied Science and Technology Research Institute, Co., Ltd. Dynamic allocation of channels in a wireless network
US7280505B2 (en) 2002-11-13 2007-10-09 Nokia Corporation Method and apparatus for performing inter-technology handoff from WLAN to cellular network
DE60203312T2 (de) 2002-12-20 2006-04-27 Alcatel Verfahren und Vorrichtung zur Authentifizierung eines Benutzers
US8254276B2 (en) * 2003-08-05 2012-08-28 Qualcomm Incorporated Packet data services using version and capability information
US6958405B2 (en) 2004-03-09 2005-10-25 Arco Chemical Technology, L.P. Polymer-encapsulated titanium zeolites for oxidation reactions
US9032065B2 (en) 2004-07-30 2015-05-12 Qualcomm Incorporated Fast link establishment for network access
US8233416B2 (en) * 2004-09-28 2012-07-31 Qualcomm Incorporated Handoff supports for networks having different link establishment protocols

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002501331A (ja) * 1998-01-12 2002-01-15 テレフオンアクチーボラゲツト エル エム エリクソン(パブル) リンク構成方法および装置
JP2001086156A (ja) * 1999-09-10 2001-03-30 Fujitsu Ltd 拡張pppフレームを用いた通信システム
JP2004201087A (ja) * 2002-12-19 2004-07-15 Nec Corp 携帯電話機によるダイヤルアップ接続方法
JP2005244388A (ja) * 2004-02-25 2005-09-08 Hitachi Communication Technologies Ltd 通信端末装置及び通信接続装置
JP2006019934A (ja) * 2004-06-30 2006-01-19 Kddi Corp パケット交換網の呼設定方法

Also Published As

Publication number Publication date
RU2007107401A (ru) 2008-09-10
EP1779631A1 (en) 2007-05-02
CA2575233A1 (en) 2006-02-09
MX2007001165A (es) 2007-04-20
US20060095962A1 (en) 2006-05-04
AU2009235987A1 (en) 2009-11-26
BRPI0513886A (pt) 2008-05-20
KR100919142B1 (ko) 2009-09-28
JP4625081B2 (ja) 2011-02-02
WO2006015253A1 (en) 2006-02-09
AU2005267792A1 (en) 2006-02-09
EP2285062A1 (en) 2011-02-16
RU2351082C2 (ru) 2009-03-27
US9032065B2 (en) 2015-05-12
KR20070037652A (ko) 2007-04-05
EP1779631B1 (en) 2012-06-13

Similar Documents

Publication Publication Date Title
JP4625081B2 (ja) ネットワーク・アクセスのための早いリンク確立
JP5372890B2 (ja) 異なるリンク確立プロトコルを有するネットワークのためのハンドオフサポート
US8086748B2 (en) Avoiding PPP time outs during IPCP negotiations
JP4865805B2 (ja) 異なる認証証明書をサポートするための方法および機器
US7369529B2 (en) Method and apparatus for differentiating point to point protocol session termination points
JP2003516058A (ja) 無線遠隔通信システムにおける認証のための方法および装置
US7412528B2 (en) Avoiding PPP time-outs during IPCP negotiations
CN101057459B (zh) 对具有不同链路建立协议的网络的越区切换支持
CN101032148B (zh) 用于网络接入的通信会话的设备及方法
JP2006019934A (ja) パケット交換網の呼設定方法
KR20070067911A (ko) 피피피를 이용한 다수의 디엔스서버 주소제공 장치 및 방법

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20100202

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100216

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20100517

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20100524

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20100616

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20100623

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100716

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

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20101005

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20101104

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

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

Free format text: PAYMENT UNTIL: 20131112

Year of fee payment: 3

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees