JP4801203B2 - 呼を回線交換領域から統一サービス領域へルーティングする方法、装置及びコンピュータプログラム - Google Patents

Description

本発明は一般的には呼をルーティングする技術に関する。特に、本発明は、呼を回線交換アクセス領域から統一サービス領域へルーティングする技術に関する。

第２世代（２Ｇ）と第３世代（３Ｇ）移動体通信システムにおいて、複数のユーザ端末をそれらのユーザ端末にサービス提供するコアネットワークに接続するアクセスネットワーク内では、明確な交換領域を識別することができる。これらの交換領域には、回線交換（ＣＳ）領域とパケット交換（ＰＳ）領域とが含まれる。ＣＳ領域では、信号はユニークな接続を通じてそれらの宛先へ物理的にトランスポートされ、他方、ＰＳ領域では、個々のパケットは、各パケットに関連する宛先アドレスに基づいて適切な宛先へ動的にルーティングされる。

現行のＧＳＭ（汎欧州デジタル移動電話方式）やＷＣＤＭＡ（広帯域符号分割多元接続）標準に従って動作する２Ｇや３Ｇのユーザ端末は、典型的にはＣＳアクセスネットワーク、即ち、ＣＳ領域を介してコアネットワークにアクセスする。ＣＳアクセス領域から、呼はコアネットワーク内の特定のサービス領域へルーティングされるであろう。

発信サービス、着信サービス、中継サービスを含む呼サービスを提供するため、現在、各種のサービス領域が展開されている。過去において、移動体通信ネットワークは、純粋なＣＳネットワークであった。即ち、アクセス領域でもサービス領域でも、ＣＳパラダイムが根底にあった。移動体通信ネットワークが純粋のＣＳネットワークからインターネットプロトコル（ＩＰ）を利用したネットワークへと進化するにつれて、新しいサービス領域が導入されている。これらの新しいサービス領域の１つが、現在第３世代パートナシッププロジェクト（３ＧＰＰ）によって標準化されているＩＰマルチメディアサブシステム（ＩＭＳ）である。ＩＭＳは、固定端末にも移動端末にもサービス提供し、インターネットやその他のＰＳを利用したネットワークを含めてユビキタスなＩＰ環境へとシームレスに統合するネットワークアーキテクチャである。

ＩＭＳサービス領域およびその他の新しいサービス領域の高度化した機能は、ほとんどの場合、サブスクリプションベースで提供される。このことは、ＩＭＳの典型的な事例では、特定の呼は、その呼に関わる少なくとも１つの端末についてＩＭＳサブスクリプションが判定できた場合にのみ、ＩＭＳサービス領域へルーティングされることを意味する。そうでなければ、即ち、ＩＭＳサブスクリプションが判定できない場合には、呼サービスは、従来のやり方で、そして典型的にはＣＳを利用したサービス領域において提供されるであろう。

個々の呼について利用可能であるさまざまな多数のサービス領域が、呼毎に特定のアクセス領域から、従来型（ＣＳ利用の）サービス領域、ＩＭＳサービス領域、或はなんらかのそれ以外の新しいサービス領域へと、選択的に切り替わるメカニズムが必要である。従って、現行のサブスクリプション状況またはその他のパラメータに応じて、ユーザ端末に必要であるかまたはユーザ端末により要求されたいくつかの呼サービスが１つのサービス領域内で提供され、他方、この端末のための他の呼サービスが別のサービス領域内で提供されるかもしれない。ローミング中の移動端末については、端末の位置によってネットワークの能力が変化する場合、まったく同じサービスが異なるサービス領域内で提供されることさえあるかもしれない。まったく同じ端末に関する呼をさまざまなサービス領域が処理する可能性があるため、どちらのシナリオも結果として、ユーザ体験が不均一になってしまう。

もっと均一なユーザ体験を提供し、かつ、サービス領域切り替え技術に関する作業負荷を減らすために、過剰なさまざまなサービス領域ではなくて統一されたサービス領域を提供することが望ましい。一貫して呼をＣＳネットワークアクセスからＩＭＳネットワークを介してＩＭＳサービス領域へルーティングするための対応する解決策が、現在３ＧＰＰによって調査されている。その作業項目は、ＩＭＳ集中型サービス（ＩＣＳ：IMS Centralized Services）と呼ばれており、サービス環境を調和させるためにすべての加入者をＩＭＳに移動させることを目指している（非特許文献１を参照）。

ＩＣＳの展開に必要なルーティングメカニズムでは、根底にある機能性を提供するＩＣＳクライアントアプリケーションのインストールが必要である。現在、クライアント・インストールに関する２つの基本的な選択肢が検討されている。第１のネットワーク中心の構想によると、ネットワーク側が、新たなルーティング機能によって強化される。即ち、ＩＣＳクライアントアプリケーションが、ネットワーク内に、例えば、移動通信交換局（ＭＳＣ）或はＭＳＣサーバ（ＭＳＣ−Ｓ）上にインストールされる。第２のインストール構想として、ＩＣＳクライアントアプリケーションを端末に配置することもできる。

３ＧＰＰ ＴＳＧ ＳＡ ＷＧ２ アーキテクチュア−ＳＡ２＃５、ソフィア、アンチポリス（Sophia Antipolis）、フランス、２００６年８月２８日−９月１日、Ｔｄｏｃ Ｓ２−０６３３３５

いずれの構想もそれぞれ長所と短所がある。早期に導入するには、例えば、ネットワーク側でＩＣＳを非常に迅速にサポートすることが望ましいであろう。加えて、ネットワーク中心のアプローチは、想定される大量展開のシナリオにおいて拡張性が高く、旧製品や低価格の端末に対してもＩＣＳサポートを提供する。しかし、当初はＩＣＳユーザ数が非常に少ないであろうから、統一されたサービスパラダイムが一般的に採用されるまでは、端末中心の解決策の方が、リソース効率が高いであろう。

従って、クライアントアプリケーションを個別にインストールするという選択肢の利点を否定することなく統一サービス領域を効率的に実現する技術が必要である。

第１の側面からすれば、回線交換アクセス領域から統一サービス領域への呼のルーティングをサポートする機能を提供する１つ以上のクライアントアプリケーションのアクティベーション状態を制御する方法が備えられる。ここで、第１のクライアントアプリケーションがネットワーク側で提供され、第２のクライアントアプリケーションが端末側で提供される可能性がある。この方法は、ネットワーク側で、メッセージを端末側から受信する工程と、そのメッセージに応じて、ルーティング機能を提供することになるクライアントアプリケーションを検出する工程と、前記検出の結果に従って、前記第１のクライアントアプリケーションと前記第２のクライアントアプリケーションの少なくともいずれか一方のアクティベーション状態を制御する工程とを備える。

統一されたサービス領域は、２つ以上の利用可能となりうるサービス領域から、サービス領域を調和させるための特定のサービス領域として選択されたサービス領域であってもよい。その選択は、ネットワーク運用業者によって行われる。一変形例では、統一されたサービス領域は、非特許文献１に記載のようなＩＣＳパラダイムの下でのＩＭＳサービス領域であり、特に、クライアントアプリケーションの機能及び統一サービス領域の特徴に関する限り、ここで参照により本願に組み込まれる。

アクセス領域はＣＳアクセス領域であることが望ましいけれども、これは、ＣＳアクセス領域から別のアクセス領域（例えばＩＰ−ＣＡＮのようなＰＳ領域）への、あるいはそのような別のアクセス領域からＣＳアクセス領域への、あるいは２つの異なるＣＳアクセス領域間の、なんらかの呼転送を除外するものではない。そのような呼転送は、例えば、「音声呼の連続性」（ＶＣＣ：Voice Call Continuity）のようなサービス連続性のシナリオの中で発生することがある。

回線交換アクセス領域から統一サービス領域への呼のルーティングをサポートする１つ以上のクライアントアプリケーションの機能は、クライアントアプリケーションと統一サービス領域へのインタフェース構成要素（例えば、ＩＭＳインタフェースアダプタ）との間のセション制御シグナリングのルーティングを含んでもよい。セション制御シグナリングに加えて、メディアデータおよびメディアデータ関連のシグナリングがサポートされてもよい。

必要なルーティング機能を提供することになる特定のクライアントアプリケーションの検出は、端末側とネットワーク側との内、少なくともいずれかで利用可能な能力を判定することを含んでもよい。１つのシナリオでは、第２のクライアントアプリケーションがそもそも端末側で提供されるかどうかが判定されるか、または、端末側に提供される何らかの第２のクライアントアプリケーションの特定の機能が判定される。加えて、あるいは代わりに、第１のクライアントアプリケーションがそもそもネットワーク側に提供されるかどうかが判定されるか、または、ネットワーク側に提供される何らかの第１のクライアントアプリケーションの特定の機能が判定される。その検出はさらに、ルーティング機能を備えるために第１のクライアントアプリケーションと第２のクライアントアプリケーションのうちの一つを選択することを含んでもよい。この決定は、第１と第２のクライアントアプリケーションのうち少なくとも１つの利用可能性と、第１と第２のクライアントアプリケーションのうち少なくとも一方によって提供される特定の機能との内の少なくともいずれかに基づいてもよい。

上述したように、その検出は、端末側からのメッセージの受信に応じて行われる。第１の変形例によると、そのメッセージは、前記検出する工程の間に評価される情報を含む。第１の変形例と組み合わせることが可能な第２の変形例によると、メッセージの受信は、前記検出する工程を開始するためのトリガとして働く。さらに別の変形例によると、前記検出する工程は、前記メッセージの受信と時間的に密接に関連して実行される（例えば、メッセージ受信は、前記検出するステップを実行するための時間間隔を指定するタイマをスタートさせる）。

本発明の１つの制御シナリオでは、前記ネットワーク側に常駐する第１のクライアントアプリケーションは、前記端末側で第２のアプリケーションが検出できなかった場合、アクティベーション状態になるように制御される。別の制御シナリオでは、第２のアプリケーションが検出できた場合、第１のクライアントアプリケーションは、ディアクティベートされた状態になるように制御される。第１のクライアントアプリケーションがディアクティベートされた状態において、ネットワーク側のノードによって実行される方法はさらに、何らかの制御シグナリングを第２のクライアントアプリケーションから、そして第２のクライアントアプリケーションへ透過的に転送する工程を備えてもよい。

端末側から受信したメッセージは、呼をルーティングする機能を提供することになる特定のクライアントアプリケーションの表示を含んでもよい。この表示は、例えば、端末側での第２のクライアントアプリケーションの利用可能性についての通知、或は、その代わりに、ネットワーク側での第１のクライアントアプリケーションのアプリケーションに関する命令を含んでもよい。さらに、その表示は、ユーザ端末を統一サービス領域に登録する要求であってもよい。この登録要求は、第２のネットワークアプリケーションの制御によって、或は、その制御の下で生成されて（従って、端末側での第２のクライアントアプリケーションの利用可能性を示して）てもよい。端末側からのメッセージを介して受信された何らかの表示に基づいて、ネットワーク側は、ネットワークベースの第１のクライアントアプリケーションのアクティベーション状態をしかるべく制御してもよい。

ネットワーク側は、ネットワークベースの第１のクライアントアプリケーションのアクティベーション状態か、端末ベースの第２のクライアントアプリケーションのアクティベーション状態か、或は、両方のクライアントアプリケーションのアクティベーション状態を制御してもよい。端末側の第２のクライアントアプリケーションのアクティベーション状態を制御することは、第２のクライアントアプリケーションのアクティベーション状態に関するアクティベーション指示を端末側へ送信することを含んでもよい。それ故、第２のクライアントアプリケーションは、アクティベートされるか、或は、ディアクティベートされるかのいずれかである。

ネットワーク側では、例えば、ホームロケーションレジスタ（ＨＬＲ）データベース或は在圏ロケーションレジスタ（ＶＬＲ）データベースのような１つ以上のロケーション登録データベースが提供されるとよい。次いで、その方法はさらに、ロケーション登録データベースの中に第１のクライアントアプリケーションと第２のクライアントアプリケーションの内の少なくとも１つの現在のアクティベーション状態を記憶する工程を備えるとよい。加えて、統一サービス領域から要求されるか、或は、統一サービス領域で提供される少なくとも１つのサービスのサービス状態が、ロケーション登録データベースの中に記憶されるとよい。

一つのシナリオでは、この方法はさらに、統一サービス領域に対するインタフェース構成要素を選択する工程と、第１と第２のクライアントアプリケーションのうちアクティベートされた方を選択されたインタフェース構成要素に接続する工程とを備える。前記選択されたインタフェース構成要素の識別子（例えば、そのネットワークアドレス）が、ロケーション登録データベースのうちの少なくとも１つと、第１と第２のクライアントアプリケーションのうちアクティベートされた方へ送信されてもよい。

在圏ネットワークへローミングしている端末については、この方法はさらに、前記在圏ネットワークにより、前記選択されたインタフェース構成要素の識別子を受信する工程と、前記在圏ネットワークにより、前記選択されたインタフェース構成要素を介して前記統一サービス領域内でローミング中の端末の登録の更新を実行する工程とを備えてもよい。前記在圏ネットワークでは、前のネットワークでの第１のクライアントアプリケーションのアクティベーション状態を受信して評価する工程がさらに実行されてもよい。前のネットワークでの第１のクライアントアプリケーションのアクティベーション状態に応じて、新たな第１のクライアントアプリケーションが前記在圏ネットワーク内でインスタンス化されてもよい。そのようなインスタンス化は、特に、前のネットワークで第１のクライアントアプリケーションがアクティベーション状態であるか、またはアクティベーション状態であったと判定された場合に行われてもよい。

個々のあるいはすべてのルーティング機能は、サブスクリプションベースで提供されるとよい。そのような場合、ネットワーク側で実行される方法はさらに、サブスクリプション情報を要求することと受信することのいずれか一方を備えてもよい。第１のクライアントアプリケーションのルーティング機能は次いで、サブスクリプションの存在に応じて提供されてもよい。さらに、ルーティング機能に関する許可情報が、ネットワーク内で要求されてもよい。要求された許可情報の受信と評価時に、次いで特定の端末が統一サービス領域内で登録されることになるか否かが決定されてもよい。

本発明を別の側面から見ると、回線交換アクセス領域から統一サービス領域への呼のルーティングをサポートする機能を提供する１つ以上のクライアントアプリケーションのアクティベーション状態を制御する方法が備えられる。ここで、第１のクライアントアプリケーションがネットワーク側に備えられ、第２のクライアントアプリケーションが端末側に備えられる可能性がある。この方法は、端末側で、呼をルーティングする機能を提供することになるクライアントアプリケーションの表示を生成する工程と、その表示をネットワーク側へ送信する工程とを備える。この表示を使って、ネットワーク側の第１のクライアントアプリケーションのアクティベーション状態が上述のように影響を受けてもよい。

一変形例では、この方法はさらに、端末側に第２のクライアントアプリケーションを備える工程を備える。そのような場合、前記ネットワーク側へ送信される表示には、前記端末側での第２のクライアントアプリケーションの利用可能性への参照が含まれてもよい。加えて、あるいはその代わりとして、その表示はネットワーク側に備えられる第１のクライアントアプリケーションへの何らかの参照を含んでもよい。ネットワーク側では、第１のクライアントアプリケーションへの参照を、第１のクライアントアプリケーションがアクティベートされた状態であるように制御するための命令として解釈してもよい。

本発明は、ハードウェアの形で、ソフトウェアの形で、あるいはハードウェア／ソフトウェアの組み合わせの形のやり方で実施することができる。ソフトウェアの態様については、コンピュータプログラム製品が提供される。そのコンピュータプログラム製品は、コンピュータプログラム製品が１つ以上のコンピュータデバイス上で実行される場合に本発明の工程を実行するプログラムコード部を備える。そのコンピュータプログラム製品は、コンピュータ可読記録媒体に記憶されてもよい。

ハードウェアの面からすれば、回線交換アクセス領域から統一サービス領域への呼のルーティングをサポートする機能を提供する１つ以上のクライアントアプリケーションのアクティベーション状態を制御するネットワークノードが備えられる。ここで、第１のクライアントの表示がネットワーク側で備えられ、第２のクライアントアプリケーションが端末側で備えられる可能性がある。このネットワーク構成要素は、端末側からメッセージを受信するように適合されたインタフェースと、前記メッセージに応じて、前記ルーティング機能を提供することになるクライアントアプリケーションを検出するように適合された検出器と、前記検出の結果に応じて、第１のクライアントアプリケーションと第２のクライアントアプリケーションのうち少なくとも１つのアクティベーション状態を制御するように適合されたコントローラとを備える。

別のハードウェアの面からすれば、回線交換アクセス領域から統一サービス領域への呼のルーティングをサポートする機能を提供する１つ以上のクライアントアプリケーションのアクティベーション状態を制御する端末が備えられる。ここで、第１のクライアントアプリケーションがネットワーク側に備えられ、第２のクライアントアプリケーションが端末側に備えられる可能性がある。この端末は、呼のルーティング機能を提供することになるクライアントアプリケーションの表示をネットワーク側へ送信するように適合されたインタフェースを備える。その端末はさらに、その表示を生成するプロセッサを備えてもよい。さらにその上、その端末は第２のクライアントアプリケーションを備えてもよい。

以下に、本発明について図面で例示された代表的な実施例を参照して説明する。

本発明の２つの装置の実施例を含む通信ネットワークを示す概略的ブロック図である。 本発明の第１の方法の実施例を示すフローチャートである。 本発明の第２の方法の実施例を示すフローチャートである。 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 代表的なＩＣＳ環境における本発明の多様な別の実施例を示す模式的なブロック図と概略的なシグナリング図である。

以下の説明では、限定ではなく説明のため、本発明の十分な理解を提供することを目的として、例えば、特定の連続するステップ、インタフェース、及び構成のような具体的詳細について説明する。当業者には明白であろうが、本発明は、これらの具体的詳細から離れた他の実施例において実施されてもよい。例えば、実施例は代表的には統一されたＩＭＳサービス領域の環境で説明されるであろうが、本発明は、ＩＭＳが包含するものとは異なる他の統一サービス領域においても実施可能であることは明らかである。加えて、例えば、非構造化付加サービスデータ（ＵＳＳＤ）プロトコル、ＩＳＤＮユーザ部（ＩＳＵＰ）プロトコル、及び、ベアラ・インデペンデント呼制御（ＢＩＣＣ）プロトコルのような個別のプロトコルについても下記の実施例の中で記述するが、他の適切なプロトコルが、これらのプロトコルのうちの１つ以上の代わりにもしくはそれに加えて使用されてもよいということは容易に明らかになるであろう。

さらに当業者であれば、以下に説明した諸機能が、プログラムされたマイクロプロセッサまたは汎用コンピュータに関連して機能するソフトウェアを用いて実装されてもよいことを認識するであろう。また認識されるであろうが、本発明は基本的に方法と装置の形で記述されているが、本発明はコンピュータプログラム製品として、また、コンピュータのプロセッサとそのプロセッサに連結されたメモリとを備えたシステムとして実施されてもよい。なお、そのメモリがここで開示された諸機能を実行しうる１つ以上のプログラムを使って符号化される。

図１は、一方に端末１１０、他方にネットワークノード１１２という形で２つの装置の実施例を含む通信ネットワーク１００を示す。通信ネットワーク１００はさらに、統一サービス領域１１４を含む。端末１１０は、例えば、パーソナルコンピュータ、携帯電話または携帯情報端末のような、固定端末または移動端末であってもよい。ネットワークノード１１２は、例えば、ＭＳＣまたはＭＳＣ−Ｓのようなネットワーク交換構成要素であってもよい。ネットワークノード１０２は、図１の矢印１１６で示すように端末１１０が統一サービス領域１１４にそれを介して接続できるような、ＣＳアクセス領域にアタッチしているかまたはその一部であることが望ましい。

端末１１０は、ＣＳアクセス領域からネットワークノード１１２を使って統一サービス領域１１４への呼のルーティングをサポートする機能を提供するクライアントアプリケーション１２０をオプションで備える。クライアントアプリケーション１２０は（例えば、本質的に同じ機能を提供するクライアントアプリケーションがネットワークノード１１２に位置する場合）省略される可能性があるであろうという点でオプションである。端末１１０はさらに、呼を統一サービス領域１１４へルーティングするための機能を提供することになる特定のクライアントアプリケーションの表示をネットワークノード１１２へ送信するよう適合されたネットワークインタフェース１２２を備える。ネットワークインタフェース１２２を介して送信されることになる表示は、端末１１０のプロセッサ１２４によって生成される。図１に示すように、プロセッサ１２４は、オプションのクライアントアプリケーション１２０とネットワークインタフェース１２２の両方と通信するように適合される。

ネットワークノード１１２は、端末１１０からメッセージを受信するように適合されたネットワークインタフェース１３０を備える。ネットワークインタフェース１３０を介して端末１１０から受信されたメッセージは、呼をルーティングする機能を提供することになるクライアントアプリケーションの表示を含んでいるかもしれない。しかし、そのメッセージは、ネットワークノード１１２の動作に影響を与えることなく原則としてそのような表示がなくてもよい。そのような場合、統一サービス領域のサポートが自動的にネットワークノード１１２によって提供されてもよい。

図１に示すように、ネットワークノード１１２はさらに、統一サービス領域サポートを選択的に提供するために、独自のクライアントアプリケーション１３２を備える。端末１１０のオプションのクライアントアプリケーション１２０と同様、ネットワークベースのクライアントアプリケーション１３２は、端末１１０からネットワークノード１１２を介して統一サービス領域１１４への呼のルーティングをサポートする機能を提供するように適合される（矢印１１６を参照）。加えて、ネットワークノード１１２は、ネットワークインタフェース１３０に結合された検出器１３４を備える。検出器１３４は、ネットワークインタフェース１３０を介したメッセージの受信に応じて、ルーティング機能を提供することになるクライアントアプリケーションを検出するように適合されている。

検出器１３４は、検出器１３４により実行された検出結果に応じて、ネットワークベースのクライアントアプリケーション１３２とオプションの端末ベースのクライアントアプリケーション１２０との内、少なくとも一方のアクティベーション状態を制御するように適合された制御器１３６と通信する。その検出結果によって、制御器１３６は、例えば、ネットワークベースのクライアントアプリケーション１３２をアクティベートするか、またはディアクティベートさせる。しかし、制御器１３６は、端末ベースのクライアントアプリケーション１２０のアクティベーション状態を遠隔制御してもよい。この目的で、制御器１３６は、ネットワークインタフェース１３０を介して制御命令を端末１１０へ送信してもよい。

図２は、本発明の第１の方法の実施例のフローチャート２００を示す。この実施例は、ＣＳアクセス領域から統一サービス領域への呼のルーティングをサポートする機能を提供する１つ以上のクライアントアプリケーションのアクティベーション状態を制御することを目標とする。ここで、第１のクライアントアプリケーションがネットワーク側で提供され、オプションの第２のクライアントアプリケーションが端末側で提供される可能性がある。図２に示す方法は、図１に示す端末１１０によって、或は、他の何らかの端末によって実施されてもよい。

その方法は、ステップ２０２で、呼のルーティング機能を提供することになる特定のクライアントアプリケーションの表示の生成で始まる。一例では、その表示により、クライアントアプリケーションが実際に端末側で提供されることをネットワーク側で検出することを可能にする。別の例では、その表示は、ネットワークベースのクライアントアプリケーションのアクティベーションを要求する。

いったん、その表示がステップ２０２において生成されると、この方法はステップ２０４へと続く。ステップ２０４では、その表示はネットワーク側へ送信される。この目的で表示は、ルーティング機能を提供することになるクライアントアプリケーションを検出するネットワークノードにより解釈可能な制御メッセージの中に包含されてもよい。その表示をネットワーク側へ送信することによって、その端末はネットワークベースのクライアントアプリケーションのアクティベーション状態を遠隔制御することができる。

図３は、ＣＳアクセス領域から統一サービス領域への呼のルーティングをサポートする機能を提供する１つ以上のクライアントアプリケーションのアクティベーション状態を制御するための別の実施例のフローチャート３００を示す。この方法は、図１に示すネットワークノード１１２によって実施されてもよいし、或は、他の何らかのネットワークノードによって実施されてもよい。

最初のステップ３０２では、メッセージが端末側から受信される。そのメッセージは、既存のプロトコル標準に従う従来型のメッセージであってもよい。そのメッセージは、図２に示す方法の実施例の環境で上述したような表示を含んでいてもよいし、含まなくてもよい。

メッセージ受信時、この方法は、ルーティング機能を提供することになるクライアントアプリケーションが検出されるステップ３０４へと続く。この検出はステップ３０２で受信したメッセージの内容に基づいてもよい。あるいは、その検出が、このメッセージの受信によって単純にトリガされてもよい。

さらなるステップ３０６では、ネットワークベースのクライアントアプリケーションと端末ベースのクライアントアプリケーションとの内、少なくとも一方のアクティベーション状態が、検出ステップ３０４の結果によって制御される。その制御は、一方のクライアントアプリケーションのアクティベーションと、それと同時に起こる他方のクライアントアプリケーションのディアクティベーションとを含んでもよい。クライアントアプリケーションが端末側に提供されていない場合には、ステップ３０６は、ネットワークベースのクライアントアプリケーションをアクティベートすることだけを含んでもよい。もしネットワークベースのクライアントアプリケーションがデフォルトではアクティベートされた状態にある場合、ステップ３０６は結果として、ネットワークベースのクライアントアプリケーションのアクティベートされた状態を維持するであろう。

ＩＣＳ実装の例
次に、図４〜図１９の概略ネットワーク図およびシグナリング図を参照しながら、種々の更なる実施例について検討する。同一または類似の構成要素を示すのに、図１で用いたのと同じ参照番号を用いる。

図４〜図１９の更なる実施例は、代表的なＩＣＳ環境におけるネットワークベースのクライアントアプリケーションと端末ベースのクライアントアプリケーションのいずれか一方の動的選択に関する。まず、クライアントアプリケーションを端末に（図４）そしてネットワークに（図５）インストールするより詳細な解決策について説明する。

端末ベース及びネットワークベースのＩＣＳクライアントアプリケーション
図４のネットワークシステム４００は、ＣＳネットワークアクセスを有する端末１１０（ユーザ機器ＵＥともいう）を含む。端末１１０は、ＩＭＳクライアントアプリケーション１５６と、それに加えてＩＣＳクライアントアプリケーション１２０とを備える。ネットワークシステム４００にはさらに、ＭＳＣ−Ｓ １１２と、メディアゲートウェイ（ＭＧＷ）１５４と、ＩＭＳ１１４に対するインタフェースとして機能するインタフェースアダプタ（ＩＡ）１５０と、メディアプロキシ（ＭＰ）１５２とが含まれる。

端末１１０のＩＣＳクライアントアプリケーション１２０は、ＩＣＳ環境における専用のタスクを提供し、ネットワークシステム４００の階層アーキテクチャを反映する２つの機能的構成要素を含む。制御レイヤ（または制御プレーン）上では、ＩＣＳクライアントアプリケーション１２０は、セション制御処理のための機能ブロック“Ｃ”を含む。ユーザレイヤ（またはユーザプレーン）上では、ＩＣＳクライアントアプリケーション１２０は、メディア接続処理のための機能ブロック“Ｍ”を含む。ＩＣＳクライアントアプリケーション１２０の個々の機能ブロックは、ＩＡ１５０の対応する機能ブロックと通信する。制御レイヤ上での通信は、ＵＳＳＤによるＩＣＳプロトコルを必要とするのに対し、ユーザレイヤ上での通信は、一方の側で（ＩＣＳクライアントアプリケーション１２０とＭＳＣ−Ｓ１１２の間で）３ＧＰＰ技術仕様２４．００８標準を必要とし、他方の側では（ＭＳＣ−Ｓ１１２とＭＰ１５２の間で）ＩＳＵＰ／ＢＩＣＣを必要とする。

制御レイヤとユーザレイヤとは、ＩＡ１５０及びＭＰ１５２を介してＩＭＳ１１４にアタッチされる。図４に示すように、ＩＭＳ１１４は、ＩＭＳコア及びＩＭＳアプリケーションサービス（例えば、マルチメディア電話（ＭＭＴｅｌ）サービス）を含む。ＩＭＳコア及びＩＭＳアプリケーションサービスはＩＳＣプロトコルを介して通信する。

ＩＣＳクライアントアプリケーションがネットワーク側のどこかに存在すると仮定すると（例えば、上記の図１または下記の図５を参照）、図４の端末１１０は、図２の環境において上述した方法の実施例を実行するように構成されてもよい。一実施形において、端末１１０は、端末１１０におけるＩＣＳクライアントアプリケーション１２０の利用可能性についてネットワーク側に情報提供する表示をネットワーク側へ送信する。

図４が端末ベースのＩＣＳクライアントアプリケーション１２０を備えたネットワークシステム４００を示す一方、図５はネットワークベースのＩＣＳクライアントアプリケーション１３２を備えたネットワークシステム５００を示す。図５から明らかになるように、ＩＣＳクライアントアプリケーション１３２は、ＭＳＣ−Ｓ１１２にインストールされる。別のＩＣＳクライアントアプリケーションが（図４に示すように）端末１１０にインストールされてもよい。図５のＭＳＣ−Ｓ１１２は、図３の環境中で上述した方法の実施例を実行するように構成されてもよい。ネットワークシステム５００の残りの構成要素は、上述のネットワークシステム４００の構成要素と同様であり、従って、詳細な説明はここでは省略する。

図４と図５に関して、以下ではＩＣＳクライアントアプリケーション１３２（“ｕＩＣＳクライアント”ともいう）は常にネットワーク側にインストールされ、ＩＣＳクライアントアプリケーション１２０（“ｎＩＣＳクライアント”ともいう）は端末側にインストールされてもよいし、されなくてもよいと仮定する。

すでに上記で説明したように、（ネットワークベースまたは端末ベースの）ＩＣＳクライアントアプリケーションは、ＩＭＳ１１４に対するインタフェースとなるノードとして機能するＩＭＳ ＩＡ １５０に接続するであろう。ＩＡ １５０の実施形は、ＩＣＳクライアントアプリケーションの位置に依存すべきでなく、即ち、（端末側またはネットワーク側にある）ＩＣＳクライアントアプリケーションの配置はＩＡ １５０には見えないことが望ましい。

ＭＳＣ−Ｓ １１２の中のＩＣＳクライアントアプリケーション１３２は、端末中心の解決策において端末１１０が行うはずのやり方と同じやり方でＵＳＳＤ上のＩＣＳプロトコルを用いる。対応するメッセージによって端末１１０によって開始されるロケーション更新／ＩＭＳＩアタッチ手順において、ＭＳＣ−Ｓ １１２は、端末１１０の中のＩＣＳクライアントアプリケーションを検出しようと試みる。端末１１０が（例えば、図４に示されているように）ＩＣＳクライアントの能力を有する場合、ＭＳＣ−Ｓ １１２のＩＣＳクライアントアプリケーション１３２はディアクティベートされる。そうでなければ、即ち、端末１１０上でＩＳＣクライアントアプリケーションが検出されない場合、ＭＳＣ−Ｓ１１２のＩＣＳクライアントアプリケーション１３２がアクティベートされる（または、これがデフォルト状態であるならば、アクティベートされた状態に維持される）。端末１１０を操作している加入者は、特定のＩＣＳクライアントアプリケーションを（例えば、ウェブポータルを介して）デフォルトとして選択して、いずれかのネットワークベースの選択に優先させてもよい。

ＩＣＳクライアントアプリケーション１３２の少なくともアクティベーション状態について、そして、端末１１０上で提供される可能性のあるＩＣＳクライアントアプリケーション１２０の利用可能性／アクティベーション状態についてのＩＣＳ関連情報が、ＭＳＣ−Ｓ １１２のＶＬＲ（図４と図５では不図示）に局所的に記憶される。また、そのような情報が、ＨＬＲ（図４と図５では不図示）にアップロードされる。

従って、（ＭＳＣ−Ｓ １１２とＨＬＲに維持される）ＩＣＳクライアントのステータスは下記の状態をとりうる。即ち、
− ネットワーク起因のディアクティベート状態 ＝
端末ベースのＩＣＳクライアントが想定される
− ネットワーク起因のアクティベート状態（＆ＩＡ ＩＤ）＝
ネットワークベースのＩＣＳクライアントが想定される
− 加入者によるアクティベート状態 ＝
ネットワークベースが強制される
・ ＭＳＣ−Ｓ １１２のＵＳＳＤアプリケーションがブロックされる
・ ＭＳＣ−ＳベースのＩＣＳクライアントが常に使用される
− 加入者によるディアクティベート状態 ＝
端末ベースが強制される
・ ＭＳＣ−Ｓ １１２のＩＣＳクライアントが起動しない
・ ＭＳＣ−Ｓ １１２のＵＳＳＤアプリケーションがアクティベートされる。

ロケーション更新／ＩＭＳＩアタッチでＭＳＣ−Ｓ １１２が端末ベースのＩＣＳクライアントアプリケーションをまったく検出できない場合、ネットワークベースのＩＣＳクライアントアプリケーション１３２は、ＩＭＳ １１４へのインタフェースをとるために用いられることになるＩＡノード１５０を選択するであろう。一旦、ＩＡノード１５０とＩＡインスタンスが捕捉されると、ＩＣＳクライアントアプリケーション１３２は、ＩＭＳ登録手順を開始する。ＩＡ識別子がＩＣＳクライアントアプリケーション１３２へ返信され、そして、ネットワークベースのＩＣＳクライアントの場合、ＩＡ識別子と関連のＩＣＳサービス状態が、ＶＬＲに記憶され、ＨＬＲへアップロードされる。

端末１１０がＭＳＣ−Ｓ１１２により（そして、ＭＳＣ−Ｓ１１２のＩＳＣクライアントアプリケーション１３２により）サービスされるエリアから新たなＭＳＣ−Ｓのエリアへとローミングする場合、ＩＡ識別子とＩＣＳサービス状態が、加入者データとともに新たなＭＳＣ−ＳでＨＬＲから受信される。次いで、受信されたＩＡ識別子によって識別されたＩＡ１５０が新たなＭＳＣ−Ｓによって用いられ、ローミング中の端末１１０についてのＩＭＳ登録を更新するであろう。このことは、端末１１０がローミングしている場合でも、接続するＩＡ１５０のアイデンティティは変わらないことを意味する。

前のＭＳＣ−Ｓ １１２の中のＩＣＳクライアントアプリケーション１３２は、ＨＬＲから“ロケーションの削除”の表示の受信時、解放される。端末１１０がＭＳＣ−Ｓ１１２からデタッチする場合、ＩＡ１５０も解放される必要がある。

ネットワークベースのＩＣＳクライアントのシナリオでは、ＭＳＣ−Ｓ１１２のＩＣＳクライアントアプリケーション１３２は、端末１１０の登録を取り消し、ＩＡインスタンスを解放する。端末ベースのＩＣＳクライアントアプリケーション１２０の場合、ＩＡタイマが端末１１０によるＩＭＳ登録を管理する。タイマが切れると、ＩＡインスタンスが解放される。

図４〜図１９に示す実施例では、ＩＭＳ１１４のＩＣＳ機能がサブスクリプションに基づいて提供される。ＩＣＳサブスクリプションは、加入者毎に運用業者によってＨＬＲにおいて提供され、従来型のＭＡＰ挿入加入者データ（MAP Insert Subscriber Data）メッセージと共にＭＳＣ−Ｓ １１２へダウンロードされる。ＭＳＣ−Ｓ １１２によってサービスを受ける端末１１０について、ＩＣＳサブスクリプションが判定できない場合、端末１１０は通常のＣＳサブスクリプションに従って処理され、ＣＳサービス領域の中で従来通りにサービスを提供されるであろう。しかし、端末１１０についてＩＣＳサブスクリプションを判定することができる場合、ＩＣＳクライアントの状態によって（可能性のあるＩＣＳクライアント状態はすでに上述した）、ネットワークベースまたは端末ベースのＩＣＳクライアントアプリケーションがアクティベートされる。加入者データの中に、ｕＩＣＳの規制表示が追加されていてもよい。ｕＩＣＳ規制表示を設定することによって、運用業者は、いかなる端末ベースのＩＣＳクライアントアプリケーションの利用をも防ぐことができる。

ここで、端末ベースのＩＣＳアプリケーション１２０（図４を参照）またはネットワークベースのＩＣＳクライアントアプリケーション１３２（図５を参照）のいずれか一方の動的選択に関わる上記の基本メカニズムについて、図６〜図１９のシグナリングのシナリオを参照してより詳細に説明する。最初に、ＩＣＳクライアントアプリケーションの動的選択をトリガするＩＭＳＩアタッチの基本手順について呈示する。

ＩＭＳＩアタッチ手順
図６〜図７はＩＣＳサポートを行なうホームネットワーク内をローミングしている端末１１０についてのＩＭＳＩアタッチ手順を示す。ＩＭＳＩアタッチ手順は、端末ベースのＩＣＳクライアントアプリケーション１２０に関わる。

ホームネットワーク内（またはＩＣＳサポートを行なう他の何らかのネットワーク内）をローミングする場合、図６に示す選択手順は、端末によってＭＳＣ−Ｓ １１２へ送信されるＩＭＳＩアタッチメッセージで始まる（ステップ１）。次いで、ＭＳＣ−Ｓ １１２は、ネットワークベースのＩＣＳクライアントアプリケーションを適用すべきかどうか、または、何らかの端末ベースのＩＣＳクライアントアプリケーション１２０を用いるかどうかを判定しなければならない（ステップ２）。ＭＳＣ−Ｓにおけるこの決定は、例え ば、ネットワーク運用業者１７０によって規定される各種の情報に基づく。ＭＳＣ−Ｓ １１２は、端末１１０におけるＩＣＳクライアントアプリケーション１２０の存在を下記の基準に基づいて検出することができる。

− ＶＬＲ（不図示）の中の加入者データがＩＣＳへのサブスクリプションを含み、
− そして、続行リクエストをＩＭＳＩアタッチで受信する。ここで、この続行が呼と独立のトランザクション（Call Independent transaction）でのＵＳＳＤを介するＩＭＳ登録である（従って、ＭＳＣ−Ｓ１１２のＵＳＳＤアプリケーションは、端末１１０から受信したＵＳＳＤ列をチェックして、ＩＭＳ登録が端末１１０によって開始されるかどうかを判定するか、
あるいは、
− ＶＬＲの加入者データがＩＣＳへのサブスクリプションを含み、
− そして、新たに定義されたＩＣＳ表示情報要素（ＩＥ）が、２４．００８ＩＭＳＩアタッチメッセージで検出されるか、
あるいは、
− ＶＬＲの加入者データがＩＣＳへのサブスクリプションを含み、
− そして、新たに定義された２４．００８クラスマーク（Classmark IE）表示が端末１１０によって追加されて、端末１１０におけるＩＣＳサポートを示す。

次に、ＭＳＣ−Ｓ１１２が負荷共有の検討に基づいてＩＡ選択を行う（ステップ３）。次のステップで、選択されたＩＡ１５０によって、ホームサブスクライバレジスタ（ＨＳＲ）１６０に対するＩＣＳサブスクリプションチェックが行われる（ステップ４）。ＩＣＳサブスクリプションが存在する場合、端末１２０は、ＩＭＳ１１４に登録される（ステップ５）。加えて、選択されたＩＡ１５０は、そのユニークな識別子をＭＳＣ−Ｓ１１２および端末１１０に常駐するＩＣＳクライアントアプリケーション１２０へ将来の利用のために返信する（ステップ６）。

端末ベースのＩＣＳクライアントアプリケーション１２０がＭＳＣ−Ｓ１１２によって検出された場合のシグナリングフローが図７に示されており、これを以下に簡単に説明する。

ステップ１）〜ステップ５）：ロケーション更新タイプのＩＭＳＩアタッチ、ＨＬＲ１８０の更新（図６には不図示）、そして、加入者データのＶＬＲへの挿入（図６には不図示）。加入者データは、ＩＣＳサブスクリプションの表示を含む。

ステップ６）〜ステップ７）：ＭＳＣ−Ｓ１１２のモビリティ管理レイヤが、ＶＬＲの中のＩＣＳサブスクリプションをチェックする。このシーケンスでは、端末１１０のＩＣＳクライアントアプリケーション１２０がＩＭＳＩアタッチの続行リクエストによって検出されると仮定される。

ステップ８）〜ステップ９）：端末１１０が、呼と独立のトランザクション（Call Independent transaction）を開始する。

ステップ１０）〜ステップ１２）：端末ベースのＩＣＳクライアントアプリケーション１２０が、確立済みの呼と独立のトランザクション（Call Independent transaction）を用いてＵＳＳＤ列をＩＡ１５０へ送信する。

ステップ１３）〜ステップ１６）：ＩＡ１５０はＨＳＲ１６０のＩＣＳサービスを許可し、ＩＭＳ登録を行う。

ステップ１７〜ステップ２０）：ＩＡ１５０はＩＭＳ登録の成功を示すため、ＵＳＳＤ列を端末１１０のＩＣＳクライアントアプリケーション１２０へ返信する。ＩＣＳクライアントアプリケーション１２０は、登録管理タイマをスタートさせる。

ステップ２１〜ステップ２２）：ＭＳＣ−Ｓ１１２のＵＳＳＤアプリケーションは、ＶＬＲとＨＬＲ１８０のＩＣＳサービスステータスを更新して、ネットワークベースのＩＣＳクライアントアプリケーションがディアクティベートされることを示す。それから、選択手順は完了する。

ＭＳＣ−Ｓ１１２が端末ベースのＩＣＳサポートをまったく検出することができない場合には、ネットワーク中心のＩＣＳサポートがアクティベートされる。この点で、図８〜図９は、ホームネットワーク内をローミングする端末１１０のＩＭＳＩアタッチ手順を示す。ＩＭＳＩアタッチ手順は、ネットワークベースのＩＣＳクライアントアプリケーション１３２を含み、そして、図８のステップ１〜７で模式的に例示されるように進行する。関連するシグナリングフローの詳細な説明を図９に示す。

ステップ１）〜ステップ５）：ロケーション更新タイプのＩＭＳＩアタッチ、ＨＬＲ１８０に対する更新、そして、加入者データのＶＬＲへの挿入。加入者データはＩＣＳサブスクリプションを含む。

ステップ６）〜ステップ７）：ＭＳＣ−Ｓ１１２の中のモビリティ管理レイヤが、ＶＬＲのＩＣＳサブスクリプションをチェックする。このシーケンスでは、端末１１０のＩＣＳクライアントアプリケーション１２０がまったく検出されないと仮定される。

ステップ８）：ＭＳＣ−Ｓ１１２のモビリティ管理レイヤが、加入者のためのネットワークベースのＩＣＳサポートをアクティベートする。

ステップ９）〜ステップ１０）：ネットワークベースのＩＣＳクライアントアプリケーションが、確立済みの呼と独立のトランザクション（Call Independent transaction）を用いてＵＳＳＤ列をＩＡ１５０へ送信する。

ステップ１１）〜ステップ１４）：ＩＡ１５０はＨＳＲ１６０のＩＣＳサービスを許可し、ＩＭＳ登録を行う。

ステップ１５）〜ステップ１７）：ＩＡ１５０はＩＭＳ登録の成功を示すため、ＵＳＳＤ列をネットワークベースのＩＣＳクライアントアプリケーションへ返信する。ＩＣＳクライアントアプリケーションは登録管理タイマをスタートさせる。

ステップ２１）〜ステップ２２）：ＭＳＣ−Ｓ１１２のＵＳＳＤアプリケーションは、ＶＬＲとＨＬＲ１８０のＩＣＳサービスステータスを更新して、ネットワークベースのＩＣＳクライアントアプリケーションがアクティベートされることと、応答の中で受信されたＩＡ識別子とを示す。それから、選択手順は完了する。

図１０はネットワークベースのＩＣＳサポートなしで在圏ネットワーク内をローミングしている端末１１０のＩＭＳＩアタッチ手順を示す。この場合、端末ベースのＩＣＳクライアントアプリケーション１２０が用いられねばならない。さもなければ、加入者はＩＭＳ中心のサービスをまったく用いることができないであろう。

図１０に示すように、シグナリングは、端末１１０から在圏ネットワーク内のＭＳＣ−Ｓ１１２へと送信されるＩＭＳＩアタッチメッセージで始まる（ステップ１）。在圏ネットワーク内のＭＳＣ−Ｓ１１２は、どんなＩＣＳサポートも提供せず、従って、いかなるＵＳＳＤオペレーションであっても、ホームネットワーク内のＨＬＲ１８０に常駐するＵＳＳＤアプリケーションへトランスペアレントに転送する（ステップ２）。ＨＬＲ１８０は、負荷共有の検討に基づいてＩＡ選択を行う（ステップ３）。次いで、選択されたＩＡ１５０によって、ＨＳＲ１６０に対してＩＣＳサブスクリプションチェックが行われる（ステップ４）。ＩＣＳサブスクリプションが存在する場合、端末１２０はＩＭＳ１１４に登録される（ステップ５）。加えて、選択されたＩＡ１５０は、ユニークな識別子をＨＬＲ１８０に対して、および端末１１０に常駐するＩＣＳクライアントアプリケーション１２０に対して、将来の利用のために返信する（ステップ６）。

図６〜図１０に示すシナリオでは、ＭＳＣ−Ｓ１１２は、ネットワークベースのＩＣＳクライアントアプリケーションを用いるかどうかまたは端末ベースのＩＣＳクライアントアプリケーションを許可するかどうかの決定制御権を運用業者１７０または加入者に与えるため、追加のメカニズムを実装することもできる。ＭＳＣ−Ｓ１１２における追加の機能は、端末ベースのＩＣＳクライアントアプリケーションが利用可能であり、ＭＳＣ−Ｓ１１２によって検出されてはいるが、ネットワークベースのＩＣＳサポートを起動することもできる。このような優先は、例えば、加入者データの端末ベースのＩＣＳサポートについての規制表示によって、あるいは、特定のネットワークからのそのような規制をすべてのローミング中の加入者に設定することによって表わされるような運用業者の好みに基づいてもよい。このような優先は、ＭＳＣ−Ｓ１１２のＵＳＳＤアプリケーションで（例えば、ＭＳＣ−Ｓ１１２のいかなるＩＭＳ登録ＵＳＳＤ列をも拒否することによって）実施されてもよい。

ＣＳネットワークにおけるローミングシナリオ
図１１〜図１２は、アクティベートされた状態（作動状態）にある端末ベースのＩＳＣクライアントアプリケーションに関連してローミング中の端末１１０のために行われる動作を示す。図６〜図７に示す当初のＩＳＣクライアント選択手順を実行したのと同じＭＳＣ−Ｓ１１２のサービスエリアの中をローミングする場合、図１１のステップ１〜６で示すような新たな動作はまったく行われない。旧ＭＳＣ−Ｓ１１２のサービスエリアを去り、新ＭＳＣ−Ｓ１１２’のサービスエリアに入る場合、ＩＡ識別子とＩＣＳサービスのステータスがＨＬＲ１８０からダウンロードされ、従って、端末ベースのＩＣＳクライアントアプリケーションが以前に用いられていた場合には、この状態が継続され、同じＩＡ１５０がその先も用いられるであろう（図１１のステップ７〜１２）。

関連するシグナリングフローの詳細は図１２に示されている。

ステップ１）〜ステップ５）：ロケーション更新タイプのＬＡ変更、ＨＬＲ１８０に対する更新、及び、加入者データのＶＬＲへの挿入。加入者データはＩＣＳサブスクリプションを含む。その状態はネットワークベースのＩＣＳサポート（即ち、ネットワークベースのＩＣＳクライアントアプリケーション）がディアクティベートされた状態（非作動状態）であることを示す。

ステップ６）〜ステップ７）：ＭＳＣ−Ｓ１１２のモビリティ管理レイヤがＶＬＲのＩＣＳサブスクリプションをチェックする。その状態はネットワークベースのＩＣＳサポートがディアクティベートされた（非作動状態）であること示すので、ＭＳＣ−Ｓ１１２でさらなる動作は実行されない。

図１３と図１４は、ローミング中の端末１１０のために行われる、アクティベートされたネットワークベースのＩＳＣクライアントアプリケーションに関連する動作を示す。図８〜図９に示したように当初のＩＳＣクライアント選択手順を実行したのと同じＭＳＣ−Ｓ１１２のサービスエリアの中をローミングする場合、図１３のステップ１〜５で示すような新たな動作はまったく行われない。旧ＭＳＣ−Ｓ１１２のサービスエリアを去り、新ＭＳＣ−Ｓ１１２’のサービスエリアに入る場合、ＩＡ識別子とＩＣＳサービスのステータスがＨＬＲ１８０からダウンロードされ、従って、ネットワークベースのＩＣＳクライアントアプリケーションが以前に用いられていた場合には、この状態が継続され、同じＩＡ１５０がその先も用いられるであろう（図１３のステップ６〜１２）。

関連するシグナリングフローの詳細が図１４に示されている。

ステップ１）〜ステップ５）：ロケーション更新タイプのＬＡ変更、ＨＬＲ１８０に対する更新、そして、加入者データのＶＬＲへの挿入。加入者データはここでもやはりＩＣＳサブスクリプションを含む。状態はネットワークベースのＩＣＳサポートがアクティベートされた状態（作動状態）であることと、さらに割り当てられたＩＡ識別子とを示す。

ステップ６）〜ステップ７）：ＭＳＣ−Ｓ１１２’の中のモビリティ管理レイヤが、ＶＬＲの中のＩＣＳサブスクリプションをチェックする。状態は、ネットワークベースのＩＣＳサポートがアクティベートされた状態（作動状態）にあることを示すので、新たなローカルなネットワークベースのＩＣＳクライアントアプリケーションが、ＭＳＣ−Ｓ１１２’によって捕捉される必要がある。

ステップ８）〜ステップ９）：新たなＩＣＳクライアントアプリケーションが捕捉される。新たなＩＣＳクライアントアプリケーションはアクティブな状態のＩＭＳ登録やタイマステータスのデータを全くもたないので、ＩＭＳ再登録がトリガされねばならない。

ステップ１０）〜ステップ１６）：以前と同じＩＡ１５０を介してＩＭＳ再登録が行われる。ＨＳＲサブスクリプションのチェックは必要ない。

ＨＬＲに関わるロケーション削除手順
端末１１０が新たなＭＳＣ−Ｓ１１２’のサービスエリアに進入するとき、旧ＭＳＣ−Ｓ１１２がＨＬＲ１８０から削除される。アクティベートされた状態（作動状態）の端末ベースのＩＣＳクライアントアプリケーションの場合、さらなる動作は必要ない。この場合はＶＬＲにおいてＩＣＳサブスクリプションステータスをチェックすることによって、新たなＭＳＣ−Ｓ１１２’によって識別される。ネットワーク中心のＩＣＳサポートが用いられた場合、旧ＭＳＣ−Ｓ１１２のＩＣＳクライアントアプリケーションは、図１５のシグナリングフローに示されるように解放される必要がある。ＩＡ１５０が新たなＭＳＣ−Ｓ１１２’によって再利用されるため、ＩＡ１５０またはＩＭＳ１１４へのさらなる動作は必要ない。

ＣＳデタッチ（分離）処理
端末１１０の電源がオフになると、図１６〜図１７のシグナリングフローに模式的に図示するように、ＭＳＣ−Ｓ１１２においてデタッチ表示が受信される。

端末ベースのＩＣＳクライアントアプリケーション（図１６）の場合、端末１１０がＵＳＳＤ列をまったく送信できないため、更なる動作を行うことができない。

ステップ１）：端末１１０からのデタッチ表示をＭＳＣ−Ｓ１１２が受信する。

ステップ２）〜ステップ３）：ＭＳＣ−Ｓ１１２のモビリティ管理レイヤが、ＩＣＳサブスクリプションをチェックする。ネットワークベースのＩＣＳサポートがディアクティベートされた状態（非作動状態）であるので、更なる動作は行われない。

ステップ４）〜ステップ５）：ＩＡ１５０の登録管理タイマが切れて、ＩＡ１５０が自分自身を解放する。ＩＭＳ登録の期限が切れて、ＩＭＳ１１４によって自動的に消去される。

なお、図１６に示すシナリオの中で、ＭＳＣ−Ｓ１１２は、ＩＡ識別子（端末ベースのＩＣＳサポート）について情報提供されていないため、ＩＡ１５０にコンタクトすることができない。

ネットワークベースのＩＣＳクライアントサポートの場合、ネットワークベースのＩＣＳクライアントアプリケーションは、図１７に概略を示すようにＩＭＳ登録をやはり停止することができる。

ステップ１）：端末１１０からのデタッチ表示をＭＳＣ−Ｓ１１２が受信する。

ステップ２）〜ステップ３）：ＭＳＣ−Ｓ１１２のモビリティ管理レイヤがＩＣＳサブスクリプションをチェックし、このチェックがネットワークベースのＩＣＳクライアントアプリケーションがアクティベートされた状態（作動状態）にあることを示す。

ステップ４）：モビリティ管理レイヤがネットワークの中のＩＣＳクライアントアプリケーションにデタッチについて情報提供する。

ステップ５）〜ステップ１１）：ＩＡ１５０を介したＩＭＳ登録取消が行われて、ＩＡインスタンスが解放される。

ステップ１２）〜ステップ１３）ＭＳＣ−Ｓ１１２のＵＳＳＤアプリケーションがＨＬＲ１８０とＶＬＲを更新して、ＩＡ識別子を削除する。

再登録手順
ＩＣＳクライアントアプリケーションはＩＭＳ登録を時間管理する必要があり、即ち、ＩＭＳ登録が切れる少し前に、ＩＣＳクライアントアプリケーションは、加入者を、従って端末１１０を再登録する必要がある。

端末ベースのＩＣＳクライアントアプリケーションの場合には、これは、図１８のシグナリングフローにより詳細に示されるように、端末１１０の中で行われる。タイマが切れると、呼と独立のトランザクション（Call Independent transaction）が確立され、ＵＳＳＤを介して再登録が開始される。

ネットワークベースのＩＣＳクライアントアプリケーションの場合には、図１９のシグナリングフローで示されるように、ＭＳＣ−Ｓ１１２でタイマが動く。そのタイマが切れると、ネットワークベースのＩＣＳクライアントアプリケーションが再登録のためにＩＡ１５０にコンタクトする。

自己管理
ネットワークベースのＩＣＳサポートとそのステータス（状態）管理は、ＨＬＲ１８０において運用業者によって提供される。そのステータスは以下のことを用いることによって加入者によって変更される。即ち、
− ｎＩＣＳサービスを使って拡張された、既存の補足的サービス（ＳＳ）手順、
または、
− Ｕｔ手順、または
− ウェブポータル及びこのウェブポータルに対するＰＳアクセス
である。

実施例から明らかになったように、端末中心のＩＣＳ（ｕＩＣＳ）とネットワーク中心のＩＣＳ（ｎＩＣＳ）の利点が組み合わさって、端末ベースのクライアントアプリケーションとネットワークベースのクライアントアプリケーションとが１人の加入者（または１つの端末）について１つのネットワークに共存する１つの動的な解決策となることが可能になる。加入者がＩＣＳクライアントアプリケーションを有する新型の端末を使用する場合、その加入者は、端末ベースのやり方を用いて完全なＩＭＳ機能範囲を経験することができる。その加入者がＩＣＳクライアントアプリケーションを有しない旧型の端末を使用する場合、１つ、それ以上、またはすべてのＩＭＳ機能の恩恵を受けるためにネットワーク支援を得ることができる。

実施例では、ネットワーク側が端末側の能力に動的に適合し、そして、ネットワーク中心のＩＣＳクライアントアプリケーションを提供するか、あるいは、ネットワークが端末内にＩＣＳクライアントアプリケーションを検出するかまたはネットワークが端末にインストールされているＩＣＳクライアントアプリケーションをアクティベートするように明示的に端末に命令した場合には、ネットワーク中心のＩＣＳクライアントアプリケーションがディアクティベート（非作動）状態にされる。さらに、実施例は、ＩＣＳクライアントサポートがいったん提供されたら、ＣＳネットワーク内でＭＳＣ−Ｓノード間をローミング中にどのように維持されるかを示す。

本発明の実施例が添付図面で図示され、発明の詳細な説明で述べられてきたが、本発明はここに開示された実施例に限定されるものではないということは理解されよう。特に、本発明は、次の請求の範囲で説明されそれらによって定義される本発明の精神から逸脱することなく、多くの再構成、修正、及び代替が可能である。

Claims (25)

1. 回線交換アクセス領域（１２２）からＩＭＳ統一サービス領域（１１４）への呼のＩＣＳルーティングをサポートする機能を提供する１つ以上のＩＭＳ集中型サービス、或は、ＩＣＳクライアントアプリケーションのアクティベーション状態を制御する方法であって、第１のＩＣＳクライアントアプリケーション（１３２）がネットワーク側（１１２）で提供され、前記方法は、前記ネットワーク側（１１２）において、
   メッセージを端末側（１１０）から受信する工程と、
   前記メッセージに応じて、前記端末側（１１０）に備えられた第２のＩＣＳクライアントアプリケーション（１２０）がルーティング機能を提供することになることを検出する工程と、
   前記検出の結果に従って、前記第１のＩＣＳクライアントアプリケーション（１３２）のアクティベーション状態を制御する工程とを有し、
   前記制御は前記第１のＩＣＳクライアントアプリケーション（１３２）をディアクティベートすることを含むことを特徴とする方法。
2. 前記第２のＩＣＳクライアントアプリケーション（１２０）のアクティベーション状態を制御する工程をさらに有し、
   前記制御は前記第２のＩＣＳクライアントアプリケーション（１２０）をアクティベートすることを含むことを特徴とする請求項１に記載の方法。
3. 回線交換アクセス領域（１２２）からＩＭＳ統一サービス領域（１１４）への呼のＩＣＳルーティングをサポートする機能を提供する１つ以上のＩＭＳ集中型サービス、或は、ＩＣＳクライアントアプリケーションのアクティベーション状態を制御する方法であって、第１のＩＣＳクライアントアプリケーション（１３２）がネットワーク側（１１２）で提供され、前記方法は、前記ネットワーク側（１１２）において、
   メッセージを端末側（１１０）から受信する工程と、
   前記メッセージに応じて、前記端末側（１１０）の第２のＩＣＳクライアントアプリケーション（１２０）がルーティング機能を提供することにならないことを検出する工程と、
   前記検出の結果に従って、前記第１のＩＣＳクライアントアプリケーション（１３２）のアクティベーション状態を制御する工程とを有し、
   前記制御は前記第１のＩＣＳクライアントアプリケーション（１３２）をアクティベートするか、或は前記第１のＩＣＳクライアントアプリケーション（１３２）のアクティベートされた状態を維持することを含むことを特徴とする方法。
4. 前記第１のＩＣＳクライアントアプリケーション（１３２）は、もし前記第２のＩＣＳクライアントアプリケーション（１２０）が検出できないなら、アクティベートされた状態であるように制御されることを特徴とする請求項３に記載の方法。
5. 前記第１のＩＣＳクライアントアプリケーション（１３２）は、もし前記第２のＩＣＳクライアントアプリケーション（１２０）が検出できるなら、ディアクティベートされた状態であるように制御されることを特徴とする請求項１又は２に記載の方法。
6. 前記第１のＩＣＳクライアントアプリケーション（１３２）がディアクティベートされた状態において、前記第２のＩＣＳクライアントアプリケーション（１２０）からの制御シグナリングと前記第２のＩＣＳクライアントアプリケーション（１２０）への制御シグナリングをトランスペアレントに転送する工程をさらに有することを特徴とする請求項５に記載の方法。
7. 前記メッセージは前記呼のルーティング機能を提供することになる前記第２のＩＣＳクライアントアプリケーションの表示を含み、
   前記第１のＩＣＳクライアントアプリケーション（１３２）の前記アクティベーション状態は前記メッセージの表示に依存して制御されることを特徴とする請求項１乃至６のいずれか１項に記載の方法。
8. 前記表示は、前記第２のＩＣＳクライアントアプリケーション（１２０）によって生成される前記ＩＭＳ統一サービス領域（１１４）への登録要求であることを特徴とする請求項７に記載の方法。
9. 前記第２のＩＣＳクライアントアプリケーション（１２０）のアクティベーション状態に関係する命令を前記端末側（１１０）に送信する工程をさらに有することを特徴とする請求項１乃至８のいずれか１項に記載の方法。
10. 前記第１と第２のＩＣＳクライアントアプリケーション（１３２；１２０）の内の少なくとも１つの現在のアクティベーション状態をロケーション登録データベース（１８０）に格納する工程をさらに有することを特徴とする請求項１乃至９のいずれか１項に記載の方法。
11. 前記ＩＭＳ統一サービス領域（１１４）に対するインタフェース構成要素（１５０）を選択する工程と、
    前記第１と第２のＩＣＳクライアントアプリケーション（１３２；１２０）の内のアクティベートされたクライアントアプリケーションを前記選択されたインタフェース構成要素（１５０）に接続する工程とをさらに有することを特徴とする請求項１乃至１０のいずれか１項に記載の方法。
12. 前記選択されたインタフェース構成要素（１５０）の識別子をロケーション登録データベース（１８０）と前記第１と第２のＩＣＳクライアントアプリケーション（１３２；１２０）の内のアクティベートされたクライアントアプリケーションとの内の少なくとも１つに送信する工程をさらに有することを特徴とする請求項１１に記載の方法。
13. 在圏ネットワークへローミング中の端末（１１０）に関し、
    前記在圏ネットワークにより、前記選択されたインタフェース構成要素（１５０）の識別子を受信する工程と、
    前記在圏ネットワークにより、前記選択されたインタフェース構成要素（１５０）を介して前記ＩＭＳ統一サービス領域内で前記ローミング中の端末（１１０）の登録の更新を実行する工程とをさらに有することを特徴とする請求項１２に記載の方法。
14. 前記在圏ネットワークでは、
    前のネットワークでの前記第１のＩＣＳクライアントアプリケーション（１３２）のアクティベーション状態を受信して評価する工程と、
    前記前のネットワークでの前記第１のＩＣＳクライアントアプリケーション（１３２）がアクティベーション状態にあるなら、新たな第１のＩＣＳクライアントアプリケーション（１３２）をインスタンス化する工程とをさらに有することを特徴とする請求項１３に記載の方法。
15. 前記ルーティング機能は、サブスクリプションベースで提供され、
    サブスクリプション情報を要求することと受信することのいずれか一方の工程を有することを特徴とする請求項１乃至１４のいずれか１項に記載の方法。
16. 前記ルーティング機能に関する許可情報を要求する工程と、
    前記要求した許可情報を受信する工程と、
    前記受信された許可情報に応じて、前記端末（１１０）を前記ＩＭＳ統一サービス領域（１１４）内で登録する工程とをさらに有することを特徴とする請求項１乃至１５のいずれか１項に記載の方法。
17. 回線交換アクセス領域（１１２）からＩＭＳ統一サービス領域（１１４）への呼のＩＣＳルーティングをサポートする機能を提供する１つ以上のＩＭＳ集中型のサービス、或はＩＣＳクライアントアプリケーションのアクティベーション状態を制御する方法であって、
    第１のＩＣＳクライアントアプリケーション（１３２）がネットワーク側（１１２）に備えられ、
    前記方法は端末側で、
    前記端末側（１１０）に備えられた第２のＩＣＳクライアントアプリケーション（１２０）が呼をルーティングする機能を提供することになるという表示を生成する工程と、
    前記表示を前記ネットワーク側（１１２）へ送信し、前記第１のＩＣＳクライアントアプリケーションをディアクティベートする工程とを有することを特徴とする方法。
18. 前記端末側（１１０）に前記第２のＩＣＳクライアントアプリケーション（１２０）を備える工程をさらに有し、
    前記表示は、前記第２のＩＣＳクライアントアプリケーション（１２０）の利用可能性への参照を含むことを特徴とする請求項１７に記載の方法。
19. 前記第２のＩＣＳクライアントアプリケーション（１２０）をアクティベートする工程をさらに有することを特徴とする請求項１７又は１８に記載の方法。
20. １つ以上のコンピュータ機器において請求項１乃至１９のいずれか１項に記載の工程を実行するプログラムコード部を有することを特徴とするコンピュータプログラム。
21. 前記コンピュータプログラムはコンピュータ可読媒体に格納されることを特徴とする請求項２０に記載のコンピュータプログラム。
22. 回線交換アクセス領域（１１２）からＩＭＳ統一サービス領域（１１４）への呼のＩＣＳルーティングをサポートする機能を提供する１つ以上のＩＭＳ集中型サービス、或は、ＩＣＳクライアントアプリケーションのアクティベーション状態を制御するネットワークノード（１１２）であって、
    第１のＩＣＳクライアントアプリケーション（１３２）がネットワーク側（１１２）で備えられ、前記ネットワークノードは、
    端末側（１１０）からメッセージを受信するように適合されたインタフェース（１３０）と、
    前記メッセージに応じて、前記端末側（１１０）に備えられた第２のＩＣＳクライアントアプリケーション（１２０）がルーティング機能を提供することになることを検出するように適合された検出器（１３４）と、
    前記検出の結果に応じて、前記第１のＩＣＳクライアントアプリケーション（１３２）のアクティベーション状態を制御するように適合されたコントローラ（１３６）とを有し、
    前記制御は前記第１のＩＣＳクライアントアプリケーション（１３２）をディアクティベートすることを含むことを特徴とするネットワークノード。
23. 回線交換アクセス領域（１１２）からＩＭＳ統一サービス領域（１１４）への呼のＩＣＳルーティングをサポートする機能を提供する１つ以上のＩＭＳ集中型サービス、或は、ＩＣＳクライアントアプリケーションのアクティベーション状態を制御するネットワークノード（１１２）であって、
    第１のＩＣＳクライアントアプリケーション（１３２）がネットワーク側（１１２）で備えられ、前記ネットワークノードは、
    端末側（１１０）からメッセージを受信するように適合されたインタフェース（１３０）と、
    前記メッセージに応じて、前記端末側（１１０）に備えられた第２のＩＣＳクライアントアプリケーション（１２０）がルーティング機能を提供することにならないことを検出するように適合された検出器（１３４）と、
    前記検出の結果に応じて、前記第１のＩＣＳクライアントアプリケーション（１３２）のアクティベーション状態を制御するように適合されたコントローラ（１３６）とを有し、
    前記制御は前記第１のＩＣＳクライアントアプリケーション（１３２）をアクティベートするか、或は、前記第１のＩＣＳクライアントアプリケーション（１３２）のアクティベートされた状態を維持することを含むことを特徴とするネットワークノード。
24. 回線交換アクセス領域（１１２）からＩＭＳ統一サービス領域（１１４）への呼のルーティングをサポートする機能を提供する１つ以上のＩＭＳ集中型サービス、或は、ＩＣＳクライアントアプリケーションのアクティベーション状態を制御する端末（１１０）であって、
    第１のＩＣＳクライアントアプリケーション（１３２）がネットワーク側（１１２）に備えられ、前記端末（１１０）は、
    前記端末側（１１０）に備えられた第２のＩＣＳクライアントアプリケーション（１２０）が前記呼のルーティング機能を提供することになることの表示を生成するプロセッサ（１２４）と、
    前記ネットワーク側（１１２）へ前記表示を送信し、前記第１のＩＣＳクライアントアプリケーション（１３２）のディアクティベーションを実行するように適合されたインタフェース（１２２）とを有することを特徴とする端末。
25. 前記第２のＩＣＳクライアントアプリケーション（１２０）をさらに有することを特徴とする請求項２４に記載の端末。

Images