(57)【要約】  本発明は、アクセス技術タイプに関連するサービス配信制御、および詳細には、許容するアクセス技術タイプに基づくサービス配信制御のための方法、アプリケーションノード（１０４、２６、３００）、ポリシーノード（１０８、２４、４００）、システムを提供する。ノード間インタフェースＲｘ（１０６）を介してポリシーノードと通信するサービスプロバイダに関連するアプリケーションノードによって定義される無線アクセス技術タイプ、および移動電話機（１０２、２２）が現時点で通信する無線アクセス技術タイプに基づいて、移動電話機が通信する無線アクセス技術タイプが許容する無線アクセス技術タイプの中に存在するか否かについての判定が行われる。存在しない場合、許容する無線アクセス技術タイプと現行無線アクセスレート間にマッチングが存在するように現アクセス技術タイプを更新することができる。【選択図】  なし
2010533418.tif 000002
【特許請求の範囲】
【請求項１】
ポータブル電子通信デバイスに提供可能なサービスの制御に対するサービス配信属性データを提供する方法であって、
前記ポータブル電子通信デバイス（１０２、２２）から起動関連サービスリクエストを受信するステップ（ステップ５０２）と、
リクエストされるサービスを前記ポータブル電子通信デバイス（１０２、２２）に提供することができる少なくとも１つの許容する無線アクセス技術タイプを判定するステップ（ステップ５１２）と、
前記リクエストされるサービスに関連付けられている属性関連メッセージであって、当該属性関連メッセージをポリシーノードが処理することができるような前記少なくとも１つの許容する無線アクセス技術タイプを含む属性関連メッセージを前記ポリシーノード（１０８、２４、４００）に送信するステップ（ステップ５１４）と
を備えることを特徴とする方法。
【請求項２】
前記ポータブル電子通信デバイスに関連付けられている少なくともアイデンティティ関連情報を受信するステップを更に備え、
前記判定するステップは、前記ポータブル電子通信デバイスに関連付けられている、受信する前記少なくともアイデンティティ関連情報に応じて実行される
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記リクエストされるサービスに関連するサービスプロビジョン情報を取得するステップ（ステップ５０８）を更に備え、
前記判定するステップは、取得されるサービスプロビジョン情報に応じて実行される
ことを特徴とする請求項１または２に記載の方法。
【請求項４】
前記起動関連サービスリクエストを受信するステップ（ステップ５０２）は、前記ポータブル電子通信デバイス（１０２、２２）が通信する通信ネットワークから起動関連サービスリクエストを受信することを含む
ことを特徴とする請求項１乃至３のいずれか１項に記載の方法。
【請求項５】
前記リクエストされるサービスに関連付けられている属性関連メッセージ応答を前記ポリシーノード（１０８、２４、４００）から受信するステップ（ステップ５１６、５１８）を更に備える
ことを特徴とする請求項１乃至４のいずれか１項に記載の方法。
【請求項６】
ポータブル電子通信デバイス（１０２、２２）に対するサービスの制御用のサービス配信属性データを提供するためのアプリケーションノード（１０４、２６、３００）であって、
前記ポータブル電子通信デバイスから、起動関連サービスリクエストを受信するように構成されている受信ユニット（３０２）と、
前記ポータブル電子通信デバイスに対して、リクエストされるサービスを提供することができる少なくとも１つの許容する無線アクセス技術タイプを判定するように構成されている判定ユニット（３０４）と、
前記リクエストされるサービスに関連付けられている属性関連メッセージをポリシーノード（１０８、２４、４００）に送信し、かつ前記リクエストされるサービスに関連付けられている属性関連メッセージ応答を前記ポリシーノードから受信するように構成されている通信ユニット（３０８）と
を備えることを特徴とするアプリケーションノード。
【請求項７】
前記受信ユニット（３０２）は、更に、前記ポータブル電子通信デバイス（１０２、２２）に関連付けられている少なくともアイデンティティ関連情報を受信するように構成されていて、
前記判定ユニット（３０４）は、前記ポータブル電子通信デバイスに関連付けられている、受信される少なくともアイデンティティ関連情報に応じて少なくとも１つの許容する無線アクセス技術タイプを判定するように構成されている
ことを特徴とする請求項６に記載のアプリケーションノード。
【請求項８】
サービスプロビジョン情報を取得するように構成されているアプリケーションインタフェースを更に備え、
前記判定ユニット（３０４）は、更に、取得されるサービスプロビジョン情報に応じて少なくとも１つの許容する無線アクセス技術タイプを判定するように構成されている
ことを特徴とする請求項６または７に記載のアプリケーションノード。
【請求項９】
前記通信ユニット（３０８）は、更に、前記属性関連メッセージを送信し、かつノード間インタフェース（１０６）を介して前記属性関連メッセージ応答を受信するように構成されている
ことを特徴とする請求項６乃至８のいずれか１項に記載のアプリケーションノード。
【請求項１０】
前記ノード間インタフェース（１０６）は、更に、参照点Ｒｘを備える
ことを特徴とする請求項６乃至９のいずれか１項に記載のアプリケーションノード。
【請求項１１】
通信ネットワークを介してポータブル電子通信デバイスからのサービスリクエストに対するサービス配信制御データを処理する方法であって、
リクエストされるサービスに関連付けられている属性関連メッセージであって、前記リクエストされるサービスを前記ポータブル電子通信デバイス（１０２、２２）に提供することができる少なくとも１つの許容する無線アクセス技術タイプを含む属性関連メッセージを、アプリケーションノード（１０４、２６、３００）から受信するステップ（ステップ２０８、６０２）と、
前記ポータブル電子通信デバイス（１０２、２２）が通信している無線アクセス技術タイプに関連付けられている情報を取得するステップ（ステップ２１０、６０４）と、
前記ポータブル電子通信デバイスが前記通信ネットワークを介して通信している前記無線アクセス技術タイプと、および前記サービスを前記アプリケーションノード（１０４、２６、３００）から提供することができる少なくとも１つの許容する無線アクセス技術タイプとに関連するサービス配信制御を実行するステップ（ステップ２１２、６０６、６０８）と、
前記サービスの配信が制御されるように、実行される前記サービス配信制御に応じて、前記ポータブル電子通信デバイスへのサービスのプロビジョンを開始するために、前記アプリケーションノード（１０４、２６、３００）に前記リクエストされるサービスに関連付けられている属性関連メッセージ応答を送信するステップ（ステップ２１４、２１８、６１０、６１４）と
を備えることを特徴とする方法。
【請求項１２】
前記サービス配信制御を実行するステップ（ステップ６０６、６０８）は、前記ポータブル電子通信デバイスが前記通信ネットワークを介して通信している前記無線アクセス技術タイプと、前記サービスを提供することができる前記少なくとも１つの許容する無線アクセス技術タイプとの比較を実行することを含む
ことを特徴とする請求項１１に記載の方法。
【請求項１３】
前記属性関連メッセージ応答を送信するステップは、更に、前記ポータブル電子通信デバイスが前記通信ネットワークを介して通信している前記無線アクセス技術タイプが、前記サービスを提供することができる前記少なくとも１つの許容する無線アクセス技術タイプ内に含まれることを確認する無線アクセス技術受理情報を送信すること（ステップ２１４、６１０）を含む
ことを特徴とする請求項１１または１２に記載の方法。
【請求項１４】
前記属性関連メッセージ応答を送信するステップは、更に、前記ポータブル電子通信デバイスが前記通信ネットワークを介して通信している前記無線アクセス技術タイプが、サービスを提供することができる前記少なくとも１つの許容する無線アクセス技術タイプ内に含まないことを確認する無線アクセス技術拒否情報を送信すること（ステップ２１８、６１４）を含む
ことを特徴とする請求項１１または１２に記載の方法。
【請求項１５】
前記サービス配信制御を実行するステップは、更に、前記ポータブル電子通信デバイス（１０２、２２）が前記通信ネットワークを介して通信することができる無線アクセス技術タイプとして、前記リクエストされるサービスを提供することができる許容する無線アクセス技術タイプを特定し、および特定される許容する無線アクセス技術タイプを介して前記リクエストされるサービスを前記ポータブル電子通信デバイスに提供することができるように、前記ポータブル電子通信デバイスが通信している前記無線アクセス技術タイプを前記特定される許容する無線アクセス技術タイプに更新するためのリクエストを前記ポータブル電子通信デバイスに送信すること（ステップ２２２、６２２）を含む
ことを特徴とする請求項１１または１２に記載の方法。
【請求項１６】
前記リクエストされるサービスに関連付けられている属性関連メッセージ応答を送信するステップは、前記特定される許容する無線アクセス技術タイプを前記アプリケーションノード（１０４、２６、３００）に送信することを含む
ことを特徴とする請求項１１乃至１５のいずれか１項に記載の方法。
【請求項１７】
通信ネットワークを介して通信するポータブル電子通信デバイス（１０２、２２）によってリクエストされるサービスのサービス配信制御データを処理するように構成されているポリシーノードであって、
ポータブル電子通信デバイスに前記サービスを提供することを許容する少なくとも１つの無線アクセス技術タイプを含む、リクエストされるサービスに関連付けられている属性関連メッセージを受信するように構成されている通信ユニット（４０２）と、
前記ポータブル電子通信デバイスが前記通信ネットワークを介して通信する前記無線アクセス技術タイプに少なくとも関連する情報を受信するように構成されている記憶ユニット（４０４）と、
前記ポータブル電子通信デバイスが前記通信ネットワークを介して通信する前記無線アクセス技術タイプおよび前記サービスを提供することができる少なくとも１つの許容する無線アクセス技術タイプに関連するサービス配信制御を実行するように構成されている処理ユニット（４０６）とを備え、
前記通信ユニット（４０２）は、更に、前記リクエストされるサービスに関連付けられている属性関連メッセージ応答を提供し、実行されるサービス配信制御に応じて、前記ポータブル電子通信デバイスに対する前記サービスのプロビジョンを開始するよう構成されている
ことを特徴とするポリシーノード。
【請求項１８】
前記処理ユニット（４０６）は、更に、前記ポータブル電子通信デバイス（１０２、２２）が前記通信ネットワークを介して通信する前記無線アクセス技術タイプと、前記サービスを提供することができる少なくとも１つの許容する無線アクセス技術タイプとの比較を実行するように構成されている
ことを特徴とする請求項１７に記載のポリシーノード。
【請求項１９】
前記処理ユニット（４０６）は、更に、前記ポータブル電子通信デバイス（１０２、２２）が前記通信ネットワークを介して通信する前記無線アクセス技術タイプを、前記リクエストされるサービスを提供することができる、許容する無線アクセス技術タイプとして特定するように構成される
ことを特徴とする請求項１７または１８に記載のポリシーノード。
【請求項２０】
前記処理ユニット（４０６）は、前記ポータブル電子通信デバイス（１０２、２２）が前記通信ネットワークを介して通信することができる無線アクセス技術タイプとして、前記リクエストされるサービスを提供することができる許容する無線アクセス技術タイプを特定し、および特定される許容する無線アクセス技術タイプを介して前記リクエストされるサービスを前記ポータブル電子通信デバイスに提供することができるように、前記ポータブル電子通信デバイスが通信している前記無線アクセス技術タイプを前記特定される許容する無線アクセス技術タイプに更新するためのリクエストを前記ポータブル電子通信デバイスに送信するように構成されている
ことを特徴とする請求項１７または１８に記載のポリシーノード。
【請求項２１】
前記通信ユニットは、更に、前記アプリケーションノード（１０４、２６、３００）からリクエストされるサービスに関連付けられている前記属性関連メッセージを受信し、かつ前記リクエストされるサービスに関連付けられている前記属性関連メッセージ応答を、ノード間インタフェース（１０６）を介して前記アプリケーションノードに送信するように構成されている
ことを特徴とする請求項１７乃至２０のいずれか１項に記載のポリシーノード。
【請求項２２】
前記ノード間インタフェースは、参照点Ｒｘを含む
ことを特徴とする請求項１７乃至２１のいずれか１項に記載のポリシーノード。
【請求項２３】
前記ポリシーノードは、更に、ポリシーおよび課金ルール機能を含む
ことを特徴とする請求項１７乃至２２のいずれか１項に記載のポリシーノード。
【請求項２４】
ポータブル電子通信デバイス（１０２、２２）に提供されるサービスのサービス配信制御を実行する方法であって、
通信ネットワークを介して通信する前記ポータブル電子通信デバイスから起動関連サービスリクエストを受信するステップ（ステップ５０２）と、
前記サービスを前記ポータブル電子通信デバイスに提供することができる少なくとも１つの許容する無線アクセス技術タイプを判定するステップ（ステップ５１２）と、
前記ポータブル電子通信デバイスが前記通信ネットワークを介して通信する無線アクセス技術タイプに関連付けられている情報を取得するステップ（ステップ６０４）と、
前記ポータブル電子通信デバイスが前記通信ネットワークを介して通信する前記無線アクセス技術タイプおよび前記サービスを提供することができる前記少なくとも１つの許容する無線アクセス技術タイプに関連するサービス配信制御を実行するステップ（ステップ６０６、６０８）と、
実行されるサービス配信制御に応じて、前記ポータブル電子通信デバイスに提供されるサービスのプロビジョンを開始するために、前記リクエストされるサービスに関連付けられている属性関連メッセージ応答を前記アプリケーションノードに送信するステップ（ステップ６１０、６１４）と
を備えることを特徴とする方法。
【請求項２５】
ポータブル電子通信デバイス（１０２、２２）によってリクエストされるサービスのサービス配信制御を実行するシステム（１００）であって、
通信ネットワークを介して通信する前記ポータブル電子通信デバイスから起動関連サービスリクエストを受信するように構成されている受信ユニット（３０２）と、
前記ポータブル電子通信デバイスによってリクエストされる前記サービスを提供し、かつ前記サービスを許容できるように提供する少なくとも１つの無線アクセス技術タイプを判定するように構成されているアプリケーションノード（１０４、２６、３００）と、
前記ポータブル電子通信デバイスが前記通信ネットワークを介して通信する前記無線アクセス技術タイプに少なくとも関連する情報を受信するよう構成されている通信ユニット（４０２）と、
前記ポータブル電子通信デバイスが前記通信ネットワークを介して通信する無線アクセスタイプおよび前記サービスが利用可能でありうる少なくとも１つの許容する無線アクセス技術タイプに関連するサービス配信制御を実行するよう構成されているポリシーノード（１０８、２４、４００）と、
前記アプリケーションノードと前記ポリシーノード間のインタフェース（１０６）とを備え、
前記ポリシーノードは、更に、実行されるサービス配信制御に応じて、前記ポータブル電子通信デバイスへの前記サービスのプロビジョンを開始するために、前記リクエストされるサービスに関連付けられている属性関連メッセージ応答を提供するように構成されていて、
前記インタフェースは、前記アプリケーションノードから前記ポリシーノードへ前記リクエストされるサービスに関連付けられている属性関連メッセージを通信し、かつ前記ポリシーノードから前記アプリケーションノードへ前記リクエストされるサービスに関連付けられている前記属性関連メッセージ応答を通信するように構成されている
ことを特徴とするシステム。
【請求項２６】
前記インタフェースは、参照点Ｒｘ（１０６）を含む
ことを特徴とする請求項２５に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、通信システムにおけるサービス配信制御に関するものであり、および、詳細には、無線アクセス技術タイプに基づいてサービス配信制御に関するものである。
【背景技術】
【０００２】
３ＧＰＰ  Ｒ７では、ポリシーおよび課金制御（ＰＣＣ：Policy and Charging Control）のための新しい解決策が導入されている。ＰＣＣアーキテクチャは、ポリシーおよび課金ルール機能（ＰＣＲＦ：Policy and Charging Rules Function）並びにＰＣＥＦ（Policy and Charging Enforcement Function：ポリシーおよび課金施行機能）を備えている。
【０００３】
ＰＣＣアーキテクチャは、ゲートウェイ汎用パケット無線サービス・サポート・ノード（ＧＧＳＮ：Gateway General Packet Radio Service Support Node）のようなゲートウェイ（ＧＷ：Gateway）−ノード、またはパケット・データ・ゲートウェイ（ＰＤＧ：Packet Data Gateway）のようなその他のインターネットプロトコル接続エリアネットワーク（ＩＰ−ＣＡＮ：Internet Protocol Connectivity Area Network）ゲートウェイにおける、サービスフローのサービス配信制御メカニズムを提供する。ＰＣＣによって提供されるおよび／または扱われる、ポリシー関連機能は、サービス品質（ＱｏＳ：Quality of Service）制御、ゲーティング（gating）、セッションイベントおよび課金制御である。
【０００４】
ＰＣＲＦは、様々なユーザおよび様々なサービスに様々なタイプのポリシーを適用することができる。このポリシーの決定は、例えば、加入情報、無線アクセス技術（ＲＡＴ：Radio Access Technology）タイプのような現状のアクセスにお基づくことができる。例えば、ネットワークユニバーサル移動通信システム地上無線アクセスネットワーク（ＵＴＲＡＮ：Universal mobile telecommunications system Terrestrial Radio Access Network）、グローバルエボリューション無線アクセスネットワーク用の移動通信高度データレート用グローバルシステム（ＧＥＲＡＮ：Global system for mobile communication Enhanced data rates for global evolution Radio Access Network）、無線ローカル・エリア・ネットワーク（ＷＬＡＮ：Wireless Local Area network）およびグローバル・エリア・ネットワーク（ＧＡＮ：Global Area Network）を使用する場合、ＲＡＴタイプパラメータは、特定ユーザがその時点でどの無線アクセス技術を使用しているか示すものである。
【０００５】
コンテンツプロバイダは、あるコンテンツをストリーミングする、または配信することができるアクセス技術に制限を設けることができる。あるサービスプロバイダは、ＷＣＤＭＡにおいて、例えば、サッカー世界選手権をストリーミングするまたは配信する権利を、例えば、購入することができるが、他のサービスプロバイダは、ＷＬＡＮにおいてそれをストリーミングするまたは配信する権利を購入することができる。
【０００６】
特定のサービスに対して許容されるアクセス技術タイプを特定して、ＰＣＲＦにおける静的ポリシーとして準備することができる。
【０００７】
しかしながら、これがもたらす欠点は、新規のサービスを始めるまたは展開するとすぐ、許容するアクセス技術タイプの新規のポリシーおよびルールをＰＣＲＦにおいてプロビジョンしなければならないようなことである。これは、典型的には、ＰＣＲＦに向けられる運用および保守インタフェースによって実行することができる。
【０００８】
このロジックを直接アプリケーションサーバに配置することは、サービスごとに特定の解決策を提供することを意味する。より汎用的な方法が要望されている。
【０００９】
更に、ＰＣＲＦのポリシーと、あるとすればＧＧＳＮのルールとの間の不一致が生じることがあり、これは、ＰＣＲＦのポリシーが、ＧＧＳＮのルールによって以前には許可されていたアクセスを阻止する可能性あることにつながりえよう。
【先行技術文献】
【非特許文献】
【００１０】
【非特許文献１】３ＧＰＰ（3rd generation partnership project）Ｒ７、ポリシーおよび課金制御のための新しい解決策
【発明の概要】
【発明が解決しようとする課題】
【００１１】
本発明の目的は改善されたサービス配信制御を提供する方法、アプリケーションノード、ポリシーノードおよびシステムを提供することである。
【課題を解決するための手段】
【００１２】
本発明の態様に従えば、ポータブル電子通信デバイスに提供可能なサービスの制御に対するサービス配信属性データを提供する方法が提供される。この方法は：
−ポータブル電子通信デバイスから起動関連サービスリクエストを受信するステップと、
−リクエストするサービスをアプリケーションノードからポータブル電子通信デバイスに提供することができる少なくとも１つの許容する無線アクセスタイプを判定するステップと、
−リクエストするサービスに関連付けられている属性関連メッセージであって、リクエストをポリシーノードが処理することができるような少なくとも１つの許容する無線アクセスタイプを含む属性関連メッセージをポリシーノードに送信するステップと
を備える。
【００１３】
サービス配信属性データを提供する前記方法は、ポータブル電子通信デバイスに関連付けられている少なくともアイデンティティ関連情報を受信するステップを更に含むことができ、ポータブル電子通信デバイスに関連付けられている、受信する少なくともアイデンティティ関連情報に応じて判定するステップを実行することができる。
【００１４】
サービス配信属性データを提供する前記方法は、リクエストされるサービスに関連するサービスプロビジョン情報を取得するステップを更に含むことができ、取得するサービスプロビジョン情報に応じて判定するステップを実行することができる。
【００１５】
サービス配信属性データを提供する前記方法は、ポータブル電子通信デバイスが通信する通信ネットワークから起動関連サービスリクエストを受信するステップを更に含むことができる。
【００１６】
サービス配信属性データを提供する前記方法は、リクエストするサービスに関連付けられている属性関連メッセージ応答をポリシーノードから受信するステップを更に含むことができる。
【００１７】
別の態様に従えば、ポータブル電子通信デバイスに対するサービスの制御用のサービス配信属性データを提供するアプリケーションノードが提供される。このアプリケーションノードは：
−ポータブル電子通信デバイスから起動関連サービスリクエストを受信するように構成されている受信ユニットと、
−ポータブル電子通信デバイスに対してリクエストするサービスを提供することができる少なくとも１つの許容する無線アクセス技術タイプを判定するように構成されている判定ユニットと、
−リクエストするサービスに関連付けられている属性関連メッセージをポリシーノードに送信し、リクエストするサービスに関連付けられている属性関連メッセージ応答をポリシーノードから受信するように構成されている通信ユニットと
を備える。
【００１８】
アプリケーションノードの受信ユニットは、更に、ポータブル電子通信デバイスに関連付けられている少なくともアイデンティティ関連情報を受信するように構成することができ、判定ユニットは、ポータブル電子通信デバイスに関連付けられている、受信される少なくともアイデンティティ関連情報に応じて少なくとも１つの許容する無線アクセス技術タイプを判定するように構成することができる。
【００１９】
アプリケーションノードは、サービスプロビジョン情報を取得するように構成されているアプリケーションインタフェースを更に含むことができ、判定ユニットは、更に、取得するサービスプロビジョン情報に応じて少なくとも１つの許容する無線アクセス技術タイプを判定するように構成することができる。
【００２０】
アプリケーションノードの通信ユニットは、更に、属性関連メッセージを送信し、かつノード間インタフェースを介して属性関連メッセージ応答を受信するように構成することができる。
【００２１】
アプリケーションノードに関連するノード間インタフェースは、更に、参照点Ｒｘを含むことができる。
【００２２】
尚、別の態様に従えば、通信ネットワークを介してポータブル電子通信デバイスからのサービスリクエストに対するサービス配信制御データを処理する方法が提供される。この方法は：
−リクエストするサービスに関連付けられている属性関連メッセージをアプリケーションノードから受信するステップであって、前記リクエストがリクエストするサービスをポータブル電子通信デバイスに提供することができる少なくとも１つの許容する無線アクセス技術タイプを含む、受信するステップと、
−ポータブル電子通信デバイスが通信している無線アクセス技術タイプに関連付けられている情報を取得するステップと、
−ポータブル電子通信デバイスが通信ネットワークを介して通信している無線アクセス技術タイプおよびサービスをアプリケーションノードから提供することができる少なくとも１つの許容する無線アクセス技術タイプに関連するサービス配信制御を実行するステップと、
−リクエストするサービスに関連付けられている属性関連メッセージ応答をアプリケーションノードに送信して、サービスの配信が制御されるように、実行するサービス配信制御に応じて、ポータブル電子通信デバイスへのサービスのプロビジョンを開始するステップと
を備える。
【００２３】
サービス配信制御データの前記処理方法は、ポータブル電子通信デバイスが通信ネットワークを介して通信している無線アクセス技術タイプと、サービスを提供することができる少なくとも１つの許容する無線アクセス技術タイプとの比較を実行するステップを更に含むことができる。
【００２４】
サービス配信制御データの前記処理方法に含まれる属性関連メッセージを送信する前記ステップは、ポータブル電子通信デバイスが通信ネットワークを介して通信している無線アクセス技術タイプが、サービスを提供することができる少なくとも１つの許容する無線アクセス技術タイプ内に含まれることを確認する無線アクセス技術受理情報を送信するステップを更に含むことができる。
【００２５】
サービス配信制御データの前記処理方法に含まれる属性関連メッセージを送信する前記ステップは、ポータブル電子通信デバイスが通信ネットワークを介して通信している無線アクセス技術タイプが、サービスを提供することができる少なくとも１つの許容する無線アクセス技術タイプ内に含まないことを確認する無線アクセス技術拒否情報を送信するステップを更に含むことができる。
【００２６】
サービス配信制御データの前記処理方法は、更に、ポータブル電子通信デバイスが通信ネットワークを介して通信することができる無線アクセス技術タイプであって、前記無線アクセスタイプがリクエストするサービスを提供することができる、許容する無線アクセス技術タイプである無線アクセス技術タイプを特定するステップと、および特定する許容する無線アクセス技術タイプを介してリクエストするサービスをポータブル電子通信デバイスに提供することができるように、前記ポータブル電子通信デバイスが通信している無線アクセス技術タイプを前記特定する無線アクセス技術タイプに更新するためのリクエストをポータブル電子通信デバイスに送信するステップを更に含むことができる。
【００２７】
サービス配信制御データの前記処理方法は、特定される許容する無線アクセス技術タイプをアプリケーションノードに送信するステップを更に含むことができる。
【００２８】
なおさらなる態様に従えば、通信ネットワークを介して通信するポータブル電子通信デバイスによってリクエストされるサービスのサービス配信制御データを処理するように構成されているポリシーノードが提供される。このポリシーノードは：
−ポータブル電子通信デバイスにサービスを提供することを許容する少なくとも１つの無線アクセス技術タイプを含む、リクエストするサービスに関連付けられている属性関連メッセージを受信するように構成されている通信ユニットと、
−ポータブル電子通信デバイスが通信ネットワークを介して通信する無線アクセス技術タイプに少なくとも関連する情報を受信するように構成されている記憶ユニットと、
−ポータブル電子通信デバイスが通信ネットワークを介して通信する無線アクセス技術タイプおよびサービスを提供することができる少なくとも１つの許容する無線アクセス技術タイプに関連するサービス配信制御を実行するように構成されている処理ユニットとを備え、
通信ユニットは、更に、リクエストするサービスに関連付けられている属性関連メッセージ応答を提供し、実行するサービス配信制御に応じて、ポータブル電子通信デバイスにサービスの提供を開始するよう構成されている。
【００２９】
ポリシーノードの処理ユニットは、更に、ポータブル電子通信デバイスが通信ネットワークを介して通信する無線アクセス技術タイプと、サービスを提供することができる少なくとも１つの許容する無線アクセス技術タイプとの比較を実行するように構成することができる。
【００３０】
ポリシーノードの処理ユニットは、更に、ポータブル電子通信デバイスが通信ネットワークを介して通信する無線アクセス技術タイプを、リクエストするサービスを提供することができる、許容する無線アクセス技術タイプとして特定するように構成することができる。
【００３１】
ポリシーノードの処理ユニットは、更に、ポータブル電子通信デバイスが通信ネットワークを介して通信することができる無線アクセス技術タイプであって、前記無線アクセス技術タイプがリクエストするサービスを提供することができる、許容する無線アクセス技術タイプである無線アクセス技術タイプを特定するようにし、および特定される許容する無線アクセス技術タイプを介してリクエストするサービスをポータブル電子通信デバイスに提供することができるように、前記携帯通信デバイスが通信する無線アクセス技術タイプを前記特定される許容する無線アクセス技術タイプに更新するためのリクエストをポータブル電子通信デバイスに送信するように構成することができる。
【００３２】
ポリシーノードの通信ユニットは、更に、アプリケーションノードからリクエストするサービスに関連付けられている属性関連メッセージを受信し、かつリクエストするサービスに関連付けられている属性関連メッセージ応答を、ノード間インタフェースを介してアプリケーションノードに送信するように構成することができる。
【００３３】
ポリシーノードに関連するノード間インタフェースは、更に、参照点Ｒｘを含むことができる。
【００３４】
ポリシーノードは、更に、ポリシーおよび課金ルール機能を含むことができる。
【００３５】
なお別の態様に従えば、ポータブル電子通信デバイスに提供されるサービスのサービス配信制御を実行する方法が提供される。この方法は：
−通信ネットワークを介して通信するポータブル電子通信デバイスから起動関連サービスリクエストを受信するステップと、
−サービスをポータブル電子通信デバイスに提供することができる少なくとも１つの許容する無線アクセス技術タイプを判定するステップと、
−ポータブル電子通信デバイスが通信ネットワークを介して通信する無線アクセス技術タイプに関連付けられている情報を取得するステップと、
−ポータブル電子通信デバイスが通信ネットワークを介して通信する無線アクセス技術タイプおよびサービスを提供することができる少なくとも１つの許容する無線アクセス技術タイプに関連するサービス配信制御を実行するステップと、
−実行するサービス配信制御に応じてポータブル電子通信デバイスに提供するサービスのプロビジョンを開始するために、リクエストするサービスに関連付けられている属性関連メッセージ応答をアプリケーションノードに送信するステップと
を備える。
【００３６】
なお異なる態様に従えば、ポータブル電子通信デバイスによってリクエストされるサービスのサービス配信制御を実行するシステムが提供される。このシステムは：
−通信ネットワークを介して通信するポータブル電子通信デバイスから起動関連サービスリクエストを受信するように構成されている受信ユニットと、
−ポータブル電子通信デバイスによってリクエストされるサービスを提供し、かつサービスを許容できるように提供する少なくとも１つの無線アクセス技術タイプを判定するように構成されているアプリケーションノードと、
−ポータブル電子通信デバイスが通信ネットワークを介して通信する無線アクセス技術タイプに少なくとも関連する情報を受信するよう構成されている通信ユニットと、
−ポータブル電子通信デバイスが通信ネットワークを介して通信する無線アクセスタイプおよびサービスが利用可能でありうる少なくとも１つの許容する無線アクセス技術タイプに関連するサービス配信制御を実行するよう構成されているポリシーノードと、
アプリケーションノードとポリシーノード間のインタフェースとを備え、
このポリシーノードは、更に、実行するサービス配信制御に応じて、ポータブル電子通信デバイスへのサービスのプロビジョンを開始するために、リクエストするサービスに関連付けられている属性関連メッセージ応答を提供するように構成されていて、
−このインタフェースは、アプリケーションノードからポリシーノードへリクエストするサービスに関連付けられている属性関連メッセージを通信し、かつポリシーノードからアプリケーションノードへリクエストするサービスに関連付けられている属性関連メッセージ応答を通信するように構成されている。
【００３７】
システムのノード間インタフェースは、参照点Ｒｘを更に含むことができる。
【００３８】
明細書において使用する場合、用語「含む／含んでいる」は、記載する特徴、整数、ステップまたは構成要素の存在を特定すると解釈するものとするが、１つまたは複数のその他の特報、整数、ステップまたは構成要素もしくは以上のグループの存在または追加を排除するものでないことが強調されるべきである。
【００３９】
本発明および本発明の利点並びに特徴をより詳細に説明するために、添付する図面を参照して以下に実施形態を記述することにする。
【図面の簡単な説明】
【００４０】
【図１】システムの実施形態を図示するブロック図である。
【図２】信号交換の実施形態を図示するブロック図である。
【図３】アプリケーションノードの実施形態を示すブロック図である。
【図４】ポリシーノードの実施形態を示すブロック図である。
【図５】方法のステップの実施形態を示すフローチャートである。
【図６】方法のステップの実施形態を示すフローチャートである。
【発明を実施するための形態】
【００４１】
システム１００の実施形態を示すブロック図を示す図１を参照することにより、本発明のいくつかの実施形態に含むいくつかの特徴を記述することにする。
【００４２】
実施形態において、図１のシステム１００は、アプリケーション機能（ＡＦ：application function）１０４を備えている。システム１００の実施形態で、ＡＦは、ストリーミングサーバによって実現することができる。ＡＦは、ポリシーおよび課金ルール機能（ＰＣＲＦ）１０８の形式のポリシーノード１０８に接続されている。認証および認可リクエスト（ＡＡ−リクエスト：Authentication Authorization requests）の形式の属性関連メッセージ、および認証および認可応答（ＡＡ−応答：Authentication Authorization responses）の形式の属性関連メッセージ応答を通信することができるインタフェースを介して、ＡＦ１０４はＰＣＲＦ１０８に接続することができる。いくつかの実施形態に従えば、このインタフェース１０６は、参照点Ｒｘを備えている。
【００４３】
その上、図１に図される実施形態で、ポータブル電子通信デバイス１０２の一例である移動電話機１０２のようなユーザ機器（ＵＥ：user equipment）は、ＡＦ１０４に接続される。ここで、ＵＥ１０２は、実際にはＧＧＳＮを介してＡＦに接続されているが、図１が概要ブロック図であるため、これを明確には示していないことに注意されたい。
【００４４】
更に、ゲートウェイ汎用パケット無線サービス・サポート・ノード（ＧＧＳＮ）１１４のポリシーおよび課金施行機能（ＰＣＥＦ）は、図１に示されるように、Ｇｘインタフェースを介してＰＣＲＦ１０８に接続されている。
【００４５】
代替実施形態に従えば、ＡＦは、アプリケーションノードの一部であるプロキシ−呼セッション制御機能（Ｐ−ＣＳＣＦ：Proxy-Call Session Control Function）によって実現される。アプリケーションノードは、サービス提供−ＣＳＣＦ（Ｓ−ＣＳＣＦ：Serving-CSCF）およびアプリケーションサーバ（ＡＳ：Application Server）を更に備える
ことができる。この実施形態で、ＳＤＰオファー（SDP offer：ＳＤＰ提案）を受信し、サービスプロバイダによって許容されるＲＡＴタイプに関する決定を行うことができるのはＡＳである。従って、ＡＳは、ＵＥ向けのＳＤＰアンサー（SDP Answer：ＳＤＰ回答）を送信する。
【００４６】
以下の本明細書では、本発明のいくつかの実施形態を、主として、第３世代パートナーシッププロジェクト（３ＧＰＰ）ＰＣＣアーキテクチャのコンテキストにおいて記述することにする。
【００４７】
本発明の実施形態の基本概念は、以下のように定義することができる；１）サービスプロバイダのサービスは、ＰＣＲＦにおける修正を行う必要なく、サービス展開におけるセッションセットアップの過程において、許容するアクセス技術タイプを指定することができるべきであり、２）ＡＦとＰＣＲＦ間のＲｘインタフェースを、ＡＦによって許容されるＲＡＴタイプを含むように拡張し、３）ＰＣＲＦ内のロジックを拡張し、Ｒｘにおいて受信する場合に許容するＲＡＴタイプの、ＩＰ  ＣＡＮ確立の過程でＧｘにおいて受信することができるようなＵＥがそのときに通信しているＲＡＴタイプとのマッチングを実行することができるようにし、４）ＰＣＲＦが行うことができる可能性のある決定は、サービスセッションセットアップリクエストに対する単純な受理応答または拒否応答を送信する、または許容するＲＡＴタイプのリストに基づく新規に許容するＲＡＴタイプをセットアップすることを目的とするメカニズムを起動するのいずれかである。
【００４８】
サービスロジック
上述のように、いくつかの実施形態に従えば、サービスロジック、即ち、ＡＦ１０４は、アプリケーションサーバ（ＡＳ）自体、例えば、ストリーミングサーバによって実現することができる。選択的には、アプリケーション機能（ＡＦ）は、アプリケーションノードの一部であるプロキシ−呼セッション制御機能（Ｐ−ＣＳＣＦ）によって実現することができ、ここで、アプリケーションノードは、サービス提供−呼セッション制御機能（Ｓ−ＣＳＣＦ）を更に含むことができる。
【００４９】
いくつかの実施形態に従えば、セッションセットアップシグナリング、例えば、ＵＥとＡＦ間のセッション開始プロトコル（ＳＩＰ：Session Initiation Protocol）が存在する。このシグナリングは、セッション記述プロトコル（ＳＤＰ：Session Description Protocol）を備えている場合がある。
【００５０】
サービスロジック、例えば、ＡＦを備えるＡＳは、特定のユーザおよびサービスに許容される無線アクセス技術タイプを指定する。このＲＡＴタイプ情報は、ポリシーおよび課金ルール機能（ＰＣＲＦ）に直接通信する。
【００５１】
アプリケーションノードがＰ−ＣＳＣＦの形式の、即ち、インターネット・プロトコル・マルチメディア・サブシステム（ＩＭＳ：Internet Protocol Multimedia Subsystem）の場合における、ＡＦを備える代替実施形態に従えば、許容する無線アクセス技術タイプをＰ−ＣＳＣＦを介してＰＣＲＦに通信することができる。
【００５２】
ＡＦからポリシー制御ノードの一例であるＰＣＲＦに送信される、許容するＲＡＴタイプの優先順位を、サービスが指定することができるべきである。ＡＦによってＰＣＲＦに送信される情報がＰＣＲＦ／加入プロファイルリポジトリ（ＳＰＲ：Subscription Profile Repository）に存在しうる静的にプロビジョンされるルールに勝るであろうかどうかを、このような優先順位情報によって判定することができる。
【００５３】
いくつかの代替実施形態に従えば、ＡＦから送信される情報より高い、またはその逆の優先順位が、ＰＣＲＦの静的ルールに与えられる。
【００５４】
この実施形態は、オペレータ専用であっても良く、また、あるオペレータに第１の実施形態を選択し、別のオペレータに第２の実施形態を選択させることを可能とし、ここで、第１の実施形態および第２の実施形態は、この点で互いに他と相違する。
【００５５】
アプリケーション機能−ポリシー制御インタフェース
いくつかの実施形態に従えば、Ｒｘインタフェースへの拡張を使用して、許容する無線アクセス技術（ＲＡＴ）タイプに関する情報をＰＣＲＦに通信することができる。
【００５６】
全ての許容するＲＡＴタイプを含み、次いで、拡張Ｒｘインタフェースを介して通信することができるであろう新規の属性値ペア（ＡＶＰ：Attribute Value Pair）の形式で、このようなＲｘインタフェースへの拡張を導入することができよう。
【００５７】
いくつかの実施形態に従えば、主要点は、アプリケーションノードの一例であるアプリケーション機能とポリシーノード間に位置するインタフェースを介して、ＲＡＴタイプ関連情報を通信することである。
【００５８】
尚、いくつかの代替実施形態に従えば、許容するＲＡＴタイプに関する情報を、全く新規のインタフェースにおいてアプリケーションノードとポリシー決定ノード間で通信することができる。新規のインタフェースの一例は、例えば、単純オブジェクト・アクセス・プロトコル（ＳＯＡＰ：Simple Object Access Protocol）に基づくことができる。このケースでは、サービス特定ポリシーに対してＲＡＴタイプを提供するために、新規のインタフェースが典型的には使用されることになる。ポリシー決定ノードは、また、許容するアクセス技術タイプについてアプリケーションノードに問い合わせ、存在する場合には、構成されているポリシーの静的動作を回避することができる。
【００５９】
ＰＣＲＦロジック
ＵＥがネットワークに接続する場合に発生する、インターネットプロトコル接続エリアネットワーク（ＩＰ  ＣＡＮ）の確立の間に、ＰＣＲＦは、特定ユーザに対する現行ＲＡＴタイプを受信することになる。現行ＲＡＴタイプ値は、ＰＣＲＦのデータベースに記憶される。
【００６０】
セッションセットアップ時に、即ち、ＰＣＲＦがセッションシグナリングの間にＲｘを介して情報を受信する場合に、ＰＣＲＦは、現行ＲＡＴタイプを、ＡＦから受信される許容するＲＡＴタイプリストと比較する。
【００６１】
静的にプロビジョンされているＲＡＴタイプルールは、また、ＰＣＲＦ／ＳＰＲにおいてプロビジョンされても良い。
【００６２】
いくつかの代替実施形態に従えば、現行ＲＡＴタイプは、ベアラ（ＩＰ  ＣＡＮ）確立時に起動されるＳＰＲにおいて静的にプロビジョンされるデフォルトのＲＡＴタイプ、およびセッション確立時に使用される、許容するＲＡＴタイプのリストの両方と比較することができる。
【００６３】
加入者ＩＤ、パケット／公衆データネットワーク（ＰＤＮ：Public Data Network）アイデンティティおよびおそらく更にＩＰ−ＣＡＮセッション属性に基づいて、ＰＣＲＦは、ＩＰ−ＣＡＮ伝送レベルポリシーに関連する加入関連情報をＳＰＲからリクエストすることができる。
【００６４】
これにより、現行ＲＡＴタイプを、許容するＲＡＴタイプの中のＲＡＴタイプではなく、これに代わるＰＣＲＦ／ＳＰＲにおいて静的にプロビジョンされるＲＡＴタイプに更新することができることが可能となる。
【００６５】
ＩＰ  ＣＡＮ確立時にＧＧＳＮから受信される現行ＲＡＴタイプが、セッションセットアップ時にＡＦから受信される許容するＲＡＴタイプのリストに含まれる、またはＩＰ  ＣＡＮ確立時にＧＧＳＮから受信される現行ＲＡＴタイプが、ＰＣＲＦ／ＳＰＲにおいて静的にプロビジョンされる場合、ＰＣＲＦは、セッションセットアップリクエストを受理することになる。様々な異なるＲＡＴタイプ代替タイプに対する優先順位の設定は、また、ここでも考慮することができる。
【００６６】
その他の場合、即ち、現行ＲＡＴタイプがリストに含まれない、または現行ＲＡＴタイプがＰＣＲＦ／ＳＰＲにおいて静的にプロビジョンされない場合、ＰＣＲＦは、セッションセットアップリクエストを拒否する、またはこれが可能である場合に許容するＲＡＴタイプの１つの確立を起動する、もしくはＰＣＲＦ／ＳＰＲにおいて静的にプロビジョンされるＲＡＴタイプの１つを代わりに起動する、のいずれかの決定を行うことになる。
【００６７】
許容するＲＡＴタイプの１つの確立を起動する決定を行うことは、もちろん、ＵＥが現在使用するものより他のアクセスネットワークの範囲にいることが必要になる。ＰＣＲＦが起動すべきＲＡＴタイプをＰＣＲＦ自体によって決定することができる、即ち、ＰＣＲＦにおいて、優先順位、例えば、１）ＵＴＲＡＮ、２）ＧＥＲＡＮ、３）（ＷＬＡＮ）および４）ＧＡＮでソートされているＲｘインタフェースにおいて送信される場合に許容するアクセスのリストにおいて、アクセス優先順位に関するポリシーをプロビジョンすることができる。
【００６８】
ＰＣＲＦは、端末にＲＡＴタイプの変更を開始させることができる。
【００６９】
上述の起動メカニズムに対する代替メカニズムは、ＡＦおよびＵＥにＲＡＴタイプの変更を扱わせることである。ＡＦに送信される拒否メッセージは、端末に伝搬することができる。この端末は、この場合、ＲＡＴタイプを変更することができる、または、エンドユーザにその時点で使用されているＲＡＴタイプを更新する必要性について通知することができる。
【００７０】
以下で、実施形態をよりよく説明するために、図の提示を更に続ける。
【００７１】
図２のブロック図は、ＵＥ２２、ＰＣＲＦ２４およびＡＦ２６間の信号フローの実施形態を示している。
【００７２】
図３は、アプリケーションノードの一例である、簡略化アプリケーション機能の実施形態を示すブロック図である。この実施形態に従えば、アプリケーション機能３００は、判定ユニット３０４に接続されるＳＤＰポート３０２を備え、この判定ユニット３０４は、更にアプリケーションインタフェース３０６に接続されている。判定ユニット３０４は、また、通信ユニット３０８に接続されている。全ての機能およびポート、即ち、ＳＤＰポート３０２、判定ユニット３０４、アプリケーションインタフェース３０６および通信ユニット３０８は、制御ユニット３１０にも接続することができ、いくつかの実施形態に従えば、この制御ユニット３１０は、その各ユニットによって実行されるステップを制御する。
【００７３】
その上、図３の実施形態で、上記の図は、ＳＤＰポート３０２に接続されているＵＥ３１２をまた備えている。加えて、ＡＦ３００の通信ユニット３０８は、ＰＣＲＦ３１４に接続されている。
【００７４】
同様に、図４は、ポリシーノードの一例であるＰＣＲＦの実施形態を示すブロック図である。この実施形態に従えば、ＰＣＲＦ４００は、比較ユニット４０６に接続されている通信ユニット４０２を備えている。更に、通信ユニット４０２および比較ユニット４０６に接続されているデータベース４０４が提供されている。いくつかの実施形態に従えば、制御ユニット４０８は、通信ユニット４０２、データベース４０４および比較ユニット４０６にまた接続することができ、これらのユニットによって実行されるステップを制御する。
【００７５】
以下で、方法のステップの実施形態を示すフローチャートである図５および図６を参照する。
【００７６】
ＡＦのステップおよび特徴−フットボール・ゲーム・シナリオ
以下で、ＡＦおよび、またＰＣＲＦの可能なステップおよび特徴を説明するために、フットボール・ゲーム・シナリオを以下で参照する。
【００７７】
移動電話機のようなＵＥのユーザがあるフットボールゲームにアクセスすることを望み、そして、フットボールゲームを経験するために、例えば、ボタンを押すことによって移動電話機を動作させる場合、メッセージが、ＵＥからＡＦに送信される。
【００７８】
いくつかの実施形態に従えば、このようなメッセージはＳＤＰオファーを含んでいて、これは、ＳＤＰオファーがＡＦ１０４、２６、３００によって受信され、また、ＳＤＰオファーがポータブル電子通信デバイスの一例であるＵＥ１０２、２２によって送信されることを意味する。ＳＤＰオファーを受信するこのステップは、図２のステップ２０２によって示され、このステップは、起動関連サービスリクエストを受信する一例である。図３では、ＵＥ３１２がメッセージＳ−３０２をＡＦ３００のＳＤＰポート３０２に送信することが示されている。いくつかの実施形態に従えば、メッセージＳ−３０２は、従って、ＳＤＰオファーである。加えて、図５は、ＵＥからＡＦにサービスリクエストを通信する別の例である、ＵＥからのＳＤＰオファーを受信するステップ５０２も含んでいる。
【００７９】
このＳＤＰオファーメッセージは、従って、ＡＦ１０４、２６、３００のＳＤＰポート３０２によって受信することができ、ここで、ＳＤＰポートは、図３に概略的に示されている。
【００８０】
典型的には、ＳＤＰオファーは、ユーザ機器のアイデンティティに関連付けられている情報、およびこの場合では所望のフットボールゲームのパケットフローに対応するインターネット・プロトコル・マルチメディア・サブシステム通信サービスアイデンティティ（ＩＣＳＩ：Internet protocol multimedia subsystem Communication Service Identifier）の形式で、リクエストされているサービスに関する情報を備えている。
【００８１】
ここで、ＳＤＰオファーに含まれる情報は、ＵＥから直接受信されるのではなく、現行無線ネットワークからの入力を介してＧＧＳＮから受信される可能性があることに注意されたい。
【００８２】
ステップ２０２、ステップ５０２で、ＡＦが信号Ｓ−３０２によってＳＤＰオファーを受信することに加えて、これらの実施形態に従う方法は、ステップ５０４で、ＳＤＰオファーからＵＥのアイデンティティを取得することも含んでいる。このポータブル通信デバイスに関連付けられている、アイデンティティ関連情報を少なくとも受信するステップの例である、このステップ、ステップ５０４は、いくつかの実施形態に従って、ＡＦによってＵＥからＳＤＰオファーを受信するステップ２０２、ステップ５０２に含むことができる。
【００８３】
別の代替実施形態に従えば、アイデンティティ関連情報を、ＩＭＳユーザアイデンティティの形式で、ＡＦによって受信することができる。
【００８４】
ＳＤＰアンサーメッセージは、その後、ＡＦからＵＥに送信され、ここで、これは、これらの実施形態に従うステップ２０４、ステップ５０６に対応する。ＡＦによる、このようなＳＤＰアンサーの送信は、明示的に示されていないが、ＡＦの制御ユニット３１０の制御の下に、ＳＤＰポート３０２によって実行することができる。このステップで、ＡＦは、従って、ＵＥアイデンティがサービスをリクエストしていることを確認応答する。
【００８５】
いくつかの実施形態に従う方法では、リクエストされているサービスに関連するサービスプロビジョン情報を取得するこのステップは、ＳＤＰオファーＳ−３０２からサービス情報を取得するステップであるステップ５０８に対応する。このステップは、典型的には、制御ユニット３１０の制御の下に、ＳＤＰポート３０２によって実行される。このステップで、ＡＦは、フットボールゲームである、リクエストされているサービスに関する情報を取得することができる。
【００８６】
ステップ５０８でサービス情報を取得すると、ステップ５１０で、サービス用のＲＡＴタイプデータを取得するステップが続く。上述のように、サービス情報は、ＳＤＰオファーＳ−３０２から、ＳＤＰポート３０２によって受信することができる。しかしながら、いくつかの実施形態に従えば、ステップ５１０におけるサービス用のＲＡＴタイプデータは、ＡＦ３００のアプリケーションインタフェース３０６から取得することができる。
【００８７】
ステップ５１０で受信される情報は、また、ＲＡＴタイプの個別優先順位を含むことができ、これらの優先順位は、サービスプロバイダによってストリーミングサーバの形式で典型的に定義することができる。
【００８８】
従って、ＳＤＰポート３０２は、ＵＥのアイデンティティ、およびＵＥによってリクエストされるサービスに関するサービス情報を受信している。また、アプリケーションインタフェース３０６は、リクエストされているサービスをＡＦから提供することができるＲＡＴタイプを含むサービス用のＲＡＴタイプデータを取得している。
【００８９】
従って、ＵＥのアイデンティに関する情報、およびリクエストされているサービスに関するサービス情報は、メッセージＳ−３０４によって判定ユニット３０４に通信される。また、リクエストされているサービスを提供することができるＲＡＴタイプを備える、取得されているＲＡＴタイプデータは、メッセージＳ−３０６によって判定ユニット３０４に通信することができる。
【００９０】
次に、ＡＦ３００の判定ユニット３０４は、ステップ５１２で、ＵＥのアイデンティティおよび取得されているサービスＲＡＴタイプデータに基づいて、サービスに対して許容されるＲＡＴタイプを判定するステップを実行することができる。このステップは、アプリケーションノードからリクエストされるサービスをポータブル電子通信デバイスに提供することができる少なくとも１つの許容する無線アクセス技術タイプを判定するステップの一例である。
【００９１】
図２で、ＡＦによって許容されるＲＡＴタイプを判定するステップ２０６によって、図５のステップ５１２が示される。
【００９２】
シナリオＩとして図１で示される実施形態のシナリオに従えば、判定ユニットは、ＵＥアイデンティティ（ＩＤ）「Ａ」を有し、かつ特定のユーザに属するＵＥに、ＲＡＴタイプＹおよびＸにおいて、フットボールゲームを提供することができると判定する。
【００９３】
いくつかの実施形態に従えば、判定ユニット３０４は、制御ユニット３１０の制御の下に、この判定を実行することができる。
【００９４】
ここで、ＡＦは、フットボールゲームを特定のユーザに配信することができるＲＡＴタイプを判定している。いわゆるサービス固有で、かつユーザ専用に許容するＲＡＴタイプが判定される。
【００９５】
これらのＲＡＴタイプ、この例では、ＵＴＲＡＮおよびＷＬＡＮは、フットボールゲームがサービスプロバイダによって提供することができるＲＡＴタイプであることであることに留意すべきである。ＵＥがフットボールゲームを受信することができるＲＡＴタイプ（群）は判定されていない。これは、判定対象が残っている。
【００９６】
図３でメッセージＳ−３１０によって示されるように、いくつかの実施形態に従う本方法の次のステップは、属性関連メッセージを認証認可リクエスト（ＡＡＲ）の形式でＰＣＲＦに送信するステップ２０８、ステップ５１４である。このステップは、リクエストされるサービスに関連付けられている属性関連メッセージをポリシーノードに送信するステップの一例であり、このリクエストは、リクエストがポリシーノードによって処理することができるように、少なくとも１つの許容される無線アクセス技術タイプを含んでいる。
【００９７】
いくつかの実施形態に従えば、制御ユニット３１０の制御の下に、メッセージＳ−３０８により、許容するＲＡＴタイプに関する情報を判定ユニット３０４から受信した後、この属性関連メッセージは、通信ユニット３０８によって生成することができる。
【００９８】
再度、いくつかの実施形態に従えば、上述のように、ＡＦ２６によって送信されるように、属性関連メッセージをＰＣＲＥ２４によって受信するステップ２０８によって、これを図２で概略的に示される。
【００９９】
いくつかの実施形態に従えば、実際に、Ｒｘインタフェースを介して通信される５要素の組の唯一のアイデンティティであるＵＥのソースおよびポートＩＰアドレスは、サービスリクエストのストリーミングを曖昧さなく定義していることに留意されたい。
【０１００】
ＰＣＲＦステップおよび特徴−フットボール・ゲーム・シナリオ
図６は、典型的には、ポリシーノードによって実行される方法のステップの実施形態を示すフローチャートである。これらのステップは、ステップ５１４である、図５の本方法の最後のステップに接続して開始する。
【０１０１】
図６の最初のステップは、ステップ５１４で、参照点Ｒｘを介してＡＦからＡＡリクエストの形式の属性関連メッセージＳ−４０２を取得するステップである。
【０１０２】
従って、ステップ６０２は、ＡＦから許容するＲＡＴタイプを含む属性関連メッセージＳ−４０２を取得するステップを含んでいる。いくつかの実施形態に従えば、ＡＦとＰＣＲＦ間のインタフェースは、参照点Ｒｘを備える。
【０１０３】
しかしながら、上述のように、アプリケーション機能−ポリシー制御インタフェースの下で、アプリケーションノードとポリシーノード間のインタフェースは、完全に新しいインタフェースによって実現することができる。
【０１０４】
いくつかの実施形態に従えば、許容するＲＡＴタイプを含む属性関連メッセージを取得するステップに戻り、ここで、属性関連メッセージはＡＡリクエストに対応していて、通信ユニット４０２によって取得することができる。
【０１０５】
ＡＦ２６からＰＣＲＦ２４によって属性関連メッセージＳ−４０２を受信することによって、ＵＥ２２のアイデンティティおよびユーザの加入を考慮する少なくとも１つのＲＡＴタイプにおいてＵＥ２２を宛先とする、ＵＥ２２を伴うリクエストサービスをＡＦ２６から提供することができることを示す情報を、ＰＣＲＦ２４は受信している。次に、ＰＣＲＦ２４のタスクは、ＵＥ２２が現に通信するＲＡＴタイプの知識を取得することである。
【０１０６】
次いで、ＰＣＲＦ２４は、ＵＥ２２が現在通信するＲＡＴタイプに関する情報を取得することができる。これは、現行ＲＡＴタイプを取得するステップ６０４で実される。図１の信号交換では、このステップは、ステップ２１０に対応する。
【０１０７】
ゲートウェイ汎用パケット無線サービス・サポート・ノード（ＧＧＳＮ）４１２のようなゲートウェイからメッセージＳ−４０４によるＧｘシグナリングを介して、既にＩＰ  ＣＡＮの確立過程において、実際のＲＡＴタイプ情報は、典型的には、ＰＣＲＦ２４、４００に配信される。それゆえ、いくつかの実施形態に従えば、ＵＥが通信するＲＡＴタイプに関する情報は、典型的には、ＰＣＲＦによって取得される。
【０１０８】
ＵＥ２２が現時点で通信するＲＡＴタイプに関する情報は、ＰＣＲＦ４００のデータベース４０４に記憶することができる。図１の右側のテーブル１１２は、ＵＥ  ＩＤおよび現行ＲＡＴタイプを記憶されているコンテンツを概略的に示している。この記憶されている情報は、この例におけるＸがＷＬＡＮである場合には、シナリオＩに従い、アイデンティティ「Ａ」を有するＵＥが、現にＲＡＴタイプＸにおいて通信することを示している。
【０１０９】
ステップ６０４で、ＵＥ２２が現時点で通信するＲＡＴタイプを取得すると、この情報は、データベース４０４からメッセージＳ−４０６によって比較ユニット４０６に通信される。ＵＥによってリクエストされるサービスをＡＦによって提供することができる、許容するＲＡＴタイプに関する情報も、通信ユニット４０２からメッセージＳ−４０８によって比較ユニット４０６に通信される。メッセージＳ−４０６およびメッセージＳ−４０８の情報にアクセスすると、制御ユニット４０８の制御の下で、ステップ６０６および図２のステップ２１２では、ＰＣＲＦによって、サービス配信制御ステップの例である、現行ＲＡＴタイプと許容するＲＡＴタイプとを比較するステップを実行することができる。
【０１１０】
再度、シナリオＩおよび図１の左側のテーブル１１０を参照すると、ＹがＵＴＲＡＮであり、ＸがＷＬＡＮであるＲＡＴタイプにおいてインターネット・プロトコル・ソース（ＩＰＳＲＣ：Internet Protocol Source）から、ＵＥ  ＩＤ「Ａ」を有するユーザにフットボールゲームを提供することができることがわかる。また、ＵＥがＷＬＡＮであるＲＡＴタイプＸにおいて現在通信していることがわかる。
【０１１１】
ステップ６０６またはステップ２１２は、典型的には、ＰＣＲＦ４００の比較ユニット４０６によって実行され、ここで、比較ユニット４０６は、通信ユニット４０２に接続されていて、また、リクエストされているサービスをＡＦによって提供することができる、少なくとも１つの許容するＲＡＴタイプＳ−４０８を、比較ユニット４０６が取得することができる。
【０１１２】
上述ように、また、図１の右側のテーブル１１２によって示されるように、データベース４０４は、ＵＥが通信するＲＡＴタイプを記憶するように構成することができる。
【０１１３】
図６のフローチャートの本方法のステップにおいて、現行ＲＡＴタイプが、Ｒｘインタフェースを介して受信される許容するＲＡＴタイプの中にあるかどうかを、以下のステップであるステップ６０８で判定する。
【０１１４】
制御ユニット４０８の制御の下に、データベース４０６から情報Ｓ−４０６が提供され、および通信ユニット４０２から情報Ｓ−４０８が提供される、比較ユニット４０６によって、このステップを実行することができる。
【０１１５】
図１において、シナリオＩに従い、左側のテーブル１１０には、ＡＦがフットボールゲームを提供することができるＩＰＳＲＣ「１」を有する、許容するＲＡＴタイプが示されている。また、右側のテーブル１１２から、ＩＤが「Ａ」に等しいＵＥが通信するＲＡＴタイプがＸ（ＷＬＡＮ）であることが示され、これは、サービスを提供することができる少なくとも１つのＲＡＴタイプ、ＲＡＴタイプＹ（ＵＴＲＡＮ）およびＲＡＴタイプＸ（ＷＬＡＮ）内に、ＲＡＴタイプＸが検出されることを意味する。従って、ＰＣＲＦ４００の比較ユニット４０６によって行われるＲＡＴタイプのマッチングが存在する。
【０１１６】
比較ユニット４０６によるマッチングが存在すると判定し、メッセージＳ−４１０が、ＰＣＲＦ４００の通信ユニット４０２に送信される。
【０１１７】
ステップ６０８で肯定するように問い合わせに答え、図１の以下のシナリオＩは、図６の方法の後続ステップが、ＰＣＲＦとＡＦ間のインタフェースを介してＡＦに受理を送信するようにステップ６１０で定義する。いくつかの実施形態に従えば、このインタフェースは、参照点Ｒｘである。
【０１１８】
制御ユニット４０８の制御の下に、受理を送信するこのステップは、通信ユニット４０２によって実行することができ、ここで、受理は通信ユニット４０２からＡＦ４１０に送信される属性関連メッセージ応答Ｓ−４１２の一例である。この属性関連メッセージは、ノード間インタフェースあるいは参照点Ｒｘを介して通信される。
【０１１９】
図２で、ステップ２１２において示されるように、比較ユニット４０６によってＲＡＴタイプのマッチングが存在することを判定した後、ＰＣＲＦによってＡＦへの受理の送信ステップを含む応答を送信するステップが、ステップ２１４によって示され、再度、いくつかの実施形態に従えば、この受理は、ＡＡ−応答として実現することができる属性関連メッセージ応答の一例である。
【０１２０】
フットボールゲームを、例えば、ＧＥＲＡＮおよびＵＴＲＡＮにおいてのみ配信することができ、かつ移動電話機が現時点でＷＬＡＮにおいて通信する場合では、図１の左のテーブル１１０および右側のテーブル１１２それぞれによって示されるように、異なるシナリオ、シナリオＩＩがある。
【０１２１】
このシナリオＩＩに従い、次に、ＩＰＳＲＣ２によって配信されるフットボールゲームは、ＧＥＲＡＮであるＲＡＴタイプＺおよびＵＴＲＡＮであるＲＡＴタイプＹにおいてのみ配信することができるが、アイデンティティＵＥ  ＩＤ  Ａを有するＵＥの現行ＲＡＴタイプは、ＷＬＡＮであるＲＡＴタイプＸである。それゆえ、ステップ６０８では、制御ユニット４０８の制御の下に、比較ユニット４０６によって判定されるように、ＡＦによって許容されるＲＡＴタイプの中に、現行ＲＡＴタイプを検出することができないと判定される。ステップ６０８の問い合わせに対する回答は、否定的であり、そのため、この方法の次のステップは、許容され、かつ現行ＲＡＴタイプと異なるあるＲＡＴタイプを起動するかどうかをステップ６１２で判定することである。このステップは、制御ユニット４０８によって実行することができる。
【０１２２】
代替実施形態に従えば、ＰＣＲＦにおいてプロビジョンされる静的ルールを考慮することができる。現行ＲＡＴタイプが許容するＲＡＴタイプの中にないとステップ６０８で判定される場合、ＰＣＲＦは、この代替実施形態に従って、現行ＲＡＴタイプがＰＣＲＦにおいて静的にプロビジョンされるかどうかを判定することができる。
【０１２３】
静的加入ルールを含むように構成されている加入プロファイルリポジトリ（ＳＰＲ）の支援により、この判定は、ＰＣＲＦによって実行することができる。
【０１２４】
現行ＲＡＴタイプは、実際、静的に、例えば、ＳＰＲにおいてプロビジョンされることがＰＣＲＦにおいて判定される場合、受理メッセージは、ステップ６１０に従ってＡＦに送信されることになる。
【０１２５】
現行ＲＡＴタイプが静的にプロビジョンされず、また、現行ＲＡＴタイプが、許容するＲＡＴタイプの中にないことが、ステップ６０８で検出されたと、ＰＣＲＦによって判定される場合、ＵＥが現時点で通信するＲＡＴタイプと異なるあるＲＡＴタイプの起動ステップであるステップ６１２により本方法は継続し、ここで、ＲＡＴタイプは、ＡＦによって許容される、または静的ルールがプロビジョンされる場合ではＰＣＲＦ／ＳＰＲによって静的にプロビジョンされる、ことのいずれかによってなされる、または両者によってなされる。比較ユニット４０６およびデータベース４０４による支援により、このステップは、制御ユニット４０８によって実行することができる。
【０１２６】
いくつかの実施形態に従えば、図６のステップ６１２における現行ＲＡＴタイプと異なるあるＲＡＴタイプを起動するかどうかを判定するステップは、図２のステップ２１６に対応し、これは、許容するＲＡＴタイプの１つに現行ＲＡＴタイプを更新するかを判定する。
【０１２７】
比較ユニット４０６および制御ユニット４０８が、現行ＲＡＴタイプと異なるＲＡＴタイプを起動しないと判定する場合、即ち、ステップ６１２で問い合わせに否定するように回答する場合、ステップ６１４で、インタフェースＲｘを介してＡＦ４１０に拒否応答を送信するステップによって、これらの実施形態の方法が進められる。
【０１２８】
この拒否応答は、典型的には、通信ユニット４０２からＡＦ４１０に送信される属性関連メッセージ応答Ｓ−４１２の一例である。この属性関連メッセージ応答は、認証認可応答（ＡＡＲ）によって実現することができる。
【０１２９】
また、現行ＲＡＴタイプと異なるＲＡＴタイプを起動しないことの情報を含む、比較ユニット４０６から通信ユニット４０２に送信されるメッセージＳ−４１０によって、属性関連メッセージ応答の送信が拒否として先行する。
【０１３０】
ＵＥが現時点で通信するＲＡＴタイプ、つまり、ＵＥに対する現行ＲＡＴタイプと異なるＲＡＴタイプを起動しない１つの理由は、現時点で使用されるものより他のＲＡＴタイプをＵＥがサポートできないということでありえよう。
【０１３１】
ＵＥが現時点で通信するＲＡＴタイプと異なるＲＡＴタイプを起動しない別の理由は、他のサービスが既に前記現行ＲＡＴを使用していることでありえよう。
【０１３２】
しかしながら、ＰＣＲＦの比較ユニット４０６がステップ６１２で問い合わせに肯定するように回答する場合、本方法は、ステップ６１６でＲＡＴタイプの優先順位を取得するステップによって進むことができる。代替実施形態に従えば、このステップは許容するＲＡＴタイプの優先順位を取得するステップを含むことができ、また、ＳＰＲに記憶される、静的にプロビジョンされるＲＡＴタイプの優先順位を取得するステップを含むことができる。
【０１３３】
サービスを提供することができるＡＦによって許容されるいくつかのＲＡＴタイプが存在しうるため、異なるＲＡＴタイプは、ＡＦによって定義される異なる優先順位を有することができる。例えば、一例を記述すれば、ＧＥＲＡＮに代わりＷＬＡＮにおいてフットボールゲームを提供することは、サービスプロバイダにとって、より好ましいことでありうる。
【０１３４】
また、地理的位置が、利用可能なＲＡＴタイプに影響する可能性がある。例えば、ＷＬＡＮは、田舎では利用可能ではないが、都市では非常に良く利用することができる可能性がある。その上、ＷＬＡＮは、典型的には、ホットスポットで存在する。単数のネットワークまたは複数のネットワークによるサービス範囲、日時、ネットワーク（群）の負荷は取り分け、サービスプロバイダまたはネットワークによって定義される優先順位に影響するパラメータである可能性がある。例えば、あるオペレータは、ＷＬＡＮにおいてサービスを配信する権利を購入している可能性があるが、繁忙時間中ではなく、それはその時間中にＷＬＡＮを使用する権利は、異なるオペレータによって購入されている場合があるからである。
【０１３５】
代替実施形態に従えば、許容するＲＡＴタイプと、およびおそらくはまた静的にプロビジョンされるＲＡＴタイプとの双方のＲＡＴタイプ優先順位を取得すると、図６の方法の次のステップは、ＵＥ内部のＲＡＴタイプのプリファレンスを取得するステップ６１８である。このステップで、例えば、１つまたは複数の理由でＷＬＡＮよりＧＥＲＡＮが好ましいというＵＥ内部のプリファレンスをこの場合取得することができる。
【０１３６】
プリファレンスは、ＵＥが現時点で使用しているものより他のアクセスネットワークの範囲に所在するかにも基づく場合がある。
【０１３７】
後続ステップは、プロバイダの優先順位およびＵＥのプリファレンスに関係する、現行ＲＡＴタイプと異なる特定のＲＡＴタイプを選択するステップ、ステップ６２０でありうる。
【０１３８】
このステップ内では、ＡＦによって提供される優先順位は、ＵＥに対するプリファレンスに勝る場合がある。ＡＦがリクエストされているサービスを提供できる場合、この場合では、ＷＬＡＮおよびＧＥＲＡＮのような２つの等しい優先順位の許容するＲＡＴタイプにおいてフットボールゲームを提供することができ、また、ＵＥが他よりも前記２つのＲＡＴタイプの１つを好む場合には、このＵＥの好むＲＡＴタイプがもちろん選択されることになる。
【０１３９】
ＡＦが、２つの異なる優先順位の許容するＲＡＴタイプ、即ち、他に優先しているものにおいてリクエストされているサービスを提供することができるが、ＵＥが優先順位のないまたはより低い優先順位のものを好む場合には、ＡＦによって定義される優先順位がＵＥのプリファレンスに勝る場合では、より優先順位の高いＲＡＴタイプが選択される。
【０１４０】
しかしながら、ＡＦが、一方が他に優先する２つのＲＡＴタイプを提供し、ＵＥが、優先されるＲＡＴタイプで通信することができない場合、より低い優先順位を有するＲＡＴタイプを通信する新規のＲＡＴタイプとして選択されることになる。
【０１４１】
ＵＥが通信することができ、また、この場合ではフットボールゲームである所望のサービスを受信することができるＲＡＴタイプの選択の優先順位およびプリファレンスのさらなる例が存在する。
【０１４２】
いくつかの実施形態に従えば、優先順位およびプリファレンスに関係し、ＵＥが現時点で通信するＲＡＴタイプである現行ＲＡＴタイプとは異なるＲＡＴタイプを選択するステップは、図２のステップ２２０に対応し、更新するＲＡＴタイプを判定し、この更新するＲＡＴタイプの判定は、現行ＲＡＴタイプを、許容するＲＡＴタイプの１つに更新するかのステップ２１６における問い合わせに肯定的に回答することを意味する。
【０１４３】
現行とは異なるＲＡＴタイプを選択するステップを実行すると、後続ステップは、ＵＥに、更新するＲＡＴタイプリクエストを提供するステップ、ステップ６２２である。このステップは、ＰＣＲＦとＵＥ間の新しいインタフェースを介してＲＡＴタイプ情報を通信することによって実行することができる。
【０１４４】
図２で、このステップはステップ２２２に対応し、ＰＣＲＦからＵＥに更新するＲＡＴタイプリクエストを送信する。
【０１４５】
代替実施形態に従えば、ステップ６２２で、ＵＥにリクエストを送信する必要なく、ＲＡＴタイプの更新は、ＵＥのネットワークによって直接扱うことができる。
【０１４６】
更に、いくつかの実施形態に従えば、ＡＦからのサービスリクエストをＰＣＲＦの現行ＩＰセッションとマッチングさせるために、ＰＣＲＦによって使用されるものは、ＵＥのソースアドレスおよびポートＩＰアドレスであることに注意されたい。
【０１４７】
さらなるＡＦステップおよび特徴−フットボール・ゲーム・シナリオ
現行ＲＡＴタイプが許容するＲＡＴタイプの中にないことをステップ６０８で判定した後、上述したように、ＰＣＲＦからＡＦに受理応答Ｓ−４１２を送信するステップは、図６のステップ６１０に従って実行される。
【０１４８】
従って、この応答のＡＦ３００による受信は、ステップ５１６によって示される属性関連メッセージ応答Ｓ−３１４の受信、ＡＦの方法の実施形態を示す図５の参照点Ｒｘを経るＰＣＲＦからの受理の受信によるものとなる。
【０１４９】
図２において、受理応答を受信するステップは、ＡＡ−応答によって実現することができる属性関連メッセージ応答の形式の受理を、ＰＣＲＦ２４によってＡＦ２６に送信するステップ、ステップ２１４に対応し、このステップ２１４は、制御ユニット４０８の制御の下に、比較ユニット４０６によってマッチングを判定するステップに続く。
【０１５０】
この属性関連メッセージ応答は、リクエストされるサービス、この場合では、フットボールゲームを配信し、かつＵＥによって受信することができるＲＡＴタイプに関するＡＦへの情報を含むことができる。
【０１５１】
選択的には、図６に示されるように、ステップ６１２でＰＣＲＦが現行ＲＡＴタイプと異なるあるＲＡＴタイプを起動しないと判定する場合では、次のステップは、上述のように、ステップ６１４でＰＣＲＦからＡＦへの拒否応答として属性関連メッセージ応答Ｓ−４１２を送信するステップである。
【０１５２】
この場合では、それゆえ、拒否応答として属性関連メッセージ応答Ｓ−３１４がＡＦ３００によって受信されるが、これは、参照点Ｒｘを介してＰＣＲＦから拒否を受信する図５のステップ５１８によって示される。
【０１５３】
再度、図２はまたステップ５１８に対応するステップを示している。ここで、ステップ５１８は、ＰＣＲＦ２４からＡＦ２６へのＡＡ−応答として実現することができる属性関連メッセージ応答の形式の拒否応答を送信するステップ２１８である。
【０１５４】
この拒否応答は、ＵＥによって行われるサービスリクエストに関してリクエストされるサービスを受理することができないことに関するＡＦへの情報を含む可能性がある。この例の可能性に従えば、ＵＥのユーザは、従って、ＵＥの使用によってフットボールゲームを経験することができない。
【０１５５】
非３ＧＰＰ  ＰＣＣアーキテクチャ
本発明のいくつかの実施形態は、主として第３世代パートナーシッププロジェクト（３ＧＰＰ）ＰＣＣアーキテクチャのコンテキストにおいて記載している。一般的な発明の概念は、他のポリシー制御アーキテクチャにも適用可能であることに気をつけるべきである。この他のポリシー制御アーキテクチャには、高度化ネットワーク用の通信およびインターネット融合サービスおよびプロトコル（ＴＩＳＰＡＮ：Telecom & Internet converged Service & Protocol for Advanced Networks）、マイクロ波アクセス用の全世界相互動作（ＷｉＭａｘ：Worldwide Interoperability for Microwave Access）、デジタル加入者線（ＤＳＬ：Digital Subscriber Line）およびその他のものがある。
【０１５６】
このことは、アプリケーションノード−ポリシーノードインタフェースへの拡張が、様々な規格、いくつかの例のみを記述すると、例えば、３ＧＰＰの場合ではダイアミタ（Ｄｉａｍｅｔｅｒ）およびいくつかのその他の場合ではサービス指向アーキテクチャプロトコル（ＳＯＡＰ：Service Oriented Architecture Protocol）間で異なることに関係する。
【０１５７】
いくつかの実施形態に従えば、本方法のステップの順序は変更することができ、図５および図６の少なくとも一方に示されるいくつかのステップは、上記実施形態の保護範囲から離れることなく削除さえすることができる。
【０１５８】
本実施形態は、様々な方法で変形することができ、提示されるその代替実施形態はほんのいくつかの例であることであることが強調される。これら様々な実施形態は、従って、限定する例ではない。本発明の範囲は、特許請求の範囲によってのみ制限される。
【０１５９】
従って、実施形態がいくつかの利点を伴い、その１つがセッションセットアップ過程における実行時に特定サービスに対して許容されるアクセスの指定を可能にすることであることは容易に理解される。これの１つの明確な意味は、新規サービスが展開される場合に、ＰＣＲＦのようなポリー制御ユニットにおいて更新される静的ルールをプロビジョンする必要がないことである。
【０１６０】
別の利点は、全てのアプリケーションが使用することができる汎用的なメカニズムが提供されることである。
【０１６１】
また、有益なことは、様々なアクセス技術タイプ間に優先順位を指定することが可能であることである。
【０１６２】
エンドユーザにとって、およびサービスプロバイダに対して、期待される経験品質（ＱｏＥ：Quality of Experience）を実現することが比較的容易である。
【０１６３】
別の有利な特徴は、ＵＥが現時点で通信する無線アクセス技術タイプを更新するメカニズムをいくつかの実施形態が可能にすることである。
【図１】
2010533418.tif 000003
【図２】
2010533418.tif 000004
【図３】
2010533418.tif 000005
【図４】
2010533418.tif 000006
【図５】
2010533418.tif 000007
【図６】
2010533418.tif 000008
【国際調査報告】
2010533418.tif 000009
2010533418.tif 000010
2010533418.tif 000011