JP5144749B2

JP5144749B2 - 改良型サービス許可方法及び装置

Info

Publication number: JP5144749B2
Application number: JP2010506120A
Authority: JP
Inventors: ステンフェルト，ジョン; ロヴセン，ラーズ; マットソン，ハンズ; サンティソ，ガダルーペサンチェス
Original assignee: テレフオンアクチーボラゲットエルエムエリクソン（パブル）
Priority date: 2007-04-27
Filing date: 2007-04-27
Publication date: 2013-02-13
Anticipated expiration: 2027-04-27
Also published as: CN101682609A; US20100146596A1; EP2153621B1; EP2153621A4; BRPI0721599A2; WO2008133561A1; AU2007352471A1; EP2153621A1; AU2007352471B2; BRPI0721599B1; JP2010525732A; CN101682609B

Description

本発明は、無線アクセス電気通信システムにおいて改良型サービス許可の取得を可能にする方法及び装置を開示する。

現在、いくつかの無線アクセス電気通信システム、例えば２Ｇシステムや、３ＧＧＰＲＳのような３Ｇシステムには、それぞれシステム内部のサービス又はシステム外部のサービスへのユーザ・アクセスを許可又は拒否する機能が存在する。大部分の２Ｇ及び３Ｇシステムでは、そのようなユーザ・アクセスの許可機能又は拒否機能は次のように設計される。ユーザは、システム内のノード、ＧＰＲＳシステムの場合はいわゆるＧＧＳＮ（ＧａｔｅｗａｙＧＰＲＳＳｕｐｐｏｒｔＮｏｄｅ：ゲートウェイＧＰＲＳサポート・ノード）に対する要求を利用してサービスへのアクセス要求を行う。

ＧＧＳＮは、ユーザの権限と、当該ユーザが通常ＰＣＲＦ（ＰｏｌｉｃｙａｎｄＣｈａｒｇｉｎｇＲｕｌｅＦｕｎｃｔｉｏｎ：ポリシー及び課金ルール機能）として知られるシステム内の別の機能を利用してアクセス可能なサービスと、を認識している。ＧＧＳＮは通常、ＵＥが新しいセッションを要求したとき、例えばＵＥの最初の電源投入時等に、当該ユーザがどのサービスにアクセスすることができ、どのサービスにアクセスすることができないかを定義するリストをＰＣＲＦに要求し、ＰＣＲＦから当該リストを受け取る。このリストはその後、ＧＧＳＮが該当するセッション中にユーザのアクセス要求対象となるサービスへのユーザ・アクセスを許可又は拒否するのに使用される。

ＰＣＲＦからの情報に従ってＧＧＳＮがユーザ・アクセスを拒否することを望むサービスへのアクセス要求が、ユーザによって行われた場合、当該要求は、サービス要求の拒否を処理するシステム内の別個の機能にリダイレクトされ得る。この別個の機能は、アクセスが拒否されたことをユーザに知らせるメッセージをＵＥに送信し、当該ユーザは、例えば「Access Denied（アクセス拒否）」や「Service not authorized（許可されていないサービス）」等のメッセージを受信する。

ユーザ・アクセスを許可又は拒否する文脈において、ＧＧＳＮは、ポリシー課金実施機能（ＰｏｌｉｃｙＣｈａｒｇｉｎｇＥｎｆｏｒｃｅｍｅｎｔＦｕｎｃｔｉｏｎ：ＰＣＥＦ）と呼ばれる役割を担う。ＰＣＥＦは、Ｇｘとして知られるインターフェースを利用してＰＣＲＦにアクセスする。

ユーザが通常アクセスを許可されるサービスの中には、例えば以下に示すように、いくつかのＰＣＲＦ定義ポリシーによって一時的に許可が取り消されるものも存在する可能性がある。
●ユーザが通常アクセスを許可されるサービスであっても、そのユーザが異なるネットワークをローミングした場合は許可が取り消される可能性がある。
●一部のサービスは、１日のうちの一定の期間、例えば平日の午前９時〜午後６時の間だけ許可される可能性がある。
●一部のサービスは、要求対象のベアラ（ｂｅａｒｅｒ）が十分高い品質を提供する場合にのみ許可される可能性がある。
●ユーザの端末機器の制限。

あるユーザについて１つ又は複数のサービスが拒否され得ることが明らかである場合も、Ｇｘインターフェースは、サービスに対するユーザ・アクセスが許可されるか否かに関する情報しか提供しない。

例えば、あるサービスに対するユーザ・アクセスの拒否が、当該ユーザの端末が該当するサービスをサポートしていないことによるものであるのか、それとも当該ユーザが該当するサービスを拒否する別のネットワークをローミングしていることによるものであるのかを、ＰＣＥＦ／ＧＧＳＮが知ることは不可能である。それ故、拒否された場合にＰＣＥＦが取り得る唯一のアクションは、ユーザ端末から発行されたサービス要求を上記のメッセージで例示したような一般的なリダイレクト・アドレスにリダイレクトし、そのサービスが不特定の理由で拒否されたことをユーザに知らせることだけとなる。

要約
したがって、上記の説明から分かるように、例えばＰＣＥＦ／ＧＧＳＮ等のノードが、アクセス要求を行ったサービスへのアクセスを拒否されたユーザに対して、現在可能なものよりも多くの拒否理由に関する情報を提供する方法が必要とされている。

この必要性は、本明細書に開示されるように、いくつかのユーザ機器ＵＥと、ＵＥが特定のサービスへのアクセス要求を送信することが可能な第１のノードとが存在し得る無線アクセス電気通信システムで使用される本発明に係る方法によって満足される。

本発明が適用され得る前記システムは、特定のサービスに対する前記システム内の複数のＵＥのアクセス権に関する情報を保持する制御機能も備え、更に、前記システムは、前記第１のノードと前記制御機能との間のインターフェースを備える。

本発明に係る前記方法は、前記第１のノードにＵＥのアクセス権に関する情報を前記制御機能から受信させるステップと、前記制御機能からの前記アクセス権情報を使用してＵＥからのサービス・アクセス要求を前記第１のノードに処理させるステップと、を含む。前記方法は、前記制御機能から前記第１のノードへの前記アクセス権情報に、前記ＵＥがアクセスを拒否されるサービスに関するコードを含めるステップも含む。

したがって、本発明を利用すると、ユーザがあるサービスへのアクセスを拒否される理由に関するより詳細な情報を各ユーザに提供するために、前記第１のノード、例えばＰＣＥＦ／ＧＧＳＮは、前記制御機能、例えばＰＣＲＦから取得される前記コードを使用することが可能となる。本発明の好ましい一実施形態では、前記コードは、前記アクセス要求を前記システム内の第２の機能にリダイレクトするために前記第１のノード（ＰＣＥＦ／ＧＧＳＮ）によって使用され、本実施形態において、前記方法は、前記第２の機能に拒否理由に関する明示的なメッセージを要求元の前記ＵＥに送信させるステップも含む。一方、前記第１のノードにおいてコードを「復号化」することができるように、前記第１のノードが前記コードのリストを含むようにすることも十分可能であり、その場合は、該当する前記コードに対応するメッセージを前記第１のノードから前記ＵＥに送信することが可能となる。

情報量が不十分な「拒否メッセージ（ｄｅｎｉａｌｍｅｓｓａｇｅ）」の問題に加えて、現行のシステムの別の問題は、オペレータがいくつかのサービスを限られた期間、例えば平日の午前８時〜午後６時の間、複数のユーザに許可したいと望む可能性があることである。現行の標準的なＧｘプロトコルを用いてこれを実現するには、影響を受けるすべてのセッションに関するＰＣＥＦ内の許可情報をほぼ同時に更新する必要がある。このような処理は、Ｇｘシグナリングのピークがかなり大きくなるため非常に望ましくない。

この問題は、前記制御機能（例えばＰＣＲＦ）から前記第１のノード（例えばＰＣＥＦ／ＧＧＳＮ）への前記アクセス権情報に、前記ＵＥが前記サービスのうちの１つ又は複数へのアクセスを許可又は拒否される期間に関する情報を含めるステップを含む、本発明の特定の一実施形態によって対処される。

したがって、本発明を利用すると、あるサービスへのアクセスを拒否されたユーザに拒否理由を知らせることが可能となり、また、ユーザがサービスへのアクセスを時間間隔に基づいて拒否又は許可され得る手法を改良することが可能となる。

本発明の上記及び他の利点は、以下の詳細な説明を読めばより明らかとなるだろう。

本発明は、前記第１のノード（例えばＰＣＥＦ／ＧＧＳＮ）と前記制御機能（例えばＰＣＲＦ）との間で使用される改良されたインターフェース、ならびに前記第１のノードとして使用されるノードも開示する。

図面の簡単な説明
以下では、添付の図面を参照して本発明についてより詳細に説明する。

図１は、従来技術のシステムを示す図である。図２は、本発明を適用した図１のシステムを示す図である。図３は、本発明の例示的なイベント図である。図４は、本発明の例示的なイベント図である。

詳細な説明
図１は、本発明の読者の理解を助けるために従来技術のシステム１００の一例を示す。図１ならびに以下の説明では、３ＧＧＰＲＳシステムのシステム・コンポーネント及び名称を利用して本発明の説明を行うが、これらは単なる例示にすぎず、本発明は事実上、本発明で対処される問題の解決が望まれる任意のシステムに適用可能であることを理解していただきたい。

図１に示されるように、システム１００には、いくつかのユーザ機器ＵＥ１１０と、第１のノード１２０、即ちＧＧＳＮとが存在する可能性がある。本明細書のＧＧＳＮは、ＧＰＲＳ向けのＰＣＥＦを構成することから、代替的にＰＣＥＦ（ポリシー課金実施機能）とも呼ばれる。

ＧＰＲＳシステムは、図１に示されていない多数のコンポーネントを含むことを指摘しておく。これは、本発明に直接関与するコンポーネントだけを図示し、本明細書に記載するためである。例えば、３ＧＧＰＲＳシステムは、ＵＥ１１０とＰＣＥＦ／ＧＧＳＮ１２０との間に配置されるＳＧＳＮとして知られる機能を含む。しかしながら、本発明に関与するメッセージはＳＧＳＮを「通過」してＵＥとＰＣＥＦ／ＧＧＳＮとの間でやりとりされるので、ＳＧＳＮと本発明の関連性は低い。

ＰＣＲＦ１６０は、ＵＥ１１０がどのサービスへのアクセスを許可され、どのサービスへのアクセスを拒否されるのかに関する情報を有する。この情報は、他の時点で通信される可能性もあるが、通常は最初のＵＥベアラ・サービス要求時にＰＣＥＦ／ＧＧＳＮに通信される。ＰＣＲＦ１６０とＰＣＥＦ／ＧＧＳＮ１２０との間のインターフェースは、Ｇｘインターフェースとして知られる。

したがって、ＰＣＲＦ１６０は、ＵＥ１３０がアクセスを拒否又は許可されるサービスのリストをＰＣＥＦ／ＧＧＳＮ１２０に通信する。一例として、リスト内の許可されないサービスはすべて拒否されると見なすことが可能である。ＰＣＥＦ／ＧＧＳＮは、このリストを記憶し、図１の矢印１で示されるように、あるサービスへのアクセス要求を行う要求メッセージがＵＥ１１０からＰＣＥＦ／ＧＧＳＮ１２０に送信されたときは、以下の処理が行われる可能性がある。
●ＰＣＥＦ／ＧＧＳＮ１２０は、ＰＣＲＦからＧｘインターフェースを介して提供された情報に基づいて、ＵＥ１１０に該当するサービスへのアクセスを許可する。この要求は、ＰＣＥＦ／ＧＧＳＮによってそれ自体の宛先に経路指定／転送される。
●ＰＣＥＦ／ＧＧＳＮ１２０は、ＰＣＲＦからＧｘインターフェースを介して提供された情報を利用して、ＵＥ１１０によってアクセス要求が行われたサービスへのアクセスをＵＥ１１０に許可することができないことを確認する。その場合は、図１の矢印２で示されるように、ＰＣＥＦ／ＧＧＳＮからの矢印２で要求を傍受し、「リダイレクト」応答、即ち、システム内の第２の機能１７０にＵＥの要求をリダイレクトするメッセージをＵＥに送信し、ＵＥの要求は、図１の矢印３で示されるようにリダイレクトされる。第２の機能１７０は、矢印４で示されるメッセージをＵＥ１１０に送信する。図１の従来技術のシステム１００では、このメッセージは、「Access Denied」や「Service not authorized」のような標準化された「拒否メッセージ」とすることしかできない。

図２は、本発明のシステム２００を示す。図１のシステム１００に示されるコンポーネント及び機能は、図１と同じ参照番号が使用されており、ここでは改めて説明しない。

本発明のシステム２００では、制御機能１６０、即ちＰＣＲＦは、Ｇｘインターフェースを介したいくつかのサービスに対するＵＥのアクセス権に関する情報をＰＣＥＦ／ＧＧＳＮに送信することができる。しかしながら、図１のシステム１００と異なり、システム２００では、ＰＣＲＦ１６０からＰＣＥＦ／ＧＧＳＮ１２０に送信される情報は、図２にも示されるように、以下の構造を有することができる。

ＰＣＲＦからＧｘインターフェースを介してＰＣＥＦ／ＧＧＳＮに提供されるサービス許可情報の例
Service "A": OK
Service "B": Not OK, "NOK", Code 2
Service "C": OK
Service "D": NOK; Code 4

したがって、図面からも分かるように、ユーザ１１０がアクセスを拒否されたサービスに関して、ＰＣＲＦは、Ｇｘインターフェースを使用してどのサービスが許可されているかだけでなく、一時的であるにせよどのサービスが許可されていないか（ＮＯＫ）についても、その拒否理由に関連するコードと共にＰＣＥＦ／ＧＧＳＮ１２０に明示的に知らせる。

その結果、ＰＣＲＦからの情報に従ってアクセスが拒否されるサービスへのアクセス要求がＵＥによって行われたとき、ＰＣＥＦ／ＧＧＳＮは、Ｇｘメッセージに含まれるコードを使用するが、この処理の流れを以下に示す。
●ＵＥ１１０は、それ自体の要求メッセージを送信する（図２の矢印１）。
●ＰＣＥＦ／ＧＧＳＮ１２０は、要求されたサービスを識別し、ＵＥ１１０からの該当するサービスへのアクセスが拒否されることを確認し、ＵＥ１１０にリダイレクト・メッセージを送信する（矢印２）。しかしながら、従来技術のシステム１００のイベント・シーケンスと異なり、この場合のＰＣＥＦ／ＧＧＳＮは、アクセス拒否に関連する追加的な情報、即ち上述のコードを有する。このコードは、本発明のある実施形態では、ＵＥからのアクセス要求を図２の１８０〜１８２で示されるいくつかの指定機能のうちの１つにリダイレクトするのに使用される。リダイレクトされた要求は、矢印３で示され、機能１８０〜１８２からの応答は、矢印４で示される。

拒否された要求をいくつかの機能１８０〜１８２のうちの１つにリダイレクトすることができるので、ＵＥ１１０に対する「拒否メッセージ」の内容を従来不可能とされていた手法で修正（ｔａｉｌｏｒ）することが可能となる。好ましいことに、各ＮＯＫコードは、各機能１８０〜１８２のうちの指定された１つと結合され、その結果、各ＮＯＫコードとある拒否メッセージとを対応付けることが可能となる。

したがって、各機能１８０〜１８２は、あるメッセージと共に作成されるが、例えば以下のようなメッセージを含むことができる。
●「The requested service can only be reached from your Home PLMN, Public Land Mobile Network.（要求されたサービスは、ホームＰＬＭＮ（ＰｕｂｌｉｃＬａｎｄＭｏｂｉｌｅＮｅｔｗｏｒｋ：公衆陸上移動通信網）からのみアクセス可能です。）」
●「The requested service cannot be accessed from this terminal type. Please contact customer support for minimal terminal requirements.（要求されたサービスは、この端末タイプではアクセスすることができません。最低端末要件についてはカスタマー・サポートにお問い合わせください。）」
●「The requested service can only be accessed between 0700 and 1800 Monday to Friday.（要求されたサービスは、月曜日から金曜日の午前７時〜午後６時の間だけアクセス可能です。）」
●「The requested service requires a 3G connection.（要求されたサービスは、３Ｇ接続が必要です。）」

言うまでもなく、図２に示される「拒否メッセージ機能」１８０〜１８２の数は、単なる例示であり、これより大きい数あるいは小さい数に制限なく変更することが可能である。

また、拒否メッセージ機能１８０〜１８２は、本発明の機能拡張Ｇｘメッセージを利用する一手法にすぎないことも指摘しておく。また、ＰＣＲＦ自体に由来するコードを復号化する機能をＰＣＥＦ／ＧＧＳＮに備えさせ、その結果、ＰＣＥＦ／ＧＧＳＮ内の当該機能を利用することにより、拒否メッセージがＰＣＥＦ／ＧＧＳＮ１２０からＵＥ１１０に直接送信されるようにすることも十分可能である。

更に、拒否メッセージ機能１８０〜１８２は、図２に示されるようにＰＣＥＦ／ＧＧＳＮの外部に所在させることも可能であるが、それらを単一の機能とし、したがって、拒否理由に関してＰＣＲＦから送信されるすべてのコードを復号化する能力を備えさせることも可能である。

上記の説明から分かるように、本発明は、ＰＣＲＦがＵＥによるサービス・アクセスの拒否理由に関するより多くの情報をＰＣＥＦに通信することができるようにＧｘプロトコルを拡張することを含む。このようなＧｘプロトコルの拡張は、属性値ペア（ＡｔｔｒｉｂｕｔｅＶａｌｕｅＰａｉｒ：ＡＶＰ）と呼ばれることもあり、以下ではこの用語を使用することもある。ＡＶＰは、Ｇｘプロトコルで使用される情報コンテナである。

図３は、本発明のＡＶＰが使用されるシグナリング・シーケンス３００を示す。シグナリングは、ＵＥと、ＰＣＥＦと、ＰＣＲＦと、図２の機能１８０〜１８２に対応するリダイレクト・サーバとの間で行われる。

シーケンスは以下のとおりである。
（１）ベアラ・サービス要求を確立する：ＵＥは、ＰＣＥＦ／ＧＧＳＮにベアラ・セットアップ要求を送信する。ＧＰＲＳの場合、この要求は「Activate PDP Context Request」となる。
（２）ＧｘＣＣＲ（「Credit Control Request」：クレジット制御要求）を開始する。ＰＣＥＦは、ＰＣＲＦとのＧｘセッションを開始し、ＵＥのＩＤ、要求されるＱｏＳ、ＰＬＭＮ‐ＩＤ等を含む。
（３）ＧｘＣＣＡを開始する。ＰＣＲＦは、許可されている「Charging-Rule-Base」と、通常はホームＰＬＭＮでのみ使用可能な「Charging-Rule-Name」とに関する１つの「Charging-Rule-Install」を含むＣＣＡ（「Credit Control Answer」：クレジット制御応答）で応答する。本例のＵＥは現在別の事業者のネットワークをローミングしているため、サービスが一時的に許可されなくなる。該当するＣＣＡは、以下の情報を含むことができる。

（４）「Bearer Service Request」を確立する。要求されたベアラが許可される。ＧＰＲＳの場合、この許可は「Activate PDP Context Accept」となる。
（５）ＵＥは、ウェブ・ページ、例えばＵＲＬ「ｘ」へのアクセスを要求する。ＰＣＥＦは、ＵＲＬ「ｘ」が例えばローミングによって一時的に許可が取り消される「Charging-Rule No. 5」に対応することを検出する。
（６）ＰＣＥＦは、「DENIED_ROAMING」（ＵＲＬ「ｙ」）でのみ使用される構成済みのリダイレクト・サーバ・アドレスを含むリダイレクト指示を含む応答をＵＥに送信する。
（７）ＵＥは、ＵＲＬ「ｙ」の要求を発行する。
（８）ＵＲＬ「ｙ」のリダイレクト・サーバは、要求されたウェブ・ページがホームＰＬＭＮからのみアクセス可能である旨の応答をＵＥに返す。

以下では単なる例示として、本発明のＡＶＰのいくつかの例を示す。

「Charging-Rule-Install」ＡＶＰ
「Charging-Rule Install」ＡＶＰには、新しいＡＶＰ、即ち以下に示す「Charging- Rule-Authorization」ＡＶＰを挿入することによって現在及び次の期間中の許可状態が含められる。

「Charging-Rule-Authorization」ＡＶＰで提供される許可情報は、ＣＣＡ又はＲＡＲ（「Re-Authorization Request」：再許可要求）で提供される「Charging-Rule-Install」ＡＶＰのインスタンス内で提供されるすべての「Charging-Rule-Name」及び「Charging-Rule-Base-Name」に対して有効である。

「Charging-Rule-Authorization」ＡＶＰ内に「Charging-Rule-Authorization」ＡＶＰが存在しない場合は、すべての「Charging-Rule-Definition」、「Charging-Rule-Name」、及び「Charging-Rule-Base-Name」が制限なく許可されることを意味する（標準的な解決策）。

「Charging-Rule-Authorization」ＡＶＰ
「Charging-Rule-Authorization」ＡＶＰは、関連する課金ルール及び課金ルール・ベースに関する現在及び次の期間中の許可状態を定義するのに必要となるＡＶＰをグループ化する。

「Charging-Rule-Authorization」ＡＶＰは、同一の「Authorization-state」を有する「Charging-Rule-Name」又は「Charging-Rule-Base-Name」を対象とする同一の「Charging-Rule-Install」内で共用される。

「Charging-Rule-Authorization」ＡＶＰは、以下の形式とすることができる。

「Authorization-State」ＡＶＰ
「Authorization-State」ＡＶＰは、「列挙（ｅｎｕｍｅｒａｔｅｄ）」型とすることができ、「Charging-Rule-Install」ＡＶＰで提供される課金ルール及び課金ルール・ベースに関する許可状態及び不許可理由が指定される。

「Authorization-State」ＡＶＰについては以下の値が定義され得る。

上記の説明から分かるように、本発明を利用すれば「アクセス拒否メッセージ」に関連する問題に対処することが可能となる。本発明の特定の一実施形態によって解決され得る別の問題は、システム・オペレータがいくつかのサービスを限られた期間、例えば平日の午前８時〜午後６時といった特定の時間帯に多数のユーザに許可したいと望む可能性があることである。ＰＣＲＦとＰＣＥＦの間で使用される現行のＧｘプロトコルを用いてこれを実現するには、影響を受けるすべてのセッションに関するＰＣＥＦ内の許可情報をほぼ同時に更新する必要がある。このような処理は、システム内のＧｘシグナリングのピークが大きくなるため望ましくない。

この問題に対処するために、本発明の上述の実施形態は、制御機能即ちＰＣＲＦから第１のノード即ちＰＣＥＦ／ＧＧＳＮへのアクセス権情報に、ＵＥが１つ又は複数のサービスへのアクセスを許可又は拒否される期間に関する情報を含めるステップを含む。

一例として、いくつかのサービスは、特定の期間だけ、例えばそのサービスがアクティブ化された時点から２４時間以内、あるいは繰り返し期間、例えば平日の午前７時〜午後６時まで、あるユーザを対象に許可することが可能である。

このような情報をＰＣＥＦに提供するために、ＰＣＲＦからＰＣＥＦに提供される上述の「許可コード」、いわゆるＰＣＣルールを、許可状態が変更された特定の時点に関する情報と関連付けることができる。この種のサービスでは、許可状態が変更された後に有効となる次の許可状態も提供されなければならない。このようにして、ＰＣＥＦは、例えばあるユーザがあるサービスへのアクセスを本例では午後６時まで許可され、その後カレンダー時間制限によってそのサービスへのアクセスを拒否されることを判定することが可能となる。無論、逆の場合、即ち、ユーザによるサービスへのアクセスが当初カレンダー時間制限によって一時的に拒否されるが、本例では午後６時を過ぎるとサービスへのアクセスがユーザに許可されるようにすることも可能である。

本発明のカレンダー時間ベース許可の実施形態における別の「ビルディング・ブロック」は、ＰＣＥＦからＰＣＲＦへの新しいポリシー情報要求のスケジューリングを行うバリディティ・タイマ（ｖａｌｉｄｉｔｙｔｉｍｅｒ）である。バリディティ・タイマは、ＰＣＲＦからＰＣＥＦに提供され、典型的には許可状態変更時刻以降、例えば本例では午後６時以降から、後続の許可状態変更時刻以前、即ち本例では遅くとも翌日の午前７時以前に新しいポリシー情報を取得するに足る長さの時間にセットされることになる。

したがって、本発明に係るカレンダー時間ベース許可の実施形態を利用すれば、Ｇｘシグナリングのピークを回避することが可能となる。

ここで、あるサービスに対する時間ベースのアクセス許可又は拒否／許可を説明するために、図４を参照する。図４は、時間ベースのアクセス拒否／許可が使用されるシグナリング図４００である。

図４のシグナリングは、ＵＥと、ＰＣＥＦと、ＰＣＲＦとの間で行われる。このシグナリングは、図４に示される横矢印のとおり以下のように進められる。
（１’）ベアラ・サービス要求を確立する。ＵＥは、ＰＣＥＦ／ＧＧＳＮにベアラ・セットアップ要求を送信する。ＧＰＲＳの場合、この要求は「Activate PDP Context Request」となる。
（２’）ＧｘＣＣＲを開始する。ＰＣＥＦ／ＧＧＳＮは、ＰＣＲＦとのＧｘセッションを開始し、ＵＥのＩＤ、要求されるＱｏＳ、ＰＬＭＮ‐ＩＤ等を含む。
（３’）ＧｘＣＣＡを開始する。ＰＣＲＦは、許可されている「Charging-Rule-Base」と、カレンダー時間によって現時点で許可されていない「Charging-Rule-Name」とに関する１つの「Charging-Rule-Install」を含むＣＣＡで応答する。許可状態変更時刻は、翌日の午前７時にセットされる。許可状態変更時刻が経過したときは、サービスへのアクセスがユーザに許可される（次の許可状態）。また、「authorization-validity-time」は、ポリシー情報がＰＣＥＦによって翌日の午後６時までにリフレッシュされなければならないことを示す。該当するＣＣＡは、以下のフォーマットとすることができる。

（４’）「Bearer Service Request」を確立する。要求されたベアラが許可される。ＧＰＲＳの場合、この許可は「Activate PDP Context Accept」となる。このベアラは「DENIED_CALENDAR_TIME」となっているため、該当する「Charging-Rule-Name」に関連するすべてのサービス要求は、リダイレクト・サーバにリダイレクトされる。
（５’）午前７時に、許可状態が「DENIED_CALENDAR_TIME」から「AUTHORIZED」に変更される。これ以降、ＰＣＥＦは、該当する「Charging-Rule-Name」に関するサービス要求をリダイレクトすることはなく、それらの要求はＰＣＥＦを通過することになる。
（６’）ＣＣＲを更新する。午後６時以前のある時点で、ＰＣＥＦは、ポリシー情報をリフレッシュするために新しいＣＣＲを発行する。多数のセッションが同一の「Authorization-Validity-Time」を共用する場合のシグナリング・ピークを回避するために、この種の要求の配信は、ＰＣＥＦが担当する。
（７’）ＣＣＡを更新する。ＰＣＲＦは、新しいポリシー情報で応答する。この時点の「Charging-Rule」の許可状態は「AUTHORIZED」であり、次の許可状態は「DENIED_CALENDAR_TIME」である。許可状態変更時刻は午後６時であり、ポリシー情報は、遅くとも翌日の午前７時に再度リフレッシュしなければならない。新しい値は、以下の形式とすることができる。

サービスに対するカレンダー・ベースのアクセス許可／拒否と共に使用され得る本発明のＡＶＰのいくつかの例を以下に示す。以下のＡＶＰは単なる例示であり、いかなる場合も本発明の所期の保護範囲を限定するものと解釈されるべきでないことを指摘しておく。

「Authorization-State-Change-Time」ＡＶＰ
「Authorization-State-Change-Time」は、「Authorization-State」ＡＶＰで提供される許可状態が無効となる日時を識別するタイム・スタンプである。「Authorization-State-Change-Time」ＡＶＰの一例は、「時刻（Ｔｉｍｅ）」型であり、１９００年１月１日０時０分（ＵＴＣ）を起点とする秒単位の時刻を含む。

「Next-Authorization-State」ＡＶＰ
「Next-Authorization-State」ＡＶＰの一例は、「列挙」型であり、「Authorization-State-Change-Time」ＡＶＰで定義される有効期限経過後の許可状態及び不許可理由を指定する。「Next-Authorization-State」ＡＶＰについては以下の値が定義され得る。

「Authorization-Validity-Time」ＡＶＰ
「Authorization-Validity-Time」ＡＶＰは、「Credit Control Answer」（ＣＣＡ）又は「Re-Authorization-Request」（ＲＡＲ）に含めることができる。「Authorization-Validity-Time」は、「Charging-Rule-Install」ＡＶＰで提供される許可情報が無効となる日時を識別するタイム・スタンプである。具体的な「Authorization-Validity-Time」ＡＶＰの一例は、「時刻（Ｔｉｍｅ）」型であり、１９００年１月１日０時０分（ＵＴＣ）を起点とする秒単位の時刻を含む。

「Event-Trigger」ＡＶＰ
「Event-Trigger」ＡＶＰは、「列挙（Ｅｎｕｍｅｒａｔｅｄ）」型に適している。「Event-Trigger」は、ＰＣＣルールを再要求するイベントを示す。このＡＶＰについては以下の値が定義され得る。

この値は、「Authorization-Validity-Time」で指定される所与の時刻以前に新しいＰＣＣルールを要求すべきことを示すのに使用される。

注：「Event-Trigger 100」及び「Authorization-Validity-Time」ＡＶＰが提供されない場合も、「Charging-Rule-Authorization」で「Authorization-State-Change-Time」ＡＶＰが提供されている場合は、ＰＣＥＦの新しいＰＣＣ判定が行われるまで次の許可状態が永続的な許可状態となる。このことは、時間ベースのサブスクリプション、例えばサービス「Ａ」の１２時間アクセス等を実現するのに役立つ。

本発明は、２Ｇシステムや、３ＧＧＰＲＳシステムのような３ＧシステムにおけるＰＣＥＦ／ＧＧＳＮに適した上述のノード１２０も備える。かかるノードは、制御機能１６０からＵＥのアクセス権に関する情報を受信する手段を備える。これらの手段１４５は、図２のプロセッサ１４５として象徴的に示されているが、ハードウェア又はソフトウェアの適切な組合せとすることもできる。

本発明のノードは、前記制御機能からのアクセス権情報を使用することによってＵＥからのサービス・アクセス要求を処理する手段であって、ユーザがアクセスを拒否されるサービスに関するコードＸ、Ｙ、Ｚを含む、前記制御機能即ちＰＣＲＦからのアクセス権情報を処理することも可能なプロセッサ１４５としても適した手段も備える。

適切なことに、プロセッサ１４５は、上述のようにＵＥがアクセスを拒否されたサービスへのアクセス要求のリダイレクト処理も行うとともに、ノード１２０に対してあるサービスへのアクセス要求を行ったＵＥが、要求を行った時刻、週、月等に基づいて、ノード１２０によってアクセスを拒否又は許可され得るように、ＵＥ１１０が前記サービスのうちの１つ又は複数へのアクセスを許可又は拒否される期間に関する情報も処理する。

まとめとして、本発明によって開示されるＧｘインターフェースの改良型サービス許可を用いると、ＰＣＥＦ／ＧＧＳＮは、リダイレクト・サーバへの選択的なサービス・リダイレクトを実行することが可能となり、リダイレクト・サーバは、エンド・ユーザ即ちＵＥがアクセス要求を行ったサービスであって、通常はアクセスが許可されるサービスへのアクセスが拒否された理由に関する詳細情報を、ＵＥに提供することが可能となる。

本発明によって開示されるＧｘインターフェースを介して送られるカレンダー時間ベースの許可情報は、一定の期間だけ許可されるサービス、あるいは例えば１日又は１週間のうちのある時間帯だけ許可されるサービスについて、ＰＣＥＦ／ＧＧＳＮがサービス・ベース・アクセス制御を実行することが可能となる情報をＰＣＥＦ／ＧＧＳＮに提供する。

この情報を利用すると、その種のサービスで多数のセッションのポリシー情報を同時に更新する必要があるときに現行のＧｘソリューションで生じるシグナリング・ピークを回避することが可能となる。

本発明は、上述及び図示の例示的な実施形態に限定されるものではなく、添付の特許請求の範囲内で自由に変更することが可能である。

Claims

いくつかのユーザ機器ＵＥ（１１０）と、ＵＥが特定のサービスへのアクセス要求を送信することが可能な第１のノード（１２０）とが存在し得る無線アクセス電気通信システム（２００）で使用される方法（３００）であって、前記システム（２００）は、特定のサービスに対する前記システム内の複数のＵＥのアクセス権に関する情報を保持する制御機能（１６０）も備え、前記システム（２００）は、前記第１のノード（１２０）と前記制御機能（１６０）との間のインターフェースを更に備え、前記方法（３００）は、前記第１のノードにＵＥのアクセス権に関する情報を前記制御機能から受信させるステップ（３）と、前記制御機能からの前記アクセス権情報を使用してＵＥからのサービス・アクセス要求を前記第１のノードに処理させるステップ（５）と、を含み、前記方法は、前記制御機能から前記第１のノードへの前記アクセス権情報に、前記ＵＥがアクセスを拒否されるサービスに関するコード（Ｘ、Ｙ、Ｚ）を含めるステップ（３）と、前記制御機能（１６０）から前記第１のノード（１２０）への前記アクセス権情報に、前記ＵＥ（１１０）が前記サービスのうちの１つ又は複数へのアクセスを許可又は拒否される期間に関する情報を含めるステップ（３）を更に含み、
前記制御機能（１６０）からの前記情報に従ってアクセスが拒否されるサービスへのアクセス要求が、ＵＥ（１１０）によって行われた場合に、前記コード（Ｘ、Ｙ、Ｚ）は、前記アクセス要求を前記システム内の第２の機能（１８０〜１８２）にリダイレクトするために前記第１のノード（１２０）によって使用され、前記第２の機能は、前記サービスへのアクセス拒否理由に関する具体的な情報を含むメッセージを含み、
前記方法は、前記第２の機能（１８０〜１８２）に前記拒否理由に関する具体的な情報を含むメッセージを要求元の前記ＵＥに送信させるステップ（８）を更に含む、ことを特徴とする、方法（３００）。
前記第１のノード（１２０）は、ＰＣＥＦ（ポリシー課金実施機能）として動作するように構成された２Ｇ又は３ＧシステムのＧＧＳＮであり、前記制御機能は、前記システムのＰＣＲＦ（ポリシー及び課金ルール機能）である、上記請求項１に記載の方法（３００、４００）。
いくつかのユーザ機器ＵＥ（１１０）と、ＵＥが特定のサービスへのアクセス要求を送信することが可能な第１のノード（１２０）とが存在し得る無線アクセス電気通信システム（２００）で使用されるインターフェース（１５０であって、前記システム（２００）は、特定のサービスに対する前記システム内の複数のＵＥのアクセス権に関する情報を保持する制御機能（１６０）も備え、前記インターフェースは、前記第１のノード（１２０）と前記制御機能（１６０）との間で、様々な情報の中でもとりわけ、いくつかのサービスに対するＵＥのアクセス権に関する情報を前記制御機能から前記第１のノード（１２０）に送るのに使用されるインターフェース（１５０）であり、前記インターフェースは、前記アクセス権情報と共に、前記ＵＥがアクセスを拒否されるサービスに関する１つ又は複数のコード（Ｘ、Ｙ、Ｚ）を含むことを特徴とし、かつ、前記制御機能（１６０）から前記第１のノード（１２０）への前記アクセス権情報は、前記ＵＥ（１１０）が前記サービスのうちの１つ又は複数へのアクセスを許可又は拒否される期間に関する情報を含み、
前記制御機能（１６０）からの前記情報に従ってアクセスが拒否されるサービスへのアクセス要求が、ＵＥ（１１０）によって行われた場合に、前記コード（Ｘ、Ｙ、Ｚ）は、前記アクセス要求を前記システム内の第２の機能（１８０〜１８２）にリダイレクトするために前記第１のノードによって使用され、前記第２の機能は、前記サービスへのアクセス拒否理由に関する具体的な情報を含むメッセージを含み、前記第２の機能（１８０〜１８２）から前記拒否理由に関する具体的な情報を含むメッセージが要求元の前記ＵＥに送信される
ことを特徴とするインターフェース（１５０）。
前記インタフェースは、２Ｇシステム、又は３ＧＧＰＲＳシステム等の３ＧシステムにおけるＧｘインターフェースである、請求項３に記載のインターフェース（１５０）。
いくつかのユーザ機器ＵＥ（１１０）が存在し得る無線アクセス電気通信システム（２００）で使用され、ＵＥが特定のサービスへのアクセス要求を送信することが可能なノード（１２０）であって、前記ノードは、特定のサービスに対する前記システム内の複数のＵＥのアクセス権に関する情報を保持する制御機能（１６０）と前記システム内で情報を交換する手段を備え、前記情報の交換は、前記ノード（１２０）と前記制御機能（１６０）との間のインターフェース（１５０）を介して実行され、前記ノードは、前記制御機能（１６０）からＵＥのアクセス権に関する情報を受信する手段（１４５）と、前記制御機能からの前記アクセス権情報を使用することによってＵＥからのサービス・アクセス要求を処理する手段（１４５）と、を備え、前記ノードは、前記ＵＥがアクセスを拒否されるサービスに関するコード（Ｘ、Ｙ、Ｚ）を含む前記制御機能からの前記アクセス権情報を処理する手段（１４５）と、前記ノード（１２０）に対してあるサービスへのアクセス要求を行ったＵＥが、前記要求を行った時刻、週、月等に基づいて、前記ノード（１２０）によってアクセスを拒否又は許可され得るように、前記ＵＥ（１１０）が前記サービスのうちの１つ又は複数へのアクセスを許可又は拒否される期間に関する情報が含められた前記制御機能（１６０）からのアクセス権情報を処理する手段（１４５）と、を更に備え、
アクセス権情報を処理する前記手段（１４５）は、前記制御機能（１６０）からの前記情報に従ってアクセスが拒否されるサービスへのアクセス要求がＵＥ（１１０）によって行われた場合に、前記アクセス要求を前記システム内のいくつかの第２の機能（１８０〜１８２）のうちの１つにリダイレクトするために、前記コード（Ｘ、Ｙ、Ｚ）を使用し、前記コードは、適切な前記第２の機能を選択するのに使用され、前記第２の機能は、前記サービスへのアクセス拒否理由に関する具体的な情報を含むメッセージを含み、前記第２の機能（１８０〜１８２）から前記拒否理由に関する具体的な情報を含むメッセージが要求元の前記ＵＥに送信される
ことを特徴とする、ノード（１２０）。
前記システム内のＰＣＥＦ（ポリシー課金実施機能）として動作するように構成された２Ｇ又は３ＧシステムのＧＧＳＮである、請求項５に記載のノード（１２０）。