JP4903816B2

JP4903816B2 - 通信ネットワークにおいて用いる方法及び装置

Info

Publication number: JP4903816B2
Application number: JP2008552697A
Authority: JP
Inventors: ユベルトプリィツィビィズ，; ティモフォルスマン，; ニエト，アナマリアロペス
Original assignee: テレフオンアクチーボラゲットエルエムエリクソン（パブル）
Priority date: 2006-02-07
Filing date: 2006-02-07
Publication date: 2012-03-28
Anticipated expiration: 2026-02-07
Also published as: US8175576B2; ATE530039T1; EP1982545B1; BRPI0621025A2; CN101366311B; EP1982545A1; JP2009526425A; CN101366311A; WO2007090463A1; ES2374089T3; US20090215454A1

Description

本発明は、例えばＩＰマルチメディア・サブシステムを有する汎用移動通信システムのような通信ネットワークにおいて用いる方法及び装置に関する。

ＩＰマルチメディアサービスは、音声、映像、メッセージング、データ等の動的な組み合わせを、同一のセッション内で提供する。基本アプリケーションの数及び組み合わせ可能なメディアの数が増加することにより、エンドユーザに提供されるサービスの数が増加し、個人間の通信エクスペリエンスが豊かになるであろう。このことは、所謂「組み合わせＩＰマルチメディア」サービスを含む、新世代のパーソナライズされた豊かなマルチメディア通信サービスにつながるであろう。

背景として、ＵＭＴＳ（汎用移動通信システム）は、加入者に対してより高いデータレートと高度なサービスとを提供するように設計された第３世代の無線システムである。ＵＭＴＳは汎欧州デジタル移動電話方式（ＧＳＭ）の後継であり、ＧＳＭとＵＭＴＳとの間の重要な進化段階には汎用パケット無線サービス（ＧＰＲＳ）がある。ＧＰＲＳはＧＳＭコアネットワークに対してパケット交換方式を導入し、パケットデータネットワーク（ＰＤＮ）に対する直接アクセスを可能にする。これにより、ＩＳＤＮの６４ｋｂｐｓの限界をはるかに超える高いデータレートでのパケット交換方式の伝送がＧＳＭ呼ネットワークを介して可能になり、このことは２Ｍｂｐｓにまで及ぶＵＭＴＳのデータ伝送レートにとって不可欠である。ＵＭＴＳは、欧州電気通信標準化協会（ＥＴＳＩ）や電波産業会（ＡＲＩＢ）などの、地域の標準化団体の集合である第３世代パートナーシップ・プロジェクト（３ＧＰＰ）によって標準化された。更に詳しくは３ＧＰＰＴＳ２３．００２を参照のこと。ＵＭＴＳの標準化は、段階的に進行してきた。最初の段階はリリース’９９として知られていた。リリース’９９の仕様は、ＵＭＴＳ地上無線アクセスネットワーク（ＵＴＲＡＮ）、回線交換式コアネットワーク（ＣＳ−ＣＮ）、及びパケット交換式コアネットワーク（ＰＳ−ＣＮ）から構成される基本的なアーキテクチャを規定する。リリース’９９の仕様は、従来の回線交換式サービスに加えてパケット交換式サービスを提供する。標準化のプロセスにおける次の段階はリリース４であり、’９９のアーキテクチャに対して新たなサービスを追加するものであった。リリース５は重要な変化を表し、単一集中型のパケットベースのネットワークを介して、従来の電話サービスに加えてパケット交換式サービスを提供するものであった。

ＵＭＴＳリリース５のアーキテクチャは、従来の電話サービスに加えて新たなマルチメディアサービスをサポートするために、ＩＰマルチメディア・サブシステムとして知られる新しいサブシステムをＰＳ−ＣＮに対して追加した。ＩＭＳは、移動通信ネットワークを介してＩＰマルチメディアサービスを提供する（３ＧＰＰＴＳ２２．２２８、ＴＳ２３．２２８、ＴＳ２４．２２９、ＴＳ２９．２２８、ＴＳ２９．２２９、ＴＳ２９．３２８、及びＴＳ２９．３２９のリリース５から７）。ＩＭＳは、標準化されたＩＭＳサービス・イネーブラの使用を通じてエンドユーザの個人対個人の通信エクスペリエンスを豊かにする重要な特徴を提供する。ＩＭＳサービス・イネーブラは、ＩＰベースのネットワークを介した、新しい豊かな個人対個人（クライアント対クライアント）の通信サービスに加えて個人対コンテンツ（クライアント対サーバ）のサービスを促進するものである。ＩＭＳは、ＰＳＴＮ／ＩＳＮＤ（公衆交換電話網／サービス総合デジタル網）に加えてインターネットに対しても接続可能である。

ＩＭＳは、ユーザ端末間の（或いは、ユーザ端末とアプリケーションサーバとの間の）呼またはセッションをセットアップして制御するために、セッション開始プロトコル（ＳＩＰ）を利用する。ＳＩＰシグナリングによって搬送されるセッション記述プロトコル（ＳＤＰ）は、セッションのメディアコンポーネントを記述して交渉するために使用される。ＳＩＰがユーザ対ユーザのプロトコルとして作られたのに対し、ＩＭＳはオペレータとサービスプロバイダとがサービスに対するユーザのアクセスを制御し、それに従ってユーザに料金を請求することを可能とする。３ＧＰＰは、ユーザ装置（ＵＥ）とＩＭＳとの間のみならずＩＭＳ内のコンポーネント間のシグナリングのためにＳＩＰを選択した。

図１は、訪問先ネットワーク２０２内に位置するユーザ装置（ＵＥ）２０４を含むＵＭＴＳ通信ネットワーク２００を示す説明図である。ＵＥ２０４はＵＴＲＡＮ２０６を介して在圏ＧＰＲＳサポートノード（ＳＧＳＮ）２０８に接続されており、ＳＧＳＮは次に関門ＧＰＲＳサポートノード（ＧＧＳＮ）２１０と通信している。ＧＧＳＮ２１０は、ＵＥ２０４にとって訪問先ＩＭＳネットワーク内での最初のコンタクトポイントであるプロキシ呼セッション制御機能（Ｐ−ＣＳＣＦ）２１２と通信する。Ｐ−ＣＳＣＦ２１２は、ＳＩＰ登録メッセージ及びセッション確立メッセージをホームネットワーク２１４へ転送する。

ホームネットワーク２１４内の最初のコンタクトポイントは、ＩＭＳアーキテクチャにおけるオプションのノードであるインテロゲーティング呼セッション制御機能（Ｉ−ＣＳＣＦ）２１６である。Ｉ−ＣＳＣＦ２１６の主目的は、サービング呼セッション制御機能（Ｓ−ＣＳＣＦ）２１８の位置を発見するためにホーム加入者サーバ（ＨＳＳ）２２０に対して問い合わせることである。Ｓ−ＣＳＣＦ２１８はＩＭＳネットワークのためにセッション管理を実行し、ネットワーク内にいくつかのＳ−ＣＳＣＦが存在してもよい。ＨＳＳ２２０は中央集中型の加入者データベースであり、以前のＵＭＴＳリリースからのホームロケーションレジスタ（ＨＬＲ）から進化したものである。ＨＳＳ２２０は、加入者の位置情報及び加入者の契約情報を提供するために、Ｉ−ＣＳＣＦ及びＳ−ＣＳＣＦとやりとりする。

通信ネットワーク２００は、ホームネットワーク２１４内に位置する、アプリケーションサーバ２２２、データベース２２４、及びメールサーバ２２６を更に含む。Ｓ−ＣＳＣＦ２１８から意図された宛先に対してシグナリングメッセージが渡される。意図された宛先は、ＵＥ２３０を含む他のリリース５によるＩＭＳネットワーク２２８でもよいし、メディアゲートウェイ制御機能（ＭＧＣＦ）を介してやりとりされるＰＳＴＮを含むレガシーネットワーク２３２でもよいし、ＩＰネットワーク２３４でもよい。

ＵＭＴＳ通信ネットワーク２００の動作、及びそのようなネットワーク内の多様なコンポーネントに関する具体的な詳細は、http://www.3gpp.orgから入手可能なＵＭＴＳの技術仕様から知ることができる。

ＵＭＴＳ内でのＳＩＰの使用に関する更なる詳細は３ＧＰＰ技術仕様ＴＳ２４．２２８Ｖ５．８．０（２００４−０３）から知ることができるが、ここで図２を参照して概要を提供する。図２は、ＧＰＲＳ／ＰＳアクセスネットワークの事例において、ＩＭＳがどのようにして移動体ネットワークのアーキテクチャに適合するかを概略的に示す（ＩＭＳはもちろん他のアクセスネットワーク上でも動作可能である）。呼セッション制御機能（ＣＳＣＦ）は、ＩＭＳ内でＳＩＰプロキシとして動作する。上述の通り、３ＧＰＰアーキテクチャは３種類のＣＳＣＦを規定する。即ち、ＳＩＰ端末にとってのＩＭＳ内での最初のコンタクトポイントであるプロキシＣＳＣＦ（Ｐ−ＣＳＣＦ）、ユーザが加入しているサービスをユーザに提供するサービングＣＳＣＦ（Ｓ−ＣＳＣＦ）、及び、正しいＳ−ＣＳＣＦを特定し、ＳＩＰ端末から受信した要求をＰ−ＣＳＣＦを介してそのＳ−ＣＳＣＦへ転送する役割を担うインテロゲーティングＣＳＣＦ（Ｉ−ＣＳＣＦ）である。

ユーザは、仕様にあるＳＩＰＲＥＧＩＳＴＥＲメソッドを用いてＩＭＳに登録する。これは、ＩＭＳにアタッチし、ＳＩＰユーザアイデンティティに到達可能なアドレスをＩＭＳに知らせるためのメカニズムである。３ＧＰＰでは、ＳＩＰ端末が登録を行う際に、ＩＭＳはユーザを認証し、利用可能なＳ−ＣＳＣＦのセットから１つをそのユーザに割り当てる。Ｓ−ＣＳＣＦを割り当てる基準は３ＧＰＰによっては指定されていないが、その基準には負荷分散とサービスが必要とする要件とが含まれるであろう。Ｓ−ＣＳＣＦの割り当ては、ＩＭＳベースのサービスへのユーザのアクセスの制御（及び、ユーザのアクセスに対する料金の請求）をする上での鍵となることに留意されたい。オペレータは、ユーザ対ユーザの直接のＳＩＰセッションを防止するメカニズムを提供してもよい。さもなければ、ユーザ対ユーザの直接のＳＩＰセッションは、Ｓ−ＣＳＣＦを迂回してしまうだろう。

登録プロセスの間は、もしＳ−ＣＳＣＦがまだ選択されていない場合、Ｓ−ＣＳＣＦを選択することがＩ−ＣＳＣＦの責務である。Ｉ−ＣＳＣＦは、ホームネットワークのホーム加入者サーバ（ＨＳＳ）から必要とされるＳ−ＣＳＣＦの能力を受信し、受信した能力に基づいて適切なＳ−ＣＳＣＦを選択する。（ユーザが他の当事者からの呼を受けており、その時点でＳ−ＣＳＣＦを割り当てられていない場合にも、ユーザに対するＳ−ＣＳＣＦの割り当てがＩ−ＣＳＣＦによって行われることに留意されたい。）登録されたユーザが引き続いてセッション要求をＩＭＳに送る時は、Ｐ−ＣＳＣＦは、登録プロセスの間にＳ−ＣＳＣＦから受信した情報に基づいて選択されたＳ−ＣＳＣＦに対してその要求を転送することができる。

ＩＭＳサービスネットワーク内では、アプリケーションサーバ（ＡＳ）はＩＭＳサービス機能を実現するためのものである。アプリケーションサーバは、ＩＭＳシステム内のエンドユーザにサービスを提供する。そして、３ＧＰＰの規定するＭｒインタフェース上でエンドポイントとして接続されてもよいし、３ＧＰＰの規定するＩＳＣインタフェース上でＳ−ＣＳＣＦによって「結合」されてもよい。後者の場合、どのアプリケーションサーバが「結合」されるべきか判断するために、ＳＩＰセッションの確立中にＳ−ＣＳＣＦによって初期フィルタ条件（ＩＦＣ）が使用される（或いは実際には、何らかのＳＩＰメソッド、セッション、又は非セッション関連の目的で）。ＩＦＣは、ユーザのユーザプロファイルの一部として、ＩＭＳ登録手順の間にＳ−ＣＳＣＦによってＨＳＳから取得される。

あらゆる移動体コアネットワークの重要な機能は、サービスレベルポリシーの実施である。これらのポリシーはとりわけ、どの特定のユーザが許可され又は許可されず、また、ユーザがどのように料金請求されるかを指示する。特定のユーザが受けるサービス品質（ＱｏＳ）を指示する他のポリシーも存在するだろう。全般的なポリシー宣言として考えられ得るサービスレベルポリシーは、詳細なポリシー「ルール」を使用して実行に移される。１つのポリシーがポリシールールのセットを必要とするかもしれない。各ポリシールールは、ポリシールールが適用されるパケットを特定する１番目のサブジェクトパートと、２番目のアクションパートとを含む。サブジェクトパートは、場合によってはパケットフィルタでもよい。ポリシールールは、ユーザの全トラヒックが通過する１つのノードにインストールされるか、或いは、ユーザの全トラヒックを共同で処理する複数のノードにインストールされる。

３ＧＰＰの場合、ポリシー機能及び料金請求機能が、ユーザに高レベルのサービスを提供するアプリケーション機能（ＡＦ）からのシグナリングに基づいて所謂ポリシー＆チャージング・ルール機能（ＰＣＲＦ）論理ノードから制御されるであろうことが想定される。例えば上述のＩＰマルチメディア・サブシステム（ＩＭＳ）を考える。ＩＭＳを介して呼がセットアップされる場合、ポリシー及び料金請求の観点からはＩＭＳのプロキシ呼セッション制御機能（Ｐ−ＣＳＣＦ）がＡＦとして機能し、ＰＣＲＦに対して新しいセッションを通知する。特に、Ｐ−ＣＳＣＦはＰＣＲＦに対して、ＩＰフローの記述子（ディスクリプタ）と、適用するＱｏＳの概略定義とを送信する。ＰＣＲＦは各ユーザについて、そのユーザのためのパケットフローがどのように処理されるか（即ち、サービスの許可／拒否、料金請求、実際のＱｏＳ等）を記述するポリシーを自身にインストールしている。（これはＰＣＲＦに手作業でインストールされてもよいし、例えばＰＣＲＦが「訪問先」ネットワーク内位置する場合にユーザのホームネットワークによってリモートにインストールされてもよい。）

このシナリオを更に詳細に検討すると、ＡＦはＰＣＲＦに対して、５要素を含むベクトルの全部又は一部の形式でフロー記述子を送信する。このベクトルは、（１）ＩＰ発信元アドレス、（２）ＩＰ宛先アドレス、（３）使用される伝送プロトコル（例えば、ＴＣＰ又はＵＤＰ）の識別情報、（４）発信元ポート番号、及び（５）宛先ポート番号を含む。ＰＣＲＦは、ポリシールールのセットを生成するためにポリシーをこのベクトルに適用する。例えばポリシーは、ベクトルに含まれるＩＰアドレス間及びポート番号間の呼に対して適用される料金及びＱｏＳを指定することができる。結果として得られるルールは、サブジェクトパートとして５要素ベクトルを含み、アクションパートに適切な料金及びＱｏＳの振る舞いを含むことになろう。ＰＣＲＦは、ルールを実行に移すトラヒックノードにポリシールールをインストールする。実施ノード(enforcement node)を通過するパケットのアドレス番号／ポート番号がルールのフィルタパートに合致すると、そのルールで指定された動作が実行される。トラヒックノードはポリシー実施機能（ＰＥＦ）と呼ばれ、ＧＰＲＳを組み込んだセルラネットワークの場合、これは通常、ＧＰＲＳ関門サポートノード（ＧＧＳＮ）内、又はＧＧＳＮの進化形内に位置する。

フレキシブル・ベアラ・チャージング（ＦＢＣ）及びサービスベース・ローカルポリシーは、３ＧＰＰリリース６（それぞれＴＳ２３．１２５及びＴＳ２３．２０７）において規定された２つのポリシー制御アーキテクチャである。２つのアーキテクチャは３ＧＰＰリリース７ではＴＲ２３．８０３が目指す進化の方向に一致して１つのポリシー＆チャージング制御（ＰＣＣ）アーキテクチャに統合されている。ポリシー機能は、多数のエンティティを跨いでネットワーク内にばらまかれる。多数のエンティティとは、添付の図面の図３に示すように、アプリケーション機能（ＡＦ）、ポリシー＆チャージング・ルール機能（ＰＣＲＦ）、及びゲートウェイ（ＧＷ）である（ＴＲ２３．８０３より）。

リリース６によるＧｏ上でのポリシー制御では、バインドメカニズムは許可トークン及び１以上のフロー識別子を使用する。トークンの重要な役割は、そのトークンを発行したノードであるのでフロー識別子によって記述されるフローのための許可を求めるためにコンタクトすべきノードである、ポリシー決定機能（ＰＤＦ）を発見するためのアドレス情報をＧＧＳＮ（ＧＷ）に対して提供することである。リリース６のフローベース・チャージング・アーキテクチャは、（ＧＷ内の）トラヒックプレーン機能（ＴＰＦ）とユーザセッションのためにチャージング・ルール機能（ＣＲＦ）に提供される情報を必要とするＡＦとの両方が、同一のＣＲＦにコンタクトすることを確実にするものである。フローベース・チャージングでは、ＴＰＦはＵＥが接続しているアクセスポイント（例えば、アクセスポイント名（ＡＰＮ））に基づいてＣＲＦにコンタクトし、ＡＦはそこで経験するエンドユーザの（ＩＰ）アドレスに基づいてＣＲＦにコンタクトする。

リリース７のＰＣＣは、ＰＣＲＦアドレス指定するＧＷのためにフローベース・チャージングに関するＣＲＦアドレス指定メカニズムに対するリリース６のＦＢＣＴＰＦを再利用するであろう。フローベース・チャージングはＴＰＦがコンタクトするものと同一のＣＲＦをＡＦが発見することに関する課題を解決するので、リリース７のＡＦは、ＰＣＲＦアドレス指定するＡＦのためにフローベース・チャージングに関するＣＲＦアドレス指定メカニズムに対するリリース６のＡＦを再利用するであろう。それゆえ、ＵＥにサービス提供するＰＣＲＦを選択するのはＧＷであり、ＡＦは、サービス提供する同一のＰＣＲＦに対して自分の許可を提供することを確実にするであろう。

本発明の第１の態様によれば、通信のネットワークの移動ノードを前記ネットワークのサブシステムに登録する方法であって、前記ネットワークは、前記ネットワークのユーザのためのポリシールール及び料金請求ルールを維持管理するか又はこれにアクセスする少なくとも１つのノードと、トラヒックフローに対する前記ポリシールール及び前記料金請求ルールの実施のための少なくとも１つのノードと、を備え、前記方法は、前記ネットワークのプロキシノードにおいて前記移動ノードから登録要求メッセージを受信するステップと、前記移動ノードのためのポリシールール及び料金請求ルールのノードの候補を選択するステップと、前記移動ノードにサービス提供するポリシールール及び料金請求ルールの実施ノードによってポリシールール及び料金請求ルールのノードの前記候補が既に選択されているか否かを判断するステップと、前記判断に応じて前記登録の手順の続くステップを実行するステップと、を備えることを特徴とする方法が提供される。

前記ネットワークは汎用移動通信システムでもよい。

前記移動ノードは前記汎用移動通信システムのユーザ装置でもよい。

ポリシールール及び料金請求ルールの前記ノードそれぞれは、前記汎用移動通信システムのポリシー＆チャージング・ルール機能を含んでもよい。

ポリシールール及び料金請求ルールの前記ノードそれぞれは、関門ＧＰＲＳサポートノードなどの前記汎用移動通信システムのゲートウェイノードを含んでもよい。

前記プロキシノードは、前記汎用移動通信システムのアプリケーション機能を含んでもよい。

前記プロキシノードは、前記汎用移動通信システムのプロキシ呼セッション制御機能を含んでもよい。

前記サブシステムはＩＰマルチメディア・サブシステムでもよい。

前記判断するステップは、前記プロキシノードからポリシールール及び料金請求ルールのノードの前記候補へ、前記移動ノードにサービス提供するポリシールール及び料金請求ルールの実施ノードによって前記候補が既に選択されているか否かを判断する際にポリシールール及び料金請求ルールのノードの前記候補が使用する情報を含む検証要求を送信するステップと、ポリシールール及び料金請求ルールのノードの前記候補から受信した応答を前記判断の基礎とするステップと、を含んでもよい。

前記検証要求は、前記プロキシノードとポリシールール及び料金請求ルールのノードの前記候補との間のアプリケーション機能セッションの一部として送信されてもよい。

前記情報は前記移動ノードのＩＰアドレスを含んでもよい。

前記方法は、前記移動ノードの前記ＩＰアドレスがポリシールール及び料金請求ルールのノードの前記候補に既に格納されているか否かを確認するステップを備えてもよい。

前記方法は、前記移動ノードにサービス提供するポリシールール及び料金請求ルールの実施ノードによってポリシールール及び料金請求ルールのノードの前記候補が既に選択されていると判断された場合に、前記移動ノードを前記サブシステムに登録するステップを継続するステップを備えてもよい。

前記方法は、前記移動ノードにサービス提供するポリシールール及び料金請求ルールの実施ノードによってポリシールール及び料金請求ルールのノードの前記候補がまだ選択されていないと判断された場合に、前記移動ノードにサービス提供するポリシールール及び料金請求ルールの実施ノードによって既に選択されていると判断されるものが選択されるか、又は更に選択する候補が存在しなくなるまで、ポリシールール及び料金請求ルールのノードの１以上の更なる候補について前記選択するステップ及び前記判断するステップを再び実行するステップを備えてもよい。

前記方法は、前記移動ノードにサービス提供するポリシールール及び料金請求ルールの実施ノードによって既に選択されていると判断されるポリシールール及び料金請求ルールのノードの候補が選択されない場合に、少なくともその関係するプロキシノードに関しては、前記移動ノードを前記サブシステムに登録する要求を拒否するステップを備えてもよい。

前記方法は、更なるプロキシノードについて前記各ステップを実行するステップを備えてもよい。

本発明の第２の態様によれば、通信のネットワークの移動ノードを前記ネットワークのサブシステムに登録するために用いる装置であって、前記ネットワークは、前記ネットワークのユーザのためのポリシールール及び料金請求ルールを維持管理するか又はこれにアクセスする少なくとも１つのノードと、トラヒックフローに対する前記ポリシールール及び前記料金請求ルールの実施のための少なくとも１つのノードと、を備え、前記装置は、前記移動ノードから登録要求メッセージを受信する手段と、前記移動ノードのためのポリシールール及び料金請求ルールのノードの候補を選択する手段と、前記移動ノードにサービス提供するポリシールール及び料金請求ルールの実施ノードによってポリシールール及び料金請求ルールのノードの前記候補が既に選択されているか否かを判断する手段と、前記判断に応じて前記登録の手順の続くステップを実行する手段と、を備えることを特徴とする装置が提供される。

本発明の第３の態様によれば、通信のネットワークの移動ノードを前記ネットワークのサブシステムに登録する方法の一部として装置が用いる方法であって、前記装置は前記ネットワークのユーザのためのポリシールール及び料金請求ルールを維持管理するか又はこれにアクセスする少なくとも１つのノードのうちの１つであり、前記ネットワークはトラヒックフローに対する前記ポリシールール及び前記料金請求ルールの実施のための少なくとも１つのノードを備え、前記装置が用いる前記方法は、前記ネットワークのプロキシノードでの前記移動ノードからの登録要求メッセージの受信と、前記移動ノードのためのポリシールール及び料金請求ルールのノードの候補としての前記装置の選択と、に続いて、前記移動ノードにサービス提供するポリシールール及び料金請求ルールの実施ノードによってポリシールール及び料金請求ルールのノードの前記候補が既に選択されているか否かを判断することによって、前記判断に応じて前記登録の手順の続くステップを実行可能にするステップを備えることを特徴とする方法が提供される。

本発明の第４の態様によれば、通信のネットワークの移動ノードを前記ネットワークのサブシステムに登録する方法において用いる装置であって、前記装置は前記ネットワークのユーザのためのポリシールール及び料金請求ルールを維持管理するか又はこれにアクセスする少なくとも１つのノードのうちの１つであり、前記ネットワークはトラヒックフローに対する前記ポリシールール及び前記料金請求ルールの実施のための少なくとも１つのノードを備え、前記装置は、前記ネットワークのプロキシノードでの前記移動ノードからの登録要求メッセージの受信と、前記移動ノードのためのポリシールール及び料金請求ルールのノードの候補としての前記装置の選択と、に続いて、前記移動ノードにサービス提供するポリシールール及び料金請求ルールの実施ノードによってポリシールール及び料金請求ルールのノードの前記候補が既に選択されているか否かを判断することによって、前記判断に応じて前記登録の手順の続くステップを実行可能にする手段を備えることを特徴とする装置が提供される。

本発明の第５の態様によれば、装置上で動作すると本発明の第１又は第３の態様に従うの方法を前記装置に実行させることを特徴とする動作プログラムが提供される。

本発明の第６の態様によれば、装置内にロードされると前記装置が本発明の第１又は第３の態様に従う装置になるようにすることを特徴とする動作プログラムが提供される。

前記動作プログラムは、搬送媒体によって搬送されてもよい。前記搬送媒体は伝送媒体でもよい。前記搬送媒体は記録媒体でもよい。

上述の提案された３ＧＰＰリリース７のポリシー＆チャージング制御（ＰＣＣ）アーキテクチャの仕様では、ポリシー制御機能を実装するエンティティがそのようなエンティティの障害やエンティティ間の通信が失われたことを原因として代替のエンティティに責務を渡すことを可能にする冗長性に関する観点が抜けているということを、本願の出願人は認識した。

ＩＭＳと通信するＵＥのために発見されて選択されたＰ−ＣＳＣＦがポリシー及び料金請求の制御の目的でＵＥのためのＡＦとして動作可能なものであるということを、提案された仕様は保証しない。その結果、ＵＥはＩＭＳに成功裏に登録できるかもしれないが、ＵＥにサービス提供するＰＣＲＦエンティティとは異なるＰＣＲＦエンティティをＰ−ＣＳＣＦが選択した場合、後でＵＥがサービスを起動しようとする際にＩＭＳサービスを利用することが妨げられる可能性がある。

本発明の実施形態を使用した結果として、ＵＥがＩＭＳに登録しようとする時に、Ｐ−ＣＳＣＦがＵＥにサービス提供する正しいＰＣＲＦエンティティと通信可能であるということが概ね確実になる。このことは、Ｐ−ＣＳＣＦが選択したＰＣＲＦが正しいものであるということを選択したＰＣＲＦに対して確認するように手配することにより、実現可能である。ＵＥによって発見されて選択されたＰ−ＣＳＣＦにとっての基本的なメカニズムは、ＵＥがＩＭＳに登録している時に、そのＵＥのためにＰ−ＣＳＣＦが選択したＰＣＲＦエンティティがそのＵＥに既にサービス提供しているものであるか否かを判定することである。

ここで図４及び図５を参照して、このコンセプトを更に詳細に説明する。図４は、ＵＥ４、ゲートウェイ（ＧＷ）１０、Ｐ−ＣＳＣＦ１２、及びＰＣＲＦ１３−１を図示し、１５とラベル付けされた部分で表される残りのＩＭＳを含む。図５は、２つの異なるＰＣＲＦ１３−１及び１３−２が示されていることを除き、多数の図４と同一の部分を示すが、残りのＩＭＳ１５は示されていない。図４に示すシグナリングフローは、ＩＭＳへの登録が最終的に成功した場合を説明するために使用するものであり、図５に示すシグナリングフローは、ＩＭＳへの登録が最終的に失敗した場合を説明するために使用するものである。

ここで本発明の実施形態に従う成功したＩＭＳ登録の例を説明するために図４を参照する。

図４のステップ１
ＵＥ４はＩＭＳシグナリングで使用するためのベアラ要求を送信する。

図４のステップ２
まだ割り当てられていない場合、ＧＷ１０はＵＥ４に対してＩＰアドレスを割り当てることができる。ＧＷ１０はＵＥ４にサービス提供するＰＣＲＦエンティティを１つ選択する。この例では、ＧＷ１０はＰＣＲＦ１３−１を選択する。

図４のステップ３
ＧＷ１０はＰＣＲＦ１３−１に対して、ＵＥ４のＩＰアドレスを含む許可要求を送信する。

図４のステップ４
まだ生成されていない場合、ＰＣＲＦ１３−１はＵＥ４のための状態を生成してＵＥ４のＩＰアドレスを格納することができる。ＰＣＲＦ１３−１は、事前設定されたポリシーに従って、ベアラと、ＩＭＳシグナリングのためのその使用とを許可する。ＰＣＲＦ１３−１は、ＩＭＳシグナリングのための関連するＰＣＣルールを判断する。

図４のステップ５
ＰＣＲＦ１３−１は、ＩＭＳシグナリングのためのＰＣＣルールを伴う許可成功応答を送信する。

図４のステップ６
ＧＷ１０はＵＥ４に対してベアラ成功応答を送信する。

図４のステップ７
ＵＥ４はＰ−ＣＳＣＦ１２を発見して選択し、Ｐ−ＣＳＣＦ１２に対して登録要求（ＳＩＰＲＥＧＩＳＴＥＲメッセージ）を送信することによってＩＭＳに登録しようとする。

（図４のステップ１から７は、以前から提案されていたメカニズムに従って実行可能である。）

図４のステップ８
Ｐ−ＣＳＣＦ１２が登録要求を受信すると、登録しようとしているＵＥ４のＩＰアドレスをその要求から特定する。Ｐ−ＣＳＣＦ１２はＰＣＲＦエンティティからそのＩＰアドレスのために設定された１つを選択し（この場合はＰＣＲＦ１３−１）、その選択の有効性を確認することを決定する。

（この時点でＰＣＲＦを選択してその選択の有効性を確認することを決定することは、以前は提案されていなかった。）

図４のステップ９
Ｐ−ＣＳＣＦ１２は選択されたＰＣＲＦ１３−１に対して、図４のステップ８で特定されたＩＰアドレスを含む検証要求を送信する。異なる実装オプションとして、検証要求は、（ＡＦセッションとは無関係の）スタンドアロンのトランザクションを開始してもよいし、新しいＡＦセッションを開始してもよい。検証のために新しいＡＦセッションが使用される場合、Ｐ−ＣＳＣＦ１２は、このＡＦセッションと、ＩＭＳ登録及びユーザプレーンにおけるＩＭＳシグナリングフローのうちの少なくとも一方との間の関連付けを生成することができる。

（このステップは以前は提案されていなかった。）

図４のステップ１０
ＰＣＲＦ１３−１は、自分がこのＩＰアドレスにサービス提供しているか否かを確認する。この例では、結果は成功である。

（このステップは以前は提案されていなかった。）

図４のステップ１１
ＰＣＲＦ１３−１はＰ−ＣＳＣＦ１２に対して、検証成功応答を送信する。

（このステップは以前は提案されていなかった。）

図４のステップ１２から１４
以前から提案されていたメカニズムに従って、ＩＭＳに対する登録成功が完了する。

ここで本発明の実施形態に従う失敗したＩＭＳ登録の例を説明するために図５を参照する。

図５のステップ１から７
これらのステップは上述した図４のステップ１から７と同一である。

図５のステップ８
Ｐ−ＣＳＣＦ１２が登録要求を受信すると、登録しようとしているＵＥ４のＩＰアドレスをその要求から特定する。Ｐ−ＣＳＣＦ１２はＰＣＲＦエンティティからそのＩＰアドレスのために設定された１つを選択し（この場合はＰＣＲＦ１３−２）、その選択の有効性を確認することを決定する。

図５のステップ９
Ｐ−ＣＳＣＦ１２は選択されたＰＣＲＦ１３−２に対して、図５のステップ８で特定されたＩＰアドレスを含む検証要求を送信する。異なる実装オプションとして、検証要求は、（ＡＦセッションとは無関係の）スタンドアロンのトランザクションを開始してもよいし、新しいＡＦセッションを開始してもよい。検証のために新しいＡＦセッションが使用される場合、Ｐ−ＣＳＣＦ１２は、このＡＦセッションと、ＩＭＳ登録及びユーザプレーンにおけるＩＭＳシグナリングフローのうちの少なくとも一方との間の関連付けを生成することができる。

（このステップは以前は提案されていなかった。）

図５のステップ１０
ＰＣＲＦ１３−２は、自分がこのＩＰアドレスにサービス提供しているか否かを確認する。この例では、ＰＣＲＦ１３−２はＵＥ４にサービス提供していないので、結果は失敗である。

（このステップは以前は提案されていなかった。）

図５のステップ１１
ＰＣＲＦ１３−２はＰ−ＣＳＣＦ１２に対して、検証失敗応答を送信する。

（このステップは以前は提案されていなかった。）

図５のステップ１２
検証失敗応答を受信すると、ＵＥ４のために２以上のものが設定されている場合、Ｐ−ＣＳＣＦ１２は他のＰＣＲＦエンティティを選択し、異なるＰＣＲＦエンティティのために図５のステップ９から１２を再び実行して検証を再試行することができる。検証成功応答が受信されるか（この場合、図４のステップ１２から１４が実行され得る）、又はこれ以上のＰＣＲＦエンティティを特定できないと判断されるまで、このことは継続し得る。この特定の例では、結果は不成功である。

（このステップは以前は提案されていなかった。）

図５のステップ１３
Ｐ−ＣＳＣＦ１２は、検証失敗の結果として、ＵＥ４に対して検証失敗応答を送信する。

（このステップは以前は提案されていなかった。）

図５のステップ１４
ＵＥ４は他のＰ−ＣＳＣＦエンティティを選択してＩＭＳへの登録を再試行することができる。

本発明の実施形態に関する１つの利点は、登録手順が改良されることである。登録手順の間、ポリシー制御エンティティが正しく選択されてアドレス指定されることが確実にされ、そうでない場合にＩＭＳサービスが拒否される可能性を回避する。

他の利点は、ＵＥとＧＷとの間のＩＭＳシグナリングが悪影響を受ける場合にＰ−ＣＳＣＦが通知を受けることが可能であるということであり、従ってそのような状況下でＩＭＳが適切な動作を行うことが可能であるということである。この利点は、図４及び図５のステップ９に関連して上述した、ＩＭＳ登録においてＰ−ＣＳＣＦとＰＣＲＦとの間にＡＦセッションが生成されるという２番目のオプションに関連する。このＡＦセッションのためにＰ−ＣＳＣＦによって許可されたＩＰフローは、ＵＥとＰ−ＣＳＣＦとの間のＳＩＰシグナリングフローに対応する。このＡＦセッションは、登録の間中存在することになる。ＡＦセッションも、許可されたフローを搬送するベアラの損失をＰＣＲＦがＡＦ（ここではＰ−ＣＳＣＦ）に対して通知するフレームワークであるため、このオプションは、ＳＩＰシグナリングフローがいつ影響を受けるかをＰ−ＣＳＣＦが知ることを可能にするということを導く。

上の実施形態はＵＭＴＳ及びＩＭＳの文脈で説明されているが、移動ノードが登録を必要とするＩＭＳに対応するネットワークのサブシステムを持つ、ＵＭＴＳに対応する通信ネットワークにおいても同一のスキームを実装可能であるということが理解できよう。ＵＭＴＳ／ＩＭＳの場合と同様に、そのようなネットワークはネットワークのユーザのためのポリシールール及び料金請求ルールを維持管理するか又はこれにアクセスする少なくとも１つのノード（上述のＰＣＲＦに対応）と、トラヒックフローに対するポリシールール及び料金請求ルールの実施のための少なくとも１つのノード（上述のＧＷに対応）と、少なくとも１つのプロキシノード（上述のＰ−ＣＳＣＦに対応）とを有するであろう。この方法は概して、ネットワークのプロキシノードにおいて移動ノードから登録要求メッセージを受信し、その移動ノードのためのポリシールール及び料金請求ルールのノードの候補を選択し、移動ノードにサービス提供するポリシールール及び料金請求ルールの実施ノードによって候補となったポリシールール及び料金請求ルールのノードが既に選択されているか否かを判断し、その判断に応じて登録手順の続くステップを実行することを含む。

１以上の上述のコンポーネントの動作はデバイス又は装置の上で動作するプログラムによって制御可能であるということが理解できよう。そのような動作プログラムはコンピュータ読み取り可能な媒体に格納可能であるし、或いは、例えばインターネットのウェブサイトから提供されるダウンロード可能なデータ信号のような信号内に取り込むことも可能である。添付の請求の範囲は、動作プログラム自体、キャリアに記録されたもの、信号、或いは何らかの他の形態をカバーするものとして解釈されるべきである。

ＵＭＴＳの一部を示す、上述した概略図である。ＩＰマルチメディア・サブシステムの３Ｇ移動通信システムへの統合を概略的に示す、上述した図である。３ＧＰＰリリース７で提案された、ポリシー機能を処理するネットワークエンティティを概略的に示す、上述した図である。ＩＭＳ登録が成功した場合の本発明の実施形態に従うシグナリングフローを概略的に示す図である。ＩＭＳ登録が失敗した場合の本発明の実施形態に従うシグナリングフローを概略的に示す図である。

Claims

通信のネットワークの移動ノードを前記ネットワークのサブシステムに登録する方法であって、前記ネットワークは、前記ネットワークのユーザのためのポリシールール及び料金請求ルールを維持管理するか又はこれにアクセスする少なくとも１つのノードと、トラヒックフローに対する前記ポリシールール及び前記料金請求ルールの実施のための少なくとも１つのノードと、を備え、前記方法は、
前記ネットワークのプロキシノードにおいて前記移動ノードから登録要求メッセージを受信するステップと、
前記移動ノードのためのポリシールール及び料金請求ルールのノードの候補を選択するステップと、
前記移動ノードにサービス提供するポリシールール及び料金請求ルールの実施ノードによってポリシールール及び料金請求ルールのノードの前記候補が既に選択されているか否かを判断するステップと、
前記判断に応じて前記登録の手順の続くステップを実行するステップと、
を備え、
前記続くステップは、前記移動ノードにサービス提供するポリシールール及び料金請求ルールの実施ノードによって既に選択されていると判断されるポリシールール及び料金請求ルールのノードの候補が選択されない場合に、少なくともその関係するプロキシノードに関しては、前記移動ノードを前記サブシステムに登録する要求を拒否するステップを含む
ことを特徴とする方法。
前記ネットワークは汎用移動通信システムであることを特徴とする請求項１に記載の方法。
前記移動ノードは前記汎用移動通信システムのユーザ装置であることを特徴とする請求項２に記載の方法。
ポリシールール及び料金請求ルールの前記ノードそれぞれは、前記汎用移動通信システムのポリシー＆チャージング・ルール機能を含むことを特徴とする請求項２又は３に記載の方法。
ポリシールール及び料金請求ルールの前記ノードそれぞれは、関門ＧＰＲＳサポートノードなどの前記汎用移動通信システムのゲートウェイノードを含むことを特徴とする請求項２乃至４のいずれか１項に記載の方法。
前記プロキシノードは、前記汎用移動通信システムのアプリケーション機能を含むことを特徴とする請求項２乃至５のいずれか１項に記載の方法。
前記プロキシノードは、前記汎用移動通信システムのプロキシ呼セッション制御機能を含むことを特徴とする請求項２乃至６のいずれか１項に記載の方法。
前記サブシステムはＩＰマルチメディア・サブシステムであることを特徴とする請求項２乃至７のいずれか１項に記載の方法。
前記判断するステップは、
前記プロキシノードからポリシールール及び料金請求ルールのノードの前記候補へ、前記移動ノードにサービス提供するポリシールール及び料金請求ルールの実施ノードによって前記候補が既に選択されているか否かを判断する際にポリシールール及び料金請求ルールのノードの前記候補が使用する情報を含む検証要求を送信するステップと、
ポリシールール及び料金請求ルールのノードの前記候補から受信した応答を前記判断の基礎とするステップと、
を含むことを特徴とする請求項１乃至８のいずれか１項に記載の方法。
前記検証要求は、前記プロキシノードとポリシールール及び料金請求ルールのノードの前記候補との間のアプリケーション機能セッションの一部として送信されることを特徴とする請求項９に記載の方法。
前記情報は前記移動ノードのＩＰアドレスを含むことを特徴とする請求項９又は１０に記載の方法。
前記移動ノードの前記ＩＰアドレスがポリシールール及び料金請求ルールのノードの前記候補に既に格納されているか否かを確認するステップを備えることを特徴とする請求項１１に記載の方法。
前記移動ノードにサービス提供するポリシールール及び料金請求ルールの実施ノードによってポリシールール及び料金請求ルールのノードの前記候補が既に選択されていると判断された場合に、前記移動ノードを前記サブシステムに登録するステップを継続するステップを備えることを特徴とする請求項１乃至１２のいずれか１項に記載の方法。
前記移動ノードにサービス提供するポリシールール及び料金請求ルールの実施ノードによってポリシールール及び料金請求ルールのノードの前記候補がまだ選択されていないと判断された場合に、前記移動ノードにサービス提供するポリシールール及び料金請求ルールの実施ノードによって既に選択されていると判断されるものが選択されるか、又は更に選択する候補が存在しなくなるまで、ポリシールール及び料金請求ルールのノードの１以上の更なる候補について前記選択するステップ及び前記判断するステップを再び実行するステップを備えることを特徴とする請求項１乃至１３のいずれか１項に記載の方法。
更なるプロキシノードについて前記各ステップを実行するステップを備えることを特徴とする請求項１に記載の方法。
通信のネットワークの移動ノードを前記ネットワークのサブシステムに登録するために用いる装置であって、前記ネットワークは、前記ネットワークのユーザのためのポリシールール及び料金請求ルールを維持管理するか又はこれにアクセスする少なくとも１つのノードと、トラヒックフローに対する前記ポリシールール及び前記料金請求ルールの実施のための少なくとも１つのノードと、を備え、前記装置は、
前記移動ノードから登録要求メッセージを受信する手段と、
前記移動ノードのためのポリシールール及び料金請求ルールのノードの候補を選択する手段と、
前記移動ノードにサービス提供するポリシールール及び料金請求ルールの実施ノードによってポリシールール及び料金請求ルールのノードの前記候補が既に選択されているか否かを判断する手段と、
前記判断に応じて前記登録の手順の続くステップを実行する手段と、
を備え、
前記続くステップは、前記移動ノードにサービス提供するポリシールール及び料金請求ルールの実施ノードによって既に選択されていると判断されるポリシールール及び料金請求ルールのノードの候補が選択されない場合に、少なくとも前記装置に関しては、前記移動ノードを前記サブシステムに登録する要求を拒否するステップを含む
ことを特徴とする装置。
通信のネットワークの移動ノードを前記ネットワークのサブシステムに登録する方法の一部として装置が用いる方法であって、前記装置は前記ネットワークのユーザのためのポリシールール及び料金請求ルールを維持管理するか又はこれにアクセスする少なくとも１つのノードのうちの１つであり、前記ネットワークはトラヒックフローに対する前記ポリシールール及び前記料金請求ルールの実施のための少なくとも１つのノードを備え、前記装置が用いる前記方法は、
前記ネットワークのプロキシノードでの前記移動ノードからの登録要求メッセージの受信と、前記移動ノードのためのポリシールール及び料金請求ルールのノードの候補としての前記装置の選択と、に続いて、前記移動ノードにサービス提供するポリシールール及び料金請求ルールの実施ノードによってポリシールール及び料金請求ルールのノードの前記候補が既に選択されているか否かを判断することによって、前記判断に応じて前記登録の手順の続くステップを実行可能にするステップ
を備え、
前記続くステップは、前記移動ノードにサービス提供するポリシールール及び料金請求ルールの実施ノードによって既に選択されていると判断されるポリシールール及び料金請求ルールのノードの候補が選択されない場合に、少なくともその関係するプロキシノードに関しては、前記移動ノードを前記サブシステムに登録する要求を拒否するステップを含む
ことを特徴とする方法。
通信のネットワークの移動ノードを前記ネットワークのサブシステムに登録する方法において用いる装置であって、前記装置は前記ネットワークのユーザのためのポリシールール及び料金請求ルールを維持管理するか又はこれにアクセスする少なくとも１つのノードのうちの１つであり、前記ネットワークはトラヒックフローに対する前記ポリシールール及び前記料金請求ルールの実施のための少なくとも１つのノードを備え、前記装置は、
前記ネットワークのプロキシノードでの前記移動ノードからの登録要求メッセージの受信と、前記移動ノードのためのポリシールール及び料金請求ルールのノードの候補としての前記装置の選択と、に続いて、前記移動ノードにサービス提供するポリシールール及び料金請求ルールの実施ノードによってポリシールール及び料金請求ルールのノードの前記候補が既に選択されているか否かを判断することによって、前記判断に応じて前記登録の手順の続くステップを実行可能にする手段
を備え、
前記続くステップは、前記移動ノードにサービス提供するポリシールール及び料金請求ルールの実施ノードによって既に選択されていると判断されるポリシールール及び料金請求ルールのノードの候補が選択されない場合に、少なくともその関係するプロキシノードに関しては、前記移動ノードを前記サブシステムに登録する要求を拒否するステップを含む
ことを特徴とする装置。
装置上で動作すると請求項１乃至１５及び１７のいずれか１項に記載の方法を前記装置に実行させることを特徴とするプログラム。
装置内にロードされると前記装置が請求項１６又は１８に記載の装置になるようにすることを特徴とするプログラム。
搬送媒体によって搬送されることを特徴とする請求項１９又は２０に記載のプログラム。
前記搬送媒体は伝送媒体であることを特徴とする請求項２１に記載のプログラム。
前記搬送媒体は記録媒体であることを特徴とする請求項２１に記載のプログラム。