JP2012532504A - 進化型パケットシステムのボイスサービスインジケータに基づいてボイスサービスにアクセスするシステムおよび方法 - Google Patents

Abstract

通信システムにおいて、ユーザ機器（ＵＥ）を使用してボイスサービスにアクセスするシステムおよび方法が提供される。ＵＥは、オーディオセッション表示を含み得る第１のメッセージを受信するように構成される。方法は、第１のメッセージに応答して第２のメッセージを送信するステップを含み、第２のメッセージは、少なくとも１つの値を備える１つ以上のボイスサービスインジケータに基づいている。第２のメッセージは、代替ドメインを選択しないことを示す応答であってもよい。第２のメッセージはまた、受取り不可能な応答であってもよい。
【選択図】図１

Description

（技術の分野）
本開示は、概して、通信システムにおいてユーザ機器（ＵＥ）を使用してボイスサービスにアクセスする方法に関し、より具体的には、インターネットプロトコルマルチメディアサブシステム（ＩＭＳ）においてボイスサービスを提供する方法、および対応するネットワーク要素に関する。

本明細書で使用されるように、用語「デバイス」は、用語「移動局」（ＭＳ）、「ユーザエージェント」、または「ユーザ機器」（ＵＥ）を指し、固定および携帯電話、携帯端末、ハンドヘルドまたはラップトップコンピュータ、スマートフォン、プリンタ、ファックス機器、テレビ、セットトップボックス、ならびに他のビデオディスプレイデバイス等の電子デバイス、家庭用オーディオ機器および他の家庭用娯楽システム、家庭用監視および制御システム（例えば、家庭用監視、アラームシステム、および温度調節システム）、コンピュータ制御式冷蔵庫等の進化型家庭用器具、ならびにネットワーク通信能力を有する類似デバイスを含むことが可能である。いくつかの構成において、ＵＥは、移動無線デバイスと称されてもよい。

ＵＥはまた、デスクトップコンピュータ、セットトップボックス、ＴＶ、ＩＰＴＶ、またはネットワークノード等、類似能力を有するが、容易に搬送可能ではないデバイスを指してもよい。

用語「デバイス」はまた、固定または移動式であることが可能なセッション開始プロトコル（ＳＩＰ）ユーザエージェント（ＵＡ）を指してもよい。ＵＡがネットワークノードである時、ネットワークノードは、ＵＡまたは固定回線デバイス等の別の機能に代わって作用し、ＵＡまたは固定回線デバイスをシミュレートあるいはエミュレートしてもよい。例えば、いくつかのＵＡの場合、一般的には、デバイス上に常駐するインターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）ＳＩＰクライアントは、実際にネットワーク内に常駐し、最適化されたプロトコルを使用して、デバイスにＳＩＰメッセージ情報を中継する。換言すると、従来、ＵＡによって実行されていたいくつかの機能は、遠隔ＵＡの形態で分散することが可能であって、その場合、遠隔ＵＡは、ネットワーク内のＵＡを表す。

用語「ＵＥ」はまた、ＳＩＰセッションを含み得るが、それに限定されない、通信セッションを着信可能な任意のハードウェアまたはソフトウェア構成要素も指すことも可能である。また、用語「ユーザエージェント」、「ＵＡ」、「ユーザ機器、「ＵＥ」、および「ノード」は、本明細書では、同義的に使用される場合がある。当業者は、これらの用語が、本願において、互換可能に使用可能であることを理解するであろう。

ＵＥは、種々のネットワーク構成および／または無線アクセス技術（ＲＡＴ）を使用して、高速データ通信を提供する無線通信ネットワーク内で動作してもよい。例えば、ＵＥは、移動通信用グローバルシステム（ＧＳＭ（登録商標））および汎用パケット無線サービス（ＧＰＲＳ）技術に従って動作してもよい。今日、そのようなＵＥはさらに、ＧＳＭ（登録商標）進化型高速データレート（ＥＤＧＥ）、あるいは拡張型ＧＰＲＳ（ＥＧＰＲＳ）または拡張型ＧＰＲＳ Ｐｈａｓｅ ２（ＥＧＰＲＳ２）に従って動作してもよい。ＵＥが動作し得る他の無線ネットワークは、ＣＤＭＡ、ＵＭＴＳ、Ｅ−ＵＴＲＡＮ、ＷｉＭａｘ、およびＷＬＡＮ（例えば、ＩＥＥＥ ８０２．１１）を含むが、それらに限定されない。ＵＥはまた、ｘＤＳＬ、ＤＯＣＳＩＳケーブルネットワーク、イーサネット（登録商標）、または光ネットワーク等、固定ネットワーク環境内で動作してもよい。いくつかのＵＥは、多モード動作可能であってもよく、その場合、一度に、単一アクセスネットワーク技術に基づいて、または多重アクセスネットワーク技術を同時に使用して、いくつかのデバイス内においてのいずれかとして、２つ以上のアクセスネットワーク技術に基づいて動作可能である。

無線電気通信システムにおいて、基地局内の伝送機器は、セルとして周知の地理的な領域内全体に信号を伝送する。技術が進化するに伴って、以前では不可能であったサービスを提供可能な、より高度なネットワークアクセス機器が導入されるようになった。この高度機器は、例えば、基地局ではなく、拡張型ユニバーサル地上無線アクセスネットワーク（Ｅ−ＵＴＲＡＮ）ノードＢ（ｅＮＢ）、または従来の無線電気通信システムにおける同等機器よりも高度に進化した他のシステムおよびデバイスを含む場合がある。そのような高度なまたは次世代機器は、本明細書では、ロングタームエボリューション（ＬＴＥ）機器と称されてもよく、また、そのような機器を使用するパケットベースのネットワークは、進化型パケットシステム（ＥＰＳ）と称することも可能である。本明細書で使用されるように、用語「アクセスデバイス」は、ＵＥに、電気通信システム内の他の構成要素へのアクセスを提供することが可能である、従来の基地局、ｅＮＢ、または他のＬＴＥアクセスデバイス等の任意の構成要素を指してもよい。

第３世代移動体通信システムの標準化プロジェクト（３ＧＰＰ）システムにおいて、ボイスサービスは、一連の手段を経由して、移動オペレータによって提供可能である。ＧＰＲＳ／ＥＤＧＥ無線アクセスネットワーク（ＧＥＲＡＮ）およびユニバーサル地上無線アクセスネットワーク（ＵＴＲＡＮ）を介して、例えば、回路交換（ＣＳ）インフラストラクチャを使用して、ボイスサービスを提供してもよい。代替として、ＧＥＲＡＮおよびＵＴＲＡＮを介して、ＩＭＳ−またはＩＰコアネットワーク（ＣＮ）マルチメディアサブシステムを使用可能である。その場合、ＩＭＳを使用するボイスオーバＩＰまたはボイス通信は、ＩＭＳボイスオーバＰＳと称されてもよい。さらに、ＣＳを使用することにより、ボイスベアラを提供し、ＩＭＳを使用して、ボイスベアラを制御するハイブリッドソリューションにもまた、対応可能であって、これは、ＩＭＳ集中型サービス（ＩＣＳ）として知られており、３ＧＰＰ ＴＳ ２３．２９２および３ＧＰＰ ＴＳ ２４．２９２に定義されている。（Ｅ−ＵＴＲＡＮ）を介して、ＩＭＳを使用してもよい。ある場合には、ＬＴＥネットワークを介したボイスサービス（すなわち、アクティブに接続されたＵＥによって、ＬＴＥネットワークを介してデータを交換する）は、ＩＭＳを使用して提供されてもよい。

種々のボイスサービスインジケータ（ＶＳＩ）は、どの状況下において、特定のネットワーク、ネットワークエリア、またはネットワークセルが、ボイスサービスを提供し得るかを示すように規定されている。インジケータは、以下の値を含む：「ＩＭＳボイスオーバＰＳセッション対応」（すなわち、ＶｏＩＭＳインジケータ）、「ボイス中心」または「データ中心」、および「ＣＳボイス専用」、「ＩＭＳ ＰＳボイス専用」、「ＣＳボイス優先、ＩＭＳボイス二次優先」、あるいは「ＩＭＳボイス優先、ＣＳボイス二次優先」。ＶｏＩＭＳインジケータは、「ボイス中心」または「データ中心」インジケータがＵＥ内にある間、各ＮＡＳ登録（例えば、ＥＰＳアタッチ）およびＮＡＳ登録アップデートにおいて、ネットワークによって、ＵＥに提供されてもよい。ある場合には、「ＩＭＳボイスオーバＰＳセッション対応」インジケータの不在は、ネットワーク（例えば、ｅＮｏｄｅＢ）が、ボイスのために最適化されていないことを示唆し得る。しかしながら、ある場合には、ボイスは、好ましくあり得ないにもかかわらず、依然として、対応され得る。選好は、オペレータ選好、ユーザ選好、加入者選好、またはそれらの組み合わせとして規定され得る。ユーザ、加入者（例えば、企業）、および／またはオペレータは、選好を管理可能である。選好は、アクセスネットワーク毎に適用可能であって、例えば、ＷＩＭＡＸまたはＩＥＥＥ ８０２．１１ベースのアクセスネットワーク等、別のアクセスネットワークと比較して、異なる選好が、Ｅ−ＵＴＲＡＮのために存在してもよい。そのような選好は、ＵＥに対応する各アクセスネットワークと関連付けられなくてもよい。オペレータのネットワーク要素は、ボイス呼が、好ましい代替が存在する場合、あまり好ましくないアクセスネットワークを使用して、配信または着信されないように、選好を把握していてもよい。

本開示では、ＶＳＩは、上述の「ＩＭＳボイスオーバＰＳセッション対応」表示に匹敵するネットワーク提供ＶｏＩＭＳインジケータ（または、ＩＭＳボイスオーバＰＳ（ＩＭＳＶｏＰＳ）インジケータ）を含むいくつかの様式において、分類されてもよく、ＵＥの使用設定は、上述の「ボイス中心」または「データ中心」ＶＳＩと同一であってもよい。ボイス中心ＵＥは、ボイスサービスを使用可能であってもよく、したがって、どのようにサービスが提供され得るかに関わらず、ボイスサービスを取得するよう試みてもよい。対照的に、データ中心ＵＥは、ボイスサービスが利用可能ではない時でも、最も可能性のあるＰＳ（パケット交換）サービスを有することを優先してもよい。例えば、データ中心ＵＥは、ボイスサービスが、Ｅ−ＵＴＲＡＮ上で利用可能ではないときでも、Ｅ−ＵＴＲＡＮ内に留まることを優先してもよい。ボイスサービスは、オペレータのサービスシナリオに応じて、データ中心ＵＥのために提供されてもよい。最後に、ＵＥのボイス設定は、上述の「ＣＳボイス専用」、「ＩＭＳ ＰＳボイス専用」、「ＣＳボイス優先、ＩＭＳボイス二次優先」、または「ＩＭＳボイス優先、ＣＳボイス二次優先」ＶＳＩと同一であってもよい。以下の表１は、これらの群および名称の定義を要約したものである。

無線通信ネットワークが継続して進化することに伴って、いくつかのネットワーク実装では、ＧＥＲＡＮおよび／またはＵＴＲＡＮによって提供される、より完全な無線範囲内に常駐するＬＴＥ型ネットワークの範囲の島が存在するようになるであろう。したがって、ボイスサービスをＬＴＥネットワークに接続されたＵＥに配信するための種々の機構が、規定されている。例えば、ＣＳフォールバックプロシージャによって、ＵＥは、第１のＲＡＴを使用して、ネットワークに接続可能となり、ＲＡＴは、ＰＳ（パケット交換）ドメインサービスのみを提供し、また、同時に、ＣＳドメインサービスを提供する別のネットワークに登録する。ＣＳフォールバックを使用して、例えば、ＣＳドメインサービスを提供するネットワークのセルに移動し、ボイス呼を開始する際、ＵＥが、ＰＳドメインサービスのみを提供する（すなわち、ＣＳドメインサービスを提供しない）ネットワークのセルに関連付けられたときにボイス呼を開始するように、ＵＥをトリガしてもよい。ボイス呼を開始するＵＥは、ＰＳドメインサービスのみを提供するネットワークのセル上において、アイドルまたはアクティブのいずれかであってもよい。用語「登録」は、本書では、２つの目的のために使用されている：（１）ＳＩＰ ＵＡをＳＩＰレジストラに登録する作用を説明するためと、（２）下位層への登録の作用を説明するため。ＳＩＰでは、ＵＡが登録されると、一般的には、ＳＩＰ登録要求がＵＡによって伝送され、ＳＩＰ２００（ＯＫ）応答が、ＵＡによって受信される。代替として、ＵＡは、他の手段を経由して、登録されてもよい。本書では、我々は、ＵＡが、機能的要素のＩＭＳノードであるノードまたは機能的要素上において、レジストラ機能に登録される場合、用語「ＩＭＳ登録」を使用する。一般的には、Ｓ−ＣＳＣＦは、ＩＭＳにおいて、レジストラの役割を果たす。下位層では、例えば、ＮＡＳまたはアクセス階層では、ＵＥは、ネットワークに登録し、ＵＴＲＡＮまたはＧＥＲＡＮを介して、ＧＰＲＳネットワークに対して、アタッチプロシージャを行うか、あるいはＬＴＥまたはＥ−ＵＴＲＡＮを介して、ＥＰＣとアタッチを行うことのいずれかによって、接続を取得する。ＮＡＳ層における登録はまた、ルーティングエリアアップデート、追跡エリアアップデート（ＴＡＵ）、ＮＡＳ複合アタッチ、および複合ＴＡＵの概念を指してもよい。これは、本書を通して、「登録」が適用される文脈から明白となるはずである。

具体的には、オペレータが、ＬＴＥを徐々に配備し、配備されたＩＭＳを有しない場合、ＣＳフォールバックプロシージャによって、ＵＥは、以下が可能となる：移動性の場合、初期アタッチまたは複合追跡エリアアップデートプロシージャにおいて、複合アタッチプロシージャを行うことによって、ＰＳコアネットワーク（すなわち、３ＧＰＰ進化型パケットコア（ＥＰＣ）およびＣＳドメイン（すなわち、移動通信交換局（ＭＳＣ）に同時にアタッチする；ＬＴＥを介して、データサービスを交換する一方、着信ＣＳ呼通知を受信し、別のＲＡＴ（ＧＥＲＡＮまたはＵＴＲＡＮ）へのハンドオーバを行い、ＣＳドメインを使用して、ＣＳ呼の確立を継続するように、ＵＥをトリガ可能である；ＬＴＥを介して、データサービスを交換する一方、別のＲＡＴ（ＧＥＲＡＮまたはＵＴＲＡＮ）へハンドオーバし、ＣＳドメインを使用してＣＳ呼の確立を行うことによって、発信ＣＳ呼を確立可能である。

ＵＥは、ＬＴＥを介したいくつかの方法において、ボイスサービスに対応するように構成されてもよい。例えば、ＵＥは、ネットワークオペレータ（例えば、Ｓｋｙｐｅ）、ＣＳフォールバック、ＩＭＳ、または汎用アクセス経由ボイスオーバＬＴＥ（ＶｏＬＧＡ）によって提供されないボイスオーバＩＰソリューションに対応してもよい。上述のように、特定のＬＴＥ（例えば、ＶｏＩＭＳ、ＳＲＶＣＣ）を介して、ＩＭＳが利用可能か否かを規定するためのいくつかのメッセージタグが存在する。さらに、ＵＥは、所定の論理ツリーに基づいて、初期または優先ボイスソリューションを選択するように構成されてもよい。初期ボイスソリューションが利用可能ではない場合、ＵＥは、所定の論理ツリーに基づいて反応するように構成されてもよい。

モバイル着信セッションが、ＩＭＳネットワーク（例えば、ＩＭＳアプリケーションサーバ（ＡＳ）のようなノードを含む）に提示されると、ノードは、呼配信のための標的ドメイン（すなわち、ＣＳドメインまたはＰＳドメイン）を選択する方法を決定する。標的ドメインは、ＬＴＥネットワークまたはＥ−ＵＴＲＡＮを介したＩＭＳ登録の結果として、あるいはＣＳ標的アドレスによって構成されることによって（ＣＳ標的アドレスは、例えば、複合アタッチメントプロシージャの結果として提供される）規定されてもよい。ある場合には、登録のとき、ＵＥが、ＶｏＩＭＳまたは単一無線ボイス呼継続性（ＳＲＶＣＣ）が非対応であることを発見する場合、ＵＥは、その登録情報内に「オーディオ」特徴タグまたはＩＭＳ通信サービス識別子（ＩＣＳＩ）（例えば、マルチメディア電話（ＭＭＴｅＩ））等の表示を含まなくてもよい。しかしながら、「オーディオ」特徴タグが、双方向全二重ボイス専用より多くのサービスを記述し得るので、「オーディオ」特徴タグの不在は、ＩＰを介した音楽または無線等のより多くのサービスへのＵＥアクセスを拒絶し得る。同様に、ＭＭＴｅＩ ＩＣＳＩの不在は、ＭＭＴｅＩ仕様に従って、特定のサービス（例えば、ファイル転送）を拒絶し得る。頭字語「ＡＳ」は、本書では、２つの目的のために使用されていることに留意されたい：（１）ノードまたは機能的要素「アプリケーションサーバ」を識別するためと、（２）「アクセス階層」を識別するためである。ＳＩＰにおいて、ＵＡがサービスを要求し、別のＵＡがサービスをレンダリングまたは提供すると、一般的には、ＳＩＰ要求メッセージが、ＵＡによって別のＵＡに伝送される。他のＵＡは、ＩＭＳにおいて「アプリケーションサーバ」と呼ばれるノードまたは機能的要素上にホスト可能である。一般的には、Ｉ−ＣＳＣＦ、またはＳ−ＣＳＣＦ、あるいはＥ−ＣＳＣＦが、要求をアプリケーションサーバにルーティングする。これは、本書を通して、頭字語「ＡＳ」が提供される文脈から明白となるはずである。

概して、ＩＭＳ ＡＳは、ＩＭＳ登録メッセージを受信後、ＬＴＥアクセスがボイスサービスに対応可能か否かを把握していない。したがって、ＩＭＳ ＡＳは、ＩＭＳ登録メッセージ内に含有される情報ではなく、他の情報に依存することにより、ＵＥが、セッション（ボイスを含む）がルーティングされるべき方法、またはセッション（ボイスを含む）がルーティングされるべき方法を決定するオプションを与えられるべきか否かを決定してもよい。ＵＥが、セッション（ボイスを含む）がルーティングされるべき方法を決定するオプションを与えられる場合、ＵＥは、モバイル着信呼またはボイスを含むものに対するオファーによって、ＳＩＰ ＩＮＶＩＴＥの受信に応じた応答方法を決定する。本開示では、ＩＭＳ ＡＳは、サービス集中継続性アプリケーションサーバ（ＳＣＣ ＡＳ）であってもよい。

規格変更を考慮して、ＵＥは、ＲＡＴに接続されている間、あるサービスに対応していることの表示、例えば、アタッチ、追跡エリアアップデート、ルーティングエリアアップデート、または複合アタッチプロシージャの実行に応じて、受信されたＧＰＲＳあるいはＬＴＥ／ＥＰＣ／Ｅ−ＵＴＲＡＮに接続されるときの「ＩＭＳボイスオーバＰＳセッション対応」表示を受信してもよい。登録エリアアップデートプロシージャの実行によって、「あるサービスに対応していることの表示」が変更されてもよい。その結果、ＵＥが、ＩＭＳドメインからサービスを受信し（加入者のためにプロビジョニングされるように）、また、登録されている場合、ＵＥは、ＩＭＳドメインによってオファーされ、「あるサービスに対応していることの表示」の現在の値に応じて、アクセスネットワーク上での加入の一部として認証されるいくつかのサービスを取得可能でなくてもよい。

いくつかの事例では、問題は、サービスがＵＥに提供される方法、ＶｏＩＭＳインジケータの値、ならびにＵＥ使用およびボイス設定に応じた、ＵＥへのサービス（例えば、モバイル着信ボイス呼）の配信に関する。特に、問題は、ＵＥが、種々のＲＡＴおよびボイスソリューションを介して、サービスを受信可能であって、ＵＥが優先するＲＡＴ（例えば、ＵＥ内のポリシーに基づいて、優先されると決定されるＲＡＴ）が、要求されるサービス／特徴に対応していない場合のシナリオに当てはまり得る。ある場合には、ＵＥが優先するＲＡＴが規定されることがないことに留意されたい。

例えば、ＵＥは、ＶｏＩＭＳインジケータによって示されるように、ＶｏＩＭＳが利用可能ではないエリア内において、ＬＴＥを介して、またはＥ−ＵＴＲＡＮを使用して、ＩＭＳに登録され得る。同様に、ＳＲＶＣＣが利用不可能であって、ＳＲＶＣＣフラグは設定されない場合がある。ＶｏＩＭＳインジケータに非対応である場合、ネットワークによって利用可能となるか、またはＵＥ内の下位層によって利用可能となる表示がない場合がある。その場合、ＵＥは、ＩＭＳ登録を行う前、またはＩＭＳ登録を行った後であるが、ＩＭＳボイス（ＶｏＩＭＳ）セッションを確立する前に、ＶｏＩＭＳに対応しているか否かを決定不可能である場合がある。ＶｏＩＭＳインジケータの不在は、デフォルトによって、ＶｏＩＭＳに対応しているか、または対応していない、のいずれかを含意し得る。

したがって、ＩＭＳ登録に応じて、ＵＥは、ＵＥが、ボイスサービスのためにＩＭＳを使用することを意図するか否かをＩＭＳインフラストラクチャに示すことが不可能であり得る。さらに、ＵＥが、「ボイス」サービスのために、または「非ボイス」サービスのためだけに（例えば、ＵＥが、「ボイス」および「非ボイス」サービスを所望するが、ＶｏＩＭＳインジケータが存在しないか、またはＶｏＩＭＳが利用可能ではないことが示されないとき）、ＩＭＳを使用することを意図するか否かをＩＭＳ（例えば、登録に応じて）に示すように構成されていると仮定する場合でも、ＩＭＳに着信するモバイル着信呼が、ＵＥがＰＳ ＲＡＴ（例えば、ＬＴＥ）上でキャンプオンするとき、どのように配信されるか否か、または呼が、ＣＳドメインを介してどのようにＵＥにルーティング可能であるかは、不明であり得る。故に、呼が、ＰＳドメイン内のＰＳ ＲＡＴを介して、ＩＭＳを使用して、ＵＥにルーティングされるか否か、または呼が、ＣＳドメインを通してルーティングされるか否かについて、不明であり得る。

ＵＥ ＩＭＳまたはＳＩＰスタックが、ＶｏＩＭＳインジケータの値に関する、ＮＡＳによって提供された表へのアクセスを有しないＵＥでは、ＵＥは、ＵＥが、あるエリア内のＩＭＳボイスを受信または開始可能であるか否か分からない。ある場合には、ＵＥ内のＩＭＳまたはＳＩＰスタックは、ＶｏＩＭＳセッションのために、ＩＭＳを使用する意図によって、最初に、ＩＭＳに登録してもよく、後に、ＮＡＳは、ＶｏＩＭＳインジケータを通して、ＶｏＩＭＳが利用可能ではないことを認識してもよい。その場合、ＵＥ内のＩＭＳまたはＳＩＰスタックが、呼がＩＭＳを介して配信されるべきではないことをネットワークに示すことは困難である場合があり、コアネットワークインフラストラクチャは、これらの２つの場合を区別不可能である。したがって、ＩＭＳに登録されたＵＥのＡＳ／ＮＡＳ層が、ＶｏＩＭＳインジケータを通して、ＩＭＳボイス呼が不可能であって、ＩＭＳを介してＵＥに配信される着信呼が存在することを知っているとき、ＵＥ内のＩＭＳスタックは、例えば、ＩＭＳスタックがＡＳ／ＮＡＳスタックと強固に統合されておらず、ＩＭＳスタックがＶｏＩＭＳ表示を有していないため、依然として、着信ボイス呼を受理する場合がある。本問題はまた、ＵＥが、ＩＭＳを介して着信呼を受理する際に、誤動作を行うときにも生じ得る。

さらなる問題は、ＵＥが、起動している２つ以上のボイスソリューション（すなわち、異なるアプリケーション：実施例は、ＶｏＬＧＡおよびＩＭＳである）を有する場合に生じ得る。１つのボイスソリューションは、オペレータによって提供され（ＯｐＶｏｉｃｅ）、１つ以上のソリューションは、他の当事者によって、ＩＭＳ（例えば、企業によって提供されるエンタープライズボイス）、またはＡｐｐＶｏｉｃｅおよびＡｐｐＩＭＳを経由して提供されてもよい。その場合、ＯｐＶｏｉｃｅサービスにアクセスするために、ＵＥは、ＩＭＳ、ＣＳフォールバック、および任意の他の可能なソリューション（例えば、ＶｏＬＧＡ）の選択のために、現在のソリューション（例えば、３ＧＰＰに定義されるもの）を実装してもよい。ＡｐｐＶｏｉｃｅにアクセスするために、ＵＥは、ＡｐｐＩＭＳインフラストラクチャに接続してもよい。ＡｐｐＩＭＳに接続するか否かの決定は、ＵＥが、トランスポート層からのＶｏＩＭＳインジケータが利用可能であって、ネットワークが、ＩＭＳが利用可能であることを示すとき、ＡｐｐＩＭＳのみに接続することを決定する場合、ＵＥは、他のサービスのためのＩＭＳ登録を試みない場合があるため、ＯｐＶｏｉｃｅのために使用される同一規則／機構に基づかなくてもよい。ＵＥが、代わりに、ＡｐｐＶｏｉｃｅのためにＡｐｐＩＭＳに登録する場合、ＵＥは、ＶｏＩＭＳインジケータが、ＩＭＳボイス呼が非対応（例えば、ＱｏＳのため）であることを表すエリア内にない場合があるので、着信ＡｐｐＶｏｉｃｅ呼に関するルーティング問題は、解決される必要があり得る。

言い換えると、問題は、１）ＵＥが、ネットワークに接続され、３ＧＰＰに現在規定されているＯｐＶｏｉｃｅのためのボイスソリューションを選択する（すなわち、ＶｏＩＭＳインジケータ、ＣＳフォールバック複合登録／ＴＡＵの成功または失敗等に基づいている）、あるいは２）ＵＥが、例えば、ＡｐｐＶｏｉｃｅプロバイダによってＵＥに提供されるポリシーに基づいて、ＡｐｐＶｏｉｃｅのために、ＡｐｐＩＭＳに接続されるときに生じ得る。ＶｏＩＭＳインジケータが利用可能であって、ＩＭＳボイスが可能ではないか、またはＶｏＩＭＳが利用可能ではないことを示す場合でも、ポリシーが、ＵＥがそうすることを示す場合、ＵＥは、ＡｐｐＶｏｉｃｅのために、ＡｐｐＩＭＳに登録し得る。問題はまた、３）ＵＥが、ＶｏＩＭＳインジケータがＩＭＳボイスに非対応であることを表すエリア内にあるとき、または４）ＡｐｐＶｏｉｃｅソリューションが、ＵＥ内の他のボイスソリューション（例えば、ＶｏＬＧＡ、ＣＳフォールバック等）と統合されていないとき、したがって、ＵＥは、ＩＭＳボイスが利用可能ではないとき、他のソリューションに「フォールバック」し、ＡｐｐＶｏｉｃｅをＵＥに提供不可能であるときに生じ得る。ＡｐｐＶｏｉｃｅスタックは、ＵＥ内のＯｐＶｏｉｃｅスタックと別個であってもよい。

ここで、本開示のより完全な理解のために、添付の図面および発明を実施するための形態と関連して、以下の簡単な説明を参照する（類似参照数字は、類似部品を表す）。
図１は、非複合ＥＰＳ／ＩＭＳＩアタッチを行う時のＵＥ挙動の工程図であって、ＵＥに対して「ＩＭＳ ＰＳボイス優先し、ＣＳボイス二次優先」が規定されている。 図２は、ＵＥに対して「ＩＭＳ ＰＳボイス優先、ＣＳボイス二次優先」の設定が規定された、複合ＥＰＳ／ＩＭＳＩアタッチを行うときのＵＥ挙動の工程図である。 図３は、ＵＥに対して「ＣＳボイス優先、ＩＭＳ ＰＳボイス二次優先」の設定が規定された、ＵＥ挙動の工程図である。 図４は、ＵＥに対して「ＬＭＳ ＰＳボイス専用」の設定が規定された、ＵＥ挙動の工程図である。 図５は、ＵＥに対して「ＣＳボイス専用」の設定が規定された、ＵＥ挙動の工程図である。 図６は、非ローミング構成における、全体的ポリシー制御および課金制御（ＰＣＣ）論理アーキテクチャを示す、図である。 図７Ａ、Ｂは、ＰＣＣとの相互作用を伴う、アタッチプロシージャを行うための例示的メッセージフローを例示する。 図７Ａ、Ｂは、ＰＣＣとの相互作用を伴う、アタッチプロシージャを行うための例示的メッセージフローを例示する。 図８は、ＶｏＬＧＡネットワークの構成要素を示す、例示的ネットワーク構成要素マップの図である。 図９は、ＵＥが、ＶｏＬＧＡネットワークに登録するためのメッセージフローを例示する。 図１０は、ＶｏＬＧＡモバイル発信呼を開始するために、ＵＥとＶｏＬＧＡネットワークとの間の接続を確立するためのメッセージフローを例示する。 図１１は、モバイル着信呼のために、ＵＥとＶｏＬＧＡネットワークとの間の接続を確立するためのメッセージフローを例示する。 図１２は、ネットワークにＵＥの能力を通知するためのメッセージシーケンスの図である。 図１３は、ＵＥとネットワークとの間の接続を確立するためのメッセージフローの図であって、ネットワークは、ＵＥによって所望されるサービスまたは特徴に対応せず、ＵＥが、非ボイスサービスに対して登録を行う。 図１４は、ＵＥとネットワークとの間の接続を確立するためのメッセージフローの図であって、ＵＥは、ネットワークによって提供されるサービスまたは機能インジケータを考慮しない。 図１５は、コンパレータの機能性の概略図を示す、図である（着信アクセスドメイン選択（Ｔ−ＡＤＳ）機能）。 図１６は、ＵＥとネットワークとの間の接続を確立するためのメッセージフローの図であって、ＵＥがＣＳフォールバックのための正常な登録を有する場合、ＵＥは、ＩＭＳ ＡＳをトリガし、ＳＤＰ−ＣＳを含むために使用される特徴タグを含む。 図１７は、ＵＥとネットワークとの間の接続を確立するためのメッセージフローの図であって、ＵＥは、ＶｏＩＭＳインジケータを検査し、呼配信がＯｐＶｏｉｃｅソリューションを介して行うべきことを示す。 図１８は、ユーザエージェントの実施形態を含む、無線通信システムを例示する。 図１９は、デジタル信号プロセッサ（ＤＳＰ）およびメモリを含む、ユーザエージェントのブロック図を示す。 図２０は、ユーザエージェントのプロセッサによって実装され得る、ソフトウェア環境を例示する。 図２１は、ネットワーク間を遷移するセッションの継続性を提供するための方法を実装するために好適な処理構成要素を含む、システムの実施例を例示する。

本開示は、概して、通信システムにおいて、ユーザ機器（ＵＥ）を使用してボイスサービスにアクセスする方法に関し、より具体的には、インターネットプロトコルマルチメディアサブシステム（ＩＭＳ）において、ボイスサービスを提供する方法と、対応するネットワーク要素とに関する。

次に、本開示の種々の側面を添付の図面を参照して説明するが、同一番号は、全体を通して、同一または対応する要素を指す。しかしながら、図面およびそれに関する発明を実施するための形態は、請求される主題を開示される特定の形態に限定することを意図するものではないことを理解されたい。むしろ、請求される主題の精神および範囲内にある、あらゆる修正、均等物、および代替を網羅することを意図する。

本明細書で使用されるように、用語「構成要素」、「システム」等は、ハードウェア、ハードウェアとソフトウェアとの組み合わせ、ソフトウェア、または実行時のソフトウェアのいずれかであるコンピュータ関連エンティティを指すことが意図される。例えば、構成要素は、プロセッサ上で起動するプロセス、プロセッサ、オブジェクト、実行ファイル、実行のスレッド、プログラム、および／またはコンピュータであり得るが、それらに限定されない。例示として、コンピュータ上で起動するアプリケーションおよびコンピュータは両方とも、構成要素であることが可能である。１つ以上の構成要素は、プロセスおよび／または実行のスレッドの中に常駐してもよく、構成要素は、１つのコンピュータ上に局在しているか、および／または２つ以上のコンピュータ間に分散していてもよい。

単語「例示的」は、本明細書では、実施例、事例、または図としての役割を果たすことを意味するために使用される。「例示的」として本明細書に説明される任意の側面または設計は、必ずしも、他の側面または設計より好ましいあるいは有利であると解釈されるわけではない。

さらに、開示される主題は、標準的プログラミングおよび／またはエンジニアリング技法を使用して、ソフトウェア、ファームウェア、ハードウェア、またはそれらの任意の組み合わせを生産し、本明細書に詳述される側面を実装するためのデバイスに基づいて、コンピュータまたはプロセッサを制御する、システム、方法、装置、または製品として実装されてもよい。本明細書で使用されるように、用語「製品」（または代替として、「コンピュータプログラム製品」）は、任意のコンピュータ可読デバイス、搬送波、またはメディアからアクセス可能なコンピュータプログラムを包含することが意図される。例えば、コンピュータ可読メディアは、磁気記憶デバイス（例えば、ハードディスク、フロッピー（登録商標）ディスク、磁気ストリップ等）、光学ディスク（例えば、コンパクトディスク（ＣＤ）、デジタル多用途ディスク（ＤＶＤ）等）、スマートカード、およびフラッシュメモリデバイス（例えば、カード、スティック等）を含むことが可能であるが、それらに限定されない。加えて、搬送波は、電子メールを送受信する際、あるいはインターネットまたはローカルエリアネットワーク（ＬＡＮ）等のネットワークにアクセスする際に使用されるもの等、コンピュータ可読電子データを搬送するために採用可能であることを理解されたい。当然ながら、当業者は、請求される主題の範囲または精神から逸脱することなく、多くの修正が、本構成に成されてもよいことを認識するであろう。

本発明は、パケット交換ドメインおよび回路交換ドメインのうちの少なくとも１つに対応する通信システムにおいて、ユーザ機器を使用して、ボイスサービスにアクセスするための方法を提供する。方法は、ＵＥにおいて、第１のメッセージを受信するステップを備え、第１のメッセージは、オーディオセッション表示を含む。方法は、第１のメッセージに応答して第２のメッセージを送信するステップをさらに備え、第２のメッセージは、少なくとも１つの値を備える１つ以上のボイスサービスインジケータに基づいている。第１および第２のメッセージは、ＳＩＰメッセージであってもよく、ＳＩＰ要求メッセージおよびＳＩＰ応答メッセージのうちの少なくとも１つであってもよい。

本システムは、ユーザ機器（ＵＥ）を使用して、サービスにアクセスする方法を提供する。ＵＥは、第１のサービスを要求するようにさらに構成される。方法は、第１のネットワークセルを使用して、ＵＥとネットワークとの間でデータを通信するためのセッションを確立するステップと、第１のネットワークセルに対応する第２のサービスのうちの少なくとも１つのリストを読み出すステップとを含む。第１のネットワークセルに対応する第２のサービスのうちの少なくとも１つが、ＵＥによって要求される第１のサービスのうちの少なくとも１つに匹敵しないとき、方法は、ＵＥによって要求される第１のサービスが非対応であることを示すメッセージをネットワークに伝送するステップを含む。

種々のネットワーク配備において、種々のネットワーク要素は、１つ以上のＳＩＰエンティティを含んでもよい。ＳＩＰエンティティは、例えば、ＳＩＰプロキシまたはＳＩＰサーバを含んでもよい。いくつかのＳＩＰエンティティは、一般的には、ＵＡに備えられ、以下の２つの様式で動作してもよい：１）要求メッセージをサーバに対して生成するユーザエージェントクライアント（ＵＡＣ）として、２）要求メッセージを受信し、それらを処理し、好適な応答を生成するユーザエージェントサーバ（ＵＡＳ）として。いくつかの用途シナリオでは、単一のＵＡは、ＳＩＰエンティティ（例えば、ＵＥデバイス）またはネットワークノードの両方として機能してもよい。

一実装では、ＳＩＰは、６種類の要求を使用する：ＩＮＶＩＴＥ−ユーザまたはサービスが、セッションに参加するように招待されていることを示す（注記：用語「セッション」および「呼セッション」は、時として、互換可能に使用される）。ＡＣＫ−クライアントが、ＩＮＶＩＴＥ要求に対する最終応答を受信したことを確認する。ＢＹＥ−セッションを着信し、発呼者または受呼者のいずれかによって送信されてもよい。ＣＡＮＣＥＬ−ＵＥによって送信された以前の要求をキャンセルする。ＯＰＴＩＯＮＳ−ＵＥの能力のクエリを行う。ＲＥＧＩＳＴＥＲ−Ｔｏ：ヘッダフィールド内に列挙されたアドレスをＳＩＰサーバに登録する。ＳＩＰは、進化するように構成されているので、受信者は、時として、認識しない要求の方法を受信し得る。そのような要求は、未知の要求方法として指定されてもよい。

要求への応答において、ＳＩＰは、以下の応答分類を使用する：１ｘｘ情報メッセージ、２ｘｘ成功応答、３ｘｘリダイレクション応答、４ｘｘ要求失敗応答、５ｘｘサーバ失敗応答、および６ｘｘ一般失敗応答。

ＳＩＰメッセージは、一般的には、標準化メッセージ構造を使用して提供される。構造は、初期ライン（要求内の要求ラインおよび応答内の状態ライン）を識別するコマンドライン部分、種々の情報を伝達する１つ以上のヘッダフィールドを識別するヘッダ部分、およびＳＩＰメッセージのメッセージ本文部分内に提供され得る、１つ以上のメッセージ本文から成る。メッセージ本文は、拡張マークアップ言語（ＸＭＬ）、ハイパーテキストマークアップ言語（ＨＴＭＬ）等のマークアップ言語内にレンダリングされ得るプレーンテキスト、コード化された画像、または任意の情報等のコンテンツを保持するように動作可能である。各メッセージ本文（一部）は、それぞれ、ＳＩＰメッセージのコンテンツに関する情報を提供する、コンテンツ配置、コンテンツエンコーディング、およびコンテンツタイプ等のヘッダフィールドを使用して記述される。いくつかの実装では、コンテンツタイプヘッダフィールドの値は、多目的インターネットメール拡張（ＭＩＭＥ）タイプである。ＩＥＴＦ ＲＦＣ ３２６１は、例えば、ＳＩＰの一実装のさらなる説明を提供する。いくつかのシステム実装では、ＳＩＰエンティティは、３ＧＰＰ ＴＳ ２３．２２８および３ＧＰＰ ＴＳ ２４．２２９等の種々の３ＧＰＰ仕様に準拠する。

１つ以上のネットワークノードまたはネットワーク要素は、コアインフラストラクチャまたはコアネットワークを備え、ＳＩＰエンティティと称されてもよい。例えば、ネットワークノードは、プロキシ−呼セッション制御機能（Ｐ−ＣＳＣＦ）ノード、サービング−ＣＳＣＦまたはＳ−ＣＳＣＦノード、問い合わせ−ＣＳＣＦまたはＩ−ＣＳＣＦノード、ブレークアウトゲートウェイ制御機能（ＢＧＣＦ）ノード、メディアゲートウェイ制御機能（ＭＧＣＦ）ノード、家庭用加入者サーバ（ＨＳＳ）ノード、ＩＭＳ ＡＳまたはアプリケーションサーバノード等を例示してもよい。上述のように、ノードならびに終点ＵＥデバイスは、セッション制御、すなわち、通信セッションの設定および中止のために、通信プロトコルとして、ＳＩＰを採用してもよい。故に、ネットワークノードおよびＵＥデバイスは、集合的に、「ＳＩＰエンティティ」、またはより一般的には、「通信プロトコルエンティティ」と称されてもよく、種々のサービス、例えば、ＶＣＣ、ＰＴＴ、ＰｏＣ、緊急サービス、ＩＣＳ等を達成するために、好適な通信プロトコルメッセージ（例えば、ＳＩＰメッセージ）の送受信に従事する。

ＩＭＳ集中型サービス（ＩＣＳ）は、エンドユーザに提供されるサービスをＩＭＳネットワーク内にホスト可能にする。サービスは、信号伝達のために利用可能なＰＳのみを有する加入者に、またはＣＳベアラを介してボイスをオファーすることがより望ましい場合、オファーされてもよい。ＩＣＳの場合、呼およびサービス制御信号伝達は、ＰＳドメインの一部として、Ｇｍ基準点を介して、ＳＩＰ制御チャネルを経由して行われてもよい一方、ボイスは、例えば、ＣＳドメインの従来のＣＳベアラ部分を使用する。完全なサービスを提供するために、ネットワークおよびＵＥは、ボイスおよびデータの両方の伝送を同時に行うことが可能であってもよい（そうでなければ、ＳＩＰ制御チャネルは、失われ得る）。

いくつかのネットワーク展開では、ＩＣＳは、ＳＣＣ ＡＳまたはＳＣＣ ＡＳノードを含む。ＳＣＣ ＡＳは、モバイル着信呼のための正確な標的を選択するために、３ＧＰＰ ＴＳ ２３．２９２および３ＧＰＰ ＴＳ ２３．２３７に従って説明される着信アクセスドメイン選択（ＴＡＤＳ）を提供するように構成されてもよい。標的の選択は、ＵＥが使用または要求するアクセスの種類の決定を含んでもよい。したがって、ＩＣＳおよびＣＳフォールバック対応ＵＥは、ＩＭＳを経由して登録されるか、また、ＭＳＣに登録されてもよい。ＳＣＣ ＡＳは、呼が配信され得る標的として、これらの登録のいずれかと関連付けられた標的情報を使用するように選択可能である。

いくつかのネットワーク展開では、ＩＣＳが含まれず、通信分割（ＣＤＩＶ）ＡＳまたは電気通信アプリケーションサーバ（ＴＡＳ）が含まれる。ＣＤＩＶ ＡＳは、モバイル着信呼のための正確な標的を選択するために、３ＧＰＰ ＴＳ ２４．６０４に従って説明される通信分割に基づく規則を提供するように構成されてもよい。標的の選択は、ＵＥが使用または要求するアクセスの種類の決定を含んでもよい。したがって、ＣＤＩＶ対応ＵＥは、ＩＭＳを経由して登録されるか、また、ＭＳＣに登録されてもよい。ＣＤＩＶ ＡＳは、これらの標的のいずれかを使用したＵＥへの通信または通信の構成要素（例えば、ボイス構成要素のみ）を標的とすることが可能である。ＣＤＩＶ ＡＳは、通信の構成要素のみを標的可能ではない場合があり、その場合、通信ネットワーク内の１つ以上の他のノードは、ＣＳドメイン上でＣＳ（例えば、ボイス、メッセージング）を介して転送するために好適なメディアのみの伝送を処理する。ＣＤＩＶ ＡＳは、規則ベースであって、規則は、構成可能である。規則は、例えば、ＩＥＴＦ ＲＦＣ ４７４５、またはＯＭＡ ＸＤＭ、あるいは３ＧＰＰ ＴＳ ２４．６２３に従って、共通ポリシーＸＭＬとして表現される。規則は、ＵｔインターフェースおよびＸＣＡＰプロトコルを使用して管理可能である。ある条件において標的を識別する規則によって、ＣＤＩＶ ＡＳの構成が一致するとき、通信は、３ＧＰＰ ＴＳ ２４．６０４に規定されるようにリダイレクト可能である。１）ＵＥが通信のために使用した最新の既知のアクセスネットワークが、規則内に示されるアクセスネットワークに一致する場合、例えば、ＣＳドメインによってサーブされるアドレスに通信をリダイレクトするために、そのような規則は、プロビジョニングされる必要があるであろう。２）ネットワーク（例えば、ＰＣＣに対応する通信ネットワーク内のノード）が、ＵＥが規則内に示されるアクセスネットワークに一致するアクセスネットワークにアタッチされることを示す場合、例えば、ＣＳドメインによってサーブされるアドレスに通信をリダイレクトするために、そのような規則は、プロビジョニングされる必要があるであろう。３）（最新の既知のまたはＰＣＣ決定）アクセスネットワークが、ＵＥがＩＭＳボイスに対応不可能であるアクセスネットワークにアタッチされることを示し、規則は、そのような場合、通信がボイスメディアに対応するアクセスネットワークによってサーブされるアドレス（例えば、ＣＳドメイン）にリダイレクトされる必要があることを示す場合、例えば、ＣＳドメインによってサーブされるアドレスに通信をリダイレクトするために、そのような規則は、プロビジョニングされる必要があるであろう。４）ＵＥが、本アクセスネットワークを介して、ＩＭＳまたはＰＳボイスを受信不可能であることを示し（例えば、ＳＤＰ内のＣＳボイスメディア（ｉｅｔｄ ｄｒａｆｔ−ｉｅｔｆ−ｍｍｕｓｉｃ−ｓｄｐ−ｃｓ参照）、またはＳＩＰメッセージ、例えば、ＩＮＶＩＴＥ要求に応答するＳＩＰメッセージを示すことによって）、規則が、そのような場合、通信が、ＩＭＳボイスまたはＣＳボイスメディア対応アクセスネットワークによってサーブされるアドレスにリダイレクトされる必要があることを示す（ＳＤＰ（例えば、ＣＳドメイン）に示されるように）場合、例えば、ＣＳドメインによってサーブされるアドレスに通信をリダイレクトするために、そのような規則が、プロビジョニングされる必要があるであろう。上述の規則の条件部分は、他の条件（例えば、３ＧＰＰ ＴＳ ２４．６０４に規定される他の条件）とともに、種々の方法で複合可能である。本アプローチのさらなる利点は、ＣＤＩＶ ＡＳが、選好によって、例えば、ボイスメディアが配信される選好によってプロビジョニング可能であることである。

ネットワークが、ＣＳおよびＧｍインターフェースの両方を同時にアクティブにする能力に対応していない状況では、Ｉ１が使用されてもよい。Ｉ１は、ＵＥとネットワークとの間のインターフェースまたは基準点であって、いくつかの制限（例えば、Ｇｍ基準点の不在または二重転送モード（ＤＴＭ）に対する対応の欠如）によって、ＳＩＰ制御チャネルとＣＳベアラとの併用を防止する場合に使用されてもよい。

いくつかのネットワークでは、ＰＣＣ機能性は、進化型パケットコア（ＥＰＣ）およびＧＰＲＳネットワーク（例えば、ＧＥＲＡＮ／ＵＴＲＡＮを含む）を含む、種々のネットワークのために導入されている。ＰＣＣ機能性は、ポリシーおよび課金実施機能（ＰＣＥＦ）、ベアラ結合および事象報告機能（ＢＢＥＲＦ）、ポリシーおよび課金規則機能（ＰＣＲＦ）、アプリケーション機能（ＡＦ）、オンライン課金システム（ＯＣＳ）、オフライン課金システム（ＯＦＣＳ）、および加入プロファイルレポジトリ（ＳＰＲ）を含んでもよい。ＰＣＣアーキテクチャは、ＩＰ ＣＡＮ（例えば、ＧＰＲＳコアネットワークまたはＥＰＣ）のアーキテクチャを拡張してもよく、ポリシーおよび課金実施機能は、ＰＤＮへのＩＰアクセスを実装するゲートウェイノードにおける機能的エンティティである。

図１〜５は、ネットワークのＶｏＩＭＳインジケータとＵＥの使用設定の異なる組み合わせのために必要とされるＵＥ作用を示す、種々の使用例のシナリオの図である。

図１は、非複合ＥＰＳ／ＩＭＳＩアタッチを行うときのＵＥ挙動の工程図であって、「ＩＭＳ ＰＳボイス優先、ＣＳボイス二次優先」がＵＥに対して規定されている。ステップ１０において、ＵＥは、ＩＭＳボイス優先、ＣＳボイス二次優先に設定される。ステップ１２において、ＵＥは、ＥＰＳアタッチプロシージャ（示されるように、アタッチプロシージャは、非複合である）を開始し、ステップ１４において、ＵＥは、ネットワークからのＩＭＳボイス対応表示を確認する。対応する場合、ＵＥは、ステップ１６において、ＩＭＳボイスを使用し、追跡エリアアップデート（ＴＡＵ）を行った後に、ステップ１４へ戻ってもよい。しかしながら、ＩＭＳボイスに非対応である場合、ＵＥは、ステップ１８において、ＣＳフォールバックのための複合ＴＡＵを行う。成功する場合、ＵＥは、ステップ２０において、ＣＳフォールバックの結果、利用可能となったボイスサービスを使用する。しかしながら、ＣＳフォールバックが失敗した場合、ＵＥは、ステップ２２において、その独自の設定を確認し、ボイス中心またはデータ中心であるか否かを決定する。データ中心の場合、ＵＥは、ステップ２４において、現在のＲＡＴ内に留まる。しかしながら、ＵＥがボイス中心である場合、ステップ２６において、代替ＲＡＴを再選択する。

図２は、複合ＥＰＳ／ＩＭＳＩアタッチを行うときのＵＥ挙動の工程図であって、ＵＥに対して「ＩＭＳ ＰＳボイス優先、ＣＳボイス二次優先」の設定が規定されている。ステップ３０において、ＵＥは、ＩＭＳ ＰＳボイス優先、ＣＳボイス二次優先に設定される。ステップ３２において、ＵＥは、複合ＥＰＳ／ＩＭＳＩアタッチプロシージャを開始し、ネットワークからのＩＭＳボイスオーバＰＳセッション対応表示を確認する。ステップ３４において、複合アタッチが受理され、ＩＭＳ ＰＳボイスに非対応である場合、ＵＥは、ＣＦフォールバックを使用して、ボイス接続を確立する。しかしながら、ＩＭＳ ＰＳボイスに対応する場合（複合アタッチが失敗または受理されたか否かに関わらず）、ＵＥは、ステップ３６において、ＩＭＳボイスサービスを使用する。複合アタッチが失敗し、ＩＭＳ ＰＳボイスに非対応である場合、ＵＥは、ステップ３８において、ボイス中心またはデータ中心通信のための選好に対して、その設定を確認する。データ中心の場合、ＵＥは、ステップ４０において、現在のＲＡＴ内に留まる。しかしながら、ボイス中心の場合、ＵＥは、ステップ４２において、アクセスボイスサービスへの別のＲＡＴを再選択する。

図３は、ＵＥ挙動の工程図であって、「ＣＳボイス優先、ＩＭＳ ＰＳボイス二次優先」がＵＥに対して規定されている。ステップ５０において、ＵＥは、ＣＳボイス優先、ＩＭＳ ＰＳボイス二次優先に設定される。ステップ５２において、ＵＥは、複合ＥＰＳ／ＩＭＳＩアタッチプロシージャを開始する。成功の場合、ＵＥは、ステップ５４において、ＣＳフォールバックを使用する。不成功の場合、ＵＥは、ステップ５６において、ネットワークからのＩＭＳボイス対応表示を確認する。対応する場合、ＵＥは、ステップ５８において、ＩＭＳボイスサービスを使用し、ＴＡＵを行う。非対応の場合、ＵＥは、ステップ６０において、その設定を確認し、ボイスまたはデータ中心であるか否かを決定する。データ中心の場合、ＵＥは、ステップ６２において現在のＲＡＴ内に留まる。ボイス中心の場合、ＵＥは、ステップ６４において別のＲＡＴを再選択する。

図４は、ＵＥ挙動の工程図であって、「ＩＭＳ ＰＳボイス専用」の設定が、ＵＥに対して規定されている。ステップ７０において、ＵＥは、ＩＭＳ ＰＳボイス専用に設定される。ステップ７２において、ＵＥは、ＥＰＳアタッチプロシージャを開始し、ステップ７４において、ＵＥは、ネットワークからのＩＭＳボイス対応表示を確認する。対応する場合、ＵＥは、ステップ７６において、ＩＭＳボイスを使用し、追跡エリアアップデート（ＴＡＵ）を行った後、ステップ７４に戻ってもよい。しかしながら、ＩＭＳボイスに非対応である場合、ＵＥは、その独自の設定を確認し、ステップ７８において、ボイス中心またはデータ中心であるか否かを決定する。データ中心の場合、ＵＥは、ステップ８０において、現在のＲＡＴ内に留まる。しかしながら、ＵＥがボイス中心である場合、ステップ８２において、代替ＲＡＴを再選択する。

図５は、ＵＥ挙動の工程図であって、「ＣＳボイス専用」の設定が、ＵＥに対して規定されている。ステップ９０において、ＵＥは、ＣＳボイス専用に設定される。ステップ９２において、ＵＥは、複合ＥＰＳ／ＩＭＳＩアタッチプロシージャを開始する。成功の場合、ＵＥは、ステップ９４においてＣＳフォールバックを使用する。不成功の場合、ＵＥは、ステップ９６においてその設定を確認し、ボイスまたはデータ中心であるか否かを決定する。データ中心の場合、ＵＥは、ステップ９８において現在のＲＡＴ内に留まる。ボイス中心の場合、ＵＥは、ステップ１００において別のＲＡＴを再選択する。

図６は、非ローミング構成における全体的なＰＣＣ論理アーキテクチャを示す図である。ＰＣＲＦ１０２は、ＳＰＲ１０４、ＡＦ１０６、ＢＢＥＲＦ１０８、およびゲートウェイ１１０（ＰＣＥＦ１１２を含む）と通信する。ゲートウェイ１１０は、ＯＣＳ１１６およびＯＦＣＳ１１４の両方と通信する。ＯＣＳ１１６は、サービスデータフローベースクレジット制御１１８を提供する。例示的なＰＣＣアーキテクチャにおいて、ＡＦ１０６は、サービスをＵＥに提供する（例えば、ＡＦ１０６は、ＩＭＳサーバであってもよい）。

ＬＴＥを介したＥＰＣへのアタッチメントに応じて、図７に例示されるように、ＰＣＣとの相互作用が存在してもよい。図７は、ＰＣＣとの相互作用を伴う、アタッチプロシージャを行うための例示的メッセージフローを例示する。特に、要素１３０、１３２、および１３４によって示されるステップはすべて、ＰＣＣアーキテクチャ内のＰＣＲＦとの相互作用を伴う。ＰＣＣは、ＧＥＲＡＮ／ＵＴＲＡＮへのアタッチメントの際、コアネットワークと相互作用してもよく、コアネットワークは、ＬＴＥ ＴＡＵに応じて、ベアラをポリシングするために、ＰＣＣと相互作用してもよく、ＰＣＣは、ルーティングエリアアップデートに応じて、ＧＰＲＳコアネットワークと相互作用してもよい。

ネットワーク内のアプリケーションが、サービスを提供するためのＱｏＳを伴う、特有のベアラを要求するとき（例えば、ＶｏＩＭＳを提供するために、ボイスを搬送可能なベアラを要求するＩＭＳ）、ＩＭＳは、ＰＣＣと相互作用し、そのようなベアラを要求する。次に、ＰＣＣは、ＥＰＣ（ＬＴＥの場合）またはＧＰＲＳコアネットワーク（ＧＥＲＡＮ／ＵＴＲＡＮの場合）と相互作用し、適切なベアラを確立する。

汎用アクセス経由ボイスオーバＬＴＥ（ＶｏＬＧＡ）において、オペレータは、Ｅ−ＵＴＲＡＮ範囲下、ＣＳサービスの確立を制御し、ＩＭＳを提供する、既存のＣＳドメインエンティティ（例えば、ＭＳＣ／ＶＬＲ）を再使用してもよい。ＶｏＬＧＡアクセスネットワークコントローラ（ＶＡＮＣ）によって、ＵＥは、ＥＰＳによって提供される汎用ＩＰ接続を使用して、ＭＳＣ／ＶＬＲにアクセス可能となる。ＶＡＮＣは、Ａ−インターフェース（「ＶｏＬＧＡ Ａモード」）またはＩｕ−ＣＳインターフェース（「ＶｏＬＧＡ Ｉｕモード」）を使用して、ＭＳＣ／ＶＬＲに接続可能である。ＥＰＳの観点から、ＶＡＮＣは、アプリケーション機能として見なされる。

図８は、ＶｏＬＧＡネットワークの構成要素を示す、例示的なネットワーク構成要素マップの図である。ＶｏＬＧＡ Ａモードアーキテクチャにおいて、家庭用公衆陸上移動ネットワーク（ＨＰＬＭＮ）内のＶＡＮＣは、図８上の接続１４０によって示されるように、Ａ−インターフェース（「ＶｏＬＧＡ Ａモード」）を使用して、ＭＳＣ／ＶＬＲに接続される。しかしながら、ＶｏＬＧＡ Ｉｕモードアーキテクチャにおいて、ＨＰＬＭＮ内のＶＡＮＣは、図８のＡ−インターフェース１４０と置き換わるＩｕ−ＣＳインターフェース（「ＶｏＬＧＡ Ｉｕモード」）を使用して、ＭＳＣ／ＶＬＲに接続されてもよい。

図９は、ＵＥが、ＶｏＬＧＡネットワークに登録するためのメッセージフローを例示する。接続を取得するために、ＵＥは、最初に、要素１５０によって示されるステップにおいて、ＶＡＮＣを発見する。ＵＥが、ＶＡＮＣ発見プロシージャを正常に完了する（すなわち、ＳｅＧＷおよびＶＡＮＣのアドレスを有する）場合、ＵＥは、要素１５２によって示されるステップにおいて、ＶｏＬＧＡ登録を試みてもよい。ＶＡＮＣは、要素１５４によって示されるステップにおいて登録を受理するか、要素１５６によって示されるステップにおいて登録を拒絶するか、または要素１５８によって示されるステップによって例示されるように、ＵＥを別のＶＡＮＣにリダイレクトしてもよい（例えば、ＵＥの場所、負荷バランシング、またはローミング条件に応じて）。

ＶｏＬＧＡモバイル発信呼を行うＵＥは、図１０に例示されるステップに従ってもよい。図１０は、ＶｏＬＧＡモバイル発信呼を開始するために、ＵＥとＶｏＬＧＡネットワークとの間の接続を確立するためのメッセージフローを例示する。ＵＥは、モバイル発信呼のための信号伝達をＣＳドメイン（ＭＳＣを経由して）と確立し、次いで、ＬＴＥおよびＶｏＬＧＡトンネルを介したベアラが確立される。代替として、図１１は、モバイル着信呼のために、ＵＥとＶｏＬＧＡネットワークとの間に接続を確立するためのメッセージフローを例示する。

一般に、ＵＥは、サービス、特徴、あるいはサービスおよび／または特徴群へのアクセスを要求してもよい。ＵＥは、多重ＲＡＴにアクセスし、ＲＡＴのうちの１つ以上から、接続、サービス、または特徴を取得するか否かを決定するように構成さえしてもよい。本開示では、接続は、ＵＥが、サービスまたは特徴の１つずつへのアクセスを取得可能であることを意味しない場合がある。代わりに、接続は、ＵＥがそのＲＡＴにアクセスするために認証および許可されることを意味し得る。本プロセスの一部として、ＵＥは、所望のサービスまたは特徴が、ＲＡＴ上で利用可能ではないことを発見し得る。所望のサービスまたは特徴は、ネットワークから、情報を取得するか、情報を求めるか、および動的ホスト構成プロトコル（ＤＨＣＰ）要求、リモート認証ダイヤルインユーザサービス（ＲＡＤＩＵＳ）要求、ダイアメータ要求、アタッチ受理要求等を含む、種々の２地点間メッセージを要求することを含んでもよい。所望のサービスまたは特徴はまた、ＤＨＣＰ応答、ＲＡＤＩＵＳ応答、直径応答、アタッチ受理ＯＫ表示を含む、ネットワークのある２地点間メッセージによって提供される、ブロードキャストメッセージ等において情報を検出する、および情報をスキャニングすることを含んでもよい。

ＵＥは、所望のサービスまたは特徴を取得する方法を決定する。決定は、ＡＳ／ＮＡＳレベルで行われてもよいが、ＮＡＳ／ＡＳ選択が行われると、ＵＥは、サービス（例えば、ＩＭＳ）を提供するインフラストラクチャに、所望のサービスを取得する方法を通知する必要があり得る。例えば、ＡＳ／ＮＡＳに基づく選択が、ボイスサービスを伴わず、ＬＴＥネットワークセル上にキャンプオンするＵＥをもたらす場合、ＵＥは、非ボイスサービスのための正常な登録後、ボイス呼がＩＭＳを介してルーティング不可能であることをＩＭＳに通知してもよい。

ある場合には、ＵＥは、要求するサービスまたは特徴が利用可能ではなく、代替ＲＡＴがそれらのサービスまたは特徴を配信するために使用されるべきであることをネットワークに通知してもよい。ＵＥは、メッセージをネットワークに送信し、特有のＲＡＴがサービスまたは特徴のために使用されるべきであるか、または識別されたＲＡＴが要求されるサービスまたは特徴に対応していないか否かのいずれかを示してもよい。ＵＥが、ネットワークから、サービスまたは特徴を配信するための要求を受信すると、ＵＥは、以下を行ってもよい：ネットワークが、サービスまたは特徴に対応するための代替ＲＡＴを提案する場合、ＵＥは、オファーされたサービスまたは特徴の一部または全部のために、代替ＲＡＴを使用する所望をネットワークに示してもよい；または、ＵＥは、適切なエラー原因をネットワークに送信し、ネットワークをトリガし、代替ＲＡＴを介して、サービスまたは特徴の配信を試みてもよい。

代替として、特徴またはサービスが、ＶｏＩＭＳインジケータあるいはＳＲ−ＶＣＣインジケータに基づいて利用可能ではないことを発見すると、ＵＥは、代替ＲＡＴがあるサービスまたは特徴のために使用されるべきことをネットワークに信号伝達してもよい。本実施例では、ネットワークは、ＣＳフォールバックに対応するように構成されてもよく、ＵＥは、ＩＭＳネットワークに登録するとき、ＩＣＳ特徴タグを含まなくてもよい（例えば、ＳＤＰ ＣＳ機能性を実装しないため（ｉｅｔｆ ｄｒａｆｔ−ｉｅｔｆ−ｍｍｕｓｉｃ−ｓｄｐ−ｃｓに定義されるように））。したがって、ネットワークは、ＵＥがＩＭＳへのアクセスを有するか否かに基づいて、呼をルーティングする方法を決定することが要求され得る。

図１２は、ＵＥの能力をネットワークに通知するためのメッセージシーケンスの図である。図１２のステップ２００において、ＵＥは、ＮＡＳアタッチプロシージャまたはＮＡＳ複合アタッチプロシージャを行い、ＭＭＥにおいてＥＰＣにアタッチし、あるいは別のアクセスからＬＴＥに移動するとき、または異なる追跡エリアに移動するとき、ＮＡＳ ＴＡＵ（追跡エリアアップデート）プロシージャまたはＮＡＳ複合ＴＡＵを行う。図１２に示されるように、ＭＭＥは、既存の規格に従って、ＩＭＳに対応しているか否か、またはＳＲＶＣＣに対応しているか否かを示す少なくとも１つのフラグを信号伝達してもよい。複合アタッチまたはＴＡＵの場合、ＭＭＥは、ステップ２０２において、ＭＳＣと相互作用し、ＵＥをＭＳＣに登録する。次いで、本情報の受信に応じて、ステップ２０４において、ＵＥは、ネットワークノード（例えば、ＩＭＳ ＡＳまたはＳＣＣ ＡＳ）にＵＥの選好を通知し、所望のサービスまたは特徴の対応の欠如に関するＵＥの知識に基づいて、着信セッションが配信されるべき方法を決定してもよい。例えば、ＵＥは、ボイスオーバＩＭＳ（ＶｏＩＭＳ）フラグが、負の表示を有することが見出されるか、またはＭＭＥから受信されないか、あるいはＳＲＶＣＣに非対応であって、ＵＥがＳＲＶＣＣの動作を要求する場合、その選好をＩＭＳ ＡＳまたはＳＣＣ ＡＳに伝送してもよい。別の実施例は、ＵＥが、所望のサービスまたは特徴の対応の欠如に関する知識に基づいて、着信セッションが配信されるべき方法に関するその所望の選好を常に信号伝達してもよいというものである（例えば、ＶｏＩＭＳおよびＳＲＶＣＣフラグ、インジケータ、または識別子の設定）。

ＵＥの選好は、全サービスをドメインＡ（例えば、ＣＳドメイン、特有のＲＡＴ−すなわち、ＧＥＲＡＮまたはＵＴＲＡＮから独立して）または第２のドメインＢに送信するものであってもよい。代替として、選好は、あるサービス要求が、あるドメインを介して送信されるべきことを規定する構造化表示を提供してもよい。ある場合には、選好は、図１２以降に示されるように、登録ステップ２０２と並行して規定されてもよい。例えば、ＶｏＩＭＳおよびＳＲＶＣＣフラグ、インジケータ、または識別子の設定に基づいて、ＵＥは、特有のサービス、例えば、ＳＭＳｏｖｅｒＩＰ、Ｖｉｄｅｏ等が、ＬＴＥを介して送信され、ボイスが、ＧＥＲＡＮ／ＵＴＲＡＮを介して送信されるべきことを決定してもよい。

いくつかのインターフェースまたは基準点を使用して、図１２に例示されるステップの１つ以上を実装してもよい。そのようなインターフェースまたは基準点の１つは、Ｕｔインターフェースである（概して、ＵＥとＳＩＰアプリケーションサーバとの間では、ＸＣＡＰおよびＳＩＰ加入／通知プロトコルは、Ｕｔインターフェースの一部として使用されてもよい）。別の潜在的インターフェースまたは基準点は、Ｉ１が、例えば、ＸＣＡＰおよび／またはＳＩＰ加入／通知と相互作用するように進化させられている場合、Ｉ１を含んでもよい。Ｉ１は、ＵＥとＩＭＳ ＡＳとの間の基準点であって、ＳＩＰ様のプロトコルを搬送するためのベース転送として、ショートメッセージサービス（ＳＭＳ）または非構造化付加サービス（ＵＳＳＤ）を使用する。

代替として、ＵＥは、異なる形態の信号伝達を使用して、ＵＥの能力のうちの１つ以上をネットワークに通知してもよい。一ネットワーク構成では、ＩＭＳ ＡＳは、ＵＥにダイレクトされ、ＵＥから送信されたＳＩＰメッセージの経路内にあって、その場合、ＩＭＳ ＡＳは、レコードルートヘッダフィールド内にそのＵＲＩを含む。Ｓ−ＣＳＣＦは、適用可能な初期フィルタ基準（ｉＦＣ）内に命令されるように、ＳＩＰメッセージをＩＭＳ ＡＳにダイレクトしてもよい。したがって、ＵＥは、種々のＳＩＰメッセージ内に、下位層の状態に関する情報（例えば、メディア特徴タグ定義およびＰ−アクセス−ネットワーク−情報ヘッダフィールドによって以下に示されるように、ＩＭＳボイスに対応するか否か）を含んでもよい。これは、以下のＳＩＰ法の実施例に例示されるように、明白であり得るインジケータまたはフラグとして作用してもよい。インジケータは、ａ．以下のＰ−アクセス−ネットワーク−情報ヘッダフィールドによって示されるＳＩＰメッセージ内のＰ−アクセス−ネットワーク−情報ヘッダフィールド、またはｂ．本明細書に説明される特徴タグによって定義されてもよい。

（メディア特徴タグ定義）
以下は、例示的メディア特徴タグ定義の説明である。

Ａ．１ メディア特徴タグｇ．３ｇｐｐ．ｎｏｖｏｉｃｅの定義
メディア特徴タグ名：ｇ．３ｇｐｐ．ｎｏｖｏｉｃｅ
ＡＳＮ．１識別子：１．３．６．１．８．２．ｘ
本タグによって示されるメディア特徴の概要：本特徴タグは、デバイスが全二重ボイスに対応不可能であることを示す。

本特徴タグと併用するために適切な値：ブール値
特徴タグは、主に、以下のアプリケーション、プロトコル、サービス、またはネゴシエーション機構における使用が意図される：本特徴タグは、電話またはＰＤＡ等、デバイスの能力を記述するために、通信用途において最も有用である。

一般的使用の実施例：携帯電話が全二重ボイスに対応していないことを示す。無線のストリーミング等、他の形態の音声に対応し得る。

Ａ．２ メディア特徴タグｇ．３ｇｐｐ．ＣＳＦＢの定義
メディア特徴タグ名：ｇ．３ｇｐｐ．ＣＳＦＢ
ＡＳＮ．１識別子：１．３．６．１．８．２．ｙ
本タグによって示されるメディア特徴の概要：本特徴タグは、デバイスが複合アタッチ（ＣＳＦＢ登録）に成功したことを示す。

本特徴タグと併用するために適切な値：ブール値
特徴タグは、主に、以下のアプリケーション、プロトコル、サービス、またはネゴシエーション機構における使用が意図される：本特徴タグは、電話またはＰＤＡ等、デバイスの能力を記述するために、通信用途において最も有用である。

一般的使用の実施例：携帯電話が、ＳＧインターフェースを介して、複合アタッチに成功したことを示す。

Ｐ−アクセス−ネットワーク−情報ヘッダフィールド（変更は、下線テキストで示される）
７．２Ａ．４ Ｐ−アクセス−ネットワーク−情報ヘッダフィールド
７．２Ａ．４．１ 導入
Ｐ−アクセス−ネットワーク−情報ヘッダフィールドは、特定のアクセス技術に関する特有の情報を含むように拡張される。

７．２Ａ．４．２ 構文
Ｐ−アクセス−ネットワーク−情報ヘッダフィールドの構文は、ＲＦＣ ３４５５に説明される。アクセス技術仕様記述に従って、ＩＰ−ＣＡＮの種類に応じて、本ヘッダフィールドのための付加的符号化規則が存在する。

以下の表２は、ＲＦＣ ３４５５に定義される、Ｐ−アクセス−ネットワーク−情報ヘッダフィールドの３ＧＰＰ仕様拡張構文を記述する。

「ｎｐ」パラメータの存在は、Ｐ−アクセス−ネットワーク−情報ヘッダフィールドがＰ−ＣＳＣＦによって提供されることを示す。コンテンツは、ＵＥによって提供される、本パラメータを伴わないＰ−アクセス−ネットワーク−情報ヘッダフィールドと異なり得る。

「ｎｐ」パラメータは、「アクセスタイプ」および「アクセスクラス」構成体の両方と併用可能である。「アクセスタイプ」構成体は、値が、特定の「アクセスクラス」値に特有であることが既知でない場合、例えば、ＰＣＲＦから配信されるいくつかの値の場合、提供される。

７．２Ａ．４．３ Ｐ−アクセス−ネットワーク−情報ヘッダフィールドのための付加的符号化規則
Ｐ−アクセス−ネットワーク−情報ヘッダフィールドは、以下のコンテンツを取り込む：
１）アクセスタイプフィールドは、
使用アクセス技術に対して必要に応じて、「３ＧＰＰ−ＧＥＲＡＮ」、「３ＧＰＰ−ＵＴＲＡＮ−ＦＤＤ」、「３ＧＰＰ−ＵＴＲＡＮ−ＴＤＤ」、「３ＧＰＰ２−１Ｘ」、「３ＧＰＰ２−１Ｘ−ＨＲＰＤ」、「３ＧＰＰ２−ＵＭＢ」、「ＩＥＥＥ−８０２．１１」、「ＩＥＥＥ−８０２．１１ａ」、「ＩＥＥＥ−８０２．１１ｂ」、「ＩＥＥＥ−８０２．１１ｇ」、「ＩＥＥＥ−８０２．１１ｎ」、「ＡＤＳＬ」、「ＡＤＳＬ２」、「ＡＤＳＬ２＋」、「ＲＡＤＳＬ」、「ＳＤＳＬ」、「ＨＤＳＬ」、「ＨＤＳＬ２」、「Ｇ。ＳＨＤＳＬ」、「ＶＤＳＬ」、「ＩＤＳＬ」、または「ＤＯＣＳＩＳ」、「ＩＥＥＥ−８０２．３」、「ＩＥＥＥ−８０２．３ａ」、「ＩＥＥＥ−８０２．３ｅ」、「ＩＥＥＥ−８０２．３ｉ」、「ＩＥＥＥ−８０２．３ｊ」、「ＩＥＥＥ−８０２．３ｕ」、または「ＩＥＥＥ−８０２．３ａｂ」、「ＩＥＥＥ−８０２．３ａｅ」、「ＩＥＥＥ−８０２．３ａｋ」、「ＩＥＥＥ−８０２．３ａｑ」、「ＩＥＥＥ−８０２．３ａｎ」、「ＩＥＥＥ−８０２．３ｙ」、「ＩＥＥＥ−８０２．３ｚ」、または「ＩＥＥＥ−８０２．３ｙ」のうちの１つに設定される。

２）アクセスタイプフィールドが「３ＧＰＰ−ＧＥＲＡＮ」に設定される場合、ｃｇｉ−３ｇｐｐパラメータは、ＵＥの下位層から取得されるセルグローバル識別に設定される。セルグローバル識別は、ＭＣＣ、ＭＮＣ、ＬＡＣ、およびＣＩの連結である（３ＧＰＰ ＴＳ ２３．００３に説明されるように）。したがって、「ｃｇｉ−３ｇｐｐ」パラメータの値は、以下のテキストストリングとして符号化される：
最上位ビットから開始し、ＭＣＣ（３桁）、ＭＮＣ（ＭＣＣ値に応じて、２または３桁）、ＬＡＣ（全１６進数表現を使用した１６ビットの固定長符号）、およびＣＩ（全１６進数表現を使用した１６ビットの固定長符号）と続く；
３）アクセスタイプフィールドが、「３ＧＰＰ−ＵＴＲＡＮ−ＦＤＤ」または「３ＧＰＰ−ＵＴＲＡＮ−ＴＤＤ」に等しい場合、「ｕｔｒａｎ−ｃｅｌｌ−ｉｄ−３ｇｐｐ」パラメータは、ＵＥの下位層から取得される、ＭＣＣ、ＭＮＣ、ＬＡＣ（３ＧＰＰ ＴＳ ２３．００３に説明されるように）、およびＵＭＴＳセル識別（３ＧＰＰ ＴＳ ２５．３３１に説明されるように）の連結に設定され、以下のようにテキストストリングとして符号化される：
最上位ビットから開始し、ＭＣＣ（３桁）、ＭＮＣ（ＭＣＣ値に応じて、２または３桁）、ＬＡＣ（全１６進数表現を使用した１６ビットの固定長符号、およびＵＭＴＳセル識別（全１６進数表現を使用した２８ビットの固定長符号）と続く；
４）アクセスクラスフィールドが設定される場合、「ｎｐ」アクセス情報パラメータは、アクセス情報パラメータのみ挿入される。本仕様の本リリースは、本パラメータにおける使用のための値を定義しない。アクセスクラスフィールドは、Ｐ−ＣＳＣＦによってのみ設定可能である；
５）アクセスタイプフィールドが、「３ＧＰＰ２−１Ｘ」に設定される場合、ｃｉ−３ｇｐｐ２パラメータは、規定の順番における、ＳＩＤ（１６ビット）、ＮＩＤ（１６ビット）、ＰＺＩＤ（８ビット、およびＢＡＳＥ＿ＩＤ（１６ビット）（３ＧＰＰ２ Ｃ．Ｓ０００５−Ｄ［８５］参照）の連結によって取得される、ストリングの１６進値のＡＳＣＩＩ表現に設定される。ｃｉ−３ｇｐｐ２パラメータの長さは、１４の１６進文字となる。１６進文字（ＡからＦ）は、大文字ＡＳＣＩＩ文字を仕様して符号化される。ＭＳが、上述のパラメータのいずれかに対する値を既知でない場合、ＭＳは、そのパラメータに対して、０の値を使用する。例えば、ＳＩＤが未知である場合、ＭＳは、ＳＩＤを０ｘ００００として表現する；
注記１：ＳＩＤ値は、３ＧＰＰ２ Ｃ．Ｓ０００５−Ｄ［８５］に規定されるように、１５ビットであるはずであるため、１６ビットを使用して表現される。

実施例：ＳＩＤ＝０ｘ１２３４、ＮＩＤ＝０ｘ５６７８、ＰＺＩＤ＝０ｘ１２、ＢＡＳＥ＿ＩＤ＝０ｘＦＦＦＦである場合、ｃｉ−３ｇｐｐ２値は、ストリング「１２３４５６７８１２ＦＦＦＦ」に設定される。

６）アクセスタイプフィールドが、「３ＧＰＰ２−１Ｘ−ＨＲＰＤ」に設定される場合、ｃｉ−３ｇｐｐ２パラメータは、規定の順番における、セクタＩＤ（１２８ビット）、およびサブネット長（８ビット）（３ＧＰＰ２ Ｃ．Ｓ００２４−Ａ［８６］参照）、ならびに利用可能である場合、搬送波ＩＤ（３ＧＰＰ２ Ｘ．Ｓ００６０［８６Ｂ］参照）の連結によって取得される、ストリングの１６進値のＡＳＣＩＩ表現に設定される。ｃｉ−３ｇｐｐ２パラメータの長さは、搬送波ＩＤが含まれるか否かに応じて、３４または４０の１６進文字となる。１６進文字（ＡからＦ）は、大文字ＡＳＣＩＩ文字を使用して符号化される；
実施例：セクタＩＤ＝０ｘ１２３４１２３４１２３４１２３４１２３４１２３４１２３４１２３４、サブネット長＝０ｘ１１、および搬送波ＩＤ＝０ｘ５５５４４４である場合、ｃｉ−３ｇｐｐ２値は、ストリング「１２３４１２３４１２３４１２３４１２３４１２３４１２３４１２３４１１５５５４４４」に設定される。

７）アクセスタイプフィールドが、「３ＧＰＰ２−ＵＭＢ」３ＧＰＰ２ Ｃ．Ｓ００８４−０００［８６Ａ］に設定される場合、ｃｉ−３ｇｐｐ２パラメータは、３ＧＰＰ２ Ｃ．Ｓ００８４−０００［８６Ａ］に定義される、セクタＩＤ（１２８ビット）の１６進値のＡＳＣＩＩ表現に設定される。ｃｉ−３ｇｐｐ２パラメータの長さは、３２の１６進文字となる。１６進文字（ＡからＦ）は、大文字ＡＳＣＩＩ文字を使用して符号化される；
実施例：セクタＩＤ＝０ｘ１２３４１２３４１２３４１２３４１２３４１２３４１２３４１２３４の場合、ｃｉ−３ｇｐｐ２値は、ストリング「１２３４１２３４１２３４１２３４１２３４１２３４１２３４１２３４」に設定される。

８）アクセスタイプフィールドが、「ＩＥＥＥ−８０２．１１」、「ＩＥＥＥ−８０２．１１ａ」、「ＩＥＥＥ−８０２．１１ｂ」または「ＩＥＥＥ−８０２．１１ｇ」、あるいは「ＩＥＥＥ−８０２．１１ｎ」のうちの１つに設定される場合、「ｉ−ｗｌａｎ−ｎｏｄｅ−ｉｄ」パラメータは、任意の区切文字を伴わない、ＡＰのＭＡＣアドレスの１６進値のＡＳＣＩＩ表現に設定される；
実施例：ＡＰのＭＡＣアドレス＝００−０Ｃ−Ｆ１−１２−６０−２８の場合、ｉ−ｗｌａｎ−ｎｏｔｅ−ｉｄは、ストリング「０００ｃｆ １１２６０２８」に設定される。

９）アクセスタイプフィールドが、「ＡＤＳＬ」、「ＡＤＳＬ２」、「ＡＤＳＬ２＋」、「ＲＡＤＳＬ」、「ＳＤＳＬ」、「ＨＤＳＬ」、「ＨＤＳＬ２」、「Ｇ．ＳＨＤＳＬ」、「ＶＤＳＬ」、「ＩＤＳＬ」のうちの１つに設定される場合、アクセス情報フィールドは、ＣＬＦから取得されるｄｓｌ−ｌｏｃａｔｉｏｎパラメータを含有する（ＮＡＳＳ機能的アーキテクチャ参照）；
１０）アクセスタイプフィールドが、「ＤＯＣＳＩＳ」に設定される場合、アクセス情報パラメータは、挿入されない。本仕様の本リリースは、本パラメータにおける使用のための値を定義しない；
１１）アクセスタイプフィールドが、「３ＧＰＰ−Ｅ−ＵＴＲＡＮ−ＦＤＤ」または「３ＧＰＰ−Ｅ−ＵＴＲＡＮ−ＴＤＤ」に等しい場合、「ｕｔｒａｎ−ｃｅｌｌ−ｉｄ−３ｇｐｐ」パラメータは、ＵＥの下位層から取得される、ＭＣＣ、ＭＮＣ、ＴＡＣ（３ＧＰＰ ＴＳ ２３．００３に説明されるように）、および進化型セルグローバル識別（３ＧＰＰ ＴＳ ２３．４０１［７Ｂ］に説明されるように）の連結に設定され、以下のテキストストリングとして符号化される：
最上位ビットから開始し、ＭＣＣ（３桁）、ＭＮＣ（ＭＣＣ値に応じて、２または３桁）、ＴＡＣ（全１６進数表現を使用した１６ビットの固定長符号、および進化型セルグローバル識別（全１６進数表現を使用した２８ビットの固定長符号）と続く；
１１ａ）アクセスタイプフィールドが、「３ＧＰＰ−Ｅ−ＵＴＲＡＮ−ＦＤＤ」または「３ＧＰＰ−Ｅ−ＵＴＲＡＮ−ＴＤＤ」に等しい場合、ＮＷ提供ＶｏＩＭＳインジケータが、ＵＥの下位層から取得される場合、「ＮＷ提供ＶｏＩＭＳインジケータ」パラメータが、含まれる；
１２）アクセスタイプフィールドが、「ＩＥＥＥ−８０２．３」、「ＩＥＥＥ−８０２．３ａ」、「ＩＥＥＥ−８０２．３ｅ」、「ＩＥＥＥ−８０２．３ｉ」、「ＩＥＥＥ−８０２．３ｊ」、「ＩＥＥＥ−８０２．３ｕ」、「ＩＥＥＥ−８０２．３ａｂ」、「ＩＥＥＥ−８０２．３ａｅ」、ＩＥＥＥ−８０２．３ａｋ」、ＩＥＥＥ−８０２．３ａｑ」、ＩＥＥＥ−８０２．３ａｎ」、「ＩＥＥＥ−８０２．３ｙ」、「ＩＥＥＥ−８０２．３ｚ」または「ＩＥＥＥ−８０２．３ｙ」のうちの１つに設定され、ＮＡＳＳサブシステムが使用される場合、アクセス情報フィールドは、ＣＬＦから取得されたｅｔｈ−ｌｏｃａｔｉｏｎパラメータを含有する（ＮＡＳＳ機能的アーキテクチャ参照）。

注記２：他の使用の中でもとりわけ、上述の「ｃｇｉ−３ｇｐｐ」、「ｕｔｒａｎ−ｃｅｌｌ−ｉｄ−３ｇｐｐ」、「ｃｉ−３ｇｐｐ２」、「ｉ−ｗｌａｎ−ｎｏｄｅ−ｉｄ」、「ｅｔｈ−ｌｏｃａｔｉｏｎ」、および「ｄｓｌ−ｌｏｃａｔｉｏｎ」パラメータはまた、緊急サービスのために使用される場所識別子を構成する。

別の実施形態では、ＵＥは、選好の変更を示す。例えば、ユーザは、ＰＳを介してボイスを受信することから、ＣＳを介してボイスを受信するために、その選好を変更してもよい。ＳＣＣ ＡＳまたはＴＡＤＳは、ＵＥに対する選好変更およびボイスメディアを伴うセッションが存在する場合、サービス継続を行うことが可能である。選好変更は、ＵｔインターフェースおよびＸＣＡＰを使用して、またはＳＩＰメッセージを使用して示されることが可能である。例えば、ＵＥは、ＳＩＰ登録要求を使用して再登録し得るか、またはＵＥは、ＳＩＰアップデート要求またはＳＩＰ招待要求等のＳＩＰメッセージを伝送し得る（特定のセッションのみ、サービス継続を受信する必要がある場合（例えば、ＣＳドメインに転送される））。ＳＩＰメッセージは、選好を示すインジケータを含むことが可能である。インジケータは、ヘッダフィールド値またはＸＭＬ本文部分等の本文部分として、エンコード可能である。そのようなインジケータは、「ボイス中心」または「データ中心」、および「ＣＳボイス専用」、「ＩＭＳ ＰＳボイス専用」、「ＣＳボイス優先、ＩＭＳボイス二次優先」、あるいは「ＩＭＳボイス優先、ＣＳボイス二次優先」を含む値をとってもよい。特に、Ｐ−アクセス−ネットワーク−情報ヘッダフィールドは、そのようなインジケータを含むことが可能である。そのようなインジケータは、必ずしも、Ｅ−ＵＴＲＡＮのみに適用されない。インジケータはまた、表２に示される他のアクセスタイプおよびアクセスクラスに適用されてもよい。

別の実装では、インジケータは、１つ以上のインジケータまたはフラグを省略して、ＵＥによって黙示的に定義されてもよい。例えば、ＵＥは、ＳＩＰ法において、ある特徴タグ、例えば、特徴タグ「ｓｉｐ．ａｕｄｉｏ」を省略してもよい［ＲＦＣ ３８４０は、セッション開始プロトコル（ＳＩＰ）におけるユーザエージェント能力を示す］。ネットワークノード（例えば、ＳＣＣ ＡＳ）が、特徴タグの欠如を受信すると、ネットワークノードは、セッションがそのＵＥ上で着信される時、ＴＡＤＳ機能がこれを考慮することを知っている。

上述の両方の場合（明示的および黙示的信号伝達）、Ｐ−アクセス−ネットワーク−情報ヘッダフィールドは、特定のアクセス技術に関する特有の情報を含むように拡張されてもよい。

あるアクセス技術の場合、Ｐ−アクセス−ネットワーク−情報ヘッダフィールドは、「ＩＭＳボイスオーバＰＳセッション対応」インジケータを含むようにさらに拡張されてもよい。そのようなインジケータによって伝達可能な情報は、ブール値（例えば、インジケータの存在は、対応を意味し、不在は、未知または対応の欠如を意味する）であり得る；または３種類の情報が存在し得る：正の値に設定されたインジケータの存在は、対応を意味し、不在は、対応が未知であることを意味し、負に設定されたインジケータの存在は、対応の欠如を意味する。

ＵＥが、ボイスオーバＩＭＳのために構成される場合、ネットワーク内のＵＥおよびサービスドメイン選択（ＳＤＳ）機能性は、「ＩＭＳボイスオーバＰＳセッション対応表示」を考慮すべきである。ＩＭＳボイス呼（ＰＳドメイン内にボイスベアラを伴う）は、ＲＡＴのみを使用して配信されるはずであって、「ＩＭＳボイスオーバＰＳセッション対応表示」が適用され、対応を示す。

ＩＭＳがＲＡＴによって対応される時は常時、ボイス呼のために、ＩＭＳを使用するように構成されるＵＥの場合、ユーザサービスは、ＩＭ ＣＮサブシステムによって対応され、モバイル着信呼は、ＩＰマルチメディア（ＩＭ）コアネットワーク（ＣＮ）サブシステムにルーティングされるはずである。

ＩＭＳ ＡＳが、ＳＩＰメッセージにおいて、下位層の（例えば、ＮＡＳ層）対応を記述する情報または情報の変更を検出することに伴って（例えば、ＮＡＳレベルにおいて利用可能であって、対応を示す「ＩＭＳボイスオーバＰＳセッション対応表示」に関するＵＥ表示）、ＩＭＳ ＡＳは、関連表示を格納し、プロシージャにおける変更を達成してもよい。例えば、「ＩＭＳボイスオーバＰＳセッション対応」インジケータに関して受信した情報に応じて、ＩＭＳ ＡＳは、ＣＳドメインへのボイスメディア構成要素を含むモバイル着信ＳＩＰ呼を標的にしてもよい。いくつかの実装では、ＴＡＤＳ機能は、一般的には、本機能を提供する。

着信アクセスドメイン選択（ＴＡＤＳ）は、ＵＥへ着信セッションを配信するために使用されるＣＳアクセスおよび／または１つ以上のＰＳアクセスネットワークを選択する。ＴＡＤＳは、ＩＭＳ、および随意にＵＥ内に位置する機能性である。

着信セッションの場合、ＴＡＤＳは、常に、着信サービス後に行われる。Ｔ−ＡＤＳは、以下の要因（但し、それらに限定されない）を選択決定に考慮してもよい：１）回路交換（ＣＳ）ドメインにおけるＵＥの状態（この状態情報は、以下を含む：デタッチ、アタッチ）；２）ＩＭＳにおけるＵＥの状態（この状態情報は、以下を含む：登録、非登録）；３）ＵＥ能力；４）随意に、ＮＡＳレベルで利用可能であって、対応を示す、「ＩＭＳボイスオーバＰＳセッション対応表示」に関するＵＥ表示；５）ＩＣＳ対応のＵＥ表示；６）アクセスネットワーク能力；７）既存のセッションによって使用されるドメイン／アクセスタイプ；８）着信セッションに含まれるメディア構成要素；ならびに９）ユーザ選好およびオペレータポリシー。

加えて、Ｐ−アクセス−ネットワーク−情報ヘッダフィールドまたは別のヘッダフィールドは、「ボイス中心」または「データ中心」、および「ＣＳボイス専用」、「ＩＭＳ ＰＳボイス専用」、「ＣＳボイス優先、ＩＭＳボイス二次優先」、あるいは「ＩＭＳボイス優先、ＣＳボイス二次優先」を含む選好を示すように拡張されてもよい。ヘッダフィールドは、選好変更が生じると、ＳＩＰメッセージ内に含まれてもよい。そのようなＳＩＰメッセージは、ユーザが、特定のＳＩＰセッションのみのために、特定のアクセス（例えば、ＣＳ）を介して、ボイスメディアを受信することを選好するときに伝送されてもよい（ポリシーまたは選好の持続時間の間）。代替として、選好変更は、別のメッセージ内において、例えば、ＸＣＡＰプロトコルの一部として示されることが可能である。

図１３は、ＵＥとネットワークとの間の接続を確立するためのメッセージフローの図であって、ネットワークは、ＵＥによって所望されるサービスまたは特徴に対応せず、ＵＥは、非ボイスサービスに対して登録を行う。図１３では、ＵＥは、ＬＴＥ ＲＡＴを使用して（すなわち、ＧＥＲＡＮ／ＵＴＲＡＮ ＰＳまたはＥＰＣ／ＬＴＥを介して）、ＰＳドメインに接続する。ステップ２１０において、ＵＥは、ＬＴＥにアタッチするときに、ＮＡＳアタッチプロシージャまたはＮＡＳ複合アタッチプロシージャを行うか、あるいは別のアクセスからＬＴＥに移動するとき、または異なる追跡エリアに移動するときに、ＮＡＳ ＴＡＵ（追跡エリアアップデート）プロシージャまたはＮＡＳ複合ＴＡＵを行う。ＰＳドメインへの接続を獲得するための一部として、ＵＥは、ブロードキャストされる、または２地点間メッセージ（例えば、ＶｏＩＭＳおよびＳＲＶＣＣフラグ、インジケータ、または識別子の設定を含有する無線デバイスメッセージへのネットワーク）内に提供され得るフラグまたはインジケータによって、ＵＥが要求するサービスまたは機能性に非対応であることを発見する。

一実装では、ＵＥは、ＮＡＳアタッチプロシージャ、ＮＡＳ複合アタッチプロシージャ、追跡エリアアップデート（ＴＡＵ）プロシージャ、またはルーティングエリアアップデートプロシージャのいずれかとの接続を要求することによって、サービスあるいは機能性の欠如を発見してもよい。それに応答して、ＵＥが、プロシージャの正常な完了に応じて、ネットワークから受信する、あるメッセージは、ＶｏＩＭＳに非対応であることを示すフラグを含んでもよい。

次いで、ＵＥは、ステップ２１２において、上述で識別されたフラグ／インジケータを含むＩＭＳネットワークに登録してもよい。インジケータは、モバイル着信セッションを配信するための方法（例えば、ＩＭＳ ＡＳにおける着信アクセスドメイン選択（ＴＡＤＳ）機能）に関与するネットワークノードにパスされてもよい。

ＵＥが、任意の他のＳＩＰ法に関与する場合、ネットワークの特性が、上述のように、機構を使用して変更される場合、ＵＥは、任意の関連付けられたインジケータをアップデートしてもよい。

モバイル着信セッションが到着すると、セッションは、サービスをルーティングする方法の決定に関与するネットワークノードに配信される。ＴＡＤＳは、ＰＳドメインを介して登録されたＵＥが、所望のサービスに対応しないことを認知し得る。サービス対応の欠如は、ａ）ＩＭＳシステムに登録されたフラグまたはインジケータ、ｂ）ＴＡＤＳ内のオプションの構成データ設定、およびｃ）呼をルーティングする方法を決定するためにも使用され得る、さらなる基準のうちの１つ以上によって識別されてもよい。

次いで、ＴＡＤＳは、ＣＳドメイン内の無線デバイスの識別を含み得る代替の標的アドレスを選択してもよい（例えば、ＧＥＲＡＮ／ＵＴＲＡＮ ＣＳの場合、ＭＳＩＳＤＮ）。これは、ＨＳＳにクエリを行い、移動局ルーティング番号（ＭＳＲＮ）／ＣＳルーティング番号（ＣＳＲＮ）を取得し、正確なＭＳＣを特定するようにＩＭＳ ＡＳに要求し得る。次いで、セッションは、呼をＭＳＣにルーティングし、次いでＳＧインターフェースを介してＵＥを呼び出すことによって、従来のＣＳフォールバックプロシージャを使用して、無線デバイスに配信されてもよい。

本実施例では、議論は、主に、ＬＴＥおよびＧＥＲＡＮ／ＵＴＲＡＮを対象とするが、種々のＲＡＴは、以下のうちの１つ以上を含んでもよいが、それらに限定されない：

ＰＣＣは、それぞれ、ＬＴＥおよびＧＥＲＡＮ／ＵＴＲＡＮへのＮＡＳアタッチプロシージャ、追跡エリアアップデート、複合追跡エリアアップデート、およびルーティングエリアアップデートの際、ＥＰＣネットワークと相互作用するため、ＰＣＣは、それぞれ、ＴＡまたはＲＡに適用される、ＶｏＩＭＳインジケータを備えてもよい。例えば、１）ＴＡ ＵＥが、対応ＶｏＩＭＳにアタッチする場合、ＭＭＥは、ＶｏＩＭＳインジケータを「対応」に設定する。ＶｏＩＭＳに対応しない場合、ＭＭＥは、ＶｏＩＭＳインジケータを「非対応」に設定する。２）ＴＡ ＵＥが、対応ＶｏＩＭＳ内のＰＤＮ接続を確立する場合、ＭＭＥは、ＶｏＩＭＳインジケータを「対応」に設定する。ＶｏＩＭＳに対応しない場合、ＭＭＥは、ＶｏＩＭＳインジケータを「非対応」に設定するに設定する。３）ＴＡまたはＲＡ ＵＥが、対応ＶｏＩＭＳに移行する場合、ＭＭＥは、ＶｏＩＭＳインジケータを「対応」に設定するに設定する。ＶｏＩＭＳに対応しない場合、ＶｏＩＭＳインジケータを「非対応」に設定する。４）ＲＡ ＵＥが、対応ＶｏＩＭＳに移行する場合、ＳＧＳＮは、ＶｏＩＭＳインジケータを「対応」に設定する。ＶｏＩＭＳに対応しない場合、ＳＧＳＮは、ＶｏＩＭＳインジケータを「非対応」に設定する。５）ＲＡ ＵＥが、現在、対応ＶｏＩＭＳ内にキャンプオンしている場合、ＳＧＳＮは、ＶｏＩＭＳインジケータを「対応」に設定する。ＶｏＩＭＳに対応しない場合、ＳＧＳＮは、ＶｏＩＭＳインジケータを「非対応」に設定する。したがって、ＰＣＣは、常に、特有のＲＡＴおよびＵＥが位置するエリア内において、ＶｏＩＭＳの対応について通知され得る。

故に、本システムの一実装では、ＵＥによってＩＭＳインフラストラクチャに送信される、ＰＳドメインによるＶｏＩＭＳの対応を記述する情報は、ネットワーク内のＳＩＰサーバまたはＳＩＰプロキシによって、ポリシング、アサート、または訂正されてもよい（例えば、正確であるか否かを検証するため）。例えば、Ｐ−ＣＳＣＦは、ＰＣＣと相互作用してもよい。ＰＣＣ対応機能的要素から受信した応答に基づいて、Ｐ−ＣＳＣＦは、Ｐ−アクセス−ネットワーク−情報ヘッダフィールド値をポリシング、アサート、または訂正してもよい。したがって、ネットワークは、呼を適切に配信する方法を認知し得る。本システムの実装は、本開示を通して論じられた種々の実装のうちの任意の１つと併用して、または分離されて実装されてもよいことに留意されたい。

本システムのいくつかの実装では、競合条件が存在してもよい。ボイスまたは音声メディア構成要素を伴うモバイル着信ＳＩＰ要求は、下位層の対応に関するＵＥの情報（例えば、「ＩＭＳボイスオーバＰＳセッション対応」インジケータを示す）が、未だＩＭＳ ＡＳの関連表示（すなわち、ＵＥがＩＭＳ ＡＳに提供した情報）内でアップデートされていない間、ＩＭＳ ＡＳによって受信され得る。その結果、ボイスまたは音声メディア構成要素を伴う、モバイル着信ＳＩＰ要求に適用されるプロシージャは、不適切であり得る。

下位層対応に関するＵＥの情報が変更すると直ぐに、ＳＩＰメッセージを送信することをＵＥに要求することによって、プロシージャが不適切であり得る時間ウィンドウを低減させる。実施例として、ＳＩＰメッセージは、例えば、ＳＩＰ登録要求を使用してＳＩＰ登録のリフレッシュを生成してもよい。ＵＥはまた、ＩＵＴまたはリダイレクションを適用し、従来のボイス表示を伴う要求を要求された能力に対応するインターフェースに転送してもよい。代替として、ＰＣＣ機能的要素は、リソースの可用性の欠如によるサービスへの対応不能を信号伝達してもよい。

上述のように、特定のネットワーク実装のＩＭＳ機能的要素は、アクセスネットワークによって対応されるサービスを記述する最新情報を常に有していない場合ある。したがって、ＵＥがＩＣＳ対応ＵＥである一システム実装では、ＵＥは、モバイル着信（ＭＴ）呼が、ＩＭＳまたはＣＳを介して配信されるか否かに関する最終決定を行う。ＩＭＳ登録の際、ＵＥは、ＵＥがＩＣＳに対応する能力を有することをＩＭＳに信号伝達する。

登録後、モバイル着信呼がＩＭＳに到達すると、ＳＣＣ ＡＳは、ＩＰ ＲＡＴ（ＥＰＣまたはＧＥＲＡＮ／ＵＴＲＡＮ ＰＳ）を介したメディアの配信のためのＳＤＰメディア構成要素、および／またはＣＳドメインを介したメディアの配信のためのインジケータを含み得る、ＳＩＰ要求をＵＥに送信してもよい。本実施例では、ＳＣＣ ＡＳは、常に、ＣＳドメインを介したメディアの配信のための付加的ＳＤＰメディア構成要素を含む。次いで、ＵＥは、ボイスソリューション（例えば、ＧＥＲＡＮまたはＵＴＲＡＮにアクセスするためのＶｏＩＭＳフラグおよび能力）の可用性に関する、ＵＥが有する情報に基づいて、最終的に、モバイル着信セッションを受信するための使用するドメインを決定する。ＵＥが、ＩＣＳメディアタグの含有によってＩＣＳに対応するための表示を含まない場合、ＩＭＳ ＡＳは、ＣＳをボイスベアラのために使用可能にするＳＤＰを挿入する必要はない。

本アプローチは、ネットワークが標的ＵＥのための「ＩＭＳボイスオーバＰＳセッション対応」インジケータの値を認知している場合と比較して、付加的ＳＩＰメッセージ交換を必要とし得ることに留意されたい。

ＩＭＳサービス集中継続性が使用されない場合と、ＣＳドメインおよびＩＭＳの両方に加入している場合、ＵＥは、ＣＳドメインにアタッチされ、ＰＳドメインは、モバイル着信セッションをＵＥに配信するように選択されるが、以下の理由のいずれかのために、配信は失敗する：１）ＵＥによる使用時のＲＡＴでは、「ＩＭＳボイスオーバＰＳセッション対応表示」が対応を示さないか、または利用可能ではないので、ＵＥは、（ＰＳドメインにおけるボイスベアラによる）ＩＭＳボイス呼の配信を拒絶する、または２）ＲＡＴでは、「ＩＭＳボイスオーバＰＳセッション対応表示」が対応を示さないか、または利用可能ではなく、したがって、ＩＭＳに到達したセッションは、本明細書に説明されるように、ＣＳドメインにルーティングされる必要があり得るので、ＥＰＣは、ＩＭＳボイス呼のために要求されるベアラの確立を拒絶する。

図１４は、ＵＥとネットワークとの間の接続を確立するためのメッセージフローの図であって、ＵＥは、ネットワークによって提供されるサービスまたは機能インジケータを考慮する（例えば、ＲＡＴにアタッチすると、ネットワークから取得されるＶｏＩＭＳインジケータ）。

ステップ２２０では、ＵＥは、ＮＡＳアタッチプロシージャまたはＮＡＳ複合アタッチプロシージャを行う。ＵＥは、ステップ２２２において、一般的な特徴タグを含むが、ＶｏＩＭＳインジケータに関連する表示を含まないＩＭＳシステムに登録する。特徴タグまたはインジケータのうちの１つは、ＩＣＳ特徴タグであってもよい。ネットワークモード、例えば、ＳＣＣ ＡＳが、登録メッセージを受信すると、ＳＣＣ ＡＳは、受信した情報を第三者登録（例えば、ＩＣＳ特徴タグ）に格納する。ＳＣＣ ＡＳは、着信呼を受信すると、ＵＥまたはＰ−ＣＳＣＦがＬＴＥ型ＲＡＴを示すＰ−アクセス−ネットワーク−情報ヘッダを含み得るので、着信呼を受信するＵＥがＬＴＥ上に登録されていることを認知し得る。しかしながら、ＳＣＣ ＡＳが、上述のように、オプション構成ドメイン情報を受信しない限り、ＳＣＣ ＡＳは、ＬＴＥネットワークがＩＭＳボイスに対応するか否か分からない場合がある。その結果、ＴＡＤＳは、ＬＴＥ ＵＥ標的を選択し得る。ＬＴＥ（または、一般に、ＰＳドメイン）が、着信呼を配信するために選択される場合、ＵＥは、任意のドメイン構成情報が提供されず、ＵＥはＩＭＳに登録されるので、ＩＭＳ ＡＳは、ＩＣＳ特徴タグが含まれていると仮定して、ボイスアクセするために、ＣＳおよびＬＴＥの両方に対応するメディアラインを含有する、ＳＤＰオファーを構築するであろう。そうでなければ、ＳＤＰオファーのＣＳ部分は、省略されてもよい。オファーのＣＳ部分を含有するＩＮＶＩＴＥの実施例は、以下の表４に例示される。

ＳＩＰ ＩＮＶＩＴＥの受信に応じて、ＵＥは、受信したＳＤＰオプションをＵＥのオプションに対して分析し、ＵＥのボイス設定およびＵＥの使用設定を考慮して、ＰＳドメインおよびＣＳドメインを介した所望のサービスに対応する（例えば、ＣＳおよびＩＰに対応するボイスのためのＳＤＰによるＩＮＶＩＴＥの受信に応じて（ＬＴＥを介して）、ＵＥは、これをＶｏＩＭＳフラグおよびＳＲＶＣＣフラグの設定と比較し、呼の処理方法を決定する（ＬＴＥネットワークを介して呼を受理するか、またはＣＳを介して発呼し、呼を読み出す）。

図１５は、コンパレータの機能性（ＴＡＤＳ機能）の概略図を示す図である。コンパレータ２３０は、入力Ａ ２３２およびＢ ２３４を含む。一実装では、入力Ａ ２３２は、ＵＥボイス設定に配分され、入力Ｂ ２３４は、ＵＥ使用設定に配分される。付加的入力は、ＳＩＰ ＩＮＶＩＴＥメッセージ（ＳＤＰは、サービスのために現在のＲＡＴおよび代替ＲＡＴを使用する能力を含有する）（入力２３６）、二重転送モードのようなサービスに対応するためのＲＡＴ ２メッセージ（ＤＴＭ、ＩＭＳ等）（入力２３８）、およびＲＡＴ １インジケータ（サービスは、本ＲＡＴ上で利用可能ではない、例えば、ＶｏＩＭＳがない）（入力２４０）のために定義される。入力に基づいて、コンパレータ２３０は、ＳＩＰ応答２４２を出力するように構成される。図１５は、コンパレータ２３０の一特有の実装を例示するが、コンパレータの種々の能力は、ブロードキャスト情報によって、または２地点間メッセージから読み出された情報の受信を含んでもよい。ブロードキャスト情報は、ＤＴＭ、ＧＰＲＳ、ＥＤＧＥ等に対する対応であり得るが、それらに限定されない。２地点間情報は、「ＶｏＩＭＳ対応」、「ＳＲＶＣＣ対応」等であり得るが、それらに限定されない。

本システムの一実装では、以下の疑似コードは、ＶｏＩＭＳフラグが負の方向に設定されるときのＵＥの動作について記述するために使用されてもよいが、ＵＥが非対応であるＳＲＶＣＣを所望する場合にも同様に適用され得る。

表５の疑似コードでは、エラー原因は、ＳＤＰのいずれもＯＫでないことを示し得る。その場合、ＵＥは、少なくとも、ＳＤＰ−ＣＳを含む、ＵＥが受理するであろうＳＤＰのリストを含み得る。ＩＭＳ ＡＳは、エラーメッセージの受信に応じてＳＤＰ−ＣＳをＵＥに返し得る。

以下の疑似コードは、ＶｏＩＭＳフラグが正の方向に設定されるとき、ＵＥが実装し得る、一連のステップの一実施例である。

３ＧＰＰ ＴＳ ２４．２９２において実装される上述の実施例は、以下に示される：
ＩＣＳ ＵＥが、初期 ＳＩＰ ＩＮＶＩＴＥ要求内において、ＳＤＰオファー受信すると、ＵＥが、オーディオセッションのためにＲＴＰベースのＩＰベアラまたはＣＳベアラの使用を選択可能となり、すなわち、オーディオメディアラインに対して、以下が設定される：
−メディアライン内の転送プロトコルは、ＲＴＰベースのＩＰベアラに設定される；
−関連接続ラインは、ＩＰアドレスに設定される；および
−ｄｒａｆｔ−ｉｅｔｆ−ｍｍｕｓｉｃ−ｓｄｐ−ｃａｐａｂｉｌｉｔｙ−ｎｅｇｏｔｉａｔｉｏｎ［４０］、ｄｒａｆｔ−ｇａｒｃｉａ−ｍｍｕｓｉｃ−ｓｄｐ−ｍｉｓｃ−ｃａｐ［３９］、ｄｒａｆｔ−ｉｅｔｆ−ｍｍｕｓｉｃ−ｓｄｐ−ｃｓ［３６］、および ｄｒａｆｔ−ｉｅｔｆ−ｍｍｕｓｉｃ−ｓｄｐ−ｍｅｄｉａ−ｃａｐａｂｉｌｉｔｉｅｓ［４１］において定義される付加的ａ−ラインは、以下を示す：
−メディア能力属性「ｍｃａｐ」は、「−」に設定される；
−転送プロトコル能力属性「ｔｃａｐ」は、「ＰＳＴＮ」に設定される；および
−接続 データ能力属性「ｃｃａｐ」は、「ＰＳＴＮ」に設定され、「Ｅ．１６４」をアドレスタイプとして示しおよびアドレスは、ＳＣＣ ＡＳ ＰＳＩ ＤＮに設定され；
ＩＣＳ ＵＥが ＴＡＤＳ実行に対応し、ＩＣＳ ＵＥは、
ａ）ＵＥが、ＬＴＥ上にあって、ＵＥが、
ａ．ＣＳ専用であって、正常な複合アタッチを行っている場合、ＵＥは、ＣＳベアラを使用する。

ｂ．ＣＳ専用であって、正常な複合アタッチを行っていない場合、ＩＣＳ ＵＥは、６０６（受理不可）を返信する。

ｉ．代替として、フラグを介したＶｏＩＭＳが設定されている場合、ＵＥは、ＲＴＰベースのＩＰベアラを使用する。

ｉｉ．代替として、フラグを介したＶｏＩＭＳが設定されていない場合、ＩＣＳ ＵＥは、６０６（受理不可）を返信する。

ｃ．ＣＳ優先であって、正常な複合アタッチを行っている場合、ＵＥは、ＣＳベアラを使用する。

ｉ．代替として、ＣＳ優先であって、正常な複合アタッチを行っており、フラグを介したＶｏＩＭＳが設定されるが、しかしながら、ＳＤＰが、他のメディアならびにボイスを含有する場合、ＵＥは、ＲＴＰベースのＩＰベアラを使用する。

ｄ．ＣＳ優先であって、正常な複合アタッチを行っておらず、ＶｏＩＭＳインジケータが設定され、
ｉ．ＵＥが、３ＧＰＰ ＴＳ ２４．３０１に説明されるように、ＥＰＣアタッチにおいて、ＳＲＶＣＣを所望することを示し、ＳＲＶＣＣが利用可能である場合、ＵＥは、ＲＴＰベースのＩＰベアラを使用する。

ｉｉ．ＵＥが、３ＧＰＰ ＴＳ ２４．３０１に説明されるように、ＳＲＶＣＣを所望することを示し、ＳＲＶＣＣが利用可能ではない場合、ＩＣＳ ＵＥは、６０６（受理不可）を返信する。

ｉｉｉ．ＵＥが、３ＧＰＰ ＴＳ ２４．３０１に説明されるように、ＳＲＶＣＣを所望しないことを示す場合、ＵＳは、ＲＴＰベースのＩＰベアラを使用する。

ｅ．ＣＳ優先であって、正常な複合アタッチを行っておらず、ＶｏＩＭＳインジケータが設定されていない場合、ＩＣＳ ＵＥは、６０６（受理不可）を返信する。

ｆ．ＩＭＳ専用であって、ＶｏＩＭＳインジケータが設定され、
ｉ．ＵＥが、３ＧＰＰ ＴＳ ２４．３０１に説明されるように、ＥＰＣアタッチにおいて、ＳＲＶＣＣを所望し、ＳＲＶＣＣが利用可能である場合、ＵＥは、ＲＴＰベースのＩＰベアラを使用する。

ｉｉ．ＵＥが、３ＧＰＰ ＴＳ ２４．３０１に説明されるように、ＥＰＣアタッチにおいて、ＳＲＶＣＣを所望することを示し、ＳＲＶＣＣが利用可能ではない場合、ＩＣＳ ＵＥは、６０６（受理不可）を返信する。

ｉｉｉ．ＵＥが、３ＧＰＰ ＴＳ ２４．３０１に説明されるように、ＳＲＶＣＣを所望しないことを示す場合、ＵＳは、ＲＴＰベースのＩＰベアラを使用する。

ｇ．ＩＭＳ専用であって、ＶｏＩＭＳインジケータが設定されていない場合、ＩＣＳ ＵＥは、６０６（受理不可）を返信する。

ｈ．ＩＭＳ優先であって、ＶｏＩＭＳインジケータが設定され、
ｉ．ＵＥが、３ＧＰＰ ＴＳ ２４．３０１に説明されるように、ＥＰＣアタッチにおいて、ＳＲＶＣＣを所望することを示し、ＳＲＶＣＣが、利用可能である場合、ＵＥは、ＲＴＰベースのＩＰベアラを使用する。

ｉｉ．ＵＥが、３ＧＰＰ ＴＳ ２４．３０１に説明されるように、ＥＰＣアタッチにおいて、ＳＲＶＣＣを所望することを示し、ＳＲＶＣＣが、利用可能ではなく、
１．ＵＥが正常な複合アタッチを行った場合、ＣＳベアラを使用する。

２．ＵＥが正常な複合アタッチを行っていない場合、ＩＣＳ ＵＥは、６０６（受理不可）を返信する。

ｉｉｉ．ＵＥが、３ＧＰＰ ＴＳ ２４．３０１に説明されるように、ＳＲＶＣＣを所望しないことを示す場合、ＵＳは、ＲＴＰベースのＩＰベアラを使用する。

ｉ．ＩＭＳ優先であって、ＶｏＩＭＳインジケータが設定されておらず、正常な複合アタッチを行っている場合、ＵＥは、ＣＳベアラを使用する。

ｂ）ＵＥが、ローカル構成およびネットワーク条件に基づいて、ＧＥＲＡＮ／ＵＴＲＡＮ上にある場合、関連オーディオメディアストリームに対して、ＲＴＰベースのＩＰベアラまたはＣＳベアラを使用するか否かを決定する。

ＩＣＳ ＵＥが、ＲＴＰベースのＩＰベアラを使用することを決定する場合、ＩＣＳ ＵＥは、第１０．２．２．２項に説明されるように続行し、加えて、ｄｒａｆｔ−ｉｅｔｆ−ｍｍｕｓｉｃ−ｓｄｐ−ｃａｐａｂｉｌｉｔｙ−ｎｅｇｏｔｉａｔｉｏｎ［４０］に従って、ＲＴＰベースのＩＰベアラがＳＤＰアンサー内で使用されることを示す。

ＩＣＳ ＵＥが、ＣＳベアラを使用することを決定する場合、ＩＣＳ ＵＥは、第１０．２．２．３項に説明されるように続行し、加えて、ｄｒａｆｔ−ｉｅｔｆ−ｍｍｕｓｉｃ−ｓｄｐ−ｃａｐａｂｉｌｉｔｙ−ｎｅｇｏｔｉａｔｉｏｎ［４０］に従って、ＣＳベアラがＳＤＰアンサー内で使用されることを示す。

図１６は、ＵＥとネットワークとの間の接続を確立するためのメッセージフローの図であって、ＵＥは、ＵＥがＣＳフォールバックのための正常な登録を有する場合、ＩＭＳ ＡＳをトリガし、ＳＤＰ−ＣＳを含むように使用される特徴タグを含む。ＣＳフォールバックが成功しない場合、特徴タグは含まれなくてもよい。

特徴タグは、ＩＭＳ ＡＳへのＳＩＰ登録において転送されてもよい。本事例では、ＳＣＣ ＡＳ挙動は、タグの含有によって変更されてもよい。タグが含まれ、ＩＣＳ対応タグが存在する場合、ＩＭＳ ＡＳは、ＣＳ部分（ｄｒａｆｔ−ｉｅｔｆ−ｍｍｕｓｉｃ−ｓｄｐ−ｃｓ参照）を伴うＳＤＰを含有するＵＥに対して、ＳＩＰメッセージを構築してもよい。しかしながら、ＣＳフォールバックタグが含まれない場合、ＣＳ部分を伴うＳＤＰは含まれる必要がない。

多くのネットワーク実装では、ＶｏＩＭＳインジケータは、それぞれ、初期アタッチおよび／またはＴＡＵおよび／または複合ＴＡＵおよび／またはＲＡアップデートの際に、ＭＭＥまたはＳＧＳＮによってＵＥに与えられる。その結果、ＶｏＩＭＳが、ＭＭＥおよびＳＧＳＮによってＵＥに提供されると、ＭＭＥおよびＳＧＳＮは、ＩＭＳボイスが、それぞれ、特有のＴＡまたはＲＡを介して対応可能であるか否かを認知する。

モバイル着信呼が、ＩＭＳに到達し、ＵＥがＩＭＳに登録されると、呼は、ＵＥにルーティングされてもよい。ＵＥが、ＩＭＳを使用して／ＰＳドメインを介して、ルーティングされる呼を受理すると、ＩＭＳは、ベアラのアクティブ化のための必要無線ベアラを確立する必要があり、ＩＭＳは、ＰＣＣと相互作用し、それを行ってもよい。

本システムの一実装では、ＰＣＣが、それぞれ、ＮＡＳアタッチ、追跡エリアアップデート、ルーティングエリアアップデート、およびＧＥＲＡＮ／ＵＴＲＡＮにおけるＰＤＰコンテキストアクティブ化の際に、ＥＰＣと相互作用するので、ＰＣＣは、それぞれ、ＴＡまたはＲＡに適用するＶｏＩＭＳインジケータを備えてもよい。その結果、ＰＣＣは、常に、ＵＥが位置する特有のＲＡＴおよびエリア内のＶｏＩＭＳに対応することを通知され得る。

ＩＭＳからの要求着信に基づいて、ＵＥが、ＩＭＳを使用して／ＰＳドメインを介してルーティングされる呼を受理後、ＩＭＳが、ＰＣＣと相互作用し、サービスのためのベアラを確立すると、ＰＣＣは、サービスに対応可能であるか否かを決定し（例えば、ＰＣＣ内に格納されたＶｏＩＭＳインジケータの値に応じて）、ＩＭＳ要求を受理または拒絶してもよい。ＩＭＳはさらに、拒絶の理由または説明を提供してもよい。拒絶の任意のそのような理由または説明に応答して、ＩＭＳは、ＣＳドメインを介して、モバイル着信呼をＵＥにルーティングすることを決定してもよい。多くの場合、ドメインまたはＲＡＴが利用可能ではない場合、セッションまたは呼は、例えば、ボイスメールにルーティングされてもよいことに留意されたい。

ＵＥのためのベアラを確立するために、ＥＰＣは、ＰＣＣと相互作用し、ベアラのＱｏＳのポリシングを行ってもよい。ベアラ確立プロシージャは、ＵＥが、ＬＴＥへのＮＡＳアタッチ、ＧＥＲＡＮ／ＵＴＲＡＮを介したＰＤＰコンテキスト要求プロシージャ、および／またはＵＥ要求ＰＤＮ接続プロシージャを行うと生じてもよい。そのような相互作用の際、ＰＣＣは、ＶｏＩＭＳインジケータの値が提供されてもよい。

ＵＥがＩＭＳ／ＰＳドメインを介してルーティングされた呼を受理後に、ＩＭＳがＰＣＣと相互作用し、サービスのためのベアラを確立後、ＰＣＣは、ＥＰＣまたはＧＰＲＳコアネットワークと相互作用し、必要ベアラを確立するか、あるいは既存のベアラを修正してもよい。ＵＥがサービスに非対応であるエリア内に位置する場合（例えば、ＴＡまたはＲＡのためのＶｏＩＭＳインジケータがＶｏＩＭＳに非対応であることを示す）、ＵＥは、要求を拒絶し、ＰＣＣに拒絶理由を通知してもよい。次いで、ＰＣＣは、ＩＭＳ要求を拒絶し、随意に、拒絶理由を提供してもよい。拒絶理由に応答して、ＩＭＳは、ＣＳドメインを介してモバイル着信呼をＵＥにルーティングすることを決定してもよい。

図１７は、ＵＥとネットワークとの間の接続を確立するためのメッセージフローの図であって、ＵＥは、ＶｏＩＭＳインジケータを検査し、呼配信がＯｐＶｏｉｃｅソリューションを介して生じるべきであることを示す。本システムのいくつかの実装では、ＵＥは、ＮＡＳアタッチまたはＮＡＳ複合アタッチを行う。その後、ＵＥは、それぞれ、ステップ２７２および２７４において、ＯｐＶｏｉｃｅ登録ならびにＡｐｐＩＭＳ登録を行う。ＵＥが、正常にＮＡＳ複合アタッチを行う場合が、ＣＳフォールバックは、ステップ２７６において、ＯｐＶｏｉｃｅインフラストラクチャを通してＯｐＶｏｉｃｅセッションを配信するために使用可能である。代替として、ＵＥが、ＮＡＳアタッチを行う場合、ＵＥは、ＬＴＥに接続している間、ＯｐＶｏｉｃｅソリューション（例えば、ＶｏＬＧＡ）に登録を行うことが可能である。モバイル着信ＯｐＶｏｉｃｅ呼は、ＯｐＶｏｉｃｅインフラストラクチャに配信され、ＵＥにルーティングされてもよい（例えば、ＬＴＥを介してＶｏＬＧＡを使用するか、またはＣＳフォールバックプロシージャをトリガする）。モバイル着信ＡｐｐＶｏｉｃｅ呼は、ＡｐｐＩＭＳインフラストラクチャに配信され、ＵＥにルーティングされる。ＵＥが、ステップ２７８において、ＶｏＩＭＳインジケータに基づいて、ＩＭＳを介して呼を配信不可能であることを決定すると、ＵＥは、ステップ２８０において、それをＯｐＶｏｉｃｅソリューションに転送することによって呼を配信することをＡｐｐＩＭＳに示してもよい（ＣＳフォールバック、ＣＳ呼、または、例えば、ＶｏＬＧＡに基づくことが可能である）。表示ＵＥが、ＳＩＰ法、例えば、ＩＮＶＩＴＥを受信し、適切な応答、例えば、３ｘｘ応答または特に、表７に例示される３０２（一時的移動）応答で返信することによって達成されてもよい。

一実装では、ＵＥがこの場所においてサービスに対応するために一時的に利用不可能であり得るので、３０２メッセージが使用される。したがって、３０２メッセージは、ＯｐＶｏｉｃｅサービスの場所を提供してもよい（すなわち、ＯｐＶｏｉｃｅサービスを提供するエンティティの宛先アドレス、例えば、ＣＳフォールバックあるいはＶｏＬＧＡまたはＣＳサービスの場合、ＭＳＣ）。メッセージ３００および３８０もまた、使用されてもよい。ＵＥが、ＯｐＶｏｉｃｅサービスを提供するエンティティの宛先アドレスとともに構成されていない場合、ＵＥは、応答内に代替インジケータを含んでもよい（例えば、ＸＭＬ本文）。一例示的ＸＭＬ本文は、３ＧＰＰ ＴＳ ２４．２２９のａｐｐｌｉｃａｔｉｏｎ／３ｇｐｐ−ｉｍｓ＋ｘｍｌに基づいてもよい：

上述のＸＭＬ本文では、インジケータ＜ｖｏｌｇａ／＞は、ＳＩＰ本体（一部）としてＳＩＰメッセージ内に含まれるとき、ＭＩＭＥタイプａｐｐｌｉｃａｔｉｏｎ／３ｇｐｐ−ｉｍｓ＋ｘｍｌであるＸＭＬドキュメント内に含まれてもよい。３ｇｐｐ−ｉｍｓ要素内のスキーマバージョンＭＩＭＥタイプパラメータおよびバージョン属性は、「１」以外の値に設定されることが可能である。その場合、＜ｖｏｌｇａ／＞インジケータの含有は、ＵＥがＶｏｌｇａプロシージャに従って呼を処理することを所望することをネットワークに通知してもよい。

ＩＭＳ ＡＳが、応答（例えば、インジケータ＜ｖｏｌｇａ／＞を伴う３０２応答）を受信すると、ＩＭＳ ＡＳは、ＳＩＰ ＩＮＶＩＴＥ要求等のモバイル着信呼要求を宛先ヘッダにアドレスされたエンティティに送信してもよい（例えば、ＶＡＮＣのようなＶ ｏＬＧＡエンティティに接続されるＭＳＣ）。次いで、ＶＡＮＣは、ＶｏＬＧＡモバイル着信呼のためのプロシージャに従ってもよい。

次に、図１８を参照すると、例示的なＵＥ８００の実施形態を含む無線通信システムが例示される。ＵＥは、本開示の側面を実施するために動作可能であるが、本開示は、これらの実装に限定されるべきではない。携帯電話として例示されるが、ＵＥは、無線ハンドセット、ポケットベル、携帯端末（ＰＤＡ）、ポータブルコンピュータ、タブレットコンピュータコンピュータ、ラップトップコンピュータ、スマートフォン、プリンタ、ファックス機器、テレビ、セットトップボックス、および他のビデオディスプレイデバイス、家庭用オーディオ機器および他の家庭用娯楽システム、家庭用監視および制御システム（例えば、家庭用監視、アラームシステム、および温度調節システム）、ならびにコンピュータ制御式冷蔵庫等の進化型家庭用器具を含む種々の形態をとってもよい。多くの好適なデバイスは、これらの機能の一部または全部を組み合わせる。本開示のいくつかの実施形態では、ＵＥ８００は、ポータブル、ラップトップ、またはタブレットコンピュータのような汎用コンピューティングデバイスではなく、むしろ、携帯電話、無線ハンドセット、ポケットベル、ＰＤＡ、または車載電気通信デバイス等の汎用通信デバイスである。ＵＥ８００はまた、デスクトップコンピュータ、セットトップボックス、またはネットワークノード等、類似能力を有するが、可搬性ではない、デバイスである、デバイスを含む、あるいはデバイス内に含まれてもよい。ＵＥ８００は、ゲーム、在庫管理、ジョブ制御、および／またはタスク管理機能等、特殊アクティビティに対応してもよい。

ＵＥ８００は、ディスプレイ７０２を含む。ＵＥ８００はまた、ユーザによる入力のための、概して７０４と称されるタッチセンサ式表面、キーボード、または他の入力キーを含む。キーボードは、ＱＷＥＲＴＹ、Ｄｖｏｒａｋ、ＡＺＥＲＴＹ、および連続式、また電話キーパッドと関連付けられたアルファベット文字を伴う、従来の数字キーパッド等、完全または減少数の英数字キーボードであってもよい。入力キーは、内向きに押下され、さらなる入力機能を提供し得るトラックウィール、終了またはエスケープキー、トラックボール、および他のナビゲーションまたは機能的キーを含んでもよい。ＵＥ８００は、ユーザが選択するためのオプション、ユーザが作用させるための制御、および／またはユーザが指示するためのカーソルあるいは他のインジケータを提示してもよい。

ＵＥ８００はさらに、ダイヤル番号またはＵＥ８００の動作を構成するための種々のパラメータ値を含む、ユーザからのデータ入力を受理してもよい。ＵＥ８００はさらに、ユーザコマンドに応答して、１つ以上のソフトウェアまたはファームウェアアプリケーションを実行してもよい。これらのアプリケーションは、ユーザ相互作用に応答して、種々のカスタマイズされた機能を果たすように、ＵＥ８００を構成してもよい。加えて、ＵＥ８００は、例えば、無線基地局、無線アクセスポイント、またはピアＵＥ８００から、無線でプログラムおよび／または構成されてもよい。

ＵＥ８００によって実行可能な種々のアプリケーションは、ディスプレイ７０２にウェブページの表示を可能にするウェブブラウザである。ウェブページは、無線ネットワークアクセスノード、中継塔、ピアＵＥ８００、あるいは任意の他の無線通信ネットワークまたはシステム７００との無線通信を経由して、取得されてもよい。ネットワーク７００は、インターネット等の有線ネットワーク７０８に連結される。無線リンクおよび有線ネットワークを経由して、ＵＥ８００は、サーバ７１０等、種々のサーバ上の情報へのアクセスを有する。サーバ７１０は、ディスプレイ７０２上に示され得るコンテンツを提供してもよい。代替として、ＵＥ８００は、中継式またはホップ式接続において、中間体として作用するピアＵＥ８００を通してネットワーク７００にアクセスしてもよい。

図１９は、ＵＥ８００のブロック図を示す。ＵＡ１０の種々の周知の構成要素が図示されているが、ある実施形態では、列挙された構成要素および／または列挙されない付加的構成要素のサブセットが、ＵＥ８００内に含まれてもよい。ＵＥ８００は、デジタル信号プロセッサ（ＤＳＰ）８０２およびメモリ８０４を含む。示されるように、ＵＥ８００はさらに、アンテナおよびフロントエンドユニット８０６、無線周波数（ＲＦ）送受信機８０８、アナログベースバンド処理ユニット８１０、マイクロホン８１２、イヤホンスピーカ８１４、ヘッドセットポート８１６、入力／出力インターフェース８１８、リムーバブルメモリカード８２０、ユニバーサルシリアルバス（ＵＳＢ）ポート８２２、短距離無線通信サブシステム８２４、アラート８２６、キーパッド８２８、液晶ディスプレイ（ＬＣＤ）を含んでもよく、タッチセンサ式表面８３０、ＬＣＤコントローラ８３２、電荷結合素子（ＣＣＤ）カメラ８３４、カメラコントローラ８３６、および全地球測位システム（ＧＰＳ）センサ８３８を含み得る。ある実施形態では、ＵＥ８００は、タッチセンサ式画面を提供しない別の種類のディスプレイを含んでもよい。ある実施形態では、ＤＳＰ８０２は、入力／出力インターフェース８１８を通過せず、メモリ８０４と直接通信してもよい。

ＤＳＰ８０２またはいくつかの他の形態のコントローラあるいは中央演算装置は、メモリ８０４内に格納されているか、またはＤＳＰ８０２自体内に含有されるメモリ内に格納されているか、埋め込まれたソフトウェアあるいはファームウェアに従って、ＵＥ８００の種々の構成要素を制御するように動作する。埋め込まれたソフトウェアまたはファームウェアに加え、ＤＳＰ８０２は、メモリ８０４内に格納されているか、あるいはリムーバブルメモリカード８２０のようなポータブルデータ記憶メディア等の情報搬送メディアを経由して、もしくは有線または無線ネットワーク通信を経由して、他のアプリケーションを実行してもよい。アプリケーションソフトウェアは、所望の機能性を提供するようにＤＳＰ８０２を構成する、コンパイルされた機械可読命令を備えてもよく、またはアプリケーションソフトウェアは、ＤＳＰ８０２を間接的に構成するためのインタプリタまたはコンパイラによって処理される高次ソフトウェア命令であってもよい。

アンテナよびフロントエンドユニット８０６は、無線信号と電気信号とを変換するように提供され、ＵＥ８００が、セルラーネットワークまたはいくつかの他の利用可能な無線通信ネットワークから、あるいはピアＵＥ８００から、情報を送受信可能にしてもよい。ある実施形態では、アンテナよびフロントエンドユニット８０６は、ビーム形成および／または多重入力多重出力（ＭＩＭＯ）動作に対応するための多重アンテナを含んでもよい。当業者に周知のように、ＭＩＭＯ動作は、困難なチャネル条件を克服する、および／またはチャネルスループットを増加させるために使用可能である空間的多様性を提供し得る。アンテナおよびフロントエンドユニット８０６は、アンテナ同調および／またはインピーダンス整合構成要素、ＲＦ電力増幅器、および／または低雑音増幅器を含んでもよい。

ＲＦ送受信機８０８は、周波数シフト、受信したＲＦ信号のベースバンドへの変換、およびベースバンド伝送信号のＲＦへの変換を提供する。いくつかの説明では、無線送受信機またはＲＦ送受信機は、変調／復調、符号化／復号化、インターリービング／デインターリービング、拡散／逆拡散、高速フーリエ逆変換（ＩＦＦＴ）／高速フーリエ変換（ＦＦＴ）、サイクリックプレフィックス付加／除去、および他の信号処理機能等の他の信号処理機能性を含むように理解され得る。明確にするために、ここでの説明は、この信号処理の説明をＲＦおよび／または無線段階と分離し、その信号処理をアナログベースバンド処理ユニット８１０および／またはＤＳＰ８０２あるいは他の中央演算装置に概念的に配分する。いくつかの実施形態では、ＲＦ送受信機８０８、アンテナおよびフロントエンド８０６の一部、ならびにアナログベースバンド処理ユニット８１０は、１つ以上の処理ユニットおよび／または特定用途向け集積回路（ＡＳＩＣ）内に組み合わされてもよい。

アナログベースバンド処理ユニット８１０は、入力および出力の種々のアナログ処理、例えば、マイクロホン８１２およびヘッドセット８１６からの入力ならびにイヤホン８１４およびヘッドセット８１６への出力のアナログ処理を提供してもよい。この目的のために、アナログベースバンド処理ユニット８１０は、ＵＥ８００を携帯電話として使用可能にする内蔵マイクロホン８１２およびイヤホンスピーカ８１４に接続するためのポートを有してもよい。アナログベースバンド処理ユニット８１０はさらに、ヘッドセットまたは他のハンズフリーマイクロホンおよびスピーカ構成に接続するためのポートを含んでもよい。アナログベースバンド処理ユニット８１０は、一信号方向におけるデジタル／アナログ変換および逆信号方向におけるアナログ／デジタル変換を提供してもよい。いくつかの実施形態では、アナログベースバンド処理ユニット８１０の機能性の少なくともいくつかは、デジタル処理構成要素によって、例えば、ＤＳＰ８０２によって、または他の中央演算装置によって、提供されてもよい。

ＤＳＰ８０２は、変調／復調、符号化／復号化、インターリービング／デインターリービング、拡散／逆拡散、高速フーリエ逆変換（ＩＦＦＴ）／高速フーリエ変換（ＦＦＴ）、サイクリックプレフィックス付加／除去、および無線通信と関連付けられた他の信号処理機能を行ってもよい。ある実施形態では、例えば、符号分割多重アクセス（ＣＤＭＡ）技術用途では、送信機機能の場合、ＤＳＰ８０２は、変調、符号化、インターリービング、および拡散を行ってもよく、受信機機能の場合、ＤＳＰ８０２は、逆拡散、デインターリービング、復号化、および復調を行ってもよい。別の実施形態では、例えば、直交周波数分割多重アクセス（ＯＦＤＭＡ）技術用途では、送信機機能の場合、ＤＳＰ８０２は、変調、符号化、インターリービング、高速フーリエ逆変換、およびサイクリックプレフィックス付加を行ってもよく、受信機機能の場合、ＤＳＰ８０２は、サイクリックプレフィックス除去、高速フーリエ変換、デインターリービング、復号化、および復調を行ってもよい。他の無線技術用途では、さらに他の信号処理機能と信号処理機能との組み合わせが、ＤＳＰ８０２によって行われてもよい。

ＤＳＰ８０２は、アナログベースバンド処理ユニット８１０を経由して、無線ネットワークと通信してもよい。いくつかの実施形態では、通信は、インターネット接続を提供し、ユーザに、インターネット上のコンテンツへのアクセスを獲得し、電子メールまたはテキストメッセージを送受信可能にしてもよい。入力／出力インターフェース８１８は、ＤＳＰ８０２および種々のメモリと相互接続し、インターフェースをとる。メモリ８０４およびリムーバブルメモリカード８２０は、ＤＳＰ８０２の動作を構成するためのソフトウェアならびにデータを提供してもよい。インターフェースはとりわけ、ＵＳＢインターフェース８２２および短距離無線通信サブシステム８２４であってもよい。ＵＳＢインターフェース８２２を使用して、ＵＥ８００を充電してもよく、また、ＵＥ８００が、周辺機器デバイスとして機能し、パーソナルコンピュータまたは他のコンピュータシステムと情報を交換可能にしてもよい。短距離無線通信サブシステム８２４は、ＵＥ８００が他の近傍移動デバイスおよび／または無線基地局と無線通信可能となり得る赤外線ポート、Ｂｌｕｅｔｏｏｔｈ(登録商標）インターフェース、ＩＥＥＥ ８０２．１１準拠無線インターフェース、または任意の他の短距離無線通信サブシステムを含んでもよい。

入力／出力インターフェース８１８はさらに、ＤＳＰ８０２をアラート８２６に接続し、トリガされると、例えば、鳴音、メロディ再生、または振動によってＵＥ８００がユーザに通知を提供してもよい。アラート８２６は、静かな振動によって、または特定の発呼者に対して特有の事前に割り当てられたメロディを再生することによって、着信呼、新しいテキストメッセージ、および予定リマインダ等の種々のイベントのいずれかをユーザにアラートするための機能としての役割を果たしてもよい。

キーパッド８２８は、インターフェース８１８を経由して、ＤＳＰ８０２に連結し、ユーザが選択を行い、情報を入力し、および別様に入力をＵＥ８００に提供するための一機構を提供する。キーボード８２８は、ＱＷＥＲＴＹ、Ｄｖｏｒａｋ、ＡＺＥＲＴＹ、および連続式、また電話キーパッドと関連付けられたアルファベット文字を伴う、従来の数字キーパッド等、完全または減少数の英数字キーボードであってもよい。入力キーは、内向きに押下され、さらなる入力機能を提供し得るトラックウィール、終了またはエスケープキー、トラックボール、および他のナビゲーションまたは機能的キーを含んでもよい。別の入力機構は、タッチスクリーン能力を含み、また、ユーザにテキストおよび／またはグラフィックを表示し得る、ＬＣＤ８３０であってもよい。ＬＣＤコントローラ８３２は、ＤＳＰ８０２をＬＣＤ８３０に連結する。

ＣＣＤカメラ８３４が、装備されている場合、ＵＥ８００はデジタル写真を撮影することが可能となる。ＤＳＰ８０２は、カメラコントローラ８３６を経由して、ＣＣＤカメラ８３４と通信する。別の実施形態では、電荷結合素子カメラ以外の技術に従って動作するカメラが採用されてもよい。ＧＰＳセンサ８３８は、ＤＳＰ８０２に連結され、全地球測位システム信号を復号化し、それによって、ＵＥ８００は、その位置を決定することが可能となる。種々の他の周辺機器もまた、付加的機能、例えば、無線およびテレビ受信を提供するために含まれてもよい。

図２０は、ＤＳＰ８０２によって実装され得るソフトウェア環境９０２を例示する。ＤＳＰ８０２は、ソフトウェアの残りが動作するプラットフォームを提供するオペレーティングシステムドライバ９０４を実行する。オペレーティングシステムドライバ９０４は、ＵＡハードウェアのためのドライバに、アプリケーションソフトウェアにアクセス可能な標準化インターフェースを提供する。オペレーティングシステムドライバ９０４は、ＵＥ８００上で起動するアプリケーション間の制御を転送するアプリケーション管理サービス（「ＡＭＳ」）９０６を含む。また、図２０に示されるのは、ウェブブラウザアプリケーション９０８、メディアプレーヤアプリケーション９１０、およびＪａｖａ（登録商標）アプレット９１２である。ウェブブラウザアプリケーション９０８は、ウェブブラウザとして動作し、ユーザがフォームに情報を入力し、リンクを選択し、ウェブページを読み出し、閲覧可能にするようにＵＥ８００を構成する。メディアプレーヤアプリケーション９１０は、オーディオまたはオーディオビジュアルメディアを読み出し、再生するようにＵＥ８００を構成する。Ｊａｖａ（登録商標）アプレット９１２は、ゲーム、ユーティリティ、および他の機能性を提供するようにＵＥ８００を構成する。構成要素９１４は、本明細書に説明される機能性を提供する場合がある。

ＵＥ８００、アクセスデバイス１２０、および上述の他の構成要素は、上述の作用に関連する命令を実行可能な処理構成要素を含む場合がある。図２１は、本明細書に開示される１つ以上の実施形態を実装するために好適な処理構成要素１０１０を含む、システム１０００の実施例を例示する。プロセッサ１０１０（中央演算装置（ＣＰＵまたはＤＳＰ）と称されてもよい）に加え、システム１０００は、ネットワーク接続デバイス１０２０、ランダムアクセスメモリ（ＲＡＭ）１０３０、読取専用メモリ（ＲＯＭ）１０４０、二次記憶装置１０５０、および入力／出力（Ｉ／Ｏ）デバイス１０６０を含む場合がある。いくつかの実施形態では、最小数のＨＡＲＱプロセスＩＤの決定を実装するためのプログラムが、ＲＯＭ１０４０内に格納されてもよい。ある場合にはこれらの構成要素のいくつかは、存在しなくてもよく、あるいは相互に、または図示されない他の構成要素との種々の組み合わせとして、組み合わせられてもよい。これらの構成要素は、単一の物理的エンティティに、または１つより多くの物理的エンティティに位置する場合がある。プロセッサ１０１０によって実行されるものとして本明細書で説明される任意の作用は、プロセッサ１０１０によって単独で、または図面に示されているか、あるいは示されていない１つ以上の構成要素と併せてプロセッサ１０１０によって実行される場合がある。

プロセッサ１０１０は、それがネットワーク接続デバイス１０２０、ＲＡＭ１０３０、ＲＯＭ１０４０、または二次記憶装置１０５０（ハードディスク、フロッピー（登録商標）ディスク、または光ディスク等の種々のディスクベースのシステムを含む場合がある）からアクセスする場合がある、命令、コード、コンピュータプログラム、またはスクリプトを実行する。１つのプロセッサ１０１０のみ示されるが、複数のプロセッサが存在してもよい。したがって、命令は、プロセッサによって実行されるものとして論議され得るが、命令は、同時に、連続的に、または別様に、１つまたは複数のプロセッサによって実行されてもよい。プロセッサ１０１０は、１つ以上のＣＰＵチップとして実装されてもよい。

ネットワーク接続デバイス１０２０は、モデム、モデムバンク、イーサネット（登録商標）デバイス、ユニバーサルシリアルバス（ＵＳＢ）インターフェースデバイス、シリアルインターフェース、トークンリングデバイス、光ファイバ分散データインターフェース（ＦＤＤＩ）デバイス、無線ローカルエリアネットワーク（ＷＬＡＮ）デバイス、符号分割多重アクセス（ＣＤＭＡ）デバイス、グローバルシステムフォー移動コミュニケーションズ（ＧＳＭ（登録商標））無線送受信機デバイス等の無線送受信機デバイス、マイクロ波アクセス用の世界的相互運用性（ＷｉＭＡＸ）デバイス、および／またはネットワークに接続するための他の周知のデバイスの形態を成してもよい。これらのネットワーク接続デバイス１０２０は、プロセッサ１０１０が情報を受信する場合がある、またはプロセッサ１０１０が情報を出力する場合がある、インターネットまたは１つ以上の電気通信ネットワーク、あるいは他のネットワークと、プロセッサ１０１０が通信することを可能にしてもよい。

また、ネットワーク接続デバイス１０２０は、無線周波数信号またはマイクロ波周波数信号等の電磁波の形態として、データを無線伝送および／または受信可能な１つ以上の送受信機構成要素１０２５を含む場合がある。代替として、データは、電気導体の表面内または上、同軸ケーブル内、導波路内、光ファイバ等の光メディア内、あるいは他のメディア内を伝搬してもよい。送受信機構成要素１０２５は、別個の受信および伝送ユニットまたは単一送受信機を含む場合がある。送受信機１０２５によって伝送または受信される情報は、プロセッサ１０１０によって処理されたデータ、またはプロセッサ１０１０によって実行される命令を含んでもよい。そのような情報は、例えば、コンピュータデータベースバンド信号または搬送波内に埋め込まれた信号の形態として、ネットワークから受信され、そこへ出力されてもよい。データは、データの処理または生成あるいはデータの伝送または受信のいずれかのために望ましくあり得るため、異なるシーケンスに従って順序付けられてもよい。ベースバンド信号、搬送波内に埋め込まれた信号、あるいは現在使用されている、または以降に開発される、他の種類の信号は、伝送メディアと称され得、当業者に周知のいくつかの方法に従って生成されてもよい。

ＲＡＭ１０３０は、揮発性データを記憶するために、また可能性としてプロセッサ１０１０によって実行される命令を格納するために使用される場合ある。ＲＯＭ１０４０は、一般的には、二次記憶装置１０５０のメモリ容量より小さいメモリ容量を有する不揮発性メモリデバイスである。ＲＯＭ１０４０は、命令と、また可能性として、命令の実行の際に読み取られるデータを格納するために使用される場合がある。ＲＡＭ１０３０およびＲＯＭ１０４０の両方へのアクセスは、一般的には、二次記憶装置１０５０より高速である。二次記憶装置１０５０は、一般的には、１つ以上のディスクドライブまたはテープドライブから成り、ＲＡＭ１０３０が、全作業データを保持するために十分に大きくない場合、データの不揮発性記憶のために、またはオーバフローデータ記憶デバイスとして使用される場合がある。二次記憶装置１０５０は、そのようなプログラムが実行のために選択される時、ＲＡＭ１０３０にロードされるプログラムを格納するために使用されてもよい。

Ｉ／Ｏデバイス１０６０は、液晶ディスプレイ（ＬＣＤ）、タッチスクリーンディスプレイ、キーボード、キーパッド、スイッチ、ダイヤル、マウス、トラックボール、音声認識装置、カードリーダ、ペーパテープリーダ、プリンタ、ビデオモニタ、または他の周知の入力デバイスを含んでもよい。また、送受信機１０２５は、ネットワーク接続デバイス１０２０の構成要素の代わりに、またはそれに加えて、Ｉ／Ｏデバイス１０６０の構成要素と見なされる場合がある。Ｉ／Ｏデバイス１０６０の一部または全部は、ディスプレイ７０２および入力７０４等、ＵＥ８００の上述の図面に描写される種々の構成要素に実質的に類似してもよい。

いくつかの実施形態を本開示で提供したが、開示されたシステムおよび方法は、本開示の精神または範囲から逸脱することなく、多くの他の具体的形態で具現化されてもよいことを理解されたい。本実施例は、制限ではなく、例示としてみなされるべきであって、本明細書に与えられる詳細に制限されることを意図するものではない。例えば、種々の要素または構成要素は、組み合わされる、または別のシステムに統合されてもよく、あるいはある特徴は、省略される、もしくは実装されてなくてもよい。

また、個別または別個のものとして種々の実施形態で説明および例示される技術、システム、サブシステム、および方法は、本開示の範囲から逸脱することなく、他のシステム、モジュール、技術、または方法と組み合わされるか、あるいは統合されてもよい。連結されるか、または直接連結されるか、あるいは互いに通信するように図示もしくは論じられた他の項目は、あるインターフェース、デバイス、または中間構成要素を介して電気的に、機械的に、あるいは別様にかにかかわらず間接的に連結されるか、もしくは通信してもよい。変更、代用、および改良の他の実施例は、当業者によって究明可能であって、本明細書に開示される精神および範囲から逸脱することなく成され得る。

Claims (30)

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. 二重転送モードが対応されているか否かを検出することをさらに備え、
    二重転送モードが対応されていない場合に、回路交換を介して前記ユーザ機器とネットワークとの間でＩ１を使用する、請求項１に記載の方法。
26. パケット交換ドメインおよび回路交換ドメインのうちの少なくとも１つに対応している通信システムにおいて、ユーザ機器を使用してボイスサービスにアクセスする方法であって、該方法は、
    該ユーザ機器において、ボイスサービスのための第１のメッセージを受信することと、
    複合アタッチプロシージャが成功したか否かを検出することと、
    該第１のメッセージに応答して第２のメッセージを送信することであって、該第２のメッセージは、該複合アタッチプロシージャが成功したか否かの検出に基づいている、ことと
    を備える、方法。
27. パケット交換ドメインおよび回路交換ドメインのうちの少なくとも１つに対応している通信システムにおいて、ボイスサービスにアクセスするシステムであって、該システムは、
    ユーザ機器を備え、該ユーザ機器は、第１のメッセージを受信し、該第１のメッセージに応答して第２のメッセージを送信するように構成される、システム。
28. 前記第１のメッセージは、オーディオセッション表示を含む、請求項２７に記載のシステム。
29. 前記第２のメッセージは、少なくとも１つの値を備える１つ以上のボイスサービスインジケータに基づいている、請求項２７に記載のシステム。
30. 前記ユーザ機器は、回路交換フォールバックプロシージャに対応しているようにさらに構成される、請求項２７に記載のシステム。

Images