(57)【特許請求の範囲】
【請求項１】
携帯電話ネットワークにおいてパケットベースのサービスセッションに対する認可要求をハンドリングする方法であって、
ノード（８０）が、前記携帯電話ネットワークのポリシーコントローラ（３０）に前記認可要求（３０２；４０２）を送信するステップと、
前記ノード（８０）が、前記ポリシーコントローラ（３０）から、前記ポリシーコントローラ（３０）によって判定されるものとしての前記サービスセッションの認可ステータスを示す認証応答（３０６；４０６）を受信するステップと、
前記ノード（８０）が、前記ポリシーコントローラ（３０）から、前記サービスセッションの前記認可ステータスが変化したことを示すメッセージ（３１１；４１２）を受信するステップと、
前記ノード（８０）が、前記認証応答（３０６；４０６）によって示される前記認可ステータス、および、前記サービスセッションの前記認可ステータスが変化したことを示す前記メッセージ（３１１；４１２）に応じて、前記サービスセッションに関係するその動作を制御するステップと
を含み、
前記制御するステップは、
前記サービスセッションが一時的に認可されていないことを前記認証応答（３０６）が示す場合に、前記サービスセッションを終了せず、前記認可ステータスが変化するのを待つことを含む、
方法。
【請求項２】
前記認証応答（３０６）は、認可されていない前記サービスセッションの構成要素を示す、請求項１に記載の方法。
【請求項３】
前記認証応答（３０６）を受信した後、前記ノード（８０）が、前記サービスセッションの認可された構成要素に関する少なくとも１つの活動を継続するステップを含む、請求項２に記載の方法。
【請求項４】
前記サービスセッションが一時的に認可されていないことを前記認証応答（３０６）が示す場合に、前記ノード（８０）が、前記サービスセッションの前記認可ステータスが変化したことを示す前記メッセージ（３１１）が受信されるまで、前記サービスセッションに対するさらなる認可要求を送信しないステップを含む、請求項１から３のいずれか一項に記載の方法。
【請求項５】
前記サービスセッションが一時的に認可されていないことを前記認証応答（３０６）が示す場合に、前記ノード（８０）が、前記サービスセッションの前記認可ステータスが変化したことを示す前記メッセージ（３１１）が受信されるまで、認可されていない前記サービスセッションの構成要素に対する少なくとも１つの活動を停止するステップを含む、請求項１から４のいずれか一項に記載の方法。
【請求項６】
前記サービスセッションが認可されていることを前記認証応答（４０６）が示す場合に、前記ノード（８０）が、前記サービスセッションの前記認可ステータスが変化したことを示す前記メッセージ（４１２）の受信に応答して、前記サービスセッションに関する少なくとも１つの活動を停止するステップを含む、請求項１に記載の方法。
【請求項７】
前記認可要求（３０２；４０２）は、前記ノード（８０）が前記サービスセッションの前記認可ステータスが変化するか否かを通知されるべきであるという指示を含む、請求項１から６のいずれか一項に記載の方法。
【請求項８】
ノード（８０）であって、
携帯電話ネットワークのポリシーコントローラ（３０）と通信するためのインターフェース（２４０）と、
プロセッサ（２５０）とを備え、
前記プロセッサ（２５０）は、
前記インターフェース（２４０）を介して前記ポリシーコントローラ（３０）に、前記携帯電話ネットワークにおいてパケットベースのサービスセッションに対する認可要求（３０２；４０２）を送信し、
前記ポリシーコントローラ（３０）から前記インターフェース（２４０）を介して、前記ポリシーコントローラ（３０）によって判定されるものとしての前記サービスセッションの認可ステータスを示す認証応答（３０６；４０６）を受信し、
前記ポリシーコントローラ（３０）から前記インターフェース（２４０）を介して、前記サービスセッションの前記認可ステータスが変化したことを示すメッセージ（３１１；４１２）を受信し、
前記サービスセッションが一時的に認可されていないことを前記認証応答（３０６）が示す場合に、前記サービスセッションを終了せず、
前記認可ステータスが変化するのを待つ
ように構成されている、ノード。
【請求項９】
前記認証応答（３０６）は、認可されていない前記サービスセッションの構成要素を示す、請求項８に記載のノード。
【請求項１０】
前記プロセッサ（２５０）は、前記認証応答（３０６）を受信した後、前記サービスセッションの認可された構成要素に関する少なくとも１つの活動を継続するように構成されている、請求項９に記載のノード。
【請求項１１】
前記プロセッサ（２５０）は、
前記サービスセッションが一時的に認可されていないことを前記認証応答（３０６）が示す場合に、前記サービスセッションの前記認可ステータスが変化したことを示す前記メッセージ（３１１）が受信されるまで、前記サービスセッションに対するさらなる認可要求を送信しないように構成されている、請求項８から１０のいずれか一項に記載のノード。
【請求項１２】
前記プロセッサ（２５０）は、
前記サービスセッションが一時的に認可されていないことを前記認証応答（３０６）が示す場合に、前記サービスセッションの前記認可ステータスが変化したことを示す前記メッセージ（３１１）が受信されるまで、認可されていない前記サービスセッションの構成要素に対する少なくとも１つの活動を停止するように構成されている、請求項８から１１のいずれか一項に記載のノード。
【請求項１３】
前記プロセッサ（２５０）は、
前記サービスセッションが認可されていることを前記認証応答（４０６）が示す場合に、前記サービスセッションの前記認可ステータスが変化したことを示す前記メッセージ（４１２）の受信に応答して、前記サービスセッションに関する少なくとも１つの活動を停止するように構成されている、請求項８に記載のノード。
【請求項１４】
前記認可要求（３０２；４０２）は、前記ノード（８０）が前記サービスセッションの前記認可ステータスが変化するか否かを通知されるべきであるという指示を含む、請求項８から１３のいずれか一項に記載のノード。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、携帯電話ネットワークにおけるパケットベースのサービスに対する認可要求をハンドリングする方法および対応するデバイスに関する。
【背景技術】
【０００２】
ネットワークリソースの使用状況を管理するために、ネットワークは、ポリシー制御メカニズムを実装する場合がある。たとえば、３ＧＰＰ（Ｔｈｉｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）携帯電話ネットワークには、ポリシー／課金制御（ＰＣＣ）アーキテクチャが設けられている。ＰＣＣアーキテクチャの詳細は、３ＧＰＰ技術仕様書（ＴＳ）２３．２０３に見ることができる。ＰＣＣアーキテクチャは、オペレータが、自身のネットワークリソースのリアルタイム制御を達成し、サービスに対する加入者のアクセスを制御し、ネットワーク容量を積極的に最適化することを可能にする。ＰＣＣアーキテクチャの要素は、ポリシー／課金ルール機能（ＰＣＲＦ）、ポリシー実施機能（ＰＣＥＦ）および／またはベアラバインディング／イベント報告機能（ＢＢＥＲＦ）、ならびにアプリケーション機能（ＡＦ）と称されるポリシーコントローラを含む。
【０００３】
ＰＣＲＦは、サービス・データ・フロー検出、ゲーティング、サービス品質（ＱｏＳ）、およびフローベースの課金に関するネットワーク制御を提供する。この制御は、たとえば、ＰＣＣルールを作成しそれらをＰＣＥＦ内にインストールすること、ＱｏＳルールを作成してそれらをＢＢＥＲＦ内にインストールすること、または、インストールされたＰＣＣルールもしくはＱｏＳルールを起動または停止することによる、ＰＣＥＦによるＰＣＣルールの実施の制御および／またはＢＢＥＲＦによるＱｏＳルールの実施の制御を含む。
【０００４】
ＡＦは、ユーザ機器（ＵＥ）へのまたはＵＥからのパケットベースのデータ転送を必要とするパケットベースのサービスまたはアプリケーションを提供する要素である。ＰＣＣアーキテクチャは、このパケットベースのデータ転送が動的なポリシーおよび／または課金制御を受けることを可能にする。この目的のために、ＡＦは、サービスに関係する情報を転送するためにＰＣＲＦと通信し得る。ＰＣＲＦは、制御決定を行うためにこの情報を使用し得る。
【０００５】
たとえば、ＡＦが、サービスまたはアプリケーションのデータをＵＥへまたはＵＥから転送する必要があるとき、ＡＦは、サービスの認可を求める要求のためにＰＣＲＦと通信し得る。その後、ＰＣＲＦは、サービスを認可し、対応するＰＣＣ／ＱｏＳルールを作成し、それらをＰＣＥＦまたはＢＢＥＲＦ内にインストールし得る。
【０００６】
代替的に、ＰＣＲＦはサービスを認可しなくてもよい。サービスの認可を拒絶する決定は、たとえば、ユーザの加入プロファイルにおいて規定されているような、種々の基準に基づく場合がある。ＰＣＲＦは、サービスが何故ＡＦに対して認可されなかったのかという理由を示し得る。この情報に基づいて、ＡＦは、種々の行動をとり、たとえば、一定期間の後にサービスの認可を再試行し得る。
【０００７】
状況によって、サービスの認可を拒絶する根拠を成す条件は変化する場合がある。たとえば、拒絶が、特定のサービスを使用することを許可されていないカテゴリに加入者が属していることに起因していた場合、加入者のカテゴリがオペレータによって変更され得る。さらに、拒絶が、訪問先ネットワーク内でＵＥがローミングしており、その場合に特定のサービスの使用がローミング協定によって許可されていないことに起因していた場合、ＵＥはそのホームネットワークに戻り得、この場合にそのサービスの使用が再び許可されることになる。さらに、使用されている加入者のクオータが上限に達していることに起因して認可が拒絶された場合、加入者はクオータを再充填し得る。
【０００８】
しかしながら、ＡＦは一般的に、そのような条件の変化がいつ発生するかを知らない。したがって、ＡＦがサービスの認可を盲目的に再試行する場合、頻繁に拒絶が発生する場合がある。他方、ＡＦがサービスの認可を再試行しない場合、再試行していれば許可されていたサービスの使用が妨げられることになり得る。
【先行技術文献】
【非特許文献】
【０００９】
【非特許文献１】３ＧＰＰ技術仕様書（ＴＳ）２３．２０３
【発明の概要】
【発明が解決しようとする課題】
【００１０】
したがって、携帯電話ネットワーク内でサービスを効率的に認証することを可能にする技法が必要とされている。
【課題を解決するための手段】
【００１１】
本発明の一実施形態によれば、携帯電話ネットワークにおいてパケットベースのサービスに対する認可要求をハンドリングする方法が提供される。本方法によれば、ポリシーコントローラは、ノードから認可要求を受信する。認可要求の受信に応答して、ポリシーコントローラは、サービスの認可ステータスを判定するために認可検査を実行し、ノードに認証応答を送る。認証応答は、サービスの認可ステータスを示す。同じ認可要求に応答して、ポリシーコントローラは、サービスの認可ステータスを判定し直すための、少なくとも一回のさらなる認可検査を実行する。サービスの認可ステータスが変化したことをさらなる認可検査が示す場合、ポリシーコントローラはノードにメッセージを送る。メッセージは、サービスの認可ステータスが変化したことをノードに示す。
【００１２】
本発明のさらなる実施形態によれば、携帯電話ネットワークにおいてパケットベースのサービスに対する認可要求をハンドリングする方法が提供される。本方法によれば、ノードが、携帯電話ネットワークのポリシーコントローラに認可要求を送り、ポリシーコントローラから認証応答を受信する。認証応答は、ポリシーコントローラによって判定されたものとしてのサービスの認可ステータスを示す。加えて、ノードはポリシーコントローラからメッセージを受信する。メッセージは、サービスの認可ステータスが変化したことを示す。ノードは、認証応答によって示される認可ステータス、および、セッションの認可ステータスが変化したことを示すメッセージに応じて、サービスに関するその動作を制御する。  
【００１３】
本発明のさらなる実施形態によれば、ポリシーコントローラが提供される。ポリシーコントローラは、携帯電話ネットワーク内のリソースを制御するように構成されている。ポリシーコントローラは、ノードおよびプロセッサと通信するためのインターフェースを備える。プロセッサは、インターフェースを介して、携帯電話ネットワーク内のパケットベースのサービスに対する認可要求を受信するように構成されている。さらに、プロセッサは、認可要求の受信に応答して、サービスの認可ステータスを判定するために認可検査を実行し、インターフェースを介してノードに認証応答を送るように構成されている。認証応答は、サービスの認可ステータスを示す。加えて、プロセッサは、認可要求の受信に応答して、サービスの認可ステータスを判定し直すための、さらなる認可検査を実行し、サービスの認可ステータスが変化したことをさらなる認可検査が示す場合、インターフェースを介してノードにメッセージを送るように構成されている。メッセージは、サービスの認可ステータスが変化したことを示す。
【００１４】
本発明のさらなる実施形態によれば、ノードが提供される。ノードは、携帯電話ネットワークのポリシーコントローラおよびプロセッサと通信するためのインターフェースを備える。プロセッサは、インターフェースを介して、ポリシーコントローラに、携帯電話ネットワーク内のパケットベースのサービスに対する認可要求を送り、ポリシーコントローラからインターフェースを介して認証応答を受信するように構成されている。認証応答は、ポリシーコントローラによって判定されたものとしてのサービスの認可ステータスを示す。さらに、プロセッサは、ポリシーコントローラからインターフェースを介して、メッセージを受信するように構成されている。メッセージは、サービスの認可ステータスが変化したことを示す。さらに、プロセッサは、認証応答およびステータス変化メッセージによって示される認可ステータスに応じて、サービスに関するノードの動作を制御するように構成されている。
【図面の簡単な説明】
【００１５】
【図１】本発明の一実施形態によるセッション認証の概念を適用することができる携帯電話ネットワーク環境を概略的に示す図である。
【図２】本発明の一実施形態によるＰＣＣアーキテクチャを概略的に示す図である。
【図３】本発明の一実施形態による例示的なセッション認証プロセスを概略的に示すためのシグナリング図である。
【図４】本発明の一実施形態によるさらなる例示的なセッション認証プロセスを概略的に示すためのシグナリング図である。
【図５】本発明の一実施形態によるポリシーコントローラを概略的に示す図である。
【図６】本発明の一実施形態によるノードを概略的に示す図である。
【図７】本発明の一実施形態による方法を示すための流れ図である。
【図８】本発明の一実施形態によるさらなる方法を示すための流れ図である。
【発明を実施するための形態】
【００１６】
以下において、例示的な実施形態および添付の図面を参照することによって、本発明をより詳細に説明する。示されている実施形態は、携帯電話ネットワークにおけるパケットベースのサービスの認可の概念に関する。一般的に、サービスとは、携帯電話ネットワークに接続されているＵＥによってアクセスすることができる、携帯電話ネットワーク内の機能である。サービスは、サーバおよび／またはＵＥ上の特定のアプリケーションによって実施されてもよい。示されている例において、本概念は、３ＧＰＰ  ＴＳによる携帯電話ネットワーク内に適用される。しかしながら、示されている概念は他のタイプの携帯電話ネットワークにも同様に適用されてもよいことは理解されたい。
【００１７】
図１は、本発明の一実施形態による概念を適用することができる携帯電話ネットワーク環境を概略的に示す。
【００１８】
携帯電話ネットワーク環境は、端末と称される場合もあるＵＥ１０と、いくつかの携帯電話ネットワーク構成要素２２、２４、２６、３０、３６とを含む。これらの携帯電話ネットワーク構成要素の中に、無線アクセスネットワーク（ＲＡＮ）２２がある。ＲＡＮ２２は、１つまたは複数の特定のタイプの無線アクセス技術（ＲＡＴ）、たとえば、ＧＳＭ（登録商標）（Ｇｌｏｂａｌ  Ｓｙｓｔｅｍ  ｆｏｒ  Ｍｏｂｉｌｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）、ＥＤＧＥ（Ｅｎｈａｎｃｅｄ  Ｄａｔａ  Ｒａｔｅ  ｆｏｒ  ＧＳＭ  Ｅｖｏｌｕｔｉｏｎ）、ＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ  Ｍｏｂｉｌｅ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｓｙｓｔｅｍ）、広帯域符号分割多元接続（ＷＣＤＭＡ（登録商標））、またはＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）に基づく。ＲＡＮ２２は単一のノードとして示されているが、ＲＡＮ２２は実際には、本明細書においてはさらには説明しないいくつかの構成要素から形成されてもよいことは理解されたい。ＲＡＮ２２は転送ノード２４に結合されており、転送ノードはゲートウェイ（ＧＷ）２６に結合されている。ここで、代替的に２つ以上の転送ノード２４がＲＡＮ２２とゲートウェイ２６との間に結合されてもよいこと、またはＲＡＮ２２はゲートウェイ２６に直接結合されてもよいことは理解されたい。ゲートウェイ２６は、ＧＰＲＳベースのサービスの１つまたは複数の外部パケット・データ・ネットワークへの接続を提供する、ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）であってもよい。ゲートウェイ２６はまた、パケット・データ・ネットワーク・ゲートウェイ（ＰＤＮ  ＧＷ）であってもよい。
【００１９】
加えて、携帯電話ネットワークは、３ＧＰＰ  ＴＳによるポリシー／課金ルール機能（ＰＣＲＦ）として実装されるポリシーコントローラ３０を含む。ポリシーコントローラ３０は、専用ハードウェアによって実装され、および／またはプロセッサによって実行されるソフトウェア機能を含んでもよい。ゲートウェイ２６およびポリシーコントローラ３０は一般的に、コアネットワークの構成要素として考えられる。ポリシーコントローラ３０は、３ＧＰＰ  ＴＳによるＧｘインターフェースを使用して実装されてもよいシグナリング経路７を介してゲートウェイ２６と通信する。ポリシーコントローラ３０は、たとえば、３ＧＰＰ  ＴＳによるＳｐインターフェースを使用して実装されるシグナリング経路８を介して、加入者データベース３８、たとえば、３ＧＰＰ  ＴＳによる加入プロファイルレポジトリ（ＳＰＲ）またはユーザ・データ・レポジトリ（ＵＤＲ）にさらに結合されてもよい。したがって、ポリシーコントローラ３０は、特定のユーザに関係する、および／または、モバイル通信ネットワーク内で利用可能な特定のサービス、たとえば、モバイルＴＶに関係するデータを受信することができる。
【００２０】
さらに示されるように、携帯電話ネットワーク環境は、アプリケーション機能（ＡＦ）５０を含む。ＡＦ５０は、ＡＦ５０と、ＵＥ１０上で作動している１つまたは複数のクライアント／ピアアプリケーション１２との間の対話によって、ＵＥ１０によって使用されることになる１つまたは複数のパケットベースのサービスまたはアプリケーションを提供する。ＡＦ５０は、３ＧＰＰ  ＴＳによるＲｘインターフェースを使用して実装されてもよいコントロールシグナリング経路５を使用してポリシーコントローラ３０と通信することができる。
【００２１】
示されている例において、携帯電話ネットワークは、トラフィック検出機能（ＴＤＦ）３６をも含む。ＴＤＦ３６は、たとえば、ＡＦ５０によって提供される特定のサービスによって生成されるような特定のタイプのパケットベースのデータトラフィックを検出し、検出されたデータトラフィックをＰＣＲＦ３０に報告するように構成されているノードである。この目的のために、ＴＤＦ３６は、シグナリング経路６を使用してＰＣＲＦ３０と通信することができる。シグナリング経路６は、３ＧＰＰ  ＴＳによるＳｄインターフェースを使用して実装されてもよい。状況によっては、シグナリング経路６はまた、３ＧＰＰ  ＴＳによるＲｘインターフェースを使用して実装されてもよい。言い換えると、ＰＣＲＦ３０と通信するとき、ＴＤＦ３６はＡＦとして機能し得る。
【００２２】
さらに示されるように、ネットワークとＵＥ１０との間のデータトラフィックは、ＵＥ１０とＲＡＮ２２との間の無線インターフェースにわたって確立されるいくつかのベアラ５２、５４によって搬送される。データトラフィックは、特に、ＡＦ５０によって提供されるサービスの１つまたは複数に関連し得、ＵＥ１０とＡＦ５０との間で転送され得る。ベアラ５２、５４は、ＵＥ１０とゲートウェイ２６との間に確立される。ベアラ５２、５４は、ＤＬ方向およびＵＬ方向の両方においてデータトラフィックを搬送することができる、すなわち、ＤＬベアラおよびＵＬベアラから形成されているとしても考えられてもよい。ベアラ５２、５４における双方向通信をサポートするために、ＵＥ１０には、ベアラ５２、５４から入来するデータパケットを受信し、ベアラ５２、５４上で発信するデータパケットを送ることを可能にする、対応するインターフェース１５が設けられている。同様に、ゲートウェイ２６には、ベアラ５２、５４から入来するデータパケットを受信し、ベアラ５２、５４上で発信するデータパケットを送ることを可能にする、対応するインターフェース２５が設けられている。ベアラ５２、５４は、一般的にパケットベースのサービスをＵＥ１０に提供するように確立されているデフォルトのベアラ５２、および、デフォルトのベアラ５２とは異なるＱｏＳレベル、たとえば、より高いまたはより低いＱｏＳレベルを有してもよい１つまたは複数の専用ベアラ５４を含んでもよい。デフォルトのベアラ５２は一般的に、ＵＥ１０がゲートウェイ２６に接続し、たとえば、インターネット・プロトコル（ＩＰ）アドレスをＵＥ１０に割り当てることが伴いうる、そのパケットベースの接続を受けるときに確立される。専用ベアラ５４は一般的に、特定のＱｏＳレベルを必要とするデータパケットを送信する必要があるときに、要求に応じて確立される。たとえば、専用ベアラ５４は、クライアント／ピアアプリケーション１２の１つによってＵＥ１０とＡＦ５０との間のセッションが開始されるときに確立されてもよい。
【００２３】
各ベアラ５２、５４は、対応するＱｏＳプロファイルと関連付けられてもよい。ＱｏＳプロファイルは、ＱｏＳクラス識別子（ＱＣＩ）、割り当て／保持優先度（ＡＲＰ）、最大ビットレート（ＭＢＲ）、総合最大ビットレート（ＡＭＢＲ）、および／または保証ビットレート（ＧＢＲ）のようなパラメータによって定義されてもよい。トラフィックハンドリング優先度（ＴＨＰ）が、たとえば、ＱＣＩから生成され得る。したがって、特定のＱｏＳレベルが、ベアラ５２、５４のうちの対応するものにデータパケットを割り当てることによって、ＵＥ１０とゲートウェイ２６との間でデータパケットを通信するために提供され得る。
【００２４】
ＵＥ１０において、データパケットは、ＵＬパケットフィルタ６２、６４の形態の、対応して構成されているパケット分類ルールを使用して所望のベアラ５２、５４にルーティングされる。ゲートウェイ２６において、データパケットは、ＤＬパケットフィルタ７２、７４の形態の、対応して構成されているパケット分類ルールを使用して所望のベアラ５２、５４にルーティングされる。示されている３ＧＰＰ状況によれば、データパケットを対応するベアラに方向付けるように動作するフィルタ６２、６４、７２、７４のセットは、ＴＦＴとも呼ばれる。ＱｏＳプロファイルのパラメータは、ポリシーコントローラ３０からシグナリング経路７を使用してゲートウェイ２６へとシグナリングされてもよい。同様に、ゲートウェイ２６において使用されるべきＤＬパケットフィルタ７２、７４は、ポリシーコントローラ３０からシグナリング経路７を介してゲートウェイ２６へとシグナリングされてもよい。ＵＥ１０において使用されるＵＬパケットフィルタ６２、６４について、これらは、ポリシーコントローラ３０からゲートウェイ２６を介してＵＥ１０へとシグナリングされてもよい。
【００２５】
図１に示されているような状況において、ＵＥ１０のクライアント／ピアアプリケーション１２の１つまたは複数と協働してＡＦ５０によって提供されるパケットベースのサービスは、したがって、ポリシーコントローラ３０によって制御されるベアラ５２、５４の１つまたは複数を介してデータを転送することができる。そのような制御を可能にするために、サービスは、例えば加入者データベース３８からの加入データおよび／またはポリシーコントローラ３０内に構成されている他のデータもしくはルールに基づいて、ポリシーコントローラ３０によってＡＦ５０に対して認可され得る。以下において説明されているような、本発明の実施形態による概念は、そのようなサービスの認可を効率的に実施することを可能にする。
【００２６】
これに関連して、ＡＦ５０からポリシーコントローラ３０へと複数の認可要求を発行する必要なしに、ポリシーコントローラ３０がＡＦ５０に、サービスの認可ステータスの変化を示すことを可能にするメカニズムが使用され得る。このメカニズムを使用して、ポリシーコントローラ３０は、単一の認可要求を受信し、認可ステータスを示す初期認証応答を送った後、後の認証変化をＡＦ５０に示すことができる。たとえば、ポリシーコントローラ３０は、サービスまたはその構成要素が一時的に認可されていない認可ステータスから、サービスまたはその構成要素が認可されている認可ステータスへの変化、およびその逆の変化を示し得る。この目的のために、ポリシーコントローラ３０は、サービスの認可ステータスを判定し直してもよい。
【００２７】
ＡＦ５０は、たとえば、ＡＦ５０からポリシーコントローラ３０へと送信される認可要求において対応する指示を提供することによって、認可ステータスの変化に関して通知されることに同意してもよい。サービスが一時的に認可されていないことをポリシーコントローラ３０がＡＦ５０に通知すると、ＡＦ５０は、たとえば、同じ認可要求を再び送らないことによって、認可が要求されていたサービスに関するその活動を停止し得る。サービスが再び認可されたことをポリシーコントローラ３０がＡＦに通知すると、ＡＦ５０は、そのサービスに関するその活動を継続することができ、これは、ポリシーコントローラ３０に再び接触することも含み得る。
【００２８】
本明細書に記載のようなメカニズムにおいて、２つのタイプのセッション、すなわち、サービスセッションまたはＡＦセッションとも称される場合がある、ＵＥ１０とＡＦ５０との間に確立されるセッションと、制御セッションとも称される場合がある、または、シグナリング経路５のＲｘセッションとしての実施態様による、ＡＦ５０とポリシーコントローラ３０との間に確立されるセッションとが区別され得る。サービスセッションには、たとえば、ＵＥ１０とＡＦ５０との間でデータを搬送することによって、ＵＥ１０がサービスにアクセスすることを可能にするという目的がある。制御セッションには、ＡＦ５０とポリシーコントローラ３０との間で、サービスおよびその認証に関する情報を搬送するという目的がある。制御セッションは、ＡＦ５０からポリシーコントローラ３０への認可要求によって開始され得る。本明細書に記載のようなメカニズムによって、認可が要求されるサービスが一時的に認可されていない場合であっても制御セッションをアクティブなままにすることができ、再び認可されるようになっているサービスが新たな制御セッションを確立する必要なしに効率的に示され得る。
【００２９】
図２は、３ＧＰＰ  ＴＳ  ２３．２０３によるＰＣＣアーキテクチャにおける、本発明の一実施形態による概念の実施態様を示す。示されているように、ＰＣＣアーキテクチャは、ＧＷ２６、ＰＣＲＦ３０、加入者データベース３８を含む。さらに、ＰＣＣアーキテクチャは、ＧＷ２６内に実装されるＰＣＥＦ３４をも含む。示されている例において、加入者データベース３８は、ＳＰＲに対応すると仮定される。しかしながら、他のタイプの加入者データベース、たとえば、ユーザ・データ・レポジトリ（ＵＤＲ）も同様に使用され得ることを理解されたい。示されているように、ＰＣＣアーキテクチャは、１つまたは複数のＴＤＦ３６、３６’、ＢＢＥＲＦ３９、オフライン課金システム（ＯＦＣＳ）４２、オンライン課金システム（ＯＣＳ）４４、およびＡＦ５０をも含んでもよい。
【００３０】
ＰＣＲＦ３０は、ポリシー制御決定および／またはフローベースの課金制御を実行するように構成され得る。ＰＣＲＦ３０は、ＰＣＥＦ３４に対して、サービス・データ・フローの検出、ゲーティング、ＱｏＳ、およびフローベースの課金に関するネットワーク制御を提供し得る。この目的のために、ＰＣＲＦ３０は、ＰＣＣルールをＰＣＥＦ３４にシグナリングし得る。ＰＣＥＦ３４は、サービス・データ・フロー検出、ポリシー実施およびフローベースの課金の機能を実行するように構成され得、これは一般的に、ＰＣＲＦ３０によってシグナリングされるものとしてのＰＣＣルールを適用することによって達成される。さらに、ＰＣＥＦ３４は、ディープ・パケット・インスペクション（ＤＰＩ）のようなパケットインスペクション、およびサ−ビス分類のような機能も実施することができる。このように、データパケットは、ＰＣＥＦ３４において定義されているＰＣＣルールに従って分類され、特定のサービスに割り当てられ得る。
【００３１】
ＰＣＥＦ３４は、加入者の認証、アクセスおよびサービスの認可、会計処理、およびモビリティに関するポリシーを実施する役割を担い得る。ＰＣＲＦ３０は、サービスを良好に送達する、または所与のサービスのＱｏＳを良好に維持するために満たされなければならないネットワーク、アプリケーション、および加入者条件を定義する個々のポリシーを管理する役割を担い得る。独立型データベースであるか、または、ホーム加入者サーバ（ＨＳＳ）のような既存の加入者データベースに組み込まれてもよい加入者データベース３８は、権利、料金プランなどのような情報を含み得る。加入者データベース３８は、加入者の許可されたサービス、各許可されたサービスに関する買い取り優先権、加入者のＱｏＳパラメータに関する情報、たとえば、加入保証帯域幅ＱｏＳ、加入者の課金関連情報、たとえば、課金に関連する所在情報、加入者カテゴリ、たとえば、加入者が高いＱｏＳを提供されるべきゴールドユーザであるか、またはより低いＱｏＳを提供されるべきシルバーユーザもしくはブロンズユーザであるか、のような加入データを提供し得る。
【００３２】
ＡＦ５０は、１つまたは複数のパケットベースのサービスを携帯電話ネットワークに接続されているＵＥに提供するように構成され得る要素である。これらのサービスは、サービスが要求されたネットワーク層とは異なるネットワーク層において送達することができる。たとえば、サービスは、たとえば、ＵＥとＡＦ５０との間のシグナリングによってシグナリング層において要求され、たとえば、ＧＷ２６とＵＥとの間でデータパケットを転送することによって、トランスポート層において送達されることができる。ＡＦの例は、プロキシ呼セッション制御機能（Ｐ−ＣＳＣＦ）等の携帯電話ネットワークのＩＰマルチメディアサブシステム（ＩＭＳ）の機能、または、セッション開始プロトコル（ＳＩＰ）アプリケーションサーバのようなアプリケーションサーバである。ＡＦは、コンテンツプロバイダからのコンテンツ配信の促進または優先順位付けを制御するのにも使用されてもよい。ＡＦ５０は一般的に、セッション情報、たとえば、トランスポート層内で送達されるべきデータの記述を転送するためにＰＣＲＦ３０と通信する。上記のように、これは、ＡＦ５０から認可要求を受信したときの、ＰＣＲＦ３０によるサービスの認可をも含み得る。
【００３３】
ＴＤＦ３６、３６’は、たとえば、ディープ・パケット・インスペクション（ＤＰＩ）を実行することによって、パケットインスペクションおよびサービス分類をサポートし得る。この目的のために、データパケットは、データパケットを特定のタイプのサービスに割り当てることができるように、ＴＤＦ３６、３６’内に構成されているルールに従って分類され得る。ＰＣＲＦ３０は、このとき、たとえば、対応するＰＣＣルールをＰＣＥＦ３４内にインストールおよび構成することによって、このサービスのための適切なネットワークリソースの提供を制御することができる。ＴＤＦ３６、３６’は、独立型ノードとして実装することができるか、または、別のネットワークノードに組み込まれることができる。示されているＰＣＣアーキテクチャにおいて、ＴＤＦ３６’は、たとえば、検査されているデータパケット内のユニフォーム・リソース・ロケータ（ＵＲＬ）または情報資源識別子（ＵＲＩ）に基づいて、使用されているネットワークリソースをトラッキングすることによって、さらに、携帯電話ネットワークを通じて転送されているトラフィック上の情報を収集するためのプローブとして機能すると仮定されている。
【００３４】
図２にさらに示されるように、ＰＣＣアーキテクチャのノードはＧｘ、Ｇｘｘ、Ｇｙ、Ｇｚ、Ｓｄ、Ｓｐ、Ｓｙ、およびＲｘと称されるインターフェースまたは基準点によって互いに結合されている。Ｇｘ基準点はＰＣＲＦ３０とＧＷ２６との間に存在し、ＰＣＲＦ３０とＰＣＥＦ３４との間の通信を可能にする。Ｇｘｘ基準点はＰＣＲＦ３０とＢＢＥＲＦ３９との間に存在する。Ｇｙ基準点はＧＷ２６とＯＣＳ４４との間に存在する。Ｇｚ基準点はＧＷ２６とＯＦＣＳ４２との間に存在する。Ｒｘ基準点はＡＦ５０とＰＣＲＦ３０との間に存在する。さらにＲｘ基準点は、ＴＤＦ３６’とＰＣＲＦ３０との間のインターフェースを実装するのにも使用される。したがって、ＴＤＦ３６’は、ＰＣＲＦ３０と通信しているときはＡＦとして機能してもよい。Ｓｄ基準点はＴＤＦ３６とＰＣＲＦ３０との間に存在する。Ｓｐ基準点は加入者データベース３８とＰＣＲＦ３０との間に存在する。Ｓｙ基準点はＯＣＳ４２とＰＣＲＦ３０との間に存在する。これらのインターフェースおよびプロトコルの実装に関する詳細は、３ＧＰＰ  ＴＳ、たとえば、３ＧＰＰ  ＴＳ  ２３．２０３、２９．２１２、２９．２１３、および２９．２１４に見ることができる。図２のＰＣＣアーキテクチャは、本発明の実施形態の実施態様に含まれてもよい例示的な要素を示すように意図されていること、しかし、他の要素も本発明の実施形態の実施態様に含まれ得ることは理解されたい。たとえば、図２のＰＣＣアーキテクチャは、ＰＣＲＦ３０にインターフェースされているノードおよびそれぞれのインターフェースに関して変更され得る。たとえば、加入者データベース３８はＵＤＲとして実装され得、加入者データベース３８のＰＣＲＦ３０に対するインターフェースは、Ｕｄ基準点によって実装され得る。また、ＰＣＣアーキテクチャは、ローミングしているユーザが使用することになるＶ−ＰＣＲＦ（訪問先ＰＣＲＦ）を含み得、ＰＣＲＦ３０は、たとえば、Ｓ９基準点によって実装される、Ｖ−ＰＣＲＦに対するインターフェースを設けられ得る。さらに、複数インスタンスのいくつかのノード、たとえば、複数のＧＷおよび対応するＰＣＥＦ、複数のＢＢＥＲＦ、追加のＴＤＦ、または複数のＡＦが設けられてもよいことは理解されたい。
【００３５】
本明細書に記載のようなメカニズムを使用して、ＡＦ５０またはＴＤＦ３６’はＰＣＲＦ３０に認可要求を送り得る。認可要求は、３ＧＰＰ  ＴＳ  ２９．２１４において指定されているようなＡＡ要求（ＡＡＲ）コマンドであってもよい。ＰＣＲＦ３０において、この認可要求は、認可ステータスを示す認証応答、たとえば、３ＧＰＰ  ＴＳ  ２９．２１４において定義されているようなＡＡ回答（ＡＡＡ）コマンドの送信をトリガするだけでなく、認可ステータスモニタ３２の動作もトリガしてもよい。認可ステータスモニタ３２は、認可ステータスが変化したか否かを判定するための１つまたは複数のさらなる認可検査を実行し、認可要求の受信元であったノード、すなわち、ＡＦ５０またはＴＤＦ３６’にそのような変化を示し得る。認可ステータスの変化はたとえば、たとえば対応する特定アクション属性値ペア（特定アクションＡＶＰ）内の、３ＧＰＰ  ＴＳ  ２９．２１４において定義されているような再認可要求（ＲＡＲ）コマンドによって示されてもよい。状況によっては、空ＲＡＲコマンド、すなわち、特定アクションＡＶＰを一切有しないＲＡＲコマンドも、認可ステータスの変化を示すのに使用されてもよい。
【００３６】
ＡＦ５０またはＴＤＦ３６’は、認可要求において、たとえば、対応する特定アクションＡＶＰを使用することによって、認可ステータスの変化について通知されるべきであることを示すことができる。言い換えると、ＡＦ５０またはＴＤＦ３６’は、認可ステータスの変化について通知されることに同意してもよい。状況によっては、たとえば、ＡＦ５０またはＴＤＦ３６’の挙動がＰＣＲＦ３０に知られている場合、そのような同意はまた省略されてもよい。たとえば、ＴＤＦ３６’の既知の挙動に基づいて、ＰＣＲＦ３０は、ＴＤＦ３６’が常に認可ステータスの変化について通知される必要があるものと仮定し得る。
【００３７】
図３は、サービスに対する認可要求をハンドリングするためのメカニズムを使用する例示的なシナリオを示すためのシグナリング図を示す。図３の状況において、サービスは最初認可されておらず、後の時点において認可されるようになる。図３のシナリオは、ＵＥ１０、ＰＣＥＦ３４、ＰＣＲＦ３０、ＳＰＲ３８または他のタイプの加入者データベース、および、ＡＦ５０またはＴＤＦ３６’であってもよいノード８０を含む。
【００３８】
ステップ３０１において、たとえば、ＵＥ１０によってサービスセッションが開始される。セッションの開始は、ＵＥ１０とノード８０との間のシグナリングを含んでもよい。サービスセッションのデータを転送するためのリソースは、ＰＣＥＦ３４を通じてＰＣＲＦ３０によって制御される。この目的のために、ノード８０は、ＰＣＲＦ３０に認可要求３０２を送る。認可要求３０２によって、ノード８０とＰＣＲＦ３０との間の制御セッションが開始する。上述のように、認可要求はＡＡＲコマンドであってもよい。認可要求３０２は、認証されるべきサービスの記述を含んでもよい。さらに、認可要求３０２は、ノード８０が、たとえば、対応する特定アクションＡＶＰ内で、サービスまたはその構成要素の現在の認可ステータスだけでなく、認可ステータスの将来の変化に関しても通知されるべきであるという指示を含んでもよい。
【００３９】
メッセージ３０３、３０４によって示されるように、その後、ＰＣＲＦ３０は、加入データを受信するためにＳＰＲ３８と対話し得る。
【００４０】
ステップ３０５において、ＰＣＲＦ３０は、サービスの認可ステータスを判定するために認可検査を実行する。認可検査は、ＳＰＲ３８から受信されるような加入データに基づいて実行されてもよい。代替的に、または加えて、認可検査は、ＰＣＲＦ３０にとって利用可能またはアクセス可能な他のデータ、たとえば、ＩＰ接続アクセスネットワーク（ＩＰ−ＣＡＮ）のタイプ、ＵＥ１０によって使用される無線アクセス技術（ＲＡＴ）のタイプ、利用可能なクオータ、時刻ポリシーまたは曜日ポリシーのような時間関連ポリシーなどを考慮してもよい。図３の状況において、この認可検査の結果は、サービスが一時的に認可されていないというものであると仮定される。たとえば、サービスは、ＵＥ１０が別のオペレータのネットワークにおいてローミングしていることに起因して、サービスの使用が許可されていない時刻であることに起因して、または、このサービスに利用可能なクオータが使用の上限に達していることに起因して、許可されていない可能性がある。
【００４１】
ノード８０に認証応答３０６を送ることによって、ＰＣＲＦ３０は、ノード８０に、ステップ３０５において判定された認可ステータスを示す。図３の状況において、これは、サービスが一時的に認可されていないことを認証応答３０６が示していることを意味する。認証応答３０６はＡＡＡコマンドであってもよい。認可の欠如が一時的であることに起因して、ノード８０とＰＣＲＦ３０との間の制御セッションはアクティブなままにされる、すなわち、ステップ３０５における認可検査の結果に起因して、ノード８０およびＰＣＲＦ３０のいずれも制御セッションを終了しない。ステップ３０５の認可検査においてサービスのすべての構成要素が認可されていないと分かったわけではない場合、認証応答は、認可されていない１つまたは複数の構成要素も示し得る。これらの構成要素は、たとえば、データフローに関して示されてもよい。そのような構成要素の例は、マルチメディアサービス、たとえば、ビデオ会議サービスのビデオ構成要素およびオーディオ構成要素である。後者の例において、ステップ３０５における認可検査の結果は、ビデオ構成要素は認可されていないが、オーディオ構成要素は認可されていることであり得る。
【００４２】
ノード８０は認証応答３０６を受信し、それに応じてその活動を制御する。特に、認証応答３０６は、サービスまたはその構成要素が一時的に認可されていないことを示すため、ステップ３０７によって示されるように、ノード８０は、サービスセッションに関する、または、サービスセッションの任意の認可されていない構成要素に関するその活動を停止してもよい。たとえば、ノード８０は、ＰＣＲＦ３０に、サービスセッションに対するさらなる認可要求を送らない場合がある。ノード８０はまた、サービスに関するユーザ活動をモニタリングするためのタイマを停止してもよい。さらに、ノード８０がＴＤＦ３６’に対応する場合、ノード８０は、サービスセッションのデータトラフィックのモニタリングを停止してもよい。しかしながら、ノード８０はノード８０とＰＣＲＦ３０との間のサービスセッションを終了せず、むしろ、認可ステータスが変化するのを待つ。サービスのすべての構成要素が認可されていないわけではない場合、ノード８０は、たとえば、ＰＣＲＦ３０と対話することによって、認可されている構成要素に関してその活動を継続してもよい。ＰＣＲＦ３０は、このとき、たとえば、対応するＰＣＣルールをＰＣＥＦ３４内にインストールすることによって、認可されている構成要素のデータパケットを搬送するためのリソースを制御することができる。
【００４３】
メッセージ３０８、３０９によって示されるように、ＰＣＲＦ３０は、加入データを受信して、ステップ３１０において、サービスの認可ステータスが変化したか否かを判定するためにさらなる認可検査を実行するために、ＳＰＲ３８とさらに対話してもよい。さらなる認可検査はステップ３０５の認可検査と同様のデータに基づいてもよいが、ステップ３０５の認可検査以降に発生した可能性のある条件の変化、たとえば、ローミング状況の変化またはクオータの再充填を考慮する。図３の状況において、ステップ３１０におけるさらなる認可検査の結果は、サービスまたは以前認可されなかったその構成要素が今回は認可されたというものであると仮定される。
【００４４】
ノード８０にステータス変化メッセージ３１１を送ることによって、ＰＣＲＦ３０は、ノード８０に、ステップ３１０において判定された認可ステータスの変化を示す。ステータス変化メッセージ３１１はＲＡＲコマンドであってもよく、認可ステータスの変化は、対応する特定アクションＡＶＰにおいて示されてもよい。状況によっては、ステータス変化メッセージ３１１はまた、空ＲＡＲコマンドであってもよい。ノード８０は、たとえば、３ＧＰＰ  ＴＳ  ２９．２１４による再認証回答（ＲＡＡ）コマンドの形態の肯定応答メッセージ３１２を送ることによって、ステータス変化メッセージ３１１に応答してもよい。認可ステータスの変化がサービスのすべての構成要素に適用されるわけではない場合、ステータス変化メッセージ３１１はまた、たとえば、データフローに関して、ステータス変化メッセージが関係する構成要素を示してもよい。
【００４５】
ノード８０は、ＰＣＲＦ３０から受信されるステータス変化メッセージによって示される認可ステータスの変化に基づいて、その活動を制御する。特に、ステップ３１３によって示されるように、ノード８０は、サービスセッションに関する、または、もはや不認可ではないサービスセッションの構成要素に関するその活動を再開してもよい。たとえば、ノード８０は、ユーザ静止タイマを始動してもよい。ノード８０は、ＴＤＦ３６’に対応する場合、サービスのデータトラフィックのモニタリングを継続してもよい。さらに、ノード８０は、ＰＣＲＦ３０に、サービスに対する認可要求３１４を再び送ってもよい。
【００４６】
認可要求３１４の受信に応答して、ＰＣＲＦ３０は、加入データを受信して、ステップ３１７において、サービスの認可ステータスを判定するためにまたさらなる認可検査を実行するために、ＳＰＲ３８と再び対話してもよい。ステップ３１７の認可検査は、ステップ３０５および３１０の認可検査と同様のデータに基づいてもよい。図３の状況において、ステップ３１７における認可検査の結果は、ステップ３１０の認可検査を裏付ける、サービスが認可されたというものであると仮定される。このとき、ＰＣＲＦ３０は、ノード８０に認証応答３１８を送ることによって、ノード８０に認可検査の結果を示す。図３の状況において、これは、サービスが認可されていることを認証応答３１８が示していることを意味する。認証応答３１８はＡＡＡコマンドであってもよい。
【００４７】
ステップ３１９によって示されるように、その後、サービスセッションは、ＰＣＲＦ３０による、たとえば、適切なＰＣＣルールをＰＣＥＦ３４内にインストールすることによる、サービスセッションのデータパケットを搬送するためのリソースの制御に進んでもよい。
【００４８】
図４は、サービスに対する認可要求をハンドリングするためのメカニズムを使用するさらなる例示的なシナリオを示すためのシグナリング図を示す。図４の状況において、サービスは最初認可されているが、後の時点において一時的に認可されなくなる。図４のシナリオは、ＵＥ１０、ＰＣＥＦ３４、ＰＣＲＦ３０、ＳＰＲ３８、および、ＡＦ５０またはＴＤＦ３６’であってもよいノード８０を含む。
【００４９】
ステップ４０１において、たとえば、ＵＥ１０によってサービスセッションが開始される。セッションの開始は、ＵＥ１０とノード８０との間のシグナリングを含んでもよい。サービスセッションのデータを転送するためのリソースは、ＰＣＥＦ３４を通じてＰＣＲＦ３０によって制御される。この目的のために、ノード８０は、ＰＣＲＦ３０に認可要求４０２を送る。認可要求４０２によって、ノード８０とＰＣＲＦ３０との間の制御セッションが開始する。上述のように、認可要求はＡＡＲコマンドであってもよい。認可要求４０２は、認可されるべきサービスの記述を含んでもよい。さらに、認可要求４０２は、ノード８０が、たとえば、対応する特定アクションＡＶＰ内で、サービスまたはその構成要素の現在の認可ステータスだけでなく、認可ステータスの将来の変化に関しても通知されるべきであるという指示を含んでもよい。
【００５０】
メッセージ４０３、４０４によって示されるように、その後、ＰＣＲＦ３０は、加入データを受信するためにＳＰＲ３８と対話し得る。
【００５１】
ステップ４０５において、ＰＣＲＦ３０は、サービスの認可ステータスを判定するために認可検査を実行する。認可検査は、ＳＰＲ３８から受信されるような加入データに基づいて実行されてもよい。代替的に、または加えて、認可検査は、ＰＣＲＦ３０にとって利用可能またはアクセス可能な他のデータ、たとえば、ＩＰ接続アクセスネットワーク（ＩＰ−ＣＡＮ）のタイプ、ＵＥ１０によって使用される無線アクセス技術（ＲＡＴ）のタイプ、利用可能なクオータ、時刻ポリシーまたは曜日ポリシーのような時間関連ポリシーなどを考慮してもよい。図４の状況において、この認可検査の結果は、サービスが認可されているというものであると仮定される。
【００５２】
ノード８０に認証応答４０６を送ることによって、ＰＣＲＦ３０は、ノード８０に、ステップ４０５において判定された認可ステータスを示す。図４の状況において、これは、サービスが認可されていることを認証応答４０６が示していることを意味する。認証応答４０６はＡＡＡコマンドであってもよい。
【００５３】
ステップ４０７によって示されるように、ＰＣＲＦ３０は、このとき、たとえば、対応するＰＣＣルールをＰＣＥＦ３４内にインストールすることによって、サービスセッションのデータフローを搬送するためのリソースを制御することができる。ノード８０は、認証応答４０６によって示される認可ステータスに基づいて、その活動を制御する。特に、認証応答４０６は、サービスが認可されていることを示すため、ステップ４０８によって示されるように、ノード８０は、サービスセッションに関するその活動を継続してもよい。たとえば、ノード８０は、ユーザ活動をモニタリングするためのタイマを始動してもよい。ノード８０は、ＴＤＦ３６’に対応する場合、サービスのデータトラフィックのモニタリングを継続してもよい。さらに、ノード８０は、たとえば、ＰＣＲＦ３０に、サービス情報を更新することに対する認可要求を送ることによって、ＰＣＲＦ３０と再び対話してもよい。
【００５４】
メッセージ４０９、４１０によって示されるように、ＰＣＲＦ３０は、加入データを受信して、ステップ４１１において、サービスの認可ステータスが変化したか否かを判定するためにさらなる認可検査を実行するために、ＳＰＲ３８とさらに対話してもよい。さらなる認可検査はステップ４０５の認可検査と同様のデータに基づいてもよいが、ステップ４０５の認可検査以降に発生した可能性のある条件の変化、たとえば、ローミング状況の変化またはクオータの可用性の変化を考慮する。図４の状況において、ステップ４１１におけるさらなる認可検査の結果は、サービスまたはその構成要素が一時的に認可されないというものであると仮定される。たとえば、サービスは、ＵＥ１０が別のオペレータのネットワークにおいてローミングしていることに起因して、サービスの使用が許可されていない時刻であることに起因して、または、このサービスに利用可能なクオータが使用の上限に達していることに起因して、許可されていない可能性がある。
【００５５】
ノード８０にステータス変化メッセージ４１２を送ることによって、ＰＣＲＦ３０は、ノード８０に、ステップ４１１において判定された認可ステータスの変化を示す。ステータス変化メッセージ４１１はＲＡＲコマンドであってもよく、認可ステータスの変化は、対応する特定アクションＡＶＰにおいて示されてもよい。状況によっては、ステータス変化メッセージ４１１はまた、空ＲＡＲコマンドであってもよい。ノード８０は、たとえば、ＲＡＡコマンドの形態の肯定応答メッセージ４１２を送ることによって、ステータス変化メッセージ４１１に応答してもよい。認可ステータスの変化がサービスのすべての構成要素に適用されるわけではない場合、ステータス変化メッセージ４１１はまた、たとえば、データフローに関して、ステータス変化が関係する構成要素を示してもよい。そのような構成要素の例は、マルチメディアサービス、たとえば、ビデオ会議サービスのビデオ構成要素およびオーディオ構成要素である。後者の例において、ステップ４１１における認可検査の結果は、ビデオ構成要素は認可されていないが、オーディオ構成要素は認可されていることであり得る。
【００５６】
ノード８０は、受信されるステータス変化メッセージ４１１によって示される認可ステータスの変化に従って、その活動を制御する。特に、ステータス変化メッセージ４１１は、サービスまたはその構成要素が一時的に認可されていないことを示すため、ステップ４１３によって示されるように、ノード８０は、サービスセッションに関する、または、サービスセッションの認可されていない構成要素に関するその活動を停止してもよい。たとえば、ノード８０は、ＰＣＲＦ３０に、サービスセッションに対するさらなる認可要求を送らない場合がある。ノード８０はまた、サービスに関するユーザ活動をモニタリングするためのタイマを停止してもよい。さらに、ノード８０がＴＤＦ３６’に対応する場合、ノード８０は、サービスセッションのデータトラフィックのモニタリングを停止してもよい。しかしながら、ノード８０はノード８０とＰＣＲＦ３０との間の制御セッションを終了せず、むしろ、認可ステータスがさらに変化するのを待つ。サービスのすべての構成要素が認可されていないわけではない場合、ノード８０は、たとえば、ＰＣＲＦ３０と対話することによって、認可されている構成要素に関してその活動を継続してもよい。ＰＣＲＦ３０は、このとき、たとえば、対応するＰＣＣルールをＰＣＥＦ３４内にインストールすることによって、認可されている構成要素のデータフローを搬送するためのリソースを制御することができる。
【００５７】
メッセージ４１５、４１６によって示されるように、ＰＣＲＦ３０は、加入データを受信して、ステップ４１７において、サービスの認可ステータスが再び変化したか否かを判定するためにまたさらなる認可検査を実行するために、ＳＰＲ３８とさらに対話してもよい。さらなる認可検査はステップ４０５および４１１の認可検査と同様のデータに基づいてもよいが、ステップ４１１の認可検査以降に発生した可能性のある条件の変化を考慮する。図４の状況において、ステップ４１７における認可検査の結果は、サービスまたは認可されなかったその構成要素が再び認可されたというものであると仮定される。
【００５８】
ノード８０にステータス変化メッセージ４１８を送ることによって、ＰＣＲＦ３０は、ノード８０に、ステップ４１７において判定された認可ステータスの変化を示す。ステータス変化メッセージ４１８はＲＡＲコマンドであってもよく、認可ステータスの変化は、対応する特定アクションＡＶＰにおいて示されてもよい。状況によっては、ステータス変化メッセージ４１８はまた、空ＲＡＲコマンドであってもよい。ノード８０は、たとえば、ＲＡＡコマンドの形態の肯定応答メッセージ４１９を送ることによって、ステータス変化メッセージ４１８に応答してもよい。認可ステータスの変化がサービスのすべての構成要素に適用されるわけではない場合、ステータス変化メッセージ４１８はまた、たとえば、データフローに関して、ステータス変化が関係する構成要素を示してもよい。
【００５９】
ノード８０は、ステータス変化メッセージ４１８によって示される認可ステータスの変化に基づいて、その動作を制御する。特に、ステップ４２０によって示されるように、ノード８０は、サービスセッションに関するその活動を再開してもよい。たとえば、ノード８０は、ユーザ活動をモニタリングするためのタイマを再始動してもよい。ノード８０は、ＴＤＦ３６’に対応する場合、サービスのデータトラフィックのモニタリングを継続してもよい。さらに、ノード８０は、たとえば、ＰＣＲＦ３０に、サービス情報を更新することに対する認可要求を送ることによって、ＰＣＲＦ３０と再び対話してもよい。
【００６０】
図４の例から分かるように、サービスが一時的に認可されなくなるにもかかわらず、ノード８０とＰＣＲＦ３０との間の制御セッションはアクティブなままにされる、すなわち、ノード８０およびＰＣＲＦ３０のいずれも、認可されなくなっていることを示す、ステップ４１１においてＰＣＲＦ３０によって実行される認可検査に応答して制御セッションを終了しない。
【００６１】
状況によっては、図３および図４に関連して説明されているような手順は単純化されてもよい。特に、ＰＣＲＦ３０がノード８０の挙動についてアウェアである場合、ノード８０が認可ステータスの将来の変化について通知されるべきであるという指示は、認可要求３０２、４０２において提供される必要はない。むしろ、ＰＣＲＦ３０は、ノード８０の挙動のその知識に基づいて、ノード８０が認可ステータスの将来の変化について通知されるべきであると仮定することができる。そのような状況においては、たとえば、ノード８０によって認可ステータスの変化の指示として解釈される空ＲＡＲコマンドを使用することによって、ステータス変化メッセージも単純化されてもよい。単純化された手順は、たとえば、ノード８０がＴＤＦ３６’に対応する場合に使用されてもよい。
【００６２】
図４および図５のプロセスにおいて、ＰＣＲＦ３０とＳＰＲ３８との間の対話は様々な様式で行われてもよいことは理解されたい。たとえば、シグナリング図に示すように、ＰＣＲＦ３０は、ＳＰＲ３８に要求を送り、要求に応答して加入データを受信してもよい。代替的に、ＳＰＲ３８は、たとえば、そのような明確な要求なしに、たとえば、加入データの変化に応答してＰＣＲＦ３０に加入データを提供してもよい。さらに、認可検査は各々、ＰＣＥＦ３４が特定のイベント、たとえば、訪問先ネットワークの変化または所在の変化を検出することのような、様々なタイプのイベントによってトリガされてもよい。
【００６３】
図５は、上記のサービス認証の概念を実装するのに使用されてもよいポリシーコントローラ３０を概略的に示す。特に、ポリシーコントローラ３０は、３ＧＰＰ  ＴＳによるＰＣＲＦとして実装されてもよい。この場合、サービスの認可は、Ｒｘインターフェースを介したポリシーコントローラ３０とノードとの間の対話を含んでもよい。
【００６４】
示されている例において、ポリシーコントローラ３０は、１つまたは複数のノード、たとえば、ＡＦ５０またはＴＤＦ３６’と通信するためのノードインターフェース１２０を含む。加えて、ポリシーコントローラ３０は、たとえば、データを搬送するためのリソースを制御するための制御インターフェース１４０を含んでもよい。図２に示すような３ＧＰＰ  ＰＣＣアーキテクチャにおいて、ノードインターフェース１２０はＲｘインターフェースに対応してもよく、制御インターフェース１４０はＧｘインターフェースおよび／またはＧｘｘインターフェースに対応してもよい。ノードインターフェース１２０は、たとえば、サービスセッションの認証に使用されてもよい。制御インターフェース１４０は、このとき、認可されたサービスセッションの、または、認可されたその構成要素のデータを搬送するためのリソースを制御するのに使用されてもよい。さらに示されるように、ポリシーコントローラ３０は、加入者データベース、たとえば、図１および図２の加入者データベース３８と対話するためのデータベースインターフェース１３０をも含んでもよい。
【００６５】
さらに、ノードは、インターフェース１２０、１３０、１４０に結合されているプロセッサ１５０と、プロセッサ１５０に結合されているメモリ１６０とを含む。メモリ１６０は、読み出し専用メモリ（ＲＯＭ）、たとえば、フラッシュＲＯＭ、ランダムアクセスメモリ（ＲＡＭ）、たとえば、ダイナミックＲＡＭ（ＤＲＡＭ）またはスタティックＲＡＭ（ＳＲＡＭ）、大容量記憶装置、たとえば、ハードディスクまたはソリッド・ステート・ディスクなどを含んでもよい。メモリ１６０は、プロセッサ１５０によって、図１〜図４に関連して説明されたようなポリシーコントローラ３０の機能を実装するように実行されるように適切に構成されたプログラムコードを含む。より具体的には、メモリ１６０は、認可検査を実行し、受信された認可要求をハンドリングする上述の機能を実装するように、認証制御モジュール１７０を含んでもよい。さらに、メモリ１６０は、１つまたは複数のさらなる認可検査を実行し、認可ステータスの変化を報告することによって、認可ステータスをモニタリングする上述の機能を実装するように、ステータス・モニタリング・モジュールをも含んでもよい。
【００６６】
図５に示すような構造は概略に過ぎないこと、および、ポリシーコントローラ３０は実際には、明瞭にするために示されていないさらなる構成要素を含んでもよいことは理解されたい。また、メモリ１６０は、示されていないさらなるタイプのプログラム・コード・モジュール、たとえば、ポリシーコントローラの既知の機能、たとえば、ポリシー決定機能などを実装するためのプログラム・コード・モジュールを含んでもよいことは理解されたい。いくつかの実施形態によれば、たとえば、メモリ１６０内に記憶されるべきプログラムコードを記憶している媒体の形態の、ノードの機能を実装するためのコンピュータプログラム製品も提供されてもよい。
【００６７】
図６は、上記のサービス認証の概念を実装するのに使用されてもよいノード８０を概略的に示す。特に、ノード８０は、たとえば、上述のＲｘインターフェースを使用して、３ＧＰＰ  ＴＳによるＰＣＲＦと対話するように構成されてもよい。ノード８０は、たとえば、ＡＦ、または、ＰＣＲＦと対話するためにＲｘインターフェースを使用する別のノード、たとえば、ＴＤＦ３６’に対応してもよい。
【００６８】
示されている例において、ノード８０は、通信ネットワークのポリシーコントローラ、たとえば、ポリシーコントローラ３０と通信するための制御インターフェース２４０を含む。加えて、ノード８０は、たとえば、ＵＥ、たとえばＵＥ１０に関するデータを送信するためのアプリケーションインターフェース２３０を含んでもよい。図２に示すような３ＧＰＰ  ＰＣＣアーキテクチャにおいて、制御インターフェース２４０は、Ｒｘインターフェースに対応してもよい。アプリケーションインターフェース２３０は概して、ＩＰベースであってもよく、様々なタイプのサービス特有またはアプリケーション特有のプロトコル、たとえば、セッション開始プロトコル（ＳＩＰ）をさらにサポートしてもよい。制御インターフェース２４０は、たとえば、通信ネットワーク内のサービスを認証するのに使用されてもよい。
【００６９】
さらに、ノード８０は、インターフェース２４０、２３０に結合されているプロセッサ２５０と、プロセッサ２５０に結合されているメモリ２６０とを含む。メモリ２６０は、読み出し専用メモリ（ＲＯＭ）、たとえば、フラッシュＲＯＭ、ランダムアクセスメモリ（ＲＡＭ）、たとえば、ダイナミックＲＡＭ（ＤＲＡＭ）またはスタティックＲＡＭ（ＳＲＡＭ）、大容量記憶装置、たとえば、ハードディスクまたはソリッド・ステート・ディスクなどを含んでもよい。メモリ２６０は、サービスに対する認可要求を送ることによってポリシーコントローラと対話するノードの上述の機能、たとえば、ＡＦ５０またはＴＤＦ３６’であってもよい、図３および図４のノード８０の機能を実装するようにプロセッサ２５０によって実行されるように適切に構成されたプログラムコードを含む。より具体的には、メモリ２６０は、サービスに対する認可要求を生成および送信をハンドリングし、それに対する応答、たとえば、上述のような認証応答および後続のステータス変化メッセージをハンドリングするための認証制御モジュール２７０を含んでもよい。さらに、メモリ２６０はまた、受信された認証応答および後続のステータス変化メッセージに基づいてノード８０の動作を制御するための活動制御モジュール２８０であってもよい。
【００７０】
図６に示すような構造は概略に過ぎないこと、および、ノード８０は実際には、明瞭にするために示されていないさらなる構成要素を含んでもよいことは理解されたい。また、メモリ２６０は、示されていないさらなるタイプのプログラム・コード・モジュール、たとえば、特定のアプリケーションまたはサービスの機能を実装するためのプログラム・コード・モジュールを含んでもよいことは理解されたい。いくつかの実施形態によれば、たとえば、メモリ２６０内に記憶されるべきプログラムコードを記憶している媒体の形態の、ノードの機能を実装するためのコンピュータプログラム製品も提供されてもよい。
【００７１】
図７は、サービスに対する認可要求をハンドリングするための方法を示すための流れ図を示す。本方法は、携帯電話ネットワークのポリシーコントローラにおいて上述の概念を実装するのに使用されてもよい。特に、本方法は、上述のポリシーコントローラ３０によって実施されてもよい。
【００７２】
ステップ７１０において、ポリシーコントローラは、ノードから認可要求を受信する。ノードは、たとえば、ＡＦであってもよく、または、ポリシーコントローラとの通信においてＡＦとして機能してもよい。図２に示すようなＰＣＣアーキテクチャにおいて、これは、認可要求がＲｘインターフェースを介して受信されることを意味する。認可要求の例は、図３の認可要求３０２および図４の認可要求４０２である。認可要求は、ノードが、サービスの現在の認可ステータスだけでなく、認可ステータスの将来の変化が発生するときに、その変化に関しても通知されるべきであるという指示を含んでもよい。指示は、たとえば、認可要求内の対応するＡＶＰであってもよい。状況によっては、ポリシーコントローラは、ノードの挙動についてアウェアであってもよく、この知識に基づいて、ノードが認可ステータスの将来の変化について通知されるべきであると仮定してもよい。
【００７３】
ステップ７２０において、ポリシーコントローラは、サービスの認可ステータスを判定するために認可検査を実行する。この目的のために、ポリシーコントローラは、加入データに基づいて認可検査を実行することができるように、加入者データベースから加入データをも受信してもよい。認可検査は、付加的にまたは代替的に、ポリシーコントローラにおいて利用可能な、またはポリシーコントローラにとってアクセス可能な他の情報に基づいて実行されてもよい。
【００７４】
ステップ７３０において、ポリシーコントローラは、ノードに認証応答を送る。認証応答は、ステップ７２０において判定されたものとしてのセッションの認可ステータスを示す。認証応答の例は、図３の認証応答３０６および図４の認証応答４０６である。図３の状況のような場合は、認証応答は、サービスが一時的に認可されていないことを示してもよい。認証応答は、たとえば、パケットフローに関して、認可されていないサービスの構成要素も示してもよい。図４の状況のような場合は、認証応答は、サービスが認可されていることを示してもよい。
【００７５】
ステップ７４０において、ポリシーコントローラは、サービスの認可ステータスを判定し直すためにさらなる認可検査を実行する。ステップ７２０の認可検査と同様に、さらなる認可検査はステップ７１０の認可要求に応答して実行され、加入者データベースから受信される加入データに基づいてもよい。さらなる認可検査は、付加的にまたは代替的に、ポリシーコントローラにおいて利用可能な、またはポリシーコントローラにとってアクセス可能な他の情報に基づいて実行されてもよい。ステップ７５０は、サービスの認可ステータスが変化したことをステップ７４０のさらなる認可検査が示すか否かの判定に対応する。認可ステータスの変化がない場合、分岐「いいえ」によって示されるように、方法はステップ７４０に戻って、さらなる認可検査を繰り返すことができる。
【００７６】
認可ステータスが変化したことをステップ７５０の判定が示す場合、分岐「はい」によって示されるように、方法はステップ７６０に進む。ステップ７６０において、ポリシーコントローラは、ノードにメッセージを送る。メッセージは、サービスの認可ステータスが変化したことを示し、それゆえ、ステータス変化メッセージとも称される場合がある。メッセージの例は、図３のステータス変化メッセージ３１１および図４のステータス変化メッセージ４１２である。
【００７７】
図８は、サービスに対する認可要求をハンドリングするためのさらなる方法を示すための流れ図を示す。本方法は、通信ネットワークのポリシーコントローラと対話しているノードにおいて上述の概念を実装するのに使用されてもよい。特に、本方法は、ＡＦ、たとえば、ＡＦ５０、または、ＴＤＦ３６’のような、ポリシーコントローラに対してＡＦとして機能するノードによって実施されてもよい。
【００７８】
ステップ８１０において、ノードは、ポリシーコントローラに認可要求を送る。図２に示すようなＰＣＣアーキテクチャにおいて、認可要求は、Ｒｘインターフェースを介して送られてもよい。認可要求の例は、図３の認可要求３０２および図４の認可要求４０２である。認可要求は、ノードが、サービスの現在の認可ステータスだけでなく、認可ステータスの将来の変化が発生するときに、その変化に関しても通知されるべきであるという指示を含んでもよい。指示は、たとえば、認可要求内の対応するＡＶＰであってもよい。
【００７９】
ステップ８２０において、ノードは、ポリシーコントローラから認証応答を受信する。認証応答は、ポリシーコントローラによって実行された認可検査において判定されたものとしてのサービスの認可ステータスを示す。認証応答の例は、図３の認証応答３０６および図４の認証応答４０６である。図３の状況のような場合は、認証応答は、サービスが一時的に認可されていないことを示してもよい。認証応答は、たとえば、パケットフローに関して、認可されていないサービスの構成要素も示してもよい。図４の状況のような場合は、認証応答は、サービスが認可されていることを示してもよい。
【００８０】
ステップ８３０において、ノードは、認証応答によって示される認可ステータスに応じて、サービスに関するその活動を制御する。たとえば、サービスが一時的に認可されていないことを認証応答が示す場合、ノードは認可要求を再送信せず、または同じサービスに対するさらなる認可要求を送らないようにしてもよい。さらに、ノードは、たとえば、サービスに関係するユーザ活動をモニタリングするためのタイマを停止すること、または、サービスのデータトラフィックをモニタリングすることを停止することによって、認可されていないサービスまたはサービスの構成要素に関する少なくとも１つの活動またはすべてのその活動を停止してもよい。サービスが認可されていることを認証応答が示す場合、ノードは、たとえば、ユーザの活動をモニタリングするためのタイマを始動すること、または、サービスのデータトラフィックのモニタリングを開始することによって、サービスに関するその活動を通常通り継続してもよい。
【００８１】
ステップ８４０において、ノードは、ポリシーコントローラからメッセージを受信する。メッセージは、サービスの認可ステータスが変化したことを示し、それゆえ、ステータス変化メッセージとも称される場合がある。メッセージの例は、図３のステータス変化メッセージ３１１および図４のステータス変化メッセージ４１２である。メッセージは、ポリシーコントローラによって実行されるさらなる認可検査に基づく。
【００８２】
ステップ８４０において、ノードは、ステップ８４０において受信されるメッセージおよびステップ８２０において受信される認証応答によって示される認可ステータスに応じて、サービスに関するその活動をさらに制御する。たとえば、サービスが一時的に認可されていないことを、ステップ８２０において受信された認証応答が示す場合、ノードはステップ８１０の認可要求を再送信し、またはそのサービスに対するさらなる認可要求を送ってもよい。さらに、ノードは、たとえば、ユーザ活動をモニタリングするためのタイマを始動すること、または、サービスのデータトラフィックをモニタリングすることを開始することによって、もはや不認可ではないサービスまたはサービスの構成要素に関する活動を再開してもよい。ステップ８２０において受信された認証応答が、サービスが認可されていることを示した場合、ノードは、ステップ８３０のメッセージの受信に応答して、たとえば、ポリシーコントローラに対する、このサービスに関する対話を停止することによって、このサービスのデータトラフィックのモニタリングを停止することによって、または、このサービスに関係するユーザ活動をモニタリングするタイマ形式を停止することによって、サービスに関する少なくとも１つの活動またはすべてのその活動を停止してもよい。活動は、図４のステータス変化メッセージ４１８のような、ポリシーコントローラからのさらなるステータス変化メッセージを受信するまで停止されてもよい。
【００８３】
図７および図８の方法は、必要に応じて互いと組み合わされてもよい。たとえば、ポリシーコントローラと、ポリシーコントローラと対話するノードを備えるシステムにおいて、図７の方法は、認可要求を受信し、認証応答を送るポリシーコントローラによって実施され得、図８の方法は、認可要求を送り、認証応答を受信するノードによって実施され得る。
【００８４】
見てとれるように、上記で説明したような概念は、サービスに対する認可要求を効率的にハンドリングすることを可能にする。特に、過剰な制御セッションシグナリングを回避し、および／または、認可要求を送るノードの動作を柔軟に制御するために、サービスの認可ステータスの変化を考慮に入れることができる。
【００８５】
上記で説明したような例および実施形態は例示に過ぎず、様々な変更を受けることは理解されたい。たとえば、本概念は、たとえば、上述のＰＣＲＦ以外の他のタイプのポリシーコントローラを使用して、他のタイプの携帯電話ネットワークにおいて使用され得る。また、図示および説明されているノード、たとえば、ＡＦ５０、ＴＤＦ３６’またはＰＣＲＦ３０は各々、単一のデバイスによって、または複数のデバイス、たとえば、相互接続されているデバイスから成るクラウドまたはサーバファームによって実装されてもよいことは理解されたい。さらに、上記の概念は、既存のネットワークデバイス内の対応して設計されたソフトウェアを使用することによって、または専用ネットワーク・デバイス・ハードウェアを使用することによって実装されてもよいことは理解されたい。
また、本発明は以下に記載する態様を含む。
（態様１）
携帯電話ネットワークにおいてパケットベースのサービスセッションに対する認可要求をハンドリングする方法であって、
ポリシーコントローラ（３０）が、ノード（８０）から前記認可要求を受信するステップと、
前記認可要求（３０２；４０２）の受信に応答して、
前記ポリシーコントローラ（３０）が、前記サービスセッションの認可ステータスを判定するために認可検査（３０５；４０５）を実行するステップと、
前記ポリシーコントローラ（３０）が、前記ノード（８０）に、前記サービスセッションの前記認可ステータスを示す認証応答（３０６；４０６）を送信するステップと、
前記ポリシーコントローラ（３０）が、前記サービスセッションの前記認可ステータスを判定し直すために少なくとも一回のさらなる認可検査（３１０；４１１）を実行するステップと、
前記サービスセッションの前記認可ステータスが変化したことを前記さらなる認可検査（３１０；４１１）が示す場合、前記ポリシーコントローラ（３０）が前記ノード（８０）に、前記サービスセッションの前記認可ステータスが変化したことを示すメッセージ（３１１；４１２）を送信するステップと
を含む、方法。
（態様２）
前記認証応答（３０６；４０６）は、前記サービスセッションが一時的に認可されていないことを示す、態様１に記載の方法。
（態様３）
前記認証応答（３０６）は、認可されていない前記サービスセッションの構成要素を示す、態様１または２に記載の方法。
（態様４）
前記ポリシーコントローラ（３０）が、前記サービスセッションのデータパケットを搬送するためのリソースを制御するステップを含む、態様１から３のいずれか一つに記載の方法。
（態様５）
前記ポリシーコントローラ（３０）が、前記携帯電話ネットワークの加入者データベース（３８）から加入データを受信するステップと、
前記ポリシーコントローラが、前記受信された加入データに基づいて、前記認可検査（３０５；４０５）および／または前記さらなる認可検査（３１０；４１１）を実行するステップと
を含む、態様１から４のいずれか一つに記載の方法。
（態様６）
前記認可要求（３０２；４０２）は、前記ノード（８０）が前記サービスセッションの前記認可ステータスが変化するか否かを通知されるべきであるという指示を含む、態様１から５のいずれか一つに記載の方法。
（態様７）
携帯電話ネットワークにおいてパケットベースのサービスに対する認可要求をハンドリングする方法であって、
ノード（８０）が、前記携帯電話ネットワークのポリシーコントローラ（３０）に前記認可要求（３０２；４０２）を送信するステップと、
前記ノード（８０）が、前記ポリシーコントローラ（３０）から、前記ポリシーコントローラ（３０）によって判定されるものとしての前記サービスの認可ステータスを示す認証応答（３０６；４０６）を受信するステップと、
前記ノード（８０）が、前記ポリシーコントローラ（３０）から、前記サービスの前記認可ステータスが変化したことを示すメッセージ（３１１；４１２）を受信するステップと、
前記ノード（８０）が、前記認証応答（３０６；４０６）によって示される前記認可ステータス、および、前記サービスの前記認可ステータスが変化したことを示す前記メッセージ（３１１；４１２）に応じて、前記サービスに関係するその動作を制御するステップと
を含む、方法。
（態様８）
前記認証応答（３０６）は、前記サービスが一時的に認可されていないことを示す、態様７に記載の方法。
（態様９）
前記認証応答（３０６）は、認可されていない前記サービスの構成要素を示す、態様７または８に記載の方法。
（態様１０）
前記認証応答（３０６）を受信した後、前記ノード（８０）が、前記サービスの認可された構成要素に関する少なくとも１つの活動を継続するステップを含む、態様９に記載の方法。
（態様１１）
前記サービスが一時的に認可されていないことを前記認証応答（３０６）が示す場合に、前記ノード（８０）が、前記サービスの前記認可ステータスが変化したことを示す前記メッセージ（３１１）が受信されるまで、前記サービスに対するさらなる認可要求を送信しないステップを含む、態様７から１０のいずれか一つに記載の方法。
（態様１２）
前記サービスが一時的に認可されていないことを前記認証応答（３０６）が示す場合に、前記ノード（８０）が、前記サービスの前記認可ステータスが変化したことを示す前記メッセージ（３１１）が受信されるまで、認可されていない前記サービスの構成要素に対する少なくとも１つの活動を停止するステップを含む、態様７から１１のいずれか一つに記載の方法。
（態様１３）
前記セッションが認可されていることを前記認証応答（４０６）が示す場合に、前記ノード（８０）が、前記セッションの前記認可ステータスが変化したことを示す前記メッセージ（４１２）の受信に応答して、前記サービスに関する少なくとも１つの活動を停止するステップを含む、態様７に記載の方法。
（態様１４）
前記認可要求（３０２；４０２）は、前記ノード（８０）が前記サービスの前記認可ステータスが変化するか否かを通知されるべきであるという指示を含む、態様７から１３のいずれか一つに記載の方法。
（態様１５）
携帯電話ネットワーク内のリソースを制御するためのポリシーコントローラ（３０）であって、
ノード（８０）と通信するためのインターフェース（１２０）と、
プロセッサ（１５０）とを備え、
前記プロセッサ（１５０）は、
前記インターフェース（１２０）を介して、前記携帯電話ネットワークにおいてパケットベースのサービスに対する認可要求（３０２；４０２）を受信し、
前記認可要求（３０２；４０２）の受信に応答して、
前記サービスの認可ステータスを判定するために認可検査（３０５；４０５）を実行し、
前記インターフェース（１２０）を介して前記ノード（８０）に、前記サービスの前記認可ステータスを示す認証応答（３０６；４０６）を送信し、
前記サービスの前記認可ステータスを判定し直すためにさらなる認可検査（３１０；４１１）を実行し、
前記サービスの前記認可ステータスが変化したことを前記さらなる認可検査（３１０；４１１）が示す場合、前記インターフェースを介して前記ノード（８０）に、前記サービスの前記認可ステータスが変化したことを示すメッセージ（３１１；４１２）を送信するように構成されている、ポリシーコントローラ（３０）。
（態様１６）
前記携帯電話ネットワークの加入者データベース（３８）と通信するためのさらなるインターフェース（１３０）を備え、
前記プロセッサ（１５０）が、前記加入者データベース（３８）から前記さらなるインターフェース（１３０）を介して加入データを受信し、前記受信された加入データに基づいて、前記認可検査（３０５；４０５）および／または前記さらなる認可検査（３１０；４１１）を実行するように構成されている、態様１５に記載のポリシーコントローラ（３０）。
（態様１７）
前記サービスのデータパケットを搬送するためのリソースを制御するための制御インターフェース（１４０）を備える、態様１５または１６に記載のポリシーコントローラ（３０）。
（態様１８）
前記プロセッサ（１５０）は、請求項１から６のいずれか一項に記載の方法によって定義される方法のステップを実行するように構成されている、態様１５から１７のいずれか一つに記載のポリシーコントローラ（３０）。
（態様１９）
ノード（８０）であって、
携帯電話ネットワークのポリシーコントローラ（３０）と通信するためのインターフェース（２４０）と、
プロセッサ（２５０）とを備え、
前記プロセッサ（２５０）は、
前記インターフェース（２４０）を介して前記ポリシーコントローラ（３０）に、前記携帯電話ネットワークにおいてパケットベースのサービスに対する認可要求（３０２；４０２）を送信し、
前記ポリシーコントローラ（３０）から前記インターフェース（２４０）を介して、前記ポリシーコントローラ（３０）によって判定されるものとしての前記サービスの認可ステータスを示す認証応答（３０６；４０６）を受信し、
前記ポリシーコントローラ（３０）から前記インターフェース（２４０）を介して、前記サービスの前記認可ステータスが変化したことを示すメッセージ（３１１；４１２）を受信し、
前記認証応答（３０６；４０６）および前記ステータス変化メッセージ（３１１；４１２）によって示される前記認可ステータスに応じて、前記サービスに関する前記ノード（８０）の動作を制御するように構成されている、ノード。
（態様２０）
前記プロセッサ（１５０）は、態様７から１４のいずれか一項に記載の方法によって定義される方法のステップを実行するように構成されている、態様１９に記載のノード（８０）。
【図１】
0006054421.tif 000002
【図２】
0006054421.tif 000003
【図３】
0006054421.tif 000004
【図４】
0006054421.tif 000005
【図５】
0006054421.tif 000006
【図６】
0006054421.tif 000007
【図７】
0006054421.tif 000008
【図８】
0006054421.tif 000009