JP2007519263A - 通信ネットワークにおけるネットワーク選択方法、関連のネットワーク及びそのためのコンピュータプログラムプロダクト - Google Patents

Abstract

少なくとも一人のユーザー（Ａ、Ｂ、Ｃ）は、ＩＰネットワークなどの通信ネットワーク上でアクセスネットワーク（ＡＮ、ＡＳＰ）を介しかつ複数のサポートされた訪問ネットワーク（ＶＳＰ１、ＶＳＰ２、ＶＳＰ３）のいずれかを通ってそれぞれのホームオペレータ（ＨＳＰＡ、ＨＳＰＢ、ＨＳＰＣ）にアクセスできる。ユーザーには、サポートされた訪問ネットワーク（ＶＳＰ１、ＶＳＰ２、ＶＳＰ３）のリストが伝えられ、よって、それぞれのホームオペレータ（ＨＳＰＡ、ＨＳＰＢ、ＨＳＰＣ）に到達するための経路として、サポートされた訪問ネットワーク（ＶＳＰ１、ＶＳＰ２、ＶＳＰ３）の一つを選択する可能性が与えられる。

Description

本発明は、通信ネットワーク、例えば有線及び無線ローカルエリアネットワーク（ＬＡＮ）などのＩＰネットワークでのネットワーク選択手順に関する。特に、本発明は、複数のネットワークオペレータが１つのＩＰネットワークを共用するような構成に関する。

例えば非特許文献１に記載のように、いくつかのネットワークオペレータとインターネットサービスプロバイダ（ＩＳＰ）が無線ＬＡＮ（ＷＬＡＮ）などのＩＰネットワークにおいて共同で存在し、かつローミングをサポートする可能性は、パブリックＷＬＡＮの展開にとって重要な要件である。ローミングを可能にしかつユーザーが適当なネットワークを選ぶことができるようにする能力もまた、いくつかの国の規制機関から要求されている。

現在、サービスプロバイダのデータネットワークへの利用可能なアクセス手順は、非常に限定された柔軟性しかもたない。実際、アクセスネットワークのプロバイダは、通常は他のインターネットプロバイダと取引契約を行っている。これらのプロバイダの顧客は、アクセスネットワークのプロバイダのネットワークアクセス設備を通してそれぞれのネットワークにアクセスすることができる。一般に、ネットワークへのアクセスを提供するオペレータは、他のプロバイダ又はオペレータとも協定を結ぶであろう。しかしながら、多くの場合、ネットワークへのアクセスを特定のユーザーに提供するオペレータは、当該ユーザーのホームオペレータと直接的なローミング協定は結ばず、ユーザーのホームオペレータとの協定を有し得る１又はそれより多い第３のオペレータとだけ結ぶ。

これらのプロバイダ又はオペレータの顧客は、一般にはこれらの協定を意識しないであろう。所与の無線インターネットサービスプロバイダ（ＷＩＳＰ）の取り扱いエリア内にいても、顧客は、どこに認証情報が送られるか、よってどんな転送ネットワークがそれらのデータを伝えるのかを知る可能性をもたないであろう。

対応するローミングのシナリオを図１に示す。ここでは、２人のユーザーＡ及びＢが示される。これらのユーザーは、２つのそれぞれのホームサービスプロバイダ、すなわちＨＳＰＡ及びＨＳＰＢにより提供されるサービスへの加入者である。ＡとＢの両方とも、そのアクセスネットワークＡＮを介して一般的アクセスサービスプロバイダＡＳＰから彼らのＨＳＰのサービスにアクセスすることを欲している。プロバイダＡＳＰは、例えばＶＳＰ１及びＶＳＰ２などの特定の訪問(visited)サービスプロバイダとの直接的なローミング協定を有し得る。また、これら両方が、ＨＳＰＡとのローミング協定を有してもよい。しかしながら、この後者の協定は、例えば認められた価格及びサービスの品質（ＱｏＳ）の点で異なる場合がある。アクセスプロバイダＡＳＰはまた、ＨＳＰＢとのローミング協定を有する別の訪問サービスプロバイダＶＳＰ３と直接的なローミング協定を有し得る。最後にアクセスプロバイダＡＳＰはまた、ユーザーＣの別の「ホーム」サービスプロバイダ、すなわちＨＳＰＣと直接的な協定を有し得る。

アクセスネットワークＡＮへのアクセスをリクエストするクライアントの認証中に、アクセスサービスプロバイダＡＳＰは、該プロバイダＡＳＰに直接接続されたサービスプロバイダ、すなわちＶＳＰ１、ＶＳＰ２、ＶＳＰ３又はＨＳＰＣのうちの１つに認証リクエストを送るであろう。実際、アクセスサービスプロバイダＡＳＰは、ローカルでユーザーＡ及びＢを認証する立場にはない。現在の構成では、アクセスサービスプロバイダＡＳＰは、ユーザーＡ又はＢからそのアイデンティティ以外のどんな入力データも受け取ることなく、自律的に対応する決定を行う。このような状況ゆえに、広告を出すネットワークすなわち所与のパブリックＷＬＡＮにおいて得られるネットワークオペレータの告知やネットワーク選択の必要性が非特許文献２などの文献に記載されている一方で、広告を出すネットワークの機構が依然として「論じられる」理由が存在する。

ＸＭＬメタ言語に基づいた代替の構成が、非特許文献３に提案されている。これに対応する構成は、ＸＭＬ事前コンフィギュレーションを必要とするという欠点を有する。さらに、ＸＭＬコードはいっそう多くのタグ付け情報をもつので、伝送するビット量がより多く必要となる。
３ＧＰＰ ＴＲ ２２．９３４ ｖ ６．１．０ "Ｆｅａｓｉｂｉｌｉｔｙ ｓｔｕｄｙ ｏｎ ３ＧＰＰ ｓｙｓｔｅｍ ｔｏ Ｗｉｒｅｌｅｓｓ Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ （ＷＬＡＮ） ｉｎｔｅｒｗｏｒｋｉｎｇ （Ｒｅｌｅａｓｅ ６）"、２００２年１２月 ３ＧＰＰ Ｓ２-０３１８９９ "ＷＬＡＮ Ｎｅｔｗｏｒｋ ｓｅｌｅｃｔｉｏｎ"、Ｓａｎ Ｄｉｅｇｏ Ｍｅｅｔｉｎｇ、２００３年５月１２-１６日（ｗｗｗ．３ｇｐｐ．ｏｒｇ／ｆｔｐ／ｔｓｇ＿ｓａ／ＷＧ２＿Ａｒｃｈ／ＴＳＧＳ２＿３２＿Ｓａｎ＿Ｄｉｅｇｏ／ｔｄｏｃｓ） ３ＧＰＰ Ｓ２-０３１８６４ "Ｎｅｔｗｏｒｋ Ｓｅｌｅｃｔｉｏｎ"、Ｓａｎ Ｄｉｅｇｏ Ｍｅｅｔｉｎｇ、２００３年５月１２-１６日（ｗｗｗ．３ｇｐｐ．ｏｒｇ／ｆｔｐ／ｔｓｇ＿ｓａ／ＷＧ２＿Ａｒｃｈ／ＴＳＧＳ２＿３２＿Ｓａｎ＿Ｄｉｅｇｏ／ｔｄｏｃｓ）

本発明の目的と概要
したがって、本発明の目的は、上記概説した従来技術の構成の欠点を解消する構成を提供することである。

本発明によると、この目的は、特許請求の範囲に記載の特徴を有する方法によって達成される。

本発明はまた、対応する通信ネットワーク、及び少なくとも１つのコンピュータのメモリにロード可能でかつ本発明の方法を実行するソフトウエアコード部分を含んだコンピュータプログラムプロダクトにも関する。少なくとも１つのコンピュータと言っているのは、明らかに、本発明の方法が、異なるタスクがネットワーク中の異なるコンピュータに割り当てられる状況において分散方式での実行に適応していることを考慮しているのを意味している。

要するに、第三者のアクセスネットワークを介してユーザーのプロバイダの一つのネットワークにアクセスすることを望んでいるユーザーが、例えば認証情報を送るべき中間のネットワーク（１又は複数）を選ぶことを認められた構成が記載される。

このように、ユーザーのプロバイダが他のプロバイダといくつかのローミング協定を有し、該他のプロバイダが、アクセスプロバイダとして機能するプロバイダと協定を有している場合には、ユーザーはまた、彼又は彼女のデータが辿るであろう経路を選択できる。

この構成は、アクセスネットワーク内で展開されるアクセス技術とは独立である。これは、無線（例えばＷＬＡＮネットワーク）又は有線（例えばダイヤルアップアクセスによるＰＳＴＮネットワーク）とし得る。簡単のため、以下では好ましい例として絶えず無線ＬＡＮを参照する。

アクセスサービスプロバイダとして働くプロバイダは、可能な選択肢をユーザーに知らせて選択できるようにすることを担当する。

ここに記載の構成は、例えば、既に上記で述べた文献３ＧＰＰ ＳＡ２-０３１８９９に提示された広告を出すネットワークの問題を解決する。

ここに記載の構成の好ましい実施態様は、ＤｉａｍｅｔｅｒベースプロトコルにおいてサポートされるいわゆるＤｉａｍｅｔｅｒエージェントに基づいている。その基本的な関連情報が、例えばＩＥＴＦ ｄｒａｆｔ-ｉｅｔｆ-ａａａ-ｄｉａｍｅｔｅｒ-１７．ｔｘｔ “Ｄｉａｍｅｔｅｒ Ｂａｓｅ Ｐｒｏｔｏｃｏｌ”、ｗｗｗ．ｉｅｔｆ．ｏｒｇに与えられている。Ｄｉａｍｅｔｅｒエージェントは、ネットワークアクセスなどのアプリケーション又はＩＰ移動性のために認証、許可及び課金（ＡＡＡ）のフレームワークを提供するのに用いられる。本質的には、Ｄｉａｍｅｔｅｒエージェントは、リレー、プロキシ、リダイレクト又は翻訳サービスを提供するＤｉａｍｅｔｅｒノードである。具体的には、ここに記載の構成では一定の変更を与え、この変更は、これらの認証リクエストが未知のレルム(realm)を有するときＤｉａｍｅｔｅｒエージェントにより特定のＤｉａｍｅｔｅｒリクエストが処理されて関係する答えが作られるという方法にて行われる。

現在、これらのリクエストは捨てられるか、最もよい場合で、デフォルトの認証サーバに送られる。提案された変更により、Ｄｉａｍｅｔｅｒエージェントは、認証リクエストを正しく処理して、それによりＤｉａｍｅｔｅｒエージェントが該リクエストを転送しなければならない訪問認証サーバを選択する可能性をユーザーに与えるのに必要な情報を検索できる。

当業者なら、この同じ構成がまた例えば遠隔認証ダイヤルインユーザーサービス（ＲＡＤＩＵＳ）と現在称されているプロトコルなどの他の「トリプルＡ」プロトコルと共に使用できることが分かるであろう。ただし、これ（ＲＡＤＩＵＳ）は、いわゆるプロキシ、リダイレクト及びリレーを含めてエージェントに対する明示的なサポートを提供しない。期待される反応は、異なるインプリメンテーションでは変わり得るので、定義されない。

特定のユーザーの「ホーム」ＩＳＰとのローミング協定を有するサポートされた訪問ネットワークのリストが、アクセスプロバイダとして機能するプロバイダの認証サーバによりユーザーに送られる。これは、好ましくは、拡張認証プロトコル（ＥＡＰ）を用いてユーザー認証手順中に行われる。この認証プロトコル（例えばＩＥＴＦ ｄｒａｆｔ-ｉｅｔｆ-ｅａｐ-ｒｆｃ２２８４ｂｉｓ-０３．ｔｘｔ、ｗｗｗ．ｉｅｔｆ．ｏｒｇに記載）は、複数の認証機構をサポートし、一般にリンク上で直接実行される。

このために、認証中に交換されるパケットの標準シーケンスに２つのメッセージを加えることからなるＥＡＰ手順の変更が望ましい。しかしながら、提案されるこの方法は、基礎的なＷＬＡＮ規格とは独立に一般的な認証機構によりサポートされるべきである。

当該構成の主な利点は、クライアント端末及びＡＡＡサーバにおいてどんな変更も実行できるので、ローカルアクセス装置を変更する必要性がないことである。

現在のところ好ましい本発明の実施態様では、ユーザーは識別子により一義的に識別される。

これは、例えばＲＦＣ ２４８６ ３ＧＰＰ Ｓ２-０３１８６４ “Ｎｅｔｗｏｒｋ ｓｅｌｅｃｔｉｏｎ”、Ｓａｎ Ｄｉｅｇｏ Ｍｅｅｔｉｎｇ、２００３年５月１２-１６日（ｗｗｗ．３ｇｐｐ．ｏｒｇ／ｆｔｐ／ｔｓｇ＿ｓａ／ＷＧ２＿Ａｒｃｈ／ＴＳＧＳ２＿３２＿Ｓａｎ＿Ｄｉｅｇｏ／ｔｄｏｃｓ）に記載のＮＡＩとして知られる例えばネットワークアクセス識別子である。

このような好ましい実施態様では、ユーザーは彼又は彼女のクレデンシャル(credential)をアクセスネットワークに送る（これは有線装置又は無線装置により行うことができる）。アクセスネットワークは、アクセスサービスプロバイダのデータセンターに設けられたバックエンド認証サーバにこれらのクレデンシャルを転送する。この認証サーバは、ＮＡＩのレルム部分により識別されたそのユーザーに対して利用可能なローミングネットワークを検索する。このタスクを遂行するため、このサーバは、該サーバと接続されたプロバイダに属するサーバとの会話を開始する。その結果、認証サーバは、ユーザーのオペレータ（１又は複数）とのローミング協定を保持しているオペレータのリストを検索する。この手順は、該ユーザーのホームサーバプロバイダとの直接的なローミング協定が存在しないようなユーザーに関して認証サーバが最初の認証リクエストを受け取ったとき１回だけ実行される。この認証サーバはまた、アクセスネットワークを介してオペレータのリストをユーザーに転送する。ユーザーは、彼又は彼女の好みにより、又は事前に設定した何らかのセッティングに基づいて、サーバから受け取ったリストからオペレータの一つを選ぶ。このようなリストが提示されると、ユーザーは、選択したオペレータ識別子をアクセスネットワーク中の認証サーバに送り返し、この認証サーバは、ユーザーのクレデンシャルを含めて認証リクエストを、ユーザーが選んだプロバイダに転送する。

もちろん、アクセスプロバイダとして機能するプロバイダが、ユーザーのホームサービスプロバイダとの直接的なローミング協定を有する場合には、ユーザーには、１つのオペレータのみから成るリストが提示される。代わりに、このような場合には、認証サーバは、単に、認証リクエストをユーザーのホームサービスプロバイダに直接転送することを決定することもできる。

それから、ユーザーは、彼のサービスプロバイダとの通常の認証手順を実行する（例えば、ＥＡＰなどの標準的な機構を用いて）。この手順のステップを実行する間、認証情報は、以前に選択されたオペレータのネットワークを通って流れる。具体的には、認証サーバが、認証メッセージを訪問認証サーバに転送する。これらは、該メッセージをホームオペレータサーバ、すなわちホーム認証サーバにプロキシ(proxy)する。アクセスサービスプロバイダが認証リクエストを転送するプロバイダについて選択する可能性が与えられるので、ユーザーは、実際には、例えば認められた価格及びサービスの品質（ＱｏＳ）に関して選択するその後の可能性を有しつつ、そのデータフローをルーティングする。

以下、単に例として添付図面を参照して本発明を説明する。

本発明の好ましい実施態様の詳細な説明
ここで与えられる例示的で詳細な説明では、パブリック・ランド・モバイル・ネットワーク（ＰＬＭＮ）に適用されるネットワーク選択手順を参照する。具体的には、ＷＬＡＮ上で３ＧＰＰシステムにアクセスするユーザー機器を例として考える。

大まかに言えば、この手順は、文献３ＧＰＰ ＴＳ ２３．２３４ “３ＧＰＰ ｓｙｓｔｅｍ ｔｏ Ｗｉｒｅｌｅｓｓ Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ （ＷＬＡＮ） Ｉｎｔｅｒｗｏｒｋｉｎｇ； Ｓｙｓｔｅｍ Ｄｅｓｃｒｉｐｔｉｏｎ （Ｒｅｌｅａｓｅ ６）”に記載のネットワーク選択原理に従う。

無線アクセスネットワークの共有又はプロバイダ選択は、相互に作用する３ＧＰＰ-ＷＬＡＮにおけるネットワーク選択のために用いられる。図２では、単純化された相互に作用するモデルが提示されており、すべてのプレーヤー、すなわちＷＬＡＮインターネットサービスプロバイダＷＬＡＮ ＩＳＰ、訪問される(visited)３ＧオペレータＶＳＰ、及びホーム３ＧオペレータＨＳＰが示されている。

３Ｇ加入者は、自身のそれぞれの３ＧＰＰオペレータネットワーク内でリソースを利用しサービスにアクセスすることを欲していると仮定される。

相互に作用する３Ｇ-ＷＬＡＮの目標は、３ＧＰＰサービスと機能性をＷＬＡＮアクセス環境まで拡張することである。よって、ＷＬＡＮは、事実上、３ＧＰＰシステムに対して補完的な無線アクセス技術になる。相互に作用する３Ｇ-ＷＬＡＮは、基礎となるＷＬＡＮ無線技術とは独立している。

このＷＬＡＮは、ＷＬＡＮ自体内か、又はＷＬＡＮに接続されたネットワーク内に設け得るサービスへのアクセスを提供する。しかしながら、合理的には、ＷＬＡＮは３Ｇオペレータすべてとのローミング協定は有していないと仮定される。通常は、ＷＬＡＮオペレータ（又はＷＬＡＮサービスプロバイダ）は、他の３Ｇネットワーク（ユーザーの観点からは「ホーム」ネットワークプロバイダを含む）に向けて接続性を提供するために、限定数の３Ｇオペレータ（すなわち「訪問」オペレータＶＳＰ）と技術的な協力関係になるであろう。

具体的には、図３に示すようなシナリオを考える。
ここには、それぞれＷＩＳＰ１、ＷＩＳＰ２、ＷＩＳＰ３で示された重なり合った１組のＷＬＡＮインターネットサービスプロバイダ（ＷＩＳＰ）によりカバーされるエリアが示されている。プロバイダＷＩＳＰ１、ＷＩＳＰ２、及びＷＩＳＰ３の各々は、場合によっては、異なるＷＬＡＮチャンネル及びいくつかの３Ｇオペレータ３Ｇ１、３Ｇ２、３Ｇ３との異なる（ただし限定するものではない）ローミング協定によって区別される。

このエリアに入る一般のユーザーは、彼又は彼女がその加入者であるユーザー自身の特定の「ホーム」ネットワーク３ＧＡ、３ＧＢ、又は３ＧＣへの接続を望むかもしれない。これは、認証されるためであり、また、ＷＬＡＮ自体内か又はＷＬＡＮに接続されかつホーム３Ｇオペレータとの特定の協定を有するネットワーク内に設けられたサービスにアクセスするためである。

ここに記載の構成は、シグナリング経路を選択してホームネットワークから認証及び許可を得る可能性をユーザーに与えるものである。実際には、後に続くユーザーデータフローはどれも、シグナリングに用いられた同一経路を辿る可能性がおそらく高い。よって、例えば認められた価格及びサービスの品質（ＱｏＳ）に関して様々な商業協定から選択する可能性がユーザーに存在する。

図３を参照すると、３Ｇオペレータ３ＧＡに設けられたサービスに加入しているユーザーは、２つの異なる方法にて、例えば、訪問されるオペレータ３Ｇ１及び３Ｇ２のどちらかを介して関連のホームネットワークに到達できる。

従来技術では、これら２つから選択するための特定の機構を提供できない。
このことは、例えばＩＥＥＥ ８０２．１１規格に当てはまるが、同様の事が他のＷＬＡＮ技術にも当てはまる。実際、ＩＥＥＥ ８０２．１１ ＷＬＡＮの場合、ＷＬＡＮネットワーク名は、いわゆるＳＳＩＤ（サービス・セットＩＤ）情報要素にてＷＬＡＮビーコン信号上で伝えられる。また、プローブ・リクエスト・メッセージを送り、もしアクセスポイントがＩＥＥＥ ８０２．１１により定義されたように請求されたＳＳＩＤをサポートしているならばリプライを受信することにより、ユーザー機器（ＵＥ）には特定のＳＳＩＤのサポートをアクティブに請求する可能性が存在する。しかしながら、このような従来技術の構成では、ユーザーは、サポートされた訪問ネットワークの組を認識しないであろうし、よって、場合によってはこの機構を用いることにより所望のホームオペレータに到達する経路を選択するであろう。

ここに記載の構成は、ユーザーのホームインターネットサービスプロバイダとのローミング協定を有するサポートされた訪問ネットワークのリストをユーザーに送るＷＩＳＰ認証サーバの機構を提案している。

これは、ユーザーの認証手順中、すなわち、ユーザーが彼又は彼女のクレデンシャルを発送するときに行われる。

相互に作用するＷＬＡＮ-３Ｇシステムの場合、その点でのサポートは、例えば現在ＥＡＰと称されている拡張認証プロトコルなど一般の認証機構（基礎となるＷＬＡＮ規格とは独立）により提供され得る。３Ｇユーザーの場合、転送される認証機構は、このように例えばＩｎｔｅｒｎｅｔ Ｄｒａｆｔ “ｄｒａｆｔ-ａｒｋｋｏ-ｐｐｐｅｘｔ-ｅａｐ-ａｋａ-０９．ｔｘｔ”、“ＥＡＰ ＡＫＡ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ”、２００３年２月、ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｉｎｔｅｒｎｅｔ-ｄｒａｆｔｓ／ｄｒａｆｔ-ａｒｋｋｏ-ｐｐｐｅｘｔ-ｅａｐ-ａｋａ-０９に記載の既存のＥＡＰ／ＡＫＡ認証機構に基づき得る。代替案が、Ｉｎｔｅｒｎｅｔ Ｄｒａｆｔ “ｄｒａｆｔ-ｈａｖｅｒｉｎｅｎ-ｐｐｐｅｘｔ-ｅａｐ-ｓｉｍ-１０．ｔｘｔ”、“ＥＡＰ ＳＩＭ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ”、２００３年２月、ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｉｎｔｅｒｎｅｔ-ｄｒａｆｔｓ／ｄｒａｆｔ-ｈａｖｅｒｉｎｅｎ-ｐｐｐｅｘｔ-ｅａｐ-ｓｉｍ-１０ｔｘｔに記載のＥＡＰ／ＳＩＭ認証機構により示されている。

対応するアクセス認証サーバ（ＡａｕＳ）は、ＷＩＳＰ（すなわち図３中でＷＩＳＰ１、ＷＩＳＰ２及びＷＩＳＰ３として示される要素のいずれか）内に存在すると仮定される。一般に、これは、Ｄｉａｍｅｔｅｒプロキシ／リレー（ＤＲＬ）エージェントの機能を有するＤｉａｍｅｔｅｒノードである。

訪問される認証サーバ（ＶａｕＳ）は、訪問される３Ｇオペレータ（すなわち図３中の３Ｇ１、３Ｇ２又は３Ｇ３のいずれか）内に存在すると仮定される。この訪問認証サーバ（ＶａｕＳ）はまた、Ｄｉａｍｅｔｅｒリレー／プロキシエージェント（ＤＲＬ）として機能し且つＤｉａｍｅｔｅｒリダイレクトエージェント（ＤＲＤ）としても機能するＤｉａｍｅｔｅｒノードである。Ｄｉａｍｅｔｅｒインプリメンテーションは、あるリクエストに対して１形式のエージェントとして働き、かつそれ以外に対して別形式のエージェントとして働き得る。よって、Ｄｉａｍｅｔｅｒエージェントは、
− ＡａｕＳにて識別される訪問認証サーバ（ＶａｕＳ）に向けて転送されなければならないそれらのリクエストに対してプロキシ／リレーエージェント、及び
− 未知のレルムを有するそれらの認証リクエストに対してリダイレクトエージェント、
として働くようにＶａｕＳ中に存在する。
図５は、以下で説明する手順を詳しく示す。

第１ステップとして、アクセスネットワーク装置は、ユーザーのクレデンシャルについてＥＡＰリクエスト／アイデンティティ・メッセージをユーザー機器（ＵＥ）に送る。ＥＡＰパケットは、任意の無線ＬＡＮ技術固有のプロトコル内に封入されて無線ＬＡＮインターフェース上に転送される。

第２のステップとして、このＵＥは、ＲＦＣ２４８６に規定されたネットワークアクセス識別子（ＮＡＩ）フォーマットに従ってＥＡＰレスポンス／アイデンティティ・メッセージ中のユーザーのアイデンティティを、アクセスネットワーク装置に送る。このＮＡＩは、ＡａｕＳが３Ｇホームネットワーク名を引き出すことを可能にする識別子を含む。例えば、このＵＥは、ユーザーＡのアイデンティティをｕｓｅｒｎａｍｅ＠ＨＳＰＡ．ｃｏｍとして送るか、又はＳＩＭモジュールを識別手段として使用する顧客の場合には、ＩＭＳＩ＠ＨＳＰＡ．ｃｏｍとして送ることができる。

第３ステップとして、アクセスネットワーク装置は、クライアントのＥＡＰレスポンス・パケットをそのリレーＤＲＬ ＡａｕＳに転送する。一般に、これは、Ｄｉａｍｅｔｅｒユーザー名属性中のクライアントのアイデンティティと共にＤｉａｍｅｔｅｒパケット内に封入される。

示されるように、ここで考えている例示的な実施態様では、ＡａｕＳは、Ｄｉａｍｅｔｅｒ-ＥＡＰ リクエスト・メッセージ中のレルムを探索するよう適応したＤｉａｍｅｔｅｒプロキシ／リレー（ＤＲＬ）エージェントである。実際、一般にはこれは、ＨＳＰＡ．ｃｏｍについてそのＤｉａｍｅｔｅｒルーティングテーブル中にルーティングエントリを有さない。というのは、ＶａｕＳ １、ＶａｕＳ ２、ＶａｕＳ ３及びホームサービスプロバイダＨＳＰＣのみに対して直接的なローミング協定が存在するだけだからである。

一般にレルムベースのルーティングテーブルは、レルムがルーティングテーブル中に存在するレルムのどれとも対応しない認証リクエストのすべてが、すべてのＶａｕＳ／ＤＲＤにリダイレクトされるように、構成される。よって、ＡａｕＳは、リダイレクトリクエストをすべてのＶａｕＳ／ＤＲＤに送り、ユーザーのリクエストを保留状態におく。本質的に、これは、当該方法において第４のステップである。

その次の第５ステップとして、すべてのＶａｕＳ／ＤＲＤが、この場合、ホーム認証サーバに到達するのに必要な情報と共にリダイレクト通知をＡａｕＳ／ＤＲＬに戻すリダイレクトエージェントとして機能する。その関連情報は、リダイレクトホストＡＶＰ（属性値ペア(Attribute Value Pair)）の１以上の場合に応答メッセージ中に挿入される。

本質的に、以下のイベントが上述した例示的なシナリオにおいて生じる。

ＶａｕＳｌ（ＤＲＤ）は、ホームサービスプロバイダＨＳＰＡとのローミング協定を有し、よって、リダイレクト-ホストＡＶＰ＝ＶａｕＳ １を設定することによりリダイレクト通知をＡａｕＳに戻す。このように、ＡａｕＳは、ＶａｕＳ １が認証リクエストをホームサービスプロバイダＨＳＰＡに転送できることを知っている。次に、ＡＶＰ中の値ＶａｕＳ １が、ＡａｕＳにより使用され、好ましいオペレータの選択を可能にすべくユーザーに提示されるＰＬＭＮリストを形成する。

また、ＶａｕＳ ２（ＤＲＤ）は、ホームサービスプロバイダＨＳＰＡとのローミング協定を有し、よって、リダイレクト-ホストＡＶＰ＝ＶａｕＳ ２を設定することによりリダイレクト通知をＡａｕＳに戻す。このように、ＡａｕＳは、ＶａｕＳ２が認証リクエストをホームサービスプロバイダＨＳＰＡに転送できることを知っている。次に、ＡＶＰ中の値ＶａｕＳ ２が、ＡａｕＳにより使用され、好ましいオペレータの選択を可能にすべくユーザーに提示されるＰＬＭＮリストを形成する。

ＶａｕＳ ３（ＤＲＤ）は、ホームサービスプロバイダＨＳＰＡとのローミング協定を有さないが、ホームサービスプロバイダＨＳＰＢとのこのような協定を１つ有するので、リダイレクト-ホストＡＶＰ＝未知と共にリダイレクト通知を戻さなければならない。このように、ＡａｕＳは、ＶａｕＳ ３が認証リクエストをホームサービスプロバイダＨＳＰＡに転送できないことを知っている。ＶａｕＳ ３をＰＬＭＮリスト中に挿入するためでなく、ＡａｕＳに示すために、ＡＶＰ中の値は未知(Unknown)が用いられる。

以下に列挙したＡＶＰなどの他の情報は、リダイレクト通知中に含まれ得る。

− リダイレクト-ホスト-使用(Usage)ＡＶＰ：このＡＶＰは、どのようにしてＡａｕＳ／ＤＲＬがリダイレクト-ホストからのルーティングエントリを使用するかを示す。オール-レルム(ALL-REALM)に設定されると、リクエストされたレルムに向かうメッセージすべてが、リダイレクト-ホストＡＶＰ中で指定されたホストに送られる。ここに記載の例では、レルムＨＳＰＡと共にすべての認証リクエストが、ＡａｕＳ／ＤＲＬによりＶａｕＳ １又はＶａｕＳ ２に送られ得る。

− リダイレクト-最大-キャッシュ-タイムＡＶＰ：このＡＶＰは、リダイレクト-ホストの結果として生成されるルートテーブルエントリがキャッシュ(cached)される最大秒数を含む。このＡＶＰは、なんらかの未知のレルムに対して認証リクエストを再度受信したとき、すべてのＶａｕＳ／ＤＲＤに質問しなければならないことを回避する。例えば、ここに記載の例では、ＡａｕＳは、同時に１より多い認証リクエストをレルム「ＨＳＰＡ．ｃｏｍ」と共に受信できる。このように、これはユーザーに送る利用可能なＶａｕＳ／ＰＬＭＮリストをすでに有する。タイマーが終了すると、必要ならＡａｕＳが、リダイレクションプロセスを繰り返し、かくしてローミング協定に関するルーティングエントリを更新する。ＡａｕＳは、任意形のリダイレクトメッセージを所与のレルムに対するすべてのＶａｕＳ／ＤＲＤに送ることができる。ＶａｕＳは、任意形のリダイレクトレスポンスメッセージで返答することができる。ＡａｕＳについての代替案は、特定のレルムに対する新しい認証リクエストを待ち、リダイレクションプロセスをこの時にのみ繰り返すことである。

ＡａｕＳがすべてのＶａｕＳ（ＤＲＤ）からリダイレクト通知を受信したら、特定のレルムに対するレルムベースのテーブルにルーティングエントリを加える条件下となる。ここに記載の例では、リダイレクション手順の後、ＡａｕＳルーティングテーブル中には、どの認証リクエストをＶａｕＳ １又はＶａｕＳ ２に転送できるかに基づいてＨＳＰＡレルムに対するエントリが存在する。

図６に示されるように、もしＡａｕＳがリダイレクト-ホストＡＶＰ＝未知と共にすべてのリダイレクト通知を受信すると、上述した第３ステップで受信した認証リクエストを、そのルーティングテーブルのデフォルトエントリにおいて指定されたＶａｕｓに転送する。この操作は、失敗の通知の受信後にのみ実行される。

他のＨＳＰＡユーザーの認証のため、ＡａｕＳはすでにエントリを有し、その結果、リダイレクション手順は必要ない。このような場合、ＡａｕＳは、ルーティングテーブルを検索し、既に存在しているエントリを見つけ、上述した第３ステップの完了後、上述した第６ステップ又はその変形に直接進む。

当該変形とは、１つのＶａｕＳだけが認証リクエストを関係のあるＨＳＰに転送できる場合、すなわち、このようなＨＳＰとのローミング協定を有するただ１つのＶａｕＳが存在する場合をいう。

ここに記載の例では、ユーザーＢが彼の認証リクエストを送るとき（これは本質的には上述した第３ステップである）、ＡａｕＳは、ＨＳＰＢレルムに対するルーティングエントリを有さない。したがって、これはリダイレクション手順を用いて必要な情報を検索する。この場合、ＡａｕＳは、有効なリダイレクト-ホストＡＶＰと共にただ１つのリダイレクションメッセージを受信する。このメッセージは、ＶａｕＳ ３から来るが、これのみが、プロバイダＨＳＰＢとのローミング協定を有する。

好ましいオペレータ（ＰＬＭＮ）を選ぶ可能性は、ユーザーＢには存在しない。よって、リダイレクト通知メッセージが受信されるやいなや、ＡａｕＳは直接ユーザーのクレデンシャルをＶａｕＳ３に転送できる。このために、ＡａｕＳは、Ｄｉａｍｅｔｅｒヘッダー中の「ホップ−バイ−ホップ」フィールドを用いて、転送されなければならない保留状態中のユーザーの認証リクエストを見いだす。

逆に、もしいくつかのＶａｕＳ／ＰＬＭＮから選択する可能性が当該ユーザーに存在しているならば（すなわち、所望のＨＳＰとのローミング協定を有する１より多いＶａｕＳが存在するならば）、ＡａｕＳは、それらの１つをリダイレクトされるメッセージの送り先として選択する必要はなく、単に、以下に詳しく述べる方法にてそれを選択する可能性をユーザーに与える。ＡａｕＳは、Ｄｉａｍｅｔｅｒメッセージ中に封入されたＥＡＰパケットによりＶａｕＳリスト（ＰＬＭＮリスト）をユーザーに送ることができるように、Ｄｉａｍｅｔｅｒ ＥＡＰアプリケーションをサポートする。保留状態の認証リクエストのＤｉａｍｅｔｅｒヘッダー中のホップ-バイ-ホップフィールドは、その中に封入されたＥＡＰパケットと共にＤｉａｍｅｔｅｒ／ＥＡＰリクエストメッセージを送るべく、ＡａｕＳにより使用される。

このＥＡＰパケットは、ＶａｕＳ／ＰＬＭＮリストを含む。ユーザーは、好ましいＰＬＭＮ／ＶａｕＳオペレータを選択し、この選択をＤｉａｍｅｔｅｒ-ＥＡＰ-レスポンスメッセージにてＡａｕＳに送る。ＥＡＰパケット中のユーザーの選択されたレルムに基づいて、ＡａｕＳは、認証保留中 Ｄｉａｍｅｔｅｒ-ＥＡＰリクエスト／アイデンティティメッセージをユーザーが選択したＶａｕＳに転送する。

ＶａｕＳ／ＰＬＭＮリストをユーザーに向けて転送するために、特定のＥＡＰタイプを定義しなければならない。図５では、このＥＡＰタイプは、ｘｘｘで示される。

ここに記載の例では、ユーザーＡは、ＶａｕＳ １又はＶａｕＳ ２を選択する可能性を有したＡａｕＳからＶａｕＳ／ＰＬＭＮリストを受信する（これらの操作は、本質的にこの手順において第６及び第７ステップからなる）。ユーザーＡは、好ましいＰＬＭＮとしてＶａｕＳ １を選択し、この選択をＡａｕＳに送る。これらの操作は、本質的に、この手順において第８及び第９ステップからなる。最後に、ＡａｕＳは、保留中のＤｉａｍｅｔｅｒ-ＥＡＰ リクエスト／アイデンティティをＶａｕＳｌに送り、このＶａｕＳｌが、該リクエストを認証のためにプロバイダＨＳＰＡに転送する（これは本質的にこの手順において第１０ステップである）。

このように説明してきた構成では、ＷＬＡＮ内で利用可能なネットワークの識別子が、ユーザーに伝送される。認証サーバは、例えばネットワークアクセス識別子（ＮＡＩ）のレルム部分から識別されるそのユーザーに利用可能なローミングネットワークを検索する。このタスクを遂行するため、サーバは、それと接続されたプロバイダに属するすべてのサーバと会話を開始する。その結果、認証サーバは、ユーザーのホームオペレータとのローミング協定を有するオペレータのリストを検索する。この手順は、１回だけ実行される、すなわち、それぞれのホームプロバイダとの直接的なローミング協定を有さないユーザーに対して認証サーバが最初の認証リクエストを受信したとき実行される。

次に、認証サーバは、アクセスネットワークを介してオペレータのリストをユーザーに転送する。ユーザーは、彼のローカルな好みにより、又は事前に構成された何らかのセッティングに基づいて、サーバから受信したリストに含まれるオペレータのうち１つを選択する。アクセスプロバイダが当該ホームプロバイダとの直接的なローミング協定を有する場合には、ただ１つのオペレータから成るリストがユーザーに提示されるか、又は認証リクエストを直接転送することを認証サーバが決定できる。ユーザーは、選択されたオペレータの識別子をアクセスネットワーク中の認証サーバに送り返す。この時点で、認証サーバは、ユーザーのクレデンシャルを含めて認証リクエストをユーザーが選択したプロバイダに転送する。

本発明の可能な代替使用法は、ウエブベースのユーザー認証の場合である。これは、ＥＡＰサポートのないクライアントに対してこの解決策の使用を拡張する利点を有する。

以下、この手順を説明する。
ユーザーＡは、例えばウエブブラウザを「開き」、続いてＵＲＬをリクエストすることにより、無線インターネットサービスプロバイダＩＳＰからのサービスをリクエストする。アクセスネットワーク装置は、ユーザーのリクエストをインターセプトし、ＨＴＭＬページを介してユーザーに彼又は彼女のクレデンシャルを尋ねる。

ユーザーＡは、彼又は彼女のアイデンティティ（例えばＮＡＩフォーマットにて）とパスワードを提示する。クレデンシャルは、ＨＴＴＰＳを用いてアクセスネットワーク装置に転送される。アクセスネットワーク装置は、Ｄｉａｍｅｔｅｒ封入化(encapsulation)を用いてそれらをアクセス認証サーバ（ＡａｕＳ）に転送する。ＷＩＳＰ中のアクセス認証サーバ（ＡａｕＳ）は、そのユーザーに対して利用可能なローミングネットワークを検索する。これらは、ＮＡＩ識別子のレルム部分により識別される。上記説明したように、このタスクを遂行するため、サーバは、該サーバに接続されたプロバイダに属するすべてのサーバとの会話を開始する。

その結果、この認証サーバは、ユーザーのオペレータとのローミング協定を保持するオペレータのリストを検索する。アクセス認証サーバ（ＡａｕＳ）は、オペレータのこのリストをユーザーに送る。

アクセスサービスプロバイダＡＳＰが、所望のホームサービスプロバイダＨＳＰとの直接的なローミング協定を有する場合には、ユーザーには、１つのオペレータのみを含んだリストが提示される。代わりに、認証サーバは、認証リクエストを直接転送することを決定することもできる。

このリストは、ＩＰネットワーク選択リンクを有する新しいＨＴＭＬページと共に、ユーザーに提示される。ユーザーは、サーバから受信した該リスト中に含まれたオペレータのうちの１つを選択する。

この時点で、認証サーバは、ユーザークレデンシャルを含めて認証リクエストを、ユーザーにより選択されたプロバイダに転送する。ホーム認証サーバは、ユーザークレデンシャルを受け入れ、ユーザーのアイデンティティの有効性を調べ、もし認証が成功すると、アクセス認証サーバにユーザーへのサービスの提供を命じる。これに対応する手順を図７に示す。

記載された構成は、Ｄｉａｍｅｔｅｒエージェントの使用に基づいている。もちろん、Ｒａｄｉｕｓなどの他の「トリプルＡ」プロトコルもまた、たとえそのうちのあるものがプロキシ、リダイレクト及びリレーを含めてエージェントに明示的なサポートを提供できないとしても、首尾よく使用することができる。

したがって、本発明の基礎と成る原理に対する先入観なしに、特許請求の範囲に記載の本発明の範囲から逸脱することなく、単に例として上記説明してきたことに関して、その詳細と実施態様は大きく変わり得る。

図１自体は従来技術と、本発明の両方に関係し、既に上記説明した。 単純化した相互に作用するモデルの説明図である。 特定のローミングのシナリオの説明図である。 一般化したネットワーク選択手順を概略的に表す機能ブロック図である。 相互に作用するＷＬＡＮにおけるネットワーク選択手順の詳細図である。 ウエブベースのアクセスにおけるネットワーク選択の説明図である。 ネットワーク選択手順を概略的に表す別の機能ブロック図である。

符号の説明

Ａ、Ｂ、Ｃ ユーザー
ＡＮ アクセスネットワーク
ＡＳＰ アクセスサービスプロバイダ
ＶＳＰ１、ＶＳＰ２、ＶＳＰ３ 訪問ネットワーク
ＨＳＰＡ、ＨＳＰＢ、ＨＳＰＣ ホームオペレータ

Claims (32)

1. 通信ネットワーク上にてアクセスネットワーク（ＡＮ、ＡＳＰ）を介し且つ複数のサポートされた訪問ネットワーク（ＶＳＰ１、ＶＳＰ２、ＶＳＰ３）のいずれかを通るそれぞれのホームオペレータ（ＨＳＰＡ、ＨＳＰＢ、ＨＳＰＣ）へのアクセスを、少なくとも１つのユーザー（Ａ、Ｂ、Ｃ）に提供する方法であって、前記サポートされた訪問ネットワーク（ＶＳＰ１、ＶＳＰ２、ＶＳＰ３）のリストをユーザー（Ａ、Ｂ、Ｃ）に転送するステップを含み、それにより、前記それぞれのホームオペレータ（ＨＳＰＡ、ＨＳＰＢ、ＨＳＰＣ）への経路として前記サポートされた訪問ネットワーク（ＶＳＰ１、ＶＳＰ２、ＶＳＰ３）の１つを選択する可能性を前記ユーザー（Ａ、Ｂ、Ｃ）に与えることを特徴とする方法。
2. − 前記アクセスネットワーク（ＡＮ、ＡＳＰ）にて前記ユーザー（Ａ、Ｂ、Ｃ）からユーザークレデンシャルを受信するステップ、
   − 前記ユーザークレデンシャルを前記アクセスネットワーク（ＡＮ、ＡＳＰ）の認証機能部に転送するステップ、
   − 前記ユーザー（Ａ、Ｂ、Ｃ）に対して利用可能な１組のローミングネットワーク（ＶＳＰ１、ＶＳＰ２；ＶＳＰ３）を検索することで、前記ユーザー（Ａ、Ｂ、Ｃ）の前記それぞれのホームオペレータ（ＨＳＰＡ、ＨＳＰＢ、ＨＳＰＣ）とのローミング協定を保持するオペレータのリストを検索するステップ、及び
   − 前記リストを前記ユーザー（Ａ、Ｂ、Ｃ）に転送するステップ
   を含むことを特徴とする請求項１に記載の方法。
3. − 前記リストから選択されたオペレータの識別子を前記認証機能部にて前記ユーザー（Ａ、Ｂ、Ｃ）から受信するステップ、及び
   − 前記識別子により識別されたオペレータにユーザーの認証リクエストを転送するステップ
   を含むことを特徴とする請求項２に記載の方法。
4. 前記ユーザーの認証リクエスト中にユーザークレデンシャルを含めるステップを含むことを特徴とする請求項３に記載の方法。
5. − 前記ユーザー（Ａ、Ｂ、Ｃ）にＮＡＩ識別子を割り当てるステップ、
   − 前記ＮＡＩ識別子のレルム部分により前記ユーザー（Ａ、Ｂ、Ｃ）を識別するステップ
   を含むことを特徴とする請求項１に記載の方法。
6. 前記ユーザーのそれぞれのホームオペレータ（ＨＳＰＡ、ＨＳＰＢ、ＨＳＰＣ）との直接的なローミング協定が存在しないユーザーについて前記認証機能部が最初の認証リクエストを受信したとき、ユーザークレデンシャルを受信し転送し利用可能な１組のローミングネットワークを検索する前記ステップをただ１回実行することを特徴とする請求項２に記載の方法。
7. 前記アクセスネットワーク（ＡＮ、ＡＳＰ）が前記ユーザーのそれぞれのホームオペレータ（ＨＳＰＡ、ＨＳＰＢ、ＨＳＰＣ）との直接的なローミング協定を有するとき、前記ユーザーのそれぞれのホームオペレータのみを含んだリストを前記ユーザー（Ａ、Ｂ、Ｃ）に転送するステップを含むことを特徴とする請求項２に記載の方法。
8. 前記アクセスネットワーク（ＡＮ、ＡＳＰ）が前記ユーザーのそれぞれのホームオペレータ（ＨＳＰＡ、ＨＳＰＢ、ＨＳＰＣ）との直接的なローミング協定を有するとき、ユーザーの認証リクエストを前記ユーザーのそれぞれのホームオペレータ（ＨＳＰＡ、ＨＳＰＢ、ＨＳＰＣ）に直接転送するステップを含むことを特徴とする請求項２に記載の方法。
9. 前記ユーザーの認証リクエストを、前記識別子により識別された前記オペレータから前記ユーザーのそれぞれのホームオペレータ（ＨＳＰＡ、ＨＳＰＢ、ＨＳＰＣ）にプロキシするステップを含むことを特徴とする請求項３に記載の方法。
10. ＥＡＰベースの機能部として前記認証機能部を選択するステップを含むことを特徴とする請求項２に記載の方法。
11. 前記アクセスネットワーク（ＷＩＳＰ１、ＷＩＳＰ２、ＷＩＳＰ３）及び前記サポートされた訪問ネットワーク（ＶＳＰ１、ＶＳＰ２、ＶＳＰ３）のうちの少なくとも１つ中にＤｉａｍｅｔｅｒノードを含めるステップを含むことを特徴とする請求項１に記載の方法。
12. 前記アクセスネットワーク（ＷＩＳＰ１、ＷＩＳＰ２、ＷＩＳＰ３）及び前記サポートされた訪問ネットワーク（ＶＳＰ１、ＶＳＰ２、ＶＳＰ３）のうちの少なくとも１つ中にプロキシ／リレー（ＤＲＬ）エージェントを含めるステップを含むことを特徴とする請求項１に記載の方法。
13. 前記サポートされた訪問ネットワーク（ＶＳＰ１、ＶＳＰ２、ＶＳＰ３）のうちの少なくとも１つ中にリダイレクトエージェント（ＤＲＤ）を含めるステップを含むことを特徴とする請求項１に記載の方法。
14. 前記サポートされた訪問ネットワーク（ＶＳＰ１、ＶＳＰ２、ＶＳＰ３）の少なくとも１つ中に：
    − 識別されたオペレータに転送しなければならないそれらの認証リクエストのためのプロキシ／リレーエージェントを、
    − 未知のレルムを有するそれらの認証リクエストのためのリダイレクトエージェントとして、
    含めるステップを含むことを特徴とする請求項３に記載の方法。
15. − すべての前記サポートされた訪問ネットワーク（ＶａｕＳ／ＤＲＤ）に、レルムが前記アクセスネットワーク（ＡａｕＳ／ＤＲＬ）にて識別されるいずれのレルムとも対応しない認証リクエストをリダイレクトするステップ、及び
    − 前記ユーザーのそれぞれのホームオペレータへのコンタクト情報だけでなくリダイレクト通知も、前記サポートされた訪問ネットワーク（ＶａｕＳ／ＤＲＤ）から前記アクセスネットワーク（ＡａｕＳ／ＤＲＬ）に戻すステップ
    を含むことを特徴とする請求項１４に記載の方法。
16. アクセスネットワーク（ＡＮ、ＡＳＰ）を介し且つ複数のサポートされた訪問ネットワーク（ＶＳＰ１、ＶＳＰ２、ＶＳＰ３）のいずれかを通るそれぞれのホームオペレータ（ＨＳＰＡ、ＨＳＰＢ、ＨＳＰＣ）へのアクセスを、少なくとも１つのユーザー（Ａ、Ｂ、Ｃ）に提供するよう構成された通信ネットワークであって、前記アクセスネットワーク（ＡＮ、ＡＳＰ）が、前記サポートされた訪問ネットワーク（ＶＳＰ１、ＶＳＰ２、ＶＳＰ３）のリストをユーザー（Ａ、Ｂ、Ｃ）に転送するよう構成され、それにより、前記それぞれのホームオペレータ（ＨＳＰＡ、ＨＳＰＢ、ＨＳＰＣ）に到達する経路として前記サポートされた訪問ネットワーク（ＶＳＰ１、ＶＳＰ２、ＶＳＰ３）の１つを選択する可能性が前記ユーザー（Ａ、Ｂ、Ｃ）に与えられることを特徴とする通信ネットワーク。
17. − 前記アクセスネットワーク（ＡＮ、ＡＳＰ）及び関連の認証サーバを有し、前記アクセスネットワーク（ＡＮ、ＡＳＰ）が、ユーザークレデンシャルを前記ユーザー（Ａ、Ｂ、Ｃ）から受信し、前記ユーザークレデンシャルを前記認証サーバに転送するよう構成されており、
    − 前記認証サーバが、前記ユーザー（Ａ、Ｂ、Ｃ）に対して利用可能な１組のローミングネットワーク（ＶＳＰ１、ＶＳＰ２、ＶＳＰ３）を検索することで、前記ユーザー（Ａ、Ｂ、Ｃ）の前記それぞれのホームオペレータ（ＨＳＰＡ、ＨＳＰＢ、ＨＳＰＣ）とのローミング協定を保持するオペレータのリストを検索し、前記リストを前記ユーザー（Ａ、Ｂ、Ｃ）に転送するよう構成される、
    ことを特徴とする請求項１６に記載のネットワーク。
18. 前記認証サーバが、前記リストから選択されたオペレータの識別子を前記ユーザー（Ａ、Ｂ、Ｃ）から受信し、前記識別子により識別されたオペレータにユーザーの認証リクエストを転送するよう構成されることを特徴とする請求項１７に記載のネットワーク。
19. 前記認証サーバが、ユーザークレデンシャルを前記ユーザーの認証リクエスト中に含めるように構成されることを特徴とする請求項１８に記載のネットワーク。
20. 前記ユーザー（Ａ、Ｂ、Ｃ）がＮＡＩ識別子により識別され、前記アクセスネットワーク（ＡＮ、ＡＳＰ）が、前記ＮＡＩ識別子のレルム部分により前記ユーザー（Ａ、Ｂ、Ｃ）を識別するよう構成されることを特徴とする請求項１６に記載のネットワーク。
21. 前記認証サーバが、前記ユーザーのそれぞれのホームオペレータ（ＨＳＰＡ、ＨＳＰＢ、ＨＳＰＣ）との直接的なローミング協定が存在しないユーザーについて前記認証サーバが最初の認証リクエストを受信したとき、ユーザークレデンシャルを受信し、転送し、１組の利用可能なローミングネットワークをただ１回だけ検索するように構成されることを特徴とする請求項１７に記載のネットワーク。
22. 前記アクセスネットワーク（ＡＮ、ＡＳＰ）が、前記ユーザーのそれぞれのホームオペレータ（ＨＳＰＡ、ＨＳＰＢ、ＨＳＰＣ）との直接的なローミング協定を有し、前記アクセスネットワーク（ＡＮ、ＡＳＰ）が、前記ユーザーのそれぞれのホームオペレータのみを含んだリストを前記ユーザー（Ａ、Ｂ、Ｃ）に転送するよう構成されることを特徴とする請求項１７に記載のネットワーク。
23. 前記アクセスネットワーク（ＡＮ、ＡＳＰ）が、前記ユーザーのそれぞれのホームオペレータ（ＨＳＰＡ、ＨＳＰＢ、ＨＳＰＣ）との直接的なローミング協定を有し、前記アクセスネットワーク（ＡＮ、ＡＳＰ）が、ユーザーの認証リクエストを前記ユーザーのそれぞれのホームオペレータ（ＨＳＰＡ、ＨＳＰＢ、ＨＳＰＣ）に直接転送するよう構成されることを特徴とする請求項１７に記載のネットワーク。
24. 前記サポートされた訪問ネットワーク（ＶＳＰ１、ＶＳＰ２、ＶＳＰ３）が、前記ユーザーの認証リクエストを前記識別子により識別される前記オペレータから前記ユーザーのそれぞれのホームオペレータ（ＨＳＰＡ、ＨＳＰＢ、ＨＳＰＣ）にプロキシするよう構成されることを特徴とする請求項１８に記載のネットワーク。
25. 前記認証サーバがＥＡＰベースのサーバであることを特徴とする請求項１７に記載のネットワーク。
26. 前記アクセスネットワーク（ＷＩＳＰ１、ＷＩＳＰ２、ＷＩＳＰ３）及び前記サポートされた訪問ネットワーク（ＶＳＰ１、ＶＳＰ２、ＶＳＰ３）のうちの少なくとも１つが、Ｄｉａｍｅｔｅｒノードとして構成されることを特徴とする請求項１６に記載のネットワーク。
27. 前記アクセスネットワーク（ＷＩＳＰ１、ＷＩＳＰ２、ＷＩＳＰ３）及び前記サポートされた訪問ネットワーク（ＶＳＰ１、ＶＳＰ２、ＶＳＰ３）のうちの少なくとも１つがプロキシ／リレー（ＤＲＬ）エージェントを含むことを特徴とする請求項１６に記載のネットワーク。
28. 前記サポートされた訪問ネットワーク（ＶＳＰ１、ＶＳＰ２、ＶＳＰ３）の少なくとも１つがリダイレクトエージェント（ＤＲＤ）を含むことを特徴とする請求項１６に記載のネットワーク。
29. 前記サポートされた訪問ネットワーク（ＶＳＰ１、ＶＳＰ２、ＶＳＰ３）の少なくとも１つが：
    − 識別されたオペレータに転送しなければならないそれらの認証リクエストのためのプロキシ／リレーエージェントを、
    − 未知のレルムを有するそれらの認証リクエストのためのリダイレクトエージェントとして
    含むことを特徴とする請求項１８に記載のネットワーク。
30. 前記アクセスネットワーク（ＷＩＳＰ１、ＷＩＳＰ２、ＷＩＳＰ３）が、レルムが前記アクセスネットワーク（ＡａｕＳ／ＤＲＬ）にて識別されるいずれのレルムにも対応していない認証リクエストを、すべての前記サポートされた訪問ネットワーク（ＶａｕＳ／ＤＲＤ）にリダイレクトするよう構成されること、及び前記サポートされた訪問ネットワーク（ＶａｕＳ／ＤＲＤ）が、前記ユーザーのそれぞれのホームオペレータへのコンタクト情報だけでなくリダイレクト通知も前記アクセスネットワーク（ＡａｕＳ／ＤＲＬ）に戻すように構成されることを特徴とする請求項２９に記載のネットワーク。
31. ＩＰネットワークの形式である請求項１６に記載のネットワーク。
32. 少なくとも１つのコンピュータのメモリにロード可能なコンピュータプログラムプロダクトであって、請求項１〜１５のいずれか一項に記載のステップを実行するためのソフトウエアコード部分を含んだコンピュータプログラムプロダクト。

Images