(57)【要約】  本発明は、公衆地上移動体ネットワークPLMN内の装置であって、ユーザ端末UEのユーザの在圏PLMNに接続されるアクセスネットワーク内に位置するユーザ端末UEをどのゲートウェイに接続すべきかを選択する、UEのユーザのホームPLMN内の装置に関する。装置は、UEのユーザのIDを有する第１のFQDNを受信する手段を有し、ホームPLMNは在圏PLMNのIDを知っている。さらに装置は、少なくとも受信したユーザのIDに基づいて、UEがホームPLMN内のゲートウェイのみへのコネクションを確立すべきか、在圏PLMN内のゲートウェイのみへのコネクションを確立すべきか、又はホームPLMN内のゲートウェイと在圏PLMN内のゲートウェイの両方へのコネクションを確立すべきかを選択するための手段と、在圏PLMN内のゲートウェイのみへのコネクションが選択された場合に在圏PLMN内のゲートウェイに属するアドレスを送信し、ホームPLMN内のゲートウェイのみへのコネクションが選択された場合にホームPLMN内のゲートウェイに属するアドレスを送信し、ホームPLMN内のゲートウェイと在圏PLMN内のゲートウェイの両方へのコネクションが選択された場合にホームPLMN内のゲートウェイに属するアドレスと在圏PLMN内のゲートウェイに属するアドレスの両方を送信する手段を有する。本発明はさらに、ユーザ端末及びユーザ端末についての方法にも関連する。
2010510713.tif 000002
【特許請求の範囲】
【請求項１】
公衆地上移動体ネットワークPLMNにおいてユーザ端末UEが接続するゲートウェイを選択するための装置であって、前記ユーザ端末は前記ユーザ端末の在圏PLMNに接続されるアクセスネットワーク内に位置し、前記PLMNは前記UEのユーザのホームPLMNであり、前記装置が、第１の完全修飾ドメイン名FQDNを受信する手段を有し、前記第１のFQDNが前記UEのユーザのIDを有し、前記ホームPLMNが前記在圏PLMNのIDを知っており、前記装置が、受信した前記ユーザのIDに少なくとも基づいて、前記UEが前記ホームPLMN内のゲートウェイのみへコネクションを確立すべきか、前記在圏PLMN内のゲートウェイのみへコネクションを確立すべきか、前記ホームPLMN内のゲートウェイと前記在圏PLMN内のゲートウェイの両方へのコネクションを確立すべきかを選択する手段と、前記在圏PLMN内のゲートウェイのみへコネクションを確立すべきであると選択された場合に前記在圏PLMN内のゲートウェイに属するアドレスを、前記ホームPLMN内のゲートウェイのみへコネクションを確立すべきであると選択された場合に前記ホームPLMN内のゲートウェイに属するアドレスを、前記在圏PLMN内のゲートウェイと前記ホームPLMN内のゲートウェイの両方へのコネクションを確立すべきであると選択された場合に前記在圏PLMN内のゲートウェイに属するアドレスと前記ホームPLMN内のゲートウェイに属するアドレスを、それぞれ受信する手段とを有することを特徴とする装置。
【請求項２】
前記選択する手段は、少なくとも前記ユーザIDに基づいて、前記選択の結果を決定する１つ以上の有効なポリシを特定する手段をさらに有することを特徴とする請求項１記載の装置。
【請求項３】
前記ホームPLMNが、認証手順の間に前記在圏PLMNのIDを知らされることを特徴とする請求項１又は請求項２に記載の装置。
【請求項４】
前記ホームPLMNが前記在圏PLMNのIDを知ることができるように、前記第１のFQDNが前記在圏PLMNのIDを有することを特徴とする請求項１又は請求項２に記載の装置。
【請求項５】
前記ゲートウェイがPDG/TTGであることを特徴とする請求項１乃至請求項４のいずれか１項に記載の装置。
【請求項６】
前記選択する手段が、前記在圏PLMN内のゲートウェイへのコネクションと、前記ホームPLMN内のゲートウェイへのコネクションと、前記在圏PLMN内のゲートウェイと前記ホームPLMN内のゲートウェイの両方へのコネクションのいずれを用いるべきかを選択するために、認証装置及び／又はポリシサーバに問い合わせることを特徴とする請求項１乃至請求項５のいずれか１項に記載の装置。
【請求項７】
前記在圏PLMN内のゲートウェイへのコネクションが選択された場合、前記解決する手段が、
前記在圏PLMNを示す第２のFQDNを構築する手段と、
前記第２のFQDNを前記在圏PLMNに送信する手段と、
前記在圏PLMN内のゲートウェイに属するアドレスを少なくとも前記送信された第２のFQDNに基づいて受信する手段と、
前記在圏PLMN内のゲートウェイに属するアドレスを前記UEへ送信する手段を有することを特徴とする請求項１乃至請求項６のいずれか１項に記載の装置。
【請求項８】
前記第２のFQDNが、前記第１のFQDNを、
前記第１のFQDNから前記ユーザIDを除去する手段と、
前記第１のFQDNが前記在圏PLMNのIDを有する際に前記在圏PLMNのIDを前記第１のFQDNから除去する手段と、
前記第１のFQDN内の前記ホームPLMNのIDを前記在圏PLMNのIDで置き換える手段とによって変更することによって構築されることを特徴とする請求項７記載の装置。
【請求項９】
前記ゲートウェイがホームエージェント、IASA又はAENであることを特徴とする請求項１乃至請求項８のいずれか１項に記載の装置。
【請求項１０】
前記在圏PLMN内のゲートウェイへのコネクションと前記ホームPLMN内のゲートウェイへのコネクションとについてのユーザ選択の表示が前記FQDNに含められることを特徴とする請求項１乃至請求項９のいずれか１項に記載の装置。
【請求項１１】
前記有効なポリシが、前記FQDNに含まれる前記W-APN又は他のサービス関連識別子によって特定されることを特徴とする請求項２乃至請求項１０のいずれか１項に記載の装置。
【請求項１２】
前記送信する手段が、DNSリクエストで前記ゲートウェイアドレスを送信する手段を有することを特徴とする請求項１乃至請求項１１のいずれか１項に記載の装置。
前記送信する手段が前記DNS応答内の生存時間(TTL)パラメータの設定をゼロにする手段を含むことを特徴とする請求項１２記載の装置。
【請求項１３】
接続するゲートウェイを決定するための、UEにおける装置であって、前記UEは前記UEの在圏PLMNに接続されるアクセスネットワーク内に位置するとともにホームPLMNに属し、前記ホームPLMNに属するドメイン名を有する第１のFQDNをDNSリクエストに含める手段を有する前記装置が、前記UEのユーザのIDを前記第１のFQDNに含める手段と、前記UEが前記在圏PLMN内のゲートウェイへ接続すべきであると前記ホームPLMNが選択した場合に前記在圏PLMN内のゲートウェイへのアドレスを、又は／及び前記UE前記ホームPLMN内のゲートウェイへ接続すべきであると前記ホームPLMNが選択した場合は前記ホームPLMN内のゲートウェイへのアドレスを、少なくとも前記UEのユーザのIDに基づいて受信する手段とを有することを特徴とする装置。
【請求項１４】
前記ホームPLMNが前記在圏PLMNのIDを知ることができるように、前記第１のFQDNに前記在圏PLMNのIDを含める手段を有することを特徴とする請求項１３記載の装置。
【請求項１５】
前記ゲートウェイがPDG/TTGであることを特徴とする請求項１３又は請求項１４に記載の装置。
【請求項１６】
パケットフィルタを用いて、前記在圏PLMN内のゲートウェイ又は前記ホームPLMN内のゲートウェイに選択的にデータパケットを送信する手段をさらに有することを特徴とする請求項１３乃至請求項１５のいずれか１項に記載の装置。
【請求項１７】
パケットをどのゲートウェイに送信すべきかの、前記パケットフィルタに基づく選択が、IPソースアドレス、IPデスティネーションアドレス、IPヘッダ内のプロトコル表示フィールド、トランスポートプロトコル、ソースポート番号、デスティネーションポート番号、サービスタイプ及びトラフィッククラス、のパケットパラメータの少なくとも１つに基づくことを特徴とする請求項１６記載の装置。
【請求項１８】
前記パケットフィルタが時間に依存することを特徴とする請求項１６又は請求項１７に記載の装置。
【請求項１９】
前記在圏PLMN内のゲートウェイへのコネクションと前記ホームPLMN内のゲートウェイへのコネクションとについてのユーザ選択の表示を、前記FQDNに含める手段をさらに有することを特徴とする請求項１３乃至請求項１８のいずれか１項に記載の装置。
【請求項２０】
W-APNを前記FQDNに含める手段をさらに有することを特徴とする請求項１３乃至請求項１９のいずれか１項に記載の装置。
【請求項２１】
前記ゲートウェイアドレスがDNS応答内で受信されることを特徴とする請求項１３乃至請求項２０のいずれか１項に記載の装置。
【請求項２２】
UEのユーザの在圏PLMNに接続されるアクセスネットワーク内に位置する前記UEが接続するゲートウェイを選択する、PLMN内の装置であって、前記PLMNは前記UEのユーザのホームPLMNであり、前記装置は第１のFQDNを受信する手段を有し、前記第１のFQDNが前記UEのユーザのIDを有し、前記ホームPLMNは前記在圏PLMNのIDを知っており、前記装置は、少なくとも受信した前記UEのユーザのIDに基づいて、前記UEが前記在圏PLMN内のゲートウェイのみへコネクションを確立すべきであることを選択する手段と、前記受信した第１のFQDNの代わりに用いられるとともに、在圏PLMN DNSサーバへ送信されるべき第３のFQDNを有するCNAMEリソースレコードを、ホームPLMN DNSサーバによって送信する手段とを有し、前記第３のFQDNは、前記在圏PLMN DNSサーバが前記第３のFQDNを解決してゲートウェイアドレスを前記UEへ送信できるよう、W-APNネットワーク識別子及び前記在圏PLMNのIDを用いて構築されることを特徴とする装置。
【請求項２３】
接続するゲートウェイを決定するための、UEにおける装置であって、前記UEは前記UEのユーザの在圏PLMNに接続されるアクセスネットワーク内に位置するとともに前記UEのユーザはホームPLMNに属し、前記ホームPLMNに属するドメイン名を有する第１のFQDNをDNSリクエストに含める手段を有する前記装置が、前記在圏PLMNのIDを前記第１のFQDNに含める手段と、前記UEが前記在圏PLMN内のゲートウェイへ接続すべきであると前記ホームPLMNが選択した場合に前記在圏PLMN内のゲートウェイへのアドレスを、又は／及び前記UE前記ホームPLMN内のゲートウェイへ接続すべきであると前記ホームPLMNが選択した場合は前記ホームPLMN内のゲートウェイへのアドレスを、少なくとも前記UEの前記在圏PLMNのIDに基づいて受信する手段とを有することを特徴とする装置。
【請求項２４】
UEのユーザの在圏PLMNに接続されるアクセスネットワーク内に位置する前記UEを接続するためのゲートウェイを選択する、前記UEのホームPLMNにおける方法であって、
前記UEのユーザのIDを有する第１のFQDNを受信するステップを有し、前記ホームPLMNは前記在圏PLMNのIDを知っており、
さらに、少なくとも前記受信したユーザのIDに基づいて、前記UEが前記ホームPLMN内のゲートウェイのみへのコネクションを確立すべきか、前記在圏PLMN内のゲートウェイのみへのコネクションを確立すべきか、又は前記ホームPLMN内のゲートウェイと前記在圏PLMN内のゲートウェイの両方へのコネクションを確立すべきかを選択するステップと、
前記在圏PLMN内のゲートウェイのみへのコネクションが選択された場合に前記在圏PLMN内のゲートウェイに属するアドレスを、前記ホームPLMN内のゲートウェイのみへのコネクションが選択された場合に前記ホームPLMN内のゲートウェイに属するアドレスを、前記ホームPLMN内のゲートウェイと前記在圏PLMN内のゲートウェイの両方へのコネクションが選択された場合に前記ホームPLMN内のゲートウェイに属するアドレスと前記在圏PLMN内のゲートウェイに属するアドレスの両方を、それぞれ送信するステップとを有することを特徴とする方法。
【請求項２５】
前記選択するステップは、少なくとも前記ユーザIDに基づいて、前記選択の結果を決定する１つ以上の有効なポリシを特定するステップをさらに有することを特徴とする請求項２４記載の方法。
【請求項２６】
前記ホームPLMNが、認証手順の間に前記在圏PLMNのIDを知らされることを特徴とする請求項２４又は請求項２５に記載の方法。
【請求項２７】
前記ホームPLMNが前記在圏PLMNのIDを知ることができるように、前記第１のFQDNが前記在圏PLMNのIDを有することを特徴とする請求項２４又は請求項２５に記載の方法。
【請求項２８】
前記選択するステップが、
前記在圏PLMN内のゲートウェイへのコネクションと、前記ホームPLMN内のゲートウェイへのコネクションと、前記在圏PLMN内のゲートウェイと前記ホームPLMN内のゲートウェイの両方へのコネクションのいずれを用いるべきかを選択するために、認証装置及び／又はポリシサーバに問い合わせるステップをさらに有することを特徴とする請求項２４乃至請求項２７のいずれか１項に記載の方法。
【請求項２９】
前記在圏PLMN内のゲートウェイへのコネクションが選択された場合、前記解決するステップが、
前記在圏PLMNを示す第２のFQDNを構築するステップと、
前記第２のFQDNを前記在圏PLMNへ送信するステップと、
少なくとも前記送信された第２のFQDNに基づいて、前記在圏PLMN内のゲートウェイに属するアドレスを受信するステップと、
前記在圏PLMN内のゲートウェイに属するアドレスを前記UEへ送信するステップとを有することを特徴とする請求項２４乃至請求項２８のいずれか１項に記載の方法。
【請求項３０】
前記第２のFQDNが、
前記第１のFQDNから前記ユーザIDを除去するステップ、
前記第１のFQDNが前記在圏PLMNのIDを有する場合に前記第１のFQDNから前記在圏PLMNのIDを除去するステップ、
前記第１のFQDN内の前記ホームPLMNの表示を前記在圏PLMNのIDで置き換えるステップ、によって前記第１のFQDNを変更することによって構築されることを特徴とする請求項２９記載の方法。
【請求項３１】
接続するゲートウェイを決定するための、UEにおける方法であって、前記UEは前記UEの在圏PLMNに接続されるアクセスネットワーク内に位置するとともにホームPLMNに属し、前記ホームPLMNに属するドメイン名を有する第１のFQDNをDNSリクエストに含めるステップを有する前記方法が、
前記UEのユーザのIDを前記第１のFQDNに含めるステップと、
前記UEが前記在圏PLMN内のゲートウェイへ接続すべきであると前記ホームPLMNが選択した場合に前記在圏PLMN内のゲートウェイへのアドレスを、又は／及び前記UE前記ホームPLMN内のゲートウェイへ接続すべきであると前記ホームPLMNが選択した場合は前記ホームPLMN内のゲートウェイへのアドレスを、少なくとも前記UEのユーザのIDに基づいて受信するステップをさらに有することを特徴とする方法。
【請求項３２】
前記ホームPLMNが前記在圏PLMNのIDを知ることができるように、前記第１のFQDNが前記在圏PLMNのIDを有することを特徴とする請求項３１記載の方法。
【請求項３３】
前記UEが前記在圏PLMN内のゲートウェイへのアドレス及び前記ホームPLMN内のゲートウェイへのアドレスを受信すると、パケットフィルタを用いて、前記在圏PLMN内のゲートウェイ又は前記ホームPLMN内のゲートウェイに選択的にデータパケットを送信するステップをさらに有することを特徴とする請求項３１又は請求項３２記載の方法。
【請求項３４】
パケットをどのゲートウェイに送信すべきかの、前記パケットフィルタに基づく選択が、IPソースアドレス、IPデスティネーションアドレス、IPヘッダ内のプロトコル表示フィールド、トランスポートプロトコル、ソースポート番号、デスティネーションポート番号、サービスタイプ及びトラフィッククラス、のパケットパラメータの少なくとも１つに基づくことを特徴とする請求項３３記載の方法。
【請求項３５】
前記在圏PLMN内のゲートウェイへのコネクションと前記ホームPLMN内のゲートウェイへのコネクションとについてのユーザ選択の表示が前記FQDNに含められることを特徴とする請求項３１乃至請求項３４のいずれか１項に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は移動体通信ネットワークに関し、特には、I-WLAN (Interworking- Wireless Local Area Network)及びUMTS (Universal Mobile Telecommunications System)の進化版(evolution)のためのゲートウェイ選択機構に関する。
【背景技術】
【０００２】
本発明は、一般にI-WLANとして知られる、第３世代パートナーシッププロジェクト(3GPP)公衆地上移動体ネットワーク(PLMN)、すなわち汎用パケット無線サービス／ユニバーサル移動体電話システム(GPRS/UMTS)と、無線ローカルエリアネットワーク(WLAN)アクセスネットワークとの連携(interworking)に関する。本発明はさらに、3GPPによって検討されているような、現在の3GPPネットワーク（すなわち、GPRS/UMTS）アーキテクチャをいくらか単純化するとともに、よりマルチアクセスに立脚した形式にする、予定／予期される進化にも関連する。この進化及びそれに関する3GPP内の活動は一般にシステムアーキテクチャエヴォリューション(SAE)と呼ばれる。
【０００３】
I-WLANは3GPPによって策定され、機能解説は3GPP TS 23.234 v6.4.0、「第３世代パートナーシッププロジェクト：グループサービス及びシステムアスペクト技術仕様；3GPPシステムから無線ローカルエリアネットワーク(WLAN)への連携；システム解説（リリース６）」においてなされている。
【０００４】
3GPPが規定するI-WLANシナリオの１つは、WLAN 3GPP IPアクセスである。図１ａは、WLAN 3GPP IPアクセスのローミング変形のリファレンスモデルを示し、WLANアクセスネットワーク１００が3GPP在圏網１１０に接続されている。WLANユーザ機器(UE)１２０、すなわちユーザ端末とも呼ばれるI-WLAN端末は、在圏網１１０に接続されているWLANアクセスネットワーク１００によって制御されるエリア内に位置している。ユーザ端末、又は単に端末とも呼ぶことができるＵＥ１２０は、Wuインタフェース１５０を介して、ホーム網１３０への（すなわち、パケットデータゲートウェイ(PDG)と呼ばれるゲートウェイ１４０への）コネクションも有している。このコネクションは物理的にはWLANアクセスネットワーク１００及び在圏網１１０を介するものであるが、図１ａにおいてはUE１２０とPDG１４０との間の論理インタフェースを表すため、それらを直接結ぶ線として示している。WLANアクセスネットワーク１００は、Wnインタフェースを介して、WLANアクセスゲートウェイ(WAG)と呼ばれる、在圏網１１０のゲートウェイ１６０へのコネクションを有するとともに、Waインタフェース２１０を介して、認証、承認及び課金(AAA)プロキシ１８０へのコネクションを有する。WAG１６０もまた、Wgインタフェース２００を介してAAAプロキシ１８０に接続されている。ホーム網及び在圏網のゲートウェイはWpインタフェース１９０を介して接続されている。さらに、ホーム網及び在圏網のAAAプロキシはWdインタフェースを介して接続されている。図１ａ中のエンティティのうち、説明されないものは、本発明に関連せず、ネットワークアーキテクチャのより完全な図を提供するためだけに含まれている。
【０００５】
本発明においては、WLAN 3GPP IPアクセスシナリオと呼ばれるシナリオのみを対象とするので、以下の説明においては、異なるものであることが明示されない限り、WLAN 3GPP IPアクセスシナリオを仮定する。
【０００６】
WLAN 3GPP IPアクセスシナリオにおいて、WLANアクセスネットワークにアクセスするI-WLAN端末とインターネット上のピアとの間のトラフィックは端末とホームPLMNとの間で、WLANアクセスネットワーク及び在圏PLMNを介してトンネリングされ、ホームPLMN内のトンネルエンドポイントとインターネット上のピアとの間でルーティングされる。これはホームトンネリングと呼ばれる。オプションとして、トラフィックは、ホームPLMNを処理に関与させずにI-WLAN端末と在圏PLMNとの間でトンネリングされてもよく、これはローカルブレイクアウトと呼ばれる。
【０００７】
トンネルはWn及びWpインタフェースを横断する。Wnインタフェースを横断する際、トンネルは、例えばインターネットである、能力が不明で信頼できないネットワークを横断するかもしれない。Wpインタフェース上で、横断されるネットワークは、オペレータ内部ネットワークであっても、オペレータ間ネットワークGPRSローミング交換機(GRX)であっても、セキュアであると見なされる。
【０００８】
ホームPLMN又は在圏PLMN内のトンネルエンドポイントは、ゲートウェイ（PDG又はトンネル終端ゲートウェイ(TTG)）である。これら２つのノードは、二者択一的な実装であると見なされるべきであり、TTGの場合、PDG機能がTTGとGGSNとに分配されているが、論理的には両者を同一ネットワーク内に実装することが可能であろう。
【０００９】
I-WLAN端末がWLANアクセスネットワークへのアクセスを試行した際、WLANアクセスネットワークはアクセスを許可する前にユーザ認証するオプションを有している。WLANアクセスネットワークがこのオプションの仕様を選択した場合（選択しない場合よりもずっと一般的であろう）、WLANアクセスネットワークは認証、承認及び課金(AAA)インフラストラクチャを用い、ユーザのホームPLMN内のAAAサーバの支援を受けてユーザIDの認証を行う。認証の仕組みは、J. Arkko, H. Haverinenによる「第３世代認証及び鍵共有のための拡張可能な認証プロトコル方法(EAP-AKA)」 RFC 4187、2006年1月、に記載されるようなEAP-AKA又は、H. Haverinen, J. Saloweyによる「GSM(Global System for Mobile Communications)加入者IDモジュール用の拡張可能な認証プロトコル方法(EAP-SIM)」、RFC 4186、2006年1月、に記載されるようなEAP-SIMであり、ローミングの場合、ユーザIDは在圏PLMN内のAAAプロキシを介して、端末及びホームAAAサーバ間で透過的に通信される。
【００１０】
（認証されてもされなくても）ユーザーがWLANアクセスネットワークへのアクセスを許可される場合、端末は、Charlie Kaufmanらの「インターネット鍵交換(IKEv2)プロトコル」、RFC 4306、2005年12月、に記載される、ネットワーク間鍵交換バージョン２(IKEv2)を用いて、S. Kent, R. Atkinsonによる「インターネットプロトコル用セキュリティアーキテクチャ」、RFC 2401、1998年11月、及び、S. Kent, K. Seoによる同タイトルのRFC 4301に記載されるIPsecトンネルを、選択された在圏PLMN内のWAGを介してホームPLMN内のPDG/TTGへ確立する。必要に応じて、ホームPLMN内のPDG/TTGの代わりに、端末と在圏PLMN内のPDG/TTGとの間でIPsecトンネルを確立しても良い。端末は、加入者IDモジュール(SIM)又は（ユニバーサル集積回路カード(UICC)上の）ユニバーサル加入者IDモジュール(USIM)に保存されたWLANアクセスポイント名(W-APN)を用いて、リモートトンネルエンドポイントとして使用されるべきPDG/TTGのIPアドレスを判別する。ネットワーク識別子とオペレータ識別子から（かつその順番で）なるドメイン名を構成するW-APNは、通常のドメインネームシステム(DNS)メカニズムを通じてIPアドレスに解決される。
【００１１】
IKEv2では、トンネル確立の間、PDG/TTGに対してユーザを認証する統合メカニズムとして、EAP-AKA又はEAP-SIMが用いられる。PDG/TTGはホーム網内のAAAサーバと、AAAプロトコル、好ましくは例えばPat Calhounらによる「Dameterベースプロトコル」、RFC 3588、2003年9月、及びP. Eronenらによる「Diameter拡張可能な認証プロトコル(EAP)アプリケーション」、RFC 4072、2005年8月、に記載されるDiameterを用いて通信し、ユーザを認証させる。
【００１２】
IPsecトンネルが確立すると、PDG/TTGは端末に「内部」IPアドレスを割り当てる。
【００１３】
PLMN内のトンネルエンドポイントがTTGである場合、TTGはさらにGGSNへのGTPトンネルを確立し、IPsecトンネルとGTPトンネルを互いに関連付ける。そして、この（これらの）トンネルを通じた通常のトラフィックを開始することができる。
【００１４】
WLANアクセスゲートウェイ(WAG)の基本タスクは、パケットをWLANアクセスネットワークとPDG/TTG間でルーティングすることに加え、以下の事項を含む。
・PDG/TTGが別のネットワークに位置する場合、パケットを計数し、課金データを生成する
・IPヘッダの非暗号化情報に基づく簡単なパケットフィルタリング。パケットフィルタは、対象の加入者のホームAAAサーバ２３０から（Wgインタフェース上で。WAGが在圏PLMNに位置する場合には、Wdインタフェース２２０及びAAAプロキシ１８０を介して）WAG１６０に転送されるポリシ施行情報に由来する。
【００１５】
PDG/TTGの選択は、W-APN及びPLMN ID（すなわちHPLMN ID又はVPLMN ID）から得られるFQDN（完全修飾ドメイン名）に基づくDNSを介して提供される。TTGが用いられる際、ネットワークサービスアクセスポイント識別子(NSAPI)割り当ては、所与のユーザについて、同一の複数のGGSNからサービス提供を受ける複数のW-APNへ向かう全てのトンネルが同一のTTGへ導かれることを必要とする。
【００１６】
アーキテクチャ改良作業において検討されてきた１つの長期目標アーキテクチャは、図１ｂに示すように、エッジにAEN（アクセスエッジノード）を有する全面的なマルチアクセスコアネットワークを含んでいる。AENは、「GSN+」とラベル付けされたGPRSサポートノードの進歩したバージョンの展開と考えられる。そして、GSN+４３０は、現在の3GPPネットワークアーキテクチャにおけるGPRSサポートノードの進化バージョンである。図１ｂは、AEN３１０及びポリシ及び課金制御機能３２０を有するホーム網３００と、やはりAEN４１０及びポリシ及び課金制御機能４２０を有する在圏網４００を示している。在圏網のAENは広帯域符号分割多元アクセス(WCDMA)、GSM/EDGE（Global System for Mobile communications /Enhanced Data rates for GSM Evolution)、公衆ＷＬＡＮ及びデジタル加入者回線アクセスネットワーク（xDSL。ｘはA（非対称）、S（対称）、H（高速）、Ｖ（超高速）のように、様々な文字を表すことができる）の様々な変形物のような、様々なアクセスネットワークにさらに接続される。AENは、全てのアクセスに用いられる、共通アクセス非依存（しかし、ある意味において「アクセスを意識した」）機能性を有する。さらに、AENによって提供される個別のアクセス技術ごとに、アクセス依存部分が存在する。１つのAENは複数の協働ノードとして実現されてよい。
【００１７】
I-WLANに関し、進化の方針はアーキテクチャを単純化し、ノード／機能を汎用3GPPアーキテクチャを現在の仕様よりも緊密に統合することである。長期目標アーキテクチャにおいて、PDG/TTG及びWAGをAENに統合することが提案されている。可能性のある中間段階は、PDG/TTGを将来改良されるGPRSサポートノード(GSN+)に統合すること、PDG/TTG及びWAGを将来改良されるGPRSサポートノード(GSN+)に統合すること、又はPDG/TTG及びWAGを統合することすら、含むかもしれない。改良される将来のネットワークアーキテクチャの見通しはまだ不安定であるため、3GPPにおけるこの作業の結果は図１ｂに示されるものと幾分異なったものとなるかも知れない。提案されている別の進化版ネットワークアーキテクチャを図１ｃに示す。図１ｂに示す進化版ネットワークアーキテクチャにおけるAENは、図１ｃに示される改良ネットワークアーキテクチャにおいて、インターアクセスシステムアンカー(IASA)、移動性管理エンティティ(MME)及びユーザプレーンエンティティ(UPE)と呼ばれるノードの組み合わせにおおよそ等しい。図１ｃは、ローミングの場合に、ホーム網ルーティングトラフィック及びローカルブレイクアウトトラフィックの両方が在圏インターASアンカーを介してルーティングされる際のシナリオを示している。AAAサーバは、ホーム加入者サーバ(HSS)に統合されるものと仮定されていることに留意されたい。在圏網はGPRSコアネットワーク５３０及び、IASA５２０及びMME５１０及びUPE５１０を有する改良パケットコア(EPC)５００を有する。在圏GPRSコアネットワーク５３０は、GSM EDGE無線アクセスネットワーク(GERAN)、UMTS陸上無線アクセスネットワーク(UTRAN)及び改良無線アクセスネットワーク(evolved RAN)といった複数の異なるアクセスネットワークに接続され、在圏EPC５００のIASA５２０は本発明の関心であるWLANに接続される。在圏IASA５２０は在圏網のポリシ制御リソース機能５４０、ホーム網のHSS６２０及びホームEPC６００のIASA６１０に接続される。
【００１８】
システムを（異種アクセスを通じて）マルチアクセスに拡張するSAEにおいて、移動性管理の２つの「ティア」が仮定されている。インターアクセスモビリティ（すなわち、異なる形式のアクセスネットワーク間の移動性）用のティアと、3GPPドメイン内の「内部」移動性用のティアである。いずれのティアも、トラフィック用の固定ポイントとしてアンカーノードを用いる。インターアクセスシステムアンカー(IASA)は、インターアクセスモビリティ用のアンカーノードであり、ユーザプレーンエンティティ(UPE)は3GPPドメイン内モビリティ用のアンカーノードである。UPEはピュアユーザプレーンノードであり、3GPPドメイン移動性管理用の制御プレーンを取り扱う移動性管理エンティティ(MME)（ならびに他のアクセス関連シグナリング）によって補完される。
【００１９】
図１ｃにおいて、ホームトンネリングを用いたローミングの場合、在圏PLMN内の在圏IASA(v-IASA)と、ホームPLMN内のホームIASA(h-IASA)の２つのノードが関与する。本説明において、端末／UEに最も近接しているIASAを「在圏(serving) IASA」(s-IASA)と表す。非ローミングの場合、s-IASAはh-IASAであり、ローカルブレイクアウトを用いるローミングの場合にはs-IASAはv-IASAである。図１ｃに示すアーキテクチャにおいては、ローカルブレイクアウトの場合も、ホームトンネリング／ホームルーティングの場合も、全てのローミングについて、s-IASAはv-IASAである。
【００２０】
SAEアーキテクチャはインターアクセスシステムモビリティ用のアンカーノードを含んでいる。このアンカーノードはモバイルIP(MIP)ホームエージェント(HA)であると推定される。アンカーノードはモバイルIPv6(MIPV6) HAであることが好ましいが、モバイルIPv4(MIPv4)であってもよい。HAはh-IASAに統合されるか、h-IASAと同一場所に配置されるであろう。h-IASAが１つのHAに対応するか、（例えば、負荷分散目的により）複数のHAに対応するかは決定されず、また、それを特定しなくてもよい。
【００２１】
I-WLANにおけるローカルブレイクアウト、すなわち、UE-PDG/TTGトンネルがUEと在圏PLMN内のPDG/TTG（PDGv/TTGvと表記する）との間で確立される場合のシナリオは、現在のI-WANソリューションにおいてもホームオペレータの制御下においてある程度可能である。
【００２２】
ローカルブレイクアウトを選択するためには、ユーザ／UEはW-APNネットワーク識別子及びVPLMN IDをオペレータIDとして用いてFQDNを構築し、FQDNから１つ又はいくつかのPDGv/TTGv IPアドレスを解決するDNSクエリを実行する（すなわち、VPLMN内のDNSサーバからの情報を用いる）。なお、本明細書において、「DNSサーバ」、「DNSネームサーバ」及び「ネームサーバ」は同義語と見なすことに留意されたい。そして、IPsecトンネルが、UEとPDGv/TTGvとの間で、IKEv2と、ユーザ／UEを認証及び承認するAAAサーバを用いて確立される。
【００２３】
ホームトンネリング（ローカルブレイクアウトでない、基本的な場合）を選択するためには、ユーザ／UEはHPLMNを示すFQDNを構築する。
【００２４】
ローカルブレイクアウトが用いられる場合、HPLMNはPDGv/TTGvとホームAAAサーバとの間のAAA通信を通じて、ローカルブレイクアウトを承認する。HPLMNのポリシがローカルブレイクアウトを許可しない場合（このユーザについては、W-APN、VPLMN又はそれらの任意の組み合わせ）、ホームAAAサーバが拒否メッセージをPDGv/TTGvへ送信し、PDGv/TTGvはトンネル確立を拒否する。そして、ユーザ／UEはW-APN解決及びトンネル確立手順を、HPLMNを表すFQDNを用いて最初からやり直す。
【００２５】
ユーザ／UEがホームトンネリングを選択しているが、HPLMNのポリシがローカルブレイクアウトを命令するか、好む場合、ホームAAAサーバはトンネル確立を拒否しても、ポリシに関わらず許可してもよい。トンネル確立が拒否された場合、3GPP TS 23.234 v6.4.0、「第３世代パートナーシッププロジェクト；グループサービス及びシステムアスペクト技術仕様；3GPPシステムから無線ローカルエリアネットワーク(WLAN)への連携；システム解説（リリース６）」に従って、UEはVPLMNへ向かうトンネルの確立を再試行しないであろう。
【００２６】
ホームAAAサーバは、PDG及びWAGにパケットフィルタリング命令を与えなくても良い。TTGが用いられる場合、GGSNのパケットフィルタリング機能を再利用する意図があるが、ホームAAAサーバがTTGにパケットフィルタリング命令を与えることに何の制限もない。PDG/TTG及び／又はWAGがVPLMN内に位置する場合、ホームAAAサーバはパケットフィルタリング命令をVPLMN内のAAAプロキシを介して与える。
【００２７】
上述の通り、TTGの場合には、所与のユーザについて、同一GGSNからサービスを提供されるW-APNに向かう全てのトンネルが、同一のTTGへ向かうようにされるべきである。現在、これを行うための解決方法は存在していない。TTGアドレスは、W-APN及びPLMN IDから得られるFQDNにのみ基づいて、DNSを介して選択並びに返信される。TTG IPアドレスの選択を助けるために利用可能なユーザ情報は存在しない。
【００２８】
非3GPPアクセス（又は改良されたI-WLANアクセス）が用いられる場合の在圏IASA（又はAEN）の割り当ては、おおかたの場合に依然として未解決な課題である。s-IASAはアクセスネットワーク内のアクセスノード、一般にはアクセスゲートウェイ(AGW)と表記されるアクセスノードによって、ユーザID及びポリシに基づき選択され／割り当てられるものと考えられる。これは、技術的な詳細が全く提供されない、非常に高いレベルの仮説である。
【００２９】
モバイルIPv6ホームエージェントの割り当ては、IPv6におけるIETF移動性作業グループにより、J. Giaretta、「分割シナリオにおけるモバイルIPv6ブートストラップ」インターネットドラフト；draft-ietf-mip6- bootstrapping-split-02、2006年3月、において提案されている原理に従い、DNSを介して実行されるものと推定される。
【００３０】
UEは通常のDNSメカニズムを、自身のホームエージェントに関連付けられたFQDNの解決に用い、DNSシステムは割り当てられたホームエージェントのIPアドレスを返す。「名前によるHA DNSルックアップ」方法及び、「サービスによるHA DNSルックアップ」方法の２つの方法が存在する。
【００３１】
UEがホームエージェントのFQDNを用いて設定されている場合、UEは、HA PQDNに設定されたQNAME、例えば”ha.home-operation.com”と、”AAAA”に設定されたQTYPEを用いたDNSクエリを送信する。これに応答して、DNSサーバは、ホームエージェントに属するIPアドレスを返す。これが、「名前によるHA DNSルックアップ」方法である。
【００３２】
しかし、UEは、ホームエージェントのFQDNを用いて設定されなくてもよい。ホームオペレータを表すFQDN、例えば”home-operator.com”を用いて設定されれば十分である。そのような場合、UEは、”_nip6._ipv6. home-operator.com”に設定されたQNAMEと、（サービスリソースレコード要求を示す）”SRV”に設定されたQTYPEを用いてDNSクエリを送信する。DNSサーバが利用可能なホームエージェントに属している１つ以上のFQDNのリストを返すと、UEはその１つを選択する。DNSサーバはさらに、FQDNに加えてホームエージェントのIPアドレスを含ませることができる。さもなくば、UEは、「名前によるHA DNSルックアップ」方法について説明したように、選択したHAのIPアドレスの解決をDNSシステムに要求しなければならない。これが、「サービスによるHA DNSルックアップ」方法である。
【００３３】
同じ方法を、同一場所に設定されたc/oアドレスが用いられる場合（すなわち、フォーリンエージェントが用いられない場合）のモバイルIPv4ホームエージェントの割り当てにも用いることができる。フォーリンエージェントが用いられる場合、UEの代わりにフォーリンエージェントが上述の方法を用いて、ホームエージェントの割り当てを行っても良い。
【００３４】
HPLMNが制御するローカルブレイクアウトに関して言えば、ローカルブレイクアウトとホームトンネリングのいずれを用いるかの初期選択はユーザ／UEに完全に任されている。HPLMNはAAAプロトコルを通じて、この選択を受け入れるか拒否することのみ可能である。
【００３５】
拒否により、UEは新しいFQDNを用いてホームネットワークへ向かう新しいトンネルの確立の試行を行うことになるため、ローカルブレイクアウトの拒否は、ローカルブレイクアウトからホームトンネルへの暗黙的な変更(redirect)と見なすことができる。
【００３６】
ホームトンネリングの拒否は、ローカルブレイクアウトトンネルへの暗示的な変更の要因とはならない。従って、実際のところ、ホームトンネリングの拒否は、（発生しうるWLAN直接IPアクセストラフィックを除いて）ネットワークアクセスが拒否されることを意味する。
【００３７】
従って、HPLMNはユーザ／UEの初期選択において、一方向、すなわちローカルブレイクアウトからホームトンネリングへのみ影響を与えることができ、逆方向には影響を与えることができない。加えて、暗示的とは、HPLMNがUEをローカルブレイクアウトからホームトンネリングへ変更させなければならないこと、すなわち、拒否がホームネットワークへの新たなトンネル確立試行をトリガすることが、非効率的かつ遅く、アクセス遅延が大幅に増加することを意味する。IKEv2を用いるIPsecトンネル確立はあまり早い手順ではない。そのため、あるトンネル確立手順を拒否して（前と同じDNS手順を用いる）新しい手順を開始させることは、ユーザが不便であると感じるであろう程度の遅延を生じさせる。さらに、冗長な重複したトンネル確立手順は、関与するネットワークのリソースを不必要に消費する。
【００３８】
s-IASA選択メカニズムの問題は、AGWがユーザID及びポリシに基づいてs-IASAを選択するという説明以上の詳細が与えられていないことにある。
【００３９】
SAEにおけるHA割り当てに関して現在提案されている方法の問題は、それがHAの柔軟な選択に関してHPLMNに与えるものが非常に貧弱なことである。それは基本的に、単純な負荷分散手法のみを可能とする。そして、ポリシ、ユーザ固有状況、VPLMN、等の関連情報に基づくHA選択／割り当てのための手段を完全に欠いている。
【発明の概要】
【００４０】
従って、HPLMNがローカルブレイクアウトを選択すべきであるかどうかを決定できる方法を実現することが望ましいであろう。なぜなら、HPLMNは決定を行う際に、関連するポリシ及び他のプロパティを知っているからである。
【００４１】
従って、本発明の一目的は、ローカルブレイクアウトとホームトンネリングのどちらを用いるべきかを、移動体端末が在圏ネットワークのWLANアクセスネットワークに接続される際に判別するための改善された方法を実現することである。
【００４２】
この目的は、本発明の第１の見地に係るPLMN内の装置であって、UEの在圏PLMNに接続されるアクセスネットワーク内に位置する前記UEが接続するゲートウェイを選択するための装置によって実現される。前記PLMNは前記UEのユーザのホームPLMNである。前記装置は、前記UEの前記ユーザのIDを有する第１の完全修飾ドメイン名FQDNを受信する手段を有し、前記ホームPLMNは前記在圏PLMNのIDを知っている。前記装置は、少なくとも前記受信したユーザのIDに基づいて、前記UEが前記ホームPLMN内のゲートウェイ、例えばPDG/TTGのみへのコネクションを確立すべきか、前記在圏PLMN内のゲートウェイのみへのコネクションを確立すべきか、又は前記ホームPLMN内のゲートウェイと前記在圏PLMN内のゲートウェイの両方へのコネクションを確立すべきかを選択するための手段と、前記在圏PLMN内のゲートウェイのみへのコネクションが選択された場合に前記在圏PLMN内のゲートウェイに属するアドレスを送信し、前記ホームPLMN内のゲートウェイのみへのコネクションが選択された場合に前記ホームPLMN内のゲートウェイに属するアドレスを送信し、前記ホームPLMN内のゲートウェイと前記在圏PLMN内のゲートウェイの両方へのコネクションが選択された場合に前記ホームPLMN内のゲートウェイに属するアドレスと前記在圏PLMN内のゲートウェイに属するアドレスの両方を送信する手段を有する。
【００４３】
第２の見地によれば、前記UEは前記UEのIDを前記第１のFQDNに含める手段と、前記UEが前記在圏PLMN内のゲートウェイに接続すべきであると前記ホームPLMNが選択している場合に前記在圏PLMN内のゲートウェイへのアドレスと、又は／及び、前記UEが前記ホームPLMN内のゲートウェイに接続すべきであると前記ホームPLMNが選択している場合に前記ホームPLMN内のゲートウェイへのアドレスを、少なくとも前記UEの前記IDに基づいて受信する手段とを有する。
【００４４】
第３の見地によれば、UEの在圏PLMNに接続されるアクセスネットワーク内に位置する前記UEを接続するためのゲートウェイを選択する、PLMNにおける方法であって、前記PLMNが前記UEのホームPLMNである方法が提供される。前記PLMNは、前記UEのIDを有する第１のFQDNを受信し、前記ホームPLMNは前記在圏PLMNのIDを知っている。
【００４５】
少なくとも前記受信した前記ユーザのIDに基づいて、前記PLMNは前記UEが前記ホームPLMN内のゲートウェイのみへのコネクションを確立すべきか、前記在圏PLMN内のゲートウェイのみへのコネクションを確立すべきか、又は前記ホームPLMN内のゲートウェイと前記在圏PLMN内のゲートウェイの両方へのコネクションを確立すべきかを選択する。従って、前記PLMNは、前記在圏PLMN内のゲートウェイのみへのコネクションが選択された場合に前記在圏PLMN内のゲートウェイに属するアドレスを送信し、前記ホームPLMN内のゲートウェイのみへのコネクションが選択された場合に前記ホームPLMN内のゲートウェイに属するアドレスを送信し、前記ホームPLMN内のゲートウェイと前記在圏PLMN内のゲートウェイの両方へのコネクションが選択された場合に前記ホームPLMN内のゲートウェイに属するアドレスと前記在圏PLMN内のゲートウェイに属するアドレスの両方を送信する。
【００４６】
第４の見地によれば、UEにおける方法であって、前記UEのIDを前記第１のFQDNに含めるステップと、前記UEが前記在圏PLMN内のゲートウェイに接続すべきであると前記ホームPLMNが選択している場合に前記在圏PLMN内のゲートウェイへのアドレスと、又は／及び、前記UEが前記ホームPLMN内のゲートウェイに接続すべきであると前記ホームPLMNが選択している場合に前記ホームPLMN内のゲートウェイへのアドレスを、少なくとも前記UEの前記IDに基づいて受信するステップとを有する方法が提供される。
【００４７】
好ましい実施形態によれば、前記選択する手段は、前記ユーザIDに基づいて、前記選択の結果を決定する１つ以上の有効なポリシを特定する手段をさらに有する。
【００４８】
第５の見地によれば、UEの在圏PLMNに接続されるアクセスネットワーク内に位置する前記UEを接続するためのゲートウェイを選択する、前記UEのホームPLMNであるPLMNにおける装置が提供される。前記装置は、前記UEのIDを有する第１の完全修飾ドメイン名FQDNを受信する手段を有し、前記ホームPLMNは前記在圏PLMNのIDを知っている。前記装置は、前記受信した前記ユーザのIDに基づいて、前記UEが前記在圏PLMN内のゲートウェイのみへのコネクションを確立すべきであることを選択する手段と、前記受信した前記第１のFQDNの代わりに用いられ在圏PLMNに送信されるべき第３のFQDN、を有するCNAMEリソースレコードをホームPLMN DNSサーバによって送信する手段を有し、前記第３のFQDNを解決することによって前記在圏PLMN DNSサーバがゲートウェイアドレスを前記UEへ送信できるように、前記第３のFQDNはW-APNネットワーク識別子及び前記在圏PLMNの前記IDによって構成される。
【００４９】
第６の見地によれば、接続するゲートウェイを決定するための、UEにおける装置であって、前記UEは前記UEの在圏PLMNに接続されるアクセスネットワーク内に位置するとともにホームPLMNに属する前記UEにおける装置が提供される。前記装置は、前記ホームPLMNに属するドメイン名を有する第１のFQDNをDNS要求に含める手段と、前記在圏PLMNのIDを前記第１のFQDNに含める手段と、前記UEが前記在圏PLMN内のゲートウェイに接続すべきであると前記ホームPLMNが選択している場合に前記在圏PLMN内のゲートウェイへのアドレスを、又は／及び、前記UEが前記ホームPLMN内のゲートウェイに接続すべきであると前記ホームPLMNが選択している場合に前記ホームPLMN内のゲートウェイへのアドレスを、少なくとも前記UEの前記在圏PLMNの前記IDに基づいて受信する手段とを有する。
【００５０】
従って、本発明によって達成される主要な利点は、ローカルブレイクアウトを選択すべきであるかどうかを前記HPLMNが決定できることである。前記決定を行う際に、前記HPLMNは関連するポリシ及び他のプロパティを知っているため、これは有利である。
【００５１】
別の利点は、実施形態にかかる方法が、TTGの場合に、所与のユーザについて、同一のGGSNによってサービスの提供を受けるW-APNへ向かう全てのトンネルが同一のTTGへ向けられることを確実にするメカニズムを提供するためにも利用可能なことである。
【００５２】
さらなる利点は、実施形態にかかる方法が、１つのローカルブレイクアウトトンネルと１つのホームトンネルであるデュアルトンネルを用いる、ローカルブレイクアウトとホームトンネリングとの同時実施のための柔軟なサポートによって拡張可能なことである。どのトンネルを用いるかの選択は、パケットフィルタを用いてパケットごとになされる（実際には、フローごとと同等であろうが）。
【００５３】
さらなる利点は、方法が、IPsecトンネルエンドポイントがWAG又はAEN（又はAENのようなノード、例えばGSN+）に、（AEN/GSN+に併合されたPDG/TTG機能を用いて）移される、段階的に進化するシナリオにも使用可能なことである。
【００５４】
さらなる利点は、実施形態にかかる本発明が、W-APNのみに基づくことに代わり、PDG/TTG（又はGSN+又はAEN）のW-APN及びユーザIDに基づくDNS表示を可能にすること、すなわち、制御手段の柔軟性が増加することである。
【００５５】
さらなる利点は、方法が、WLANアクセスネットワーク及び在圏3GPPネットワーク(VPLMN)に対して透過的であり、ホームネットワーク(HPLMN)及び端末／UEにのみ影響することである。
【００５６】
さらなる利点は、方法が、方法のホームネットワーク部品及びその端末部品の両方が同一のベンダから（カスタマイズされた端末として、又はダウンロード可能なソフトウェアとしてでもよい）供給されるならば、標準化なしにオペレータに提供されてよいことである。
【００５７】
さらなる利点は、方法が、I-WLANトンネリング方法がアクセスネットワークと3GPP PLMNとの間の連携に用いられるという条件で、WLAN以外の他の形式の非3GPPアクセスネットワークにも用いられてよいことである。
【００５８】
さらなる利点は、方法の基本的なコンセプトが、3GPPネットワークの進化のために検討されている、長期的に進化するネットワークアーキテクチャの１つにおいて、AEN選択／割り当て手順に再利用できることである。
【００５９】
さらなる利点は、方法の基本的なコンセプトが、3GPP SAEのために検討されている、長期的に進化する別のネットワークアーキテクチャにおけるs-IASA選択／割り当て手順に再利用できることである。
【図面の簡単な説明】
【００６０】
【図１ａ】本発明を実施可能なI-WLANを示す図である。
【図１ｂ】本発明を実施可能な、3GPP SAEについて検討されている長期目標ネットワークアーキテクチャ（複数のAENを統合するもの）の１つを示す図である。
【図１ｃ】本発明を実施可能な、3GPP SAEについて検討されている長期目標ネットワークアーキテクチャ（複数のIASAを統合するもの）の１つを示す図である。
【図２】、
【図３】、
【図４】、
【図５】、
【図６】本発明の実施形態を示す信号図である。
【図７】本発明の装置を模式的に示す図である。
【図８ａ】、
【図８ｂ】本発明に係る発明のフローチャートである。
【発明を実施するための形態】
【００６１】
方法の基本メカニズムを、I-WLAN内のローカルブレイクアウトに関して説明する。ほぼ同様のメカニズムが、本発明の他の用途、すなわち進化版3GPPマルチアクセスアーキテクチャにおけるAEN／s-IASA及びHA/h-IASAの選択／割り当てに対して再利用される。
【００６２】
基本概念は、DNSサーバの選択、従ってローカルブレイクアウト又はホームトンネリングの選択を、ユーザ／UEからHPLMNに移動させることにある。なぜなら、HPLMNは自身のポリシに基づいて、ローカルブレイクアウト又はホームトンネリングを選択可能だからである。HPLMNがローカルブレイクアウトを選択したならば、HPLMNは必要なPDGv/TTGvアドレスをVPLMNから検索することができる。ホームトンネリングとローカルブレイクアウトのどちらかを選択する際、HPLMNは、W-APN、加入パラメータ、VPLMN及び、場合により位置、時刻等といった他のパラメータ、のような任意の関連する入力データを考慮しても良い。
【００６３】
ホームトンネリング対ローカルブレイクアウトの選択の移動は、ユーザ／UEが常に、HPLMNを示すFQDNを構成するように、すなわち、W-APNネットワーク識別子及びオペレータ識別子としてのHPLMN IDを用いてFQDNを構築するよう命じることによって達成できる。そのような「ホームFQDN」はHPLMNを示し、DNSクエリがHPLMNによって解決される要因となる一方で、それはHPLMNがホームトンネリング又はローカルブレイクアウトのいずれか使用するかをポリシに基づき決定するために十分な情報を含んでいない。
【００６４】
HPLMNが正しいポリシを適用できるためには、HPLMNがDNSリクエストを発信したユーザのIDを知らねばならない。そのため、ユーザ／UEは、本発明に従って、ユーザIDをDNSリクエスト内のFQDNに含める。ユーザIDは通常のホームFQDNの前に、＜ユーザID＞．＜通常ホームFPQN＞の形式で含めることができる。また、専用のデリミタ文字列（例えば”zzzz”）を用いて２つの部分に明確に分離することも可能であり、この場合、＜ユーザID＞．＜デリミタ文字列＞．＜通常ホームFPQN＞の形式となる。
【００６５】
そして、HPLMN（すなわち、ホームトンネリングが選択された場合）又は、VPLMN（すなわち、ローカルブレイクアウトが選択された場合）における１つ以上のPDGs/TTGsの１つ以上のIPアドレスを返すことが、HPLMNの選択である。前者の場合、HPLMN内のDNSサーバが応答を形成することができる。後者の場合、HPLMNは受信したPQDNを修正し、それをDNSリクエスト内でVPLMNへ送信してVPLMN内の１つ以上のPDGs/TTGsの１つ以上のIPアドレスを検索する。そして、検索されたIPアドレスは、HPLMNからのDNS応答に含められる。本明細書において、”DNSリクエスト”とは、より一般的な用語である”DNSクエリ”の同義語として用いられることに留意されたい。
【００６６】
さらに、HPLMNは関係するVPLMNのIDを知っていなければならない。その理由は２つある。１つ目の理由は、それがポリシ決定の結果（つまり、ローカルブレイクアウトかホームトンネリングか）に影響しうるからである。２つめの理由は、ローカルブレイクアウトが選択された場合、HPLMNはどのVPLMNでPPGv/TTGvアドレスを検索するかを知る必要があるからである。本発明の一実施形態において、UEはHPLMNを知らせるため、FQDN内にVPLMN IDを含めるように構成される。VPLMN IDは例えば、ユーザIDの後ろに含められ、形式は＜ユーザID＞．＜VPLMN ID＞．＜通常ホームFPQN＞又は、＜ユーザID＞．＜デリミタ文字列＞．＜VPLMN ID＞．＜デリミタ文字列＞．＜通常ホームFPQN＞となる。本発明の別の実施形態において、VPLMN IDはFQDNに含められない。代わりに、VPLMN IDは、（FQDN内のユーザIDで示される）関連ユーザについて先立ってなされるWLANアクセスAAA手順の間に、HPLMNによって、関連するVPLMNがどれかを調べるために検索される。後者の実施形態は、オプションであるアクセス認証がWLANアクセスネットワークにおいて行われていることを明らかに必要とする。
【００６７】
UEがPDG/TTG IPアドレスを受信済みである際、その後引き続くIPsecトンネル確立手順は、既存の方法と同一である。
【００６８】
FQND内のユーザIDは、NAIの名前部分のみであっても、NAI全体であってもよい。前者は、名前部分のみで不明瞭でない場合、つまり、原則としてHPLMNが全ユーザに対して同一のドメイン部分(realm part)を用いる場合に使用可能である。後者の場合、FQDN内で許されない文字”@”を、専用デリミタ文字列、例えば”.at.”に置き換えることができる。このリスクを回避するため、".at."で終了する名前部分と、".at."で始まるドメイン部分のいずれかを有することは許されるが、両方を有することは許されないようにすることができる。最も簡単なのは、名前部分の柔軟性を維持し（すなわち、".at."で終了する名前部分を許可する）、（NAIのドメイン部分を構成しうる）".at."で始まるドメイン部分が無いことをホームオペレータに保証させることである。
【００６９】
このようにして、本発明は、UEの在圏PLMN（UEのユーザのホームPLMNである）に接続されるアクセスネットワーク内に位置するUE９０６が接続すべきゲートウェイを選択するための装置であって、PLMN９０５内の１つ以上のノード９０４において実施される、図７に示す装置９００を提供する。これは、UEがSIMカードを備えており、SIMカードに登録されているユーザがホームPLMNに属していることを暗示する。装置は、UEのユーザのIDを有する第１のFQDNを受信するための手段９０１を備える。ホームPLMNは、在圏PLMNのIDを知っている。装置は、少なくとも受信したユーザIDに基づいて、UEがホームPLMN内のゲートウェイのみへのコネクションを確立すべきか、在圏PLMN内のゲートウェイのみへのコネクションを確立すべきか、ホームPLMN内のゲートウェイと在圏PLMN内のゲートウェイの両方へのコネクションを確立すべきかを選択するための手段９０２と、在圏PLMN内のゲートウェイのみへのコネクションが選択された場合には在圏PLMN内のゲートウェイに属するアドレスを、ホームPLMN内のゲートウェイのみへのコネクションが選択された場合にはホームPLMN内のゲートウェイに属するアドレスを、在圏PLMN内のゲートウェイとホームPLMN内のゲートウェイの両方へのコネクションが選択された場合に在圏PLMN内のゲートウェイに属するアドレスとホームPLMN内のゲートウェイに属するアドレスを、それぞれ送信するための手段９０３を備える。
【００７０】
さらに、本発明はUE内の装置であって、ホームPLMNに属するドメイン名を有する第１のFQDNをDNSリクエストに含めるための手段９０７と、UEのユーザのIDを第１のFQDNに含めるための手段９０８と、UEが在圏PLMN内のゲートウェイへ接続すべきであるとホームPLMNが選択した場合に在圏PLMN内のゲートウエイへのアドレスを、又は／及びUEがホームPLMN内のゲートウェイへ接続すべきであるとホームPLMNが選択した場合にホームPLMN内のゲートウエイへのアドレスを、少なくともUEのユーザのIDに基づいて受信するための手段９０９とを備える装置に関する。含めるための手段が、在圏PLMNのIDを含めることが可能であっても良いことに留意されたい。
【００７１】
本発明はさらに、UEのユーザの在圏PLMN（UEのユーザのホームPLMNである）に接続されるアクセスネットワーク内に位置するUEが接続すべきゲートウェイを選択するための、PLMNにおける方法にも関連する。この方法を図８ａに示す。方法は、第１のFQDNを受信するステップ８０１（ここで、第１のFQDNはUEのユーザのIDを有し、ホームPLMNは在圏PLMNのIDを知っている）と、受信したユーザのIDに基づいて、UEが、ホームPLMN内のゲートウェイのみへのコネクション、在圏PLMN内のゲートウェイのみへのコネクション、またはホームPLMN内及び在圏PLMN内のゲートウェイの両方へのコネクション、のどれをUEが確立すべきかを選択するステップ８０２と、在圏PLMN内のゲートウェイのみへのコネクションが選択された場合には在圏PLMN内のゲートウェイに属するアドレスを、ホームPLMN内のゲートウェイのみへのコネクションが選択された場合にはホームPLMN内のゲートウェイに属するアドレスを、在圏PLMN内のゲートウェイとホームPLMN内のゲートウェイの両方へのコネクションが選択された場合には在圏PLMN内のゲートウェイに属するアドレスとホームPLMN内のゲートウェイに属するアドレスを、それぞれ送信するためのステップ８０３とを有する。
【００７２】
本発明はさらに、UEのユーザの在圏PLMNに接続されるアクセスネットワーク内に位置するUE（UEのユーザはホームPLMNに属している）が、接続すべきゲートウェイを選択するための、UEにおける方法にも関連する。この方法を図８ｂのフローチャートに示す。方法は、ホームPLMNに属するドメイン名を有する第１のFQDNをDNSリクエストに含めるステップ８０４と、UEのユーザのIDを第１のFQDNに含めるステップ８０５と、UEが在圏PLMN内のゲートウェイへ接続すべきであるとホームPLMNが選択した場合に在圏PLMN内のゲートウエイへのアドレスを、又は／及びUEがホームPLMN内のゲートウェイへ接続すべきであるとホームPLMNが選択した場合にホームPLMN内のゲートウエイへのアドレスを、少なくともUEのユーザのIDに基づいて受信するステップ８０６とを有する。
【００７３】
図２に、汎用的な手順をさらに示す。UEは、自身が構築したFQDN（図２ではFQDNHPLMNと表記する）を解決するために、WLANアクセスネットワーク内のDNSサーバへDNSリクエストを送信する。自身ではこの特別なFQDNを解決できないWLANアクセスネットワークDNSサーバは、リクエストをHPLMNへ転送する。
【００７４】
HPLMNは受信したFQDNから、ポリシ決定への入力データとなるユーザID及びW-APNを抽出する。VPLMN IDがFQDNに含められる実施形態において、HPLMNはVPLMN IDも抽出する。VPLMN IDがFQDNに含められない実施形態では、HPLMNが、先に行われたネットワークアクセス手順の間に、（例えばAAAサーバに）保存されたデータを調べ、関連VPLMNがどれかを見出す（ただし、HPLMNがポリシ決定及び／又はDNS処理にこの情報を必要としている場合）。そして、いずれの実施形態においても、HPLMNはホームトンネリングとローカルブレイクアウトのいずれを用いるべきかを決定する。
【００７５】
ホームトンネリングが選択された場合、HPLMNは１つ以上のPDGh/TTGhアドレスを返す。ローカルブレイクアウトが選択された場合、HPLMNはFQDN（図２ではFQDNVPLMNと表記される）を、W-APNネットワーク識別子とオペレータ識別子としてのVPLMN IDを用いて構築（すなわち、UEがローカルブレイクアウトのための既存の方法で構築するものと同様のFQDNである）し、それを解決するためにDNSリクエストをVPLMNへ送信する。VPLMNは、HPLMNが自身のDNS応答に含めた１つ以上のPDGv/TTGvアドレスを、WLANアクセスネットワーク及びUEへ向けて返す。HPLMNは、関連するFQDNについてのデータをVPLMNからの以前の応答からキャッシュしている場合、又は関連するVPLMNに対してPDGv/TTGvアドレスをHPLMNが設定した場合には、DNSリクエストを送信しなくてもよい。HPLMNからのDNS応答は、WLANアクセスネットワーク内のDNSサーバ（又は場合によっては別の中間DNSサーバ）又はUE内のDNSリゾルバが、FQDN-IPアドレスマッピングをキャッシュすることを回避するため、応答が時間ゼロの間有効であること（すなわち、この応答がこの特定のリクエストについてのみ有効であること）を示す、ゼロに設定された寿命（生存時間、TTL）を有するべきである（これにより、HPLMNがその後の同一FQDNの解決において、（異なる）ポリシ決定を行う可能性を排除することができる）。”DNSリゾルバ”は、アプリケーションとDNSインフラストラクチャとの間のインタフェースを形成する、ホスト（例えばUE／端末）内のDNSソフトウェアである。
【００７６】
PDG/TTGアドレスを受信すると、UEは通常の方法でIPsecトンネル確立を開始することができる。
【００７７】
図３及び図４においては、HPLMN DNSサーバが他の関与するHPLMNエンティティから切り離されているので、修正されたDNS手順についての信号手順図がもう少し詳細に示されている。（単独のエンティティとして図示及び説明されるけれども、HPLMN DNSサーバは、DNSシステムが通常有する分散的性質に従って、HPLMNのドメイン名空間の異なる部分を受け持つ複数のDNSサーバであってよい。） HPLMN DNSサーバが分離される場合、汎用手順は２つの副変形物(sub-variants)に分岐し、一方を図３に、他方を図４に示す。いずれの副変形物においても、HPLMN DNSサーバはホームトンネリング／ローカルブレイクアウト決定を得て、最終的にFQDNを解決するため、AAAサーバ及び／又はポリシサーバに問い合わせる。
【００７８】
図３において、AAAサーバ／ポリシサーバは、ホームトンネリング／ローカルブレイクアウトの決定を行うだけでなく、PDG/TTGアドレスを検索／選択し、そのアドレスをHPLMN DNSサーバへ返す。AAAサーバ及びポリシサーバは単独のエンティティでも、複数の個別エンティティであってもよい。ホームトンネリングの場合、PDGh/TTGhアドレスはHPLMN内部で設定されるが、ローカルブレイクアウトの場合には、PDGv/TTGvアドレスを（アドレスがキャッシュされている場合やHPLMNにおいて設定されている場合をのぞいて）VPLMNから検索しなければならない。これを行うため、AAAサーバ／ポリシサーバは上述したFQDNVPLMNを構築し、通常のDNS手順を通じてそれを解決する。そして、AAAサーバ／ポリシサーバはPDGv/TTGvアドレスをHPLMN DNSサーバへ送信する。
【００７９】
図４では、HPLMN DNSサーバと、AAAサーバ／ポリシサーバとの連携が異なる。AAAサーバ／ポリシサーバはポリシ決定（すなわち、ホームトンネリング又はローカルブレイクアウト）の表示を返すが、アドレスは必ずしも返さなくて良い。ホームトンネリングの場合、AAAサーバ／ポリシサーバは１つ以上のPDGh/TTGhアドレスを返すことができるが、それらのアドレスをHPLMN DNSサーバ内に設定することも可能である。ローカルブレイクアウトの場合、AAAサーバ／ポリシサーバはポリシ決定の表示のみを返し、残り（すなわち、PDGv/TTGvアドレスがHPLMN DNSサーバ内に既にキャッシュされいていなければ、FQDNVPLMNを構築し、VPLMNから対応するPDGv/TTGvアドレスを検索する）はHPLMN DNSサーバに行わせても良い。しかし、これは、FQDNHPLMNに含まれているVPLMN IDが用いられるような変更を必要する。VPLMN IDがFQDNHPLMNに含まれていない場合、AAAサーバ／ポリシサーバはVPLMN IDあるいはFQDNVPLMN全体を返さねばならない（HPLMN DNSサーバとAAAサーバ／ポリシサーバにインテリジェンスをどのように割り振りたいかに依存する）。この場合も、HPLMN DNSサーバは、PDGv/TTGvアドレスが既に自身にキャッシュされていなければ、VPLMNからPDGv/TTGvアドレスを検索する。
【００８０】
エイリアス-DNSの別名(CNAME)機能（P. Mockapetris、”ドメイン名-コンセプト及び施設”、RFC 1034, 1987年11月を参照されたい）をさらに使用することができる。そして、ローカルブレイクアウトの場合、HPLMNは自身ではPDGv/TTGvアドレスを検索しないであろう。HPLMN DNSサーバが、元のDNSリクエスト内のFQDNの代わりに用いられるべきFQDNを含んだ、CNAMEリソースレコードを応答で返すであろう。返された新しいFQDNは、W-APNネットワーク識別子及びVPLMN IDをオペレータ識別子として用いて構築されたFQDNVPLMN（すなわち、ローカルブレイクアウトのための既存方法において、UEが構築するFQDNと同様のもの）であろう。FQDNVPLMNはVPLMNを示すため、アクセスネットワークDNSサーバは新しい要求を、FQDNVPLMNが解決されるようにVPLMN DNSサーバへ送信する。（CNAME リソースレコードに含まれる）FDNVPLMNとともにDNS応答をUEまでの全経路において送信し、新しいFQDNを用いてDNSリクエストをリスタートすることも可能である。）これは、方法の原理を変更させず、通常のDNSの振る舞いは、（ホストが明確にCNAME応答を要求しない限り）CNAME応答をホストへ返さないので、本明細書においては、アクセスネットワークDNSサーバが、受信したFQDNVPLMNを用いてDNSリクエストをリスタートさせるものと仮定している。HPLMN DNSサーバへ到達する前に、他のDNSサーバ、例えばHPLMNオペレータが所有する別のDNSサーバが問い合わせを受けるとともに、DNS再帰モードが用いられる場合にそれらDNSサーバの１つが、FQDNVPLMNを有するDNS応答を受信して、FQDNVPLMNをアクセスネットワークDNSサーバへ送信する代わりに、新しいFQDNを用いてDNSリクエストをリスタートさせるということも考えられる。しかしながら、それは単に、最も興味深い場合を説明するためだけに選択されている。VPLMN DNSサーバは１つ以上のPDGv/TTGv IPアドレスを応答し、アクセスネットワークDNSサーバはその応答をUEへ転送する。UEがPDG/TTGアドレスを受信すると、UEは通常の方法でIPsecトンネル確立を進めることができる。図５及び図６はローカルブレイクアウトの場合におけるこの変形についてのメッセージフローを示している。CNAME機能はローカルブレイクアウトの場合のみに用いられるであろうから、図２、図３、図４は依然としてホームトンネリングの場合に適用される）
【００８１】
図７に示す装置は、受信したユーザのIDに基づいて、UEが在圏PLMN内のゲートウェイのみへのコネクションを確立すべきであることを選択する別の態様にかかる選択手段９０２と、受信した第１のFQDNの代わりに用いられ在圏PLMN DNSサーバに送信されるべき第３のFQDN、を有するCNAMEリソースレコードをホームPLMN DNSサーバによって送信する手段９０３を有し、第３のFQDNを解決することによって在圏PLMN DNSサーバがゲートウェイアドレスをUEへ送信できるように、第３のFQDNはW-APNネットワーク識別子及び在圏PLMNのIDによって構成される。
【００８２】
図５はCNAME機能がローカルブレイクアウトの場合に用いられる際の手順を示す。この手順は、アクセスネットワークDNSサーバが新たなFQDNを用いてDNSリクエストをリスタートすること、すなわちPDGv/TTGvアドレスをVPLMN DNSサーバから検索すること、が可能なように、HPLMNがFQDNVPLMNをどのように返すかを示している。
【００８３】
図６において、HPLMN内のDNSサーバ及びAAAサーバ／ポリシサーバを個別に示すことにより、図５よりもメッセージシーケンス図を少し詳細にしている。AAAサーバ／ポリシサーバはポリシ決定の表示のみを返し、HPLMN DNSサーバにFQDNVPLMNを構築させてもよい。しかし、これはFQDNHPLMN内に含まれるVPLMN IDを用いる実装を必要とする。VPLMN IDがFQDNHPLMNに含まれていない場合、AAAサーバ／ポリシサーバはVPLMN IDあるいは場合によりFQDNVPLMN全体を返さねばならない（HPLMN DNSサーバとAAAサーバ／ポリシサーバにインテリジェンスをどのように割り振りたいかに依存する）。
【００８４】
本セクションにおけるメッセージシーケンス例は全て、一般的に行われているようにDNS再帰モードが用いられていることを仮定している。もし非再帰（反復）モードが使われているとすると、HPLMN DNSサーバは、ローカルブレイクアウトの場合にFQDNVPLMN（すなわち、既存の方法では、ローカルブレイクアウトを選択する場合にUEが構築するFQDN）を返すには、CNAME機能を用いねばならないであろう。そして、FQDNVPLMNはUEからの２回目のDNSリクエストに含めることが可能であろう。あるいは、HPLMN DNSサーバは、非再帰表示を無効として、とにかくVPLMN DNSサーバからPDGv/TTGvアドレスを検索することも可能であろう。これ以外に、DNS非再帰モードの使用は、DNSメッセージのシーケンスのみを変更するであろうが、方法の原理には変わりがない。
【００８５】
上述の通り、本発明をI-WLANに関して説明している。本発明の実施形態に従ったI-WLANにおける拡張や変更も可能である。
【００８６】
ユーザIDをFQDNに含めるという概念は、所与のユーザについて、同一のGGSNからサービスを提供されるW-APNへ向かう全てのトンネルが同一のTTGへ向けられることを保証するためにも用いることができる。この概念を用い、HPLMNはDNSを通じてTTGアドレスを割り当てる際に、W-APN及びユーザIDの両方へアクセスすることができる。従って、上述の通り、HPLMNは必要な場合、同一のTTGが割り当てられることを保証可能である。
【００８７】
この調整を提供するインテリジェンスは、HPLMN内のHPLMN DNSサーバ又はAAAサーバ／ポリシサーバに配置することが可能である。しかし、これは、TTGがHPLMNに割り当てられる場合のみ、すなわち、TTGhについてのみ機能する。TTGがVPLMNに割り当てられる際、すなわちTTGvについても機能させるためには、VPLMN DNSサーバへのDNSリクエスト内で送信されるFQDNにもユーザIDを含めることができるよう、方法を拡張する必要がある。そして、VPLMNは、HPLMNと同様のユーザ毎の調整を実行することが可能になり、必要な際には同一のTTGvが割り当てられることを保証可能となる。
【００８８】
この方法は、一実施形態によれば、同一のW-APNについてでさえ、ローカルブレイクアウトとホームトンネリングの両方を同時にサポートするように拡張可能である。これは制御手段の粒度(granularity)を、幾分粗いW-APN単位から上昇させ、HPLMNのトラフィックストリーム制御の柔軟性を改良するであろう。
【００８９】
ローカルブレイクアウトとホームトンネリングの同時使用は、HPLMNによって決定されるべきである。個々のトンネルを通じて送信するパケットを制御するため、パケットフィルタが用いられる。ローカルブレイクアウトとホームトンネリングが同時使用されるべきであることをUEに通知するため、HPLMNは１つ以上のPDGh/TTGhアドレスと１つ以上のPDGv/TTGvアドレスの両方を、DNSリクエストに応答して返す。あるいは、HPLMNは、１つ以上のPDGh/TTGhアドレスと、別のDNSリクエストを通じて１つ以上のPDGv/TTGvアドレスに解決可能なCNAMEレコードを返す。どのパケットフィルタにもマッチしないパケットについて、ホームトンネリング又はローカルブレイクアウトのどちらがデフォルトの方法であるべきかをPDGh/TTGh及びPDGv/TTGvの発生順序によって示すこともできる。
【００９０】
一実施形態によれば、あるW-APNについて、UEから送信されたパケットに対する（両方が同時に用いられている際に）ローカルブレイクアウトかホームトンネリングかの選択は、パケットフィルタに基づくことができる。パケットフィルタは、IPソースアドレス、IPディスティネーションアドレス、トランスポートプロトコル（例えばTCP又はUDP）、すなわち、IPv4におけるプロトコル番号フィールド（IPv6では次のヘッダフィールド）、ソースポート番号、ディスティネーションポート番号、サービスタイプ(TOS)(IPv4)、トラフィッククラス(IPv6)といったパラメータに基づくことができる。
【００９１】
パケットフィルタは、GPRS/UMTS用に規定されたトラフィックフローテンプレート(TFT)（3GPP TS 23.060 v6.8.0, 「第３世代パートナーシッププロジェクト；技術仕様グループサービス及びシステムアスペクト；汎用パケット無線サービス(GPRS)；サービス解説；ステージ２（リリース６））を参照のこと）と同一又は類似の形式であってよいが、同様の目的を提供する他の形式であっても良い。自身のパラメータがUE及び現在のトラフィックフローに関する動的なパラメータ、例えばディスティネーションアドレス及び、ソースアドレスとして用いられるUE IPアドレス、に関して規定されるという意味において、相対パケットフィルタを規定することもまた好ましく行うことができる。例えば、パケットフィルタは、UEがVPLMNから受信したIPアドレスと同一アドレス範囲のディスティネーションアドレスを有するパケットは、ローカルブレイクアウトを用いて送信されるべきことを提示することができる。
【００９２】
HPLMN及びVPLMNが個々のトンネルを通じてトラフィックストリームを整理することが可能なように、同様の／対応するパケットフィルタを、PDGh/TTGh、PDGv/TTGv及び／又はWAGへAAAインフラストラクチャを通じて送信することもできる。
【００９３】
トラフィックフローを管理するパケットフィルタは、いくつかの方法でUEへ搬送可能である。最も簡単な方法は、UICC上のUSIMアプリケーションの設定を通じての搬送である。これらの設定は、加入時に保存することができるが、HPLMNはUICC上のデータの”無線を通じた(over the air)”変更のための、利用可能な方法を用いて、それらを動的に更新することができる。パケットフィルタを端末装置で（UICCの外部で）設定することもまた可能であるが、そうするとパケットフィルタが加入者でなく端末装置と結びつけられるため、あまり好ましくない。
【００９４】
設定よりも進んだ方法は、必要な際にパケットフィルタを動的に搬送することである。これを行うための様々な手段には、UE-PDG/TTG IPsecトンネル確立中のEAP、WLANアクセス認証中、DNS、及び個別読み出し(Separate retrieval)中のEAPを含んでよい。
【００９５】
パケットフィルタは、UE-PDG/TTG IPsecトンネル確立中に拡張可能認証プロトコル(EAP)を用いて搬送することができる。従って、EAPを通じて汎用的なデータ転送メカニズムを用いることにより、パケットフィルタはEAPパケット上に乗せることができる。この汎用的なデータ転送メカニズムは、様々なEAP方法に存在する、汎用コンテナ属性又は汎用的なデータ転送のための手段のいずれかであってよい。汎用コンテナ属性という用語の詳細な説明は、国際出願WO2004/112348、WO2004/112349、及びWO2004/112347のパンフレットに記載されている。
【００９６】
この方法を通じて搬送されるパケットフィルタは、確立処理にEAP手順が関連するトンネル、を通じて送られるべきパケットを特定するために用いることができる。さらに、パケットフィルタは、このトンネルが関連するW-APNに対するデフォルトトンネルかどうかの表示を有していても良い。
【００９７】
これは、ローカルブレイクアウトとホームトンネリングの両方が同時に用いられ、その１つが個々のトンネル確立に関連付けられる場合、パケットフィルタの２つの転送が存在するであろうことを意味する。
【００９８】
パケットフィルタはまた、WLANネットワークアクセスに関連するユーザ認証の間に、上述したのと同じメカニズムを用いてEAPパケットに乗せることが可能である。この場合、HPLMNは、UEが、自身のその後のUE-PDG/TTGトンネル確立リクエストでどのW-APNを用いるかを知っていない。そのため、HPLMNは、ユーザの加入に含まれている全てのW-APLに関連するパケットフィルタを有する必要がある。
【００９９】
さらに、DNSは、UEがFQDNを１つ以上のPDG/TTGアドレスに解決することを試行する際に、パケットフィルタをHPLMNからUEへパケットフィルタを搬送するためにも用いることができる。この場合、HPLMNは関連するW-APNを知っているため、関連するW-APNに関連付けられたパケットフィルタのみ、搬送する必要がある。
【０１００】
文字列を含むDNS TXTリソースレコード（P. Mockapetris, 「ドメイン名-実装及び仕様」, RFC 1035, 1987年11月、参照）は、パケットフィルタの搬送に用いることができる。パケットフィルタ定義のための明確な形式がTXTリソース内部で用いられる必要があるだろうが、DNSシステムはこの形式を知らないであろう。R. Rosenbaum, 「ドメインネームシステムを用いた任意の文字列属性の保存」, RFC 1464, 1993年5月に示唆されている、TXTリソースレコードの構造化された利用は、 パケットフィルタ定義形式の規定に使用することができる。
【０１０１】
別の方法で、この目的の新たなDNAリソースレコードを規定しても良い。未知のリソースレコードは、DNSシステムによって透過的に処理されるので、新たなリソースレコードは3GPPスフェア外部で広く採用される必要はない。HPLMN内及びその加入者の端末ソフトウェア内でのみ実装される専用メカニズムであっても良い。
【０１０２】
さらなる遅延が発生するが、パケットフィルタの動的読み出しのための別個の手順を導入することも可能である。UEはパケットフィルタをHPLMNから、例えばHTTP(HyperText Transfer Protocol)（トランスポートレイヤセキュリティ(TLS)、セキュアソケットレイヤ(SSL)又はセキュアHTTP(S-HTTP)によって保護されることが好ましい）を用いて読み出すことができるであろう。HTTPリクエスト内で用いるURI (Uniform Resource Identifier)は、設定済み部分と動的部分との組み合わせであってよく、動的部分はW-APN、ユーザID及び場合によりVPLMN ID（VPLMN IDが含まれていない場合、HPLMNはAAAサーバを調べてVPLMN IDを読み出す必要がある）を含むことができる。１つのトンネルに対して複数のパケットフィルタが同時に読み出された場合（例えば、ローカルブレイクアウトトンネル用のパケットフィルタとホームトンネル用のパケットフィルタとについて、読み出し手順が別個の場合）、URIはリクエストがローカルブレイクアウトとホームトンネルのどちらに関するものかの表示を含むべきである。この表示は設定された部分のどちらに属してもよい（その場合、個々のトンネルについて１つずつ、２パートURIをUSIMに設定する必要がある）。
【０１０３】
USIM内のURIのいかなる部分も設定しないために、パケットフィルタの呼び出し前にHPLMNからUEへURIを転送することができる。HPLMNは、セッションに依存しない（すなわち、W-APN、ユーザID、VPLMN ID及び場合によりローカルブレイクアウト／ホームトンネル表示を除外した)URIの全体又はURIの一部のみを転送することができる。ローカルブレイクアウト／ホームトンネル表示は、URIのセッション依存部分として見ることができ、その場合、UEがURIの非セッション依存部分に付加することができる。ローカルブレイクアウト／ホームトンネル表示をURIの非セッション依存部分とも見ることができるが、その場合、HPLMNから搬送されるURIの部分に含めることができる。後者の場合、UEが確立中のIPsecトンネルがローカルブレイクアウトであるかホームトンネルであるかを、UEが知る必要はないという利点を有する。
【０１０４】
URIの全体又は非セッション依存部分は、パケットフィルタを転送するための上述したメカニズムのいずれかを用いてUEへ搬送することができる。
【０１０５】
URIの全体又は非セッション依存部分がUE-PDG/TTG IPsecトンネル確立中のEAPを用いて搬送されるとすると、その後のパケットフィルタ読み出しは関連するトンネルに関連付けられたパケットフィルタのみを返すであろう。従って、URIはローカルブレイクアウト／ホームトンネル表示を含まなくてはならず、HPLMNから転送されるか、UEによって付加される。URIの全体又は非セッション依存部分はEAPにおける汎用的データ搬送手段を用いて、又は保護された拡張可能認証プロトコルバージョン２(PEAPv2)が用いられる場合には、URI TLV(TLVは型−長さ−値符号化属性を表す）を用いて搬送することができる。
【０１０６】
URIの全体又は非セッション依存部分がWLANアクセス認証手順間のEAPを用いて搬送される場合、関連するトンネルは未だ確立されていない。従って、HPLMNから搬送される情報は、ユーザが加入する任意のW-APNに対して（さらに、ローカルブレイクアウトトンネル及びホームトンネルの両者について）必要なURIをUEが構築するために十分なものでなければならない。すなわち、HPLMNが完全なURIを転送する場合には、各加入W-APNについて１つのURI（ローカルブレイクアウトトンネル及びホームトンネルの両方に対するパケットフィルタが単独の手順で読み出し可能な場合）を、又は各加入W-APNについて、個々のトンネルに１つずつ、２つのURI（パケットフィルタが各トンネルについて別個に呼び出される場合）を、を転送しなければならない。
【０１０７】
HPLMNが部分URIのみを転送するとすると、３つの場合がある。ローカルブレイクアウトトンネル及びホームトンネルの両方についてのパケットフィルタを読み出すのに単独の手順が用いられる場合、HPLMNは１つの非セッション依存URI部分を転送すればよい。１つのトンネルについて複数のパケットフィルタが１度に呼び出される場合、HPLMNは、１つがローカルブレイクアウトトンネルについて、１つがホームトンネルについての、２パートURIを転送するか、１つの非セッション依存URI部分を転送して、UEにローカルブレイクアウトトンネル／ホームトンネル表示の付加を任せることができる。
【０１０８】
URI又は部分URIの搬送にEAPが用いられる場合、汎用的なデータ搬送手段か、PEAPv2が用いられる場合にはURI TLVを用いて完全なURI又は非セッション依存URIを搬送することができる。
【０１０９】
URI又は部分URIの搬送にDNSが用いられる場合、HPLMNはローカルブレイクアウトトンネル及びホームトンネルに対するパケットフィルタが単独の手順で読み出されるか、個別の手順で読み出されるかに応じて異なる振る舞いをする。単独手順が用いられる場合、HPLMNは１つの完全なURIか、１つの非セッション依存URI部分を転送する。個別の読み出し手順が用いられる場合、HPLMNは２つの完全なURI（個々のトンネルについて１つずつ）を転送するか、２つのURI部分（個々のトンネルについて１つずつ、すなわち、ローカルブレイクアウト／ホームトンネル表示を含む）を転送するか、１つのURI部分を転送し、ローカルブレイクアウト／ホームトンネル表示の付加をUEに任せることができる。
【０１１０】
さらに進歩した形式のパケットフィルタは、パケット自体の特性だけでなく、時間（例えば時刻や曜日）を考慮することもでき、時間依存(time sensitve)パケットフィルタと呼ぶ。そして、時間依存パケットフィルタの各々に、そのパケットフィルタが有効な期間を示すために時間情報が添付されるであろう。
【０１１１】
あるいは、パケットフィルタ命令に時間情報を含める代わりに、必要な際に、HPLMNがUE及び関連するPLMNノード内（同様の／対応するパケットフィルタがPLMNノードで用いられている場合）のパケットフィルタを単純に変更して、時間に依存したパケットフィルタ処理を実現してもよい。この場合、HPLMNは、UEがWLANアクセスネットワークと接続されている際に常時利用可能な、UEと通信するための手段を必要とする。上述した通信手段のうち、条件を満たす唯一のものは、HPLMNからの「無線による」変更を用いた、USIMアプリケーション内のパケットフィルタ設定である。PLMNノード内のパケットフィルタを変更するため（必要なら）、HPLMNはAAAインフラストラクチャ及び関連ユーザに対するアクティブAAAセッションを用いることができる。
【０１１２】
上述した、同時ローカルブレイクアウト／ホームトンネリング中のトラフィック制御に対するパケットフィルタの利用方法は、ホームトンネリング及び／又はローカルブレイクアウトと同時のWLAN直接IPアクセスをサポートするように拡張することができる。そして、HPLMNは、どんなパケットをホームトンネリング又はローカルブレイクアウトを用いて送信すべきか制御するパケットフィルタのみならず、どんなパケットをWLAN直接IPアクセスを用いて送信すべきかを制御するパケットフィルタをUEに転送するであろう。
【０１１３】
ローカルブレイクアウト又はホームトンネリングの選択はHPLMNによって制御される。しかし、その選択にユーザが影響を与えることができるようにするか、DNSリクエスト内でユーザの選択を示すことにより、少なくとも選択についての好みを表明できるようにすることが好ましい。基本的な方法においては、HPLMNがその決定についての入力データの一部として含めることのできる、あり得るユーザプロファイルを通じた方法が、決定に影響を与えるユーザの唯一の方法である。好みを表明するための、動的なセッション単位のメカニズムは存在しない。
【０１１４】
より動的な手段を用いてローカルブレイクアウト／ホームトンネリング決定に影響を与えるユーザの可能性を高める方法は、ユーザに、必要に応じてFQDN内に選択表示、すなわち、関連するセッションについてユーザがローカルブレイクアウト又はホームトンネリングのどちらを好むのかの表示、を含めさせることである。HPLMNは、（もし存在すれば）選択表示を、ユーザID及び場合によってはさらにVPLMN IDとともに抽出し、選択表示をローカルブレイクアウト／ホームトンネリング決定についての入力データの一部として用いる。
【０１１５】
選択表示は例えば、ローカルブレイクアウトが好ましいことを示す文字「Ｌ」か、ホームトンネリングが好ましいことを示す文字「Ｈ」から構成されてよい。文字の前には専用文字列、例えば、FQDN内にオプションの選択表示が存在することを示す「pppp-」が置かれる。従って、選択表示の完全な形式は、「pppp-X」（Ｘは「Ｌ」又は「Ｈ」を表す）となる。
【０１１６】
FQDNにおいて、ユーザID及び場合によってはさらにVPLMN IDに関する、選択表示の位置は重要でない。FQDN形式（VPLMN IDが含まれる実施形態における）は、例えば、＜ユーザID＞.＜VPLMN ID＞.＜選択表示＞.＜通常のホームFQDN＞、又は、＜ユーザID＞.＜デリミタ文字列＞.＜VPLMN ID＞.＜デリミタ文字列＞.＜選択表示＞.＜デリミタ文字列＞.＜通常のホームFQDN＞であってよい。選択表示がデリミタ文字列として簡単に特定可能であれば、後者のFQDN形式例における、選択表示の前後のデリミタ文字列は不要である。
【０１１７】
ユーザの選択表示をFQDNに含めることは、選択表示がHPLMNに到達する前に不正に変更されるという新たなセキュリティ脅威をDNS手順に導入することになる。そのため、ユーザの選択表示の完全性保護がなされることが好ましい。
【０１１８】
（例えば、R. Arendsらの「DNSセキュリティの導入及び要件」、RFC 4033、2005年3月、に記載されている）DNSSECセキュリティ拡張(DNSSEC)は、DNS応答についてのみ保護を提供し、DNSリクエストの保護は提供しないが、所望の保護を間接的に実現するために用いることができる。HPLMNが自身からUEへのDNS応答の完全性保護を行うためにDNSSECを用い、また、保護された応答中の例えばTXTリソースレコードに、受信した選択表示を含めるとすると、UEは、HPLMNが正しい選択表示を確かに受信したことを確認することができる。返された選択表示がUEからHPLMNへ送信したものと異なる場合、UEは受信したPDG/TTGアドレスを廃棄することが好ましい。
【０１１９】
選択表示を保護するための別の方法は、先行して行われるWLANアクセス認証手順の間に生成される暗号物を利用することである（オプションであるアクセス認証が行われるという条件下で）。暗号物(cryptographic material)は、例えばEAP-AKA手順の中で生成されるCK、IK、MSK又はEMSK（又はEAP-SIM手順の中で生成される対応する暗号物）から構成されてよい。UEはこの暗号物を用いて、FQDNに付加するメッセージ認証コード(MAC)を構築することができる。そして、（VPLMN IDが含まれる実施形態における）FQDNの形式は、例えば＜MAC＞.＜ユーザID＞.＜VPLMN ID＞.＜選択表示＞.＜通常のホームFQDN＞、又は、＜MAC＞.＜デリミタ文字列＞.＜ユーザID＞.＜デリミタ文字列＞.＜VPLMN ID＞.＜デリミタ文字列＞.＜選択表示＞.＜デリミタ文字列＞.＜通常のホームFQDN＞となるであろう。選択表示がデリミタ文字列として簡単に特定可能であれば、後者のFQDN形式例における、選択表示の前後のデリミタ文字列は不要である。同様に、FQDNにMACが含まれているかどうかをHPLMNが常に知っている場合には、MAC及びユーザIDの間のデリミタ文字列は不要である。MACへの入力データ、すなわちMACで保護されるデータは、選択表示だけであってもよいし、FQDN全体であっても、DNSリクエスト全体であっても、その間のいかなるものであってもよい。
【０１２０】
先行するWLANアクセス認証が行われない場合の考えられる対策は、UEに１つ以上の乱数を生成させ、それをSIM内で稼働しているGSM認証アルゴリズムに与えることである。そして、上述したように、生成された暗号物はMACを生成するために用いることができる。そして、上述したように、MACの生成にKC又はIKが用いられる。しかしこの場合には、HPLMNが同一の暗号物を得てMACを検証できるよう、UEは生成した乱数もFQDN内に含める。（VPLMN IDが含まれる変形を用いる）FQDNの形式は、例えば＜乱数＞.＜MAC＞.＜ユーザID＞.＜VPLMN ID＞.＜選択表示＞.＜通常のホームFQDN＞、又は、＜乱数＞.＜MAC＞.＜デリミタ文字列＞.＜ユーザID＞.＜デリミタ文字列＞.＜VPLMN ID＞.＜デリミタ文字列＞.＜選択表示＞.＜デリミタ文字列＞.＜通常のホームFQDN＞であってよい。既に説明したように、選択表示の前後のデリミタ文字列及びMACに続くデリミタ文字列は必要ないかもしれない。
【０１２１】
セキュリティ脅威と戦うさらなる方法は、（選択表示をDNSリクエスト内で保護しないで送信するのに加えて）IPsecトンネル確立に関連する認証手順の中で、UEにセキュアな方法で選択表示をHPLMNに送信させることであろう。そして、HPLMNは、DNSを通じて受信した選択表示が正しいかどうかを確認することができる。UEとHPLMNとの間での選択表示のセキュアな転送は、EAP方法における汎用的なデータ転送手段を介して実現することができる。
【０１２２】
可能性のある代替方法においては（現在のI-WLANに適用されているように）ホームトンネリング及びローカルブレイクアウトの選択に関するオペレータのポリシが、全加入者に対して同一であり、代わりにVPLMN及び／又はW-APNにのみ依存する。そのような場合、方法は、ユーザ／UEが、ユーザIDではなくVPLMN IDのみをFQDNに含ませるように変更される。その結果、形式は＜VPLMN ID＞.＜通常のホームFQDN＞、又は＜VPLMN ID＞.＜デリミタ文字列＞.＜通常のホームFQDN＞となる。
【０１２３】
HPLMNは受信したFQDNからVPLMN IDを抽出し、VPLMN ID及び／又はW-APNに全面的に基づいてホームトンネリング又はローカルブレイクアウトの選択を行う。ローカルブレイクアウトが選択される場合、HPLMNは上述したように現在のI-WLANについての基本方法を開始する、すなわち、HPLMNは、W-APNネットワーク識別子と、オペレータ識別子としてのVPLMN IDとを用いてFQDNを構築し、それを解決するためにDNSリクエストをVPLMNへ送信する。
【０１２４】
I-WLANについて説明した方法は、WLANアクセスネットワークに限定されるものではなく、3GPP PLMNと連携する任意の非3GPPアクセスネットワークとともに用いることができる。これが可能なのは、本発明の方法の必須条件である、I-WLANで用いられるトンネリング方法（又は類似方法）は、任意の形式の非3GPPアクセスネットワークを介したアクセスに用いることが可能だからである。
【０１２５】
この基本方法及びその考えられる拡張は、現在の3GPP I-WLANアーキテクチャに関して説明してきた。しかし、方法は上述した、進化版ネットワークアーキテクチャ（図１ｂ及び図１ｃ参照）にも好適に適用可能である。
【０１２６】
さらに、方法は、図１ｂに示すアーキテクチャ（すなわち、AENを含んだアーキテクチャ）以後に計画されている進化した3GPPネットワークアーキテクチャのみならず、可能性のある中間段階におけるアーキテクチャにおけるI-WLANにも汎用化して適用することができる。
【０１２７】
図１ｂの、進化版ネットワークアーキテクチャにおいて、PDGh/TTGh及びPDGv/TTGvは、本方法ではAENh及びAENvで置き換えられるべきである。おそらく、UEが進化版ネットワークアーキテクチャ内でローミングしている際には、ホームトンネリングの場合にAENv-AENh部分を処理する他の移動性メカニズムを用いて、UE-AENトンネルは常にAENvで終わるべきであろう。
【０１２８】
可能性のある中間的な進化段階において、ローカルブレイクアウトトンネルはVPLMN内のWAG又はGSN+で終端するであろうが、それ以外、本方法の原理は同様である。
【０１２９】
方法を、図１ｂの進化版ネットワークアーキテクチャにおけるAENの選択に本方法を適用する際、念頭に置くべき、現在のI-WLANにおけるPDG/TTGの選択との２つの重要な差異が存在する。それらはいずれも、AENの予期される役割に由来するものである。
・AENはUEがIPアドレスを受信する前に選択されなければならない（AENはIPアドレスを割り当てるエンティティであると仮定されているため）。
・AENはアクセス認証前、すなわち、HPLMNがユーザ認証手順に関与する前に選択されねばならない（AENはアクセス認証を実行するもの、例えば（パススルーモードにおける）EAP認証器として振る舞うものと仮定されているため）。
【０１３０】
しかし、これらの差異にかかわらず、以下に説明するように方法の基本概念は再利用可能である。
【０１３１】
方法の基本概念、すなわちユーザID及び好ましくはVPLMN ID及び／又はサービス関連識別子を、DNSで解決されるFQDNに含めることは、図１ｂに示す長期的に進化するネットワークアーキテクチャにおけるAEN選択の状況においても再利用することができる。
【０１３２】
AENが選択される前にUEがIPアドレスを受信することは十中八九ない。従って、DNSリクエストはIPアドレスを必要とするため、UEは自身でDNSリクエストを発行することはまずできない。しかし、アクセスネットワークはUEに代ってそれを行うことができる。
【０１３３】
HPLMN又はVPLMNのいずれかは、AENをユーザ／UEへ割り当てるために、DNSリクエストを解決することができる。これは設計事項である。従って、DNSリクエストは（I-WLANにおけるローカルブレイクアウトに対するものとして上述した方法でのように）HPLMNへ、又はVPLMNのいずれかに送信されてよい。
【０１３４】
FQDNはUEから読み出されたデータを含むであろう。これはユーザID及び、場合によっては何らかのサービス関連識別子（APNに基づくものであってもなくてもよい）である。AENは恐らくネットワークアクセスの際にユーザ認証を実施するであろうし、AENは自身が選択される前に関与することはもちろんできないので、HPLMNはユーザがどのVPLMNにアクセスしているか知らないであろう。そのため、DNSリクエストがHPLMNに送信される場合、PQDN内にVPLMN IDも含めるべきであろう。FQDNの最後の部分は、DNS要求がHPLMNへ送信されるべきである場合にはHPLMNを示すドメイン名であるべきであり、DNS要求がVPLMNへ送信されるべきである場合にはVPLMNを示すドメイン名であるべきである。
【０１３５】
AENが割り当てられる前にUEがIPアドレスを取得できる、例えば、アクセスネットワークにより仮IPアドレスが割り当てられることも考えられる。。もしそうであれば、このIPアドレスを用いてUEはDNSリクエスト自身を発行することができる。
【０１３６】
図１ｃに示す、想定されている進化したネットワークアーキテクチャについての仮定は、図１ｂにおける進化したネットワークアーキテクチャについての仮定と幾分異なる。差異の１つは、AGW形式の非3GPP（及び場合によりI-WLAN）アクセスネットワークが、（パススルーモードにおいて）EAP認証器として振る舞ってアクセス認証を実行するものと仮定されていることである。そのため、AEN選択に関して上述した現在のI-WLANにおけるPDG/TTG選択との違いのうち、ただ１つのみがこの状況に当てはまる。すなわち、
【０１３７】
UEがIPアドレスを受信する前にs-IASAが選択されなければならないことである。
【０１３８】
UEがIPアドレスを受信する前にs-IASAが選択されねばならないため、アクセスネットワーク、すなわちAGWは、AEN選択の場合と同様、UEに代ってDNSリクエストを送信しなければならない。しかし、AEN選択の場合とは対照的に、AGWはDNSリクエストをアクセス認証前に送信しなくても良い。そのため、DNSリクエストが送信される際、HPLMNは既にユーザ認証に関与しており、そのため、（もしあれば）どのVPLMNが関連しているかを知っている。
【０１３９】
AEN選択の場合と同様、DNSリクエストはVPLMNとHPLMNのどちらにも送信することができる。DNSリクエストがHPLMNに送信される場合、VPLMN IDはFQDNに含められても含められなくても良い。HPLMNで、関連するVPLMNについて既に利用可能な情報（ユーザ認証中に読み出される）を利用するというオプションが、現在のI-WLANにおけるPDG/TTG選択に関してと同様に利用可能であるためである。
【０１４０】
VPLMNとHPLMNのいずれに送信されても、FQDNはサービス関連識別子、たとえば通信サービス識別子(CSI)又はAPNベースの識別子を含むことができる。
【０１４１】
いずれの場合も、FQDNの最後の部分は、DNS要求がHPLMNへ送信されるべきである場合にはHPLMNを示すドメイン名であるべきであり、DNS要求がVPLMNへ送信されるべきである場合にはVPLMNを示すドメイン名であるべきである。
【０１４２】
方法が同時ローカルブレイクアウト及びホームトンネリングの制御に用いられる場合、上述したのと同様、あるトラフィックフローについてローカルブレイクアウトとホームトンネリングのどちらかを選択する際の基準として、CSIをパケットフィルタの代わりに、あるいは追加して用いることができる。
【０１４３】
好ましくはないが可能な変形物は、AGWがDNSリクエストをアクセス認証前に送信することである。これは、DNSリクエストがHPLMNに送信される場合、s-IASA選択をAEN選択と非常に似た状況とし、またFQDNに含められるVPLMN IDを容易にするであろうからである。
【０１４４】
UEが潜在的に複数のIASAへそのアクセスのポイントから接続可能である場合、非ローミングの場合であっても、すなわち、VPLMNがいずれもまだ関与していない場合にも、s-IASA選択を適用可能である。これは、上述した、s-IASA選択手順の特別な場合とみることができる。この場合、VPLMN IDも、ローカルブレイクアウトも適用できない。FQDNは、HPLMNを示すドメイン名に加え、ユーザIDと、場合によりサービス関連識別子とを含むであろう。
【０１４５】
3GPP SAEアーキテクチャにおいて、AAAサーバがスタンドアロンエンティティであるか、HSS内に統合されるかは依然として未解決であることにも留意されたい。後者のアプローチは、図１ｃに示す進化したアーキテクチャについて現時点で実際に機能する仮定である。
【０１４６】
本発明はまた、図１ｃに示す進化したアーキテクチャにおけるホームエージェントの選択／割り当てにも適用可能である。この、予定されている進化したネットワークアーキテクチャの現在の見通しにおいて、少なくとも非３GPP（そして場合によりI-WLAN）アクセスが用いられている場合には、HAはDNSを用いてUEに直接割り当てられる。本発明のこの用途は、現在のI-WANにおけるPDG/TTG選択について述べた本発明の適用と非常に似ている。PDG/TTG選択の場合と同様、HAはHPLMNとVPLMNのいずれかに割り当てることができる（HPLMNが最も一般的に用いられるオプションであると仮定する）。
【０１４７】
現在のI-WLAN（及び一般的には現在のネットワークアーキテクチャ）との相違は、APNの概念をSAEアーキテクチャにおいては必ずしも用いなくて良い点である。これは無視できないが、それが用いられない確率の方が高い。しかし、本方法の状況において同様の処理を提供することのできる識別子は通信サービス識別子(CSI)である。
【０１４８】
APNの概念が再利用される場合、UEはその「通常のホームFQDN」を、上述したのと同じ方法で構築するであろう。さもなくば、通常のホームFQDNは単純にホームPLMNに属するドメイン名から構成されるであろう。例えば＜ホームオペレータ＞.comである。通常のホームFQDNは、ユーザID及びVPLMN IDを用いて、上述した方法に似た様々な方法で拡張可能である（例えばドメイン名や、移動体通信用国番号(MCC)及び移動体通信用網識別番号(MNC)の組み合わせの形で）。得られるFQDNは以下の通りである。
＜ユーザID＞.＜通常のホームFQDN＞又は、＜ユーザID＞.＜デリミタ文字列＞.＜通常のホームFQDN＞
＜ユーザID＞.＜VPLMN ID＞.＜通常のホームFQDN＞又は、＜ユーザID＞.＜デリミタ文字列＞.＜VPLMN ID＞.＜デリミタ文字列＞.＜通常のホームFQDN＞
【０１４９】
さらに、HPLMNに別の情報を提供するため、CSI又は他の何らかのサービス関連識別子（以下SRIと略称する）を、FQDNへ含めることができる。CSI又はサービス関連識別子は、FQDN内の例えば通常のホームFQDNの前に含めることができ、それにより以下の特別なFQDNが得られる。
＜ユーザID＞.＜CSI又はSRI＞.＜通常のホームFQDN＞又は、＜ユーザID＞.＜デリミタ文字列＞.＜CSI又はSRI＞.＜デリミタ文字列＞.＜通常のホームFQDN＞
＜ユーザID＞.＜VPLMN ID＞.＜CSI又はSRI＞.＜通常のホームFQDN＞又は、＜ユーザID＞.＜デリミタ文字列＞.＜VPLMN ID＞.＜デリミタ文字列＞.＜CSI又はSRI＞.＜デリミタ文字列＞.＜通常のホームFQDN＞
【０１５０】
サービス関連識別子（CSI又はSRI）が既に通常のホームFQDNの一部である場合には、通常のホームFQDNの前へこの識別子を追加して含めることは言うまでもなく冗長であるため、用いるべきでない。
【０１５１】
拡張されたFQDNからの関連データ抽出、（アクセスネットワーク、HPLMN及びVPLMN内の）DNSサーバ間の相互作用並びにDNSサーバとAAAサーバ／ポリシサーバ間の相互作用は、現行のI-WLANにおけるPDG/TTG選択への本発明の適用について上述したのと同様にして実行される（適用の際には、PDG/TTGについてのHAをW-APNについてのCSI又はSRIに置き換える）。
【０１５２】
I-WLANの状況について説明してきた、方法の可能性のある拡張の大半は、軽微な適応が必要な場合もあるが、図１ｃに示す、想定されている進化版ネットワークアーキテクチャにおいてにおいてもまた適用可能である。
【０１５３】
ローカルブレイクアウト及びホームトンネリングの同時拡張も適用可能である。ローカルブレイクアウトがMIPV6ルート最適化を通じて実現される場合、HPLMNはその機能を有効にするために何も行う必要はないが、パケットフィルタをUEへ送信すれば、ローカルブレイクアウト及びホームトンネリングのそれぞれに許されるトラフィックの種類について何らかの制御をHPLMNが行うことが可能になる。WLANアクセスについてのユーザ認証のためのEAP手順をアクセスネットワークにおけるユーザ認証のためのEAP手順に置き換え、IPsecトンネル確立中のEAP手順をUE-HA IPsecセキュリティアソシエーション(SA)確立に関連するEAP手順と置き換える（これはあまり実行されないが）ことにより、上述した、パケットフィルタをUEへ搬送するための手段と同じ手段を用いることが可能である。上述したパケットフィルタパラメータの例に加え、サービス関連パラメータ、例えばCSI又はAPNのようなパラメータを用いることができる。VPLMNがパケットフィルタルールを実行できるよう、同様のパケットフィルタをVPLMNへ搬送しても良い。そのためには、（例えば、アクセスネットワークにおけるユーザ認証手順の間に）AAAインフラストラクチャを用いるか、PLMN間ポリシ制御インタフェースを用いることができる。
【０１５４】
WLANアクセスについてのユーザ認証のためのEAP手順をアクセスネットワークにおけるユーザ認証のためのEAP手順に置き換え、IPsecトンネル確立中のEAP手順をUE-HA IPsecセキュリティアソシエーション(SA)確立に関連するEAP手順と置き換える（これはあまり実行されないが）ことにより、ホームトンネリング又はローカルブレイクアウトのいずれを好むかを示す選択表示をユーザがFQDNへ含めることを可能にするための上述した拡張を適用可能である。
【０１５５】
上述した、ユーザIDを含まないFQDNを用いる変形も適用可能である。しかし、説明したW-APNの利用は、W-APNをCSIのような他のサービス関連識別子によって置き換える（つまりFQDNに含められる）ことの可能性を含むように一般化される。
【０１５６】
HA割り当てのための上述した方法のための移動性プロトコルはモバイルIPv6を想定しているが、同一の方法をモバイルIPv4 HAの割り当てにも使用できる。
【０１５７】
本技術分野に属する当業者は、添付の請求項に規定される発明の範囲内で、本発明に様々な改変及び変更を行いうることを理解するであろう。
【図１ａ】
2010510713.tif 000003
【図１ｂ】
2010510713.tif 000004
【図１ｃ】
2010510713.tif 000005
【図２】
2010510713.tif 000006
【図３】
2010510713.tif 000007
【図４】
2010510713.tif 000008
【図５】
2010510713.tif 000009
【図６】
2010510713.tif 000010
【図７】
2010510713.tif 000011
【図８ａ】
2010510713.tif 000012
【図８ｂ】
2010510713.tif 000013
【手続補正書】
【提出日】平成21年10月28日(2009.10.28)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
公衆地上移動体ネットワークPLMNにおいてユーザ端末UEが接続するゲートウェイを選択するための装置であって、前記ユーザ端末は前記ユーザ端末の在圏PLMNに接続されるアクセスネットワーク内に位置し、前記PLMNは前記UEのユーザのホームPLMNであり、前記装置が、第１の完全修飾ドメイン名FQDNを受信する手段を有し、前記第１のFQDNが前記UEのユーザのIDを有し、前記ホームPLMNが前記在圏PLMNのIDを知っており、前記装置が、受信した前記ユーザのIDに少なくとも基づいて、前記UEが前記ホームPLMN内のゲートウェイのみへコネクションを確立すべきか、前記在圏PLMN内のゲートウェイのみへコネクションを確立すべきか、前記ホームPLMN内のゲートウェイと前記在圏PLMN内のゲートウェイの両方へのコネクションを確立すべきかを選択する手段と、前記在圏PLMN内のゲートウェイのみへコネクションを確立すべきであると選択された場合に前記在圏PLMN内のゲートウェイに属するアドレスを、前記ホームPLMN内のゲートウェイのみへコネクションを確立すべきであると選択された場合に前記ホームPLMN内のゲートウェイに属するアドレスを、前記在圏PLMN内のゲートウェイと前記ホームPLMN内のゲートウェイの両方へのコネクションを確立すべきであると選択された場合に前記在圏PLMN内のゲートウェイに属するアドレスと前記ホームPLMN内のゲートウェイに属するアドレスを、それぞれ受信する手段とを有することを特徴とする装置。
【請求項２】
前記選択する手段は、少なくとも前記ユーザIDに基づいて、前記選択の結果を決定する１つ以上の有効なポリシを特定する手段をさらに有することを特徴とする請求項１記載の装置。
【請求項３】
前記ホームPLMNが、認証手順の間に前記在圏PLMNのIDを知らされることを特徴とする請求項１又は請求項２に記載の装置。
【請求項４】
前記ホームPLMNが前記在圏PLMNのIDを知ることができるように、前記第１のFQDNが前記在圏PLMNのIDを有することを特徴とする請求項１又は請求項２に記載の装置。
【請求項５】
前記ゲートウェイがPDG/TTGであることを特徴とする請求項１乃至請求項４のいずれか１項に記載の装置。
【請求項６】
前記選択する手段が、前記在圏PLMN内のゲートウェイへのコネクションと、前記ホームPLMN内のゲートウェイへのコネクションと、前記在圏PLMN内のゲートウェイと前記ホームPLMN内のゲートウェイの両方へのコネクションのいずれを用いるべきかを選択するために、認証装置及び／又はポリシサーバに問い合わせることを特徴とする請求項１乃至請求項５のいずれか１項に記載の装置。
【請求項７】
前記在圏PLMN内のゲートウェイへのコネクションが選択された場合、前記解決する手段が、
前記在圏PLMNを示す第２のFQDNを構築する手段と、
前記第２のFQDNを前記在圏PLMNに送信する手段と、
前記在圏PLMN内のゲートウェイに属するアドレスを少なくとも前記送信された第２のFQDNに基づいて受信する手段と、
前記在圏PLMN内のゲートウェイに属するアドレスを前記UEへ送信する手段を有することを特徴とする請求項１乃至請求項６のいずれか１項に記載の装置。
【請求項８】
前記第２のFQDNが、前記第１のFQDNを、
前記第１のFQDNから前記ユーザIDを除去する手段と、
前記第１のFQDNが前記在圏PLMNのIDを有する際に前記在圏PLMNのIDを前記第１のFQDNから除去する手段と、
前記第１のFQDN内の前記ホームPLMNのIDを前記在圏PLMNのIDで置き換える手段とによって変更することによって構築されることを特徴とする請求項７記載の装置。
【請求項９】
前記ゲートウェイがホームエージェント、IASA又はAENであることを特徴とする請求項１乃至請求項８のいずれか１項に記載の装置。
【請求項１０】
前記在圏PLMN内のゲートウェイへのコネクションと前記ホームPLMN内のゲートウェイへのコネクションとについてのユーザ選択の表示が前記FQDNに含められることを特徴とする請求項１乃至請求項９のいずれか１項に記載の装置。
【請求項１１】
前記有効なポリシが、前記FQDNに含まれる前記W-APN又は他のサービス関連識別子によって特定されることを特徴とする請求項２乃至請求項１０のいずれか１項に記載の装置。
【請求項１２】
前記送信する手段が、DNSリクエストで前記ゲートウェイアドレスを送信する手段を有することを特徴とする請求項１乃至請求項１１のいずれか１項に記載の装置。
【請求項１３】
前記送信する手段が前記DNS応答内の生存時間(TTL)パラメータの設定をゼロにする手段を含むことを特徴とする請求項１２記載の装置。
【請求項１４】
接続するゲートウェイを決定するための、UEにおける装置であって、前記UEは前記UEの在圏PLMNに接続されるアクセスネットワーク内に位置するとともにホームPLMNに属し、前記ホームPLMNに属するドメイン名を有する第１のFQDNをDNSリクエストに含める手段を有する前記装置が、前記UEのユーザのIDを前記第１のFQDNに含める手段と、前記UEが前記在圏PLMN内のゲートウェイへ接続すべきであると前記ホームPLMNが選択した場合に前記在圏PLMN内のゲートウェイへのアドレスを、又は／及び前記UE前記ホームPLMN内のゲートウェイへ接続すべきであると前記ホームPLMNが選択した場合は前記ホームPLMN内のゲートウェイへのアドレスを、少なくとも前記UEのユーザのIDに基づいて受信する手段とを有することを特徴とする装置。
【請求項１５】
前記ホームPLMNが前記在圏PLMNのIDを知ることができるように、前記第１のFQDNに前記在圏PLMNのIDを含める手段を有することを特徴とする請求項１４記載の装置。
【請求項１６】
前記ゲートウェイがPDG/TTGであることを特徴とする請求項１４又は請求項１５に記載の装置。
【請求項１７】
パケットフィルタを用いて、前記在圏PLMN内のゲートウェイ又は前記ホームPLMN内のゲートウェイに選択的にデータパケットを送信する手段をさらに有することを特徴とする請求項１４乃至請求項１６のいずれか１項に記載の装置。
【請求項１８】
パケットをどのゲートウェイに送信すべきかの、前記パケットフィルタに基づく選択が、IPソースアドレス、IPデスティネーションアドレス、IPヘッダ内のプロトコル表示フィールド、トランスポートプロトコル、ソースポート番号、デスティネーションポート番号、サービスタイプ及びトラフィッククラス、のパケットパラメータの少なくとも１つに基づくことを特徴とする請求項１７記載の装置。
【請求項１９】
前記パケットフィルタが時間に依存することを特徴とする請求項１７又は請求項１８に記載の装置。
【請求項２０】
前記在圏PLMN内のゲートウェイへのコネクションと前記ホームPLMN内のゲートウェイへのコネクションとについてのユーザ選択の表示を、前記FQDNに含める手段をさらに有することを特徴とする請求項１４乃至請求項１９のいずれか１項に記載の装置。
【請求項２１】
W-APNを前記FQDNに含める手段をさらに有することを特徴とする請求項１４乃至請求項２０のいずれか１項に記載の装置。
【請求項２２】
前記ゲートウェイアドレスがDNS応答内で受信されることを特徴とする請求項１４乃至請求項２１のいずれか１項に記載の装置。
【請求項２３】
UEのユーザの在圏PLMNに接続されるアクセスネットワーク内に位置する前記UEが接続するゲートウェイを選択する、PLMN内の装置であって、前記PLMNは前記UEのユーザのホームPLMNであり、前記装置は第１のFQDNを受信する手段を有し、前記第１のFQDNが前記UEのユーザのIDを有し、前記ホームPLMNは前記在圏PLMNのIDを知っており、前記装置は、少なくとも受信した前記UEのユーザのIDに基づいて、前記UEが前記在圏PLMN内のゲートウェイのみへコネクションを確立すべきであることを選択する手段と、前記受信した第１のFQDNの代わりに用いられるとともに、在圏PLMN DNSサーバへ送信されるべき第３のFQDNを有するCNAMEリソースレコードを、ホームPLMN DNSサーバによって送信する手段とを有し、前記第３のFQDNは、前記在圏PLMN DNSサーバが前記第３のFQDNを解決してゲートウェイアドレスを前記UEへ送信できるよう、W-APNネットワーク識別子及び前記在圏PLMNのIDを用いて構築されることを特徴とする装置。
【請求項２４】
接続するゲートウェイを決定するための、UEにおける装置であって、前記UEは前記UEのユーザの在圏PLMNに接続されるアクセスネットワーク内に位置するとともに前記UEのユーザはホームPLMNに属し、前記ホームPLMNに属するドメイン名を有する第１のFQDNをDNSリクエストに含める手段を有する前記装置が、前記在圏PLMNのIDを前記第１のFQDNに含める手段と、前記UEが前記在圏PLMN内のゲートウェイへ接続すべきであると前記ホームPLMNが選択した場合に前記在圏PLMN内のゲートウェイへのアドレスを、又は／及び前記UE前記ホームPLMN内のゲートウェイへ接続すべきであると前記ホームPLMNが選択した場合は前記ホームPLMN内のゲートウェイへのアドレスを、少なくとも前記UEの前記在圏PLMNのIDに基づいて受信する手段とを有することを特徴とする装置。
【請求項２５】
UEのユーザの在圏PLMNに接続されるアクセスネットワーク内に位置する前記UEを接続するためのゲートウェイを選択する、前記UEのホームPLMNにおける方法であって、
前記UEのユーザのIDを有する第１のFQDNを受信するステップを有し、前記ホームPLMNは前記在圏PLMNのIDを知っており、
さらに、少なくとも前記受信したユーザのIDに基づいて、前記UEが前記ホームPLMN内のゲートウェイのみへのコネクションを確立すべきか、前記在圏PLMN内のゲートウェイのみへのコネクションを確立すべきか、又は前記ホームPLMN内のゲートウェイと前記在圏PLMN内のゲートウェイの両方へのコネクションを確立すべきかを選択するステップと、
前記在圏PLMN内のゲートウェイのみへのコネクションが選択された場合に前記在圏PLMN内のゲートウェイに属するアドレスを、前記ホームPLMN内のゲートウェイのみへのコネクションが選択された場合に前記ホームPLMN内のゲートウェイに属するアドレスを、前記ホームPLMN内のゲートウェイと前記在圏PLMN内のゲートウェイの両方へのコネクションが選択された場合に前記ホームPLMN内のゲートウェイに属するアドレスと前記在圏PLMN内のゲートウェイに属するアドレスの両方を、それぞれ送信するステップとを有することを特徴とする方法。
【請求項２６】
前記選択するステップは、少なくとも前記ユーザIDに基づいて、前記選択の結果を決定する１つ以上の有効なポリシを特定するステップをさらに有することを特徴とする請求項２５記載の方法。
【請求項２７】
前記ホームPLMNが、認証手順の間に前記在圏PLMNのIDを知らされることを特徴とする請求項２５又は請求項２６に記載の方法。
【請求項２８】
前記ホームPLMNが前記在圏PLMNのIDを知ることができるように、前記第１のFQDNが前記在圏PLMNのIDを有することを特徴とする請求項２５又は請求項２６に記載の方法。
【請求項２９】
前記選択するステップが、
前記在圏PLMN内のゲートウェイへのコネクションと、前記ホームPLMN内のゲートウェイへのコネクションと、前記在圏PLMN内のゲートウェイと前記ホームPLMN内のゲートウェイの両方へのコネクションのいずれを用いるべきかを選択するために、認証装置及び／又はポリシサーバに問い合わせるステップをさらに有することを特徴とする請求項２５乃至請求項２８のいずれか１項に記載の方法。
【請求項３０】
前記在圏PLMN内のゲートウェイへのコネクションが選択された場合、前記解決するステップが、
前記在圏PLMNを示す第２のFQDNを構築するステップと、
前記第２のFQDNを前記在圏PLMNへ送信するステップと、
少なくとも前記送信された第２のFQDNに基づいて、前記在圏PLMN内のゲートウェイに属するアドレスを受信するステップと、
前記在圏PLMN内のゲートウェイに属するアドレスを前記UEへ送信するステップとを有することを特徴とする請求項２５乃至請求項２９のいずれか１項に記載の方法。
【請求項３１】
前記第２のFQDNが、
前記第１のFQDNから前記ユーザIDを除去するステップ、
前記第１のFQDNが前記在圏PLMNのIDを有する場合に前記第１のFQDNから前記在圏PLMNのIDを除去するステップ、
前記第１のFQDN内の前記ホームPLMNの表示を前記在圏PLMNのIDで置き換えるステップ、によって前記第１のFQDNを変更することによって構築されることを特徴とする請求項３０記載の方法。
【請求項３２】
接続するゲートウェイを決定するための、UEにおける方法であって、前記UEは前記UEの在圏PLMNに接続されるアクセスネットワーク内に位置するとともにホームPLMNに属し、前記ホームPLMNに属するドメイン名を有する第１のFQDNをDNSリクエストに含めるステップを有する前記方法が、
前記UEのユーザのIDを前記第１のFQDNに含めるステップと、
前記UEが前記在圏PLMN内のゲートウェイへ接続すべきであると前記ホームPLMNが選択した場合に前記在圏PLMN内のゲートウェイへのアドレスを、又は／及び前記UE前記ホームPLMN内のゲートウェイへ接続すべきであると前記ホームPLMNが選択した場合は前記ホームPLMN内のゲートウェイへのアドレスを、少なくとも前記UEのユーザのIDに基づいて受信するステップをさらに有することを特徴とする方法。
【請求項３３】
前記ホームPLMNが前記在圏PLMNのIDを知ることができるように、前記第１のFQDNが前記在圏PLMNのIDを有することを特徴とする請求項３２記載の方法。
【請求項３４】
前記UEが前記在圏PLMN内のゲートウェイへのアドレス及び前記ホームPLMN内のゲートウェイへのアドレスを受信すると、パケットフィルタを用いて、前記在圏PLMN内のゲートウェイ又は前記ホームPLMN内のゲートウェイに選択的にデータパケットを送信するステップをさらに有することを特徴とする請求項３２又は請求項３３記載の方法。
【請求項３５】
パケットをどのゲートウェイに送信すべきかの、前記パケットフィルタに基づく選択が、IPソースアドレス、IPデスティネーションアドレス、IPヘッダ内のプロトコル表示フィールド、トランスポートプロトコル、ソースポート番号、デスティネーションポート番号、サービスタイプ及びトラフィッククラス、のパケットパラメータの少なくとも１つに基づくことを特徴とする請求項３４記載の方法。
【請求項３６】
前記在圏PLMN内のゲートウェイへのコネクションと前記ホームPLMN内のゲートウェイへのコネクションとについてのユーザ選択の表示が前記FQDNに含められることを特徴とする請求項３２乃至請求項３５のいずれか１項に記載の方法。
【手続補正書】
【提出日】平成21年10月29日(2009.10.29)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
公衆地上移動体ネットワークPLMNにおいてユーザ端末UEが接続するゲートウェイを選択するための装置であって、前記ユーザ端末は前記ユーザ端末の在圏PLMNに接続されるアクセスネットワーク内に位置し、前記PLMNは前記UEのユーザのホームPLMNであり、前記装置が、第１の完全修飾ドメイン名FQDNを受信する手段を有し、前記第１のFQDNが前記UEのユーザのIDを有し、前記ホームPLMNが前記在圏PLMNのIDを知っており、前記装置が、受信した前記ユーザのIDに少なくとも基づいて、前記UEが前記ホームPLMN内のゲートウェイのみへコネクションを確立すべきか、前記在圏PLMN内のゲートウェイのみへコネクションを確立すべきか、前記ホームPLMN内のゲートウェイと前記在圏PLMN内のゲートウェイの両方へのコネクションを確立すべきかを選択する手段と、前記在圏PLMN内のゲートウェイのみへコネクションを確立すべきであると選択された場合に前記在圏PLMN内のゲートウェイに属するアドレスを、前記ホームPLMN内のゲートウェイのみへコネクションを確立すべきであると選択された場合に前記ホームPLMN内のゲートウェイに属するアドレスを、前記在圏PLMN内のゲートウェイと前記ホームPLMN内のゲートウェイの両方へのコネクションを確立すべきであると選択された場合に前記在圏PLMN内のゲートウェイに属するアドレスと前記ホームPLMN内のゲートウェイに属するアドレスを、それぞれ受信する手段とを有することを特徴とする装置。
【請求項２】
前記選択する手段は、少なくとも前記ユーザIDに基づいて、前記選択の結果を決定する１つ以上の有効なポリシを特定する手段をさらに有することを特徴とする請求項１記載の装置。
【請求項３】
前記ホームPLMNが、認証手順の間に前記在圏PLMNのIDを知らされることを特徴とする請求項１又は請求項２に記載の装置。
【請求項４】
前記ホームPLMNが前記在圏PLMNのIDを知ることができるように、前記第１のFQDNが前記在圏PLMNのIDを有することを特徴とする請求項１又は請求項２に記載の装置。
【請求項５】
前記ゲートウェイがPDG/TTGであることを特徴とする請求項１乃至請求項４のいずれか１項に記載の装置。
【請求項６】
前記選択する手段が、前記在圏PLMN内のゲートウェイへのコネクションと、前記ホームPLMN内のゲートウェイへのコネクションと、前記在圏PLMN内のゲートウェイと前記ホームPLMN内のゲートウェイの両方へのコネクションのいずれを用いるべきかを選択するために、認証装置及び／又はポリシサーバに問い合わせることを特徴とする請求項１乃至請求項５のいずれか１項に記載の装置。
【請求項７】
前記在圏PLMN内のゲートウェイへのコネクションが選択された場合、前記解決する手段が、
前記在圏PLMNを示す第２のFQDNを構築する手段と、
前記第２のFQDNを前記在圏PLMNに送信する手段と、
前記在圏PLMN内のゲートウェイに属するアドレスを少なくとも前記送信された第２のFQDNに基づいて受信する手段と、
前記在圏PLMN内のゲートウェイに属するアドレスを前記UEへ送信する手段を有することを特徴とする請求項１乃至請求項６のいずれか１項に記載の装置。
【請求項８】
前記第２のFQDNが、前記第１のFQDNを、
前記第１のFQDNから前記ユーザIDを除去する手段と、
前記第１のFQDNが前記在圏PLMNのIDを有する際に前記在圏PLMNのIDを前記第１のFQDNから除去する手段と、
前記第１のFQDN内の前記ホームPLMNのIDを前記在圏PLMNのIDで置き換える手段とによって変更することによって構築されることを特徴とする請求項７記載の装置。
【請求項９】
前記ゲートウェイがホームエージェント、IASA又はAENであることを特徴とする請求項１乃至請求項８のいずれか１項に記載の装置。
【請求項１０】
前記在圏PLMN内のゲートウェイへのコネクションと前記ホームPLMN内のゲートウェイへのコネクションとについてのユーザ選択の表示が前記FQDNに含められることを特徴とする請求項１乃至請求項９のいずれか１項に記載の装置。
【請求項１１】
前記有効なポリシが、前記FQDNに含まれる前記W-APN又は他のサービス関連識別子によって特定されることを特徴とする請求項２乃至請求項１０のいずれか１項に記載の装置。
【請求項１２】
前記送信する手段が、DNSリクエストで前記ゲートウェイアドレスを送信する手段を有し、及び／又は、前記送信する手段が前記DNS応答内の生存時間(TTL)パラメータの設定をゼロにする手段を含むことを特徴とする請求項１乃至請求項１１のいずれか１項に記載の装置。
【請求項１３】
接続するゲートウェイを決定するための、UEにおける装置であって、前記UEは前記UEの在圏PLMNに接続されるアクセスネットワーク内に位置するとともにホームPLMNに属し、前記ホームPLMNに属するドメイン名を有する第１のFQDNをDNSリクエストに含める手段を有する前記装置が、前記UEのユーザのIDを前記第１のFQDNに含める手段と、前記UEが前記在圏PLMN内のゲートウェイへ接続すべきであると前記ホームPLMNが選択した場合に前記在圏PLMN内のゲートウェイへのアドレスを、又は／及び前記UE前記ホームPLMN内のゲートウェイへ接続すべきであると前記ホームPLMNが選択した場合は前記ホームPLMN内のゲートウェイへのアドレスを、少なくとも前記UEのユーザのIDに基づいて受信する手段とを有することを特徴とする装置。
【請求項１４】
前記ホームPLMNが前記在圏PLMNのIDを知ることができるように、前記第１のFQDNに前記在圏PLMNのIDを含める手段を有することを特徴とする請求項１３記載の装置。
【請求項１５】
前記ゲートウェイがPDG/TTGであることを特徴とする請求項１３又は請求項１４に記載の装置。
【請求項１６】
パケットフィルタを用いて、前記在圏PLMN内のゲートウェイ又は前記ホームPLMN内のゲートウェイに選択的にデータパケットを送信する手段をさらに有することを特徴とする請求項１３乃至請求項１５のいずれか１項に記載の装置。
【請求項１７】
パケットをどのゲートウェイに送信すべきかの、前記パケットフィルタに基づく選択が、IPソースアドレス、IPデスティネーションアドレス、IPヘッダ内のプロトコル表示フィールド、トランスポートプロトコル、ソースポート番号、デスティネーションポート番号、サービスタイプ及びトラフィッククラス、のパケットパラメータの少なくとも１つに基づくことを特徴とする請求項１６記載の装置。
【請求項１８】
前記パケットフィルタが時間に依存することを特徴とする請求項１６又は請求項１７に記載の装置。
【請求項１９】
前記在圏PLMN内のゲートウェイへのコネクションと前記ホームPLMN内のゲートウェイへのコネクションとについてのユーザ選択の表示を、前記FQDNに含める手段をさらに有することを特徴とする請求項１３乃至請求項１８のいずれか１項に記載の装置。
【請求項２０】
W-APNを前記FQDNに含める手段をさらに有することを特徴とする請求項１３乃至請求項１９のいずれか１項に記載の装置。
【請求項２１】
前記ゲートウェイアドレスがDNS応答内で受信されることを特徴とする請求項１３乃至請求項２０のいずれか１項に記載の装置。
【請求項２２】
UEのユーザの在圏PLMNに接続されるアクセスネットワーク内に位置する前記UEが接続するゲートウェイを選択する、PLMN内の装置であって、前記PLMNは前記UEのユーザのホームPLMNであり、前記装置は第１のFQDNを受信する手段を有し、前記第１のFQDNが前記UEのユーザのIDを有し、前記ホームPLMNは前記在圏PLMNのIDを知っており、前記装置は、少なくとも受信した前記UEのユーザのIDに基づいて、前記UEが前記在圏PLMN内のゲートウェイのみへコネクションを確立すべきであることを選択する手段と、前記受信した第１のFQDNの代わりに用いられるとともに、在圏PLMN DNSサーバへ送信されるべき第３のFQDNを有するCNAMEリソースレコードを、ホームPLMN DNSサーバによって送信する手段とを有し、前記第３のFQDNは、前記在圏PLMN DNSサーバが前記第３のFQDNを解決してゲートウェイアドレスを前記UEへ送信できるよう、W-APNネットワーク識別子及び前記在圏PLMNのIDを用いて構築されることを特徴とする装置。
【請求項２３】
接続するゲートウェイを決定するための、UEにおける装置であって、前記UEは前記UEのユーザの在圏PLMNに接続されるアクセスネットワーク内に位置するとともに前記UEのユーザはホームPLMNに属し、前記ホームPLMNに属するドメイン名を有する第１のFQDNをDNSリクエストに含める手段を有する前記装置が、前記在圏PLMNのIDを前記第１のFQDNに含める手段と、前記UEが前記在圏PLMN内のゲートウェイへ接続すべきであると前記ホームPLMNが選択した場合に前記在圏PLMN内のゲートウェイへのアドレスを、又は／及び前記UE前記ホームPLMN内のゲートウェイへ接続すべきであると前記ホームPLMNが選択した場合は前記ホームPLMN内のゲートウェイへのアドレスを、少なくとも前記UEの前記在圏PLMNのIDに基づいて受信する手段とを有することを特徴とする装置。
【請求項２４】
UEのユーザの在圏PLMNに接続されるアクセスネットワーク内に位置する前記UEを接続するためのゲートウェイを選択する、前記UEのホームPLMNにおける方法であって、
前記UEのユーザのIDを有する第１のFQDNを受信するステップを有し、前記ホームPLMNは前記在圏PLMNのIDを知っており、
さらに、少なくとも前記受信したユーザのIDに基づいて、前記UEが前記ホームPLMN内のゲートウェイのみへのコネクションを確立すべきか、前記在圏PLMN内のゲートウェイのみへのコネクションを確立すべきか、又は前記ホームPLMN内のゲートウェイと前記在圏PLMN内のゲートウェイの両方へのコネクションを確立すべきかを選択するステップと、
前記在圏PLMN内のゲートウェイのみへのコネクションが選択された場合に前記在圏PLMN内のゲートウェイに属するアドレスを、前記ホームPLMN内のゲートウェイのみへのコネクションが選択された場合に前記ホームPLMN内のゲートウェイに属するアドレスを、前記ホームPLMN内のゲートウェイと前記在圏PLMN内のゲートウェイの両方へのコネクションが選択された場合に前記ホームPLMN内のゲートウェイに属するアドレスと前記在圏PLMN内のゲートウェイに属するアドレスの両方を、それぞれ送信するステップとを有することを特徴とする方法。
【請求項２５】
前記選択するステップは、少なくとも前記ユーザIDに基づいて、前記選択の結果を決定する１つ以上の有効なポリシを特定するステップをさらに有することを特徴とする請求項２４記載の方法。
【請求項２６】
前記ホームPLMNが、認証手順の間に前記在圏PLMNのIDを知らされることを特徴とする請求項２４又は請求項２５に記載の方法。
【請求項２７】
前記ホームPLMNが前記在圏PLMNのIDを知ることができるように、前記第１のFQDNが前記在圏PLMNのIDを有することを特徴とする請求項２４又は請求項２５に記載の方法。
【請求項２８】
前記選択するステップが、
前記在圏PLMN内のゲートウェイへのコネクションと、前記ホームPLMN内のゲートウェイへのコネクションと、前記在圏PLMN内のゲートウェイと前記ホームPLMN内のゲートウェイの両方へのコネクションのいずれを用いるべきかを選択するために、認証装置及び／又はポリシサーバに問い合わせるステップをさらに有することを特徴とする請求項２４乃至請求項２７のいずれか１項に記載の方法。
【請求項２９】
前記在圏PLMN内のゲートウェイへのコネクションが選択された場合、前記解決するステップが、
前記在圏PLMNを示す第２のFQDNを構築するステップと、
前記第２のFQDNを前記在圏PLMNへ送信するステップと、
少なくとも前記送信された第２のFQDNに基づいて、前記在圏PLMN内のゲートウェイに属するアドレスを受信するステップと、
前記在圏PLMN内のゲートウェイに属するアドレスを前記UEへ送信するステップとを有することを特徴とする請求項２４乃至請求項２８のいずれか１項に記載の方法。
【請求項３０】
前記第２のFQDNが、
前記第１のFQDNから前記ユーザIDを除去するステップ、
前記第１のFQDNが前記在圏PLMNのIDを有する場合に前記第１のFQDNから前記在圏PLMNのIDを除去するステップ、
前記第１のFQDN内の前記ホームPLMNの表示を前記在圏PLMNのIDで置き換えるステップ、によって前記第１のFQDNを変更することによって構築されることを特徴とする請求項２９記載の方法。
【請求項３１】
接続するゲートウェイを決定するための、UEにおける方法であって、前記UEは前記UEの在圏PLMNに接続されるアクセスネットワーク内に位置するとともにホームPLMNに属し、前記ホームPLMNに属するドメイン名を有する第１のFQDNをDNSリクエストに含めるステップを有する前記方法が、
前記UEのユーザのIDを前記第１のFQDNに含めるステップと、
前記UEが前記在圏PLMN内のゲートウェイへ接続すべきであると前記ホームPLMNが選択した場合に前記在圏PLMN内のゲートウェイへのアドレスを、又は／及び前記UE前記ホームPLMN内のゲートウェイへ接続すべきであると前記ホームPLMNが選択した場合は前記ホームPLMN内のゲートウェイへのアドレスを、少なくとも前記UEのユーザのIDに基づいて受信するステップをさらに有することを特徴とする方法。
【請求項３２】
前記ホームPLMNが前記在圏PLMNのIDを知ることができるように、前記第１のFQDNが前記在圏PLMNのIDを有することを特徴とする請求項３１記載の方法。
【請求項３３】
前記UEが前記在圏PLMN内のゲートウェイへのアドレス及び前記ホームPLMN内のゲートウェイへのアドレスを受信すると、パケットフィルタを用いて、前記在圏PLMN内のゲートウェイ又は前記ホームPLMN内のゲートウェイに選択的にデータパケットを送信するステップをさらに有することを特徴とする請求項３１又は請求項３２記載の方法。
【請求項３４】
パケットをどのゲートウェイに送信すべきかの、前記パケットフィルタに基づく選択が、IPソースアドレス、IPデスティネーションアドレス、IPヘッダ内のプロトコル表示フィールド、トランスポートプロトコル、ソースポート番号、デスティネーションポート番号、サービスタイプ及びトラフィッククラス、のパケットパラメータの少なくとも１つに基づくことを特徴とする請求項３３記載の方法。
【請求項３５】
前記在圏PLMN内のゲートウェイへのコネクションと前記ホームPLMN内のゲートウェイへのコネクションとについてのユーザ選択の表示が前記FQDNに含められることを特徴とする請求項３１乃至請求項３４のいずれか１項に記載の方法。
【国際調査報告】
2010510713.tif 000014
2010510713.tif 000015