JP2009522965A - Ｉｍｓを含むネットワーク環境においてドメインを選択するシステムおよび方法 - Google Patents

Abstract

一実施形態では、回路交換（ＣＳ）ネットワークおよびインターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）ネットワークを含む、ネットワーク環境内での動作のためのドメイン選択方法が開示される。適切なネットワークドメインはポリシー基準のうちの少なくとも一部に基づく加入者に向けられる入力コールに関して選択される。本発明はネットワークノードを提供し、該ネットワークノードは、インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）ネットワーク内で動作可能なネットワークノードであって、該ネットワークノードは、該ネットワークノードによって提供されるように動作可能である、加入者に関するポリシー基準を保持するための手段と、該加入者に向けられた入力コールのルーティングに関して適切なドメインを選択するための手段であって、該選択することは該ポリシー基準の少なくとも一部に基づく。

Description

本特許開示は、概して、通信ネットワーク内でのコールのルーティングに関する。より具体的には、本特許開示は、限定されないが、回路交換（ＣＳ）ネットワークおよびＩＰマルチメディアサブシステム（ＩＭＳ）ネットワークを含む、ネットワーク環境内で動作可能なドメイン選択システムおよび方法に関し、ここでは、入力コール（ｉｎｃｏｍｉｎｇ ｃａｌｌ）が、適切なドメイン（例、ＣＳドメインまたはＩＭＳドメイン）にルーティングされる。

移動ボイスオーバＩＰ（ＶｏＩＰ）ハンドオーバとは、ＩＰベースのネットワーク（例、無線ＬＡＮ（ＷＬＡＮ）またはＷｉ−ＭＡＸネットワーク、第三世代パートナーシッププロジェクト（３ＧＰＰ）パケット交換（ＰＳ）ネットワーク、長期発展（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ：ＬＴＥ）ネットワークなど）と、回路交換セルラネットワークとの間をユーザが移動するときに、音声コールを連続させる処理である。このようなハンドオーバを達成するために、現行の第三世代パートナーシッププロジェクト（３ＧＰＰ）規格では、ＩＰマルチメディアサブシステム（ＩＭＳ）と称される新たなＩＰベースのネットワークアーキテクチャ内に配置された、コール連続性制御機能（ｃａｌｌ ｃｏｎｔｉｎｕｉｔｙ ｃｏｎｔｒｏｌ ｆｕｎｃｔｉｏｎ：ＣＣＣＦ）要素を規定している。さらに、ネットワークドメイン選択（ＮｅＤＳ）と称される別のエンティティは、デュアルドメイン能力（すなわち、ＣＳドメインおよびＩＭＳドメイン）を有するユーザ機器（ＵＥ）デバイスに向けられた入力コールに関する適切なドメイン選択を容易にするために、ＣＣＣＦ要素と相互運用する３ＧＰＰ規格によって規定される。しかし、現在のＮｅＤＳ機能の開発においては、複数の欠点がなおも存在することが知られている。

本特許開示の実施形態は、添付図面とともに用いられる以下の詳細な説明を参照することによって、より完全に理解することができる。

本特許開示は、広く、ＣＳネットワークおよびＩＭＳネットワークを含むネットワーク環境内での動作のためのドメイン選択アーキテクチャに関する。加入者に関するポリシー基準情報はネットワークノードに関連して保持される。適切なネットワークドメインがポリシー基準のうちの少なくとも一部に基づいて加入者に向けられる入力コールまたはセッションに関して選択される。以下に説明する本開示および特許請求の範囲のために、「コール」という用語は、「コール」および「セッション」を包含するように解釈されるべきである。

一側面において、ドメイン選択スキームを用いるＩＭＳネットワークノードが開示される。請求される実施形態は、ネットワークノードによって提供されるように動作可能な加入者に関するポリシー基準を保持するための手段と、該加入者に向けられる入力コールのルーティングに対して適切なネットワークノードを選択するための手段とを備え、該選択することはポリシー基準のうちの少なくとも一部に基づく。

さらに別の側面において、ＣＳネットワークおよびＩＭＳネットワークを含むネットワーク環境において動作可能なドメイン選択方法が本明細書において開示される。請求される実施形態は、ネットワークノードによって提供されるように動作可能な加入者に関するポリシー基準を保持することと、該加入者に向けられる入力コールのルーティングに対して適切なネットワークドメインを選択することとを含み、該選択することはポリシー基準の少なくとも一部に基づく。

本特許開示のシステムおよび方法を、実施形態をどのように最良に実行および使用することができるのかといった種々の実施例を参照して以下に説明する。説明および複数の図面を通じて、同じ参照番号は同じ要素または対応する要素を示し、種々の要素は必ずしも原寸に比例して描かれているわけではない。以下、図面を参照する。図１を参照すると、例示的なネットワーク環境１００が示され、本特許開示の一実施形態は、適切なドメイン（例、ＣＳドメインまたはＩＭＳドメイン）への入力コールに関するコールのルーティングを達成するために実行され得る。示されるように、ネットワーク環境１００は、複数のＵＥデバイス１０２−１〜１０２−Ｎに対して利用可能な多数のアクセス技術で構成されたアクセス空間１０４を含む。本開示では、ＵＥデバイスは、あらゆる連結された、または連結されていない通信デバイスとすることができ、また、好適な無線モデムまたはモバイル通信デバイス（例えば、メッセージの送受信、ウェブ閲覧などができるセルラ電話またはデータ使用可能ハンドヘルドデバイス）を備えたあらゆるパーソナルコンピュータ（例、デスクトップ、ラップトップ、パームトップ、またはハンドヘルドコンピューティングデバイス）を含むか、または、Ｅメール、ビデオメール、インターネットアクセス、企業データアクセス、メッセージング、カレンダリングおよびスケジューリング、情報管理などが可能なあらゆる拡張ＰＤＡデバイスまたは統合型情報機器を含むことができる。ＵＥデバイスは、回路交換（ＣＳ）通信、およびパケット交換（ＰＳ）通信の両方に接続することができ、また、連続性を損なわずに、ある通信モードから別の通信モードに遷移することができるという点で、複数のモードで動作できることが好ましい。

アクセス空間１０４は、ＣＳおよびＰＳネットワーク両方で構成され得、無線技術、有線技術、ブロードバンドアクセス技術などを伴う場合もある。例えば、参照番号１０６は、モバイル通信用グローバルシステム（Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｖａｔｉｏｎｓ：ＧＳＭ）ネットワークおよび符号分割多重アクセス（Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ：ＣＤＭＡ）ネットワークのような無線技術を指すが、これらの教示は、あらゆる第三世代パートナーシッププロジェクト（３ＧＰＰ）に準拠したセルラ電話ネットワーク（例、３ＧＰＰまたは３ＧＰＰ２）にも拡大される場合があると想定される。参照番号１０８は、無線ローカルエリアネットワーク（すなわちＷＬＡＮ）、Ｗｉ−ＭＡＸネットワーク、およびＤＳＬ、ケーブルブロードバンドなどの固定ネットワークを含む、ブロードバンドアクセスネットワークを指す。また、従来の有線ＰＳＴＮインフラストラクチャ１１０も、アクセス空間１０４の一部として例示される。

ＩＰマルチメディアサブシステム（ＩＭＳ）コアネットワーク１１２は、あらゆるＣＳベースのネットワークを含む、上述した様々なアクセスネットワークに接続される。周知のように、３ＧＰＰによって規定されるＩＭＳ規格は、サービスプロバイダが、あらゆるネットワークタイプ上において、ＩＰを経て配信することができる様々なサービスを管理することができるようにデザインされており、ＩＰを使用して、ベアラトラフィックおよびセッション開始プロトコル（ＳＩＰ）ベースのシグナリングトラフィックの両方をトランスポートする。概して、ＩＭＳは、アプリケーション（すなわちサービス）およびネットワーク（すなわちアクセス）を管理するためのフレームワークであり、マルチメディアサービスを提供することができる。ＩＭＳは、加入者が使用するサービスを配信するネットワーク要素（例、音声コール連続性（ＶＣＣ）、プッシュツートーク（ＰＴＴ）など）として、「アプリケーションサーバ」を規定する。ＩＭＳは、共通の制御構成要素を規定することによってアプリケーションを管理し、それぞれのアプリケーションサーバ（ＡＳ）は、例えば、加入者のプロフィール、ＩＭＳのモビリティ、ネットワークアクセス、認証、サービス許可、課金および請求、オペレータ間機能、およびレガシー（ｌｅｇａｃｙ）電話ネットワークとの相互動作を有することが必要とされる。

ＩＭＳは、主にＧＳＭネットワークのアドレス指定を行う３ＧＰＰ規格本体によって規定されるが、一方で、別のグループである３ＧＰＰ２は、マルチメディアドメイン（ＭＭＤ）と称される、極めて類似したアーキテクチャを規定することに関与するものと理解されたい。ＭＭＤは、基本的にはＣＤＭＡネットワークのためのＩＭＳであり、ＭＭＤおよびＩＭＳは、概略的には同じであるため、「ＩＭＳ」という用語を、本特許開示では、適用可能である場合に、ＩＭＳおよびＭＤＤの両方を集合的に称するように用いる場合がある。

続けて図１を参照すると、参照番号１１４−１〜１１４−Ｎは、上述したように、様々なＩＭＳサービス（例、ＶＣＣ、ＰＴＴなど）をサポートするように動作可能である複数のＡＳノードを指す。さらに、コールの連続性および適切なドメイン選択を達成するために、別のネットワークノードまたはＡＳ１２０を、コール連続性制御機能（ＣＣＣＦ）１１６およびネットワークドメイン選択（ＮｅＤＳ）１１８と称される機能を実装する、加入者のホームＩＭＳコアネットワーク１１２の一部として提供することができる。本質的には、ＡＳ１２０のＣＣＣＦ部分１１６は、ホームＩＭＳネットワーク内に存在し、全てのコールセッションおよび関連するモバイルボイスオーバーＩＰ（ＶｏＩＰ）ベアラトラフィックを追跡し、ＣＳドメインとＩＭＳドメインとの間のコールハンドオーバ／ルーティングを含む、新たなＩＭＳアプリケーションサーバ要素として動作可能である。以下に詳述するように、ＡＳ１１６のＮｅＤＳ部分１１８は、とりわけ、ＩＭＳネットワークとＣＳネットワーク（例、ＧＳＭまたはＣＤＭＡ）との間の登録／登録取り消しの管理、および入力コールのルーティングのためのドメイン選択を実行する役割を果たす。潜在的に別個の機能ではあるが、図１に示されるように、ＣＣＣＦ機能およびＮｅＤＳ機能の両方を、単一のＩＭＳ互換のネットワーク要素１２０に組み込むことが可能である。加えて、適切なデータベース構造（例、ＤＢ１２２）およびタイマ機構（例、タイマ１２４）は、ＡＳ１２０に関連して提供することができるが、この目的は、単一のネットワーク要素に配信（例えば、２つ以上の構成要素の中で）するか、または組み込むことができる、ＮｅＤＳ機能に関して以下に詳述する。実装における柔軟性が高いことから、当業者は、以下に使用される「ＮｅＤＳ要素」という用語が、全般的に、ドメイン選択機能を有する「ネットワークノード」と同義に扱われ、単一のプラットホームまたは複数のプラットホームで構成することができるものと認識されたい。例えば、ネットワークノードは、ドメイン転送機能（ＤＴＦ）（機能エンティティＦＥ−Ａとも称する）、ＣＳ適合機能（ＣＳＡＦ）（ＦＥ−Ｂとも称される）、ＣＡＭＥＬサービス（ＦＥ−Ｃとも称される）、およびドメイン選択機能（ＤＳＦ）（ＦＥ−Ｄとも称される）のような機能を含むことができ、これらは、３ＧＰＰ ＴＳ ２３．２０６ドキュメントに規定されている。

図２は、本特許出願のネットワーク要素２００の一実施形態を示す図である。当業者は、必要要件ではないが、図１を参照して上記したように、実施形態２００は、ＣＣＣＦ要素とともに動作することができるものと理解されたい。さらに、上記したように、ネットワーク要素／ノードの機能は、ＴＳ２３．２０６に規定された複数の異なる機能の中で配信することができる。本願明細書に示されるように、ＮｅＤＳ要素またはノード２００は、コールがＩＭＳ発信なのか、ＣＳ発信なのか、ＵＥデバイスのステータスなどに基づいて、また、あらゆる適用可能なユーザベース、およびオペレータベースのポリシーおよびプレファレンスに基づいて、入力コールを終了する役割を果たすドメインルーティング機能２０２を含む。したがって、適切なソフトウェア／ファームウェア構造、すなわちロジック２０４は、ＵＥデバイスがどの１つのまたは複数のドメイン内にあるのかに関する情報を保持するための、ＮｅＤＳ要素２００の一部として提供される。ＵＥデバイスがその中にあるそれぞれのドメインに関しては、明確な遷移を有する複数の「状態」を含むものとして処理することができる、ＵＥデバイスのステータス情報をモニタするために、１つ以上の状態エンジンが提供される。状態遷移は、ルール、ポリシー、プレファレンス、およびＵＥデバイスによって提供される更新された情報に基づいて達成できることが好ましい。それに応じて、状態遷移モデルは、入力コールに関する適切なドメイン選択を容易にするために、ＵＥデバイスの正確な表示をドメインルーティング機能２０２に提供するように動作可能である。実例として、参照番号２０６−１〜２０６−Ｎは、ＵＥデバイスのドメイン情報に基づいて選択的に適用することができる、ＮｅＤＳ要素２００によって保持された複数のＵＥ状態遷移モデルまたはエンジンを指す。

本特許開示の一実施形態によれば、ＮｅＤＳ能力２００を有するＩＭＳネットワークノードは、種々のユーザベースの、および／またはオペレータベースのポリシーおよびプレファレンスをローカルに保持するために、適切な内部データベース２０８および２１０を備えることができ、これらは定期的に更新するか、または適用可能な無線（ｏｖｅｒ−ｔｈｅ−ａｉｒ：ＯＴＡ）機構を経て更新することができる。別様には、または加えて、どのドメインおよび状態にＵＥデバイスがあるのかに関する決定に基づいて、ドメインルーティング機能２０２が、適用可能なルール、ポリシー、およびプレファレンスを問い合わせることができるように、外部データベース２１２は、ＮｅＤＳ要素２００とインターフェースすることができる。それに応じて、全体的なＮｅＤＳ機能は、コールの終了に対して１つ以上のフィルタを適用するために、適切なロジック構造／ソフトウェア／ファームウェアモジュールを含むことが好ましい場合があり、これらのフィルタは、ＵＥデバイスの現在のドメイン、デバイスの状態、プレゼンス情報、適切なポリシーまたはプレファレンス、または他の基準（集合的に「ステータス情報」）に基づいて、複数の決定を実行するように動作可能である。より高いレベルの抽象概念では、したがって、全体的なサービスロジックは、（ａ）ＩＭＳサービス（例、ＶＣＣ）が呼び出されるべきであるかどうかを決定することと、（ｂ）入力コールを適切なドメインにルーティングすることとを実行するように動作可能である。機能の第１の部分は、ＵＥデバイスがＩＭＳサービスに対応しているかどうか、ＵＥデバイスの位置、およびＵＥデバイスが登録または接続されたネットワークに基づいて、調整することができる。同様に、ＮｅＤＳ機能の第２の部分は、ＵＥがどのドメインに登録されたか、登録されたドメインに対するＵＥの状態、オペレータベースのプレファレンス、およびユーザベースのプレファレンスに基づいて、調整することができる。本開示の以下のセクションでは、上述したＮｅＤＳ機能の種々の構成要素を達成するようにデザインされた、全体的なＮｅＤＳの一実施形態を示す。

図３を参照すると、入力コールをルーティングするための、本特許開示の一実施形態のフロー図が示されている。上述のように、最初に、サービングＮｅＤＳノードにおいて、ＩＭＳベースのサービスを呼び出すべきかどうか、および／または入力コールが向けられたＵＥデバイスがＩＭＳサービスに対応できるかどうか、の決定が行われる。これらの条件が満たされると、ＮｅＤＳのドメインドメインルーティング機能によって一連の決定を行って、コールのルーティングを容易にすることができる。ＵＥデバイスがどのドメイン内にあるのかに関して決定を行うことができる（ブロック３０２）。別には、そのドメインに対して、ＵＥがどの状態にあるのかを識別する決定を伴う（ブロック３０４）。さらに別には、入力コールに対して、ユーザ／オペレータポリシーおよび／またはプレファレンスの適用性を決定する（ブロック３０６）。入力コールは、次いで、上述の決定に基づいて、適切なドメイン／機能に対するＮｅＤＳネットワークノードによって終了される（ブロック３０８）。

図４は、一実施形態による、ＵＥデバイスと、関連するＮｅＤＳ要素との間の相互作用のモデルに関するフロー図である。図に示されるように、ＵＥデバイスは、ＣＳシグナリングまたはＩＭＳシグナリングのいずれかを使用して、そのＮｅＤＳネットワークノードに最初に登録するように動作可能である（ブロック４０２）。ＵＥデバイスは、続いて、その状態、ドメイン、およびポリシー／プレファレンスを、何らかの定期的な様態で（例えば、適用可能なタイマ機構に基づいて）ＮｅＤＳノードに提供することができる（ブロック４０４）。別様には、または加えて、ＮｅＤＳノードは、好適なプレゼンスベースのインターフェーシングを経て、ＵＥデバイスに関連するプレゼンスエージェントに加入することができ、これによって、ＵＥデバイスの状態、ドメイン、およびポリシー／プレファレンスのあらゆる変更の通知を受信することができる（ブロック４０６）。更新された情報に基づいて、ＮｅＤＳネットワークノードは、ドメイン選択およびコールの終了を達成するために、ＵＥデバイスのための正確な状態／ドメイン／ポリシースペースを保持する（ブロック４０８）。

図５は、一実施形態による、ＮｅＤＳ要素（例、ＮｅＤＳ２００）を備えた複数のインターフェースを示す機能ブロック図である。図に示されるように、ＮｅＤＳ２００は、リファレンスポイントとも称される場合のある、明確なインターフェースを経て、複数の機能的な／論理的なエンティティによって動作可能であることが好ましい。参照点「Ｐｚ」は、通信経路、したがってＮｅＤＳ２００とプレゼンスネットワークエージェント５０８との間の通信経路の必要性を識別し、これによって、ＮｅＤＳ２００は、モビリティ管理イベントをプレゼンスネットワークエージェント５０８に報告することができる。ＩＰベースのドメイン（すなわちＰＳドメイン）に関して、イベントは、これに限定されないが、接続、ページングに対して到達不可、分離、ルーティング領域（ＲＡ）の更新などを含むことができる。ＣＳドメインに関しては、イベントは、これに限定されないが、同様に、接続、分離、位置エリア（ＬＡ）更新などを含む。更なるバリエーションでは、参照点Ｐｚによって、ＮｅＤＳ２００は、ベアラ情報およびコール解放によるコールの設定のような、コール関連のイベントを報告できるようになる。加えて、参照点Ｐｚによって、ＮｅＤＳ２００は、モビリティ状態（例、分離、アイドル、接続など）、およびアクティブまたは非アクティブＰＤＰコンテクストのようなセッション状態も報告できるようになる。実装に関しては、参照点Ｐｚの例示的な一実施形態は、３ＧＰＰベースのＣｕｓｔｏｍｉｚｅｄ Ａｐｐｌｉｃａｔｉｏｎｓ ｆｏｒ Ｍｏｂｉｌｅ Ｅｎｈａｎｃｅｄ Ｌｏｇｉｃ（ＣＡＭＥＬ）に準拠したインターフェースを伴う場合がある。

参照点「Ｐｗ」は、通信経路、したがってＮｅＤＳ２００と、例えばＧＰＰ ＴＳ２３．１４１に定義されているようなプレゼンティティプレゼンスプロキシ５０２との間の通信経路の必要性を識別する。プレゼンティティプレゼンスプロキシ５０２は、プレゼンティティに関連するプレゼンスサーバを決定するような、プレゼンティティ関連の機能を提供する機能エンティティとして動作可能である。無線アクセスネットワークホットスポットデータベース５０４（例、ＷＬＡＮ、Ｗｉ−ＭＡＸネットワークなどのためのホットスポット）は、参照点「ｚ」を経てＮｅＤＳ２００とインターフェースすることができるが、この参照点によって、ＮｅＤｓのドメインルーティング機能は、ＩＭＳサービス（例、ＶＣＣ）が、ＵＥが現在登録されている無線アクセスネットワークにおいて、実行することができるかどうか、および／または実行すべきかどうかを決定することができる。このような決定は、全地球測位システム（ＧＰＳ）情報、セルグローバル識別（ＣＧＩ）、または空港コード、都市名、ランドマークなどのような他のユーザ入力の中継地点に基づいて、ＵＥの位置を決定することによって達成することができる。ポリシー決定機能５０６は、参照点「ｊ」を経てＮｅＤＳ２００とインターフェースすることができるが、この参照点によって、ＮｅＤＳ２００は、コールをルーティングするためのオペレータポリシー／プレファレンス情報を得ることができる。ユーザポリシー／プレファレンスに関しては、それらは、参照点「ｙ」を経てＮｅＤＳ２００とインターフェースするホーム加入者サーバ（ＨＳＳ）（例、ＨＳＳ ５１２）と呼ばれる、別のネットワーク要素に格納することができる。ユーザポリシー情報がＨＳＳ５１２内に格納されていない場合、参照点ｊは、ＮｅＤＳ機能が使用して、外部データベースから適切なポリシー情報を得ることができる。

続けて図５を参照すると、ＮｅＤＳ２００と、ＵＥデバイス５１０との間のインターフェースは、参照点「ｋ」によって規定され、ＵＥデバイスは、ＮｅＤＳが、プレゼンスベースのステータス通知を受信するために加入することができる、プレゼンスユーザエージェント５１４も含むことができる。このインターフェースによって、ＮｅＤＳは、各ドメイン内のＵＥデバイスの状態（例、接続、分離など）、任意の接続の状態（例、ＰＤＰの起動、発信コール、コールがいつ設定されたか、コールがいつ解除されたか、など）、およびＵＥデバイスに関する位置情報を認識することができる。加えて、このインターフェースによって、ユーザは、ＮｅＤＳノードにおいて、ＩＭＳサービスの設定を、起動、停止、問い合わせ、および／または修正を行うこともできる。上述のように、ＨＳＳ５１２は、参照点ｙを経てＮｅＤＳとインターフェースすることができ、これによって、ＮｅＤＳは、（ｉ）適切なＣＡＭＥＬトリガをオンにすることによって、ＩＭＳサービス（例、ＶＣＣ）を起動させること、（ｉｉ）ＣＡＭＥＬトリガをオフにすることによって、ＩＭＳサービスを停止させること、および（ｉｉｉ）コールルーティングするためのユーザポリシー情報を得ることができる。

図６Ａは、ＵＥデバイスの適切な状態遷移を保持するネットワークノード（例、ＮｅＤＳ２００）を備えた、状態転移エンジン６００の一実施形態を示す図である。基本的に、図６Ａに示される種々の状態は、ＵＥデバイスが取り得る複数のステータス条件およびステータス間の許容可能な遷移を規定する。ＵＥデバイスは、初期ヌル状態６０２から始まり、状態６１８へ遷移することができ、この状態は、ＵＥがＣＳドメインに接続され、コールを発生および終了できることを規定する。状態６１６は、ＵＥデバイスが、ＣＳドメインへの接続を継続し、コール時にアクティブであることを規定する。状態６１２は、ＵＥデバイスが、ＣＳドメインに接続され、例えばＷＬＡＮ、Ｗｉ−ＭＡＸ、ＬＴＥなどを経て、ＩＭＳドメインに登録されることを規定する。さらに、ＵＥデバイスは、ＣＳドメイン内でのコール時にアクティブであり、このドメイン内でのコールの発生および終了だけを行うことができる。状態６０６は、ＵＥデバイスが、ＣＳドメインに接続され、ＩＭＳドメインに登録されることを規定する。ＵＥデバイスは、ＩＭＳドメイン内でのコールにおいてアクティブであり、ＩＭＳドメイン内でのコールの発生および終了だけを行うことができる。状態６１８に類似した状態６０８は、ＵＥデバイスが、例えばＷＬＡＮ、Ｗｉ−ＭＡＸ、ＬＴＥなどを経て、ＩＭＳドメイン内に登録され、コールを発生および終了できることを規定する。状態６１０は、ＵＥデバイスが、例えばＷＬＡＮを経てＩＭＳドメイン内に登録され、コール時にアクティブであることを規定する。状態６０４は、ＵＥデバイスがＣＳドメインに接続され、さらにＩＭＳドメインに登録されるが、両ドメインにおいてアイドルであることを規定する。状態６１４は、ＵＥデバイスが、ＣＳドメインに接続され、ＩＭＳドメインに登録され、両ドメインにおいてアクティブであることを規定する。この遷移状態は、ドメイン間のＩＭＳサービス（例、ＶＣＣ）が、実際に実行され、一定の時間現れるときに存在する。

図６Ａにはいかなるサブ状態も明確に示していないが、特定のＩＭＳベースの状態が、実際の実装によって、１つ以上のこのようなサブ状態を有する場合があると想定される。例示的な一実施形態では、このようなサブ状態は、ＵＥデバイス自体から分かる場合がある。例えば、ＵＥデバイスが、例えばＷＬＡＮ、Ｗｉ−ＭＡＸ、またはＬＴＥネットワークを伴うが、まだローカルＩＰアドレスを有していないことを規定し得る。ローカルＩＰアドレスがＵＥデバイスに割り当てられると、デバイスは、まだＩＭＳネットワークに登録されていないが、この条件を規定する別のサブ状態に遷移することができる。このような状態は、ＵＥデバイスがＷＬＡＮを使用してＩＭＳコアへ到達できる前に、いくつかのタイプの承認がＵＥデバイスに求められる時に存在し得る。

当業者は、図６Ａの状態遷移エンジン／モデル６００におけるＷＬＡＮに関して参照したが、他のＩＰベースの無線ネットワークに関する状態遷移も含むことができると認識されたい。したがって、「ＩＭＳの状態」という用語は、本特許開示に対して、ＷＬＡＮおよび他のＩＰベースの無線アクセスネットワークの両方に関する状態を包含し得る。

上述したように、種々のポリシー／プレファレンス（例、オペレータベースのポリシーおよびプレファレンス、ユーザベースのポリシーおよびプレファレンス）、およびそれらのあらゆる組み合わせ（集合的に「ポリシー基準」）を提供して、本願明細書において説明される実施形態による、ＮｅＤＳ機能のドメイン選択プロセスを調整することができる。図６Ｂは、本開示のために、ネットワークベースまたはデバイスベースのいずれかのデータベース構造として組み込むことができる、ポリシースキーマ６５０を示す図であり、参照番号６５２は、ＵＥに対して適用可能なポリシースペース全体を指す。例示的なオペレータベースのポリシー６５４は、（ｉ）ＩＭＳコール配信６５８（すなわち、入力コールの終了がＩＭＳドメイン内で生じた）、および（ｉｉ）ＣＳコール発信６５６（すなわち、入力コールの終了がＣＳドメイン内で生じた）の２つのカテゴリに分類することができる。同様に、ユーザベースのポリシー６６０も、ＩＭＳコール配信６６２およびＣＳコール配信６６４のカテゴリに分類することができる。

オペレータベースのＩＭＳコール配信ポリシー６５６には、次のような例が挙げられる。
−ＵＥデバイスがＣＳ登録されたときに、そのデバイスがＩＭＳ登録されていても、ＩＭＳコール／セッションがＣＳ側に配信される。
−ＵＥデバイスがＣＳ登録されたときに、そのデバイスがＣＳ登録されていても、あらゆるサービスの質（ＱｏＳ）の考慮に関わらず、ＩＭＳコール／セッションがＩＭＳ側に配信される。
−ＵＥデバイスがＣＳ登録されたときに、そのデバイスがＣＳ登録されていても、所与の最小ＱｏＳに対して、ＩＭＳコール／セッションがＩＭＳ側に配信される。
−ＵＥデバイスがＣＳ登録されたときに、ＩＭＳコール／セッションは、ＩＭＳが利用できないときにはＣＳ側に配信されない。
−いかなるポリシーも指定されない。

同様に、オペレータベースのＣＳコール配信ポリシー６５８には、次のような例が挙げられる。
−ＵＥデバイスがＩＭＳ登録されたときに、そのデバイスがＣＳ登録されていても、ＣＳコール／セッションがＩＭＳ側に配信される。
−ＵＥデバイスがＩＭＳ登録されたときに、そのデバイスがＣＳ登録されていても、所与の最小ＱｏＳに対して、ＣＳコール／セッションがＩＭＳ側に配信される。
−ＵＥデバイスがＩＭＳ登録されたときに、そのデバイスがＩＭＳ登録されていても、ＣＳコール／セッションがＣＳ側に配信される。
−ＵＥデバイスがＣＳ登録されたときに、ＣＳコール／セッションは、ＣＳが利用できないときにはＩＭＳ側に配信されない。
−いかなるポリシーも指定されない。

同様に、ユーザベースのＩＭＳコール配信ポリシー６６２には、次のような例が挙げられる。
−ＵＥデバイスがＣＳ登録されたときに、そのデバイスがＩＭＳ登録されていても、ＩＭＳコール／セッションがＣＳ側に配信される。
−ＵＥデバイスがＣＳ登録されたときに、そのデバイスがＣＳ登録されていても、あらゆるサービスの質（ＱｏＳ）の考慮に関わらず、ＩＭＳコール／セッションがＩＭＳ側に配信される。
−ＵＥデバイスがＣＳ登録されたときに、そのデバイスがＣＳ登録されていても、所与の最小ＱｏＳに対して、ＩＭＳコール／セッションがＩＭＳ側に配信される。
−ＵＥデバイスがＣＳ登録されたときに、ＩＭＳコール／セッションは、ＩＭＳが利用できないときにはＣＳ側に配信されない。
−いかなるポリシーも指定されない。

加えて、ユーザベースのＣＳコール配信ポリシー６６４には、次のような例が挙げられる。
−ＵＥデバイスがＩＭＳ登録されたときに、そのデバイスがＣＳ登録されていても、ＣＳコール／セッションがＩＭＳ側に配信される。
−ＵＥデバイスがＩＭＳ登録されたときに、そのデバイスがＣＳ登録されていても、所与の最小ＱｏＳに対して、ＣＳコール／セッションがＩＭＳ側に配信される。
−ＵＥデバイスがＩＭＳ登録されたときに、そのデバイスがＩＭＳ登録されていても、ＣＳコール／セッションがＣＳ側に配信される。
−ＵＥデバイスがＣＳ登録されたときに、ＣＳコール／セッションは、ＣＳが利用できないときにはＩＭＳ側に配信されない。
−いかなるポリシーも指定されない。

さらに、更なるポリシーまたはルーティングルール６６６を、コール回線識別（ＣＬＩ）に基づいて実装することができ、１つ以上の一連のＥ．１６４コーリングパーティ番号を、特定のルーティング処理に対して規定することができる。範囲は、一連のあらゆる任意のサイズＩ（Ｉ＝１、２、．．．、Ｎ）を含むことができる。規定されたそれぞれの範囲に関して、例示的なポリシーは、入力コールを、（ｉ）ＩＭＳ側のみに配信すべきか、（ｉｉ）ＣＳ側のみに配信すべきか、（ｉｉｉ）最初にＩＭＳ側に終了し、失敗した場合は、次いでＣＳ側に終了する、（ｉｖ）最初にＣＳ側に終了し、失敗した場合は、次いでＩＭＳ側に終了する、（ｖ）選択的処理無しなどを含むことができる。

例示的なポリシー／プレファレンススキーム６５０は、起こり得る競合の場合に、適切なルールまたは優先権が実行される、競合解消機構（ｃｏｎｆｌｉｃｔ ｒｅｓｏｌｕｔｉｏｎ ｍｅｃｈａｎｉｓｍ）６６８を含むこともできる。ユーザベースのポリシーと、オペレータベースのポリシーとの間には、次のようなオプションを実装することができる。（ｉ）ユーザポリシーが、常に優先権を取る、（ｉｉ）オペレータポリシーが、常に優先権を取る、（ｉｉｉ）ユーザポリシーが存在しないときには、オペレータポリシーを使用する、および（ｉｖ）オペレータポリシーが存在しないときには、ユーザポリシーを使用する。加えて、ＣＬＩベースのルーティングポリシー６６６が、ユーザベースであるか、オペレータベースであるかに関わらず、ＣＬＩベースのルーティングポリシー６６６がＩＭＳおよびＣＳコール配信ポリシーに優先するという、ルールを提供することができる。

上述のように、種々のポリシーおよびプレファレンス６５２は、ＮｅＤＳ要素内にローカルに格納するか、または適切なインターフェーシングを経てＮｅＤＳ要素にアクセス可能な外部データベース内に提供することができる。加えて、ユーザポリシーおよびプレファレンス、ならびに他の関連情報は、ＵＥデバイスの一部として提供される、汎用集積回路カード（ＵＩＣＣ）、汎用加入者識別モジュール（ＵＳＩＭ）、着脱可能なユーザ識別モジュール（ＲＵＩＭ）、コンパクトフラッシュ（登録商標）、セキュアデジタル（ＳＤ）メモリカードなどのような着脱可能なモジュール内に格納することができる。さらに、加入者は、ＵＥデバイスを操作して、適用可能なＣＳベースの、またはＩＭＳベースのメッセージングを使用して、ＮｅＤＳ要素において、適切なユーザポリシー設定を達成することができる。

図７は、本開示の一実施形態による、ＮｅＤＳ要素（例、ＮｅＤＳ２００）においてユーザポリシー／プレファレンス設定を達成するためのメッセージフロー図である。以下の説明で分かるように、本開示のメッセージフロー図は、モバイルスイッチングセンタ（ＭＳＣ）、ビジタロケーションレジスタ（ＶＬＲ）、およびホーム加入者サーバ（ＨＳＳ）のような既知の要素で示す場合があるが、これらは、例えばＭＳＣ／ＶＬＲエンティティが、コール制御、サービス制御、およびメディア交換を実行することができるような、特定の機能を有するネットワークノードとして一般化される場合がある。したがって、本願明細書で説明される特定の実装に関わらず、例示的な機能は、別個のプラットホームによっても達成できることは明らかである。図７に示されるように、ＵＳＳＤメッセージ７０４をＣＳドメイン内のＵＥデバイス５１０によって発生させて、ＮｅＤＳ２００においてユーザポリシーおよびプレファレンスを、起動、問い合わせ、停止、または変更することができる。一般的に、メッセージフローは、ＵＥデバイスと、そのホームＩＭＳ ＮｅＤＳノード２００との間に配置された、モバイルスイッチングセンタ（ＭＳＣ）および関連するビジタロケーションレジスタ（ＶＬＲ）のような、ネットワーク要素（集合的にノード７０２と称する）を経て仲介することができる。応答ＵＳＳＤメッセージ７０６は、リクエストに応じて、適切な情報とともに、ＭＳＣ／ＶＬＲ７０２を経て、ＮｅＤＳ２００からＵＥデバイス５１０へ伝搬される。

別様には、ＮｅＤＳ２００においてユーザポリシー／プレファレンス設定を達成するためのメッセージフローは、拡張マークアップ言語（ＸＭＬ）設定アクセスプロトコル（ＸＣＡＰ）メッセージングまたはＳＩＰパブリッシュメッセージングのような、他のメッセージングプロトコルを使用して、ＩＭＳドメイン内に実装することができる。ＣＳベースのメッセージング、またはＩＭＳベースのメッセージングの使用を問わず、ＵＥデバイス５１０は、次の情報要素のうちの１つ以上を含むように動作可能である。加入者識別（例、国際モバイル加入者識別（ＩＭＳＩ）、モバイル識別番号（ＭＩＮ）、ネットワークアクセス識別子（ＮＡＩ）などのようなプライベートユーザ識別）、機器識別またはインスタンス識別子（例、国際モバイル機器識別（ＩＭＥＩ）またはＩＭＥＩＳＶ、電子シリアル番号（ＥＳＮ）、個人識別番号（ＰＩＮ）、媒体アクセス制御（ＭＡＣ）アドレスなど）、グローバルにルーティング可能なユーザエージェントＵＲＩ（ＧＲＵＵ）またはＧＲＵＵ（ＩＭＳＩおよびＩＭＥＩの組み合わせとすることができる）、ポリシー情報、および取るべきアクション（例、起動、停止、変更、問い合わせなど）。例えば、ユーザは、ＩＭＳサービス（例、ＶＣＣ）を起動することができ、その後、複数のユーザポリシーを、上述したようなＩＭＳコールおよび／またはＣＳコールに関して設定することができる。同様にユーザは、ＣＳまたはＩＭＳドメイン内の適切なメッセージングを経て、ＩＭＳサービスを停止することもできる。ユーザによる問い合わせ時に、ＮｅＤＳ２００からの応答メッセージは、問い合わせられたＩＭＳサービスを停止することを示すか、またはアクティブである場合は、適用可能なポリシー／プレファレンスを含めることができる。変更オプションを使用することで、ユーザは、クエリ内に含まれるＩＭＳサービスに関して、１つ以上の適用可能なユーザポリシーおよびプレファレンスを変更することができる。

一例として、ＮｅＤＳネットワークノードにおいてポリシー／プレファレンスを達成するＸＭＬメッセージングの表を以下に示す。

ＸＭＬにおけるポリシーアクティブ化の別の実施例を、次の表ＩＩに示す。

種々の例示的な符号化構造を、ＮｅＤＳ２００においてユーザポリシー／プレファレンス設定を達成するための上述したメッセージフローに用いることができる。例示的な実装として、８ビットおよび４ビットの２進コードを、ＸＭＬベースの構文の範囲内で使用することができる。構文の全般的な構造を以下に示す。

実行するオペレーション
長さ
配信オプション（無し、ＣＳ、ＩＭＳ）
長さ
ポリシー（１〜Ｎ）
配信オプション（無し、ＣＳ、ＩＭＳ）
長さ
ポリシー（１〜Ｎ）
次の表は、動作および配信オプションに関する８ビット２進コードの構造を示す。

図８は、一実施形態における、ネットワークノードによる初期登録に関連するメッセージフロー図である。図に示されるように、ＵＥデバイス５１０がＣＳシグナリングを使用してネットワークに接続すると、ＨＳＳ５１２は、ＵＥデバイスの接続ステータスのサービングネットワークノード２００を通知するように動作可能である。参照番号８０２は、ＵＥ５１０と、ＭＳＣ／ＶＬＲ７０２との間のプロシージャメッセージングの適用可能な接続を指す。同様に、参照番号８０４は、ＭＳＣ／ＶＬＲ７０２と、ＨＳＳ５１２との間のプロシージャメッセージングの接続を指す。上述のように、ＭＳＣ／ＶＬＲは、基本的に、セッション制御および／または音声のような交換媒体の役割を果たすネットワークノードである。ＨＳＳ５１２は、基本的に、これに限定されないが、加入者が加入したサービス、加入したサービスのユーザ構成、ユーザポリシー、オペレータポリシー、およびポリシーおよびポリシーの組み合わせが適用されたときに、種々のネットワーク要素がどのように作用するのか、に関する情報を含むデータベース機能である。

接続プロシージャ８０４のときに、ＨＳＳ５１２は、ＮｅＤＳ２００に向けて通知メッセージ８０６を発生して、ＵＥの接続ステータスを通知する。通知８０６を受信すると、タイマを開始することができ（ブロック８０８）、ＵＥデバイス５１０から登録メッセージ８１２を受信するまで保持される。ＮｅＤＳ２００において登録メッセージ８１２を受信すると、タイマが停止され（ブロック８１４）、ＵＥデバイスがＩＭＳサービスに対応できることを示す。タイマ機構（ブロック８１０）は、ＵＥデバイス上で開始することができるので、また、登録メッセージ８１２が発生されたときに、ＮｅＤＳ２００からの登録応答メッセージ８１６の有効性を保証することができる。応答メッセージ８１６を受信すると、ＵＥのタイマを停止することができる（ブロック８１８）。

図９は、（例えば、ＧＰＲＳネットワーク、ＬＴＥネットワーク、Ｗｉ−ＭＡＸ、またはＷＬＡＮのようなＩＰベースのネットワークを経て）ＩＭＳシグナリングが使用される別の実施形態における、ネットワークノードによる初期登録に関連するメッセージフロー図である。ＣＳシグナリングを使用したＭＳＣ７０２によるＵＥデバイスの接続プロシージャ９０８のときに、適切な位置更新（ＬＵ）および加入者データ挿入（ＩＳＤ）プロシージャ９１０を、ＨＳＳ５１２とＭＳＣ７０２との間で行う。加えて、ＩＰベースのネットワーク（例、ＧＰＲＳ）によるＵＥデバイスの接続プロシージャ９１２のときに、サービングＧＰＲＳサポートノード（ＳＧＳＮ）９０２は、ＨＳＳ５１２による適用可能なＬＵおよび／またはＩＳＤプロシージャ９１４を行うように動作可能である。それに応答して、通知メッセージ９１６が発生され、ＵＥデバイス５１０に関する接続ステータスをＮｅＤＳ２００に通知し、その時点でタイマ機構を開始することができる（ブロック９１８）。ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）によるＰＤＰコンテクスト（参照番号９２０）を生成すると、ＵＥ５１０は、登録メッセージ９２２を経て、サービングコールセッション制御機能（Ｓ−ＣＳＣＦ）９０６によって登録する。それに応じて、Ｓ−ＣＳＣＦ９０６は、ＮｅＤＳ２００による第三者登録プロシージャ９２４を行い、その時点で、タイマ機構を停止することができる（ブロック９２６）。更なる実装として、ＩＭＳネットワークによって登録が行われた後に、ＮｅＤＳノード２００は、ＳＩＰオプションリクエスト９２８をＵＥデバイス５１０へ送信して、その能力（例えば、特にＩＭＳサービス能力）をリクエストする。それに応じて、ＵＥ５１０は、リクエストされた能力に関する適切なインジケーションを含むことができる、ＳＩＰ ＯＫメッセージ９３０を発生する。その後、ＳＩＰパブリッシュメッセージまたはＸＣＡＰメッセージ９３２を、ＵＥデバイス５１０によってＮｅＤＳ２００に提供することができ、このメッセージは、適切な構成情報（例、ポリシー情報、更新、行うべきアクションなど）を含む。

別の実装では、ＣＣＣＦ／ＮｅＤＳ機能を有するＩＭＳノードは、ＨＳＳにＣＡＭＥＬトリガを無効にすることを通知するように動作可能である。図１０は、一実施形態による、ＮｅＤＳ要素によるトリガの無効化に関連するメッセージフロー図である。上述のように、ＵＥデバイス５１０は、適用可能な接続プロシージャ８０２を使用して、ＭＳＣ／ＶＬＲ７０２に接続する。タイマ機構は、メッセージ８１２を発生したときに、ＵＥデバイス５１０上で開始することができ、ＭＳＣ／ＶＬＲインフラストラクチャを経てＮｅＤＳ２００に伝搬される。メッセージ８１２を受信すると、ＮｅＤＳノード２００においてタイマ機構を開始することができる（ブロック１００２）。また、停止メッセージ１００４は、ＮｅＤＳ２００によってＨＳＳ５１２に向けて発生され、１つ以上の選択ＩＭＳサービス（例、ＶＣＣ）に関連するＣＡＭＥＬトリガを無効にすることを示す。それに応じて、通知メッセージ１００６は、ＨＳＳ５１２によってＮｅＤＳ２００に提供され、その時点で、タイマ機構は停止される（ブロック１００８）。適切な応答メッセージング１０１０は、逆にＮｅＤＳ２００からＵＥデバイス５１０へ伝搬される。

ＵＥデバイスおよびその情報は、最終的にＮｅＤＳの機能によって登録する必要があるので、ＣＣＣＦは、特に、ＵＥデバイスが、ＣＣＣＦノードによって登録するようにしか動作できない場合に、必要な情報を関連するＮｅＤＳに通信するステップを伴う場合がある。上述のように、ＮｅＤＳによる登録は、ＩＭＳドメインを経て、またはＣＳドメインを経て達成することができる。また、適用可能な登録プロセスは、ＵＥデバイスが、ＣＳネットワークまたはＰＳネットワークのいずれかに接続された後に行われることが好ましい。例示的な実装として、ＮｅＤＳの登録が、ＩＭＳシグナリングを経て最初に行われるように指定される場合がある。しかし、ＩＭＳシグナリングが利用できない場合（例えば、ＧＰＲＳまたはＷＬＡＮのカバレッジが無いために）、登録は、上述のように、ＣＳシグナリングを使用して進めることができる。

図１１は、ＨＳＳノードを伴わない一実施形態における、ネットワークノードによる一般化された登録プロセスに関連するメッセージフロー図である。適用可能な接続プロシージャ８０２を経たＣＳネットワークによる接続後に、ＵＥ５１０は、ＭＳＣ／ＶＬＲインフラストラクチャ７０２を経てＮｅＤＳ２００に伝搬される、登録メッセージ１１０２を発生するように動作可能である。登録メッセージ１１０２は、これに限定されないが、ＵＳＳＤメッセージング（下記に詳述する）、またはショートメッセージサービス（ＳＭＳ）メッセージングを使用して実装することができる。好適な応答メッセージング１１０４は、ＮｅＤＳによってＵＥ５１０に提供される。例示的な実装として、ＣＳドメイン内で達成される登録メッセージ１１０２は、以下の情報要素のうちの１つ以上を含むことができる。ＧＲＵＵ、ＧＲＵＵサポート、加入者識別（例、ＩＭＳＩ）、装置識別またはインスタンス識別子（例、ＩＭＥＩ／ＩＭＥＩＳＶ、ＰＩＮ、ＥＳＮなど）、加入者の位置（例、ＧＰＳ情報、登録されたネットワークに関するＣＧＩ情報、空港名コード、都市、対象地点またはランドマークデータ、郵便番号のようなユーザ入力中継地点など）、利用可能なネットワークに関するネットワークＩＤ情報（例、広域携帯電話ネットワークに関するＣＧＩ情報、ＷＬＡＮに関するサービスセット識別子（Ｓｅｒｖｉｃｅ Ｓｅｔ Ｉｄｅｎｔｉｆｉｅｒ：ＳＳＩＤ）情報、Ｗｉ−ＭＡＸネットワークなど）、位置更新タイマ情報、ＰＳ接続ステータス（すなわち、接続または分離）、ルーティング更新タイマ情報、ＰＤＰコンテクストステータス（すなわち、接続または分離）、ＩＰネットワークステータス（例、ＷＬＡＮステータス）（関連する、割り当てられたローカルＩＰアドレス、接触したＰＤＦなど）、および加入者プレファレンス／ポリシー。

上述のように、ＧＲＵＵは、ＩＭＳＩおよびＩＭＥＩの組み合わせで構成することができ、一意のインスタンスＩＤ（例、ＩＭＥＩ）およびレコード（例、ＳＩＰ ＵＲＩ）のアドレスを示すように動作可能である。位置データを使用して、（例えば、ＶＣＣがサポートされていない国または領域において）ＩＭＳサービス（例、ＶＣＣ）を呼び出すべきか、または無効にすべきかを決定することができる。加えて、位置データを使用して、ＵＥデバイスが、ＩＭＳサービスに対応できるネットワーク上に現在登録されているかどうかを決定することもできる。ネットワークＩＤ情報を使用して、リダイレクション能力をサポートすることができる。すなわち、ＵＥデバイスは、利用可能なネットワークおよびそれらの能力、およびＵＥデバイスによって指定されたサービス要件に基づいて、異なる携帯電話ネットワーク、またはＩＭＳネットワークノードによるＷＬＡＮへリダイレクトすることができる。位置更新タイマ情報は、ＵＥデバイスとＮｅＤＳとの間で、情報の更新を同調させるように、ＮｅＤＳ機能によって使用することができる。ルーティング更新タイマ情報は、ルーティング更新タイマがリセットされたかどうかを検証するために、どのくらいの頻度でＰＳネットワークによって定期的にチェックするのかを決定するように、ＮｅＤＳ機能によって使用することができる。

ＣＳシグナリングを経た登録に関するＵＥデバイス５１０の動作は、次のように要約することができる。登録メッセージの送信時に、ＵＥデバイスは、ＮｅＤＳ機能からの応答が予想される時間ウィンドウを設定するように、（ハードコードされた、またはＵＥ内（いずれもＯＴＡで設定できる、上述したような着脱可能なモジュール内か、またはＵＥ内に組み込まれたメモリ内）に設定された）タイマを開始することができる。いかなる応答も受信しなかった場合、ＵＥデバイスは、登録プロセスを選択した回数（例、５回）試行することができ、その後に、通信経路が故障した、および／またはＩＭＳサービスが利用できないものとみなすことができる。応答メッセージを、時間ウィンドウ内に、または有効な再試行時に受信した場合、ＵＥデバイスは、タイマ機構を停止するように動作可能である。応答メッセージが、ＶＣＣを行うべきではない旨のインジケーションを含む場合、ＵＥデバイスは、ＩＭＳからＣＳへ、また逆の場合も同様に、いかなるハンドオーバも実行できない。その結果、ＵＥデバイスは、ＶＣＣのためのいかなるシグナリングも行うことができない。ＵＥデバイスが、応答メッセージを経てＧＲＵＵを受信する場合、受信したＧＲＵＵは、ＵＥのメモリ内、またはＵＥに接続された着脱可能なモジュール内にローカルに格納することができる。状況に応じて、ＮｅＤＳ更新タイマを、ＵＥデバイスへの応答メッセージ内に備えることができ、これも同様にローカルに格納することができるが、任意のデフォルト値を上書きすることが好ましい。更なるバリエーションでは、ＵＥデバイスは、それが現在登録されていないネットワークに対する１つ以上のＰＬＭＮ（Ｐｕｂｌｉｃ Ｌａｎｄ Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ）符号を受信することができる。このような符号が含まれる場合、ＵＥデバイスは、適用可能な帯域および技術でスキャンを実行して、ネットワークを発見することができる。その後、発見時に、ＵＥデバイスは、発見したネットワークに関して接続プロシージャを実行することができ、また、登録および登録後の処理を繰り返すことができる。別様には、いかなるネットワークも発見しなかった場合、受信したＰＬＭＮ符号を無視することができる。

同様に、ＩＭＳシグナリングを経たＵＥデバイス５１０の登録動作は、次のように要約することができる。ＣＳネットワークまたはＰＳネットワークによるＵＥデバイスの認証が成功すると、次いで、上述したように、ＳＩＰメッセージング（例、ＳＩＰノーティファイまたはＳＩＰパブリッシュ）またはＸＣＡＰメッセージングを経て、例えばＧＰＲＳのような適用可能なパケットデータインフラストラクチャを通じて、ＮｅＤＳに登録することができる。用いた実際のメッセージングプロトコルに関わらず、登録メッセージは、ＣＳシグナリングを経た登録に関して、上述した情報要素に類似した複数の情報要素を含むことが好ましい。さらに、種々のタイマ機構および登録後のプロセスは、ＩＭＳシグナリングを経た登録時に、ＵＥによって起動することも可能であり、このプロセスは、ＣＳベースの登録におけるＵＥの動作に関して上述したプロセスとほぼ同じである。

実例として、図１２および１３は、ＵＳＳＤのメッセージングを使用した、ＮｅＤＳ要素による一般化されたＣＳベースの登録プロセスに関連するメッセージフロー図である。モバイル発信ＵＳＳＤ（ＭＯ−ＵＳＳＤ）登録メッセージ１２０４は、ＭＳＣ／ＶＬＲインフラストラクチャ７０２を経たＮｅＤＳ２００への伝搬のために、ＵＥデバイス５１０によって発生される。それに応答して、肯定応答メッセージ（ＭＯ−ＵＳＳＤ−Ａｃｋ）１２０８が、ＮｅＤＳ２００によって返される。その後、別のメッセージ、モバイルターミネーテッドＵＳＳＤ（ＭＴ−ＵＳＳＤ）応答１２１０は、ＮｅＤＳ機能２００によってＵＥデバイスに提供され、適切な情報を含む。それに応答して、肯定応答メッセージ（ＭＴ−ＵＳＳＤ−Ａｃｋ）１２１４が、ＵＥデバイスによって発生される。参照番号１２０２／１２１２および１２０６／１２１６は、上記に詳述したように、それぞれデバイス側、およびＮｅＤＳ側へのタイマープロセスを指す。図１３に示されるメッセージフローの実施形態は、いかなる別個のＵＳＳＤ肯定応答メッセージも使用されていないことを除いて、基本的に、図１２に示されるメッセージフローの実施形態に類似する。したがって、参照番号１３０４および１３０６は、それぞれＭＯ−ＵＳＳＤ登録および応答メッセージを指し、応答メッセージ１３０６は、肯定応答および必要な情報の両方を含む。同様に、参照番号１３０２および１３０８は、上述のように、デバイス側へのタイマープロセスを指す。

登録の後に、ＵＥデバイスは、次の条件のうちの１つ以上に基づいて、更新されたステータス情報をＮｅＤＳ要素に提供することができる。（ｉ）ＮｅＤＳ位置更新タイマの終了、（ｉｉ）ＣＳドメインステータスの変化、および（ｉｉｉ）ＩＰドメインステータス（例、ＷＬＡＮに関するステータス）の変化。一実装例では、更新された情報の伝送は、上述したＮｅＤＳ／ＵＥデバイスのインターフェースを使用するプレゼンスベースのメッセージングを経て制御することができる。例えば、ＮｅＤＳ機能は、ＣＳステータス、ＩＭＳステータス、タイマーイベントなどの何らかの変化を検出したときに、適切な通知をＮｅＤＳに提供できるように、ＵＥのユーザエージェントに加えることができる。図１４は、ＵＥデバイスのステータス変更に関する、ＵＥデバイスと、関連するＮｅＤＳ要素との間のメッセージングに関連するメッセージフロー図である。ＮｅＤＳ２００によってＵＥデバイス５１０に向けて発生されたＳＩＰサブスクライブメッセージ１４０２は、種々のリクエストされたステータス変更を含む。ＵＥデバイスからの応答メッセージ１４０６は、リクエストに従って適切なステータス更新を含む。別様には、ＵＥデバイス５１０がＮｅＤＳ２００に登録されるときに、ＵＳＳＤ／ＳＭＳまたはＳＩＰ応答メッセージでフラグを返すことができ、当該のプレゼンス情報が必要であることを示す。

定期的な通知が実装された場合（例えば、ＮｅＤＳタイマの終了に基づいて）、ＣＳシグナリングまたはＩＭＳシグナリングのいずれかを使用することができる。ＮｅＤＳタイマが終了したときに、ＵＥは、上述した情報要素（例えば、ＧＲＵＵ、加入者識別、装置識別、加入者の位置（例、ＧＰＳ情報、登録されたネットワークに関するＣＧＩ情報など）、ネットワークＩＤ情報（例、ＣＧＩおよび／またはＳＳＩＤ）、位置更新タイマ情報、ＰＳ接続ステータス、ルーティング更新タイマ情報、ＰＤＰコンテクストステータス、ＷＬＡＮステータス、および加入者プレファレンス／ポリシー）のうちのいずれかに関するステータス変更を含む、更新メッセージを送信するように動作可能である。別個のタイマ機構は、更新メッセージングプロセスに関して、ＵＥデバイスによって実装することができる。更新メッセージを送信すると、タイマを開始して、応答ウィンドウを識別することができる。応答ウィンドウ内で、ＮｅＤＳ機能からいかなる応答または肯定応答も受信されなかった（すなわち、タイマが終了した）場合、ＵＥは、更新メッセージが失敗したとみなされる前に、選択した回数（例、最大５回）更新メッセージの再送信を試行することができる。

ＵＥデバイスがＣＳカバレッジを喪失し、ＮｅＤＳ機能が、別の無線アクセス技術（例えばＷＬＡＮ、Ｗｉ−ＭＡＣ、ＬＴＥなど）を経て到達することができる場合、ＵＥデバイスは、「ＣＳカバレッジ喪失」メッセージを通じて、ＣＳカバレッジを喪失したことをＮｅＤＳに通知するロジックを含む。加えて、次の情報要素を、これに限定されないが、ＣＳカバレッジの損失メッセージ内に含むことができる。ＧＲＵＵ、加入者識別（公開ユーザＩＤおよび／またはプライベートユーザＩＤ）、端末識別（ＭＡＣアドレス、ＩＭＥＩ／ＩＭＥＩＳＶ、ＰＩＮ、ＥＳＮなど）、加入者の位置、ネットワークＩＤ情報（例、ＳＳＩＤおよび／またはＣＧＩ）、およびＣＳ分離ステータス。このＣＳカバレッジの喪失メッセージは、ＳＩＰノーティファイまたはＳＩＰパブリッシュメッセージを使用して実装することができると理解されたい。さらに、このプロシージャは、ＷＬＡＮドメイン内に発信コールがある間に行うことができる。

ＵＥデバイスがＣＳカバレッジを再び発見した場合、ＵＥデバイスは、それに応じてＮｅＤＳ機能に通知するロジックを含む。図１５は、ＵＥ５１０によるＣＳドメインの発見に関する、ＵＥ５１０と、関連するＮｅＤＳ要素２００との間のメッセージングに関連するメッセージフロー図である。図に示されるように（参照番号８０２）、新たに発見したＣＳネットワークへの接続は、オプションである場合がある。更新メッセージ１５０２は、ＵＥデバイス５１０によって、提供され、次の情報を含む。ＧＲＵＵ、加入者識別、端末識別、加入者の位置、ネットワークＩＤ情報（例、ＳＳＩＤおよび／またはＣＧＩ）、ＣＳ接続ステータス、およびＷＬＡＮ／ＩＭＳステータス。

プレゼンスベースのメッセージングを経たＣＳドメインステータス変更の伝送の制御と同様に、ＷＬＡＮ／ＩＭＳステータス変更は、図１６に示されるように、プレゼンス使用可能なプロシージャを経てＮｅＤＳ機能に通知することもできる。参照番号１６０２は、ＳＩＰサブスクライブメッセージを指し、これによって、ＮｅＤＳ２００は、ＵＥデバイスによって発生された応答メッセージ（例、ＳＩＰノーティファイ）を経て、ＷＬＡＮ／ＩＭＳステータス変更が生じたときに、これらの変更を受信することができる。さらに、別の実施形態では、ＵＥデバイスは、図１７に示されるような、ＣＳシグナリングを経てＷＬＡＮ／ＩＭＳステータス変更を提供するロジックも含むことができ、参照番号１７０２は、ＷＬＡＮ／ＩＭＳドメインへの適切な更新を含む、（例えば、ＵＳＳＤなどを使用した）更新メッセージを指す。その上、ＳＩＰメッセージング（すなわち、ノーティファイまたはパブリッシュ）が使用されているか、ＵＳＳＤメッセージングが使用されているかに関わらず、次のような更なる情報を更新メッセージに含めることができる。ＧＲＵＵ、加入者識別、端末識別、加入者の位置、ネットワークＩＤ情報（例、ＳＳＩＤおよび／またはＣＧＩ）、およびＷＬＡＮ／ＩＭＳステータス。

図１８は、本特許開示のための、デュアルドメイン能力（すなわちＣＳドメインおよびＩＭＳドメイン）を有する動作可能な無線ＵＥデバイス（例、ＵＥ５１０）として動作可能な通信デバイスの一実施形態のブロック図である。当業者は、ＵＥ５１０の一実施形態は、図１８に示されるものに類似した機構を含む場合があるが、示された種々のモジュールに関して、ハードウェア、ソフトウェア、またはファームウェアに複数のバリエーションおよび改良があり得ることを、本願明細書を参照することで認識されよう。さらに、ＵＥデバイスは、モバイル機器（ＭＥ）と、上記詳述した種々の情報を有する着脱可能なストレージモジュールとの組み合わせとして扱われる場合がある。したがって、図１８の機構は、本特許開示の実施形態に関して、これを制限するものではなく、例示的なものであると考えられたい。ＵＥ５１０の実施形態の全体的な制御を提供するマイクロプロセッサ１８０２は、マルチモード通信（例、ＣＳドメイン、ＩＭＳ／ＷＬＡＮ／Ｗｉ−ＭＡＸのようなＩＰドメインなど）が行える通信サブシステム１８０４に動作可能に接続される。通信サブシステム１８０４は、一般的に、１つ以上の受信器１８０８と、１つ以上の送信器１８１４、ならびに、１つ以上のローカル発振器（ＬＯ）モジュール１８１０のような関連する構成要素と、デジタル信号処理器（ＤＳＰ）１８１２のような処理モジュールとを含む。通信分野の当業者には明らかであるように、通信モジュール１８０４の特定のデザインは、モバイルデバイスの動作を目的とする通信ネットワーク（例、ＣＤＭＡネットワーク、ＧＳＭネットワーク、ＷＬＡＮなど）に依存する。しかし、特定のデザインに関わらず、適切なアクセスインターフェース１８０５（例、携帯電話の基地局のタワー、ＷＬＡＮのホットスポットなど）を介して、アンテナ１８０６によって受信した信号は、受信器１８０８に提供され、信号増幅、周波数ダウン変換、フィルタリング、チャネル選択、アナログ−デジタル（Ａ／Ｄ）変換、などのような共通する受信器の機能を実行することができる。同様に、送信すべき信号は、例えば、ＤＳＰ１８１２によって、変調および符号化を含む処理が行われ、デジタル−アナログ（Ｄ／Ａ）変換、周波数アップ変換、フィルタリング、増幅、およびアンテナ１８１６を経て無線インターフェースを通じた送信のために、送信器１８１４に提供される。

マイクロプロセッサ１８０２は、補助入出力（Ｉ／Ｏ）１８１８、シリアルポート１８２０、ディスプレイ１８２２、キーボード／キーパッド１８２４、スピーカ１８２６、マイクロホン１８２８、ランダムアクセスメモリ（ＲＡＭ）１８３０、短距離通信サブシステム１８３２などのデバイスサブシステム、および他のデバイスサブシステム（例えば、通常は参照符号１８３３で表記される、上述のタイマ機構）ともインターフェースすることができる。データのアクセスを制御し、そのストレージを提供するために、加入者識別モジュール（ＳＩＭ）または着脱可能なユーザ識別モジュール（ＲＵＩＭ）、あるいはＵＩＣＣインターフェース１８３４を、マイクロプロセッサ１８０２と通信するように提供することもできる。一実装例では、ＳＩＭ／ＲＵＩＭ／ＵＩＣＣインターフェース１８３４は、複数のキー構成１８４４と、ユーザポリシー／プレファレンス、タイマ期間などのような識別および加入関連のデータなどの他の情報１８４６とを有する、ＳＩＭ／ＲＵＩＭ／ＵＩＣＣカードによって動作可能である。

オペレーティングシステムソフトウェアおよび適用可能なサービスロジックソフトウェアは、フラッシュメモリ１８３５のような永続格納モジュール（すなわち不揮発性ストレージ）内に組み込むことができる。一実装例では、フラッシュメモリ１８３５は、例えば、コンピュータプログラム１８３６（例、サービス処理ロジック）のための格納領域、およびデバイス状態１８３７、アドレスブック１８３９、他のパーソナルインフォメーションマネージャ（ＰＩＭ）データ１８４１のようなデータストレージ領域と、通常は参照符号１８４３で表記される他のデータストレージ領域との異なる領域に分けることができる。トランスポートスタック１８４５を提供して、１つ以上の適切な無線パケットトランスポートプロトコルを達成することができる。加えて、プレゼンスエージェント、更新ロジックモジュール１８４８が、上記に詳述したＵＥデバイス機能を達成するために提供される。基本的に、ロジックモジュール１８４８は、（ｉ）ＮｅＤＳ（ＣＳまたはＩＭＳ）への登録、（ｉｉ）ドメインのＮｅＤＳへの、ＵＥデバイスが現在登録されていることの通知、（ｉｉｉ）登録されたドメイン内のＵＥデバイスの状態の識別、（ｉｖ）ＵＥデバイスに関連する位置情報の識別（ＩＭＳサービスを行うべきかどうかを容易にする）、および（ｖ）プレゼンスおよび／またはタイマ機構に基づいた、ステータスの更新のＮｅＤＳへの提供、を容易にするように、他の構造とともに動作可能である。

上記の詳細な説明に基づいて、登録メッセージング、最初の位置更新、および以降の更新情報を受信したときのＮｅＤＳの動作をさらに以下に詳述する。ＣＳシグナリングを経た登録に関して、ＮｅＤＳは、メッセージ文字列のコンテンツを調査し、ＧＲＵＵが含まれていたかどうかを決定するように動作可能である。いかなるＧＲＵＵも受信しなかった場合、ＮｅＤＳ機能は、加入者ＩＤおよび機器ＩＤを使用してＧＲＵＵを発生させるように動作可能である。構成されたＧＲＵＵは、インデクサとして動作可能であり、ＮｅＤＳ機能で受信した情報を格納する。結果として生じたＧＲＵＵレコードは、図６Ａにおいて確認された状態のうちの１つとなるようにマーキングされる。初期登録の場合、有効な状態は、（ｉ）ＣＳに接続／アイドル（状態６１８）、または（ｉｉ）ＣＳに接続／アイドルおよびＩＭＳに登録／アイドル（状態６０４）となり得る。一方では、ＧＲＵＵがＵＥデバイスから得られた場合、ＮｅＤＳ機能は、受信したＧＲＵＵに対してレコードがすでに存在しているかどうかを決定するように動作可能である。その場合、ＧＲＵＵレコードは、提供された情報に基づいて更新される。レコードが存在しない場合、受信したＧＲＵＵおよび関連する情報に基づいて、新たなＧＲＵＵレコードが生成される。

別様には、ＧＲＵＵ能力がＵＥデバイスによってサポートされていない場合、ＮｅＤＳは、ＩＭＳＩ、ＭＩＮ、ＰＩＮなどとなり得るプライベートユーザ識別（Ｐｒｉｖａｔｅ Ｕｓｅｒ Ｉｄｅｎｔｉｔｙ：ＰＵＩ）に基づいて、レコードを発生するように動作可能である。この場合、ＰＵＩ／ＩＭＳＩは、ＮｅＤＳ内のレコードのインデックス作成に使用することができる。さらに、上述したように、ＮｅＤＳ機能は、ＵＥデバイスの位置を調査し、ＩＭＳサービス（例、ＶＣＣ）を提供すべきかどうかを決定するロジックを含むことができる。関連する実装では、ＩＭＳサービスを行うべきではない場合、ＮｅＤＳ機能は、（例えば図１０に示されるように）ＣＡＭＥＬが配置されていた場合に、ＨＳＳにおいてあらゆるＣＡＭＥＬトリガを停止させるということを、ＨＳＳ要素に通知するロジックを含む。関連して、ＮｅＤＳ機能は（例えば、ＵＥデバイスへの応答メッセージ内に、ＩＭＳサービスフラグを提供または設定することによって）ＩＭＳサービスが実行されないということをＵＥデバイスに通知することもできる。一方で、ＩＭＳサービスを実行すべき場合は、ＮｅＤＳ機能は、ＵＥの位置を調査して、リクエストされたＩＭＳサービスをサポートするネットワーク内にＵＥがあるかどうかを決定するように動作可能である。ネットワークがＩＭＳサービスをサポートしていない場合、ＮｅＤＳ機能は、ＩＭＳサービスをサポートする別のネットワークに切り替えることをＵＥデバイスに通知することができる。上述したように、１つ以上のＰＬＭＮコードを、ＩＭＳサービス（すなわちネットワークリダイレクション）をサポートできるものと識別されたＵＥデバイスに提供することができる。実装として、ＮｅＤＳ機能は、ＵＥデバイスによって提供されたネットワークＩＤデータを使用して、内部または外部データベースを参照して、どのネットワークがＩＭＳサービスをサポートしているのかを決定することができる。

加えて、ＮｅＤＳ機能は、好適なメッセージを経て、ＵＥデバイスが、ＣＳドメイン内で利用可能であることをどのくらいの頻度で通知する必要があるのかをＵＥデバイスに通知する能力も含み、その通知は、ＵＥの応答にＣＳ位置更新タイマを提供することによって実装することができる。ＮｅＤＳ機能は、このメッセージをＵＥデバイスに送信すると、その更新タイマを初期化することができる。デフォルトの実装として、ＮｅＤＳ位置更新タイマは、ＣＳ位置更新タイマと同じ場合がある。さらに、ＮｅＤＳ機能は、上述のように、適切なインターフェースを経て、規定されたプロトコルを使用して、プレゼンスサーバからプレゼンス情報をリクエストする能力を含むことが好ましい場合がある。その上、ＮｅＤＳ機能は、例えばＣＳまたはＷＬＡＮを喪失した、などのあらゆるプレゼンス情報が必要であるかどうかを、応答／リクエストメッセージ構造の範囲内の適切なフラグを経由して、ＵＥデバイスに通知することも必要な場合がある。

ＩＭＳ登録に関して、ほぼ同じ動作を、ＮｅＤＳ機能に同様にエンジニアリングすることができる。上述したように、ＮｅＤＳ機能は、ＳＩＰオプションメッセージをＵＥデバイスに送信する能力を含むこともできる（図９に示す）。ＵＥデバイスから、ＩＭＳサービスをサポートできないという応答があった場合、２つの例示的な実装を提供することができる。一実装例では、ＮｅＤＳ要素は、あらゆるＣＡＭＥＬトリガを停止させるようにＨＳＳノードに通知することができ、これは上述のＣＳ登録動作に類似する。別様には、ＮｅＤＳ要素は、この特定の加入者／ＵＥの組み合わせに対して、ＩＭＳサービスが利用できないことを記録することができる。したがって、初期ＤＰをＭＳＣから受信したときには、モバイル発信のコールに対して、入力コールパーティ番号を、発信コールに使用する番号としてＭＳＣに返すことができる。さらに、ＵＳＳＤメッセージを使用する場合、元の入力コールパーティ番号は、設定に称する番号として返すことができる。

ＩＭＳ登録プロシージャの一部としてＳＩＰパブリッシュまたはＸＣＡＰメッセージングを受信すると、ＮｅＤＳ機能は、上述したＣＳ登録動作とほぼ同じように、その中のコンテンツを調査し、また、ＧＲＵＵが提供されたかどうかに基づいて、適切なレコードを構成するように動作可能である。また、ＮｅＤＳは、内部／外部データベースを使用した位置情報に基づいて、ＩＭＳサービスを提供すべきかどうかを決定することができ、また、このような決定に基づいて、ＮｅＤＳは、ＣＡＭＥＬが配置された範囲で、ＨＳＳ内の適切なＣＡＭＥＬトリガを停止させることができる。ＣＳ登録動作に類似して、他のネットワークへのリダイレクションも、この場合は可能となり得る。

最初の位置更新に関して、ＮｅＤＳ機能は、ＰＳの接続および関連する一更新が行われた旨の通知を、ＨＳＳまたはプレゼンティティプレゼンスプロキシサーバから受信するように動作可能である。それに応答して、ＮｅＤＳ機能は、タイマを開始して、（ＣＳ側の）ＵＳＳＤを使用するか、または（図９に示されるように、ＩＭＳ側の）第三者登録を使用して、ＵＥからの登録を予測するように動作可能である。これらの２つの登録イベントのうちのいずれかが行われた場合、タイマを停止することができる。一方で、登録が無いままタイマが終了した場合、ＵＥデバイスはＩＭＳサービスに対応していないものとみなすことができる。ＩＭＳサービスがサポートされていない状況に関して提供された処理に類似して、モバイル発信のコールに対して初期ＤＰをＭＳＣから受信したとき、モバイル発信のコールに対しては、入力コールパーティ番号を、発信コールに使用する番号としてＭＳＣに返すことができる。

ＵＥデバイスからの定期的な更新の受信に関して、ＮｅＤＳ機能は、（例えば、ＣＳドメイン内のＵＳＳＤまたはＳＭを経て、またはＩＭＳドメイン内のＳＩＰパブリッシュを経て）適用可能な更新メッセージを調査し、それに応じて、その加入者／ＵＥレコードおよび／または状態を更新するように動作可能である。ＮｅＤＳは、上述のように、ＧＲＵＵのインデックス作成、またはＰＵＩのインデックス作成によって、内部レコードを相関させるように動作可能であることが好ましい。ＣＳステータス変更を受信すると、ＮｅＤＳ機能は、特定のＧＲＵＵまたはＰＵＩ／ＩＭＳＩに関連する状態モデル情報を更新するように動作可能である。図６Ａに示される状態遷移モデルに基づいて、ＣＳステータスが「分離」である場合、有効な状態は、ＩＭＳに登録／アイドル（状態６０８）、またはＩＭＳに登録／アクティブ（状態６１０）のみとなり得る。同様に、ＣＳステータスが「接続」の場合、有効な状態は、ＣＳに接続／アイドル（状態６１８）、ＣＳに接続／アイドルおよびＩＭＳに登録／アイドル（状態６０４）、またはＣＳに接続／アイドルおよびＩＭＳに登録／アイドル（状態６０６）となり得る。

同様に、ＮｅＤＳ機能が、ＩＭＳ／ＷＬＡＮステータス変更を受信した場合、それに関連する状態エンジンは、ＧＲＵＵまたはＰＵＩ／ＩＭＳＩに基づいて、それに応じて適用可能な状態モデル情報も更新するように動作可能である。ＩＭＳステータスが「ローカルＩＰ割り当て」または「関連」である場合、有効なステータスは、ＣＳに接続／アイドル（状態６１８）またはＣＳに接続／アクティブ（状態６１６）となり得る。ＩＭＳステータスが「ＰＤＦと接触」の場合、有効な状態は、ＩＭＳに登録／アイドル（状態６０８）、ＣＳに接続／アイドルおよびＩＭＳに登録／アイドル（状態６０４）、またはＣＳに接続／アクティブおよびＩＭＳに登録／アイドル（状態６１２）となり得る。

本特許出願書の実施形態の動作および構成は、上述の詳細な説明から明らかになるものと考えられる。ここに示し説明した例示的な実施形態は、好適なものとして位置付けられているが、以下の特許請求の範囲に定義される本開示の範囲から逸脱することなく、種々の変更および修正を行うことができることが容易に理解されよう。

図１は、本特許開示の一実施形態が実行され得る、回路交換（ＣＳ）ネットワークインフラストラクチャおよびＩＰマルチメディアサブシステム（ＩＭＳ）インフラストラクチャを含むネットワーク環境を描く。 図２は、本特許開示のためのドメイン選択を達成するように動作可能なネットワーク要素の一実施形態を示す。 図３は、入力コールをルーティングするための、本特許開示の一実施形態のフロー図を描く。 図４は、一実施形態による、ＵＥデバイスと、関連するＮｅＤＳ要素との間の全体的な相互作用のモデルに関するフロー図である。 図５は、一実施形態による、ＮｅＤＳ要素を備えた複数のインターフェースを示す機能ブロック図を描く。 図６Ａは、ＵＥデバイスの状態遷移を保持するＮｅＤＳ要素を備えた、状態遷移エンジンの一実施形態を描く。 図６Ｂは、本特許開示のためのポリシー／プレファレンススキーマを示す。 図７は、本開示の一実施形態による、ＮｅＤＳ要素においてユーザポリシー／プレファレンス設定を達成するためのメッセージフロー図である。 図８は、一実施形態における、ＮｅＤＳ要素による初期登録に関連するメッセージフロー図である。 図９は、別の実施形態における、ＮｅＤＳ要素による初期登録に関連するメッセージフロー図である。 図１０は、一実施形態による、ＮｅＤＳ要素によるトリガの無効化に関連するメッセージフロー図である。 図１１は、一実施形態における、ＮｅＤＳ要素による一般化された登録プロセスに関連するメッセージフロー図である。 図１２は、非構造化付加サービスデータ（ＵＳＳＤ）のメッセージングを使用した、ＮｅＤＳ要素による一般化された登録プロセスに関連するメッセージフロー図である。 図１３は、非構造化付加サービスデータ（ＵＳＳＤ）のメッセージングを使用した、ＮｅＤＳ要素による一般化された登録プロセスに関連するメッセージフロー図である。 図１４は、一実施形態における、ＵＥデバイスの状態変更に関する、ＵＥデバイスと関連するＮｅＤＳ要素との間のメッセージングに関連するメッセージフロー図である。 図１５は、ＵＥデバイスによる回路交換（ＣＳ）ドメインの発見に関する、ＵＥデバイスと関連するＮｅＤＳ要素との間のメッセージングに関連するメッセージフロー図である。 図１６は、別の実施形態における、ＵＥデバイスの状態変更に関する、ＵＥデバイスと関連するＮｅＤＳ要素との間のメッセージングに関連するメッセージフロー図である。 図１７は、さらなる実施形態における、ＵＥデバイスの状態変更に関する、ＵＥデバイスと関連するＮｅＤＳ要素との間のメッセージングに関連するメッセージフロー図である。 図１８は、本特許開示のための動作可能な通信デバイスの一実施形態のブロック図である。

Claims (22)

1. インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）ネットワーク内で動作可能なネットワークノードであって、該ネットワークノードは、
   該ネットワークノードによって提供されるように動作可能である、加入者に関するポリシー基準を保持するための手段と、
   該加入者に向けられた入力コールのルーティングに関して適切なネットワークドメインを選択するための手段であって、該選択することは該ポリシー基準の少なくとも一部に基づく、手段と
   を含む、ネットワークノード。
2. 前記ポリシー基準のうちの少なくとも一部は、回路交換（ＣＳ）シグナリングによって動作可能なユーザ機器（ＵＥ）デバイスを用いる前記加入者によって設定されるように動作可能である、請求項１に記載のネットワークノード。
3. 前記ポリシー基準のうちの少なくとも一部は、ＩＭＳシグナリングによって動作可能なＵＥデバイスを用いる前記加入者によって設定されるように動作可能である、請求項１に記載のネットワークノード。
4. 前記ポリシー基準のうちの少なくとも一部は、オペレータベースのポリシーを含む、請求項１に記載のネットワークノード。
5. 前記オペレータベースのポリシーは、ＩＭＳドメインにおいて発せられたコールの終了に関する、請求項４に記載のネットワークノード。
6. 前記オペレータベースのポリシーは、ＣＳドメインにおいて発せられたコールの終了に関する、請求項４に記載のネットワークノード。
7. 前記ポリシー基準のうちの少なくとも一部は、ユーザベースのポリシーを含む、請求項１に記載のネットワークノード。
8. 前記ユーザベースのポリシーは、ＩＭＳドメインにおいて発せられたコールの終了に関する、請求項７に記載のネットワークノード。
9. 前記ユーザベースのポリシーは、ＣＳドメインにおいて発せられたコールの終了に関する、請求項７に記載のネットワークノード。
10. 前記ポリシー基準のうちの少なくとも一部は、コール回線識別（ＣＬＩ）情報に基づく、請求項１に記載のネットワークノード。
11. 前記入力コールのルーティングに対して適用されるとき、２つ以上のポリシー間の競合を解決するための手段をさらに含む、請求項１に記載のネットワークノード。
12. 回路交換（ＣＳ）ネットワークおよびインターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）を含むネットワーク環境において動作可能なドメイン選択方法であって、
    ネットワークノードによって提供されるように動作可能である、加入者に関するポリシー基準を保持することと、
    該加入者に向けられる入力コールのルーティングに関して適切なネットワークドメインを選択することであって、該選択することは、該ポリシー基準のうちの少なくとも一部に基づく、ことと
    を含む、方法。
13. 前記ポリシー基準のうちの少なくとも一部は、ＣＳシグナリングによって動作可能なユーザ機器（ＵＥ）デバイスを用いる前記加入者によって設定されるように動作可能である、請求項１２に記載のドメイン選択方法。
14. 前記ポリシー基準のうちの少なくとも一部は、ＩＭＳシグナリングによって動作可能なＵＥデバイスを用いる前記加入者によって設定されるように動作可能である、請求項１２に記載のドメイン選択方法。
15. 前記ポリシー基準のうちの少なくとも一部は、オペレータベースのポリシーを含む、請求項１２に記載のドメイン選択方法。
16. 前記オペレータベースのポリシーは、ＩＭＳドメインにおいて発せられたコールの終了に関する、請求項１５に記載のドメイン選択方法。
17. 前記オペレータベースのポリシーは、ＣＳドメインにおいて発せられたコールの終了に関する、請求項１５に記載のドメイン選択方法。
18. 前記ポリシー基準のうちの少なくとも一部は、ユーザベースのポリシーを含む、請求項１２に記載のドメイン選択方法。
19. 前記ユーザベースのポリシーは、ＩＭＳドメインにおいて発せられたコールの終了に関する、請求項１８に記載のドメイン選択方法。
20. 前記ユーザベースのポリシーは、ＣＳドメインにおいて発せられたコールの終了に関する、請求項１８に記載のドメイン選択方法。
21. 前記ポリシー基準のうちの少なくとも一部は、コール回線識別（ＣＬＩ）情報に基づく、請求項１２に記載のドメイン選択方法。
22. 前記入力コールのルーティングに対して適用されるとき、２つ以上のポリシー間の競合を解決することをさらに含む、請求項１２に記載のドメイン選択方法。

Images