(57)【要約】【課題】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メッセージに基づいて情報端末の認証を行う手順とを含む。【選択図】        図１
2006019934.tif 000002
【特許請求の範囲】
【請求項１】
無線情報端末と、当該無線情報端末との間に無線リンクを確立する無線アクセスネットワークおよび当該無線アクセスネットワークを広域ネットワークに接続するPDSN（パケットデータ交換ノード)を含むネットワークシステムとから構成されるネットワークにおいて、前記情報端末とPDSNとの間にPPPコネクションを確立するための呼設定方法において、
前記情報端末とPDSNとの間に無線リンクを確立する手順と、
前記PDSNから情報端末へ標準の設定要求メッセージを送信する手順と、
前記PDSNから情報端末へ非標準の設定要求メッセージを送信する手順と、
前記情報端末が、前記標準および非標準の設定要求メッセージのいずれか一方に応答して、それぞれ標準または非標準の設定応答メッセージを送信する手順と、
前記PDSNが、前記標準または非標準の設定応答メッセージの内容に基づいて情報端末の認証を行う手順とを含み、
前記情報端末は、前記非標準メッセージに対応しているか否かに応じて、前記非標準の設定要求メッセージに対して優先的に応答することを特徴とするパケット交換網の呼設定方法。
【請求項２】
前記非標準メッセージに対応した情報端末が、
前記標準の設定要求メッセージを受信した後、当該メッセージへ応答せずに所定時間だけ待機する手順と、
前記待機時間内に非標準の設定要求メッセージを受信すると、当該非標準の設定要求メッセージに応答して非標準の設定応答メッセージを送信する手順と、
前記待機時間内に非標準の設定要求メッセージを受信できないと、前記標準の設定要求メッセージに応答して標準の設定応答メッセージを送信する手順とを含むことを特徴とする請求項１に記載のパケット交換網の呼設定方法。
【請求項３】
前記非標準のメッセージは、複数の標準メッセージに分散登録される複数の設定要求が一括登録されるオプションフィールドを含み、前記複数の設定要求が前記非標準のメッセージで一括送信されることを特徴とする請求項１または２に記載のパケット交換網の呼設定方法。
【請求項４】
前記非標準のメッセージは、そのメッセージ種別およびオプションデータの代表値が登録されるオプションフィールドを含むことを特徴とする請求項１または２に記載のパケット交換網の呼設定方法。
【請求項５】
前記オプションフィールドが複数ビットの領域を有し、各メッセージ種別およびそのオプションデータの代表値が所定の１ビットに登録されることを特徴とする請求項４に記載のパケット交換網の呼設定方法。
【請求項６】
前記非標準の設定応答メッセージが、ドメイン代表値フィールド、サブドメイン代表値フィールド、ユーザ名構築ルールフィールドおよびPAP/CHAP拡張フィールドを含み、
前記PDSNが、前記ドメイン代表値フィールド、サブドメイン代表値フィールド、ユーザ名構築ルールフィールドおよびPAP/CHAP拡張フィールドに登録された情報に基づいてユーザ名を構築する手順をさらに含み、
前記ユーザ名を構築する手順が、
前記ユーザ名構築ルールが第１タイプのときに、受信メッセージのPAP/CHAP拡張フィールドに登録されているユーザ名を認証用ユーザ名とする手順と、
前記ユーザ名構築ルールが第２タイプのときに、情報端末のIMSI、前記ドメイン代表値と関連付けられたドメイン名、および前記サブドメイン代表値と関連付けられたサブドメイン名とに基づいて認証用ユーザ名を構築する手順とを含むことを特徴とする請求項１ないし５のいずれかに記載のパケット交換網の呼設定方法。
【請求項７】
前記ユーザ名を構築する手順がさらに、
前記ユーザ名構築ルールが第３タイプのときに、情報端末のIMSIを認証用ユーザ名とする手順を含むことを特徴とする請求項６に記載のパケット交換網の呼設定方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、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を採用した場合のシーケンス図である。
【図１】
2006019934.tif 000003
【図２】
2006019934.tif 000004
【図３】
2006019934.tif 000005
【図４】
2006019934.tif 000006
【図５】
2006019934.tif 000007
【図６】
2006019934.tif 000008
【図７】
2006019934.tif 000009
【図８】
2006019934.tif 000010
【図９】
2006019934.tif 000011
【図１０】
2006019934.tif 000012
【図１１】
2006019934.tif 000013
【図１２】
2006019934.tif 000014
【図１３】
2006019934.tif 000015
【図１４】
2006019934.tif 000016
【図１５】
2006019934.tif 000017
【図１６】
2006019934.tif 000018
【図１７】
2006019934.tif 000019
【図１８】
2006019934.tif 000020
【図１９】
2006019934.tif 000021