JP2006019934A - パケット交換網の呼設定方法 - Google Patents

パケット交換網の呼設定方法 Download PDF

Info

Publication number
JP2006019934A
JP2006019934A JP2004194376A JP2004194376A JP2006019934A JP 2006019934 A JP2006019934 A JP 2006019934A JP 2004194376 A JP2004194376 A JP 2004194376A JP 2004194376 A JP2004194376 A JP 2004194376A JP 2006019934 A JP2006019934 A JP 2006019934A
Authority
JP
Japan
Prior art keywords
standard
message
information terminal
pdsn
field
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.)
Pending
Application number
JP2004194376A
Other languages
English (en)
Inventor
Tsunehiko Chiba
恒彦 千葉
Hiroyuki Shinpo
宏之 新保
Hidetoshi Yokota
英俊 横田
Akira Idogami
彰 井戸上
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.)
KDDI Corp
Original Assignee
KDDI Corp
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 KDDI Corp filed Critical KDDI Corp
Priority to JP2004194376A priority Critical patent/JP2006019934A/ja
Priority to US11/168,930 priority patent/US20060009197A1/en
Publication of JP2006019934A publication Critical patent/JP2006019934A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1073—Registration or de-registration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/12—Setup of transport tunnels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/69—Identity-dependent
    • H04W12/72—Subscriber identity

Abstract

【課題】PPP非標準のメッセージを用いて手順やデータ量を削減することにより呼設定に要する時間を短縮し、さらには端末あるいはPDSNが非標準メッセージに未対応であってもPPP標準の手順で呼設定手順を継続可能とする。
【解決手段】情報端末とPDSNとの間に無線リンクを確立する手順と、PDSNから情報端末へPPP標準のLCP Cfg-Requestメッセージを送信する手順と、PDSNから情報端末へPPP非標準のAltPPP Cfg-Requestメッセージを送信する手順と、情報端末が、非標準メッセージに対応していればAltPPP Cfg-Requestメッセージに応答して非標準のAltPPP Cfg-Responseを返信し、非標準メッセージに未対応であればLCP Cfg-Requestメッセージに応答して標準のLCP Cfg--Responseを返信する手順と、PDSNが、前記標準または非標準のCfg--Responseメッセージに基づいて情報端末の認証を行う手順とを含む。
【選択図】 図１

Description

本発明は、PPP（Point to Point Protocol）に準拠した手順でパケット交換網の呼設定を短時間で行う呼設定方法に関する。
インターネットに接続する際のトランスポートレイヤプロトコルとしてTCP(Transmission Control Protocol）が普及している。また、端末が公衆網を経由してインターネットへ接続する場合には、TCP/IP（TCP/Internet Protocol）の下位レイヤであるデータリンクレイヤプロトコルとして、PPP（Point to Point Protocol）が一般的に使用されている。また、第３世代携帯電話の標準方式cdma2000においても、データ通信の呼設定にPPPが採用されている。
図１８に示したように、3GPP2（3rd Generation Partnership Project 2）で標準化が進められている次世代移動体通信システムのcdma2000では、IPデータ通信を実現するために、ネットワーク側には基地局、基地局コントローラ、PCF (Packet Control Function)、PDSN (Packet Data Serving Node：パケットデータ交換ノード)およびAAA (Authentication, Authorization and Accounting)サーバが接続される。ユーザ側の無線情報端末(MS)には、AT (Access Terminal)およびTE (Terminal Equipment)が設置される。TEはパーソナルコンピュータなどの情報端末であり、ATは無線アクセス端末である。
前記基地局は、ATとの間に無線チャネルを確立する。基地局コントローラは基地局を制御する。PCFは基地局コントローラとPDSNとの間でデータ通信を制御する。PDSNは、無線アクセスネットワークとIPネットワークとを接続して論理リンクを終端する。PPPコネクションは、TEとPDSNとの間に確立されるデータ通信路である。R−Pコネクションは、PPPコネクションを確立するときにPCFとPDSNとの間に確立されるデータ通信路であり、PPPコネクションごとに確立され、ユニークな識別子が割り当てられている。
図１９は、cdma2000で規定されているSimple IP(SIP)コールでの認証時に、CHAP（Challenge Handshake Authentication Protocol ）を採用した場合のシーケンスを示した図である。ここで、CHAPは回線上でサポートされるセキュリティ機能であり、無認可のアクセスを防御するためにPPP カプセル化を用いる。
手順(a)：情報端末(MS)とRAN（無線アクセスネットワーク）との間に無線チャネルが確立される。
手順(b)：PCFとPDSNとの間に個別のR−Pコネクションが確立される。
手順(c)：無線端末がPDSNに対してCHAPによる認証を要求する。
手順(d)：PDSNが情報端末に対してCHAPによる認証を要求し、かつPDSNが受信可能な最大パケットサイズMRUを伝達する。これにより、情報端末と無線アクセスネットワークとの間に無線チャネルが確立される。
手順(e)：CHAPによる認証がPDSNにおいて了承される。
手順(f)：CHAPによる認証およびPDSNのMRUが情報端末において了承される。
手順(g)：CHAP認証のためのchallengeメッセージがPDSNから情報端末へ送信される。
手順(h)：情報端末によりchallenge responseが生成され、ユーザ名（Username）と共にPDSNへ送信される。
手順(i)：PDSNからAAAサーバへ、前記Username、CHAP challenge、CHAP responseが認証用プロトコルを用いて送信される。
手順(j)：AAAサーバからPDSNへ、認証結果（成功または失敗）および必要に応じて情報端末が利用するIPアドレス「y」が、認証用プロトコルを用いて送信される。
手順(k)：PDSNから情報端末へ認証結果が送信される。
手順(l)：認証が成功した場合には、PDSNが自身のIPアドレスとして「x」を使うことを情報端末に対して要求する。
手順(m)：アドレスを割り当てられていない情報端末は、自身のIPアドレスとして「0.0.0.0」の使用をPDSNに要求する。
手順(n)：PDSNが情報端末に対して、IPアドレス「y」の使用を要求する。
手順(o)：情報端末において、PDSNが自身のIPアドレスとして「x」を使うことが了承される。
手順(p)：情報端末が自身のIPアドレスとして「y」を使うことをPDSNへ要求する。
手順(q)：PDSNにおいて、情報端末がIPアドレス「y」を使うことが了承される。この後、情報端末がDNSサーバのアドレスなどを要求した場合には、それらに対して適切に応答する。
手順(r)：PDSNが認証サーバに対して課金の開始を要求する。
手順(s)：認証サーバがPDSNに対して課金の開始を了承する。
Simpson, "The Point to Point Protocol (PPP)", RFC 1661, July 1994. P.R0001, "Wireless IP Network Architecture based on IETF Protocols", 3GPP2, July 2000. P.S0001-A Version 3.0.0, "Wireless IP Network Standard", 3GPP2, July 2001. Simpson, "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996. A.S0007-0 version 1.0, "1xEV-DO Inter-Operability Specification (IOS) for CDMA 2000 Access Network Interfaces", 3GPP2, July 2001.
PPPはもともと、モデムを用いたダイアルアップ接続用に策定されたプロトコルであり、cdma2000では必ずしも利用しないパラメータおよびシーケンスが存在する。したがって、これをそのままパケット交換網のデータ通信における呼設定に利用すると効率が悪い。
例えば、SIPコールでの認証時にCHAPを用いる場合のシーケンス（図１９）では、手順(c)、(e)において情報端末がPDSNを認証する要求／応答メッセージが交換されるが、実際には行われないため冗長である。また、手順(m)において情報端末がIPアドレス(0.0.0.0)を送信したのち、PDSNから手順(n)において情報端末が使用すべきアドレスが送信されるが、IPアドレスは常にPDSNから付与されるために手順(m)のシーケンスは冗長である。
また、cdma2000 1X EV-DOでは上り回線の速度が低いため、できるだけ情報量を削減する必要がある。しかしながら、PPPでは上り下りで対象のシーケンスが実行されるので効率が悪い。
本発明の目的は、上記した従来技術の課題を解決し、SIPコールでの認証時に冗長な手順を省略すると共に、PPP非標準のメッセージを用いて手順やデータ量を削減することにより呼設定に要する時間を短縮し、さらには端末あるいはPDSNが前記非標準メッセージに未対応であってもPPP標準の手順で呼設定手順を継続できるパケット交換網の呼設定方法を提供することにある。
上記した目的を達成するために、本発明は、無線情報端末と、当該無線情報端末との間に無線リンクを確立する無線アクセスネットワークおよび当該無線アクセスネットワークを広域ネットワークに接続するPDSN（パケットデータ交換ノード)を含むネットワークシステムとから構成されるネットワークにおいて、前記情報端末とPDSNとの間にPPPコネクションを確立するための呼設定方法において、以下のような手段を含むことを特徴とする。
(1)情報端末とPDSNとの間に無線リンクを確立する手順と、PDSNから情報端末へ標準の設定要求メッセージを送信する手順と、PDSNから情報端末へ非標準の設定要求メッセージを送信する手順と、情報端末が、前記標準および非標準の設定要求メッセージのいずれか一方に応答して、それぞれ標準または非標準の設定応答メッセージを送信する手順と、前記PDSNが、前記標準または非標準の設定応答メッセージの内容に基づいて情報端末の認証を行う手順とを含み、情報端末は、非標準メッセージに対応しているか否かに応じて、非標準の設定要求メッセージに対して優先的に応答することを特徴とする。
(2)前記非標準メッセージに対応した情報端末が、標準の設定要求メッセージを受信した後、当該メッセージへ応答せずに所定時間だけ待機する手順と、前記待機時間内に非標準の設定要求メッセージを受信すると、当該メッセージに応答して非標準の設定応答メッセージを送信する手順と、前記待機時間内に非標準の設定要求メッセージを受信できないと、前記標準の設定要求メッセージに応答して標準の設定応答メッセージを送信する手順とを含むことを特徴とする。
(3)非標準のメッセージは、複数の標準メッセージに分散登録される複数の設定要求が一括登録されるオプションフィールドを含み、前記複数の設定要求が前記非標準のメッセージで一括送信されることを特徴とする。
(4)非標準のメッセージは、そのメッセージ種別およびオプションデータの代表値が登録されるオプションフィールドを含むことを特徴とする。
(5)オプションフィールドが複数ビットの領域を有し、各メッセージ種別およびそのオプションデータの代表値が所定の１ビットに登録されることを特徴とする。
(6)非標準の設定応答メッセージが、ドメイン代表値フィールド、サブドメイン代表値フィールド、ユーザ名構築ルールフィールドおよびPAP/CHAP拡張フィールドを含み、前記PDSNが、前記ドメイン代表値フィールド、サブドメイン代表値フィールド、ユーザ名構築ルールフィールドおよびPAP/CHAP拡張フィールドに登録された情報に基づいてユーザ名を構築する手順をさらに含み、前記ユーザ名を構築する手順が、ユーザ名構築ルールが第１タイプのときに、受信メッセージのPAP/CHAP拡張フィールドに登録されているユーザ名を認証用ユーザ名とする手順と、ユーザ名構築ルールが第２タイプのときに、情報端末のIMSI、前記ドメイン代表値と関連付けられたドメイン名、および前記サブドメイン代表値と関連付けられたサブドメイン名とに基づいて認証用ユーザ名を構築する手順とを含むことを特徴とする。
(7)前記ユーザ名を構築する手順がさらに、ユーザ名構築ルールが第３タイプのときに、情報端末のIMSIを認証用ユーザ名とする手順を含むことを特徴とする。
(1)請求項１の発明によれば、非標準メッセージに対応したPDSNからは、非標準の設定要求メッセージに加えて標準の設定要求メッセージも送信される。したがって、無線情報端末が非標準メッセージに対応していれば非標準の設定要求メッセージに応答して非標準の設定応答メッセージを返信できる一方、無線情報端末が非標準メッセージに非対応であっても標準の設定要求メッセージに応答して標準の設定応答メッセージを返信できる。
(2)請求項２の発明によれば、非標準メッセージに対応した情報端末は、PDSNから標準の設定要求メッセージを受信しても直ぐには応答せずに所定時間だけ待機し、この所定時間内に非標準の設定要求メッセージを受信できない場合だけ、前記標準の設定要求メッセージに応答して標準の設定応答メッセージを送信する。したがって、PDSNが非標準メッセージに対応していれば、当該メッセージに対して非標準のメッセージで優先的に応答できる一方、PDSNが非標準メッセージに未対応であっても標準のメッセージで応答できる。
(3)請求項３の発明によれば、非標準のメッセージには、複数の標準メッセージに分散登録されていた複数の設定要求が登録されて一括送信されるので、呼設定に要するメッセージ数を減じることができる。
(4)請求項４の発明によれば、標準メッセージの拡張フィールドにおいて数十ビットを占有していたオプションデータが、そのメッセージ種別と共に代表値としてオプションフィールドに登録されるので、拡張フィールドの短縮によるデータ量の削減が可能になる。
(5)請求項５の発明によれば、標準メッセージの拡張フィールドにおいて数十ビットを占有していたオプションデータを、非標準メッセージ上では１ビットで表現できるようになる。
(6)請求項６，７の発明によれば、情報端末からPDSNへ認証用のユーザ名そのものを送信することなく、当該ユーザ名をPDSN側において構築するのに必要な情報のみを送信すれば良いので、情報端末からPDSNへ送信する情報量を減じることができる。
以下、図面を参照して本発明の好ましい実施の形態について詳細に説明する。図１は、前記図１８に関して説明したネットワークシステムにおいて、cdma2000で規定されているSIPコールでの認証時に本発明を適用した場合のシーケンスを示した図であり、図１７は、その状態遷移図である。
手順(1)：リンク停止(Dead)フェーズにおいて、情報端末(MS)と無線アクセスネットワーク（RAN）との間に無線チャネルが確立される。
手順(2)：端末認証が成功した後、RANのPCFからPDSNへA11 Registration Request（登録要求）が送出される。
手順(3)：PDSNからPCFへ、手順(2)のA11 Registration Requestに応答してA11 Registration Reply（登録応答）が送出される。この結果、PCFとPDSNとの間にR-Pコネクション(A10/11)が確立されてリンク確立(Establish)フェーズへ移行する。
手順(4)：PDSNが情報端末との間にデータリンク層で無線チャネルを確立するために、初期(Initial)フェーズにおいてPPP標準のLCP(Link Control Protocol) Cfg-Request（設定要求）メッセージが送信される。このメッセージには、CHAPによる認証要求およびPDSNにおいて受信可能な最大パケットサイズMRUが登録されている。
手順(5)：PDSNから情報端末へ、前記LCP Cfg-Requestと同時に、本発明に固有であってPPP非標準のCfg-Request メッセージが送出される。なお、本実施形態では非標準メッセージと標準メッセージとを区別するために、非標準メッセージには添字「AltPPP」を付している。このAltPPP Cfg-Requestには、CHAP認証で使用する暗号鍵(challenge value)が含まれる。なお、実装に際しては、手順(4)のLCP Cfg-Requestと手順(5)のAltPPP Cfg-Requestとを同一のA10パケットに含めることが望ましい。その後、PDSNは待機(Waiting)フェーズへ移行する。
なお、本実施形態では情報端末におけるメッセージの受信漏れを防ぐために、当該メッセージは所定の複数回数だけ再送される。このとき、IDおよびChallenge value等は同一とする。
手順(6)：本実施形態では、情報端末が前記非標準メッセージに対応しているので、情報端末からPDSNへ、前記AltPPP Cfg-Requestメッセージに応答してPPP非標準のAltPPP Cfg-Response（設定応答）メッセージが送出される。このメッセージは、後に詳述する「ドメイン代表値フィールド」、「サブドメイン代表値フィールド」、「ユーザ名構築ルールフィールド」および「拡張(Extention)フィールド」を含み、拡張フィールドにはCHAP/PAP認証用のデータが登録される。その後、情報端末は手続(Proceeding)フェーズへ移行する。
手順(7)：PDSNは、AltPPP Cfg-Responseを情報端末から受信すると前記AltPPP Cfg-Requestの再送を停止し、AAA(Accounting, Authentication, and Authorization：課金、認証、認定）サーバへRADIUS Access-Requestメッセージを送信して手続(Proceeding)フェーズへ移行する。
このとき、PDSNで受信されたAltPPP Cfg-ResponseメッセージにCHAP/ResponseあるいはPAP/Requestが登録されておらず、かつPDSNにパスワードが事前登録されていないなど、RADIUS Access-Requestを送出できる条件が揃っていない場合には、PDSNから情報端末へAltPPP Cfg-Nackメッセージが送信される。
手順(8)：AAAサーバからPDSNへRADIUS Access-Acceptが送信される。このメッセージには、認証結果（成功または失敗）および必要に応じて情報端末で利用されるIPアドレスが含まれる。
手順(9)：PDSNから情報端末へAltPPP Cfg-Successが送出される。このメッセージには、IPv4アドレスやIPv6 Interface-ID、IPv4 DNSアドレス情報等が含まれる。その後、PDSNは開放(Opening)フェーズへ移行する。
手順(10)：情報端末は、前記AltPPP Cfg-Successの受信に応答してPDSNへAltPPP Cfg-Ackを返信し、その後、開放(Opening)フェーズへ移行する。この時点で情報端末はサービス開始できる。あるいは、手続(Proceeding)フェーズのままAltPPP Cfg-Nackを送信する。
PDSNは、AltPPP Cfg-Successを受信してPPPネットワークフェーズへ移行し、その後、標準のPPPにしたがってサービスを開始できる。なお、情報端末からAltPPP Cfg-Nackメッセージを受信した場合、開放(Opening)フェーズのままAltPPP Cfg-Successメッセージを送出する。このとき、IPCP/IPv6CP等のConfigure-Requestの該当するオプションをNackの内容にあわせて設定し、その他のパラメータについては過去に送出したAltPPP Cfg-Successメッセージと同一の内容とする。
手順(11)：PDSNから情報端末へRouter Advertisementが送出される。このメッセージには、IPv6 Prefix情報やIPv6 DNSアドレス情報が含まれる。
手順(12)：PDSNからAAAサーバに対してRADIUS Accounting Request（課金要求）が送信され、課金の開始が要求される。
手順(13)：AAAからPDSNに対してRADIUS Accounting Response（課金応答）が返信され、課金開始が了承される。
手順(14)：情報端末とPDSNとの間でデータ通信が開始される。
図２は、前記AltPPP（非標準）メッセージのフォーマットを示した図であり、RFC2153の規定通りに、メッセージの種別が登録されるCodeフィールドと、送信者の識別子が登録されるIDフィールドと、パケット全体（Code〜Extensionの最後まで）の長さが登録されるLenghフィールドと、エラー検出用のMagic-Numberフィールドとを含む。
前記AltPPPメッセージはさらに、ベンダあるいは通信事業者の識別子が登録されるOUIフィールドと、拡張ヘッダ(Extension)の有無およびメッセージの種別が登録されるKindフィールドと、ドメイン名を特定するための代表値が登録されるDomainフィールドと、サブドメイン名を特定するための代表値が登録されるSub-domainフィールドと、ユーザ名を利用したドメイン名の構築ルールが登録されるユーザ名構築ルールフィールドと、これまでは複数の標準メッセージに分散されて送信されていた各種の設定要求や、標準メッセージの拡張フィールドにおいて数十ビットを占有していたオプションデータを、そのメッセージ種別と共に代表するデータが登録されるReq-Optionsフィールドとを含む。本実施形態では、各データの論理和がReq-Optionsフィールドに登録される。
前記Kindフィールドには、本実施形態では拡張ヘッダが存在する場合に、その最上位ビットに「１」がセットされる。さらに具体的に説明すれば、図３に一例を示したように、Kindフィールドが「１」または「１２９」であれば、PDSNからMSへ送信されるConfigure-Requestメッセージであり、MSへCHAP challenge valueを通知したり、あるいは情報端末へA10コネクションが確立したことを通知するために利用される。
同様に、Kindフィールドが「２」または「１３０」であれば、情報端末からPDSNへ送信されるConfigure-Responseメッセージであり、PDSNへユーザ名あるいはパスワードに関する情報を通知したり、あるいはPDSNから通知してほしい情報(IPv4アドレス、etc)をオプションリクエストとして通知するために利用される。
同様に、Kindフィールドが「３」または「１３１」であれば、PDSNから情報端末へ送信されるConfigure-Successメッセージであり、サービスが許可された場合、必要な情報(IPv4アドレス、etc)を情報端末へ通知したり、あるいはPDSNが使用する情報(IPv4アドレス、etc)をオプションリクエストとして通知するために利用される。
同様に、Kindフィールドが「４」または「１３２」であれば、情報端末からPDSNへ送信されるConfigure-Ackメッセージであり、前記Configure-Successを受信したことをPDSNに通知するために利用される。
同様に、Kindフィールドが「５」または「１３３」であれば、PDSNから情報端末へ送信されるConfigure-Nakメッセージであり、サービスが許可されなかった場合に、これを情報端末へ通知したり、あるいはPDSNからのオプションリクエストに対して受け入れられない場合にreject/nakの内容をPDSNに通知するために利用される。
前記Domainフィールドには、図４に一例を示したように、ユーザ名を設定しない場合には「０」が設定され、ドメイン名として「ezweb.ne.jp」を指定する場合には「１」が設定される。同様に、使用頻度の高いドメイン名に関しては、それぞれ「２」，「３」…がドメイン名を代表するドメイン名代表値として登録される。
前記Sub-domainフィールドには、図５に一例を示したように、ユーザ名あるいはSub-domainを設定しない場合には「０」が設定され、サブドメイン名として「ev01」を指定する場合には「１」が設定される。同様に、使用頻度の高いサブドメイン名に関しては、それぞれ「２」，「３」…がサブドメイン名を代表するサブドメイン名代表値として登録される。
前記ユーザ名構築ルールフィールドには、後に図１４を参照して詳述するように、拡張フィールドのCHAP/ResponseまたはPAP/Requestに含まれるUsernameをユーザ名とする場合には「０」が登録され、A11メッセージに含まれるIMSI をユーザ名とする場合には「１」が登録され、IMSI@Sub-domain.Domainをユーザ名とする場合には「２」が登録される。ユーザ名構築ルールが「１」または「２」の場合は、拡張フィールドにUsernameが登録されている場合であっても無視される。
前記Req-Optionsフィールドには、これまで複数の標準メッセージに分散されて送信されていた各種の設定要求が一括して登録されると共に、標準メッセージの拡張フィールドにおいて数十ビットを占有していたオプションデータおよびそのメッセージ種別を代表する値が、いずれも１ビットで登録される。
図６は、Req-Optionsフィールドの各ビットの状態と設定内容との関係を示した図であり、従来はIPCP Cfg-Req メッセージおよびIPv6CP Cfg-Req メッセージの２つに分散されて送信されたIPv4およびIPv6の設定要求が、Req-Optionsフィールドの上位２ビットがセットされた唯一のAltPPP Cfg-Req メッセージを送信するだけで可能になる。これにより、本実施形態では呼設定手順の削減が可能になる。
さらに、例えば図１９の手順(m)では、情報端末がIPアドレスの割り当てをPDSNに対して要求する際に、IPCP Cfg-Req メッセージの拡張フィールドに３２ビットのオプションデータフィールドを確保し、当該フイールドにダミーアドレス[０．０．０．０]を登録して送信する必要があった。
しかしながら、本実施形態ではReq-Optionsフィールドの上位第３ビット目がセットされたAltPPP Cfg-Req メッセージを送信すれば、その拡張フィールドにダミーアドレスを登録することなく、PDSNに対してIPアドレスの割り当てを要求できる。同様に、情報端末がDNSのアドレスをPDSNに対して要求する際も、本実施形態ではReq-Optionsフィールドの上位第５ビット目あるいは第６ビット目がセットされたAltPPP Cfg-Req メッセージを送信すれば、その拡張フィールドにDSNのダミーアドレス[０．０．０．０]を登録することなく、PDSNに対してDNSのアドレスを要求できる。これにより、本実施形態では拡張フィールドの短縮によるデータ量の削減が達成される。
図７は、LCP/IPCP/IPv6CPにおける前記拡張フィールドのフォーマットを示した図であり、Protocol IDフィールドには、図８に一例を示したように、IANAにてアサインされたDLL Protocol Numbersが設定される。Codeフィールドには、図９にLCPおよびIPCPの場合を例にして示したように、LCP、IPCP等で規定されているCodeが設定される。Lengthフィールドには、オプションパラメータのバイト数がLCP、IPCP等で規定されている通りに設定される。
Type-X（X＝A，B…）フィールドには、図１０にLCPの場合を例にして示したように、オプションパラメータのTypeについてLCP、IPCP等で規定されている値が設定される。Length-Xフィールドには、オプションパラメータのバイト数がLCP、IPCP等で規定されている通りに設定される。Value-Xフィールドには、オプションパラメータについてLCP、IPCP等で規定されているValueが設定される。
図１１は、PAP/CHAP拡張フィールドのフォーマットを示した図であり、Protocol IDフィールドには、図１２に一例を示したように、IANAにてアサインされたDLL Protocol Numbersが設定される。Codeフィールドには、図１３にCHAPの場合を例にして示したようにCHAPで規定されているCodeが設定される。IDフィールドには、PAP、CHAP等で規定されている値が設定される。Lengthフィールドには、PAP、CHAP等で規定されている値が設定される。Dataフィールドには、PAP、CHAP等で規定されている値(Usernameを含む)が設定される。
次いで、PDSNが前記図１の手順(6)で受信したAltPPP Cfg-Responseメッセージの登録データに基づいてユーザ名を構築し、その認証を行う方法について、図１４のフローチャートに沿って説明する。
本実施形態では、前記AltPPP Cfg-Responseメッセージが、ドメイン代表値フィールド、サブドメイン代表値フィールド、ユーザ名構築ルールフィールドおよびPAP/CHAP拡張フィールドを含み、このAltPPP Cfg-Responseメッセージを受信したPDSNが、前記ドメイン代表値フィールド、サブドメイン代表値フィールド、ユーザ名構築ルールフィールドおよびPAP/CHAP拡張フィールドに登録されているデータに基づいて、以下の手順でユーザ名を構築し、その認証をAAAサーバへ要求する。
ステップＳ１では、AltPPP Cfg-Responseメッセージのユーザ名構築ルールフィールドが参照される。ステップＳ２では、参照結果に基づいてユーザ名構築ルールが判別される。このユーザ名構築ルールは、PDSNが前記各フィールドに登録されているデータに基づいて認証用のユーザ名を構築する際のルールを規定するものであり、ユーザ名構築ルールが「０」であればステップＳ３へ進む。ステップＳ３，Ｓ４では、PAP/CHAP拡張フィールドにCHAP/responseおよびPAP/requestのいずれが登録されているかが判定される。
PAP/CHAP拡張フィールドにCHAP/responseが登録されていればステップＳ５へ進み、CHAP/response拡張フィールドのDataフィールドに登録されているUsernameが認証用ユーザ名として登録される。ステップＳ６では、前記ステップＳ５で構築された認証用ユーザ名と、前記手順(5)で情報端末へ送信したAltPPP Cfg-Requestに登録したCHAP challenge valueと、前記CHAP/response拡張フィールドのDataフィールドに登録されているCHAPパスワードとが、前記手順(7)においてAAAサーバへ送信される。
これに対して、前記PAP/CHAP拡張フィールドにPAP/requestが登録されていればステップＳ７へ進み、PAP/request拡張フィールドのDataフィールドに登録されているUsernameが認証用ユーザ名として登録される。ステップＳ８では、前記ステップＳ７で構築された認証用ユーザ名と、前記PAP/request拡張フィールドのDataフィールドに登録されているユーザパスワードとが、前記手順(7)においてAAAサーバへ送信される。なお、前記PAP/CHAP拡張フィールドにCHAP/responseおよびPAP/requestのいずれもが登録されていなければ、ステップＳ９へ進んで「パスワードなし」接続となる。
一方、前記ステップＳ２において、ユーザ名構築ルールが「０」以外と判定されればステップＳ１０へ進む。ステップＳ１０では、ユーザ名構築ルールが「１」および「２」のいずれであるかが判定される。ユーザ名構築ルールが「２」であればステップＳ１１へ進み、前記AltPPP Cfg-ResponseメッセージのDomainフィールドに登録されているドメイン代表値、およびSub-domainフィールドに登録されているサブドメイン代表値が抽出される。ステップＳ１２では、前記各代表値と予め対応付けられているドメイン名およびサブドメイン名が検索される。
ステップＳ１３では、前記A11メッセージに含まれるIMSIと、前記検索されたドメイン名およびサブドメイン名とを組み合わせて構築される「IMSI@サブドメイン名．ドメイン名」がユーザ名として登録される。すなわち、図４に一例を示したように、ドメイン代表値が「１」であればドメイン名は「ezweb.ne.jp」となり、サブドメイン代表値が「１」であればサブドメイン名は「ev01」となる。したがって、この場合のユーザ名は「IMSI@ev01.ezweb.ne.jp」となる。なお、前記ステップＳ１０において、ユーザ名構築ルールが「１」と判定されていればステップＳ１８へ進み、前記IMSIそのものが認証用ユーザ名として登録される。
ステップＳ１４，Ｓ１５では、PAP/CHAP拡張フィールドにCHAP/responseおよびPAP/requestのいずれが登録されているかが判定される。CHAP/responseが登録されていればステップＳ１６へ進み、前記ステップＳ１３またはＳ１８で構築された認証用ユーザ名と、前記手順(5)で情報端末へ送信したAltPPP Cfg-Requestに登録したCHAP challenge valueと、前記CHAP/response拡張フィールドのDataフィールドに登録されているCHAPパスワードとが、前記手順(7)においてAAAサーバへ送信される。
これに対して、前記PAP/CHAP拡張フィールドにPAP/requestが登録されていればステップＳ１７へ進み、前記ステップＳ１３またはＳ１８で構築された認証用ユーザ名と、前記PAP/request拡張フィールドのDataフィールドに登録されているユーザパスワードとが、前記手順(7)においてAAAサーバへ送信される。
なお、PAP/CHAP拡張フィールドにCHAP/responseおよびPAP/requestのいずれもが登録されていなければステップＳ１９へ進み、ドメインまたはサブドメイン毎に予め設定されたパスワード(ドメインで共通)に基づいてCHAP計算が行われ、CHAPパスワードおよびCHAP-Challenge valueが、前記手順(7)においてAAAサーバへ送信される。
このように、本実施形態では情報端末からPDSNへ認証用のユーザ名そのものを送信することなく、当該ユーザ名をPDSN側において構築するのに必要な情報のみが送信されるので、情報端末からPDSNへ送信する情報量を減じることができる。
図１５は、前記非標準のAltPPPメッセージにPDSNのみが対応しており、情報端末(MS)が非対応の場合のシーケンスを示した図である。
情報端末(MS)では、手順(4)でPPP標準のLCP Cfg-Reqメッセージを受信し、これと同時に手順(5)でPPP非標準のAltPPP Cfg-Reqメッセージを受信するが、非対応の情報端末では非標準のAltPPP Cfg-Reqが無視され、標準のLCP Cfg-Reqに応答して、手順(6)でLCP Cfg-Ackメッセージが送信される。これ以後は従来のPPP標準のシーケンスが実行される。
このように、本実施形態ではPDSNから情報端末へ、PPP非標準のAltPPP Cfg-Reqメッセージのみならず、これと同時にPPP標準のLCP Cfg-Reqメッセージも送信されるので、非標準メッセージに未対応の情報端末であってもPDSNからの要求に応答できる。そして、これ以後はPPP標準のシーケンスが従来と同様に実行されるので、非標準メッセージに対応したPDSNと未対応の情報端末との間でも通信が可能になる。
図１６は、上記とは逆に非標準のAltPPPメッセージに情報端末のみが対応しており、PDSNが非対応の場合のシーケンスを示した図である。
情報端末(MS)は、手順(4)でPPP標準のLCP Cfg-ReqメッセージをPDSNから受信しても、これに対して直ぐには応答せずに、PPP非標準のAltPPP Cfg-Reqメッセージの受信に備えて所定時間だけ待機する。この待機時間内にAltPPP Cfg-Reqメッセージが受信されれば、図１に関して説明した実施形態と同様に、PPP非標準のAltPPP Cfg-Resメッセージを返信する。
これに対して、AltPPP Cfg-Reqメッセージを受信できずに待機時間がタイムアウトすると、前記手順(4)で受信したPPP標準のLCP Cfg-Reqに応答して、手順(5)でLCP Cfg-Ackメッセージが送信される。これ以後は従来のPPP標準のシーケンスが実行される。
このように、本実施形態では情報端末がPPP標準のLCP Cfg-Reqメッセージを受信しても、これに対して直ぐには応答せずに、PPP非標準のAltPPP Cfg-Reqメッセージの受信に備えて所定時間だけ待機し、待機時間が経過してもAltPPP Cfg-Reqを受信できない場合はPPP標準のシーケンスへ移行するので、非標準メッセージに対応した情報端末と未対応のPDSNとの間でも通信が可能になる。
SIPコールでの認証時に本発明を適用した場合のシーケンスを示した図である。 AltPPP（非標準）メッセージのフォーマットを示した図である。 Kindフィールドの登録内容の一例を示した図である。 Domainフィールドの登録内容の一例を示した図である。 Sub-domainフィールドの登録内容の一例を示した図である。 Req-Optionsフィールドの登録内容の一例を示した図である。 拡張フィールドのフォーマットを示した図である。 Protocol IDフィールドの登録内容の一例を示した図である。 Codeフィールドの登録内容の一例を示した図である。 Type-Xフィールドの登録内容の一例を示した図である。 PAP/CHAP拡張フィールドのフォーマットを示した図である。 PAP/CHAP拡張フィールドのProtocol IDフィールドの登録内容の一例を示した図である。 PAP/CHAP拡張フィールドのCodeフィールドの登録内容の一例を示した図である。 PDSNにおけるユーザ名の構築および認証方法を示したフローチャートである。 非標準のAltPPPメッセージにPDSNのみが対応し、情報端末が非対応の場合におけるシーケンスを示した図である。 非標準のAltPPPメッセージに情報端末のみが対応し、PDSNが非対応の場合におけるシーケンスを示した図である。 情報端末およいPDSNの状態遷移図である。 本発明が根起用されるパケット交換網のネットワーク構成を示した図である。 SIPコールでの認証時にCHAPを採用した場合のシーケンス図である。

Claims (7)

  1. 無線情報端末と、当該無線情報端末との間に無線リンクを確立する無線アクセスネットワークおよび当該無線アクセスネットワークを広域ネットワークに接続するPDSN（パケットデータ交換ノード)を含むネットワークシステムとから構成されるネットワークにおいて、前記情報端末とPDSNとの間にPPPコネクションを確立するための呼設定方法において、
    前記情報端末とPDSNとの間に無線リンクを確立する手順と、
    前記PDSNから情報端末へ標準の設定要求メッセージを送信する手順と、
    前記PDSNから情報端末へ非標準の設定要求メッセージを送信する手順と、
    前記情報端末が、前記標準および非標準の設定要求メッセージのいずれか一方に応答して、それぞれ標準または非標準の設定応答メッセージを送信する手順と、
    前記PDSNが、前記標準または非標準の設定応答メッセージの内容に基づいて情報端末の認証を行う手順とを含み、
    前記情報端末は、前記非標準メッセージに対応しているか否かに応じて、前記非標準の設定要求メッセージに対して優先的に応答することを特徴とするパケット交換網の呼設定方法。
  2. 前記非標準メッセージに対応した情報端末が、
    前記標準の設定要求メッセージを受信した後、当該メッセージへ応答せずに所定時間だけ待機する手順と、
    前記待機時間内に非標準の設定要求メッセージを受信すると、当該非標準の設定要求メッセージに応答して非標準の設定応答メッセージを送信する手順と、
    前記待機時間内に非標準の設定要求メッセージを受信できないと、前記標準の設定要求メッセージに応答して標準の設定応答メッセージを送信する手順とを含むことを特徴とする請求項１に記載のパケット交換網の呼設定方法。
  3. 前記非標準のメッセージは、複数の標準メッセージに分散登録される複数の設定要求が一括登録されるオプションフィールドを含み、前記複数の設定要求が前記非標準のメッセージで一括送信されることを特徴とする請求項１または２に記載のパケット交換網の呼設定方法。
  4. 前記非標準のメッセージは、そのメッセージ種別およびオプションデータの代表値が登録されるオプションフィールドを含むことを特徴とする請求項１または２に記載のパケット交換網の呼設定方法。
  5. 前記オプションフィールドが複数ビットの領域を有し、各メッセージ種別およびそのオプションデータの代表値が所定の１ビットに登録されることを特徴とする請求項４に記載のパケット交換網の呼設定方法。
  6. 前記非標準の設定応答メッセージが、ドメイン代表値フィールド、サブドメイン代表値フィールド、ユーザ名構築ルールフィールドおよびPAP/CHAP拡張フィールドを含み、
    前記PDSNが、前記ドメイン代表値フィールド、サブドメイン代表値フィールド、ユーザ名構築ルールフィールドおよびPAP/CHAP拡張フィールドに登録された情報に基づいてユーザ名を構築する手順をさらに含み、
    前記ユーザ名を構築する手順が、
    前記ユーザ名構築ルールが第１タイプのときに、受信メッセージのPAP/CHAP拡張フィールドに登録されているユーザ名を認証用ユーザ名とする手順と、
    前記ユーザ名構築ルールが第２タイプのときに、情報端末のIMSI、前記ドメイン代表値と関連付けられたドメイン名、および前記サブドメイン代表値と関連付けられたサブドメイン名とに基づいて認証用ユーザ名を構築する手順とを含むことを特徴とする請求項１ないし５のいずれかに記載のパケット交換網の呼設定方法。
  7. 前記ユーザ名を構築する手順がさらに、
    前記ユーザ名構築ルールが第３タイプのときに、情報端末のIMSIを認証用ユーザ名とする手順を含むことを特徴とする請求項６に記載のパケット交換網の呼設定方法。
JP2004194376A 2004-06-30 2004-06-30 パケット交換網の呼設定方法 Pending JP2006019934A (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2004194376A JP2006019934A (ja) 2004-06-30 2004-06-30 パケット交換網の呼設定方法
US11/168,930 US20060009197A1 (en) 2004-06-30 2005-06-29 Call setting method for packet exchange network

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2004194376A JP2006019934A (ja) 2004-06-30 2004-06-30 パケット交換網の呼設定方法

Publications (1)

Publication Number Publication Date
JP2006019934A true JP2006019934A (ja) 2006-01-19

Family

ID=35542026

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004194376A Pending JP2006019934A (ja) 2004-06-30 2004-06-30 パケット交換網の呼設定方法

Country Status (2)

Country Link
US (1) US20060009197A1 (ja)
JP (1) JP2006019934A (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008508813A (ja) * 2004-07-30 2008-03-21 クゥアルコム・インコーポレイテッド ネットワーク・アクセスのための早いリンク確立
KR100862729B1 (ko) 2007-03-12 2008-10-10 주식회사 케이티프리텔 Ｃｄｍａ 이동통신망의 데이터 호 처리 시스템 및 방법
US8233416B2 (en) 2004-09-28 2012-07-31 Qualcomm Incorporated Handoff supports for networks having different link establishment protocols

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8086853B2 (en) * 2005-03-18 2011-12-27 Microsoft Corporation Automatic centralized authentication challenge response generation
CN101204028B (zh) * 2005-06-20 2012-11-07 Sk电信有限公司 在cdma 2000网络中用于节省连接时间的快速数据链路连接方法
US7808970B2 (en) * 2005-06-30 2010-10-05 Motorola, Inc. Method of dynamically assigning mobility configuration parameters for mobile entities
US8176327B2 (en) * 2006-12-27 2012-05-08 Airvana, Corp. Authentication protocol
US9172707B2 (en) * 2007-12-19 2015-10-27 Microsoft Technology Licensing, Llc Reducing cross-site scripting attacks by segregating HTTP resources by subdomain

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0594244B1 (en) * 1992-10-19 2001-01-10 Koninklijke Philips Electronics N.V. Communication system and a private branch exchange to be used in such a communication system
US5999979A (en) * 1997-01-30 1999-12-07 Microsoft Corporation Method and apparatus for determining a most advantageous protocol for use in a computer network
JP3653569B2 (ja) * 1997-01-30 2005-05-25 マイクロソフト コーポレーション ビデオをオン・デマンドでレンダリングするｖｃｒに似た機能
US6006241A (en) * 1997-03-14 1999-12-21 Microsoft Corporation Production of a video stream with synchronized annotations over a computer network
US6014706A (en) * 1997-01-30 2000-01-11 Microsoft Corporation Methods and apparatus for implementing control functions in a streamed video display system
WO2000016541A1 (en) * 1998-09-15 2000-03-23 Microsoft Corporation Annotation creation and notification via electronic mail
GB2348089B (en) * 1999-03-17 2001-09-26 Samsung Electronics Co Ltd Inter-terminal communication method
US7082130B2 (en) * 2002-06-13 2006-07-25 Utstarcom, Inc. System and method for point-to-point protocol device redundancey
KR100640332B1 (ko) * 2003-01-28 2006-10-30 삼성전자주식회사 음성 서비스와 패킷 데이터 서비스를 지원하는 복합 액세스 단말의 크로스 호출 방법
WO2004112349A1 (en) * 2003-06-18 2004-12-23 Telefonaktiebolaget Lm Ericsson (Publ) Method, system and apparatus to support mobile ip version 6 services in cdma systems

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008508813A (ja) * 2004-07-30 2008-03-21 クゥアルコム・インコーポレイテッド ネットワーク・アクセスのための早いリンク確立
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
KR100862729B1 (ko) 2007-03-12 2008-10-10 주식회사 케이티프리텔 Ｃｄｍａ 이동통신망의 데이터 호 처리 시스템 및 방법

Also Published As

Publication number Publication date
US20060009197A1 (en) 2006-01-12

Similar Documents

Publication Publication Date Title
JP4865805B2 (ja) 異なる認証証明書をサポートするための方法および機器
AU776094B2 (en) Method and apparatus for authentication in a wireless telecommunications system
CN101843145B (zh) 用于建立连接时的分组数据网络网关的重新选择的系统和方法
EP1693988B1 (en) A method of the subscriber terminal selecting the packet data gateway in the wireless local network
EP2469961B1 (en) Method, apparatus and network system for tunnel establishment
US20070264997A1 (en) Method and System for Transparently and Securely Interconnecting a WLAN Radio Access Network Into a GPRS/GSM Core Network
JP2010016844A (ja) 無線通信システムにおいて準備データの転送を実行する方法及びシステム
US8433286B2 (en) Mobile communication network and method and apparatus for authenticating mobile node in the mobile communication network
EP2406976B1 (en) Communication of session-specific information to user equipment from an access network
US20020181498A1 (en) Method and apparatus for differentiating point to point protocol session termination points
WO2006135217A1 (en) System and method for otimizing tunnel authentication procedure over a 3g-wlan interworking system
KR20090127356A (ko) 서로 다른 링크 확립 프로토콜을 가진 네트워크들에 대한 핸드오프 지원
JP2008508813A (ja) ネットワーク・アクセスのための早いリンク確立
US20060009197A1 (en) Call setting method for packet exchange network
CN101057459B (zh) 对具有不同链路建立协议的网络的越区切换支持
KR100724232B1 (ko) Ｐｐｐ 링크에서의 ｉｐ 버전 타입별 프로토콜 식별 방법
US20050144260A1 (en) Method for setting up point-to-point protocol (PPP) connection between mobile communication terminal and base station
US6947406B2 (en) Establishing connections between terminal equipment and a mobile terminal
EP1692902B1 (en) System and method providing secure access and roaming support for mobile subscribers in a semi-connected mode
WO2007050610A2 (en) Methods and apparatus for use in a packet data network
WO2012022212A1 (zh) 用户设备接入方法、装置及系统
WO2014032542A1 (zh) 多连接建立的方法及系统
WO2013034056A1 (zh) 一种位置信息处理方法和系统
KR20070034188A (ko) 포인트 투 포인트 프로토콜을 이용한 멀티미디어 메시지서비스 정보 획득방법
JP2010028231A (ja) データネットワーク接続システム及びデータネットワーク接続方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20070309

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20081118

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20081203

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090202

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090401

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090514

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20090930