(57)【要約】  ユーザ機器ＵＥ（１１０）と、ＵＥがサービスへのアクセス要求を送信することが可能な第１のノード（１２０）と、特定のサービスに対するシステム内のＵＥのアクセス権に関する情報を有する制御機能（１６０）と、を含む無線伝記通信システム（２００）のための方法（３００）。前記システム（２００）は、前記第１のノード（１２０）と前記制御機能（１６０）との間のインターフェース（１５０）を備え、前記方法（３００）は、前記第１のノードにＵＥのアクセス権に関する情報を前記制御機能から受信させるステップ（３）と、前記制御機能からの前記アクセス権情報を使用してＵＥからのサービス・アクセス要求を前記第１のノードに処理させるステップと、を含む。前記方法は更に、前記制御機能から前記第１のノードへの前記アクセス権情報に、前記ＵＥがアクセスを拒否されるサービスに関するコード（Ｘ、Ｙ、Ｚ）を含めるステップ（３）を含む。
2010525732.tif 000002
【特許請求の範囲】
【請求項１】
いくつかのユーザ機器ＵＥ（１１０）と、ＵＥが特定のサービスへのアクセス要求を送信することが可能な第１のノード（１２０）とが存在し得る無線アクセス電気通信システム（２００）で使用される方法（３００）であって、前記システム（２００）は、特定のサービスに対する前記システム内の複数のＵＥのアクセス権に関する情報を保持する制御機能（１６０）も備え、前記システム（２００）は、前記第１のノード（１２０）と前記制御機能（１６０）との間のインターフェースを更に備え、前記方法（３００）は、前記第１のノードにＵＥのアクセス権に関する情報を前記制御機能から受信させるステップ（３）と、前記制御機能からの前記アクセス権情報を使用してＵＥからのサービス・アクセス要求を前記第１のノードに処理させるステップ（５）と、を含み、前記方法は、前記制御機能から前記第１のノードへの前記アクセス権情報に、前記ＵＥがアクセスを拒否されるサービスに関するコード（Ｘ、Ｙ、Ｚ）を含めるステップ（３）を更に含むことを特徴とする、方法（３００）。
【請求項２】
前記制御機能（１６０）からの前記情報に従ってアクセスが拒否されるサービスへのアクセス要求が、ＵＥ（１１０）によって行われた場合に、前記コード（Ｘ、Ｙ、Ｚ）は、前記アクセス要求を前記システム内の第２の機能（１８０〜１８２）にリダイレクトするために前記第１のノード（１２０）によって使用され、前記方法は、前記第２の機能（１８０〜１８２）に拒否理由に関する明示的なメッセージを要求元の前記ＵＥに送信させるステップ（８）を更に含む、請求項１に記載の方法（３００）。
【請求項３】
前記制御機能（１６０）から前記第１のノード（１２０）への前記アクセス権情報に、前記ＵＥ（１１０）が前記サービスのうちの１つ又は複数へのアクセスを許可又は拒否される期間に関する情報を含めるステップ（３’）を更に含む、請求項１又は２に記載の方法（３００、４００）。
【請求項４】
前記第１のノード（１２０）は、ＰＣＥＦ（ポリシー課金実施機能）として動作するように構成された２Ｇ又は３ＧシステムのＧＧＳＮであり、前記制御機能は、前記システムのＰＣＲＦ（ポリシー及び課金ルール機能）である、上記請求項のいずれかに記載の方法（３００、４００）。
【請求項５】
いくつかのユーザ機器ＵＥ（１１０）と、ＵＥが特定のサービスへのアクセス要求を送信することが可能な第１のノード（１２０）とが存在し得る無線アクセス電気通信システム（２００）で使用されるインターフェース（１５０であって、前記システム（２００）は、特定のサービスに対する前記システム内の複数のＵＥのアクセス権に関する情報を保持する制御機能（１６０）も備え、前記インターフェースは、前記第１のノード（１２０）と前記制御機能（１６０）との間で、様々な情報の中でもとりわけ、いくつかのサービスに対するＵＥのアクセス権に関する情報を前記制御機能から前記第１のノード（１２０）に送るのに使用されるインターフェース（１５０）であり、前記インターフェースは、前記アクセス権情報と共に、前記ＵＥがアクセスを拒否されるサービスに関する１つ又は複数のコード（Ｘ、Ｙ、Ｚ）を含むことを特徴とするインターフェース（１５０）。
【請求項６】
前記制御機能（１６０）からの前記情報に従ってアクセスが拒否されるサービスへのアクセス要求が、ＵＥ（１１０）によって行われた場合に、前記コード（Ｘ、Ｙ、Ｚ）は、前記アクセス要求を前記システム内の第２の機能（１８０〜１８２）にリダイレクトするために前記第１のノードによって使用され得る、請求項５に記載のインターフェース（１５０）。
【請求項７】
前記制御機能（１６０）から前記第１のノード（１２０）への前記アクセス権情報は、前記ＵＥ（１１０）が前記サービスのうちの１つ又は複数へのアクセスを許可又は拒否される期間に関する情報を含む、請求項５又は６に記載のインターフェース。
【請求項８】
前記インタフェースは、２Ｇシステム、又は３Ｇ  ＧＰＲＳシステム等の３ＧシステムにおけるＧｘインターフェースである、請求項５乃至７のいずれかに記載のインターフェース（１５０）。
【請求項９】
いくつかのユーザ機器ＵＥ（１１０）が存在し得る無線アクセス電気通信システム（２００）で使用され、ＵＥが特定のサービスへのアクセス要求を送信することが可能なノード（１２０）であって、前記ノードは、特定のサービスに対する前記システム内の複数のＵＥのアクセス権に関する情報を保持する制御機能（１６０）と前記システム内で情報を交換する手段を備え、前記情報の交換は、前記ノード（１２０）と前記制御機能（１６０）との間のインターフェース（１５０）を介して実行され、前記ノードは、前記制御機能（１６０）からＵＥのアクセス権に関する情報を受信する手段（１４５）と、前記制御機能からの前記アクセス権情報を使用することによってＵＥからのサービス・アクセス要求を処理する手段（１４５）と、を備え、前記ノードは、前記ＵＥがアクセスを拒否されるサービスに関するコード（Ｘ、Ｙ、Ｚ）を含む前記制御機能からの前記アクセス権情報を処理する手段（１４５）を更に備えることを特徴とする、ノード（１２０）。
【請求項１０】
アクセス権情報を処理する前記手段（１４５）は、前記制御機能（１６０）からの前記情報に従ってアクセスが拒否されるサービスへのアクセス要求がＵＥ（１１０）によって行われた場合に、前記アクセス要求を前記システム内のいくつかの第２の機能（１８０〜１８２）のうちの１つにリダイレクトするために、前記コード（Ｘ、Ｙ、Ｚ）は前記手段によって使用され、前記コードは、適切な前記第２の機能を選択するのに使用される、請求項９に記載のノード（１２０）。
【請求項１１】
前記ノード（１２０）に対してあるサービスへのアクセス要求を行ったＵＥが、前記要求を行った時刻、週、月等に基づいて、前記ノード（１２０）によってアクセスを拒否又は許可され得るように、前記ＵＥ（１１０）が前記サービスのうちの１つ又は複数へのアクセスを許可又は拒否される期間に関する情報が含められた前記制御機能（１６０）からのアクセス権情報を処理する手段（１４５）を更に備える、請求項９又は１０に記載のノード（１２０）。
【請求項１２】
前記システム内のＰＣＥＦ（ポリシー課金実施機能）として動作するように構成された２Ｇ又は３ＧシステムのＧＧＳＮである、請求項９乃至１１のいずれかに記載のノード（１２０）。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線アクセス電気通信システムにおいて改良型サービス許可の取得を可能にする方法及び装置を開示する。
【背景技術】
【０００２】
現在、いくつかの無線アクセス電気通信システム、例えば２Ｇシステムや、３Ｇ  ＧＰＲＳのような３Ｇシステムには、それぞれシステム内部のサービス又はシステム外部のサービスへのユーザ・アクセスを許可又は拒否する機能が存在する。大部分の２Ｇ及び３Ｇシステムでは、そのようなユーザ・アクセスの許可機能又は拒否機能は次のように設計される。ユーザは、システム内のノード、ＧＰＲＳシステムの場合はいわゆるＧＧＳＮ（Ｇａｔｅｗａｙ  ＧＰＲＳ  Ｓｕｐｐｏｒｔ  Ｎｏｄｅ：ゲートウェイＧＰＲＳサポート・ノード）に対する要求を利用してサービスへのアクセス要求を行う。
【０００３】
ＧＧＳＮは、ユーザの権限と、当該ユーザが通常ＰＣＲＦ（Ｐｏｌｉｃｙ  ａｎｄ  Ｃｈａｒｇｉｎｇ  Ｒｕｌｅ  Ｆｕｎｃｔｉｏｎ：ポリシー及び課金ルール機能）として知られるシステム内の別の機能を利用してアクセス可能なサービスと、を認識している。ＧＧＳＮは通常、ＵＥが新しいセッションを要求したとき、例えばＵＥの最初の電源投入時等に、当該ユーザがどのサービスにアクセスすることができ、どのサービスにアクセスすることができないかを定義するリストをＰＣＲＦに要求し、ＰＣＲＦから当該リストを受け取る。このリストはその後、ＧＧＳＮが該当するセッション中にユーザのアクセス要求対象となるサービスへのユーザ・アクセスを許可又は拒否するのに使用される。
【０００４】
ＰＣＲＦからの情報に従ってＧＧＳＮがユーザ・アクセスを拒否することを望むサービスへのアクセス要求が、ユーザによって行われた場合、当該要求は、サービス要求の拒否を処理するシステム内の別個の機能にリダイレクトされ得る。この別個の機能は、アクセスが拒否されたことをユーザに知らせるメッセージをＵＥに送信し、当該ユーザは、例えば「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」：クレジット制御応答）で応答する。本例のＵＥは現在別の事業者のネットワークをローミングしているため、サービスが一時的に許可されなくなる。該当するＣＣＡは、以下の情報を含むことができる。
【数１】
2010525732.tif 000003
（４）「Bearer Service Request」を確立する。要求されたベアラが許可される。ＧＰＲＳの場合、この許可は「Activate PDP Context Accept」となる。
（５）ＵＥは、ウェブ・ページ、例えばＵＲＬ「ｘ」へのアクセスを要求する。ＰＣＥＦは、ＵＲＬ「ｘ」が例えばローミングによって一時的に許可が取り消される「Charging-Rule No. 5」に対応することを検出する。
（６）ＰＣＥＦは、「DENIED_ROAMING」（ＵＲＬ「ｙ」）でのみ使用される構成済みのリダイレクト・サーバ・アドレスを含むリダイレクト指示を含む応答をＵＥに送信する。
（７）ＵＥは、ＵＲＬ「ｙ」の要求を発行する。
（８）ＵＲＬ「ｙ」のリダイレクト・サーバは、要求されたウェブ・ページがホームＰＬＭＮからのみアクセス可能である旨の応答をＵＥに返す。
【００３９】
以下では単なる例示として、本発明のＡＶＰのいくつかの例を示す。
【００４０】
「Charging-Rule-Install」ＡＶＰ
「Charging-Rule Install」ＡＶＰには、新しいＡＶＰ、即ち以下に示す「Charging- Rule-Authorization」ＡＶＰを挿入することによって現在及び次の期間中の許可状態が含められる。
【数２】
2010525732.tif 000004
【００４１】
「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」ＡＶＰは、以下の形式とすることができる。
【数３】
2010525732.tif 000005
【００４６】
「Authorization-State」ＡＶＰ
「Authorization-State」ＡＶＰは、「列挙（ｅｎｕｍｅｒａｔｅｄ）」型とすることができ、「Charging-Rule-Install」ＡＶＰで提供される課金ルール及び課金ルール・ベースに関する許可状態及び不許可理由が指定される。
【００４７】
「Authorization-State」ＡＶＰについては以下の値が定義され得る。
【数４】
2010525732.tif 000006
【００４８】
上記の説明から分かるように、本発明を利用すれば「アクセス拒否メッセージ」に関連する問題に対処することが可能となる。本発明の特定の一実施形態によって解決され得る別の問題は、システム・オペレータがいくつかのサービスを限られた期間、例えば平日の午前８時〜午後６時といった特定の時間帯に多数のユーザに許可したいと望む可能性があることである。ＰＣＲＦとＰＣＥＦの間で使用される現行のＧｘプロトコルを用いてこれを実現するには、影響を受けるすべてのセッションに関するＰＣＥＦ内の許可情報をほぼ同時に更新する必要がある。このような処理は、システム内のＧｘシグナリングのピークが大きくなるため望ましくない。
【００４９】
この問題に対処するために、本発明の上述の実施形態は、制御機能即ちＰＣＲＦから第１のノード即ちＰＣＥＦ／ＧＧＳＮへのアクセス権情報に、ＵＥが１つ又は複数のサービスへのアクセスを許可又は拒否される期間に関する情報を含めるステップを含む。
【００５０】
一例として、いくつかのサービスは、特定の期間だけ、例えばそのサービスがアクティブ化された時点から２４時間以内、あるいは繰り返し期間、例えば平日の午前７時〜午後６時まで、あるユーザを対象に許可することが可能である。
【００５１】
このような情報をＰＣＥＦに提供するために、ＰＣＲＦからＰＣＥＦに提供される上述の「許可コード」、いわゆるＰＣＣルールを、許可状態が変更された特定の時点に関する情報と関連付けることができる。この種のサービスでは、許可状態が変更された後に有効となる次の許可状態も提供されなければならない。このようにして、ＰＣＥＦは、例えばあるユーザがあるサービスへのアクセスを本例では午後６時まで許可され、その後カレンダー時間制限によってそのサービスへのアクセスを拒否されることを判定することが可能となる。無論、逆の場合、即ち、ユーザによるサービスへのアクセスが当初カレンダー時間制限によって一時的に拒否されるが、本例では午後６時を過ぎるとサービスへのアクセスがユーザに許可されるようにすることも可能である。
【００５２】
本発明のカレンダー時間ベース許可の実施形態における別の「ビルディング・ブロック」は、ＰＣＥＦからＰＣＲＦへの新しいポリシー情報要求のスケジューリングを行うバリディティ・タイマ（ｖａｌｉｄｉｔｙ  ｔｉｍｅｒ）である。バリディティ・タイマは、ＰＣＲＦからＰＣＥＦに提供され、典型的には許可状態変更時刻以降、例えば本例では午後６時以降から、後続の許可状態変更時刻以前、即ち本例では遅くとも翌日の午前７時以前に新しいポリシー情報を取得するに足る長さの時間にセットされることになる。
【００５３】
したがって、本発明に係るカレンダー時間ベース許可の実施形態を利用すれば、Ｇｘシグナリングのピークを回避することが可能となる。
【００５４】
ここで、あるサービスに対する時間ベースのアクセス許可又は拒否／許可を説明するために、図４を参照する。図４は、時間ベースのアクセス拒否／許可が使用されるシグナリング図４００である。
【００５５】
図４のシグナリングは、ＵＥと、ＰＣＥＦと、ＰＣＲＦとの間で行われる。このシグナリングは、図４に示される横矢印のとおり以下のように進められる。
（１’）ベアラ・サービス要求を確立する。ＵＥは、ＰＣＥＦ／ＧＧＳＮにベアラ・セットアップ要求を送信する。ＧＰＲＳの場合、この要求は「Activate PDP Context Request」となる。
（２’）Ｇｘ  ＣＣＲを開始する。ＰＣＥＦ／ＧＧＳＮは、ＰＣＲＦとのＧｘセッションを開始し、ＵＥのＩＤ、要求されるＱｏＳ、ＰＬＭＮ‐ＩＤ等を含む。
（３’）Ｇｘ  ＣＣＡを開始する。ＰＣＲＦは、許可されている「Charging-Rule-Base」と、カレンダー時間によって現時点で許可されていない「Charging-Rule-Name」とに関する１つの「Charging-Rule-Install」を含むＣＣＡで応答する。許可状態変更時刻は、翌日の午前７時にセットされる。許可状態変更時刻が経過したときは、サービスへのアクセスがユーザに許可される（次の許可状態）。また、「authorization-validity-time」は、ポリシー情報がＰＣＥＦによって翌日の午後６時までにリフレッシュされなければならないことを示す。該当するＣＣＡは、以下のフォーマットとすることができる。
【数５】
2010525732.tif 000007
（４’）「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」である。許可状態変更時刻は午後６時であり、ポリシー情報は、遅くとも翌日の午前７時に再度リフレッシュしなければならない。新しい値は、以下の形式とすることができる。
【数６】
2010525732.tif 000008
【００５６】
サービスに対するカレンダー・ベースのアクセス許可／拒否と共に使用され得る本発明のＡＶＰのいくつかの例を以下に示す。以下のＡＶＰは単なる例示であり、いかなる場合も本発明の所期の保護範囲を限定するものと解釈されるべきでないことを指摘しておく。
【００５７】
「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」ＡＶＰについては以下の値が定義され得る。
【数７】
2010525732.tif 000009
【００５９】
「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」は、ＰＣＣルールを再要求するイベントを示す。このＡＶＰについては以下の値が定義され得る。
【数８】
2010525732.tif 000010
【００６１】
この値は、「Authorization-Validity-Time」で指定される所与の時刻以前に新しいＰＣＣルールを要求すべきことを示すのに使用される。
【００６２】
注：「Event-Trigger 100」及び「Authorization-Validity-Time」ＡＶＰが提供されない場合も、「Charging-Rule-Authorization」で「Authorization-State-Change-Time」ＡＶＰが提供されている場合は、ＰＣＥＦの新しいＰＣＣ判定が行われるまで次の許可状態が永続的な許可状態となる。このことは、時間ベースのサブスクリプション、例えばサービス「Ａ」の１２時間アクセス等を実現するのに役立つ。
【００６３】
本発明は、２Ｇシステムや、３Ｇ  ＧＰＲＳシステムのような３ＧシステムにおけるＰＣＥＦ／ＧＧＳＮに適した上述のノード１２０も備える。かかるノードは、制御機能１６０からＵＥのアクセス権に関する情報を受信する手段を備える。これらの手段１４５は、図２のプロセッサ１４５として象徴的に示されているが、ハードウェア又はソフトウェアの適切な組合せとすることもできる。
【００６４】
本発明のノードは、前記制御機能からのアクセス権情報を使用することによってＵＥからのサービス・アクセス要求を処理する手段であって、ユーザがアクセスを拒否されるサービスに関するコードＸ、Ｙ、Ｚを含む、前記制御機能即ちＰＣＲＦからのアクセス権情報を処理することも可能なプロセッサ１４５としても適した手段も備える。
【００６５】
適切なことに、プロセッサ１４５は、上述のようにＵＥがアクセスを拒否されたサービスへのアクセス要求のリダイレクト処理も行うとともに、ノード１２０に対してあるサービスへのアクセス要求を行ったＵＥが、要求を行った時刻、週、月等に基づいて、ノード１２０によってアクセスを拒否又は許可され得るように、ＵＥ  １１０が前記サービスのうちの１つ又は複数へのアクセスを許可又は拒否される期間に関する情報も処理する。
【００６６】
まとめとして、本発明によって開示されるＧｘインターフェースの改良型サービス許可を用いると、ＰＣＥＦ／ＧＧＳＮは、リダイレクト・サーバへの選択的なサービス・リダイレクトを実行することが可能となり、リダイレクト・サーバは、エンド・ユーザ即ちＵＥがアクセス要求を行ったサービスであって、通常はアクセスが許可されるサービスへのアクセスが拒否された理由に関する詳細情報を、ＵＥに提供することが可能となる。
【００６７】
本発明によって開示されるＧｘインターフェースを介して送られるカレンダー時間ベースの許可情報は、一定の期間だけ許可されるサービス、あるいは例えば１日又は１週間のうちのある時間帯だけ許可されるサービスについて、ＰＣＥＦ／ＧＧＳＮがサービス・ベース・アクセス制御を実行することが可能となる情報をＰＣＥＦ／ＧＧＳＮに提供する。
【００６８】
この情報を利用すると、その種のサービスで多数のセッションのポリシー情報を同時に更新する必要があるときに現行のＧｘソリューションで生じるシグナリング・ピークを回避することが可能となる。
【００６９】
本発明は、上述及び図示の例示的な実施形態に限定されるものではなく、添付の特許請求の範囲内で自由に変更することが可能である。
【図１】
2010525732.tif 000011
【図２】
2010525732.tif 000012
【図３】
2010525732.tif 000013
【図４】
2010525732.tif 000014
【手続補正書】
【提出日】平成22年4月22日(2010.4.22)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
いくつかのユーザ機器ＵＥ（１１０）と、ＵＥが特定のサービスへのアクセス要求を送信することが可能な第１のノード（１２０）とが存在し得る無線アクセス電気通信システム（２００）で使用される方法（３００）であって、前記システム（２００）は、特定のサービスに対する前記システム内の複数のＵＥのアクセス権に関する情報を保持する制御機能（１６０）も備え、前記システム（２００）は、前記第１のノード（１２０）と前記制御機能（１６０）との間のインターフェースを更に備え、前記方法（３００）は、前記第１のノードにＵＥのアクセス権に関する情報を前記制御機能から受信させるステップ（３）と、前記制御機能からの前記アクセス権情報を使用してＵＥからのサービス・アクセス要求を前記第１のノードに処理させるステップ（５）と、を含み、前記方法は、前記制御機能から前記第１のノードへの前記アクセス権情報に、前記ＵＥがアクセスを拒否されるサービスに関するコード（Ｘ、Ｙ、Ｚ）を含めるステップ（３）と、前記制御機能（１６０）から前記第１のノード（１２０）への前記アクセス権情報に、前記ＵＥ（１１０）が前記サービスのうちの１つ又は複数へのアクセスを許可又は拒否される期間に関する情報を含めるステップ（３）を更に含むことを特徴とする、方法（３００）。
【請求項２】
前記制御機能（１６０）からの前記情報に従ってアクセスが拒否されるサービスへのアクセス要求が、ＵＥ（１１０）によって行われた場合に、前記コード（Ｘ、Ｙ、Ｚ）は、前記アクセス要求を前記システム内の第２の機能（１８０〜１８２）にリダイレクトするために前記第１のノード（１２０）によって使用され、前記方法は、前記第２の機能（１８０〜１８２）に拒否理由に関する明示的なメッセージを要求元の前記ＵＥに送信させるステップ（８）を更に含む、請求項１に記載の方法（３００）。
【請求項３】
前記第１のノード（１２０）は、ＰＣＥＦ（ポリシー課金実施機能）として動作するように構成された２Ｇ又は３ＧシステムのＧＧＳＮであり、前記制御機能は、前記システムのＰＣＲＦ（ポリシー及び課金ルール機能）である、上記請求項のいずれかに記載の方法（３００、４００）。
【請求項４】
いくつかのユーザ機器ＵＥ（１１０）と、ＵＥが特定のサービスへのアクセス要求を送信することが可能な第１のノード（１２０）とが存在し得る無線アクセス電気通信システム（２００）で使用されるインターフェース（１５０であって、前記システム（２００）は、特定のサービスに対する前記システム内の複数のＵＥのアクセス権に関する情報を保持する制御機能（１６０）も備え、前記インターフェースは、前記第１のノード（１２０）と前記制御機能（１６０）との間で、様々な情報の中でもとりわけ、いくつかのサービスに対するＵＥのアクセス権に関する情報を前記制御機能から前記第１のノード（１２０）に送るのに使用されるインターフェース（１５０）であり、前記インターフェースは、前記アクセス権情報と共に、前記ＵＥがアクセスを拒否されるサービスに関する１つ又は複数のコード（Ｘ、Ｙ、Ｚ）を含むことを特徴とし、かつ、前記制御機能（１６０）から前記第１のノード（１２０）への前記アクセス権情報は、前記ＵＥ（１１０）が前記サービスのうちの１つ又は複数へのアクセスを許可又は拒否される期間に関する情報を含むことを特徴とするインターフェース（１５０）。
【請求項５】
前記制御機能（１６０）からの前記情報に従ってアクセスが拒否されるサービスへのアクセス要求が、ＵＥ（１１０）によって行われた場合に、前記コード（Ｘ、Ｙ、Ｚ）は、前記アクセス要求を前記システム内の第２の機能（１８０〜１８２）にリダイレクトするために前記第１のノードによって使用され得る、請求項４に記載のインターフェース（１５０）。
【請求項６】
前記インタフェースは、２Ｇシステム、又は３Ｇ  ＧＰＲＳシステム等の３ＧシステムにおけるＧｘインターフェースである、請求項４乃至５のいずれかに記載のインターフェース（１５０）。
【請求項７】
いくつかのユーザ機器ＵＥ（１１０）が存在し得る無線アクセス電気通信システム（２００）で使用され、ＵＥが特定のサービスへのアクセス要求を送信することが可能なノード（１２０）であって、前記ノードは、特定のサービスに対する前記システム内の複数のＵＥのアクセス権に関する情報を保持する制御機能（１６０）と前記システム内で情報を交換する手段を備え、前記情報の交換は、前記ノード（１２０）と前記制御機能（１６０）との間のインターフェース（１５０）を介して実行され、前記ノードは、前記制御機能（１６０）からＵＥのアクセス権に関する情報を受信する手段（１４５）と、前記制御機能からの前記アクセス権情報を使用することによってＵＥからのサービス・アクセス要求を処理する手段（１４５）と、を備え、前記ノードは、前記ＵＥがアクセスを拒否されるサービスに関するコード（Ｘ、Ｙ、Ｚ）を含む前記制御機能からの前記アクセス権情報を処理する手段（１４５）と、前記ノード（１２０）に対してあるサービスへのアクセス要求を行ったＵＥが、前記要求を行った時刻、週、月等に基づいて、前記ノード（１２０）によってアクセスを拒否又は許可され得るように、前記ＵＥ（１１０）が前記サービスのうちの１つ又は複数へのアクセスを許可又は拒否される期間に関する情報が含められた前記制御機能（１６０）からのアクセス権情報を処理する手段（１４５）と、を更に備えることを特徴とする、ノード（１２０）。
【請求項８】
アクセス権情報を処理する前記手段（１４５）は、前記制御機能（１６０）からの前記情報に従ってアクセスが拒否されるサービスへのアクセス要求がＵＥ（１１０）によって行われた場合に、前記アクセス要求を前記システム内のいくつかの第２の機能（１８０〜１８２）のうちの１つにリダイレクトするために、前記コード（Ｘ、Ｙ、Ｚ）は前記手段によって使用され、前記コードは、適切な前記第２の機能を選択するのに使用される、請求項７に記載のノード（１２０）。
【請求項９】
前記システム内のＰＣＥＦ（ポリシー課金実施機能）として動作するように構成された２Ｇ又は３ＧシステムのＧＧＳＮである、請求項７乃至８のいずれかに記載のノード（１２０）。
【国際調査報告】
2010525732.tif 000015
2010525732.tif 000016
2010525732.tif 000017
2010525732.tif 000018
2010525732.tif 000019
2010525732.tif 000020