(57)【特許請求の範囲】
【請求項１】
ゲートウェイ（ＧＷ）（１０，１７，２０）に向けて複数のアクセス上で確立される接続を有するユーザ機器（ＵＥ）（１４）がＩＰフローモビリティのＵＥセントリックな制御を伴うシステムにおいてサービスセッションについて新たなサービスのセットアップを開始する際にアクセスフィードバックを提供するための方法であって、前記方法は、
−前記ＵＥ（１４）によって開始される前記新たなサービスの前記セットアップへの応答として、前記ＧＷ（１０，１７，２０）又はポリシー及び課金ルール機能（ＰＣＲＦ）（１３）が、サービス品質（ＱｏＳ）リソース予約を開始し、前記ＧＷ（１０，１７，２０）又は前記ＰＣＲＦ（１３）は、前記ＱｏＳリソース予約において、特定のアクセスが明示的に割り当てられていないＩＰフローについて、現行アクセスとしてデフォルトアクセスである第１のアクセスを選択するステップ（２２）と、
−前記ＵＥが、アクセスネットワークディスカバリ及び選択機能から受信されるアクセス選択ポリシーに基づいて現行アクセスとしての前記第１のアクセスを拒絶し、拒絶メッセージを前記ＧＷ（１０，１７，２０）に送信し、前記ＧＷ（１０，１７，２０）又は前記ＰＣＲＦ（１３）は、当該拒絶メッセージを受けて、現行アクセスとして第２のアクセスを選択して新たなＱｏＳサービスを開始するステップ（２３）と、
を含み、
前記ＵＥ（１４）が前記第２のアクセスを現行アクセスとして容認し、容認メッセージを前記ＧＷ（１０，１７，２０）に送信する場合、当該容認メッセージを受けて、前記ＧＷ（１０，１７，２０）又は前記ＰＣＲＦ（１３）は、選択され及び容認される前記アクセス上で、開始される前記ＱｏＳリソース予約を続行する、
ことを特徴とする、方法。
【請求項２】
前記容認を受けて、前記ＵＥ（１４）は、選択される前記現行アクセスを介して前記確立されるサービス又はＩＰセッションフローについてＩＰフローモビリティメッセージを前記ＧＷ（１０，１７，２０）に送信することによって、フローモビリティ手続きを開始する、請求項１に記載の方法。
【請求項３】
前記ＵＥ（１４）は、前記ＱｏＳリソース予約におけるアクセス選択メッセージにおいて、選択される前記第１のアクセスについて通知される、請求項１又は請求項２に記載の方法。
【請求項４】
前記アクセス選択メッセージは、前記ＧＷ（１０，１７，２０）又は前記ＰＣＲＦ（１３）が拒絶メッセージを受信するケイパビリティを示す許容情報を含む、請求項３に記載の方法。
【請求項５】
前記拒絶メッセージは、前記ＧＷ（１０，１７，２０）又は前記ＰＣＲＦ（１３）によって現行アクセスとして選択可能な少なくとも１つの第２のアクセスを示すアクセス情報を含む、請求項１〜４のいずれか１項に記載の方法。
【請求項６】
前記アクセス情報は、少なくとも１つの第２のアクセスのリストで構成され、当該リストは優先順位でソートされる、請求項５に記載の方法。
【請求項７】
前記拒絶メッセージは、現行アクセスとしての前記第１のアクセスの前記拒絶の理由についての情報を含む、請求項５又は請求項６に記載の方法。
【請求項８】
前記アクセス情報において示される第２のアクセスにおける前記ＱｏＳリソース予約が失敗する場合、前記アクセス情報において示される別の第２のアクセスにおいてＱｏＳリソース予約が実行される、請求項５〜７のいずれか１項に記載の方法。
【請求項９】
前記アクセス情報において示される全ての第２のアクセスにおける前記ＱｏＳリソース予約が失敗する場合、前記ＧＷ（１０，１７，２０）によって取得される前記デフォルトアクセスが現行アクセスとして前記ＵＥ（１４）によって容認される、請求項５〜８のいずれか１項に記載の方法。
【請求項１０】
複数のアクセス上で確立される接続を有するユーザ機器（ＵＥ）（１４）であって、当該ＵＥがＩＰフローモビリティのＵＥセントリックな制御を伴うシステムにおいてサービスセッションについて新たなサービスのセットアップを開始する際にＧＷ（１０，１７，２０）にアクセスフィードバックを提供するために適合され、
前記ＵＥ（１４）は、前記ＵＥによって開始されるサービスセッションへの応答として前記ＧＷ（１０，１７，２０）又はポリシー及び課金ルール機能（ＰＣＲＦ）（１３）によって開始されるサービス品質（ＱｏＳ）リソース予約において特定のアクセスが明示的に割り当てられていないＩＰフローについて選択される、現行アクセスとしてのデフォルトアクセスである第１のアクセスを、アクセスネットワークディスカバリ及び選択機能から受信されるアクセス選択ポリシーに基づいて拒絶し、拒絶メッセージをＧＷ（１０，１７，２０）に送信するように適合され、
前記ＵＥ（１４）は、前記ＧＷ（１０，１７，２０）又は前記ＰＣＲＦ（１３）により当該拒絶メッセージを受けて現行アクセスとして選択される第２のアクセスを、現行アクセスとして容認し、容認メッセージを前記ＧＷ（１０，１７，２０）に送信し、
前記第２のアクセス上で開始される前記ＱｏＳリソース予約は、前記容認メッセージを受けて前記ＧＷ（１０，１７，２０）又は前記ＰＣＲＦ（１３）により続行される、
ことを特徴とする、ユーザ機器（１４）。
【請求項１１】
請求項１０に記載の前記ＵＥ（１４）によって開始される新たなサービスの前記セットアップへの応答として、サービス品質（ＱｏＳ）リソース予約を開始するために適合されるゲートウェイ（ＧＷ）（１０，１７，２０）であって、当該ＧＷ（１０，１７，２０）は、前記ＱｏＳリソース予約において、現行アクセスとして前記第１のアクセスを選択するように適合され、
前記ＧＷ（１０，１７，２０）は、前記ＵＥ（１４）によって送信される前記拒絶メッセージを受けて新たなＱｏＳリソース予約を開始し、現行アクセスとして前記第２のアクセスを選択するようにさらに適合される、
ことを特徴とする、ゲートウェイ（１０，１７，２０）。
【請求項１２】
請求項１０に記載の前記ＵＥ（１４）によって開始される新たなサービスの前記セットアップへの応答として、サービス品質（ＱｏＳ）リソース予約を開始するために適合されるポリシー及び課金ルール機能（ＰＣＲＦ）（１３）であって、当該ＰＣＲＦ（１３）は、前記ＱｏＳリソース予約において、現行アクセスとして前記第１のアクセスを選択するように適合され、
前記ＰＣＲＦ（１３）は、前記ＵＥ（１４）によって送信される前記拒絶メッセージを受けて、新たなＱｏＳリソース予約を開始し、現行アクセスとして前記第２のアクセスを選択するようにさらに適合されること、
を特徴とする、ポリシー及び課金ルール機能（１３）。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アクセスフィードバックを提供するための方法に関する。本発明は、同じ目的のために適合されるゲートウェイ及びユーザ機器にも関する。
【背景技術】
【０００２】
端末（ＵＥ／ＭＳ）が複数の異なるアクセス技術を介してアクセスを得ることができるシナリオは、ますます普及しつつある。例えば、携帯電話は、セルラアクセスケイパビリティ（capabilities）及びＷＬＡＮ（Wireless  Local  Area  Network）アクセスケイパビリティの双方をしばしば備える。ラップトップコンピュータは、しばしば、イーサネットアクセスケイパビリティ、ＷＬＡＮアクセスケイパビリティ、及び、時としてセルラアクセスケイパビリティも有する。これらの異なるインタフェースは、一度に１つずつ用いられても、又は、同時に起動されてもよい。しかしながら、さらに重要なことには、現行の解決策において、所与のサービス又は所与のＩＰセッションは、通常一度に１つのアクセスを用いているに過ぎない。
【０００３】
現在、３ＧＰＰ  ＥＰＳ−Evolved  Packet  System（３ＧＰＰ  ＳＡＥ−System  Architecture  Evolutionとしても知られる）は、ＵＥ（User  Equipment）が異なるアクセス間で移動する場合、どのようにセッション継続性を達成することができるかについての解決策を定義している。これは、例えば、セルラアクセス上で実行されているサービスが代わりにＷＬＡＮアクセス上で実行されるように移行される（moved）ことを意味し得る。しかし、この解決策によっても、ＵＥは一度に１つのアクセスを用いているに過ぎず、アクセス変更の期間中、ＩＰセッション全体及び当該ＩＰセッション内で実行されている全てのサービスは、ソースアクセスからターゲットアクセスへ移行される。２つのアクセス間でのハンドオーバ期間中の非常に短い時間を除いて、（マルチホーミング（multi-homing）としても知られる）複数のアクセスの同時使用はサポートされていない。
【０００４】
マルチホーミングシナリオにおけるモビリティ解決策を定義するための作業はＩＥＴＦ（Internet  Engineering  Task  Force）において進行中であり、関連する作業が３ＧＰＰにおいて立ち上げられつつある。この作業の一部として、「フローモビリティ（flow  mobility）」のコンセプト、即ち、所与のＩＰセッションについてのＩＰフローのサブセットのみが１つのアクセスから別のアクセスへと移行されることが研究されている。例えば、マルチメディアコールのビデオコンポーネントのみがセルラアクセスからＷＬＡＮへ移行される一方、同じコールの音声コンポーネントに関連するＩＰフローはセルラアクセスに留まり得る。従って、１つのＩＰセッションが複数のアクセス上で同時にアクティブとなるであろう。
【０００５】
同時マルチアクセス（３ＧＰＰにおいて、ＭＡＰＩＭ−Multi  Access  PDN  connectivity  and  IP  flow  Mobilityと呼ばれる）に関する３ＧＰＰの作業において提案される１つの解決策は、フローモビリティを制御しているのはＵＥであるということである。これは、ＵＥが各アクセス（例えば、３ＧＰＰアクセス及びＷＬＡＮ）を起動し、どのＩＰフローが各アクセスにトランスポートされるかを決定することを意味する。ＵＥは、利用可能なアクセスの中からデフォルトアクセスも選択する。特定のアクセスが明示的に割り当てられていないＩＰフローは、デフォルトアクセスに引き継がれる（carried  over）。ネットワークは、ＵＥからの要求を容認し又は拒絶することを選択し得るが、ハンドオーバ手続きを開始し得ない。
【０００６】
ＩＰフローモビリティのこのＵＥセントリックの（UE-centric）制御は、解決策の基本原理であり、実際、リリース８において３ＧＰＰ  ＳＡＥについて定義されるアクセス間モビリティ（inter-access  mobility）の拡張である。リリース８において、２つの異なるアクセス間のハンドオーバをトリガするのは常にＵＥである。この１つの理由は、ＵＥは、ネットワークにおいて、例えば異なるアクセス技術の信号品質を認知している唯一のエンティティであるからである。また、ＵＥによってトリガされる（UE-triggered）ハンドオーバ手続きは、異種の（heterogeneous）アクセスネットワーク間のインタラクションの必要性を回避する。ネットワークによってトリガされる（Network-triggered）ハンドオーバ手続き、即ち、ネットワークがハンドオーバを開始する手続きは、ＧＥＲＡＮ（GSM  Edge  Radio  Access  Network）、ＵＴＲＡＮ（UMTS  Terrestial  Radio  Access  Network）及びＥ−ＵＴＲＡＮ（Evolved  UTRAN）といった「緊密にカプリングされる（tightly  coupled）」アクセス間でのみ定義される。
【０００７】
ＵＥは、あるＩＰフローを実行すべきであるアクセスを選択するために複数の基準を用い得る。まず、ＵＥは（ＵＥにおいて予め設定されるか、又は、ネットワークオペレータから無線で受信される）アクセス選択ポリシー（access  selection  policies）を有する。このポリシーは、あるサービスについて用いられるべきアクセスの優先順位リストを含み得る。次に、ＵＥは、様々な利用可能なアクセスの信号品質、特性、スループット等に関する情報も有する。
【０００８】
ＩＰフローモビリティのためのＵＥセントリックのモビリティパラダイムがネットワークによって開始される（network-initiated）ＱｏＳ手続き（procedures）と組み合わされる場合、１つの問題が生じる。（リリース８にあるように）単一のアクセスのみがアクティブである場合、問題点は無い。なぜなら、ネットワークによって開始される手続きを用いて新たなＱｏＳリソースを確立する場合、ネットワークには選択肢（choice）が無いからである。ただし、複数のアクセスが同時に利用可能である場合、ネットワークは、原則として、異なるアクセス技術間で選択肢を有する。しかしながら、ＵＥセントリックのモビリティパラダイムによれば、あるＩＰフローについてどのアクセスを用いるかを決定するのは常にＵＥである。ＵＥセントリックのモビリティパラダイムにおける現行の解決策は、ネットワークが、デフォルトアクセス上の新たなＩＰフローについてネットワークによって開始されるＱｏＳリソースをセットアップすることである。新たなＩＰフローを別のアクセスに移行するためのモビリティ手続きを後でトリガすることを望むかどうかは、ＵＥ次第である。
【０００９】
このアプローチには幾つかの欠点がある。まず、このアプローチは、ネットワークによって開始されるＱｏＳ（Quality  of  Service：サービス品質）手続きを用いるサービスについては非効率的なサービス確立手続きという結果になる。ネットワークは、常にまずデフォルトアクセスにおいてＱｏＳリソースを確立しなければならず、次いで、ＵＥは、（例えばアクセス選択ポリシーに基づいて）リソースをより適切なアクセスに後で移行することができる。サービスについてのＩＰフローの移行は、ＮＷが新たなアクセスにおいて対応するリソースを確立し、古いアクセスにおけるリソースを破棄する（tear  down）ことを要求する。
【００１０】
さらに、このアプローチは、非最適なサービス経験という結果にもなり得る。なぜなら、例えばより高いビットレート容量及び／又はより良好なＱｏＳケイパビリティを有する、より最適なアクセスに（ＵＥによって）移行されることができる前に、サービスは非最適なアクセスにおいて開始され得るからである。現行の技術水準は、図２に図示される。この図面は、本特許出願において詳細には説明されないであろう。このシグナリングフロー手続きに関するさらなる情報は、３ＧＰＰ技術仕様書ＴＳ  ２３．４０１、ＴＳ  ２３．４０２、ＴＳ  ２３．２０３及びＴＳ  ２３．２６１において見出すことができる。
【００１１】
この問題に対する１つの解決策は、デフォルトアクセスの代わりに「最良の（best）」アクセスにおいて、ネットワークがＱｏＳ手続きを直接的に開始することであり得る。ただし、これはＵＥセントリックのモビリティパラダイムを壊してしまう（breaks）。別の問題は、ＱｏＳ手続きを開始するネットワークノードが、アクセス選択ポリシーへのアクセスを有しないことである。なぜなら、そのようなポリシーは、アクセスネットワークディスカバリ及び選択機能（ＡＮＤＳＦ：Access  Network  Discovery  and  Selection  Function）に記憶されるからである。それ故に、ネットワークは、どのアクセスが「最良の」アクセスであるのかを知得していない。第３の欠点は、ネットワークベースのアクセス選択及びネットワークによってトリガされるアクセス間ハンドオーバが、異種のアクセスをより緊密にカプリングさせることである。異種のアクセスをカプリングすることは、簡単ではない（non-trivial）。なぜなら、各アクセスは通常、セキュリティ、モビリティ等といった重要な側面に対して異なる解決策を有するからである。
【発明の概要】
【発明が解決しようとする課題】
【００１２】
それ故に、本発明の課題は、マルチアクセス環境においてハンドオーバ期間中にＩＰフロー又はサービスのためのＱｏＳリソースが所望のアクセスにおいて確立されることを確保することである。
【課題を解決するための手段】
【００１３】
本発明の課題は、ゲートウェイ（ＧＷ）に向けて複数のアクセス上で確立される接続を有するユーザ機器（ＵＥ）がサービスセッションについて新たなサービスのセットアップを開始する際に、アクセスフィードバックを提供するための方法によって解決される。方法は、ＵＥによって開始される新たなサービスのセットアップへの応答として、ＧＷ又はポリシー及び課金ルール機能（ＰＣＲＦ）が、サービス品質（ＱｏＳ）リソース予約を開始するステップを含む。ＧＷ又はＰＣＲＦは、ＱｏＳリソース予約において、現行アクセスとして第１のアクセスを選択する。
【００１４】
方法は、特に、ＵＥが、現行アクセスとしての第１のアクセスを拒絶し、拒絶メッセージをＧＷに送信し、ＧＷ又はＰＣＲＦが、拒絶メッセージを受けて、現行アクセスとして第２のアクセスを選択して新たなＱｏＳサービスを開始するステップを特徴とする。
【００１５】
本発明の課題は、複数のアクセス上で確立される接続を有するユーザ機器（ＵＥ）によっても解決される。ＵＥは、サービスセッションについて新たなサービスのセットアップを開始する際にＧＷにアクセスフィードバックを提供するために適合される。ＵＥは、特に、現行アクセスとしての選択される第１のアクセスを拒絶し、拒絶メッセージをＧＷに送信するように適合される。第１のアクセスは、ＵＥによって開始されるサービスセッションへの応答として、ＧＷ又はポリシー及び課金ルール機能（ＰＣＲＦ）によって開始されるサービス品質（ＱｏＳ）リソース予約において選択される。
【００１６】
本発明の課題は、請求項１１に記載のＵＥによって開始される新たなサービスのセットアップへの応答として、サービス品質（ＱｏＳ）リソース予約を開始するために適合されるゲートウェイ（ＧＷ）によっても解決される。ＧＷは、ＱｏＳリソース予約において、現行アクセスとしてあるアクセスを選択するように適合される。ＧＷは、特に、ＵＥによって送信される前記拒絶メッセージを受けて新たなＱｏＳリソース予約を開始し、現行アクセスとして第２のアクセスを選択するようにさらに適合されることを特徴とする。
【００１７】
本発明の課題は、最後に、請求項１１に記載のＵＥによって開始される新たなサービスのセットアップへの応答として、サービス品質（ＱｏＳ）リソース予約を開始するために適合されるポリシー及び課金ルール機能（ＰＣＲＦ）（１３）によって解決される。ＰＣＲＦは、ＱｏＳリソース予約において、現行アクセスとしてあるアクセスを選択するように適合される。ＰＣＲＦは、特に、ＵＥによって送信される拒絶メッセージを受けて、新たなＱｏＳリソース予約を開始し、現行アクセスとして第２のアクセスを選択するようにさらに適合されることを特徴とする。
【００１８】
本発明の主な利点は、まずデフォルトアクセスにおいてリソースをセットアップし、次いでＵＥに所望のアクセスへのＩＰフローの移行をトリガさせるという中間的なステップを経ることなく、ＩＰフローについてのＱｏＳリソースが所望の（現行）アクセスにおいて速やかに確立されることをネットワークが確保することができることである。これは幾つかの利点を有する：
【００１９】
‐ＱｏＳ予約は、（まずデフォルトアクセスにおいて、次いで所望のアクセスにおいて）２回の代わりに、（所望のアクセスにおいて）１回だけ発生するため、アクセスネットワーク上の負荷を低減する。
【００２０】
‐サービスは、デフォルトアクセスにおいて立ち上がり、次いで所望のアクセスへ移行される代わりに、所望のアクセスにおいて迅速に始まるため、サービス経験が改善される。
【００２１】
‐サービスを所望のアクセスへ移行させるチャンスをＵＥが得る前に、サービスがデフォルトアクセスにおいて完全に拒絶される場合における、サービス損失の低減されるリスク。
【００２２】
‐ＮＷベースのアクセス選択又はＮＷによってトリガされるアクセス間モビリティ手続きを導入する必要が無い。
【００２３】
さらなる利点は、従属項の特徴のうちの１つ又は幾つかを実装することによって達成される。これは、以下でさらに説明されるであろう。
【図面の簡単な説明】
【００２４】
添付の図面において示される例を参照しつつ、本発明は以下においてより詳細に説明されるであろう。
【図１】マルチアクセスを有するネットワークを図示する。
【図２】マルチアクセス環境におけるハンドオーバについての既知のネットワークシグナリング図を図示する。
【図３】マルチアクセス環境におけるハンドオーバについてのネットワークシグナリング図の本発明に係る第１の例を図示する。
【図４】マルチアクセス環境におけるハンドオーバについてのネットワークシグナリング図の本発明に係る第２の例を図示する。
【図５】本発明に係る方法についてのフロースキームを図示する。
【発明を実施するための形態】
【００２５】
以下において説明される本発明の実施形態及びさらなる展開は、例としてのみ見なされるべきであって、決して特許請求の範囲によって提供される保護の範囲を限定するものではない。
【００２６】
本発明は、アクセスフィードバックを提供するための方法に関する。本発明は、同じ目的のために適合されるゲートウェイ及びユーザ機器にも関する。詳細な説明は、これらの機能によって実行される方法を説明するが、これらの方法ステップを実行するように適合されるこれらの機能も説明において開示されることを当業者は認識する。
【００２７】
図１は、本発明が好適に実装されるネットワークを示す。図１は、システムアーキテクチャエボリューション（ＳＡＥ：System  Architecture  Evolution）コアネットワークを示す。ネットワークのコンポーネントは、参照点及びインタフェース（Ｇｎ，Ｇｐ，Ｓ３，Ｓ４，Ｓ１０，Ｓ１１，Ｓ１ｕ，Ｓ５，Ｇｘａ，Ｇｘｂ，Ｇｘｃ，Ｇｘ，Ｒｘ，Ｓ２ａ，Ｓ２ｂ，Ｓ２ｃ，ＳＧｉ）を介して互いに通信する。これは、ここではこれ以上詳細に説明されないであろう。ＳＡＥコアネットワークの幾つかのコンポーネントは、モビリティマネジメントエンティティ（ＭＭＥ：Mobility  Management  Entity）１６、サービングゲートウェイ（Ｓ−ＧＷ：Serving  Gateway）１７、非３ＧＰＰアクセスＧＷ２０、発展型パケットデータゲートウェイ（ｅＰＤＧ：evolved  Packet  Data  Gateway）２１、及びパケットデータネットワークゲートウェイ（ＰＤＮ−ＧＷ：Packet  Data  Network  Gateway）１０である。
【００２８】
ＭＭＥ１６は、Ｅ−ＵＴＲＡＮ無線アクセスネットワーク（ＲＡＮ：Radio  Access  Network）１１を制御し、ユーザ機器（ＵＥ）１４についてＳ−ＧＷ１７を選択することに関与する。以下、全てのＲＡＮは「アクセス（access）」と名付けられるであろう。ＭＭＥは、Ｅ−ＵＴＲＡＮアクセスとＧＥＲＡＮ／ＵＴＲＡＮアクセス１９との間のモビリティについて制御プレーン機能も提供する。ＧＥＲＡＮ／ＵＴＲＡＮアクセス１９は、プレリリース８のＧＥＲＡＮ／ＵＴＲＡＮとリリース８のＧＥＲＡＮ／ＵＴＲＡＮとに分けられる。Ｓ−ＧＷは、特定のサービスについてＩＰフローをルーティングし及び転送する。Ｓ−ＧＷは、Ｅ−ＵＴＲＡＮとＧＥＲＡＮ／ＵＴＲＡＮとの間のモビリティについてモビリティアンカーとしての役割も果たす。サービングＧＰＲＳサポートノード（ＳＧＳＮ：Serving  GPRS  Support  Node）１５は、ＧＰＲＳコアネットワークにおいて、例えばＵＥ１４からのＩＰフローをルーティングし及びＵＥ１４へＩＰフローを転送するために用いられることができる。ＳＧＳＮ１５は、ＳＡＥにおいて、ＭＭＥ及びＳ−ＧＷに接続される。今日、ユーザプレーンデータにはＳＧＳＮをバイパスするオプションがある。このオプションが用いられる場合、ＳＧＳＮは制御プレーンエンティティに過ぎず、ユーザデータをルーティングし又は転送しない。ｅＰＤＧは、ＵＥとＰＤＮ−ＧＷとの間のパケットをルーティングし、ＵＥとｅＰＤＧとの間のプロテクションＩＰパケットについてＩＰＳｅｃ機能をサポートする。
【００２９】
ＰＤＮ−ＧＷ１０は、ＵＥについてのトラフィックの出口のポイント及び入口のポイントとなることによって、ＵＥ１４と外部のパケットデータネットワーク（ＰＤＮ：Packet  Data  Networks）１８との間に接続性を提供する。ＵＥは、複数のＰＤＮにアクセスするために１つより多くのＰＤＮ−ＧＷ１０との同時接続性を有し得る。ＰＤＮ−ＧＷの重要な役割は、３ＧＰＰ技術と、ＷｉＭＡＸ、ＷＬＡＮ及び３ＧＰＰ２といった非３ＧＰＰ技術との間のモビリティについてアンカーとしての役割を果たすことである。非３ＧＰＰ技術も、以下において、「アクセス」という用語によって包含される。
【００３０】
ポリシー及び課金ルール機能（ＰＣＲＦ：Policy  and  Charging  Rules  Function）１３は、Ｇｘ参照点を介してＰＣＣルールを提供することによって、ＰＤＮ−ＧＷ１０におけるＰＣＥＦを制御する。ＰＣＲＦにおけるＰＣＣルールの決定は、Ｇｘ参照点を介してＰＣＥＦによって取得される情報に基づき得る。ＰＣＲＦは、ＰＣＣルールを変更することによって、ＵＥについてのＰＤＰコンテキストベースのアクセスを制御することができる（図１を参照）。
【００３１】
用いられるアーキテクチャのオプションに応じて、ＰＣＲＦは、ＰＣＥＦの制御に加えて、Ｇｘａ参照点、Ｇｘｂ参照点又はＧｘｃ参照点を介してサービス品質（ＱｏＳ：Quality  of  Service）ルールを提供することによって、ベアラバインディング及びイベント報告機能（ＢＢＥＲＦ：Bearer  Binding  and  Event  Reporting  Function）も制御し得る。ＢＢＥＲＦは、サービングＧＷ１７及び／又は非３ＧＰＰアクセス１２におけるアクセスＧＷに配置されてもよい。サービングＧＷ１７（又は非３ＧＰＰアクセスにおけるアクセスＧＷ２０）とＰＤＮ−ＧＷとの間のモビリティプロトコルがＱｏＳシグナリングをサポートしない場合、ＰＣＥＦに加えてＢＢＥＲＦを有するアーキテクチャオプションが用いられる。より詳細については、３ＧＰＰ  ＴＳ  ２３．２０３を参照されたい。これは、以下においてより詳細に説明されるであろう。
【００３２】
本マルチホーミングシナリオの主な問題は、サービスが、例えばより高いビットレート容量及び／又はより良好なＱｏＳケイパビリティを有するより最適なアクセスに（ＵＥによって）移行されることができる前に、非最適なアクセスにおいて開始され得ることである。それ故に、まずデフォルトアクセスにおいてリソースをセットアップし、次いでＩＰフローの所望のアクセスへの移行をＵＥにトリガさせる中間的なステップを経ることなく、ＩＰフローについてのＱｏＳリソースが所望の（現行）アクセスにおいて速やかに（immediately）確立されることを確保することが重要である。
【００３３】
そのような改善された確立手続きを可能にするために、本発明は、ＵＥ１４が複数のアクセス上でゲートウェイ（ＧＷ）への接続を確立し、サービスセッションについて新たなサービスのセットアップを開始する際にアクセスフィードバックを提供するために実行されるあるステップを含む。サービスは、例えば、ＵＥ１０とＰＤＮ１８との間のテレフォニー（telephony）又はオーディオストリーミング／ビデオストリーミングである。
【００３４】
１．第１のステップ２２において（図５を参照）、ＧＷ１０、１７、２０又はＰＣＲＦ１３は、ＵＥ１４によって開始される新たなサービスのセットアップへの応答として、サービス品質（ＱｏＳ）リソース予約（resource  reservation）を開始する。ＧＷは、ＱｏＳリソース予約における現行アクセス（present  access）として第１のアクセス１１、１２、１９を選択する。
【００３５】
２．発明に関する（inventive）第２のステップ２３において（図５を参照）、ＵＥ１４は、現行アクセスとしての上記第１のアクセス１１、１２、１９を拒絶し、拒絶メッセージ（reject  message）をＧＷ１０、１７、２０に送信する。ＧＷ又はＰＣＲＦ１３は、拒絶メッセージを受けて、現行アクセスとして第２のアクセス１１、１２、１９を選択して新たなＱｏＳリソース予約を開始する。
【００３６】
ＧＷは、ＰＤＮ−ＧＷ１０、サービングＧＷ１７、又はアクセスＧＷ２０のうちの１つを指す。ＧＷのうちのどれが意味されるかは、用いられているアーキテクチャオプション、即ち、ＢＢＥＲＦが存在するか否かによって決まる。
【００３７】
拒絶メッセージがＧＷ１０、１７、２０に送信されるという事実は、ＧＷからＰＣＲＦ１３に送信される新たなメッセージに拒絶メッセージが含まれるシナリオも包含する。そのようなシナリオにおいて、ＧＷは結果として新たな形でメッセージをＰＣＲＦに転送する。これは、ＰＣＲＦが新たなリソース予約を開始する際に、拒絶メッセージはＰＣＲＦに到達することが可能であることを意味する。
【００３８】
ＧＷ１０、１７、２０又はＰＣＲＦ１３のいずれかが新たなリソース予約を開始するという事実は、ＢＢＥＲＦの存在に関する。用いられるアーキテクチャオプションに応じて、ＰＣＲＦは、ＰＣＥＦの制御に加えて、Ｇｘａ参照点、Ｇｘｂ参照点、又はＧｘｃ参照点を介してサービス品質（ＱｏＳ）ルールを提供することによってベアラバインディング及びイベント報告機能（ＢＢＥＲＦ）も制御し得る。ＢＢＥＲＦは、サービングＧＷ１７及び／又は非３ＧＰＰアクセス１２におけるアクセスＧＷに配置されてもよい。結果として、ＢＢＥＲＦが存在する場合、ＱｏＳリソース予約はＰＣＲＦによって開始される。ＢＢＥＲＦが存在しない場合、リソース予約はＧＷによって開始される。
【００３９】
これは、ネットワーク（ＰＣＲＦ１３）が（デフォルトの）アクセス上でＵＥ１４に向けてＱｏＳ手続きを開始する際に、ＵＥが、ＧＷ１０、１７、２０又はＰＣＲＦ１３からの要求の「部分的な拒絶（partial  reject）」をし、（拒絶をＰＣＲＦに転送し得る）ＧＷに当該拒絶を返すことができることが提案されることを意味する。「部分的な拒絶」である理由は、当該拒絶が要求の完全な拒絶ではなく、むしろ、このアクセスにおいてサービスが確立されるべきではないという指標だからである。
【００４０】
ＵＥ１４が拒絶メッセージを送信するという事実は、アクセス１１、１２、１９上の負荷が低減されるという結果をもたらす。なぜなら、ＱｏＳ予約は、（まずデフォルトアクセスにおいて、次いで所望のアクセスにおいて）２回の代わりに、（所望のアクセスにおいて）１回だけ発生するからである。サービスは、デフォルトアクセスにおいて立ち上がり、次いで所望のアクセスに移行される代わりに、所望のアクセスにおいて迅速に（rapidly）始まるため、サービス経験が改善される。
【００４１】
ＧＷ１０、１７、２０又はＰＣＲＦ１３が第１のアクセス又は第２のアクセスを選択するという事実は、ＵＥ１４からの情報に基づいてＧＷ又はＰＣＲＦがアクセスを選択し得ることを意味する。ＵＥは、選択されるべきアクセスの候補（possible  accesses）を提供し、ＧＷ又はＰＣＲＦは、これらの提供されるアクセスのうちの１つを、選択されるアクセスとして選ぶ。例えば、第１のアクセスが現行アクセスとして選択される場合、第１のアクセスはＵＥ１４によって既に選択されているため、これは実際には選択ではない。代替案は、ＵＥによって提供される情報無しに、ＧＷ又はＰＣＲＦが単独でアクセスを選ぶことである。
【００４２】
ＵＥ１４が、現行アクセスとして上記第２のアクセスを容認し（accepts）、容認メッセージ（accept  message）をＧＷ１０、１７、２０に送信する場合、当該容認メッセージを受けて、ＧＷ又はＰＣＲＦは、選択され及び容認されるアクセス上で、開始されるＱｏＳリソース予約を続行する。さらに、容認を受けて、ＵＥは、選択される現行アクセスを介して、確立されたサービス又はＩＰセッションについてＧＷにＩＰフローモビリティメッセージを送信することによって、フローモビリティ手続きを開始する。
【００４３】
容認メッセージ及びフローモビリティメッセージがＧＷ１０、１７、２０に送信されるという事実は、ＧＷからＰＣＲＦ１３に送信される新たなメッセージにこれらのメッセージが含まれるシナリオも包含する。
【００４４】
ＵＥ１４は、好適には、ＱｏＳリソース予約におけるアクセス選択メッセージにおいて、選択される第１のアクセスについて通知される。このアクセス選択メッセージは、ＧＷ１０、１７、２０又はＰＣＲＦ１３が拒絶メッセージを受信するケイパビリティの情報を含み得る。
【００４５】
上述の通り、ＵＥは、拒絶メッセージにおいて、選択されるべきアクセスの候補について通知し得る。拒絶メッセージは、ＧＷ１０、１７、２０又はＰＣＲＦ１３によって現行アクセスとして選択可能な少なくとも１つの第２のアクセスを示すアクセス情報を含む。これらの第２のアクセスは、ＧＷ又はＰＣＲＦによるアクセス選択について第１のアクセスの代わりに用いられる。アクセス情報は、ＵＥによってアクセス選択ポリシーとして返される。アクセス情報は、少なくとも１つの第２のアクセスのリストで構成され、当該リストは優先順位でソートされる。このアクセス情報は、ＵＥによって望まれるアクセスをＧＷ又はＰＣＲＦが選択することを確実にするために非常に適切な手法である。
【００４６】
図３は、マルチアクセス環境におけるハンドオーバについてのネットワークシグナリング図の第１の例を図示する。例において、ＵＥ１０は、専用のリソースを要求するあるサービスを実行するために用いられ得る少なくとも２つの異なるアクセスタイプを用いる同じＡＰＮ（Access  Point  Name：アクセスポイント名）へのアクセスを有すると仮定される。ＵＥは、例えばアクセスネットワークディスカバリ及び選択機能（ＡＮＤＳＦ：Access  Network  Discovery  and  Selection  Function）から受信される、アクセス選択ポリシーを有する。例において、ネットワークによって開始されるＱｏＳ手続きを用いる新たなサービスセッションが始められる。この特定のサービスは、このタイプのサービスについてアクセスＡ１１よりもアクセスＢ１２が高い優先度を有することを示すアクセス選択ポリシーを有する。オンパスの（on-path）ＰＣＣ（Policy  and  Charging  Control：ポリシー及び課金制御）を有するシナリオについて、以下にコールフローの例を示す：
【００４７】
これらのステップが実行される（図３を参照）：
【００４８】
１．Ｒｘ（コールフローにおいて図示せず）上で受信されるサービス情報に基づいて、ＰＣＲＦ１３は、新たなＰＣＣルールをＰＤＮ−ＧＷ１０に提供する。
【００４９】
２．ＰＤＮ−ＧＷ１０は、現行のアクセスとして第１のアクセス１１を選択する（デフォルトアクセスはＵＥ１４によって既に選択されているため、これは実際には選択ではない）。ＰＤＮ−ＧＷは、新たに確立されるサービスセッションについて（現行アクセスにおいて）ＱｏＳ手続きを開始する。
【００５０】
３．ＵＥ１４は、例えばアクセス選択ポリシーに基づいて、要求を拒絶し、現行アクセスとして代わりにどの第２のアクセスが用いられるべきかを示す応答をする。
【００５１】
４．ＰＤＮ−ＧＷ１０は、結果をＰＣＲＦ１３に報告する。
【００５２】
５．ＰＣＲＦ１３は、ＵＥ１４によって提供されるアクセス情報において示される通りの、最も高い優先度を有する第２のアクセス１２（アクセスＢ）を選ぶ。ＰＤＮ−ＧＷ１０は、新たに確立されるサービスセッションについて、このアクセスにおいてＱｏＳ手続きを開始する。
【００５３】
６．ＱｏＳ手続きは成功裏に完了される。
【００５４】
７．ＰＤＮ−ＧＷ１０は、ＰＣＲＦ１３に、ＰＣＣルールのインストールを確認応答する。
【００５５】
８．サービス開始を充分に（fully）完了するために、ＵＥは、（ＵＥセントリックのモビリティパラダイムに従って）ネットワークにルーティング／モビリティルールも提供しなければならない。このステップは、ステップ５〜６から独立しており、例えば５〜６と同時に行われてもよい。これは、ステップ１からトラフィックが現行アクセス１２（アクセスＢ）において流れ始めることができるまでの合計時間を低減する。
【００５６】
上記の例は、双方のアクセスにおいて「オンパスの」ＰＣＣを有するネットワークシナリオを示す。同様のコールフローは、「オフパスの（off-path）」ＰＣＣの場合にも適用されるであろう。重要な違いは、ＰＣＲＦ１３が各アクセス１１、１２においてアクセスＧＷに直接「ＱｏＳルール」を提供することによってＱｏＳ予約を実行することであろう。
【００５７】
図４は、マルチアクセス環境におけるハンドオーバについてのネットワークシグナリング図の第２の例を図示する。この例において、アクセス情報において示される第２のアクセスにおけるＱｏＳリソース予約は失敗する。ＱｏＳリソース予約は、アクセス情報において示される別の第２のアクセスにおいて実行され得る。アクセス情報において示される全ての第２のアクセスにおけるＱｏＳリソース予約が失敗する場合、ＰＤＮ−ＧＷ１０によって取得される（retrieved）デフォルトアクセスが現行アクセスとしてＵＥ１４によって容認される。
【００５８】
これらのステップが実行される（図４を参照）：
【００５９】
１．Ｒｘ（コールフローにおいて図示せず）上で受信されるサービス情報に基づいて、ＰＣＲＦ１３は、新たなＰＣＣルールをＰＤＮ−ＧＷ１０に提供する。
【００６０】
２．ＰＤＮ−ＧＷ１０は、現行アクセスとして第１のアクセス１１を選択する（デフォルトアクセスはＵＥ１４によって既に選択されているため、これは実際には選択ではない）。ＰＤＮ−ＧＷは、新たに確立されるサービスセッションについて（現行アクセスにおいて）ＱｏＳ手続きを開始する。
【００６１】
３．ＵＥ１４は、例えばアクセス選択ポリシーに基づいて、要求を拒絶し、現行アクセスとして代わりにどの第２のアクセスが用いられるべきかを示す応答をする。
【００６２】
４．ＰＤＮ−ＧＷ１０は、結果をＰＣＲＦ１３に報告する。
【００６３】
５．ＰＣＲＦ１３は、ＵＥ１４によって提供されるアクセス情報において示される通りの、最も高い優先度を有する第２のアクセス１２（アクセスＢ）を選ぶ。ＰＣＲＦ１３は、新たに確立されるサービスセッションについて、このアクセスにおいてＱｏＳ手続きを開始する。
【００６４】
６．無線リソースの不足に起因して、予約は失敗する。
【００６５】
７．ＰＣＲＦ１３は、必要に応じてＰＤＮ−ＧＷ１０に更新後のＰＣＣルールを提供する。ＰＤＮ−ＧＷは、ＰＣＲＦ１３に応答する。
【００６６】
８．ＵＥは、（ＵＥセントリックのモビリティパラダイムに従って）ルーティング／モビリティルールをネットワークに提供する。ＵＥは、予約が失敗したという事実を認知していない。
【００６７】
９．ＰＤＮ−ＧＷ１０は、ルーティングルールを拒絶する。
【００６８】
１０．ＰＤＮ−ＧＷ１０は、新たに確立されるサービスセッションについて、代わりに第１のアクセスにおいてＱｏＳ手続きを開始する。このステップは、アクセス情報において提供される全ての第２のアクセスをＰＤＮ−ＧＷ又はＰＣＲＦ１３が試行し及び失敗した場合、最後のステップとなり得る。
【００６９】
１１．ＵＥ１４は、例えばアクセス選択ポリシーに基づいて、ＱｏＳリソース要求を容認し、容認メッセージで応答する。
【００７０】
上記の例は、アクセスＡにおける「オンパスの」ＰＣＣ、及びアクセスＢにおける「オフパスの」ＰＣＣを有するネットワークシナリオを示す。同様のコールフローは、「オフパスの」ＰＣＣがアクセスＡにおいて用いられ、及び／又は、「オンパスの」ＰＣＣがアクセスＢにおいて用いられることになる場合にも適用されるであろう。アクセスＡにおける「オフパスの」ＰＣＣについての重要な違いは、ＰＣＲＦ１３が、アクセス１１においてアクセスＧＷに直接「ＱｏＳルール」を提供することによって、ＱｏＳ予約を実行することであろう。アクセスＢにおける「オンパスの」ＰＣＣについての重要な違いは、ＰＣＲＦ１３がＰＤＮ−ＧＷ１０に「ＰＣＣルール」を提供することによってＱｏＳ予約を実行し、ＰＤＮ−ＧＷがアクセス１２に向けてＱｏＳ予約手続きを開始することであろう。
【００７１】
要するに、本発明は、まずデフォルトアクセスにおいてリソースをセットアップし、次いでＵＥに所望のアクセスへのＩＰフローの移行をトリガさせるという中間的なステップを経ることなく、ＩＰフローについてのＱｏＳリソースが所望の（現行）アクセスにおいて速やかに確立されることをＰＤＮ−ＧＷ１０が確保することができるという利点を提供する。
【００７２】
本発明は、上述された例に限定されるものとして見なされるべきではない。多数の付加的な変形例及び変更例が後続の特許請求の範囲内において可能である。
【図２】
0005619271.tif 000002
【図３】
0005619271.tif 000003
【図４】
0005619271.tif 000004
【図５】
0005619271.tif 000005
【図１】
0005619271.tif 000006