JP2009502071A - Ｉｍｓネットワークにおけるサーバの割当方法及び装置 - Google Patents

Abstract

ＩＰマルチメディアサブシステム内のアプリケーションサーバにリクエストを方法である。この方法は、ＩＰマルチメディアサブシステムのエンティティにおいて、ＩＰマルチメディアサブシステムのユーザに関連するリクエストの受信時に、ユーザがアプリケーションサーバに割り当てられているか否かを判定するために、一元的に保持されるデータベースに問い合わせる工程を備える。ユーザがアプリケーションサーバに割り当てられていないと判定される場合、ユーザはこのエンティティにおいてアプリケーションサーバに割り当てられ、そのリクエストはこのエンティティから割り当てられているアプリケーションサーバに転送され、アプリケーションサーバまたはこのエンティティからデータベースに送信されているリクエストは、その割当をそこに記録させる。ユーザが既にアプリケーションサーバに割り当てられていると判定される場合、このリクエストはこのエンティティから割り当てられているアプリケーションサーバに転送される。
【選択図】 なし

Description

本発明の分野
本発明は、ＩＰマルチメディアサブシステムネットワークにおけるサーバの割り当てる方法および装置に関するものであり、特に、必須ではないが、ＩＰマルチメディアサブシステムユーザにアプリケーションサーバを動的に割り当てる方法および装置に関するものである。

本発明に対する背景
ＩＰマルチメディアサービスは、同一セッション内の音声、ビデオ、メッセージング、データ等の動的な組み合わせを提供する。組み合わせすることが可能な基本アプリケーション数およびメディア数の増加によって、エンドユーザ（例えば、加入者）に提供されるサービス数は増大し、個人間通信の経験は豊かになるだろう。このことは、いわゆる「複合ＩＰマルチメディア」サービスを含む、個人向けの豊かなマルチメディア通信サービスの新世代を導くことになるだろう。

ＩＰマルチメディアサブシステム（ＩＭＳ）は、第３世代パートナーシッププロジェクト（３ＧＰＰ）によって規定された技術であり、これは、移動通信ネットワーク上でＩＰマルチメディアサービスを提供する（３ＧＰＰ ＴＳ ２２．２２８、ＴＳ ２３．２２８、ＴＳ ２４．２２９、ＴＳ ２９．２２８、ＴＳ ２９．２２９、ＴＳ ２９．３２８およびＴＳ ２９．３２９ リリース５〜７）。ＩＭＳは、標準化ＩＭＳサービスイネーブラの使用を通じて、エンド加入者の個人対個人の通信経験を豊かにするために重要な機能を提供する。ＩＭＳサービスイネーブラは、ＩＰベースのネットワーク上で、新規の豊かな個人対個人（クライアント・ツー・クライアント）通信サービスおよび個人対コンテンツ（クライアント・ツー・サーバ）サービスを容易にする。ＩＭＳは、加入者端末間（または加入者端末とアプリケーションサーバとの間）の呼またはセッションをセットアップおよび制御するために、セッション開始プロトコル（ＳＩＰ：Session Initiation Protocol）を使用する。ＳＩＰシグナリングにより搬送されるセッション記述プロトコル（ＳＤＰ：Session Description Protocol）は、セッションのメディアコンポーネントを記述し、かつネゴシエートするために使用される。ＳＩＰが加入者対加入者のプロトコルとして生成されているのに対して、ＩＭＳは、オペレータおよびサービスプロバイダがサービスへの加入者アクセスを制御し、それに応じて加入者に課金することを可能にする。

一例として、図１は、ＧＰＲＳ／ＰＳアクセスネットワーク（ＩＭＳは、もちろん他のアクセスネットワーク上で動作してもよい）の場合に、移動ネットワークアーキテクチャにＩＭＳがどのように適合するかを概略的に示している。呼／セッション制御機能（ＣＳＣＦ：Call/Session Control Function）は、ＩＭＳ内でＳＩＰプロキシとして動作する。３ＧＰＰアーキテクチャは、３種類のＣＳＣＦを規定している。これらの内、プロキシ（Ｐｒｏｘｙ） ＣＳＣＦ（Ｐ−ＣＳＣＦ）は、ＳＩＰ端末に対するＩＭＳ内の第１の接点である。在圏（Ｓｅｒｖｉｎｇ）ＣＳＣＦ（Ｓ−ＣＳＣＦ）は、加入者に加入者が加入しているサービスを提供する。、尋問（Ｉｎｔｅｒｒｏｇａｔｉｎｇ） ＣＳＣＦ（Ｉ−ＣＳＣＦ）の役割は、正規のＳ−ＣＳＣＦを識別し、そのＳ−ＣＳＣＦにＰ−ＣＳＣＦを介してＳＩＰ端末から受信した要求を転送することである。

加入者は、規定のＳＩＰ ＲＥＧＩＳＴＥＲメソッドを使用してＩＭＳに登録する。これは、ＩＭＳに参加し、ＳＩＰ加入者アイデンティティに到達できるアドレス（「連絡先」）をＩＭＳに通知するメカニズムである。３ＧＰＰでは、ＳＩＰ端末が登録を実行する場合、ＩＭＳは加入者を認証し、その加入者に利用可能なＳ−ＣＳＣＦのセットの中から１つのＳ−ＣＳＣＦを割り当てる。Ｓ−ＣＳＣＦを割り当てる基準は３ＧＰＰでは規定されていないが、これには、負荷分散およびサービス要件を含んでも良い。Ｓ−ＣＳＣＦの割当は、ＩＭＳベースのサービスへの加入者アクセスを制御（および課金）するために重要であることに注意されたい。オペレータは、直接の加入者対加入者ＳＩＰセッションを防ぐメカニズムを提供してもよく、そうしないと直接の加入者対加入者ＳＩＰセッションは、Ｓ−ＣＳＣＦを回避することになる。

Ｓ−ＣＳＣＦがまだ選択されていない場合、登録プロセス中に、Ｓ−ＣＳＣＦを選択することはＩ−ＣＳＣＦの担当となる。Ｉ−ＣＳＣＦは、ホームネットワークのホーム加入者サーバ（ＨＳＳ：Home Subscriber Server）から必要なＳ−ＣＳＣＦ機能を受信し、その受信した機能に基づいて適切なＳ−ＣＳＣＦを選択する。［Ｓ−ＣＳＣＦ割当は、ユーザが別のパーティ（加入者）からの呼を受け、加入者がＳ−ＣＳＣＦを現在割り当てられていない場合に、その加入者に対しても、Ｉ−ＣＳＣＦによって実行されることに注意されたい。］複数のＨＳＳがネットワークに配置される場合、加入者に対する正規のＨＳＳを識別するために、加入ロケータ機能（ＳＬＦ：Subscription Locator Function）がＩ−ＣＳＣＦによって使用される。登録された加入者が引き続きＩＭＳにセッションリクエストを送信する場合、Ｐ−ＣＳＣＦは、登録プロセス中にＳ−ＣＳＣＦから受信される情報に基づいて、選択されたＳ−ＣＳＣＦにそのリクエストを転送することができる。

ＩＭＳサービスネットワーク内には、ＩＭＳサービス機能を実現するために、アプリケーションサーバ（ＡＳ）が提供される。アプリケーションサーバは、ＩＭＳシステム内のエンド加入者にサービスを提供し、３ＧＰＰが規定するＭｒインタフェースを通じて端点として接続されても良いし、または、３ＧＰＰ規定のＩＳＣインタフェースを通じてＳ−ＣＳＣＦによって「リンクイン（liked in）」されても良い。後者の場合には、初期フィルタ基準（ＩＦＣ：Initial Filter Criteria）がＳ−ＣＳＣＦによって使用され、ＳＩＰセッション確立中（または、実際には、任意のＳＩＰメソッドのために、セッションに関係または非セッションに関係）、どのアプリケーションサーバが「リンクイン」されるべきかを決定する。このＩＦＣは、加入者の加入者プロファイルの一部としてＩＭＳ登録手順中、ＨＳＳからＳ−ＣＳＣＦによって受信される。

図２は、ＡＳとＳ−ＣＳＣＦとの間のＩＭＳサービス制御（ＩＳＣ：IMS Service Control）インタフェースおよびＩＭＳ内の他のインタフェースを示している。図２のＡＳは、Ｓ−ＣＳＣＦへのインタフェースを１つだけ有するように示されているが、当然のことながら、実際には、ＩＳＣインタフェースは、所与のオペレータのネットワークのＣＳＣＦサーバの多く（またはすべて）が接続されている通信ネットワークの全域で使用され、ＡＳがこれらのＣＳＣＦのすべてと通信することを可能にする。［図２に示される他のエンティティは、当業者には周知であろう。］
別のインタフェース（Ｕｔ）が、ＡＳと加入者端末（ＴＳ ２３．００２）との間に存在するが、これは図示されていない。Ｕｔインタフェースは、例えば、パブリックサービスアイデンティティの作成および割当、例えば、「プレゼンス（存在）」サービスによって使用される権限付与（認可）ポリシーの管理、会議ポリシー管理等の自身のサービスに関する情報を、加入者が管理することを可能にする。

３ＧＰＰで規定されるＩＭＳでは、加入者はＨＳＳに静的に割り当てられるが、ＡＳこそが、ネットワークによって提供されるサービスである場合に特定の値を提供する。３ＧＰＰ規格のリリース５と６の解釈は、加入者は固定の方法で特定のＳＩＰ ＡＳに割り当てられることを示唆している。この基本概念は、所与の１つ以上のサービスに関して特定の１つのＳＩＰ−ＡＳによってサポートされることが加入者に提供されることである。割り当てられたＳ−ＣＳＣＦがＩＳＣインタフェースを通じて割り当てられたＡＳに到達することを可能にするために、そのサービスに関するその加入者に対するフィルタ基準（ＨＳＳからＳ−ＣＳＣＦに送信されるＩＦＣ内に含まれる）は、宛先アドレス（ＳＩＰ−ＵＲＩとして記号化される）として完全記述ドメイン名（ＦＱＤＮ：fully qualified domain name）またはＩＰアドレスを含んでいる。このことが意味することは、例えば、Ｓ−ＣＳＣＦが、特定のＩＮＶＩＴＥをＡＳに転送されるべきであると識別する場合に、Ｓ−ＣＳＣＦに、Ｃｘインタフェースを介して特定のＡＳのアドレスが提供されることである。例えば、加入者端末とＳＩＰ−ＡＳとの間のＵｔインタフェース等の他のインタフェースに対する正規のＡＳを識別するために、ルーティングプロキシには、特定の加入者に対するＡＳのアドレスを提供される。加入者に特定のＡＳが割り当てられる場合、端末はそのインタフェースおよびサービスに対するＡＳのアドレスで設定される、または端末はその加入者に対するＡＳのアドレスの取得方法を知っているエンティティにリクエストを送信する。「フロントエンド」はこれを実行することができ、そのような場合、ルーティング機能はフロントエンドに構成されるであろう。

本発明の要約
上述の説明から明らかであるように、加入者へのＡＳの割当に関する既存の提案は、所与のサービスまたはサービスセットに対して、加入者への特定のＳＩＰアプリケーションサーバのプロビジョン（provisioning）を必要とする。これは、高レベルの利用可能性およびＡＳでの永続的なデータ記憶を必要とする。その理由は、１つのＡＳが一時的に利用不可能になる場合または適切な情報を保有しない場合、そのＡＳが割り当てられている加入者に対しては、プロビジョンされているサービス（群）は利用不可能になるからである。このアプローチの採用は、各ＡＳに冗長性の組み込みを必要としても良い。さらに、静的な加入者の割当は、ネットワークの動作態様を複雑にし、ＡＳへの加入者の再割当のような動作を重要なタスクにする。このような再割当は、例えば、ネットワーク内の加入者数が追加の容量（処理能力、メモリ等）を必要とするほど多くなる場合に必要となることがある。

本発明の第１の態様に従えば、ＩＰマルチメディアサブシステム内のアプリケーションサーバに要求を向ける（direct：行う）方法が提供される。この方法は、
ＩＰマルチメディアサブシステムのエンティティにおいて、ＩＰマルチメディアサブシステムユーザに関連するリクエストの受信時、ユーザがアプリケーションサーバに割り当てられているか否かを判定するためにデータベースに問い合わせる工程と、
ユーザがアプリケーションサーバに割り当てられていないと判定される場合、このエンティティにおいてユーザをアプリケーションサーバに割り当て、このエンティティからのリクエストを割り当てられたアプリケーションサーバに転送し、その割当がデータベースに記録されるように、アプリケーションサーバまたはこのエンティティからのリクエストをデータベースに送信する工程と、
ユーザがアプリケーションサーバに割り当てられていると判定される場合、このエンティティからのリクエストを割り当てられているアプリケーションサーバに転送する工程と
を備える。

本発明の実施形態は、ＩＰマルチメディアサブシステムのユーザをセッション開始プロトコルアプリケーションサーバ（ＳＩＰ−ＡＳ）へ動的に割り当てる処理手段を提供する。ユーザの動的割り当ての利点は、割当データの永続的な記憶要件が緩められ、例えば、新規のアプリケーションサーバを導入することによって、ネットワークアーキテクチャの変更とアップグレードがより容易になることである。

このリクエストは、セッション開始プロトコルリクエストまたはユーザのアプリケーションサーバに向かう任意の他のプロトコル（例えば、Ｕｔインタフェース）に準拠するリクエストであっても良い。

好ましくは、ユーザがアプリケーションサーバに割り当てられているか否かを判定するためのデータベースへの問い合わせのステップは、セッション開始プロトコルに従って実行される。

本発明の一実施形態では、ＩＰマルチメディアサブシステムのエンティティは、サービング（serving：在圏）呼セッション制御機能である。この場合は、問い合わせおよびその問い合わせへの応答は、Ｃｘインタフェースを通じてホーム加入者サーバに送信される。

代替の実施形態では、このＩＰマルチメディアサブシステムのエンティティは、フロントエンドディストリビュータまたはネットワークの残りの部分に対して単一の論理的アプリケーションサーバとして動作する「代表」アプリケーションサーバである。ＩＰマルチメディアサブシステムの在圏呼セッション制御機能において、ユーザから受信したリクエストに対して、フロントエンドディストリビュータは、ＩＳＣインタフェース上の、アプリケーションサーバと在圏呼セッション制御機能との間に配置される。在圏呼セッション制御機能でのリクエストの受信時、在圏呼セッション制御機能は、ホーム加入者サーバに問い合わせて、リクエストが送信されるべきフロントエンドディストリビュータを識別する。この問い合わせは、在圏呼セッション制御機能に単一のフロントエンドディストリビュータの識別情報を返信しても良いし、あるいはこの問い合わせは、１つのフロントエンドディストリビュータがその中から選択されるフロントエンドディストリビュータのグループを識別しせても良い。

選択的には、フロントエンドディストリビュータは、Ｕｔインタフェースを通じてユーザからリクエストを受信しても良い。

このフロントエンドディストリビュータは、ＩＰマルチメディアサブシステム内のスタンドアローンノードであっても良い。選択的には、アプリケーションサーバに常駐する機能エンティティであっても良い。後者の場合には、フロントエンドディストリビュータは、それが常駐するアプリケーションサーバにリクエストを転送しても良いし、ユーザが割り当てられているアプリケーションサーバに依存する別のアプリケーションサーバにリクエストを転送しても良い。

前述のデータベースは、ホーム加入者サーバに提供されても良い。ユーザのアプリケーションサーバへの割当は、トランスペアレントおよび非トランスペアレントＩＳＣインタフェースの少なくともを使用して、ホーム加入者サーバに記憶されても良い。他の代替の一元的に保持されるデータベースは、ＬＤＡＰディレクトリおよびＳＱＬ、ＪＤＢＣ、ＯＤＢＣ等のインタフェースを通じて利用可能なリレーショナル／オブジェクトデータベースを含んでも良い。このデータベースを、ネットワーク内の複数の位置で保持することも可能である。例えば、アプリケーションサーバ割当を実行するエンティティがＦＥ−ＤＩＳＴである場合は、データベースのコピーが各ＦＥ−ＤＩＳＴで提供されても良い。

好ましくは、アプリケーションサーバまたは前述のエンティティからデータベースへ送信されるリクエストは、アプリケーションサーバの１つ以上のアドレスを含んでいる。アドレスは、アプリケーションサーバが接続されている各インタフェースに対するものが含まれても良い。

ユーザが従前にアプリケーションサーバに割り当てられていない場合には、アプリケーションサーバは、ホーム加入者サーバから加入者データを取得することになる。従前に割り当てられているユーザに対しては、アプリケーションサーバは、加入者データを保持している場合がある。加入者データは、ユーザがＩＰマルチメディアサブシステムから登録抹消されている／ＩＰマルチメディアサブシステムに未登録であるか否かにかかわらず、アプリケーションサーバによって保持されても良い。

本発明のいくつかの実装では、前述のエンティティからリクエストを受信するアプリケーションサーバは、別のアプリケーションサーバにそのリクエストを転送しても良いし、および／またはその別のサーバへのユーザの割当をデータベースに記録させるようにしても良い。

本発明の第２の態様に従えば、ＩＰマルチメディアサブシステムネットワークで使用するための装置が提供される。この装置は、
ＩＰマルチメディアサブシステムのユーザに関連するリクエストを受信する手段と、
ユーザがアプリケーションサーバに割り当てられているか否かを判定するために、データベースに問い合わせる手段と、
ユーザがアプリケーションサーバに割り当てられていないと判定される場合、ユーザをアプリケーションサーバに割り当て、その割り当てられているアプリケーションサーバにリクエストを転送する手段と、
ユーザがアプリケーションサーバに割り当てられていると判定される場合、その割り当てられているアプリケーションサーバにリクエストを転送する手段と
を備える。

この装置は、在圏呼セッション制御機能サーバ内に備えられていても良い。選択的には、この装置は、アプリケーションサーバに常駐していても良いし、または、ＩＰマルチメディアサブシステム内のスタンドアローンノードであっても良い。

本発明の第３の態様に従えば、セッション開始プロトコルリクエストをＩＰマルチメディアサブシステム内のアプリケーションサーバに向ける（行う）方法が提供される。この方法は、
ＩＰマルチメディアサブシステムの在圏呼セッション制御機能において、ＩＰマルチメディアサブシステムのユーザに関連するセッション開始プロトコルリクエストの受信時に、宛先変更（redirection：リダイレクション）サーバとして動作する第１のアプリケーションサーバにそのリクエストを転送する工程と、
第１のアプリケーションサーバで、ユーザがアプリケーションサーバに割り当てられているか否かを判定するためにデータベースに問い合わせる工程と、
ユーザがアプリケーションサーバに割り当てられていないと判定される場合、第１のアプリケーションサーバでユーザを第２のアプリケーションサーバに割り当て、その第２のアプリケーションサーバを識別する在圏呼セッション制御機能にリダイレクションリクエストを返信する工程と、
在圏呼セッション制御機能からのリクエストを第２のアプリケーションサーバに転送する工程と
を備える。

前述のリダイレクションリクエストは、セッション開始プロトコルリクエストに応じて送信される、以下のＳＩＰメッセージを１つ以上備えても良い。

「３００ Ｍｕｌｔｉｐｌｅ Ｃｈｏｉｃｅｓ（複数選択）」
「３０１ Ｍｏｖｅｄ Ｐｅｒｍａｎｅｎｔｌｙ（恒久的に移動）」
「３０２ Ｍｏｖｅｄ Ｔｅｍｐｏｒａｒｉｌｙ（一時的に移動）」
在圏呼セッション制御機能は、第２のアプリケーションサーバのアイデンティティ／位置をキャッシュしてもよく、それにより、その後のリクエストを第２のアプリケーションサーバに直接転送することが可能となる。これは、例えば、「３０１ Ｍｏｖｅｄ Ｐｅｒｍａｎｅｎｔｌｙ」応答または「３０２ Ｍｏｖｅｄ Ｔｅｍｐｏｒａｒｉｌｙ」応答の使用を容易にする。

本発明の第４の態様に従えば、ＩＰマルチメディアサブシステムで使用するアプリケーションサーバが提供される。このサーバは、
在圏呼セッション制御機能からＩＰマルチメディアサブシステムのユーザに関連するリクエストを受信する手段と、
ユーザがアプリケーションサーバに割り当てられているか否かを判定するために、データベースに問い合わせ、割り当てられていない場合、ユーザに第２のアプリケーションサーバを割り当てる手段と、
第２のアプリケーションサーバを識別する在圏呼セッション制御機能にリダイレクションリクエストを返信する手段と
を備える。

上記で参照する３ＧＰＰ技術標準は、初期フィルタ基準（ＩＦＣ：Initial Filter Criteria）の使用を記述し、この初期フィルタ基準は、ＨＳＳに記憶され、加入者登録時または未登録の加入者に終了呼（terminating call）がなされる場合にサービング（serving：在圏）呼／セッション制御機能（Ｓ−ＣＳＣＦ）ノードに送信される。従来は、加入者に関するＩＦＣは、例えば、完全記述ドメイン名（ＦＱＤＮ）のような特定のＳＩＰアプリケーションサーバ（ＡＳ）アドレスを含んでいる。これは、所与のサービスに対するその加入者に割り当てられるＡＳを識別する。［ＩＦＣは、それぞれのＩＭＳサービスに対応する２つ以上のＡＳアドレスを有することが可能である。］ＩＦＣ内のＡＳアドレスがＳＩＰ−ＵＲＬである場合、ＤＮＳは、ＳＩＰ−ＵＲＬをＩＰアドレスに解決するために使用される。Ｓ−ＣＳＣＦは、効率化のために、特定のＳＩＰ−ＡＳアドレスとＩＰアドレスとの間の関連付けをキャッシュしても良い。このキャッシングは、システムのＳ−ＣＳＣＦのＤＮＳクライアントでは一般的であり、加入者単位ではなくノード単位でキャッシュされる。

以下の説明は、一例として、ＳＩＰ−ＡＳ割当の柔軟で動的なアプローチが使用されることを想定する。これには、動的なＳＩＰ−ＡＳ割当がまだ完了していない場合に、ホーム加入者サーバ（ＨＳＳ：Home Subscriber Server）の初期フィルタ基準（ＩＦＣ）に記憶されている特定のＡＳアドレスを、例えば、ＳＩＰ−ＡＳ−ｓｅｒｖｉｃｅ．ｏｐｅｒａｔｏｒ．ｃｏｍ等の汎用ＡＳアイデンティティで置き換えることを含んでいる。１つまたはグループのＡＳを直接識別するのではなく、このアイデンティティは、本明細書では、フロントエンドディストリビュータ（ＦＥ−ＤＩＳＴ：Front End Distributor（フロントエンド分配部））または「ＦＥ−ＤＩＳＴ」と呼ばれる、ＩＭＳ内の新規の機能エンティティを識別する。ＦＥ−ＤＩＳＴは、代わりに「代表ＡＳ」として知られても良い。ＦＥ−ＤＩＳＴは、ＩＳＣインタフェース上でＳ−ＣＳＣＦとＡＳとの間に配置される。加入者の登録時、または未登録加入者への呼終了時、ＩＦＣは、３ＧＰＰ ＴＳ ２３．２２８、３ＧＰＰ ＴＳ ２９．２２８、３ＧＰＰ ＴＳ ２９．２２９に記載の手順に従ってＣｘインタフェースを介してＳ−ＣＳＣＦにダウンロードされる。ＳＩＰ−ＡＳの汎用アイデンティティは、例えば、ＦＥ−ＤＩＳＴ．ｏｐｅｒａｔｏｒ．ｃｏｍ等の特定の名前に解決され、さらにＩＰアドレスに解決される、または汎用アイデンティティはＩＰアドレスに直接解決される。既存のＤＮＳメソッドは、解決プロセスで使用される。［汎用アイデンティティが、ＩＰアドレスにさらに解決される特定の名前に解決される場合には、Ｓ−ＣＳＣＦとＤＮＳとの間で２往復（ラウンドトリップ）が必要とされる。］ＩＦＣは、Ｓ−ＣＳＣＦによって、ＦＥ−ＤＩＳＴ機能へのサードパーティ登録メッセージ、すなわち、ＳＩＰ ＲＥＧＩＳＴＥＲメッセージのプロビジョン（provision）を起動する。Ｓ−ＣＳＣＦは、この段階では、加入者と、選択されたＦＥ−ＤＩＳＴアドレスとの間の関連付けをキャッシュしない。

ＦＥ−ＤＩＳＴ機能は、（要求される）サービスを提供するすべてのＳＩＰ−ＡＳ毎に常駐する機能エンティティであっても良いし、スタンドアローンノードとして配置されても良い。サービスがネットワークに配備され、かつインストールされる場合、すなわち、あるＡＳにスタンドアローンＦＥ−ＤＩＳＴノードと共存するＦＥ−ＤＩＳＴ機能エンティティが配備され、かつインストールされる場合、これら２つのアプローチを組み合わせることはもちろん可能である。以下で参照され、提案を説明するために使用される図では、ＦＥ−ＤＩＳＴとＡＳ（この上にアプリケーションロジックが常駐する）とを別々の機能エンティティとして示している。

図３は、加入者端末へのサービスのプロビジョンを容易にする、ＩＰマルチメディアサブシステム（ＩＭＳ）内の機能エンティティを概略的に示している。図３は、一例として、フロントエンド分配エンティティ（ＦＥ₁〜ＦＥ_n）によって実現されるＩＭＳアプリケーションサーバ（ＡＳ₁〜ＡＳ_n）への加入者の動的割当に関連する手順のステップも示している。本明細書では、アプリケーションサーバ割当は登録時に発生すると想定するが、これは、他のときに起こっても良い。

１ａ 加入者端末が、ＩＭＳネットワークにＳＩＰ ＲＥＧＩＳＴＥＲメッセージを送信することによって登録（ＲＥＧＩＳＴＲＡＴＩＯＮ）プロセスを開始し、３ＧＰＰ規定の手順に従ってＳ−ＣＳＣＦの中の１つに割り当てられる。

１ｂ 登録プロセス中、加入者に関するサービスプロファイルが、ＨＳＳからダウンロードされる。このサービスプロファイルは、ＩＦＣを含んでいる。

２ａ 登録プロセス完了後、Ｓ−ＣＳＣＦは、ＩＦＣで識別されるアプリケーションサーバ名にサードパーティ登録を送信すべきであることを理解する。アプリケーションサーバ名は、汎用名である。Ｓ−ＣＳＣＦは、ＤＮＳサーバからＩＰアドレスをリクエストする。ＤＮＳサーバは、１つまたはいくつかの利用可能なＦＥ−ＤＩＳＴのアドレスを返信する。ここで、Ｓ−ＣＳＣＦは、そのアドレスをＡＳアドレスと解釈し、Ｓ−ＣＳＣＦの機能への変更は必要とされないことに注意されたい。

２ｂ Ｓ−ＣＳＣＦは、ＲＥＧＩＳＴＥＲメッセージを転送すべきアドレスとして、返信されるＩＰアドレスの中の１つを選択する。

２ｃ サードパーティＲＥＧＩＳＴＥＲメッセージは、選択されているＦＥ−ＤＩＳＴに送信される。

２ｄ ＦＥ−ＤＩＳＴは、Ｓｈインタフェースを通じてＨＳＳに記憶されている中央データベースに問い合わせることによって、加入者が既にＡＳに割り当てられているかを、チェックする。割り当てられている場合、ＲＥＧＩＳＴＥメッセージは、割り当てられているＡＳに転送される。参照（ルックアップ）動作が、加入者はまだＡＳに割り当てられていないことを示す場合、ＦＥ−ＤＩＳＴは、ＡＳを選択し、選択したＡＳにＲＥＧＩＳＴＥＲメッセージを送信する。

３ サードパーティ登録の受信時、ＡＳは、以下のタスクを実行する。

自装置のアドレスと加入者アイデンティティとのマッピングをＨＳＳに記憶する。ＡＳが記憶するアドレスは、実際には、様々なインタフェースに対する一連の様々なアドレスである。例えば、ＳＩＰメッセージ、ＨＴＴＰトラフィック等の受信に対して異なるアドレスが存在しても良い。

中央記憶位置（例えば、ＨＳＳまたは他の中央リポジトリ）からデータを取得する。ＡＳは、中央記憶位置に登録（加入）することで、加入者データの変更が通知されることになる。

短期間では、ＳＩＰ−ＡＳは、トランスペアレントデータ（Ｓｈインタフェースを通じて：トランスペアレントデータは、ＨＳＳによっては理解されない）を使用して、ＨＳＳにそのアドレスと加入者アイデンティティとのマッピングを記憶しても良い。長期間では、マッピングは、ＨＳＳの非トランスペアレントデータに追加されても良い。

１つの記憶位置、すなわち、ＨＳＳにおいて、ステップ２ｂで参照されるデータベースを記憶するのではなく、複数のコピーをネットワーク内の様々な位置に記憶されても良いことは明らかであろう。例えば、各ＦＥ−ＤＩＳＴは、自装置のデータベースのコピーを記憶しても良い。

図３に示されるプロセスの完了時、ＳＩＰ−ＡＳは、加入者に割り当てられていて、また、ＳＩＰ−ＡＳは、要求される加入者データのコピーを取得して、加入者にサービスを提供する準備を行う。

ＩＭＳに対する加入者の登録抹消時、加入者は、ＳＩＰ−ＡＳに割り当てられたままにすることができ、ＦＥ−ＤＩＳＴ／ＡＳ／ＨＳＳによって維持される加入者データは消去される必要はない。このことは、加入者／ＡＳ割当手順をＩＭＳ／ＳＩＰ登録手順から明確に分離することを可能にし、加入者データ取得頻度は、割当手順がＳＩＰ／ＩＭＳ登録手順に結合される場合に比べて少なくなるという利点を提供する。

図４を参照して、既に登録されている加入者に関する発信および終了ＩＭＳ「呼」処理手順を、図の番号のプロセスステップを参照して説明する。

１ａ ユーザに関連するＳＩＰリクエスト（例えば、ＳＩＰ ＩＮＶＩＴＥ）が、Ｓ−ＣＳＣＦで受信される。

２ａ Ｓ−ＣＳＣＦは、最初のＳＩＰリクエストを解析し、Ｃｘインタフェースを通じてＨＳＳから受信されるＳＩＰ−ＡＳ名に基づき、ＤＮＳサーバからＩＰアドレスをリクエストする。ＤＮＳサーバは、利用可能なＦＥ−ＤＩＳＴの１つまたはいくつかのアドレスを返信する。ここで、Ｓ−ＣＳＣＦは、アドレスをＡＳアドレスとして解釈し、Ｓ−ＣＳＣＦの機能は変更されないことに注意されたい。

２ｂ 必要な場合、Ｓ−ＣＳＣＦは、ＦＥ−ＤＩＳＴを指示することになる、返信されるアドレスの１つを選択する。

２ｃ 最初のＳＩＰメッセージは、提供されたまたは選択されたＦＥ−ＤＩＳＴアドレスに送信される。

２ｄ 受信するＦＥ−ＤＩＳＴは、トランスペアレントＳｈを通じてＨＳＳを参照することによって（または、自装置にデータベースのコピーが備えられている場合はそのコピーを検査することによって）、加入者に割り当てられているＡＳを識別する。

３ ＳＩＰリクエストは、ＳＩＰ−ＡＳに送信される。ＳＩＰ−ＡＳは、（以前に実行されている）登録プロセスから加入者に対するデータのコピーを有する。ＳＩＰ−ＡＳは、ＳＩＰリクエストの処理に進む。

図５を参照して、未登録加入者に対する終了ＩＭＳ「呼」処理手順を、図の番号のプロセスステップを参照して説明する。

１ａ Ｓ−ＣＳＣＦは、終了ＳＩＰリクエスト（例えば、ＳＩＰ ＩＮＶＩＴＥ）を受信する。

１ｂ サービスプロファイルが、ＨＳＳからＳ−ＣＳＣＦへダウンロードされる。これは、初期フィルタ基準を含んでいる。

２ａ Ｓ−ＣＳＣＦは、最初のＳＩＰリクエストを解析し、（Ｃｘインタフェースを通じてＨＳＳから受信されるＳＩＰ−ＡＳ名に基づいて）ＤＮＳサーバからＩＰアドレスをリクエストする。ＤＮＳサーバは、利用可能なＦＥ−ＤＩＳＴの１つまたはいくつかのアドレスをＳ−ＣＳＣＦに返信する。

２ｂ 必要な場合、Ｓ−ＣＳＣＦは、初期ＳＩＰメッセージを転送するために、返信されたアドレスの１つを選択する。

２ｃ 最初のＳＩＰメッセージは、選択されたＦＥ−ＤＩＳＴに送信される。

２ｄ ＦＥ−ＤＩＳＴは、トランスペアレントＳｈを通じてＨＳＳの参照を実行することによって、加入者に割り当てられているＡＳを識別する。

３ ＳＩＰリクエストは、ＳＩＰ−ＡＳに送信される。加入者がＩＭＳ登録抹消／登録されていないとしても、加入者は、ＳＩＰ−ＡＳに割り当てられたままであると想定すると、ＳＩＰ−ＡＳは、以前の登録プロセスから加入者に対するデータのコピーを有することになる。ＳＩＰ−ＡＳは、ＳＩＰリクエストの処理に進む。［ＡＳが何かの理由で加入者データを紛失している場合は、加入者データはステップ２ｄで発見されているであろう。新しいＡＳが割り当てられ、選択されたＡＳは、中央記憶位置から加入者データをフェッチしているであろう。］
ここで提案するＳＩＰリクエストを割り当て、ルーティングする手順は、リクエストがＵｔインタフェースを通じてＩＰマルチメディアサブシステムに到着する場合にも適用されても良い。

図６は、ＳＩＰリクエストがＵｔインタフェースを通じて受信され、当該ユーザが既にＡＳに割り当てられている場合を示している。図示の番号のステップは、以下の通りである。

１．リクエストが、Ｕｔインタフェースを通じてＩＭＳ内で受信される。このリクエストは、そのフロントエンドによって代理されるサービスに対して、ＦＥ−ＤＩＳＴで終了される。

２．ＦＥ−ＤＩＳＴは、Ｓｈインタフェースを通じてＨＳＳからＡＳアドレスをリクエストする。

３．明示的なＡＳアドレスが、Ｓｈインタフェースを通じてＦＥ−ＤＩＳＴに返信される。

４．このリクエストは、明示的なアドレスおよび、例えば、サービング（在圏）ＡＳのＸＭＬ文書管理サーバ（ＸＤＭＳ：XML Document Management Server）に転送される。

図７は、ＳＩＰリクエストがＵｔインタフェースを通じて受信され、当該ユーザがまだＡＳに割り当てられていない場合を示している。図示の番号のステップは、以下の通りである。

１．リクエストが、特定のインタフェースを通じて受信される。このリクエストは、そのフロントエンドによって代理されるサービスに対して、ＦＥ−ＤＩＳＴで終了される。

２．ＦＥ−ＤＩＳＴは、Ｓｈインタフェースを通じてＨＳＳからＡＳアドレスをリクエストする。

３．ＡＳは割り当てられていないことを示す指示が返信される。

４．ＦＥ−ＤＩＳＴは、ＡＳを選択する（有効なＡＳの名前を取得するために、他のデータベースを使用してもよい）。

５．このリクエストは、選択されたアドレスおよびＸＭＤＳに転送される。

６．選択されたＡＳは、以下を実行する。

・ＳＩＰ−ＡＳは、加入者に対するサービング（在圏）ＡＳとして自装置を登録することを選択してもよく、その場合は、ＨＳＳにその明示的なアドレスを記憶することになる。（トランザクションが一度だけ起こることになっていて、その後のリクエストが予期されない場合、これは必要とされなくてもよい）。

・中央データ記憶装置（通常は、ＨＳＳ）からアプリケーション専用加入者データを読み取る。

・リクエストを処理する。

図６と図７は、特に、Ｕｔインタフェースに関係しているが、ＦＥ−ＤＩＳＴは、他のインタフェースを通じて受信されるリクエストを処理しても良いことは明らかであろう。他のインタフェースはまだ標準化されていないが、一例は、アプリケーションサーバがＩＳＣもＯＳＡも実装し、かつＰａｒｌａｙプロトコルがＯＳＡで使用される場合であっても良い。

ユーザのアプリケーションサーバへの動的割当を容易にする代替のメカニズムは、ユーザをサービスに関係するアプリケーションサーバに割り当て、ＳＩＰリクエストをそのアプリケーションサーバにリダイレクト（宛先変更）させることができるＦＥ−ＤＩＳＴの実装を含んでいる。この新規のＦＥ−ＤＩＳＴは、リダイレクトモードで動作するアプリケーションサーバとして本質的に動作し、ユーザの負荷を分散するすべてのＡＳの名前またはアドレスを事前に知らなければならない。そのため、ＦＥ−ＤＩＳＴは、ユーザが動的に割り当てられてもよいＡＳのアドレスを有するテーブルを含まなければならない。ＡＳの名前またはアドレスのリストは、２つの異なる方法でＦＥ−ＤＩＳＴにセットされても良い。

１．手動で構成される（メインテナンスツール、コマンドラインインタフェース、または他の手段によって）。

２．ＡＳ自体による自動化。このアプローチでは、ＡＳがオンラインになると、ＦｒｏｍおよびＴｏヘッダーにＡＳのＳＩＰ ＵＲＩならびにＣｏｎｔａｃｔヘッダーにＡＳの名前またはアドレスを有するＳＩＰ ＲＥＧＩＳＴＥＲメッセージをＦＥ−ＤＩＳＴに送信する。図８は、この自動構成（コンフィグレーション：configuration）プロセスに関連するＳＩＰシグナリングを示している。

ここで、所与の任意のネットワークにおいても、ユーザが動的に割り当てられてもよいＡＳがあっても良いし、また、この能力を持たず、それゆえ、ユーザは静的に割り当てられなければならないＡＳがあっても良いことに注意されたい。

ユーザのＡＳへの割当は、ユーザがＩＭＳネットワークにアクセスする場合、例えば、ユーザがネットワークに登録する場合に実行される。これが行われる場合、Ｓ−ＣＳＣＦは、ＳＩＰ ＲＥＧＩＳＴＥＲメッセージを受信する。ＨＳＳからダウンロードされるトリガ情報（ＩＦＣ）に基づいて、Ｓ−ＣＳＣＦは、ＲＥＧＩＳＴＥＲメッセージをＦＥ−ＤＩＳＴに転送する。この手順は周知であり、ＩＭＳ規格で定義されている。ここで、ＦＥ−ＤＩＳＴは、１つのＡＳを登録中のユーザに割り当てる必要がある。それは、前もって構成（設定）されているＡＳのリストをチェックし、ある基準に基づいて、ＡＳを選択し、Ｓ−ＣＳＣＦへの「３００ Ｍｕｌｔｉｐｌｅ Ｃｈｏｉｃｅｓ」応答の中のコンタクト（Ｃｏｎｔａｃｔ）ヘッダーとして、その名前またはアドレスを返信する。ＦＥ−ＤＩＳＴは、選択しているＡＳのアイデンティティおよびアドレスの少なくとも一方に注意して、これをＲＥＧＳＩＴＥＲ（登録）リクエストで受信されているユーザアイデンティティと一緒に、ユーザ識別子−ＡＳマッピングテーブルに記憶する。ＡＳは、例えば、現在のその占有レベル、その使用レベル（ＦＥ−ＤＩＳＴがＡＳから負荷レポートを受信する場合）、その動作状況（ＦＥ−ＤＩＳＴがＡＳの作業状況についての情報を取得できる場合）に基づいて選択されても良い。

Ｓ−ＣＳＣＦは、ＦＥ−ＤＩＳＴ応答の受信時、ＦＥ−ＤＩＳＴによって指示されるように、ＡＳにＲＥＧＳＩＴＥＲ（登録）リクエストを転送する（サードパーティ登録として少し修正されている）。いずれは、Ｓ−ＣＳＣＦは、このＡＳまたは別の（他のリダイレクトが行われる場合）ＡＳからの「２００ ＯＫ」応答を受信し、ＲＥＧＳＩＴＥＲ（登録）リクエストのパスの前のホップに戻して、その応答を転送する（通常いずれかのＩ−ＣＳＣＦ）ことになる。

ここで、登録されるユーザに関連するその後のＳＩＰリクエストに対して、Ｓ−ＣＳＣＦは、以前にＲＥＧＳＩＴＥＲ（登録）リクエストで行ったように、それをそのトリガ情報とマッチさせた後に、各新規のリクエストをＦＥ−ＤＩＳＴに転送する。しかしながら、これは、各新ＳＩＰリクエストはＦＥ−ＤＩＳＴを介して解決されなければならず、ネットワーク全体の応答時間を悪くし、更に、Ｓ−ＣＳＣＦおよびＦＥ−ＤＩＳＴ機能の負荷を増加させるという問題をもたらす。

場合によっては、アプローチの改良としては、ＲＥＧＩＳＴＥＲで識別されるユーザがＡＳに既に割り当てられていることを検出する場合、ＦＥ−ＤＩＳＴが「３０１ Ｍｏｖｅｄ Ｐｅｒｍａｎｅｎｔｌｙ」応答でＲＥＧＩＳＴＥＲに応答することである。これは、Ｓ−ＣＳＣＦが応答に含まれるＡＳアドレスをキャッシュすることを可能にして、それ以降の関連するＳＩＰリクエストはＦＥ−ＤＩＳＴに送信されないようにする。

別のアプローチは、ＦＥ−ＤＩＳＴが所定の時間を有する失効（Ｅｘｐｉｒｅｓ）ヘッダーを含む「３０２ Ｍｏｖｅｄ Ｔｅｍｐｏｒａｒｉｌｙ」応答でＲＥＧＩＳＴＥＲに応答する。これは、Ｓ−ＣＳＣＦがその所定の時間に対してＡＳアドレスをキャッシュすることを可能にする。この時間が満了すると、Ｓ−ＣＳＣＦは、ユーザに対するその後のＳＩＰリクエストの受信時にＦＥ−ＤＩＳＴに問い合わせることになる。このアプローチの利点は、ＦＥ−ＤＩＳＴの負荷を減らす一方で、例えば、従前に割り当てられているＡＳが故障する場合に、ユーザの新規の加入者への再割当を依然として可能にすることである。

ＦＥ−ＤＩＳＴによって（「３００ Ｍｕｌｔｉｐｌｅ Ｃｈｏｉｃｅｓ」または「３０２ Ｍｏｖｅｄ Ｔｅｍｐｏｒａｒｉｌｙ」で）報告されるリダイレクション（宛先変更）をＳ−ＣＳＣＦにインストールする簡単な方法の１つは、ＦＥ−ＤＩＳＴへのリクエストの転送を開始させたトリガのトリガ情報内の宛先ＡＳフィールドを上書きすることである。ここで、「３０２ Ｍｏｖｅｄ Ｔｅｍｐｏｒａｒｉｌｙ」の場合は、Ｓ−ＣＳＣＦはトリガのために古い宛先サーバを維持する必要があり、それによって、３０２応答によって設定されている時間が満了するときに、それを回復できるようにすることに注意されたい。

ＦＥ−ＤＩＳＴは、Ｓ−ＣＳＣＦにリダイレクションを実現する場合、その後、ＨＳＳがユーザに対してＳ−ＣＳＣＦに記憶されているトリガ情報を更新すると、そのユーザに対してＳ−ＣＳＣＦにインストールされている一時的または永久的なリダイレクションは、削除されなければならない。このリダイレクションがトリガ情報を上書きすることによってインストールされる場合、ＨＳＳによって送信されている新規のトリガ情報を記憶する場合、これは、もちろん自動的に行われることになる。

図９は、ＦＥ−ＤＩＳＴがユーザからの初期ＳＩＰリクエストをどのように処理するかを示している。このリクエストは、図示されるように、ＲＥＧＩＳＴＥＲであっても良いし、またＦＥ−ＤＩＳＴが登録済の任意のユーザＩＤ−ＡＳ結合（バインディング）を有さない他のリクエストであっても良い。

図１０は、既に登録されているユーザに対するその後のＳＩＰリクエストが、「３０２ Ｍｏｖｅｄ Ｔｅｍｐｏｒａｒｉｌｙ」応答の使用を想定する、ＦＥ−ＤＩＳＴによってどのように処理されるかを示している。

図１１は、稼働中でないＡＳから別のＡＳへのユーザの移動（リロケーション）を処理する手順を示している。ここで、新規のＡＳによって提供されるサービスが登録を必要とする場合（すなわち、ＲＥＧＩＳＴＥＲ（登録）リクエストは、サービスを使用する前に受信されていなければならない）、提示のアプローチは、新規のＡＳがいくつかの方法で以前から存在する登録情報にアクセスすることができる限りにおいてのみ機能するであろう（例えば、個別のＡＳが故障している場合でさえも、動作し続ける共通の登録データベースをすべてのＡＳが共有する場合）。

様々な変更を、本発明の範囲から逸脱することなく、上記実施形態に行うことが可能であることは当業者には明らかであろう。

ＩＰマルチメディアサブシステムの３Ｇ移動通信システムへの統合の概略図である。 様々なインタフェースと一緒に、アプリケーションサーバおよび在圏呼／状態制御機能を含むＩＰマルチメディアサブシステムのエンティティの概略図である。 ＩＭＳユーザ登録時、ＩＭＳユーザをアプリケーションサーバに割り当てるＦＥ−ＤＩＳＴの使用の概略図である。 ユーザ登録後、発信呼または終了呼を処理するＦＥ−ＤＩＳＴの使用の概略図である。 未登録ユーザへの終了呼を処理するＦＥ−ＤＩＳＴの使用の概略図である。 ＩＭＳ登録ユーザに関して、非ＳＩＰインタフェースを通じて受信した要求を処理するＦＥ−ＤＩＳＴの使用の概略図である。 未登録ユーザに対して、非ＳＩＰインタフェースを通じて受信されるリクエストを処理するＦＥ−ＤＩＳＴの使用の概略図である。 代表アプリケーションサーバのアプリケーションサーバデータベース構築に関連するシグナリングの図である。 アプリケーションサーバを選択し、選択したサーバへのメッセージリダイレクションを行う代表アプリケーションサーバの使用に関連する、シグナリングおよびプロセスステップの図である。 既に割り当てられているアプリケーションサーバがアクティブである、受信されるているＩＮＶＩＴＥの場合に、代表アプリケーションサーバの使用に関連するシグナリングおよびプロセスステップの図である。 既に割り当てられているたアプリケーションサーバがインアクティブである、受信されているＩＮＶＩＴＥの場合に、代表アプリケーションサーバの使用に関連するシグナリングおよびプロセスステップの図である。

Claims (21)

1. ＩＰマルチメディアサブシステム内のアプリケーションサーバにリクエストを行う方法であって、
   前記ＩＰマルチメディアサブシステムのエンティティにおいて、ＩＰマルチメディアサブシステムのユーザに関連するリクエストの受信時に、前記ユーザがアプリケーションサーバに割り当てられているか否かを判定するためにデータベースに問い合わせる工程と、
   前記ユーザがアプリケーションサーバに割り当てられていないと判定される場合、前記エンティティにおいて前記ユーザをアプリケーションサーバに割り当て、前記エンティティからの前記リクエストをその割り当てられたアプリケーションサーバに転送し、前記ユーザの前記アプリケーションサーバへの割当が前記データベースに記録されるように、前記アプリケーションサーバまたは前記エンティティからのリクエストを前記データベースに送信する工程と、
   前記ユーザがアプリケーションサーバに割り当てられていると判定される場合、前記エンティティからの前記リクエストを前記割り当てられたアプリケーションサーバに転送する工程と
   を備えることを特徴とする方法。
2. 前記ユーザがアプリケーションサーバに割り当てられているか否かを判定するためにデータベースに問い合わせる工程は、セッション開始プロトコルに従って実行される
   ことを特徴とする請求項１に記載の方法。
3. 前記ＩＰルチメディアサブシステムのエンティティは、在圏呼セッション制御機能である
   ことを特徴とする請求項１または２に記載の方法。
4. 前記ＩＰルチメディアサブシステムのエンティティは、ネットワークの残りの部分に対して単一の論理的アプリケーションサーバとして動作するフロントエンドディストリビュータである
   ことを特徴とする請求項１または２に記載の方法。
5. 在圏呼セッション制御機能での前記リクエストの受信時に、前記リクエストが送信されるべき前記フロントエンドディストリビュータを識別するために、在圏呼セッション制御機能からホーム加入者サーバへ問い合わせを送信し、前記フロントエンドディストリビュータで、該フロントエンドディストリビュータの識別情報を受信する
   ことを特徴とする請求項４に記載の方法。
6. 前記リクエストは、セッション開始プロトコルリクエストである
   ことを特徴とする請求項１乃至５のいずれか１項に記載の方法。
7. 前記リクエストは、Ｕｔインタフェースを通じて前記エンティティで受信される
   ことを特徴とする請求項４または５に記載の方法。
8. 前記データベースは、ホーム加入者サーバに備えられている
   ことを特徴とする請求項１乃至７のいずれか１項に記載の方法。
9. 前記ユーザの前記アプリケーションサーバへの割当は、トランスペアレント及び非トランスペアレントＩＳＣインタフェースの少なくとも一方を使用して前記ホーム加入者サーバに記憶される
   ことを特徴とする請求項８に記載の方法。
10. 請求項４に従属する場合に、前記データベースは、前記フロントエンドディストリビュータに備えられている
    ことを特徴とする請求項４乃至９のいずれか１項に記載の方法。
11. 請求項４に従属する場合、前記データベースは、一元的に配置され、
    前記フロントエンドディストリビュータは、受信したアプリケーションサーバ割当データをキャッシュし、そのデータの変更を登録する
    ことを特徴とする請求項４乃至９のいずれか１項に記載の方法。
12. 前記アプリケーションサーバから前記データベースへ送信される前記リクエストは、前記アプリケーションサーバの１つ以上のアドレスを含んでいる
    ことを特徴とする請求項１乃至１１のいずれか１項に記載の方法。
13. 前記ユーザが従前にアプリケーションサーバに割当られていない場合、前記アプリケーションサーバは、前記ホーム加入者サーバから加入者データを取得する
    ことを特徴とする請求項１乃至１２のいずれか１項に記載の方法。
14. 従前に割当られているユーザに対して、前記アプリケーションサーバは、前記ユーザが、前記ＩＰマルチメディアサブシステムから登録抹消されている／前記ＩＰマルチメディアサブシステムに未登録であるか否かにかかわらず、前記加入者データを保持する
    ことを特徴とする請求項１３に記載の方法。
15. ＩＰマルチメディアサブシステムネットワークで使用する装置であって、
    ＩＰマルチメディアサブシステムのユーザに関連するリクエストを受信する手段と、
    前記ユーザがアプリケーションサーバに割り当てられているか否かを判定するために、データベースに問い合わせる手段と、
    前記ユーザがアプリケーションサーバに割り当てられていないと判定される場合、前記ユーザをアプリケーションサーバに割り当て、その割り当てられたアプリケーションサーバに前記リクエストを転送する手段と、
    前記ユーザがアプリケーションサーバに割り当てられていると判定される場合、前記割り当てられたアプリケーションサーバに前記リクエストを転送する手段と
    を備えることを特徴とする装置。
16. 当該装置は、在圏呼セッション制御機能サーバの一部を構成している
    ことを特徴とする請求項１５に記載の装置。
17. 当該装置は、アプリケーションサーバに常駐している、あるいは前記ＩＰマルチメディアサブシステム内のスタンドアローンノードである
    ことを特徴とする請求項１５に記載の装置。
18. セッション開始プロトコルリクエストをＩＰマルチメディアサブシステム内のアプリケーションサーバに行う方法であって、
    前記ＩＰマルチメディアサブシステムの在圏呼セッション制御機能において、ＩＰマルチメディアサブシステムのユーザに関連するセッション開始プロトコルリクエストの受信時、リダイレクションサーバとして動作する第１のアプリケーションサーバに前記セッション開始プロトコルリクエストを転送する工程と、
    前記第１のアプリケーションサーバで、前記ユーザがアプリケーションサーバに割り当てられているか否かを判定するためにデータベースに問い合わせる工程と、
    前記ユーザがアプリケーションサーバに割り当てられていないと判定される場合、前記第１のアプリケーションサーバで前記ユーザを第２のアプリケーションサーバに割り当て、前記第２のアプリケーションサーバを識別する在圏呼セッション制御機能にリダイレクションリクエストを返信する工程と、
    前記在圏呼セッション制御機能からの前記セッション開始プロトコルリクエストを前記第２のアプリケーションサーバに転送する工程と
    を備えることを特徴とする方法。
19. 前記リダイレクションリクエストは、前記セッション開始プロトコルリクエストに応じて送信される、
    「３００ Ｍｕｌｔｉｐｌｅ Ｃｈｏｉｃｅｓ（複数選択）」
    「３０１ Ｍｏｖｅｄ Ｐｅｒｍａｎｅｎｔｌｙ（恒久的に移動）」
    「３０２ Ｍｏｖｅｄ Ｔｅｍｐｏｒａｒｉｌｙ（一時的に移動）」
    のＳＩＰメッセージを１つ以上備える
    ことを特徴とする請求項１８に記載の方法。
20. 在圏呼セッション制御機能は、前記第２のアプリケーションサーバのアイデンティティ／位置をキャッシュし、それにより、その後のリクエストが前記第２のアプリケーションサーバに直接転送できるようにする
    ことを特徴とする請求項１８または１９に記載の方法。
21. ＩＰマルチメディアサブシステムで使用するアプリケーションサーバであって、
    在圏呼セッション制御機能から、ＩＰマルチメディアサブシステムのユーザに関連するリクエストを受信する手段と、
    前記ユーザがアプリケーションサーバに割り当てられているか否かを判定するために、データベースに問い合わせ、割り当てられていない場合、前記ユーザに第２のアプリケーションサーバを割り当てる手段と、
    前記第２のアプリケーションサーバを識別する在圏呼セッション制御機能にリダイレクションリクエストを返信する手段と
    を備えることを特徴とするアプリケーションサーバ。