ＶＯＩＰ緊急呼に関する音声呼継続性をサポートするためのシステムと方法
緊急呼に関する音声呼継続性（ＶＣＣ）をサポートするためのシステムと方法が開示される。インターネット・プロトコル・マルチメディア・サブシステム（ＩＭＳ）と回線交換（ＣＳ）サブシステムとの間のドメイン移動を容易にするために、該システムは訪問された前記ＩＭＳ内にＶＣＣアプリケーションを含む。該ＩＭＳサブシステムと該ＣＳサブシステムとの間でのドメイン移動を容易にするために、該システムはさらに、該ＶＣＣアプリケーションに動作可能に結合された前記訪問されたＩＭＳサブシステム内に緊急呼セッション制御機能（Ｅ−ＣＳＣＦ）サブシステムを含む。
【発明の詳細な説明】
【技術分野】
【０００１】
本特許出願は、下記の米国仮特許出願の利益を主張する：（１）“ＳＵＰＰＯＲＴ ＯＦＶＣＣ ＦＯＲ ＶＯＩＰ ＥＭＥＲＧＥＮＣＹ ＣＡＬＬＳ”と題され、2006年４月28日にステファン・エッジによって出願された米国仮出願第６０／７９５，７７４号；（２）“ＳＵＰＰＯＲＴ ＯＦ ＶＣＣ ＦＯＲ ＶＯＩＰ ＥＭＥＲＧＥＮＣＹ ＣＡＬＬＳ”と題され、2006年５月１日にステファン・エッジによって出願された米国仮出願第６０／７９６，６６９号；（３）“ＳＹＳＴＥＭ ＡＮＤ ＭＥＴＨＯＤ ＦＯＲ ＳＵＰＰＯＲＴＩＮＧ ＶＯＩＣＥ ＣＡＬＬ ＣＯＮＴＩＮＵＩＴＹ ＦＯＲ ＶＯＩＰ ＥＭＥＲＧＥＮＣＹ ＣＡＬＬＳ”と題され、2006年６月21日にステファン・エッジによって出願された米国仮出願第６０／８１５，７３８号。そしてこれらは本願の譲受人に譲渡され、参照により本明細書に明示的に組み込まれる。
【０００２】
この開示は、一般的には、Ｖｏｉｃｅ−Ｏｖｅｒ−ＩＰ（ＶｏＩＰ）緊急呼に関する音声呼継続性(Voice Call Continuity)（ＶＣＣ）を効果的にサポートするためのシステムと方法に関する。
【背景技術】
【０００３】
音声呼継続性(Voice Call Continuity)（ＶＣＣ）は、第３世代パートナーシッププロジェクト(Third Generation Partnership Project)（３ＧＰＰ）および第３世代パートナーシッププロジェクト２(Third Generation Partnership Project2)（３ＧＰＰ２）によって標準化が行われている特徴である。ＶＣＣの定義は３ＧＰＰによって公衆に利用可能な文書である３ＧＰＰ ＴＳ ２３．２０６（“Ｖｏｉｃｅ Ｃａｌｌ Ｃｏｎｔｉｎｕｉｔｙ ｂｅｔｗｅｅｎ ＣＳ ａｎｄ ＩＭＳ； Ｓｔａｇｅ ２”）において作成された。ＶＣＣの定義はまた、３ＧＰＰ２によってこれもまた公衆に利用可能な文書である３ＧＰＰ２ Ｘ．Ｐ００４２−００１−０（“Ｖｏｉｃｅ Ｃａｌｌ Ｃｏｎｔｉｎｕｉｔｙ ｂｅｔｗｅｅｎ ＩＭＳ ａｎｄ Ｃｉｒｃｕｉｔ Ｓｗｉｔｃｈｅｄ Ｓｙｓｔｅｍｓ−Ｓｔａｇｅ ２”）において作成された。ＶＣＣの両者の定義は非常に似通っており回線モードをサポートする無線アクセスを使用することからＶｏＩＰをサポートする無線アクセスを使用することの間で無線端末が切り替わった際に、該無線端末から他のデバイス（無線のまたは無線でない）への音声呼の継続性をサポートする。特に、ユーザーがアクセスを切り替え、それが呼に関与するユーザーに対する顕著な遅延や障害の原因となり、該呼を再確立することの不能という結果を生じるかもしれない場合、ＶＣＣの使用は、呼（例えば、回線モードの呼）を解放しなくてはならなくなることを回避し、（例えば、ＶｏＩＰを使用して）呼を再確立する。
【０００４】
しばしば回線交換（ＣＳ）ドメインと呼ばれる回線モードをサポートする無線アクセスネットワークの具体例は、Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（ＧＳＭ）、広帯域符号分割多重アクセス（Ｗ−ＣＤＭＡ）を使用したＵｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍ（ＵＭＴＳ）、およびｃｄｍａ２０００ １Ｘを含む。ＶｏＩＰをサポートする無線アクセスネットワークの例は、ＵＭＴＳ Ｗ−ＣＤＭＡ、ｃｄｍａ２０００ １ｘＥＶ−ＤＯ（Ｅｖｏｌｕｔｉｏｎ Ｄａｔａ Ｏｐｔｉｍｉｚｅｄ）、および様々な無線ＬＡＮ（ＷＬＡＮ）およびＷｉＭａｘネットワークである。ユーザーの無線端末は特定の一の呼に関して（任意の一時点で）回線モードとＶｏＩＰのうちの一つだけを使用するように要求されるだろうが、幾つかのケースにおいて、同一のアクセスネットワーク（例えば、ＵＭＴＳ Ｗ−ＣＤＭＡ）は回線モードとＶｏＩＰの両者をサポートすることが可能である。
【０００５】
無線ユーザーが特定の無線アクセスネットワークに関してカバレージを失い、他のアクセスネットワークを使用する必要があるとき、アクセスのタイプ（回線モード、またはＶｏＩＰ）を変更しないままで提供されるサービスの中断なしに一のアクセスネットワークから他への進行中の呼のハンドオーバーが時として可能である。しかしながら、（例えば、新たなアクセスネットワークが以前に使用されていたアクセス・タイプをサポートしていないなどの理由で）アクセスのタイプを変更する必要がある場合、呼を正常に解放し、新たなアクセス・タイプを使用して再び呼を再確立するだろう。ＶＣＣは、その様な中断なしにＶｏＩＰと回線モードの間でハンドオーバーを可能にする機能である。
【０００６】
ＶＣＣは現状では、通常の非緊急呼に関して３ＧＰＰと３ＧＰＰ２の両者によって定義されており、回線モードとＶｏＩＰの何れか一方を使用して発生された緊急呼を明示的にはサポートしない可能性がある。これは、ＶＣＣに関して３ＧＰＰと３ＧＰＰ２の両者において定義されているソリューションが、回線モードとＶｏＩＰの緊急呼をサポートするために定義された、および定義されている最中のソリューションとは互換性が無いからである。この非互換性の主たる原因は、緊急呼をサポートするためのソリューションが、訪問されたネットワークとして知られ、無線ユーザーにサービスを現在提供中であるネットワークからのサポートに依存しているのに対して、ＶＣＣに関するソリューションは、たとえ訪問されたネットワークとは異なっている場合でもユーザーのホーム・ネットワークにおけるＶＣＣのサポートを必要とすることである。
【０００７】
緊急呼に関するＶＣＣのサポートの欠如は、異なる複数のアクセスネットワークにおいて（または、同一のアクセスネットワークにおいて）、（例えば、ユーザーが移動した、または現在のアクセスネットワークが輻輳しているか他の何らかの悪条件にさらされている等の理由で）回線モードの使用とＶｏＩＰの使用との間で無線ユーザーが変更をする必要がある場合、その様な呼が解放され、再発行されなくてはならないであろうことを意味する。この事は特に不利である。なぜなら、もしユーザーが呼を再発行する場合、その呼は以前と同じ公衆安全応答点(Public Safety Answering Point)（ＰＳＡＰ）のオペレーターを通過しないかもしれないからである。加えて、呼が最初に確立された際にコールバック番号が供給されなかった場合（例えば、無線端末が大元のアクセスネットワークにおいて適切にオーサライズされない場合）、ＰＳＡＰのオペレーターは該呼を再発行できないかもしれない。従って、緊急呼をサポートするようにＶＣＣの機能を拡張することには有利な点があるであろう。
【発明の開示】
【発明の概要】
【０００８】
３ＧＰＰ ＴＳ ２３．２０６（“Ｖｏｉｃｅ Ｃａｌｌ Ｃｏｎｔｉｎｕｉｔｙ ｂｅｔｗｅｅｎ ＣＳ ａｎｄ ＩＭＳ； Ｓｔａｇｅ ２”）において説明されているように、ＶＣＣは、ＶＣＣ呼継続性制御機能(VCC Call Continuity Control Function)（ＶＣＣ ＣＣＣＦ）として知られ、３ＧＰＰ ＴＳ ２３．２０６のより新しいバージョンにおいてＶＣＣアプリケーション、または（ある特定の文脈において）ドメイン移動機能（Ｄｏｍａｉｎ Ｔｒａｎｓｆｅｒ Ｆｕｃｔｉｏｎ）とも呼ばれる新しいＩＭＳ（ＩＰマルチメディアサブシステム）エンティティにおいてサポートされる。３ＧＰＰ２ Ｘ．Ｐ００４２−００１−０（“Ｖｏｉｃｅ Ｃａｌｌ Ｃｏｎｔｉｎｕｉｔｙ ｂｅｔｗｅｅｎ ＩＭＳ ａｎｄ Ｃｉｒｃｕｉｔ Ｓｗｉｔｃｈｅｄ Ｓｙｓｔｅｍｓ−Ｓｔａｇｅ ２”）において説明されているように、ＶＣＣはＶＣＣアプリケーション・サーバー（ＶＣＣ ＡＳ）によってサポートされ、それは３ＧＰＰのＶＣＣアプリケーションと類似したエンティティである。３ＧＰＰのＶＣＣアプリケーションと３ＧＰＰ２のＶＣＣ ＡＳの両者は呼び出しを行う無線ユーザーのホーム・ネットワークに配置されるように定義される。この定義は、３ＧＰＰ ＴＳ ２３．１６７において定義されるＶｏＩＰ ＩＭＳ緊急呼に関する現在のソリューション、および３ＧＰＰ２ Ｘ．Ｐ００４９−０００−０（“Ａｌｌ−ＩＰ Ｅｍｅｒｇｅｎｃｙ Ｓｅｒｖｉｃｅｓ”）において定義されている３ＧＰＰ２のソリューションとは互換性が無く、ここで、これらではＩＭＳ ＶｏＩＰ緊急呼のサポートが訪問されたネットワークに制限されている。従って、訪問されたネットワークに関してＶＣＣの新しい手法が定義されるか、またはＩＭＳ緊急呼がホーム・ネットワークを介して経路制御されない限り、ＩＭＳ緊急呼に関してＶＣＣをサポートすることは不可能であろう。
【０００９】
本明細書で開示される手法は従来の代替手段を使用している。なぜなら、ＩＭＳ緊急呼のホーム・ネットワークのサポートはＶｏＩＰ緊急呼に関して現在のソリューションを顕著に変更するが、同時に、責任の問題、訪問された国の規制上の要件、および場合によってはレイテンシーの問題などの多数の新しい問題をもたらすからである。このようなホーム・ネットワークに基づくソリューションはまた、オーサライズされていないユーザーからのＩＭＳ緊急呼（例えば、訪問されたネットワークとホーム・ネットワークの間にローミングの合意が全く無いような場合）をサポートすることとも互換性が無いだろう。ホームネットワーク・ソリューションはまた、ＣＳ緊急呼をサポートすることとも互換性が無いだろう。なぜなら、これらもまた、訪問されたネットワークにおいてサポートされているからである。
【００１０】
本明細書で開示された手法は、緊急呼に関してＶＣＣサポートを可能にし、下記の機能を有する。
【００１１】
・ ＩＭＳ（ＶｏＩＰ）または回線交換（ＣＳ）ドメインの何れか一方において発生した緊急呼に関してＩＭＳ（ＶｏＩＰ）からＣＳドメインへの移動をサポートする
・ ＩＭＳ（ＶｏＩＰ）または回線交換（ＣＳ）ドメインの何れか一方において発生した緊急呼に関してＣＳドメインからＩＭＳ（ＶｏＩＰ）への移動をサポートする
・ オーサライズされた無線ユーザー装置(wireless User Equipment)（ＵＥ）をサポートする
・ オーサライズされていないＵＥをサポートする、ここで、該ＵＥは非緊急呼に関してアクセスネットワークを使うようにオーサライズされない
・ ホーム・ネットワーク内における際、またはローミングの際にＵＥをサポートする
・ 一のアクセスネットワークから他へのＶＣＣの移動に従う位置の継続的なサポートを提供する
位置のサポートとは、一般には、無線ユーザーの地理的な位置（例えば、正確な緯度と経度）を取得するためのＰＳＡＰの機能を指して言い、ここで、該無線ユーザーは呼が最初に生成された際、および／またはその呼の継続期間中の後の時刻において緊急呼を開始する。（例えば）欧州と北米の両者における回線モードの緊急呼に関してはこのような機能は現在では必須であり、ＶｏＩＰの緊急呼に関しては後日に必須となる可能性がある。位置に関する継続的なサポートとは、（例えば、ＶｏＩＰから回線モードへと）アクセス・タイプを変更した後に、ＰＳＡＰが無線ユーザーの位置を取得することが依然として可能であるであろうことを意味する。
【００１２】
添付の図面と共に理解されることにより、本開示の下記の詳細な説明から、本開示の他の態様、有利な点、および新規な特徴は明らかとなるだろう。
【発明の詳細な説明】
【００１３】
Ｉ．無線通信システム
例示的な実施形態は、ブロードキャスト・サービスをサポートしているスペクトラム拡散無線通信システムを採用する。無線通信システムは、音声、データなどのような様々なタイプの通信を提供するために広範に展開されている。これらのシステムは、符号分割多重アクセス(code division multiple access)（ＣＤＭＡ）、時分割多重アクセス(time division multiple access)（ＴＤＭＡ）、直交周波数分割多重アクセス(orthogonal frequency division multiple access)（ＯＦＤＭＡ）、３ＧＰＰ ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）無線アクセス、３ＧＰＰ２ ＵＭＢ（Ｕｌｔｒａ Ｍｏｂｉｌｅ Ｂｒｏａｄｂａｎｄ）、ＷｉＭａｘ、または他の変調技法に基づいて良い。
【００１４】
システムは、下記のような一または複数の標準をサポートするように設計されても良い、例えば、本明細書では３ＧＰＰと呼ばれる「第３世代パートナーシップ・プロジェクト(3rd Generation Partnership Project)」と名付けられたコンソーシアムによって提案され、下記を含むドキュメントの集合によって具体化された標準、ドキュメント番号ＴＳ２３．２０６（“Ｖｏｉｃｅ Ｃａｌｌ Ｃｏｎｔｉｎｕｉｔｙ ＢｅｔｗｅｅｎＣＳ ａｎｄ ＩＭＳ；Ｓｔａｇｅ ２（Ｒｅｌｅａｓｅ ７）”）、ＴＳ２３．１６７（“ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ（ＩＭＳ）Ｅｍｅｒｇｅｎｃｙ Ｓｅｓｓｉｏｎｓ（Ｒｅｌｅａｓｅ ７）”）、ＴＳ２４．００８（“Ｍｏｂｉｌｅ Ｒａｄｉｏ Ｉｎｔｅｒｆａｃｅ Ｌａｙｅｒ ３ Ｓｐｅｃｉｆｉｃａｔｉｏｎ；Ｃｏｒｅ Ｎｅｔｗｏｒｋ Ｐｒｏｔｏｃｏｌｓ；Ｓｔａｇｅ ３（Ｒｅｌｅａｓｅ ６）”）、ＴＳ２３．２７１（“Ｆｕｎｃｔｉｏｎａｌ Ｓｔａｇｅ ２ Ｄｅｓｃｒｉｐｔｉｏｎ ｏｆ Ｌｏｃａｔｉｏｎ Ｓｅｒｖｉｃｅｓ（ＬＣＳ）（Ｒｅｌｅａｓｅ ７）”）、ＴＲ２１．９０５（“Ｖｏｃａｂｕｌａｒｙ ｆｏｒ ３ＧＰＰ Ｓｐｅｃｉｆｉｃａｔｉｏｎｓ”）、およびＴＳ２３．００２（“Ｎｅｔｗｏｒｋ Ａｒｃｈｉｔｅｃｔｕｒｅ（Ｒｅｌｅａｓｅ ７）”）；本明細書では３ＧＰＰ２と呼ばれる「第３世代パートナーシップ・プロジェクト２(3rd Generation Partnership Project 2)」と名付けられたコンソーシアムによって提案された下記を含む標準、ドキュメント番号Ｘ．Ｐ００４２−００１−０（“Ｖｏｉｃｅ Ｃａｌｌ Ｃｏｎｔｉｎｕｉｔｙ Ｂｅｔｗｅｅｎ ＩＭＳ ａｎｄ Ｃｉｒｃｕｉｔ Ｓｗｉｔｃｈ Ｓｙｓｔｅｍｓ”），Ｘ．Ｐ００４９−０００−０（“Ａｌｌ−ＩＰ Ｅｍｅｒｇｅｎｃｙ Ｓｅｒｖｉｃｅｓ”），およびＸ．Ｓ００２４（“ＩＰ−Ｂａｓｅｄ Ｌｏｃａｔｉｏｎ Ｓｅｒｖｉｃｅｓ”）；ＴＩＡ／ＥＩＡ／ＡＴＩＳ Ｊ−ＳＴＤ−０３６（“Ｅｎｈａｎｃｅｄ Ｗｉｒｅｌｅｓｓ ９−１−１ Ｐｈａｓｅ ＩＩ”）；および関連するＩＥＴＦのＲＦＣドキュメントで下記を含むもの、ＩＥＴＦ ＲＦＣ ３２６１（“ＳＩＰ：Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏ
ｌ”）、およびＩＥＴＦ ＲＦＣ ２３２７（“ＳＤＰ：Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ”）。上記において引用された標準とドキュメントはここで参照により本明細書に明示的に組み込まれる。
【００１５】
図１は、多数のユーザーをサポートし、本発明の幾つかの態様と実施形態を実装することができる通信システム１００の例としての役割を果たす。図１において、参照数字１０２Ａ〜１０２Ｇはセルを指し、参照数字１６０Ａ〜１６０ＧはノードＢを指し、参照数字１０６Ａ〜１０６Ｊはアクセス端末またはユーザー装置(User Equipment)（ＵＥ）を指す。多様なアルゴリズムと手法のいずれもがシステム１００において伝送をスケジュールするために使用されても良い。各々が１６０Ａ〜１６０Ｇの対応するノードＢによってそれぞれサービスされる多数のセル１０２Ａ〜１０２Ｇに関してシステム１００は通信を提供する。例示的な実施形態において、複数のノードＢ１６０のうちの幾つかは複数の受信アンテナを有し、他は一つだけの受信アンテナを有する。同様に、複数のノードＢ１６０のうちの幾つかは複数の送信アンテナを有し、他は単一の送信アンテナを有する。送信アンテナと受信アンテナの組み合わせに関しては何の制限も無い。従って、一のノードＢについて、複数の送信アンテナと単一の受信アンテナを有し、または複数の受信アンテナと単一の送信アンテナを有し、または両者共に単一または複数である送信および受信アンテナを有することが可能である。
【００１６】
カバレージ・エリア内の端末（すなわちＵＥ）１０６は、固定されていても（即ち、固定局）、または移動式であっても良い。図１に示されるように、システム全体にわたって様々な端末（すなわちＵＥ）１０６が分散配置されている。端末（すなわちＵＥ）１０６の各々は、任意の与えられた瞬間において、ダウンリンク、およびアップリンクの上で少なくとも一つ、および場合によっては複数のノードＢ１６０と通信し、それは例えば、ソフトハンドオフが採用されているか、または該端末（すなわちＵＥ）が複数のノードＢから複数の伝送を（並列に、または逐次的に）受信するように設計され、作動されているかに依存している。ダウンリンクは、ノードＢから端末（すなわちＵＥ）への伝送を指して言い、アップリンクは、端末（すなわちＵＥ）からノードＢへの伝送を指して言う。例示的な実施形態において、複数の端末（すなわち複数のＵＥ）１０６のうちの幾つかは複数の受信アンテナを有し、他は一つだけの受信アンテナを有する。図１において、ノードＢ １６０Ａは端末（すなわちＵＥ）１０６Ａと１０６Ｊに対してダウンリンク上でデータを伝送し、ノードＢ １６０Ｂは端末（すなわちＵＥ）１０６Ｂと１０６Ｊに対してデータを伝送し、ノードＢ １６０Ｃは端末（すなわちＵＥ）１０６Ｃに対してデータを伝送し、以下同様である。
【００１７】
無線データ伝送に関する増加する需要と無線通信技術を介して利用可能なサービスの拡大は特定のデータ・サービスの開発を先導してきた。その様なサービスの一つはＨｉｇｈ Ｒａｔｅ Ｐａｃｋｅｔ Ｄａｔａ（ＨＲＰＤ）と呼ばれる。例示的なＨＲＰＤサービスは「ＨＲＰＤ仕様書」と呼ばれる“ＥＩＡ／ＴＩＡ−ＩＳ８５６ ｃｄｍａ２０００ Ｈｉｇｈ Ｒａｔｅ Ｐａｃｋｅｔ Ｄａｔａ Ａｉｒ Ｉｎｔｅｒｆａｃｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ”において提案されている。ＨＲＰＤサービスは一般的に音声通信システムに対するオーバーレイであり、無線通信システムにおけるデータのパケットの伝送の効率的な方法を提供する。伝送されるデータの量と伝送の回数が増加するにつれて、無線伝送に関して利用可能な限られた帯域幅は重要なリソースとなる。従って、利用可能な帯域幅の使用を最適化する通信システム内での伝送の効率的で公平な方法に関する需要が存在する。例示的な実施形態においては、図１に図解されているシステム１００はＨＲＰＤサービスを有する無線アクセス型のシステムと整合性が取れている。
【００１８】
図２は、例示的な３ＧＰＰ Ｗ−ＣＤＭＡ通信システムの簡単化された機能ブロック図である。上述したように、（３ＧＰＰの文脈において定義されているような）無線ネットワーク・コントローラー(Radio Network Controller)（ＲＮＣ）１３０は、ネットワーク１０４と、地理的領域全体にわたって分散配置されている（３ＧＰＰの文脈において定義されているような）様々なノードＢ１６０との間のインターフェイスを提供するために使用されることが可能である。説明の簡単化のために、一つだけのノードＢ１６０が示される。一般的に、該地理的領域は（図１に示される）セル１０２として知られるより小さい領域に分割される。各ノードＢ１６０は、その各々のセル内の全てのユーザー装置（ＵＥ）１０６をサービスするように構成される。幾つかの高いトラフィックのアプリケーションではセル１０２は、複数のセクターに分割されても良く、ここで、ノードＢ１６０は各セクターをサービスする。説明される例示的な実施形態においては、３つのＵＥ １０６Ａ〜ＣがノードＢ１６０と通信中であるとして示されている。ＲＮＣ１３０の制御の下で、各ＵＥ１０６Ａ〜Ｃはネットワーク１０４をアクセスしても良く、一または複数のノードＢ１６０を通じて他のＵＥ１０６と通信しても良い。
【００１９】
最近の通信システムは、複数のユーザーが共通の通信媒体をアクセスすることを可能とするように設計されている。多数の多重アクセス技法が当該技術分野において知られており、それらは例えば、時分割多重アクセス（ＴＤＭＡ）、周波数分割多重アクセス（ＦＤＭＡ）、空間分割多重アクセス、偏光分割多重アクセス、符号分割多重アクセス（ＣＤＭＡ）、および他の類似した多重アクセス技法などである。多重アクセスの概念は、複数のユーザーが共通の通信リンクをアクセスすることを可能にするチャネル割り当て方法である。具体的な多重アクセス技法に依存して、チャネル割り当ては様々な形態を取ることができる。例示の方法により、ＦＤＭＡシステムにおいては一般的に、全体の周波数スペクトルは多数のより小さいサブバンドに分割され、各ユーザーは通信リンクにアクセスするために自分自身のサブバンドを与えられることができる。代替的に、ＦＤＭＡのＯＦＤＭＡ変形における例に関しては、各ユーザーは多数の異なる周波数チャネルをアクセスすることを可能とされ得る。代替的に、ＴＤＭＡシステムにおいては、各ユーザーは周期的に繰り返されるタイムスロットの期間中に全範囲の周波数スペクトルを与えられる。ＣＤＭＡシステムにおいては、各ユーザーは全ての時間にわたって全範囲の周波数スペクトルを与えられるが、符号の使用を通じて自分の伝送を区別する。
【００２０】
ＨＲＰＤの伝送をサポートしており複数のユーザーに対する伝送をスケジューリングするために適応された通信システムの一つの例が図３に図解されている。図３は、本明細書において下記のとおりに詳細に説明され、具体的には、一のノードＢ１６０とＲＮＣ１３０はパケット・ネットワーク・インターフェイス１４６によってインターフェイスされている。ＲＮＣ１３０は、システム１２０内で複数の伝送に関するスケジューリング・アルゴリズムを実装するためのチャネル・スケジューラ１３２を含む。チャネル・スケジューラ１３２は、受信データに関する任意の特定の遠隔局の関連付けられた瞬間レート（最も最近に受信されたＤＲＣ信号によって表される）に基いて、その期間中にデータが該遠隔局に送信されるべきサービス区間の長さを決定する。該サービス区間は時間的に連続していなくても良く、ｎスロット毎に一回ずつ発生しても良い。一の実施形態に従うならば、パケットの第１の部分は、第１の時刻における第１のスロットの期間中に送信され、第２の部分は、後の時刻において４スロット後に送信される。さらに、該パケットの後続するいずれの部分も同様の４スロット分の散布を有する、即ち互いに４スロット分だけ離れている複数のスロットにおいて送信される。一の実施形態に従うならば、受信データの瞬間レートＲｉは特定のデータ待ち行列に関連付けられたサービス区間の長さＬｉを決定する。
【００２１】
加えて、チャネル・スケジューラ１３２は、伝送に関する特定のデータ待ち行列を選択する。その上で、送信されるべき関連付けられた量のデータがデータ待ち行列１７２から取り出され、該データ待ち行列１７２に関連付けられた遠隔局への送信のために、チャネル・エレメント１６８に供給される。以下で議論するように、該チャネル・スケジューラ１３２は該データを供給するために該待ち行列を選択し、そのデータは待ち行列の各々と関連付けられた重みを含む情報を使用して、続くサービス区間において送信される。送信された待ち行列に関連付けられた重みは、その後更新される。
【００２２】
ＲＮＣ１３０は、パケット・ネットワーク・インターフェイス１４６により、公衆交換電話網(Public Switched Telephone Network)（ＰＳＴＮ）１４８、および通信システム内の全てのノードＢ（簡単のために図２Ｂでは一つだけのノードＢが示されている）とインターフェイスされている。ＲＮＣ１３０は、通信システム内の遠隔局、およびパケット・ネットワーク・インターフェイス１４６とＰＳＴＮ１４８に接続された他のユーザーとの間の通信を調整する。ＰＳＴＮ１４８は標準的な電話網（図２Ｂには示されていない）を通じてユーザーとインターフェイスされている。
【００２３】
簡単のために図２Ｂには一つだけしか示されていないけれども、ＲＮＣ１３０は、多数の選択器エレメント１３６を含んでいる。各選択器エレメント１３６は、一または複数のノードＢと一つの遠隔局（図示無し）との間の通信を制御するために割り当てられる。所与の遠隔局に対して選択器エレメント１３６が未だ割り当てられていない場合、呼制御プロセッサー１４１は、該遠隔局に対してページングを実行する必要性を知らされる。呼制御プロセッサー１４１はその後、該遠隔局に対してページングを実行するようにノードＢ１６０に指令する。
【００２４】
データ・ソース１２２は多量のデータを含み、そのデータは所与の遠隔局に対して送信されるべきものである。データ・ソース１２２は該データをパケット・ネットワーク・インターフェイス１４６に対して供給する。パケット・ネットワーク・インターフェイス１４６は、該データを受け取り、該データを選択器エレメント１３６へとルーティングする。その上で、選択器エレメント１３６は、ターゲットとなる遠隔局と通信している各ノードＢ１６０に対して該データを送信する。例示的な実施形態において、各ノードＢ１６０は一のデータ待ち行列１７２を管理し、それは該遠隔局へと送信されるべきデータを格納する。
【００２５】
データは、データ待ち行列１７２からチャネル・エレメント１６８へとデータ・パケットに入れられて送信される。例示的な実施形態においては、順方向リンク上で、「データ・パケット」とは、最大で１０２４ビットの一定量のデータであり、一の所定のタイムスロット（例えば、≒１．６６７ミリ秒）の中で宛先の遠隔局へと送信されるべき一定量のデータを指して言う。各データ・パケットに関して、チャネル・エレメント１６８は制御フィールドを挿入する。例示的な実施形態においては、チャネル・エレメント１６８は巡回冗長検査(Cyclic Redundancy Check)ＣＲＣ、およびデータ・パケットと制御フィールドの符号化を実行し、符号テイルビットの組を挿入する。データ・パケット、制御フィールド、ＣＲＣパリティ・ビット、および符号テイルビットはフォーマットされたパケットを構成する。該例示的な実施形態においては、チャネル・エレメント１６８はその後、フォーマットされたパケットを符号化し、該符号化されたパケット内部のシンボルをインターリーブする（即ち、並べ替える）。該例示的な実施形態においては、該インターリーブされたパケットはウォルシュ符号によってカバーされ、短いＰＮＩおよびＰＮＱ符号によって拡散される。拡散されたデータはＲＦユニット１７０へ供給され、該ユニットは信号を直交変調し、フィルタリングし、増幅する。順方向リンク信号はアンテナを通じて順方向リンクへ無線で送信される。
【００２６】
遠隔局１０６において、順方向リンク信号はアンテナによって受信され、受信器へとルーティングされる。該受信器は、該信号をフィルタリングし、増幅し、直交復調し、そして量子化する。デジタル化された信号は復調器（ＤＥＭＯＤ）に供給され、ここでは、該信号は短いＰＮＩおよびＰＮＱ符号によって逆拡散され、ウォルシュ符号によってデカバーされる。復調されたデータは復号化器へと供給され、それはノードＢ１６０において行われた信号処理機能と逆のこと、具体的には、逆インターリーブ、復号化、およびＣＲＣ検査機能を実行する。復号化されたデータはデータ・シンクへと供給される。
【００２７】
図４は本特許出願に従う（３ＧＰＰの文脈における）ＵＥ、すなわち（３ＧＰＰ２の文脈における）ＡＴ１０６の他の実施形態であり、該特許出願においてはＵＥ、すなわちＡＴは、送信回路２６４（ＰＡ３０８を含む）、受信回路４０８、スロットル制御３０６、復号化処理ユニット２５８、処理ユニット３０２、キャリア制御ユニット４１２、およびメモリー４１６を含む。スロットル制御ユニット３０６は、上記で図解されたようなスロットル規則の少なくとも一つの組を実装する。スロットル規則は、ＲＬ上での送信電力を制御することに関する手段と方法を提供する。
【００２８】
下記の議論においては、本発明は主として３ＧＰＰアーキテクチャー参照モデルの文脈において説明されるだろう。しかしながら、開示された情報によれば、当該技術分野における当業者は３ＧＰＰ２ネットワーク・アーキテクチャー、または他のネットワーク・アーキテクチャーにおいて本発明の態様を容易に使用のために適合させ、実装できるだろう。
【００２９】
ＩＩ．アーキテクチャー参照モデル
図５Ａは、ドメイン移動手順を可能とするための（３ＧＰＰ ＴＳ２３．２０６に開示されているとおりの）３ＧＰＰ実装に関する参照モデルを示す。一般的に、ＶＣＣが可能なＵＥ５１６および５１８を使用している際にアクティブな音声セッションを維持しながら、ドメイン移動手順はＣＳドメイン５００とＩＰベースのドメイン５１０の間の音声継続性を可能とする。初期の、および後続する移動を含むＶＣＣ加入者呼と関連付けられた全てのドメイン移動手順は、ユーザーのホームＩＭＳネットワーク内においてドメイン移動機能(Domain Transfer Function)（ＤＴＦ）によって実行され、制御され、該ＤＴＦは図５ＡにおけるＶＣＣアプリケーションの一部を形成する。
【００３０】
図５Ａに示されるとおり、セッションの確立に際してＤＴＦにおいてＶＣＣ可能なＵＥ５１６と５１８を使用してＶＣＣ加入者音声呼に関する３ｐｃｃ（サード・パーティー呼制御(3rd party call control)）を確立するために、静的アンカーリング技法が採用される。ＶＣＣ加入者のＳ−ＣＳＣＦ５１４における初期フィルター基準（ｉＦＣ）の実行の開始動作または終了動作の一部として該ＤＴＦが起動される。ルーティング３ｐｃｃ機能を採用することによりＶＣＣ ＵＥ５１６および５１８を使用して生成されたＶＣＣ加入者の音声呼のシグナリング経路の中に該ＤＴＦは自分自身を挿入する。発呼元の音声セッションに関しては、該ＤＴＦは該ユーザーからのアクセス区間(Access Leg)を終端し、リモート端に向かってリモート区間を確立する。終端側の音声セッションに関しては、該ＤＴＦは、リモート端からのリモート区間を終端し、該ユーザーに向かってアクセス区間を確立する。それに引き続いて、該ＤＴＦは、一のＶＣＣ加入者音声呼に関連付けられたアクセス区間とリモート区間の間の呼制御シグナリングの交換を調整する。
【００３１】
図５Ａに示されるように、アクセス区間がＣＳドメイン５００とＩＭＳ５１０のそれぞれを介して確立される際に３ｐｃｃは該ＤＴＦにおいて存在し、この事はその使用がドメイン移動手順の事前条件に係わることを説明している。図５Ａは該ＤＴＦにおける３ｐｃｃ、およびドメイン移動手順に関するその使用を図解している。従って、それは、ドメイン移動の可能化と実行に関連するシグナリングとビアラーの構成要素のみを示している。
【００３２】
図５Ｂは、３ＧＰＰに関する例示的な参照モデルを示し、該参照モデルは通常のＶＣＣに関する（図５Ａで示され、３ＧＰＰ ＴＳ２３．２０６において開示された）標準的な３ＧＰＰ参照モデルとは異なる。ＩＭＳ（ＶｏＩＰ）緊急呼に関してＶＣＣをサポートすることについての３ＧＰＰ ＴＳ２３．２０６における参照モデルとの相違点には、下記が含まれ得る。すなわち、ホーム内のＶＣＣアプリケーション（図５Ａ内で構成要素５０４として示されている）よりもむしろ訪問されたネットワーク内のＶＣＣアプリケーション５７２を使用すること、および３ＧＰＰ ＴＳ２３．２０６におけるようなホーム・ネットワーク内のサービス中のＣＳＣＦ(Serving CSCF)（Ｓ−ＣＳＣＦ）（図５Ａ内で構成要素５１４として示されている）よりもむしろ訪問されたネットワーク内の緊急呼セッション制御機能(Emergency Call Session Control Function)（３ＧＰＰ ＴＳ２３．１６７において定義されているＥ−ＣＳＣＦ）を使用することである。該訪問されたネットワークのプロキシーＣＳＣＦ(Proxy CSCF)（Ｐ−ＣＳＣＦ）もまた、該モデルの一部であるが、図５Ｂには示されていない。図５ＢにおけるＶＣＣアプリケーション５７２は、ＶＣＣ呼継続性制御機能(Call Continuity Control Function)（ＣＣＣＦ）、ＶＣＣアプリケーション・サーバー（ＶＣＣ ＡＳ）、またはドメイン移動機能(Domain Transfer Function)（ＤＴＦ）とも呼ばれ得ることに注意されたい。
【００３３】
図６Ａは、図５Ａにおけるモデルとは相補的であるが、３ＧＰＰ ＴＳ２３．１６７において定義されているサービスの観点から見た参照モデルを示す。（位置抽出機能(Location Retrieval Function)（ＬＲＦ）６１０、ユーザー装置（ＵＥ）６２０、プロキシーＣＳＣＦ（Ｐ−ＣＳＣＦ）６３０、緊急ＣＳＣＦ（Ｅ−ＣＳＣＦ）６４０、およびＳ−ＣＳＣＦ６５０を含む）複数の構成要素は３ＧＰＰ ＴＳ２３．１６７において定義されているように機能する。
【００３４】
図６Ｂは、図５Ｂと同一の参照モデルを含むが、ＩＭＳ（ＶｏＩＰ）緊急呼をサポートするために３ＧＰＰ ＴＳ２３．１６７において定義されているモデルの観点から見たものを示す。図６Ｂにおいては、３ＧＰＰ ＴＳ２３．１６７において開示されている（そして、図６Ａに示されている）参照モデルとは異なり、ＶＣＣアプリケーション６６０は、訪問されたネットワーク内のＥ−ＣＳＣＦ６４０へのインターフェイス、および訪問されたネットワーク内のＰ−ＣＳＣＦ６３０への可能なインターフェイスを有する。緊急呼は、３ＧＰＰ ＴＳ２３．２０６において定義されているようにＶＣＣアプリケーション内に固定されるだろう。加えて、ＵＥ６２０がそのサービス提供中のネットワークとサービス提供中のドメインをどのように変更するかに関わらず、更新された位置の推定をＰＳＡＰがＬＲＦ６１０から取得し続けることができるように、位置のサポートは訪問されたネットワーク内のＬＲＦ６１０内に固定されるだろう。このＬＲＦ６１０はここではアンカーＬＲＦと呼ばれることができる。
【００３５】
３ＧＰＰ２に適用可能な参照モデルは、図５ＢにおけるＶＣＣアプリケーション（構成要素５７２）、および図６ＢにおけるＶＣＣアプリケーション（構成要素６６０）をＶＣＣ ＡＳで置き換えることにより得られる。３ＧＰＰに適用可能な下記の説明において、３ＧＰＰの文脈から３ＧＰＰ２の文脈への用語法と対象の特定の変更と共に３ＧＰＰ２の緊急呼に関するＶＣＣサポートの方法を定義するために（そうではないと述べられない限り）同一の説明が使用されることが可能であることが理解されるべきである。特に、参照された３ＧＰＰ ＶＣＣアプリケーション・エンティティは３ＧＰＰ２ ＶＣＣ ＡＳによって置き換えられるだろう。下記で参照される特定の他の３ＧＰＰの対象も置き換えられることが可能だろう。例えば、３ＧＰＰ ＧＭＬＣ（Ｇａｔｅｗａｙ Ｍｏｂｉｌｅ Ｌｏｃａｔｉｏｎ Ｃｅｎｔｅｒ）は３ＧＰＰ２ ＭＰＣ（Ｍｏｂｉｌｅ Ｐｏｓｉｔｉｏｎ Ｃｅｎｔｅｒ）によって置き換えられるだろう。
【００３６】
ＩＩＩ．ＶＣＣサポートの交渉
通常のＶＣＣに関して、ホーム・ネットワーク（例えば、ホームのＳ−ＣＳＣＦ）はＵＥのホーム加入者サーバー(home subscriber server)（ＨＳＳ）から取得された加入情報からＵＥのＶＣＣ可能性を認識することができる。該ＵＥは、ＶＣＣのホーム・ネットワーク・サポート、およびドメイン移動のために用いられるＶＤＮ（Ｅ．１６４ 音声ドメイン移動番号(Voice Domain Transfer Number)）およびＶＤＩ（音声ドメイン移動ＳＩＰ ＵＲＩ(Voice Domain Transfer SIP URI)）（またはＶＤＮおよびＶＶＤＩと等価な他の番号およびアドレス）を既に認識していることが可能であり、音声呼が最初に発呼された際に、いかなる明示的な交渉および情報の転送も無しにＶＣＣを可能化する。
【００３７】
同一の明示的なシグナリングの変更が必要とされるかも知れないが、ＣＳとＶｏＩＰの緊急呼に関して同様の態様でＶＣＣをサポートすることが望ましいだろう。例えば、ＶＣＣサポートの如何なる交渉も無しではＶＣＣをサポートすることは難しいだろう。なぜなら、ＵＥがドメインを変更した際に、ローミング状況の下では、古い、および新しいドメインがＶＣＣをサポートするために協働することができるか否かをＵＥは知るよしも無いからであり、従って、ＵＥは既存の呼が継続され得るか否かを知ることは無いだろうからである。下記の議論においては、ＩＭＳ緊急呼に関するＶＣＣサポートは訪問されたネットワーク内において提供されると仮定されている。
【００３８】
ＩＩＩ．Ａ．ＵＥがＶＣＣ可能であることを伝える方法
訪問されたネットワーク（例えば、Ｐ−ＣＳＣＦ、Ｅ−ＣＳＣＦ、または音声移動サービス交換センター(Voice Mobile-Service Switching Center)（ＶＭＳＣ）など）に対してＵＥがＶＣＣ可能であることを伝えるために、下記の選択肢が可能である。
【００３９】
（ａ）訪問されたネットワークがＵＥのホーム・ネットワークである場合、それはホームＨＳＳ内のＵＥに関する加入情報からＵＥのＶＣＣ可能性を発見することが可能である。
【００４０】
（ｂ）訪問されたネットワークは（ＵＥが実際にそうであるか否かに関わらず）ＵＥがＶＣＣ可能であると仮定しても良い。例えば、訪問されたネットワークがホーム・ネットワークではなく、従って選択し（ａ）を採用することができない場合、それはＵＥがＶＣＣ可能であると仮定することが可能である。
【００４１】
（ｃ）訪問されたネットワーク（例えば、Ｐ−ＣＳＣＦまたはＶＭＳＣ）はホーム・ネットワークによる登録の期間中に（例えば、ホームＳ−ＣＳＣＦの２００ ＯＫ応答からセッション・イニシエーション・プロトコル(Session Initiation Protocol)（ＳＩＰ）のＲＥＧＩＳＴＥＲメッセージ（ＩＥＴＦ ＲＦＣ３２６１で定義されている）までの間に）、またはＶＭＳＣに対してＨＬＲ／ＨＳＳによって提供されたＵＥの加入情報の中にＵＥのＶＣＣ可能性を発見することが可能である。
【００４２】
（ｄ）ＵＥは、訪問されたネットワーク（例えば、Ｐ−ＣＳＣＦまたはＥ−ＣＳＣＦ）に、自身のＶＣＣ可能性について、下記の複数の方法のうちの一つにより知らせることができる。
【００４３】
ｉ．登録の期間中に（例えば、ＳＩＰ ＲＥＧＩＳＴＥＲメッセージにおいて）；または
ｉｉ．ＩＭＳ緊急呼を発呼する際（例えば、ＳＩＰ ＩＮＶＩＴＥメッセージにおいて）；または
ｉｉｉ．ＣＳモードの緊急呼を発呼する際（例えば、３ＧＰＰ ＴＳ２４．００８において定義されているEmergency SETUPメッセージにおいて）。
【００４４】
選択肢（ａ）は、ＰＳ（パケット交換）ドメイン内で発呼された緊急呼に対して適用可能であり、ＵＥがローミング中でない（すなわち自身のホーム・ネットワークによってサービスされている）場合に３ＧＰＰ ＴＳ２３．２０６で説明されているように通常のＶＣＣサポートに関して（非緊急呼に関して）使用されているＶＣＣ可能性の発見のために同一の仕組みを使用しても良い。
【００４５】
選択肢（ｂ）に関しては、訪問されたネットワークはＵＥがＶＣＣ可能であると仮定し、（例えば、セクションＩＶおよび図７において後述されるとおりに）緊急呼が発呼された際にＶＣＣリソースを割り当てる。しかしながら、ＶＣＣリソースは、該ＵＥが実際にＶＣＣ可能であり、緊急呼がＩＭＳ（ＶｏＩＰ）および回線交換ドメインの間で遷移する必要がある場合のみ使用されるだろう。従って、（ＶＣＣリソースは呼のシグナリングを中継するためだけに使用されることから、緊急呼それ自体は必ずしも損なわれないけれども）ＶＣＣ可能でないＵＥに関するＶＣＣリソースの一定の無駄が存在するだろう。ＰＳドメインにおいて発呼された緊急呼に関しては、無駄は小さいかもしれない。なぜなら、一般にその様な呼の数は全てのＶｏＩＰ呼（緊急、および非緊急の両者の）の中の非常に小さい比率であろうからである。加えて、選択肢（ａ）と選択肢（ｂ）が組み合わされ、それにより訪問されたネットワークがホーム・ネットワークでない場合にだけ、該訪問されたネットワークがＵＥのＶＣＣ可能性を仮定するようにする場合、無駄のレベルは更に削減される。しかしながら、ＣＳで発呼された緊急呼に関しては、おそらくはより高いレベルの無駄が存在するだろう。なぜなら、少なくとも初期においては、殆どのＣＳ緊急呼はＶＣＣをサポートすることが不可能であるレガシーＵＥから来るだろうからである。
【００４６】
選択肢（ａ）と選択肢（ｂ）の両者はＵＥに大きな影響を与えることを回避し、このことは、緊急、および非緊急の両方の呼に関して（ＵＥの観点から）共通のＶＣＣソリューションを可能とするために望ましい。
【００４７】
選択肢（ｃ）もまた、ＵＥに大きな影響を与えることを回避する。しかしながら、選択肢（ｃ）はオーサライズされたＵＥだけに限定される可能性がある。
【００４８】
選択肢（ｄ．ｉ）はホーム・ネットワークに対して大きな影響を与えることを回避するが、しかしこれもまたオーサライズされたＵＥのみに限定され、その一方で、選択肢（ｄ．ｉｉ）および（ｄ．ｉｉｉ）はＵＥの観点からＶＣＣの新しい変形を必要とするけれども、全てのＵＥに関して有効である。
【００４９】
ＩＩＩ．Ｂ．訪問されたネットワークがＶＣＣ可能であることを伝える方法
訪問されたネットワークがＶＣＣ可能であることをＵＥに伝え、必要ならばＶＤＮとＶＤＩを転送するために、下記の選択肢が可能である。
【００５０】
（ｅ）その性質上固定的であり、いかなるＵＥにとっても特有のものではないシステム・ブロードキャスト・メッセージ、または他のメッセージ（例えば、特定の訪問されたネットワークに関連付けられたＷＬＡＮの広告）から、ＵＥは訪問されたネットワークのＶＣＣ可能性（そして場合によっては任意のＶＤＮおよびＶＤＩ）を発見する。これらのメッセージは同一のメッセージであることが可能であり、該メッセージは全てのＵＥに対してネットワーク情報（ネットワーク識別子、およびサポートされる機能）を提供する全てのネットワーク基地局、および／またはアクセスポイントから現在送信されているものである。
【００５１】
（ｆ）訪問されたネットワーク内のサーバーからＤＨＣＰを使用して、またはＨｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）またはセキュアＨＴＴＰ（ＨＴＴＰＳ）を使用して、ＵＥはＶＣＣ可能性、および必要ならばＶＤＮとＶＤＩを発見する、ここで、前記サーバーの役割は緊急呼に関係した情報（例えば、局所緊急番号(local Emergency numbers)も含む）を提供することである。
【００５２】
（ｇ）訪問されたネットワークはＵＥに対してそのＶＣＣ可能性を下記の何れかにおいて示す。
【００５３】
ｉ．登録の期間中（例えば、ＳＩＰ ２００ ＯＫメッセージ中において）；または
ｉｉ．ＩＭＳ緊急呼の発呼に対して応答する際（例えば、ＳＩＰ ２００ ＯＫメッセージ中において）；または
ｉｉｉ．ＰＳモード・アタッチ要求に対して応答する際（例えば、３ＧＰＰ ＴＳ２４．００８におけるネットワーク特性サポート・パラメータ(Network Feature support parameter)を使用して）；または
ｉｖ．ＣＳ緊急呼の発呼に対して応答する際（例えば、３ＧＰＰ ＴＳ２４．００８において定義されているＣＯＮＮＥＣＴメッセージ内のファシリティ・パラメータ(Facility parameter)内において）
（ｈ）緊急呼のためにＶＣＣをサポートすることが既知であるネットワークに関して、ＵＥに対し、またはＵＥ内のユニバーサル集積回路カード(Universal Integrated Circuit Card)（ＵＩＣＣ）に対してホーム・ネットワークは情報をダウンロードする。例えば、ホーム・ネットワークはそのような全てのＶＣＣ可能なネットワークに関するモバイル国コード(mobile country code)（ＭＣＣ）、およびモバイル・ネットワーク・コード(mobile network code)（ＭＮＣ）をＵＥに提供することができるだろう。その様なネットワークによって使用されるＶＤＮやＶＤＩのような追加的情報もまた、提供されることが可能だろう。
【００５４】
選択肢（ｅ）は（ＵＭＴＳ、ＧＰＲＳ、およびＧＳＭネットワークのような）無線ネットワークに適しているであろうし、ＷＬＡＮに関しても可能であり得るだろう。それはまた、ＵＥに対する如何なるポイント・ツー・ポイントのシグナリングの影響をも回避する。ＩＭＳが発生した呼に対して適用可能な選択肢（ｆ）は、ＳＩＰの影響を回避し、訪問されたネットワーク内のあるサーバーからＵＥに対して局所緊急番号(local emergency numbers)を提供する必要性と適合し得るだろう。このサーバーのアドレスは、ＤＨＣＰ、または既知のFully Qualified Domain Name（ＦＱＤＮ）の上でのＤＮＳ問い合わせの何れか一方を使用してＵＥによって取得され、ここで該ＦＱＤＮは、訪問されたネットワークの既知のドメイン名（例えば、訪問されたネットワークのＭＣＣ、およびＭＮＣに基づいたもの）、および何らかの固定的なユーザー名（例えば、”emergency-support@＜訪問されたネットワークのドメイン＞”など）を含む。一の変形として、ＶＣＣ機能（および必要ならばＶＤＮとＶＤＩアドレス）は、Ｐ−ＣＳＣＦとＤＮＳサーバー・アドレスを発見するためにＵＥがＤＨＣＰを使用する際に直接的にシグナリングされることが可能であろう。
【００５５】
選択肢（ｇ．ｉ）はオーサライズされたＵＥに関してのみ有効である可能性があり、その一方で、選択肢（ｇ．ｉｉ）、（ｇ．ｉｉｉ）、および（ｇ．ｉｖ）はオーサライズされた、およびオーサライズされていないＵＥに関して有効である。
【００５６】
選択肢（ｈ）は全てのＵＥに関して有効であることが可能であり、各ホーム・ネットワークに専用のシグナリングを使用しても良い。
【００５７】
ＩＩＩ．Ｃ．必要とされるシグナリングの変更
（上記のセクションＩＩＩ．ＡとＩＩＩ．Ｂで説明された）選択肢（ｃ）、（ｄ）および（ｇ）をサポートするために必要とされるＳＩＰシグナリングの変更は少なくとも四つの異なる方法によりサポートされ得るだろう。
【００５８】
（ｉ）既存のＳＩＰヘッダー・フィールド（例えば、Record-Route、Route、Contactなど）は新たなシグナリングを転送するために使用される。
【００５９】
（ｊ）ＳＩＰ ＲＥＧＩＳＴＥＲ、ＳＩＰ ＩＮＶＩＴＥ、およびＳＩＰ ２００ ＯＫにおけるサポートされたＳＩＰヘッダー・フィールドはＶＣＣサポートを表示する新しいオプション・タグを生成するために拡張される。追加のＶＣＣ情報（例えば、ＶＤＮ、およびＶＤＩ）の転送のために、新たなＳＩＰの拡張が、サポートされたＶＣＣオプション・タグと関連付けられて使用されるだろう。
【００６０】
（ｋ）ＳＩＰ ＩＮＶＩＴＥ、およびＳＩＰ ２００ ＯＫのセッション記述プロトコル(Session Description Protocol)（ＩＥＴＦ ２３２７において定義されているＳＤＰ）の部分が、ＩＡＮＡに登録された、または登録されていない新たな属性を定義することにより拡張される。例えば、新たなプロパティ属性がＶＣＣサポートを表示するために使用されることが可能であろうし、一つのまたは２つの異なる値の属性が（例えば、Ｅ−ＣＳＣＦ、またはＶＣＣアプリケーションから）ＵＥに対してＶＤＮ、およびＶＤＩを運ぶために割り当てられることが可能であろう。媒体レベル属性は（セッション・レベルの属性とは反対に）（例えば、マルチメディア緊急呼を確立する際に）ＶＣＣがサポートされる特定の媒体（例えば、オーディオのみ）を選択的に定義するためにより適切であるかもしれない。
【００６１】
（ｌ）選択肢（ｉ）、（ｊ）、および（ｋ）の中の２つ、またはそれ以上の組み合わせが使用されても良いだろう。例えば、（ｊ）におけるような新たにサポートされたオプション・タグを使用しただけのＳＩＰ機能の伝達と、（ｋ）におけるような新たなＳＤＰレベルの値の属性を使用した任意の更なるＶＣＣ情報（例えば、ＶＤＮ、およびＶＤＩなど）の伝達である。
【００６２】
選択肢（ｊ）の一例として、ＶＣＣサポートを表示する新たなオプション・タグを含むサポートされたＳＩＰヘッダー・フィールドを包含することによって、ＳＩＰ ＲＥＧＩＳＴＥＲメッセージの中において、ＵＥは自身のＶＣＣのサポートを表示することができるだろう。訪問されたネットワークがＶＣＣに加えて、新たなＳＩＰの拡張の中において（必要ならば）ＶＤＮとＶＤＩをサポートするならば、訪問されたネットワークのＰ−ＣＳＣＦにより返された２００ ＯＫは、その後、同一のオプション・タグを包含することができるだろう。もう一つの例として、ＳＩＰ ＩＮＶＩＴＥ、および２００ ＯＫにおける呼の確立の期間中に同一のやり取りが生起し得るだろう。ＶＣＣの表示、および／またはＶＣＣに関係した情報が新たなＳＤＰ属性を使用して伝達されることを除いて、同一の例が選択肢（ｋ）と（ｌ）に当てはまる。
【００６３】
無線インターフェイス上でのＵＥと訪問されたネットワークとの間のＳＩＰ、および他のポイント・ツー・ポイント・シグナリングの影響を回避するために、選択肢（ａ）、（ｂ）、（ｃ）、（ｅ）、（ｆ）、および（ｈ）の何らかの組み合わせが使用され得る。しかしながら、ＵＥに関してＳＩＰ、およびＣＳドメインのシグナリングの影響を許すことは、ホーム・ネットワークに対する影響を回避することができ、例えば選択肢（ｄ．ｉｉ）、（ｄ．ｉｉｉ）、（ｇ．ｉｉ）、（ｇ．ｉｉｉ）、および（ｇ．ｉｖ）を使用してオーサライズされていないＵＥに関してＶＣＣをサポートする。
【００６４】
ＩＶ．ＩＭＳ緊急呼の発呼
緊急呼の発呼は３ＧＰＰ ＴＳ２３．１６７において定義されるように発生し得るが、ＶＣＣの使用の交渉をするための幾らかの変更を伴う。特に、任意のドメイン移動に続く音声呼の継続性と同様に、位置のサポートの継続性も保存するために、訪問されたネットワーク内のＥ−ＣＳＣＦ、またはＰ−ＣＳＣＦの何れか一方は、位置を取得、または検証するため、および宛先のＰＳＡＰを選択するためにＬＲＦを起動する前に、（ＩＭＳ緊急呼に関する）ＳＩＰ ＩＮＶＩＴＥを送信する必要があるだろう。その後、ＶＣＣアプリケーションは入って来る呼の区間を固定し、Ｅ−ＣＳＣＦを通じてＰＳＡＰに向かって新たな出て行く呼の区間を発生する。ＶＣＣアプリケーションからＳＩＰ ＩＮＶＩＴＥを受信する時に、Ｅ−ＣＳＣＦは、ＴＳ２３．１６７で定義されているように通常の位置付け操作とルーティングを実行し、ＩＰを介して、または媒体ゲートウェイ制御機能(Media Gateway Control Function)（ＭＧＣＦ）、および公衆交換電話網(Public Switched Telephone Network)（ＰＳＴＮ）を通じて該呼をＰＳＡＰへと転送する。ＶＣＣアプリケーションから出て行く呼の区間の一部として位置付け操作とルーティングを実行することは、アンカー位置抽出機能（ＬＲＦ）との関連付けが該呼の継続期間全体を通じて保存されたままであるようにするために必須のものである。アンカーＬＲＦとの継続的な関連付けは位置のサポートの継続性を可能とするだろう。特に該呼が最終的に解放される際に、先行するドメイン移動の数とは無関係に、Ｅ−ＣＳＣＦは依然として呼のシグナリング経路上にあり、従って、該呼が解放されたことをＬＲＦに知らせることができ、それにより、３ＧＰＰ ＴＳ２３．１６７における要件に従って、ＬＲＦが自身の呼の記録を解放することを可能とするだろう。
【００６５】
図７は、例示的な引き続く呼の発生の手順を図解し、ＶＣＣの使用を交渉することと任意のＶＣＣに関係する情報を転送することに関して既に説明された選択肢のうちの幾つかを可能なオプションとして含む。
【００６６】
ステップ１（緊急呼を開始する）：このステップではユーザーは緊急呼を開始する。
【００６７】
ステップ２（登録）：ユーザー装置（ＵＥ）７１０は、もしもそれが適格証明を含むならば、３ＧＰＰ ＴＳ２３．１６７において説明されているように、訪問されたネットワークＰ−ＣＳＣＦ７２０、およびホーム・ネットワークＳ−ＣＳＣＦ（図示されず）と共に緊急登録手順を実行しても良い。ＵＥ７１０によって送信されたＳＩＰ ＲＥＧＩＳＴＥＲメッセージ、またはホームＳ−ＣＳＣＦによって返されたＳＩＰ ２００ ＯＫメッセージは訪問されたネットワークＰ−ＣＳＣＦ７２０に対してＵＥ７１０がＶＣＣ可能であることを示すことが可能である。訪問されたネットワークＰ−ＣＳＣＦ７２０によってＵＥ７１０に返された「２００ ＯＫ」は、訪問されたネットワークがＶＣＣ可能であり、（必要ならば）ＶＤＮとＶＤＩを提供する可能性があることを示しても良い。
【００６８】
ステップ３（INVITE(emergency,VCC)）：ユーザー装置（ＵＥ）７１０訪問されたネットワークＰ−ＣＳＣＦ７２０に対して緊急の表示と共にＩＮＶＩＴＥを送信する。該ＩＮＶＩＴＥは、ＵＥが有する如何なる位置オブジェクトを含んでいても良い。該位置オブジェクトはアクセス・ネットワーク技術に依存している。ステップ２においてＶＣＣに関するＵＥのサポートが訪問されたネットワークに伝えられていなかった場合には、該ＩＮＶＩＴＥはそれを表示しても良く、ＵＥに関する識別子情報（例えば、ＳＩＰ、および電話のコールバックのアドレスまたは番号など）をも含んでいても良い。
【００６９】
ステップ４ａ、４ｂ、および４ｃ：ＩＮＶＩＴＥ内のＶＣＣサポートの何らかの表示、またはステップ２において取得されたＶＣＣサポートの知識、または（上記のセクションＩＩＩ．Ａで説明された）選択肢（ａ）および／または（ｂ）に従ったＶＣＣサポートの知識または仮定に基づいてＰ−ＣＳＣＦ７２０は、２つの異なる方法により該ＩＮＶＩＴＥを中継する。
【００７０】
ｉ．ステップ４ａ(INVITE(emergency,VCC))：Ｐ−ＣＳＣＦはＥ−ＣＳＣＦに対して、場合によってはＶＣＣサポートの表示と共にＳＩＰ ＩＮＶＩＴＥを中継する；そして、ステップ４ｂ(INVITE(emergency,VCC))において、ステップ４ａにおけるＶＣＣサポートの表示に基づいて、またはネットワーク・ポリシー（例えば、全てのＵＥによるＶＣＣサポートの仮定）に起因して、Ｅ−ＣＳＣＦ７４０は、ＶＣＣアプリケーション７６０に対してＳＩＰ ＩＮＶＩＴＥを中継する。
【００７１】
ｉｉ．ステップ４ｃ(INVITE(emergency,VCC))：代替的に、Ｐ−ＣＳＣＦは、ＳＩＰ ＩＮＶＩＴＥを直接的にＶＣＣアプリケーションに中継する。
【００７２】
ステップ５(INVITE(emergency))：ＶＣＣアプリケーション７６０は、Ｅ−ＣＳＣＦに対してＩＮＶＩＴＥを送信する（またはそこへ返送する）ことにより、入って来る呼の区間を固定し、出て行く区間を発生する。該ＩＮＶＩＴＥは依然として緊急の表示を伝達するが、もはやＶＣＣに関するサポートは表示しない。
【００７３】
ステップ６（位置を抽出する）：Ｅ−ＣＳＣＦ７４０は、３ＧＰＰ ＴＳ２３．１６７において定義されているように、緊急呼のセットアップに関して通常の取り扱いを実行する。ＩＮＶＩＴＥの中で提供された位置オブジェクトが正確なＰＳＡＰを決定するのに不充分である場合、またはＩＭＳコアがルーティング決定機能(Routing Determination Function)（ＲＤＦ）の支援を必要とする場合、またはＩＭＳコアが位置オブジェクトを検証することを要求されている場合、位置抽出機能を実行するためにＬＲＦ７３０に対して位置抽出要求(retrieve location request)が送信される。位置抽出要求は、ＵＥ７１０を識別する情報（例えば、ＭＳＩＳＤＮ、ＩＭＳＩ、および／またはＩＭＥＩなど）、およびＩＰ接続性アクセス・ネットワーク(IP Connectivity Access Network)（ＩＰ−ＣＡＮ）を含んでも良く、ＵＥをアクセスするための手段（例えば、ＵＥのＩＰアドレス）を含んでも良い。位置抽出要求はまた、ステップ３におけるＩＮＶＩＴＥの中で提供される任意の位置オブジェクトをも含んでも良い。位置抽出要求は、ＶＣＣサポートに関する表示、およびＶＣＣアプリケーション７６０に関する識別子情報（例えば、ＶＤＮ、およびＶＤＩなど）をさらに含んでも良い。しかしながら、セクションＶＩ．Ｂ．１、およびＶＩ．Ｂ．２において後述される手順ＣとＤに関してのみ、これは必要とされるかもしれない。
【００７４】
ステップ７（仮の位置を取得する）：ＬＲＦ７３０は仮の位置の推定を取得しても良い。仮の位置の推定を取得するための手段は、ＩＭＳをアクセスするためにＵＥ７１０が使用しているアクセス技術に依存しており、3GPP TS 23.271において定義されているPS-NI-LRまたはPS-MT-LR手順、OMA AD SUPL: "Secure User Plane Location Architecture"において定義されているSecure User Plane Location (SUPL)手順、OMA TS ULP: "User Plane Location Protocol"、または他の手順を使用することを含んでも良い。該仮の位置またはステップ６において受信された任意の位置オブジェクトをＰＳＡＰのアドレスへと変換するために、ＬＲＦ７３０は、ルーティング決定機能(Routing Determination Function)（ＲＤＦ）を起動しても良い。該ＬＲＦはステップ６において受信された情報を記録しても良い。
【００７５】
ステップ８（位置を返す）：（ステップ７で取得された）位置情報および／またはＰＳＡＰアドレスは、Ｅ−ＣＳＣＦ７４０に返される。ＬＲＦ７３０は自分自身とステップ７において記憶された任意の記録を識別する相関情報（例えば、ＥＳＱＫ）をさらに返しても良い。該呼の残りの部分に関しては、ＬＲＦ７３０はアンカーＬＲＦとしての役割を果たす。
【００７６】
ステップ９ａ、９ｂ、および９ｃ：Ｅ−ＣＳＣＦ７４０はステップ８において提供されたＰＳＡＰアドレスを使用し、または、場合によってはステップ８において提供された位置情報に基づいて、緊急センター、またはＰＳＡＰ自身を選択し、該位置情報および任意の相関情報を含む要求を該緊急センター、またはＰＳＡＰ７８０へと送信する。
【００７７】
ステップ９ａ（INVITE(emergency)）：MGCF/MGW (Media Gateway Control Function/Media Gateway) ７７０に対してINVITEが送信される；
および、ステップ９ｂ（ＩＡＭ）：緊急センターまたはＰＳＡＰへ向かってSS7 ISUP IAMが継続される；
または、ステップ９ｃ（INVITE(emergency)）：INVITEが緊急センターまたはＰＳＡＰ７８０に対して直接に送信される。
【００７８】
ステップ１０ａ、１０ｂ、および１０ｃ：図示されていない呼の確立のための中間のシグナリングが生起しても良い（例えば、PSTN機能を有するPSAPからSS7 ISUP ACMを返すこと）。ＰＳＡＰが該呼に応答するとき、下記のステップが生起する。
【００７９】
ステップ１０ａ（ＡＮＭ）：ＰＳＡＰ７８０はMGCF/MGW７７０に対してSS7 ISUP ANMを返す；
および、ステップ１０ｂ（200 OK）：該MGCF/MGWは”200 OK”を該Ｅ−ＣＳＣＦに対して返す；
または、ステップ１０ｃ（200 OK）：ＰＳＡＰ７８０は、Ｅ−ＣＳＣＦ７６０に対して直接に”200 OK”を返す。
【００８０】
ステップ１１（200 OK）：Ｅ−ＣＳＣＦ７４０は（ステップ５において開始した出て行く呼のレグの上の）該ＶＣＣアプリケーション７６０に対して“200 OK”を返す。
【００８１】
ステップ１２（200 OK）：ステップ４ｃが以前に使用されたならば、ＶＣＣアプリケーション７６０は、（ステップ４において使用された入って来る呼のレグの上の）Ｅ−ＣＳＣＦ、または（図７に図示されていない）Ｐ−ＣＳＣＦ７２０の何れか一方に対して”200 OK”を返す。もしも、ＵＥ７１０がＶＣＣに関する訪問されたネットワークのサポート、およびステップ２またはステップ２以前における関連付けられた如何なるＶＣＣ情報（例えば、ＶＤＮ、ＶＤＩなど）も発見しなかった場合、ＶＣＣアプリケーション７６０によって返された”200 OK”はＶＣＣに関するサポートを表示している可能性があり、ＶＤＮおよび／またはＶＤＩを含む可能性がある。
【００８２】
ステップ１３（200 OK）：（該Ｅ−ＣＳＣＦからである場合は、例えば、Ｐ−ＣＳＣＦ７２０を介して）Ｅ−ＣＳＣＦ７４０またはＰ−ＣＳＣＦ７２０はＵＥ７１０に対して”200 OK”を返す。ＶＣＣアプリケーション７６０への影響を減らすために、ステップ１２において、Ｅ−ＣＳＣＦ７４０により、またはＰ−ＣＳＣＦ７２０により、かつＶＣＣアプリケーション７６０によらずに、如何なるＶＣＣ表示およびＶＤＮ／ＶＤＩも”200 OK”の中に置かれることができるだろう。その後、ＵＥ７１０は任意の受信されたＶＤＮおよび／またはＶＤＩを記憶する。ＵＥ７１０と図７の緊急センター７８０の間に緊急呼が確立された後に、3GPP TS 23.167およびTS23.271において既に定義されている手順を使用して該緊急センターはＬＲＦ７３０からより正確な位置を要求しても良い。
【００８３】
Ｖ．ＣＳ緊急呼の発呼
ＣＳ（回線交換）ドメインにおいて発呼されたＶＣＣ呼をサポートするための例示的な解決法が図８に図解されている。この場合、該Ｅ−ＣＳＣＦもまた、出て行く呼のレグの上のＶＣＣアプリケーションから起動され、加えて、下記で説明されるように該ＶＣＣアプリケーションに対して入って来る呼のレグを正しくルーティングするために、該ＶＣＣアプリケーションへの入って来る呼のレグの上で該ＭＳＣによって既存のGMLC MAP問い合わせが使用されることができる。この例において、該入って来る呼のレグをＶＣＣアプリケーションに対してルーティングするために、該ＧＭＬＣはＩＰマルチメディア・ルーティング番号(IP Multimedia Routing Number)（ＩＭＲＮ）を使用する。該ＧＭＬＣ問い合わせとＩＭＲＮの使用は下記に示されるように該ＭＳＣに対して、部分的または完全に透過的であることが可能である。
【００８４】
ステップ１（緊急呼を開始する）：このステップにおいては、ユーザーは緊急呼を開始する。
【００８５】
ステップ２（Emergency Setup）：（3GPP TS24.008において定義されているような）ＶＭＳＣ８３０に対してEmergency Setupメッセージを送信することにより、ＵＥ８１０はＣＳドメインにおいて、緊急音声呼び出しを発呼する。該Setupメッセージは該ＵＥがＶＣＣをサポートすることを表示しても良い。
【００８６】
ステップ３（位置付け・手順）：3GPP TS23.271において定義され、可能とされている通り、ＵＥ８１０に関する仮の位置の推定を取得するためにＶＭＳＣ８３０は該ＲＡＮにおける手順を開始しても良い。
【００８７】
ステップ４（ＭＡＰ加入者位置の報告）：局所的なＶＭＳＣ８３０のポリシーに基づいて、またはＵＥのホームＨＬＲ／ＨＳＳから取得された加入情報に基づいて、またはステップ２において受信された任意のＶＣＣ表示に基づいて、ＶＭＳＣ８３０は、（例えば、サービス中のセルのＩＤ、およびダイアルされた緊急番号に基づいて）該呼が通常はそこに向けて送信されるであろう緊急サービス・プロバイダー（ＰＳＡＰ）に関連付けられたＧＭＬＣに対してＭＡＰ加入者位置の報告を送信する。該ＭＡＰ加入者位置の報告はＩＭＳＩ、ＭＳＩＳＤＮ、ＩＭＥＩ、ＶＭＳＣアドレス、およびサービス中のセルの識別子、またはＵＥに関するＳＡＩを搬送する。それはまた、ステップ３において取得された任意の仮の位置の推定をも含む。通常、ＧＭＬＣ８５０ではなく、ＶＭＳＣ８３０が該ＰＳＡＰを決定する地域（例えば、欧州共同体など）においては該メッセージは意図された宛先ＰＳＡＰのアドレスを搬送しても良い。もしも、ステップ２において、ＭＳがＶＣＣサポートの表示を提供したならば、ＭＡＰ加入者位置の報告はさらにそのような表示をも搬送しても良い。
【００８８】
ステップ５（ＭＡＰ加入者位置の報告のＡＣＫ）：ＵＥ８１０がＶＣＣをサポートする、さもなくばＵＥ８１０がホームネットワークによりサービスされているならば、加入情報からこれを決定し、さもなくば、ステップ４において提供された任意のＶＣＣ表示からGMLC８５０がこれを決定することをGMLC８５０は仮定している。GMLC８５０は、ステップ４において受信された全ての情報を含むＵＥ８１０に関する呼記録を記憶する。GMLC８５０は該呼に対してＩＰマルチメディア・ルーティング番号(IP Multimedia Routing Number)(IMRN)を割り当てる。該IMRNは国際ITU E.164 ISDN/電話番号、国際ISDN/電話番号、または何らかの他の番号、または複数の番号または複数のパラメータの組み合わせ（例えば、１０進数の一の系列または幾つかの系列から構成されている）であっても良い。該IMRNはさらに他の名前で−例えば「ルーティング番号」と呼ばれても良い。少なくとも、該IMRNはステップ６と７においてＶＣＣアプリケーション８７０への呼のルーティングを可能にし、該GMLCを識別する。付加的に、該IMRNはさらに、該GMLCの中に記憶された呼記録を一時的に識別してもよく、および／またはＰＳＡＰを表示しても良い。NA-ESRD、またはNA-ESRKパラメータの中で、または何らかの他のパラメータまたは複数のパラメータの組の中でIMRNを搬送しながら、該GMLCはVMSC８３０に対してＭＡＰ加入者位置の報告のＡＣＫを返す。ルーティングのための仮の位置の推定、またはＰＳＡＰへの後の提供のための正確な位置の推定を取得するために、GMLC８５０は、VMSC８３０によるCS-MT-LR（図４には示されていない）を引き起こしても良い。ステップ３ではなく、このステップにおいて仮の位置の推定が取得されるならば、セクションVIでさらに説明されるように、ＩＭＳからＣＳへのドメイン移動をサポートするために、図８の手順が再利用されることが可能となるだろう。
【００８９】
ステップ６（ＩＡＭ）：VMSC８３０はステップ５において受信されたIMRNに基づいて該呼をルーティングする。もしも、既存のNA-ESRKまたはNA-ESRDパラメータを使用してIMRNが搬送されるならばVMSC８３０における呼のルーティングの手順は3GPP TS23.271における通常の緊急呼の発呼のために使用されるものと同じもので有りうる。IMRNルーティングに基づいて、VMSC８３０は訪問されたネットワーク内のＭＧＣＦ８４０に対して該呼をルーティングする。
【００９０】
ステップ７（INVITE(MRN)）：ＭＧＣＦ８４０は訪問されたＩＭＳ内のＩ−ＣＳＣＦ（図８には図示されていない）に向かってINVITEを送り出し、または場合によってはＭＧＣＦ８４０はＥ−ＣＳＣＦ８６０、Ｓ−ＣＳＣＦ（図８において図示されていない）、またはＶＣＣアプリケーション８７０に対して直接にルーティングする。INVITEはＵＥ８１０の識別子（例えば、コンタクトアドレスとして、MSISDN Tel URIなど）を含む。該Ｉ−ＣＳＣＦまたは該Ｓ−ＣＳＣＦ（図示なし）、またはＥ−ＣＳＣＦ８６０はIMRNに基づいて、ＰＳＩに基づくアプリケーションサーバの終了をＶＣＣアプリケーション８７０に対して引き起こす。
【００９１】
ステップ８（ＩＮＶＩＴＥ）：ＩＮＶＩＴＥをＥ−ＣＳＣＦ８６０へ送信し、またはＥ−ＣＳＣＦに戻すことにより、ＶＣＣアプリケーション８７０は入って来る呼のレグをアンカーリングし出て行くレグを発生させる。該ＩＮＶＩＴＥは、（例えば、ＳＩＰ ＩＮＶＩＴＥ ＴＯヘッダーの中で）緊急呼を識別し、該IMRNの復元を可能にする（例えば、IMRNの中の一意の数字が含まれても良く、既知の固定された数字が除かれても良い）情報を搬送する。位置情報（例えば、pidf-lo）は含まれている必要はない。
【００９２】
ステップ９（位置を抽出する）：例えば、ステップ８におけるIMRN情報の包含に基づいて、Ｅ−ＣＳＣＦ８６０はIMRNによって識別され、または関連付けられたＬＲＦ８５０に対して位置抽出要求を送信しても良い。該位置抽出要求はステップ８において受信されたIMRN情報、および任意のＵＥの識別子（例えば、MSISDN Tel URI）を含む。位置抽出要求は、ＶＣＣサポートの表示およびＶＣＣアプリケーションに関する識別情報−例えば、ＶＤＮおよびＶＤＩをさらに含んでも良い。しかしながら、これはセクションVI.B.1およびVI.B.2で後述する手順ＣおよびＤに関してのみ必要とされるかもしれない。
【００９３】
ステップ１０（位置を返す）：ステップ９において受信されたＵＥの任意の識別子（例えば、MSISDN）、および／またはIMRN情報に基づいて、ＬＲＦ８５０はＧＭＬＣ８５０と相互作用し、ステップ５においてＧＭＬＣ８５０によって記憶された呼記録を抽出する。既に該呼記録の中にある任意の仮の位置の情報、または（一旦これが完了したならば）ステップ５に従って取得された任意の仮の位置、または意図されたＰＳＡＰの宛先の識別子を使用して、ＬＲＦ８５０はＰＳＡＰアドレス、そして場合によっては位置情報をＥ−ＣＳＣＦ８６０に対して返す。該ＬＲＦと該ＧＭＬＣとが別個のものであるならば、該ＬＲＦは、位置の更なるサポートのためにアンカーポイントを提供するだろうし、該ＧＭＬＣから取得された呼記録をコピーしてもよく、ステップ９において該Ｅ−ＣＳＣＦから受信した情報を格納しても良い。該ＬＲＦはＥ−ＣＳＣＦ８６０に対して相関情報（例えば、ＥＳＱＫなど）を返して、自分自身と該呼記録を識別しても良い。該ＬＲＦはさらに、ＵＥに関する正確な位置の推定を取得するために（3GPP TS23.271において定義されているとおりの）ＶＭＳＣ８３０によってCS-MT-LR手順を引き起こすために、該ＧＭＬＣと相互作用しても良い。もしも、ステップ５においてＧＭＬＣ８５０によって提供されたＩＭＲＮがＰＳＡＡＰを表示し、該ＬＲＦと該ＧＭＬＣが密接に関連付けられている（例えば、同一のエンティティの複数の部分であるなど）場合には、ステップ９と１０は実行されないかも知れず、該Ｅ−ＣＳＣＦは該ＰＳＡＰアドレスを取得するために該ＩＭＲＮを使用しても良い。
【００９４】
ステップ１１（ＩＮＶＩＴＥ）：Ｅ−ＣＳＣＦ８６０は、ステップ１０において取得されたＰＳＡＰアドレスを使用し、緊急センターまたはＰＳＡＰに対して任意の位置情報および任意の相関情報（例えば、ＥＳＱＫまたはＩＭＲＮなど）を含む呼要求を送信し続ける。該呼要求はＭＧＣＦ／ＭＧＷを介してＰＳＴＮ（図示なし）の中へと送信されるか、またはＩＰ機能を有する緊急センターまたはＰＳＡＰに向かってＳＩＰ ＩＮＶＩＴＥとして直接に送信されるかの何れかである。
【００９５】
ステップ１２（ＣＳ緊急呼の残りの部分を確立する）：呼の確立手順の残りは、3GPP TS23.206において記載されたVCC CS発呼手順に基づいて、ＵＥ８１０、ＶＭＳＣ８３０、ＭＧＣＦ８４０、ＶＣＣアプリケーション８７０、Ｅ−ＣＳＣＦ８６０、およびＰＳＡＰの間で生起する。
【００９６】
図８のステップ２において、新しいサービスのカテゴリーとして（3GPP TS24.008において定義されている）Emergency Setupメッセージの中の緊急カテゴリー・パラメーターの中には任意のＶＣＣ表示が含まれているかもしれない（何故なら、現状では、最大で３つまでの新しいサービスカテゴリーが定義されることを可能とする３個の予備のビットが存在するからである）。ＣＳモードの残りの予想されるライフタイムの期間中に、新しい緊急カテゴリーが全く予期されない場合、これは機能することが可能であるかもしれない。
【００９７】
図８におけるＵＥ８１０と該ＰＳＡＰの間で緊急呼が確立された後に、3GPP TS23.167およびTS23.271において既に定義されている手順を使用して該ＰＳＡＰはＬＲＦ８５０からのより正確な位置を要求しても良い。特に、ＬＲＦ８５０を識別するために、例えばＥＳＱＫやＩＭＲＮのような、図８のステップ１１においてＥ−ＣＳＣＦ８６０から受信された任意の相関情報を該ＰＳＡＰは使用できる。ステップ９と１０が実行されていない場合には、図８のステップ５においてＧＭＬＣ８５０内で確立されたＵＥに関する記録を抽出するために、ＬＲＦ８５０は図８におけるステップ１０に関して説明されたとおり、ＧＭＬＣ８５０と相互作用する必要があるだろう。
【００９８】
上記の手順は（例えば、セルＩＤまたは仮の位置の推定を使用して）既存のＰＳＡＰルーティング・オプションに関するサポートを保存し、ＭＳＣに対する如何なる新しい影響も必要としない可能性があり、そして3GPP TS23.167およびTS23.271において現在定義されている方法で、該ＰＳＡＰによる正確な位置の抽出をサポートする。それはさらに、ＣＳが発呼した緊急呼がＩＰ機能を有するＰＳＡＰに対して送信されることを可能にする。
【００９９】
3GPP2の場合、該ＶＣＣアプリケーションを3GPP2における同等のエンティティによって置き換えることに加えて、ステップ４と５において示された3GPP MAPメッセージもまた3GPP2における同等のメッセージによって置き換えられることを除いて、ＣＳ緊急呼の発呼を記述するためにもまた図８は適用可能である。この場合、ステップ４と５における3GPP2メッセージはそれぞれ3GPP2 MAP発呼要求、およびMAP発呼要求ＡＣＫであり、ステップ４におけるMSISDNは移動機識別番号(Mobile Identification Number)(MIN)、または移動機ディレクトリ番号(Mobile Directory Number)(MDN)により置き換えられ、図８における該ＧＭＬＣは3GPP2移動機位置センター(Mobile Position Center)(MPC)によって置き換えられるだろう。
【０１００】
ＶＩ．ドメイン移動
ドメイン移動は、3GPP TS23.206において定義されているような通常のＶＣＣに関するものと非常に良く似た方法で生起する。図９Ａと９Ｂはユーザープレーンの切り替えを示している3GPP TS23.206中の図面に基づいている。ＩＭＳ緊急呼に関するＶＣＣのサポートに関しては、図９Ａと９Ｂにおいて示されたＳ−ＣＳＣＦ９１０は（訪問されたネットワーク内にあり、図１０Ａと１０Ｂにおいて示される）Ｅ−ＣＳＣＦ１０５０によって置き換えられ、ＵＥ＃Ｂ９２０および９３０（それぞれ図９Ａと９Ｂに示されている）は（図１０Ａと１０Ｂにおいて示される）ＰＳＡＰ１０６０に対応するだろう。
【０１０１】
ＶＩ．Ａ． ＩＭＳからＣＳへのドメイン移動
ＵＥがＩＭＳのカバー範囲から出てＣＳのカバー範囲の中へと移動したとき、ＩＭＳドメインからＣＳドメインへのＩＭＳ緊急呼に関するドメイン移動をサポートするために２つの代替的な手順がここで説明される。このセクションで説明されている手順Ａにおいては、ＶＣＣ機能を有するＵＥは（3GPP TS23.206において説明されている）通常のＶＣＣに関するものとして振る舞い、上記セクションIII.Bにおいて説明された選択肢(e)、(f)、(g)または(h)のいずれかを使用して訪問されたネットワークまたはホームネットワークから取得されたＶＤＮを使用して該ＶＣＣアプリケーションに対してＣＳドメイン内の新たな呼のレグを発生させる。
【０１０２】
ＶＩ．Ａ．１． ＩＭＳからＣＳへのドメイン移動 − 手順Ａ
一実施例において、ＣＳドメインをサポートする新たな訪問されたネットワークにおいて登録するための充分な信任状を有するＵＥ１１１０に対して、手順Ａは適用可能であり、該ＰＳＡＰに対するさらなるＵＥ位置の更新を提供するためのサポートの継続性について制限を加える。しかしながら該手順は、ＵＥから見て、通常のＶＣＣに関するＩＭＳからＣＳへのドメイン移動と互換性があるという有利な点を有している。図１１は手順Ａの例示的な実装を図解している。
【０１０３】
ステップ１（Setup(VDN)）：ＵＥがＣＳへのドメイン移動の必要性を判断した際にユーザーがＣＳドメインに関係付けられていなかった場合には、該ＵＥは、そのHLR/HSSに対する位置の更新を含むCS Attachを実行する。ＣＳドメインを介してアクセス・レグを確立するために、元の訪問されたネットワーク、またはホームネットワークから以前に取得されたＶＤＮを使用してＣＳドメインにおける音声呼を、それは引き続いて発呼する。この手順においては、該ＵＥはＣＳドメインにおいて認証されることが可能であると仮定されている。
【０１０４】
ステップ２（ＣＳ発呼手順）：発生する呼はＣＳネットワーク内での通常のＣＳ発呼に関するものとして処理される。
【０１０５】
ステップ３（IAM(VDN)）：訪問された移動交換センター（ＶＭＳＣ）１１３０は元の訪問されたネットワーク内のＭＧＣＦ１１４０を介して元の訪問されたＩＭＳネットワークに向かって該呼をルーティングする。
【０１０６】
ステップ４（INVITE(VCCアプリケーション)）：ＭＧＣＦ１１４０は元の訪問されたＩＭＳ内の問い合わせを行っているＣＳＣＦ（Ｉ−ＣＳＣＦ；図１１には示されていない）に向かってＩＮＶＩＴＥを送り出す、または場合によっては、Ｅ−ＣＳＣＦ１１６０、Ｓ−ＣＳＣＦ、またはＶＣＣアプリケーション１１７０に対して直接にルーティングする。該Ｉ−ＣＳＣＦ、または該Ｓ−ＣＳＣＦ（図示なし）、またはＥ−ＣＳＣＦ１１６０は、ＶＤＮに基づいて、ＶＣＣアプリケーション１１７０に対してＰＳＩに基づくアプリケーション・サーバーの終了を引き起こす。
【０１０７】
ステップ５（更新、または再度のINVITE）：Ｅ−ＣＳＣＦ１１６０を介してリモート端に対して、移動して入ってきたドメイン内で確立されたアクセス・レグのＳＤＰを通信することにより、ＶＣＣアプリケーション１１７０は、出て行くアクセス・レグを更新する。アクセス・レグの更新は、ＩＥＴＦ ＲＦＣ３２６１におけるＳＩＰセッション修正手順に従って生起する。ＶＣＣアプリケーション１１７０はまた、Ｅ−ＣＳＣＦ１１６０に対してドメイン移動を明示的に表示しても良い。
【０１０８】
ステップ６（位置の更新）：Ｅ−ＣＳＣＦ１１６０は新たなＳＤＰ情報と共にアンカーＬＲＦ１１５０に対して位置の更新を送信する。少なくとも、Ｅ−ＣＳＣＦ１１６０は、ＬＲＦ１１５０に対してＣＳドメイン移動があったことを表示する（例えば、ＶＤＩではなく、ＶＤＮを使用することから、および／またはＭＧＣＦ１１４０を伴うドメイン移動から、この事はＶＣＣアプリケーション１１７０によって知られることができる）。
【０１０９】
ステップ７（更新、または再度のＩＮＶＩＴＥ）：該ＰＳＡＰが（図１０Ａにおいて図解されるように）ＩＰ機能を有するならば、該ＰＳＡＰに向かって、または該ＰＳＡＰが（図１０Ｂにおいて図解されるように）ＣＳ機能のみを有するならば該ＭＧＣＦに向かって、該更新は継続する。
【０１１０】
ステップ８（ＣＳドメインの呼のレグの完了）：移動して入って来るＣＳドメインの中の新たな呼のレグはＶＣＣアプリケーション１１７０、Ｅ−ＣＳＣＦ１１６０、またはもし有ればＳ−ＣＳＣＦ、もし有ればＩ−ＣＳＣＦ、ＭＧＣＦ１１４０、ＶＭＳＣ１１３０、およびＵＥ１１１０の間で確立される。
【０１１１】
ステップ９（ソース・アクセス・レグの解放）：ＩＭＳの上で以前に確立されたアクセス・レグである以前の入って来るアクセス・レグが解放される。ＵＥ１１１０は、訪問されたネットワークのＰ−ＣＳＣＦとホームネットワークのＳ−ＣＳＣＦにおいて、可能であれば登録を抹消すべきである。
【０１１２】
一実施例において、手順ＡがＵＥをＣＳドメインへと移動させた後の位置のサポートの継続性は下記のとおりに制限される可能性がある。もしも、ＵＥの位置を取得するためにＰＳＡＰがアンカーＬＲＦに対して要求を送信するならば、ＵＥがＩＭＳドメイン内にあった間に使用していた（または使用すると予期していた）のと同一の位置の取得のための手順を使用し続けることは該ＬＲＦにとっては不可能であるかもしれない。例えば、該ＬＲＦとＵＥの間でUDP/IP、TCP/IP、および／またはSIPトランスポートに基づいたOMA SUPLを該ＬＲＦが使用していたならば、ＩＭＳからＣＳドメインへのドメイン移動に続いて起こる、ＵＥによるＰＳドメインに対するアクセスの喪失は、ＳＵＰＬのそれ以降の使用を妨げるかもしれない。加えて、該ＬＲＦは（例えば、3GPP TS23.271の9.1.3節におけるような）ＣＳ緊急呼に関して3GPP TS23.271において定義されている制御プレーンの位置解決法を使用することができないかもしれない。何故なら、それはＶＭＳＣアドレスを知らないかもしれないからである。しかしながら、該ＬＲＦは、3GPP TS23.271の9.1.1節および9.1.2節において説明されているより一般的なCS-MT-LR手順を使用でき、該手順においてはＧＭＬＣ（Gateway Mobile Location Center）として振舞う、またはＧＭＬＣにアクセスする該ＬＲＦは、ＵＥのホームHLR/HSSを問い合わせることによりＶＭＳＣアドレスを取得する。しかしながら、これの不利な点は、ＵＥのHLR/HSSがCS-MT-LR問い合わせ手順をサポートする必要性があるであろうこと、および、（ホームネットワークは緊急呼の重要性に気付いていない可能性があるため）訪問されたネットワークとホームネットワークとの間で課金上の問題が存在する可能性があることである。
【０１１３】
ＶＩ．Ａ．２ ＩＭＳからＣＳへのドメイン移動 − 手順Ｂ
代替的な実施例において、ＩＭＳからＣＳへのドメイン移動を可能にする手順Ｂは、ＵＥが新たな訪問されたネットワークにおいて登録するための充分な信任状を有するか否かにかかわらず、ＵＥに適用可能であり、制限なしに位置のサポートの継続性を可能にする。しかしながら、一実施例においては、この手順は同一の通信事業者に属するネットワークの間でのドメイン移動に制限される可能性がある。さらに、手順Ｂは、ＶＤＮの知識が必要とされないようなＵＥにおけるＶＣＣドメイン移動の新しい変形を必要とする。図１２は、手順Ｂの例示的な実装を図解する。
【０１１４】
ステップ１（Emergency SETUP(VCC)）：ＣＳヘのドメイン移動の必要性をＵＥが判断した時点で、ユーザーがＣＳドメインに関連付けられていない場合、ＵＥ１２１０は、それが信任状を含んでいるならば、CS Attachを実行しても良い。（3GPP TS24.008において定義されているとおり）Emergency SetupメッセージをＶＭＳＣ１２３０に送信することにより、ＣＳドメインにおいて、それは緊急音声呼を引き続いて発呼する。該Emergency SetupメッセージはＶＣＣサポートの表示を含んでも良い。しかしながら、ＶＤＮは一切含まれる必要がない。
【０１１５】
ステップ２（MAP加入者位置(IMSI,IMEI)）：局所的なＶＭＳＣのポリシーに基づいて、またはＵＥのホームHLR/HSSから取得された加入情報に基づいて、またはステップ１において受信された任意のＶＣＣ表示に基づいて、該呼が通常はそこへ向けて送信される緊急サービス・プロバイダー（ＰＳＡＰ）と関連付けられたＧＭＬＣ１２５０に対してＶＭＳＣ１２３０はMAP加入者位置の報告を送信する。該MAP加入者位置の報告は（例えば図８におけるステップ４などの）通常の緊急呼の発呼に関して送信されるであろうものと同一の情報を搬送し、それはＩＭＳＩ、ＭＳＩＳＤＮ、ＩＭＥＩ、ＶＭＳＣアドレス、および、サービス中のセルの識別子またはＳＡＩを含む。一実施例においては、位置の推定は全く含まれていないが、ＶＣＣの使用の表示は含まれていても良い。
【０１１６】
ステップ３（MAP加入者位置のＡＣＫ(VDN)）：局所的なポリシーに基づいて、またはステップ２におけるＶＣＣ表示の受信に起因して、（例えば、図７または図８において説明された手順を使用して）アンカーＬＲＦ１２５０内で最初に確立されたＵＥ１２１０に関する呼記録を探索するために、該ＧＭＬＣは関連付けられたＬＲＦ（該ＧＭＬＣと同一の物理的エンティティ内の論理的なＬＲＦ）、または関連付けられたＬＲＦの集合と相互作用する。正しい呼記録を識別するために、アンカーＬＲＦ１２５０はステップ２で受信されたＩＭＳＩ、ＭＳＩＳＤＮ、および／またはＩＭＥＩを使用しても良い。呼記録が全く見つからず、ステップ１においてＵＥがＶＣＣドメイン移動を表示しなかったならば、ＧＭＬＣ１２５０は、ＣＳ緊急呼の発呼に関するＶＣＣがサポートされている場合に、例えば図８におけるように、これは新しい緊急呼であると仮定し、それを確立するために処理を実行する。呼記録が見つからず、ステップ１においてＵＥがＶＣＣドメイン移動を表示したならば、ＧＭＬＣ１２５０は代わりにＶＭＳＣ（図示なし）に対してMAP加入者位置の報告のリターンエラーを返し、該ＶＭＳＣは呼の試行を解放するだろう。この事は、ＵＥがユーザーの観点から該呼を解放することを可能にし、ＶＣＣドメイン移動が失敗してからユーザーが緊急呼を再試行することを可能にするだろう。さもなくば、呼記録が見つかった場合、ＧＭＬＣ１２５０は、ＶＭＳＣ１２３０に対してMAP加入者位置の報告のＡＣＫを返し、新しいアクセス・レグを確立するのに必要とされるＶＤＮを搬送する。（例えば、図７のステップ６において、または図８のステップ９において）該呼が最初に発呼された時に、該ＶＤＮはＬＲＦ１２５０によって取得されているであろうし、それが該ＬＲＦ内の呼記録の位置を特定した際に、ＧＭＬＣ１２５０に対して提供されるだろう。該ＶＤＮは該MAP加入者位置の報告のＡＣＫ内の既存のNA-ESRKまたは既存のNA-ESRDパラメーターによって搬送されることが可能だろう。ＧＭＬＣ１２５０はまた、ステップ２においてＶＭＳＣ１２３０から受信された情報を記憶する。
【０１１７】
ステップ４(IAM(VDN))：ＶＭＳＣ１２３０は、ステップ３において受信されたＶＤＮに基づいて新たなレグをルーティングする。該ＶＤＮが既存のNA-ESRKまたはNA-ESRDパラメータを使用して搬送されるならば、該呼のルーティングは通常の緊急呼の発呼に関して使用するものと同一であることが可能である。ＶＤＮのルーティングに基づいて、ＶＭＳＣ１２３０は、訪問されたネットワーク内でＭＧＣＦ１２４０を介して最初の訪問されたＩＭＳネットワークに向かって該呼をルーティングする。
【０１１８】
ステップ５（INVITE(VCCアプリケーション)）：ＭＧＣＦ１２４０は訪問されたＩＭＳ（図示なし）内のＩ−ＣＳＣＦに向かってINVITEを送り出し、または場合によってはＭＧＣＦ１２４０は、Ｅ−ＣＳＣＦ１２６０、Ｓ−ＣＳＣＦ（図示なし）、またはＶＣＣアプリケーション１２７０に対して直接にルーティングする。該Ｉ−ＣＳＣＦ、またはＳ−ＣＳＣＦ（図示なし）、またはＥ−ＣＳＣＦ１２６０は該ＶＤＮに基づいて、ＶＣＣアプリケーション１２７０に対し、ＰＳＩに基づくアプリケーションサーバーの終了を引き起こす。
【０１１９】
ステップ６（更新、または再度のINVITE）：移動して入ってきたドメインにおいて確立されたアクセス・レグのＳＤＰをＥ−ＣＳＣＦ１２６０を介してリモート端に対して通信することにより、ＶＣＣアプリケーション１２７０は、出て行くアクセス・レグを更新する。アクセス・レグの更新はＩＥＴＦ３２６１におけるＳＩＰセッション修正手順に従って生起する。ＶＣＣアプリケーション１２７０はまた、Ｅ−ＣＳＣＦ１２６０に対してＣＳドメイン移動を明示的に表示しても良い。
【０１２０】
ステップ７（位置の更新）：Ｅ−ＣＳＣＦ１２６０は、新たなＳＤＰ情報と共に、アンカーＬＲＦ１２５０に対して位置の更新を送信する。少なくとも、Ｅ−ＣＳＣＦ１２６０はＬＲＦ１２５０に対してＣＳドメイン移動があったことを表示する。ＬＲＦ１２５０は、この表示をステップ３において決定されたドメイン移動の表示と相関させ、今やＵＥ１２１０はステップ２において表示されたものへとドメインを変更したことを判定する。ＬＲＦ１２５０は、ステップ２においてＶＭＳＣ１２３０によって選択されたＧＭＬＣに対してこの情報を通信する。
【０１２１】
ステップ８（更新、または再度のINVITE）：（図１０Ａにおいて図解されたような）ＰＳＡＰに向かって、または（図１０Ｂにおいて図解されたような）ＭＧＣＦに向かって更新は継続する。
【０１２２】
ステップ９（ソース・アクセス・レグの解放）：移動して入ってきたＣＳドメインの中の新たな呼のレグはＶＣＣアプリケーション１２７０、Ｅ−ＣＳＣＦ１２６０またはもし存在するならＳ−ＣＳＣＦ、もし存在するならＩ−ＣＳＣＦ、ＭＧＣＦ１２４０、ＶＭＳＣ１２３０、およびＵＥ１２１０の間で確立される。
【０１２３】
ステップ１０（ＣＳ呼の確立の残りの部分）：ＩＭＳ上で以前に確立されたアクセス・レグであるソース・アクセス・レグが解放される。もしも可能なら、訪問されたネットワークＰ−ＣＳＣＦおよびホームネットワークＳ−ＣＳＣＦにおいて、ＵＥ１２１０は登録を抹消すべきである。
【０１２４】
一実施例では、図１２のステップ１において、Emergency Setupメッセージ中の緊急カテゴリー・パラメーター内に、新しいサービス・カテゴリーとして、ＶＣＣ表示が含まれることが可能だろう（何故なら、最大で３つまでの新しいサービス・カテゴリーが定義されることを可能とする３個の予備のビットが現在存在するからである）。この実施例においては、（両方の手順が可能とされている場合は）下記の情報に基づいて手順Ａの代わりに手順ＢがＵＥによって開始されることが可能である。
【０１２５】
（ｍ）元の訪問されたネットワークからＵＥへの手順Ｂがサポートされることの表示。
【０１２６】
（ｎ）新たな訪問されたＣＳドメイン、および元の訪問されたＩＭＳまたはＣＳドメインが同一の通信事業者によって所有され、またはそれらが同一のネットワークの部分であり、または手順Ｂをサポートするための用意ができていることのＵＥによる判定。
【０１２７】
（ｏ）手順Ｂがサポートされているとの（例えば、ホームネットワークの通信事業者によって提供された）既にＵＥ内部にある情報。
【０１２８】
ＵＥに対するＶＣＣ関連の情報を搬送するためのセクションIII.Bにおいて説明された選択肢（選択肢(e)、(f)、または(g)）の何れかを使用して、（ｍ）における表示は、ＵＥに対して明示的または暗黙的に搬送されることが可能である。
【０１２９】
（ｎ）における判定は元の訪問されたドメインと新たな訪問されたＣＳドメインにおいて同一の通信事業者識別子（例えば、同一のＭＣＣ−ＭＮＣなど）を検出することに基づくことが可能であろう。その代わりに決定は新たな訪問されたネットワークから受信されたシステム・ブロードキャスト情報（例えば、該新たな訪問されたネットワークが手順Ｂをサポートすることの情報、および場合によっては、手順Ｂがサポートされる他のネットワークの識別子）に基づいているかもしれない。代替的に、（ｍ）と（ｎ）の両者の決定は、手順Ｂをサポートする用意がある全ての通信事業者を識別し、ＵＥに関するＳＩＭ／ＵＳＩＭ内に記憶された情報（例えば、（ｏ）において可能とされているような）に基づくかもしれない。
【０１３０】
登録されていないＵＥに関するドメイン移動を可能とすることとは別に、手順Ｂはさらに、緊急呼を発呼したＵＥを位置付けるために3GPP TS23.271（例えば、9.1.3節）において定義されている通常の位置付け手順をアンカーＬＲＦが活用することを可能にする。この事は、図１２におけるステップ２および３によって可能とされ、該ステップにおいては、該ＶＭＳＣは、該ＧＭＬＣに関連した情報を取得して記憶し、該ＬＲＦと該ＧＭＬＣは、該ＶＭＳＣに関連した情報を取得して記憶する。これはその後、ＵＥのホームHSS/HLRを問い合わせする必要性なしにCS-MT-LRを許可する。
【０１３１】
一実施例においては、手順Ｂのさらなる態様は次のとおりである。該ＶＭＳＣにおける該呼の発呼の手順は、通常の回線モードの緊急呼（例えば、3GPP TS 23.271、および関連するTIA/EIA/ATIS J-STD-036において定義されているようなもの）に関するものと同一であることが可能であり、および／または、図８において説明されたようなＣＳから発呼された緊急呼に関するＶＣＣサポートに関するものと同一であることが可能である。該ＧＭＬＣの観点から、該手順はさらに、該ＶＭＳＣを伴うMAPシグナリング・トランザクションに関連する通常の回線モードの緊急呼に関するものとも殆ど同一である。
【０１３２】
3GPP2の場合においては、ＶＣＣアプリケーションを3GPP2における同等のエンティティによって置き換えることに加えて、ステップ２と３において示された3GPP MAPメッセージもまた、3GPP2における同等のメッセージによって置き換えられるであろうことを除いて、図１２はさらに、ＩＭＳからＣＳへのドメイン移動に関する手順Ｂを説明するためにも適用可能である。この場合において、ステップ２と３における3GPP2メッセージはそれぞれ3GPP2 MAP発呼要求、およびMAP発呼要求のＡＣＫであり、ステップ２と３におけるＭＳＩＳＤＮは移動機識別番号(Mobile Identification Number)(MIN)、または移動機ディレクトリー番号(Mobile Directory Number)(MDN)によって置き換えられ、図１２における該ＧＭＬＣは3GPP2位動機位置センター(Mobile Position Center)(MPC)によって置き換えられる。
【０１３３】
ＶＩ．Ｂ ＣＳからＩＭＳへのドメイン移動
ＣＳドメインからＩＭＳドメインへの緊急呼に関するドメイン移動をサポートするために、ここにおいて、２つの代替的な手順が説明される。
【０１３４】
ＶＩ．Ｂ．１ ＣＳからＩＭＳへのドメイン移動 − 手順Ｃ
このセクションにおいて説明される手順Ｃにおいては、ＶＣＣ機能を有するＵＥは通常のＶＣＣ（3GPP TS23.206において説明されている）に関するものとして振る舞い、上記セクションIII.Bにおいて説明された選択肢(e)、(f)、(g)、または(h)の何れかを使用して訪問されたネットワークまたはホームネットワークから取得されたＶＤＩを使用して該ＶＣＣアプリケーションに対してＩＭＳドメインにおける新たな呼のレグを発呼する。該呼は通常の発生するＳＩＰ呼であるかのように扱われ、従って、新たな訪問されたネットワークにおいて登録するのに充分な信任状を有するＵＥに対してのみ適用可能である。それは図１３に図解されている。
【０１３５】
ステップ１（INVITE(VDI)）：ＵＥがＩＭＳへのドメイン移動の必要性を判断した時点においてユーザーがＩＭＳにより登録されていない場合は、ＵＥ１３１０は3GPP TS 23.206において指定されているとおり、ＩＭＳによる登録を開始する。ＩＭＳを経由してアクセス・レグを確立するために訪問されたネットワークから以前に取得されたＶＤＩ（例えば、上記セクションＩＶ、および図７と８において説明されたようなもの）を使用して、それは引き続いて、元の訪問されたネットワーク内のＶＣＣアプリケーション１３５０に向かってＩＭＳが発呼したセッションを開始し、ＩＭＳに対してアクティブなＣＳセッションのドメイン移動を要求する。新たな訪問されたネットワーク、またはホームネットワークの何れか一方の中のＰ−ＣＳＣＦ（図示なし）、およびホームネットワークの中のＳ−ＣＳＣＦ（図示なし）を経由して該SIP INVITEはルーティングされても良く、最終的にはＳ−ＣＳＣＦ（図示なし）または好ましくは元の訪問されたネットワーク内のＥ−ＣＳＣＦ１３４０の何れか一方に到達する。
【０１３６】
ステップ２（INVITE(VDI)）：該ＩＭＳセッションはＳ−ＣＳＣＦ（図示なし）または元の訪問されたネットワーク内のＥ−ＣＳＣＦ１３４０において処理され、ＶＣＣアプリケーション１３５０に対して配送される。
【０１３７】
ステップ３（更新、または再度のINVITE）：ＶＣＣアプリケーション１３５０は、ＩＭＳを経由した新たな入って来るアクセス・レグの確立を完了する。３ＧＰＰ TS23.206において指定されているアクセス・レグ更新手順を使用して新たに確立されたアクセス・レグのコネクション情報によりリモート・レグを更新することにより、ＶＣＣアプリケーション１３５０は、ドメイン移動を実行する。（例えば、図７、または図８に従って）該呼を発呼するために使用されたＥ−ＣＳＣＦ１３４０に対してUPDATEまたはReINVITEが送信される。ＶＣＣアプリケーション１３５０はさらにＥ−ＣＳＣＦ１３４０に対してドメイン移動を明示的に表示することもできる。
【０１３８】
ステップ４（位置の更新）：Ｅ−ＣＳＣＦ１３４０は、新たなＳＤＰ情報によってアンカーＬＲＦ１３３０を更新する − 例えば、ＵＥ１３１０は今や、ＩＭＳドメインを使用していることを表示し、ＵＥのＩＰアドレスを提供する。
【０１３９】
ステップ５（更新、または再度のINVITE）：（図１０Ａに示されるような）ＰＳＡＰ、または（図１０Ｂに示されるような）ＭＧＣＦに向かって更新は継続する。
【０１４０】
ステップ６（ソース・アクセス・レグの解放）：３ＧＰＰ ＴＳ２３．２０６において指定されているように、ＣＳ上で以前に確立されたアクセス・レグであるソース・アクセス・レグが引き続いて解放される。これは、Ｅ−ＣＳＣＦ１３４０を経由して以前の入って来るＣＳレグを解放することを含む。
【０１４１】
一旦、手順Ｃが完了したならば、ＵＥに関する位置のサポートを継続することが可能になるだろう。何故ならば、該ＬＲＦは今やＵＥのＩＰアドレスを持っているであろうし、従って、OMA SUPL（または、3GPP2 X.S0024のようなＩＰトランスポートを必要とする任意の他の位置解決法）を起動することができるからである。しかしながら、ＧＰＲＳアクセスに関してＵＥの位置づけを可能にする３ＧＰＰ制御プレーン解決法の使用は、3GPP TS23.271の9.1.1節および9.1.6節において説明されているより一般的なPS-MT-LR手順を使用する場合にのみ、可能となるだろし、該手順においては、該ＬＲＦは訪問されたＳＧＳＮアドレスに関するＵＥのホームHLR/HSSを問い合わせする。
【０１４２】
ＶＩ．Ｂ．２． ＣＳからＩＭＳへのドメイン移動 − 手順Ｄ
代替的な実施例において、ＣＳからＩＭＳへのドメイン移動をサポートしている手順Ｄは、ＵＥ１４１０が新しいＰＬＭＮにおいて登録するための充分な信任状を有しているか否かにかかわらず、適用可能であるだろう。該手順は継続的な位置のサポートに関して殆ど制限を加えない。図１４は手順Ｄの例示的な実装を図解する。
【０１４３】
ステップ１（INVITE(emergency)）：INVITEを送信するのに先立って、もしも、ＵＥ１４１０が3GPP TS23.167において定義されているような適切な信任状を含んでいる（即ち、通常の登録は使用されない）ならば、該ＵＥは新たな訪問されたＩＭＳネットワーク内で緊急の登録を実行する。この事は、（新たな訪問されたネットワークを経由して）ＵＥ１４２０に対するコールバックをサポートし、新たな訪問されたＩＭＳにおいてＵＥ１４２０を認証するために必要とされるだろう。その後、ＵＥ１４１０は、新たな訪問されたネットワーク内のＰ−ＣＳＣＦ（図１４には示されていない）に対してＩＭＳ緊急呼を表示するINVITEを送信する。該INVITE内の”SIP TO”
ヘッダーは既存の緊急呼に関するＶＣＣドメイン移動を表示するSIP URIを含んでも良い。SIPシグナリングの如何なる新たな変更も必要とすることなく、そのようなSIP
URIは、緊急呼をサポートする必要のある他のSIP URIに対して容易に追加されることができる。該SIP INVITEはさらに、元の訪問されたネットワークに関するアドレス情報（例えば、元の訪問されたネットワークに関するMCC-MNC (Mobile Country Code、およびMobile Network Code)、および場合によっては、そこから該呼が最初に発呼したセルのＩＤおよび位置領域）を含むRouteヘッダーを含んでも良い。既存の緊急呼に関するＶＣＣドメイン移動の表示に基づいて、Ｐ−ＣＳＣＦはＶＣＣサポートを（例えば、図７において可能とされているように新たな訪問されたネットワーク内でＶＣＣアプリケーションに対してSIP INVITEを転送することによって）起動しない代わりに、該INVITEを局所的なＥ−ＣＳＣＦ１４３０に渡す。
【０１４４】
ステップ２（位置を抽出する）：ＶＣＣドメイン移動の表示に基づいて、ステップ１において受信された元の訪問されたネットワークに関する任意のアドレス情報が、後続するルーティングに必要とされるＶＤＩを決定するのに充分に正確である場合、Ｅ−ＣＳＣＦ１４３０はステップ５に進んでも良い。さもなければ、Ｅ−ＣＳＣＦ１４３０は、ＬＲＦ１４４０（局所的なＬＲＦ１４４０、または好ましくは、ステップ１においてＵＥ１４２０によって提供されたRouteヘッダー情報によって表示された元の訪問されたネットワーク内のＬＲＦ１４５０の何れか一方）から位置とルーティング情報を要求する。Ｅ−ＣＳＣＦ１４３０は、ＬＲＦ１４４０に対してＵＥの識別情報（例えば、ＩＭＳＩ、ＭＳＩＳＤＮ、ＩＭＥＩなど）を提供する。Ｅ−ＣＳＣＦ１４３０はさらに、ＶＣＣドメイン移動も表示する。
【０１４５】
ステップ３（呼記録を抽出する）：図７または図８に従って、緊急呼が最初に発呼された際の該アンカーＬＲＦ内に確立された元の呼記録を探索するために、ＬＲＦ１４４０は他のＬＲＦ１４５０と相互作用しても良い。もしも、ＬＲＦ１４３０が元の訪問されたネットワーク内に有る（即ち、元の訪問されたネットワークをサポートする）場合、該相互作用と該探索は、より制限される（例えば、該ＬＲＦは自分自身がアンカーＬＲＦであるかもしれない）。
【０１４６】
ステップ４（位置を返す（ＶＤＩ））：呼記録が見つかった場合、ＬＲＦ１４３０は、ＶＤＩの形式でＥ−ＣＳＣＦ１４２０に対してルーティング情報を返す。
【０１４７】
ステップ５（INVITE(VDI)）：ステップ２において決定された、またはステップ４においてＬＲＦ１４４０によって提供されたＶＤＩを使用して、元の訪問されたネットワーク内のＶＣＣアプリケーション１４７０に対して直接に、または元の訪問されたネットワーク内のＩＭＳコア（例えば、Ｅ−ＣＳＣＦ１４６０）に対して、Ｅ−ＣＳＣＦ１４３０はINVITEを中継する。
【０１４８】
ステップ６（INVITE(VDI)）：もし必要ならば、元の訪問されたネットワーク内のＩＭＳコア（例えば、Ｅ−ＣＳＣＦ１４６０）は、ＶＣＣアプリケーション１４７０に対してINVITEを中継する。
【０１４９】
ステップ７（更新、または再度のINVITE）：Ｅ−ＣＳＣＦ１４６０を経由して、リモート端に対して、移動して入ってきたドメインにおいて確立されたアクセス・レグのＳＤＰを通信することにより、ＶＣＣアプリケーション１４７０は、出て行くアクセス・レグを更新する。ＶＣＣアプリケーション１４７０はさらに、Ｅ−ＣＳＣＦ１４６０に対してドメイン移動を明示的に表示しても良い。
【０１５０】
ステップ８（位置の更新）：Ｅ−ＣＳＣＦ１４６０は、新たなＳＤＰ情報により、アンカーＬＲＦ１４５０を更新する（例えば、ＵＥ１４２０が今やＩＭＳドメインを使用していることを表示し、ＵＥのＩＰアドレスを提供する）。
【０１５１】
ステップ９（更新、または再度のINVITE）：（図１０Ａに示されるような）ＰＳＡＰ、または（図１０Ｂに示されるような）ＭＧＣＦに向かって更新は継続する。
【０１５２】
ステップ１０（ソース・アクセス・レグの解放）：3GPP TS23.206において指定されたとおりに、ＣＳの上で以前に確立されたアクセス・レグであるソース・アクセス・レグは引き続いて解放される。これは、該Ｅ−ＣＳＣＦを経由して以前の入って来るＣＳレグを解放することを含む。図１４の手順は登録されたＵＥ、および登録されていないＵＥの両者に対して適用可能である。位置のサポートを継続することはまた、手順Ｃに関するものと同一である（例えば、図１４のステップ８においてアンカーＬＲＦ１４５０に対して提供されたＵＥのＩＰアドレスと共にOMA SUPLを使用することによって、またはGPRSによる位置付けに関して3GPP PS-MT-LR手順を使用することによって）。しかしながら、追加される利点として、3GPP TS23.271（9.1.6A節、および9.1.7節）において定義された緊急呼に特有の3GPP PS-NI-LRおよびPS-MT-LR手順を使用することが可能であるかもしれない。もしもＵＥが、GPRSアクセスに関する緊急呼、および／またはGPRS PDPコンテキストの確立を表示するならば、これは可能にされうる。これは、位置を取得するため、またはＳＧＳＮのアドレスをＧＭＬＣに提供するための何れか一方のためにＳＧＳＮがPS-NI-LRを引き起こす切っ掛けとなる。該ＧＭＬＣが該アンカーＬＲＦと関係付けられているならば、サービス中のGPRSサポート・ノード（ＳＧＳＮ）のアドレスを該アンカーＬＲＦに提供することが可能であろうし、それによって、ホームHLR/HSSを問い合わせする必要なく（そしてさらに、場合によってはHLR/HSSを伴わずに、オーサライズされていないＵＥに関する位置付けをも可能にしながら）PS-MT-LRの使用を可能にする。しかしながら、この機能は、新しい訪問されたネットワークと元の訪問されたネットワークの両方を同一の通信事業者が所有する場合に限定されるかもしれない。
【０１５３】
本開示の様々な態様が上記で説明された。本明細書における教示が広範な形態において具現化されることが可能であり、本明細書で開示された任意の特定の構造、機能、または両者が単に代表的なものであることは明らかであろう。本明細書における教示に基づいて、本明細書において開示された一の態様は他の任意の態様とは独立に実装されることが可能であり、２つまたはそれ以上のこれらの態様は様々な方法で組み合わされ得ることを当業者は理解するだろう。例えば、本明細書において上記された任意の数の態様を使用して装置は実装され、方法は実施されることが可能である。加えて、他の構造、機能、または本明細書で上記された一つ以上の態様に追加する、またはそれ以外の構造、および機能を使用して、そのような装置は実装され、そのような方法は実施されることが可能である。上記の複数の概念の中の幾つかの例として、幾つかの態様においては、パルス反復周波数に基づいて並列チャネルが確立されても良い。幾つかの態様においては、並列チャネルはパルス位置、またはオフセットに基づいて確立されても良い。幾つかの態様においては、並列チャネルは時間ホッピング系列に基づいて確立されても良い。幾つかの態様において、並列チャネルはパルス反復周波数、パルス位置、またはオフセット、および時間ホッピング系列に基づいて確立されても良い。
【０１５４】
情報、および信号が複数の異なる技術、および技法の何れのバラエティーを使用して表すこともできることを当業者は理解するだろう。例えば、上記の説明の全体を通じて参照される可能性のあるデータ、命令、コマンド、情報、信号、ビット、シンボル、およびチップは、電圧、電流、電磁波、磁場または粒子、光場または粒子、またはこれらの任意の組み合わせによって表されることが可能である。
【０１５５】
本明細書において開示された実施例に関連して説明された様々な例示的な論理ブロック、モジュール、回路、およびアルゴリズムのステップは電子的ハードウェア、コンピューター・ソフトウェア、または両者の組み合わせとして実装されうることが当業者にはさらに理解されるであろう。ハードウェアとソフトウェアのこの交換可能性を明確に例示するために、様々な例示的なコンポーネント、ブロック、モジュール、回路、およびステップはそれらの機能の観点から上記で一般的に説明された。そのような機能がハードウェアとして、またはソフトウェアとして実装されるかは、特定のアプリケーション、および全体のシステムに課される設計上の制約に依存する。特定のアプリケーションの各々に関して当業者は説明された機能を異なる方法で実装しても良いが、そのような実装上の判断は本願発明の技術的範囲からの逸脱をもたらすものと解釈されるべきではない。
【０１５６】
本明細書において開示された実施例に関連して説明された様々な例示的な論理的ブロック、モジュール、回路は汎用プロセッサー、デジタル信号プロセッサ(Digital Signal Processor)（ＤＳＰ）、特定用途向け集積回路(Application Specific Integrated Circuit)（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ(Field Programmable Gate Array)（ＦＰＧＡ）、または他のプログラム可能な論理的デバイス、離散的なゲート、またはトランジスターロジック、離散的なハードウェアコンポーネント、または本明細書において説明された機能を実行するために設計されたこれらの任意の組み合わせによって実装され、実行されることが可能である。汎用プロセッサーはマイクロプロセッサーであることが可能であるが、代替例においては、該プロセッサーは任意の従来型のプロセッサー、コントローラー、マイクロコントローラー、または状態機械であることが可能である。プロセッサーはさらに、（例えば、ＤＳＰとマイクロプロセッサーの組み合わせ、複数のマイクロプロセッサー、ＤＳＰコアと繋がった一つ以上のマイクロプロセッサー、または他の任意のそのような構成などの）複数の計算デバイスの組み合わせとして実装されても良い。
【０１５７】
任意の開示された方法における複数のステップの任意の特定の順序、または階層構造は例示的なアプローチの一例であることが理解される。設計上の好みに基づいて、該方法における複数のステップの特定の順序、または階層構造は、本願の開示の技術的範囲の中から外れることなく、並べ替えられることが可能である。随伴する方法の請求項は例示的な順序での様々なステップの要素を提供し、提供された特定の順序、または階層構造に限定されることを意味するものではない。
【０１５８】
本明細書において開示された実施例に関連して説明された方法、またはアルゴリズムの複数のステップは、ハードウェア中に直接的に、またはプロセッサーによって実行されるソフトウェア・モジュール中に、またはこれら２つの組み合わせの中に具現化されることが可能である。ソフトウェア・モジュールはランダム・アクセス・メモリー（ＲＡＭ）、フラッシュメモリー、リード・オンリー・メモリー（ＲＯＭ）、電子的プログラム可能ＲＯＭ（ＥＰＲＯＭ）、電子的消去・プログラム可能ＲＯＭ（ＥＥＰＲＯＭ）、レジスター、ハードディスク、可搬ディスク、ＣＤ−ＲＯＭ，または当該技術分野において知られている他の形態の記憶媒体の中に存在することができる。例示的な記憶媒体はプロセッサーに結合され、そのようなプロセッサーは該記憶媒体から情報を読み出し、該記憶媒体へ情報を書き込むことができる。代替例においては、該記憶媒体は該プロセッサーに統合化されていても良い。該プロセッサーと該記憶媒体はＡＳＩＣの中に存在しても良い。該ＡＳＩＣはユーザー端末（即ち、ＵＥ）の中に存在しても良い。代替例においては、該プロセッサーと該記憶媒体はユーザー端末（即ち、ＵＥ）の中に別個のコンポーネントとして存在しても良い。
【０１５９】
開示された実施例の上記の説明は、当業者が本願発明を作成し、または使用することを可能とするために提供される。これらの実施例の様々な変形例が当業者には直ちに明らかであり、本明細書で定義された一般的な原理は本願発明の精神と範囲から逸脱することなく、他の実施例に対しても適用されることが可能である。従って、本願発明は、本明細書において示された実施例に限定されるようには意図されておらず、本明細書において開示された原理と新規な特徴と整合する最も広い範囲が与えられるべきである。
【図面の簡単な説明】
【０１６０】
【図１】多数のユーザーをサポートし、本発明の少なくとも幾つかの態様と実施形態を実装することができる例示的な通信システム１００。
【図２】例示的なＣＤＭＡ通信システムの簡単化された機能ブロック図。
【図３】ＨＤＲ伝送をサポートし、多数のユーザーへの伝送をスケジューリングするように適応された例示的な通信システム。
【図４】例示的なＡＴ
【図５Ａ】（３ＧＰＰ ＴＳ ２３．２０６に開示されているような）３ＧＰＰ実装に関する標準的参照モデル。
【図５Ｂ】通常のＶＣＣに関して（図５Ａに示され、３ＧＰＰ ＴＳ ２３．２０６に開示されているような）標準的モデルとは異なる、本発明に従った修正された参照モデル。
【図６Ａ】図５Ａにおいて示されたモデルとは相補的であるが、３ＧＰＰ ＴＳ ２３．１６７において定義されているサービスの観点から見た参照モデル。
【図６Ｂ】図５Ｂにおいて示されたモデルとは相補的であるが、３ＧＰＰ ＴＳ ２３．１６７において定義されているサービスの観点から見た参照モデル。
【図７】例示的な呼の発生の手順。
【図８】ＣＳ（回線交換）ドメインにおいて発生したＶＣＣ呼をサポートする例示的なソリューション。
【図９Ａ】（３ＧＰＰ ＴＳ ２３．２０６に開示されているような）ユーザー・プレーンの切り替えの例示的なモデル。
【図９Ｂ】（３ＧＰＰ ＴＳ ２３．２０６に開示されているような）ユーザー・プレーンの切り替えの例示的なモデル。
【図１０Ａ】（３ＧＰＰ ＴＳ ２３．２０６に開示され、図９Ａ、図９Ｂに示されるような）標準モデルとは異なる、本発明に従った、ユーザー・プレーンの切り替えの修正されたモデル。
【図１０Ｂ】（３ＧＰＰ ＴＳ ２３．２０６に開示され、図９Ａ、図９Ｂに示されるような）標準モデルとは異なる、本発明に従った、ユーザー・プレーンの切り替えの修正されたモデル。
【図１１】ＩＭＳからＣＳへのドメイン移動の例示的な実装。
【図１２】ＩＭＳからＣＳへのドメイン移動の例示的で代替的な実装。
【図１３】ＣＳからＩＭＳへのドメイン移動の例示的な実装。
【図１４】ＣＳからＩＭＳへのドメイン移動の例示的で代替的な実装。
【技術分野】
【０００１】
本特許出願は、下記の米国仮特許出願の利益を主張する：（１）“ＳＵＰＰＯＲＴ ＯＦＶＣＣ ＦＯＲ ＶＯＩＰ ＥＭＥＲＧＥＮＣＹ ＣＡＬＬＳ”と題され、2006年４月28日にステファン・エッジによって出願された米国仮出願第６０／７９５，７７４号；（２）“ＳＵＰＰＯＲＴ ＯＦ ＶＣＣ ＦＯＲ ＶＯＩＰ ＥＭＥＲＧＥＮＣＹ ＣＡＬＬＳ”と題され、2006年５月１日にステファン・エッジによって出願された米国仮出願第６０／７９６，６６９号；（３）“ＳＹＳＴＥＭ ＡＮＤ ＭＥＴＨＯＤ ＦＯＲ ＳＵＰＰＯＲＴＩＮＧ ＶＯＩＣＥ ＣＡＬＬ ＣＯＮＴＩＮＵＩＴＹ ＦＯＲ ＶＯＩＰ ＥＭＥＲＧＥＮＣＹ ＣＡＬＬＳ”と題され、2006年６月21日にステファン・エッジによって出願された米国仮出願第６０／８１５，７３８号。そしてこれらは本願の譲受人に譲渡され、参照により本明細書に明示的に組み込まれる。
【０００２】
この開示は、一般的には、Ｖｏｉｃｅ−Ｏｖｅｒ−ＩＰ（ＶｏＩＰ）緊急呼に関する音声呼継続性(Voice Call Continuity)（ＶＣＣ）を効果的にサポートするためのシステムと方法に関する。
【背景技術】
【０００３】
音声呼継続性(Voice Call Continuity)（ＶＣＣ）は、第３世代パートナーシッププロジェクト(Third Generation Partnership Project)（３ＧＰＰ）および第３世代パートナーシッププロジェクト２(Third Generation Partnership Project2)（３ＧＰＰ２）によって標準化が行われている特徴である。ＶＣＣの定義は３ＧＰＰによって公衆に利用可能な文書である３ＧＰＰ ＴＳ ２３．２０６（“Ｖｏｉｃｅ Ｃａｌｌ Ｃｏｎｔｉｎｕｉｔｙ ｂｅｔｗｅｅｎ ＣＳ ａｎｄ ＩＭＳ； Ｓｔａｇｅ ２”）において作成された。ＶＣＣの定義はまた、３ＧＰＰ２によってこれもまた公衆に利用可能な文書である３ＧＰＰ２ Ｘ．Ｐ００４２−００１−０（“Ｖｏｉｃｅ Ｃａｌｌ Ｃｏｎｔｉｎｕｉｔｙ ｂｅｔｗｅｅｎ ＩＭＳ ａｎｄ Ｃｉｒｃｕｉｔ Ｓｗｉｔｃｈｅｄ Ｓｙｓｔｅｍｓ−Ｓｔａｇｅ ２”）において作成された。ＶＣＣの両者の定義は非常に似通っており回線モードをサポートする無線アクセスを使用することからＶｏＩＰをサポートする無線アクセスを使用することの間で無線端末が切り替わった際に、該無線端末から他のデバイス（無線のまたは無線でない）への音声呼の継続性をサポートする。特に、ユーザーがアクセスを切り替え、それが呼に関与するユーザーに対する顕著な遅延や障害の原因となり、該呼を再確立することの不能という結果を生じるかもしれない場合、ＶＣＣの使用は、呼（例えば、回線モードの呼）を解放しなくてはならなくなることを回避し、（例えば、ＶｏＩＰを使用して）呼を再確立する。
【０００４】
しばしば回線交換（ＣＳ）ドメインと呼ばれる回線モードをサポートする無線アクセスネットワークの具体例は、Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（ＧＳＭ）、広帯域符号分割多重アクセス（Ｗ−ＣＤＭＡ）を使用したＵｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍ（ＵＭＴＳ）、およびｃｄｍａ２０００ １Ｘを含む。ＶｏＩＰをサポートする無線アクセスネットワークの例は、ＵＭＴＳ Ｗ−ＣＤＭＡ、ｃｄｍａ２０００ １ｘＥＶ−ＤＯ（Ｅｖｏｌｕｔｉｏｎ Ｄａｔａ Ｏｐｔｉｍｉｚｅｄ）、および様々な無線ＬＡＮ（ＷＬＡＮ）およびＷｉＭａｘネットワークである。ユーザーの無線端末は特定の一の呼に関して（任意の一時点で）回線モードとＶｏＩＰのうちの一つだけを使用するように要求されるだろうが、幾つかのケースにおいて、同一のアクセスネットワーク（例えば、ＵＭＴＳ Ｗ−ＣＤＭＡ）は回線モードとＶｏＩＰの両者をサポートすることが可能である。
【０００５】
無線ユーザーが特定の無線アクセスネットワークに関してカバレージを失い、他のアクセスネットワークを使用する必要があるとき、アクセスのタイプ（回線モード、またはＶｏＩＰ）を変更しないままで提供されるサービスの中断なしに一のアクセスネットワークから他への進行中の呼のハンドオーバーが時として可能である。しかしながら、（例えば、新たなアクセスネットワークが以前に使用されていたアクセス・タイプをサポートしていないなどの理由で）アクセスのタイプを変更する必要がある場合、呼を正常に解放し、新たなアクセス・タイプを使用して再び呼を再確立するだろう。ＶＣＣは、その様な中断なしにＶｏＩＰと回線モードの間でハンドオーバーを可能にする機能である。
【０００６】
ＶＣＣは現状では、通常の非緊急呼に関して３ＧＰＰと３ＧＰＰ２の両者によって定義されており、回線モードとＶｏＩＰの何れか一方を使用して発生された緊急呼を明示的にはサポートしない可能性がある。これは、ＶＣＣに関して３ＧＰＰと３ＧＰＰ２の両者において定義されているソリューションが、回線モードとＶｏＩＰの緊急呼をサポートするために定義された、および定義されている最中のソリューションとは互換性が無いからである。この非互換性の主たる原因は、緊急呼をサポートするためのソリューションが、訪問されたネットワークとして知られ、無線ユーザーにサービスを現在提供中であるネットワークからのサポートに依存しているのに対して、ＶＣＣに関するソリューションは、たとえ訪問されたネットワークとは異なっている場合でもユーザーのホーム・ネットワークにおけるＶＣＣのサポートを必要とすることである。
【０００７】
緊急呼に関するＶＣＣのサポートの欠如は、異なる複数のアクセスネットワークにおいて（または、同一のアクセスネットワークにおいて）、（例えば、ユーザーが移動した、または現在のアクセスネットワークが輻輳しているか他の何らかの悪条件にさらされている等の理由で）回線モードの使用とＶｏＩＰの使用との間で無線ユーザーが変更をする必要がある場合、その様な呼が解放され、再発行されなくてはならないであろうことを意味する。この事は特に不利である。なぜなら、もしユーザーが呼を再発行する場合、その呼は以前と同じ公衆安全応答点(Public Safety Answering Point)（ＰＳＡＰ）のオペレーターを通過しないかもしれないからである。加えて、呼が最初に確立された際にコールバック番号が供給されなかった場合（例えば、無線端末が大元のアクセスネットワークにおいて適切にオーサライズされない場合）、ＰＳＡＰのオペレーターは該呼を再発行できないかもしれない。従って、緊急呼をサポートするようにＶＣＣの機能を拡張することには有利な点があるであろう。
【発明の開示】
【発明の概要】
【０００８】
３ＧＰＰ ＴＳ ２３．２０６（“Ｖｏｉｃｅ Ｃａｌｌ Ｃｏｎｔｉｎｕｉｔｙ ｂｅｔｗｅｅｎ ＣＳ ａｎｄ ＩＭＳ； Ｓｔａｇｅ ２”）において説明されているように、ＶＣＣは、ＶＣＣ呼継続性制御機能(VCC Call Continuity Control Function)（ＶＣＣ ＣＣＣＦ）として知られ、３ＧＰＰ ＴＳ ２３．２０６のより新しいバージョンにおいてＶＣＣアプリケーション、または（ある特定の文脈において）ドメイン移動機能（Ｄｏｍａｉｎ Ｔｒａｎｓｆｅｒ Ｆｕｃｔｉｏｎ）とも呼ばれる新しいＩＭＳ（ＩＰマルチメディアサブシステム）エンティティにおいてサポートされる。３ＧＰＰ２ Ｘ．Ｐ００４２−００１−０（“Ｖｏｉｃｅ Ｃａｌｌ Ｃｏｎｔｉｎｕｉｔｙ ｂｅｔｗｅｅｎ ＩＭＳ ａｎｄ Ｃｉｒｃｕｉｔ Ｓｗｉｔｃｈｅｄ Ｓｙｓｔｅｍｓ−Ｓｔａｇｅ ２”）において説明されているように、ＶＣＣはＶＣＣアプリケーション・サーバー（ＶＣＣ ＡＳ）によってサポートされ、それは３ＧＰＰのＶＣＣアプリケーションと類似したエンティティである。３ＧＰＰのＶＣＣアプリケーションと３ＧＰＰ２のＶＣＣ ＡＳの両者は呼び出しを行う無線ユーザーのホーム・ネットワークに配置されるように定義される。この定義は、３ＧＰＰ ＴＳ ２３．１６７において定義されるＶｏＩＰ ＩＭＳ緊急呼に関する現在のソリューション、および３ＧＰＰ２ Ｘ．Ｐ００４９−０００−０（“Ａｌｌ−ＩＰ Ｅｍｅｒｇｅｎｃｙ Ｓｅｒｖｉｃｅｓ”）において定義されている３ＧＰＰ２のソリューションとは互換性が無く、ここで、これらではＩＭＳ ＶｏＩＰ緊急呼のサポートが訪問されたネットワークに制限されている。従って、訪問されたネットワークに関してＶＣＣの新しい手法が定義されるか、またはＩＭＳ緊急呼がホーム・ネットワークを介して経路制御されない限り、ＩＭＳ緊急呼に関してＶＣＣをサポートすることは不可能であろう。
【０００９】
本明細書で開示される手法は従来の代替手段を使用している。なぜなら、ＩＭＳ緊急呼のホーム・ネットワークのサポートはＶｏＩＰ緊急呼に関して現在のソリューションを顕著に変更するが、同時に、責任の問題、訪問された国の規制上の要件、および場合によってはレイテンシーの問題などの多数の新しい問題をもたらすからである。このようなホーム・ネットワークに基づくソリューションはまた、オーサライズされていないユーザーからのＩＭＳ緊急呼（例えば、訪問されたネットワークとホーム・ネットワークの間にローミングの合意が全く無いような場合）をサポートすることとも互換性が無いだろう。ホームネットワーク・ソリューションはまた、ＣＳ緊急呼をサポートすることとも互換性が無いだろう。なぜなら、これらもまた、訪問されたネットワークにおいてサポートされているからである。
【００１０】
本明細書で開示された手法は、緊急呼に関してＶＣＣサポートを可能にし、下記の機能を有する。
【００１１】
・ ＩＭＳ（ＶｏＩＰ）または回線交換（ＣＳ）ドメインの何れか一方において発生した緊急呼に関してＩＭＳ（ＶｏＩＰ）からＣＳドメインへの移動をサポートする
・ ＩＭＳ（ＶｏＩＰ）または回線交換（ＣＳ）ドメインの何れか一方において発生した緊急呼に関してＣＳドメインからＩＭＳ（ＶｏＩＰ）への移動をサポートする
・ オーサライズされた無線ユーザー装置(wireless User Equipment)（ＵＥ）をサポートする
・ オーサライズされていないＵＥをサポートする、ここで、該ＵＥは非緊急呼に関してアクセスネットワークを使うようにオーサライズされない
・ ホーム・ネットワーク内における際、またはローミングの際にＵＥをサポートする
・ 一のアクセスネットワークから他へのＶＣＣの移動に従う位置の継続的なサポートを提供する
位置のサポートとは、一般には、無線ユーザーの地理的な位置（例えば、正確な緯度と経度）を取得するためのＰＳＡＰの機能を指して言い、ここで、該無線ユーザーは呼が最初に生成された際、および／またはその呼の継続期間中の後の時刻において緊急呼を開始する。（例えば）欧州と北米の両者における回線モードの緊急呼に関してはこのような機能は現在では必須であり、ＶｏＩＰの緊急呼に関しては後日に必須となる可能性がある。位置に関する継続的なサポートとは、（例えば、ＶｏＩＰから回線モードへと）アクセス・タイプを変更した後に、ＰＳＡＰが無線ユーザーの位置を取得することが依然として可能であるであろうことを意味する。
【００１２】
添付の図面と共に理解されることにより、本開示の下記の詳細な説明から、本開示の他の態様、有利な点、および新規な特徴は明らかとなるだろう。
【発明の詳細な説明】
【００１３】
Ｉ．無線通信システム
例示的な実施形態は、ブロードキャスト・サービスをサポートしているスペクトラム拡散無線通信システムを採用する。無線通信システムは、音声、データなどのような様々なタイプの通信を提供するために広範に展開されている。これらのシステムは、符号分割多重アクセス(code division multiple access)（ＣＤＭＡ）、時分割多重アクセス(time division multiple access)（ＴＤＭＡ）、直交周波数分割多重アクセス(orthogonal frequency division multiple access)（ＯＦＤＭＡ）、３ＧＰＰ ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）無線アクセス、３ＧＰＰ２ ＵＭＢ（Ｕｌｔｒａ Ｍｏｂｉｌｅ Ｂｒｏａｄｂａｎｄ）、ＷｉＭａｘ、または他の変調技法に基づいて良い。
【００１４】
システムは、下記のような一または複数の標準をサポートするように設計されても良い、例えば、本明細書では３ＧＰＰと呼ばれる「第３世代パートナーシップ・プロジェクト(3rd Generation Partnership Project)」と名付けられたコンソーシアムによって提案され、下記を含むドキュメントの集合によって具体化された標準、ドキュメント番号ＴＳ２３．２０６（“Ｖｏｉｃｅ Ｃａｌｌ Ｃｏｎｔｉｎｕｉｔｙ ＢｅｔｗｅｅｎＣＳ ａｎｄ ＩＭＳ；Ｓｔａｇｅ ２（Ｒｅｌｅａｓｅ ７）”）、ＴＳ２３．１６７（“ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ（ＩＭＳ）Ｅｍｅｒｇｅｎｃｙ Ｓｅｓｓｉｏｎｓ（Ｒｅｌｅａｓｅ ７）”）、ＴＳ２４．００８（“Ｍｏｂｉｌｅ Ｒａｄｉｏ Ｉｎｔｅｒｆａｃｅ Ｌａｙｅｒ ３ Ｓｐｅｃｉｆｉｃａｔｉｏｎ；Ｃｏｒｅ Ｎｅｔｗｏｒｋ Ｐｒｏｔｏｃｏｌｓ；Ｓｔａｇｅ ３（Ｒｅｌｅａｓｅ ６）”）、ＴＳ２３．２７１（“Ｆｕｎｃｔｉｏｎａｌ Ｓｔａｇｅ ２ Ｄｅｓｃｒｉｐｔｉｏｎ ｏｆ Ｌｏｃａｔｉｏｎ Ｓｅｒｖｉｃｅｓ（ＬＣＳ）（Ｒｅｌｅａｓｅ ７）”）、ＴＲ２１．９０５（“Ｖｏｃａｂｕｌａｒｙ ｆｏｒ ３ＧＰＰ Ｓｐｅｃｉｆｉｃａｔｉｏｎｓ”）、およびＴＳ２３．００２（“Ｎｅｔｗｏｒｋ Ａｒｃｈｉｔｅｃｔｕｒｅ（Ｒｅｌｅａｓｅ ７）”）；本明細書では３ＧＰＰ２と呼ばれる「第３世代パートナーシップ・プロジェクト２(3rd Generation Partnership Project 2)」と名付けられたコンソーシアムによって提案された下記を含む標準、ドキュメント番号Ｘ．Ｐ００４２−００１−０（“Ｖｏｉｃｅ Ｃａｌｌ Ｃｏｎｔｉｎｕｉｔｙ Ｂｅｔｗｅｅｎ ＩＭＳ ａｎｄ Ｃｉｒｃｕｉｔ Ｓｗｉｔｃｈ Ｓｙｓｔｅｍｓ”），Ｘ．Ｐ００４９−０００−０（“Ａｌｌ−ＩＰ Ｅｍｅｒｇｅｎｃｙ Ｓｅｒｖｉｃｅｓ”），およびＸ．Ｓ００２４（“ＩＰ−Ｂａｓｅｄ Ｌｏｃａｔｉｏｎ Ｓｅｒｖｉｃｅｓ”）；ＴＩＡ／ＥＩＡ／ＡＴＩＳ Ｊ−ＳＴＤ−０３６（“Ｅｎｈａｎｃｅｄ Ｗｉｒｅｌｅｓｓ ９−１−１ Ｐｈａｓｅ ＩＩ”）；および関連するＩＥＴＦのＲＦＣドキュメントで下記を含むもの、ＩＥＴＦ ＲＦＣ ３２６１（“ＳＩＰ：Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏ
ｌ”）、およびＩＥＴＦ ＲＦＣ ２３２７（“ＳＤＰ：Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ”）。上記において引用された標準とドキュメントはここで参照により本明細書に明示的に組み込まれる。
【００１５】
図１は、多数のユーザーをサポートし、本発明の幾つかの態様と実施形態を実装することができる通信システム１００の例としての役割を果たす。図１において、参照数字１０２Ａ〜１０２Ｇはセルを指し、参照数字１６０Ａ〜１６０ＧはノードＢを指し、参照数字１０６Ａ〜１０６Ｊはアクセス端末またはユーザー装置(User Equipment)（ＵＥ）を指す。多様なアルゴリズムと手法のいずれもがシステム１００において伝送をスケジュールするために使用されても良い。各々が１６０Ａ〜１６０Ｇの対応するノードＢによってそれぞれサービスされる多数のセル１０２Ａ〜１０２Ｇに関してシステム１００は通信を提供する。例示的な実施形態において、複数のノードＢ１６０のうちの幾つかは複数の受信アンテナを有し、他は一つだけの受信アンテナを有する。同様に、複数のノードＢ１６０のうちの幾つかは複数の送信アンテナを有し、他は単一の送信アンテナを有する。送信アンテナと受信アンテナの組み合わせに関しては何の制限も無い。従って、一のノードＢについて、複数の送信アンテナと単一の受信アンテナを有し、または複数の受信アンテナと単一の送信アンテナを有し、または両者共に単一または複数である送信および受信アンテナを有することが可能である。
【００１６】
カバレージ・エリア内の端末（すなわちＵＥ）１０６は、固定されていても（即ち、固定局）、または移動式であっても良い。図１に示されるように、システム全体にわたって様々な端末（すなわちＵＥ）１０６が分散配置されている。端末（すなわちＵＥ）１０６の各々は、任意の与えられた瞬間において、ダウンリンク、およびアップリンクの上で少なくとも一つ、および場合によっては複数のノードＢ１６０と通信し、それは例えば、ソフトハンドオフが採用されているか、または該端末（すなわちＵＥ）が複数のノードＢから複数の伝送を（並列に、または逐次的に）受信するように設計され、作動されているかに依存している。ダウンリンクは、ノードＢから端末（すなわちＵＥ）への伝送を指して言い、アップリンクは、端末（すなわちＵＥ）からノードＢへの伝送を指して言う。例示的な実施形態において、複数の端末（すなわち複数のＵＥ）１０６のうちの幾つかは複数の受信アンテナを有し、他は一つだけの受信アンテナを有する。図１において、ノードＢ １６０Ａは端末（すなわちＵＥ）１０６Ａと１０６Ｊに対してダウンリンク上でデータを伝送し、ノードＢ １６０Ｂは端末（すなわちＵＥ）１０６Ｂと１０６Ｊに対してデータを伝送し、ノードＢ １６０Ｃは端末（すなわちＵＥ）１０６Ｃに対してデータを伝送し、以下同様である。
【００１７】
無線データ伝送に関する増加する需要と無線通信技術を介して利用可能なサービスの拡大は特定のデータ・サービスの開発を先導してきた。その様なサービスの一つはＨｉｇｈ Ｒａｔｅ Ｐａｃｋｅｔ Ｄａｔａ（ＨＲＰＤ）と呼ばれる。例示的なＨＲＰＤサービスは「ＨＲＰＤ仕様書」と呼ばれる“ＥＩＡ／ＴＩＡ−ＩＳ８５６ ｃｄｍａ２０００ Ｈｉｇｈ Ｒａｔｅ Ｐａｃｋｅｔ Ｄａｔａ Ａｉｒ Ｉｎｔｅｒｆａｃｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ”において提案されている。ＨＲＰＤサービスは一般的に音声通信システムに対するオーバーレイであり、無線通信システムにおけるデータのパケットの伝送の効率的な方法を提供する。伝送されるデータの量と伝送の回数が増加するにつれて、無線伝送に関して利用可能な限られた帯域幅は重要なリソースとなる。従って、利用可能な帯域幅の使用を最適化する通信システム内での伝送の効率的で公平な方法に関する需要が存在する。例示的な実施形態においては、図１に図解されているシステム１００はＨＲＰＤサービスを有する無線アクセス型のシステムと整合性が取れている。
【００１８】
図２は、例示的な３ＧＰＰ Ｗ−ＣＤＭＡ通信システムの簡単化された機能ブロック図である。上述したように、（３ＧＰＰの文脈において定義されているような）無線ネットワーク・コントローラー(Radio Network Controller)（ＲＮＣ）１３０は、ネットワーク１０４と、地理的領域全体にわたって分散配置されている（３ＧＰＰの文脈において定義されているような）様々なノードＢ１６０との間のインターフェイスを提供するために使用されることが可能である。説明の簡単化のために、一つだけのノードＢ１６０が示される。一般的に、該地理的領域は（図１に示される）セル１０２として知られるより小さい領域に分割される。各ノードＢ１６０は、その各々のセル内の全てのユーザー装置（ＵＥ）１０６をサービスするように構成される。幾つかの高いトラフィックのアプリケーションではセル１０２は、複数のセクターに分割されても良く、ここで、ノードＢ１６０は各セクターをサービスする。説明される例示的な実施形態においては、３つのＵＥ １０６Ａ〜ＣがノードＢ１６０と通信中であるとして示されている。ＲＮＣ１３０の制御の下で、各ＵＥ１０６Ａ〜Ｃはネットワーク１０４をアクセスしても良く、一または複数のノードＢ１６０を通じて他のＵＥ１０６と通信しても良い。
【００１９】
最近の通信システムは、複数のユーザーが共通の通信媒体をアクセスすることを可能とするように設計されている。多数の多重アクセス技法が当該技術分野において知られており、それらは例えば、時分割多重アクセス（ＴＤＭＡ）、周波数分割多重アクセス（ＦＤＭＡ）、空間分割多重アクセス、偏光分割多重アクセス、符号分割多重アクセス（ＣＤＭＡ）、および他の類似した多重アクセス技法などである。多重アクセスの概念は、複数のユーザーが共通の通信リンクをアクセスすることを可能にするチャネル割り当て方法である。具体的な多重アクセス技法に依存して、チャネル割り当ては様々な形態を取ることができる。例示の方法により、ＦＤＭＡシステムにおいては一般的に、全体の周波数スペクトルは多数のより小さいサブバンドに分割され、各ユーザーは通信リンクにアクセスするために自分自身のサブバンドを与えられることができる。代替的に、ＦＤＭＡのＯＦＤＭＡ変形における例に関しては、各ユーザーは多数の異なる周波数チャネルをアクセスすることを可能とされ得る。代替的に、ＴＤＭＡシステムにおいては、各ユーザーは周期的に繰り返されるタイムスロットの期間中に全範囲の周波数スペクトルを与えられる。ＣＤＭＡシステムにおいては、各ユーザーは全ての時間にわたって全範囲の周波数スペクトルを与えられるが、符号の使用を通じて自分の伝送を区別する。
【００２０】
ＨＲＰＤの伝送をサポートしており複数のユーザーに対する伝送をスケジューリングするために適応された通信システムの一つの例が図３に図解されている。図３は、本明細書において下記のとおりに詳細に説明され、具体的には、一のノードＢ１６０とＲＮＣ１３０はパケット・ネットワーク・インターフェイス１４６によってインターフェイスされている。ＲＮＣ１３０は、システム１２０内で複数の伝送に関するスケジューリング・アルゴリズムを実装するためのチャネル・スケジューラ１３２を含む。チャネル・スケジューラ１３２は、受信データに関する任意の特定の遠隔局の関連付けられた瞬間レート（最も最近に受信されたＤＲＣ信号によって表される）に基いて、その期間中にデータが該遠隔局に送信されるべきサービス区間の長さを決定する。該サービス区間は時間的に連続していなくても良く、ｎスロット毎に一回ずつ発生しても良い。一の実施形態に従うならば、パケットの第１の部分は、第１の時刻における第１のスロットの期間中に送信され、第２の部分は、後の時刻において４スロット後に送信される。さらに、該パケットの後続するいずれの部分も同様の４スロット分の散布を有する、即ち互いに４スロット分だけ離れている複数のスロットにおいて送信される。一の実施形態に従うならば、受信データの瞬間レートＲｉは特定のデータ待ち行列に関連付けられたサービス区間の長さＬｉを決定する。
【００２１】
加えて、チャネル・スケジューラ１３２は、伝送に関する特定のデータ待ち行列を選択する。その上で、送信されるべき関連付けられた量のデータがデータ待ち行列１７２から取り出され、該データ待ち行列１７２に関連付けられた遠隔局への送信のために、チャネル・エレメント１６８に供給される。以下で議論するように、該チャネル・スケジューラ１３２は該データを供給するために該待ち行列を選択し、そのデータは待ち行列の各々と関連付けられた重みを含む情報を使用して、続くサービス区間において送信される。送信された待ち行列に関連付けられた重みは、その後更新される。
【００２２】
ＲＮＣ１３０は、パケット・ネットワーク・インターフェイス１４６により、公衆交換電話網(Public Switched Telephone Network)（ＰＳＴＮ）１４８、および通信システム内の全てのノードＢ（簡単のために図２Ｂでは一つだけのノードＢが示されている）とインターフェイスされている。ＲＮＣ１３０は、通信システム内の遠隔局、およびパケット・ネットワーク・インターフェイス１４６とＰＳＴＮ１４８に接続された他のユーザーとの間の通信を調整する。ＰＳＴＮ１４８は標準的な電話網（図２Ｂには示されていない）を通じてユーザーとインターフェイスされている。
【００２３】
簡単のために図２Ｂには一つだけしか示されていないけれども、ＲＮＣ１３０は、多数の選択器エレメント１３６を含んでいる。各選択器エレメント１３６は、一または複数のノードＢと一つの遠隔局（図示無し）との間の通信を制御するために割り当てられる。所与の遠隔局に対して選択器エレメント１３６が未だ割り当てられていない場合、呼制御プロセッサー１４１は、該遠隔局に対してページングを実行する必要性を知らされる。呼制御プロセッサー１４１はその後、該遠隔局に対してページングを実行するようにノードＢ１６０に指令する。
【００２４】
データ・ソース１２２は多量のデータを含み、そのデータは所与の遠隔局に対して送信されるべきものである。データ・ソース１２２は該データをパケット・ネットワーク・インターフェイス１４６に対して供給する。パケット・ネットワーク・インターフェイス１４６は、該データを受け取り、該データを選択器エレメント１３６へとルーティングする。その上で、選択器エレメント１３６は、ターゲットとなる遠隔局と通信している各ノードＢ１６０に対して該データを送信する。例示的な実施形態において、各ノードＢ１６０は一のデータ待ち行列１７２を管理し、それは該遠隔局へと送信されるべきデータを格納する。
【００２５】
データは、データ待ち行列１７２からチャネル・エレメント１６８へとデータ・パケットに入れられて送信される。例示的な実施形態においては、順方向リンク上で、「データ・パケット」とは、最大で１０２４ビットの一定量のデータであり、一の所定のタイムスロット（例えば、≒１．６６７ミリ秒）の中で宛先の遠隔局へと送信されるべき一定量のデータを指して言う。各データ・パケットに関して、チャネル・エレメント１６８は制御フィールドを挿入する。例示的な実施形態においては、チャネル・エレメント１６８は巡回冗長検査(Cyclic Redundancy Check)ＣＲＣ、およびデータ・パケットと制御フィールドの符号化を実行し、符号テイルビットの組を挿入する。データ・パケット、制御フィールド、ＣＲＣパリティ・ビット、および符号テイルビットはフォーマットされたパケットを構成する。該例示的な実施形態においては、チャネル・エレメント１６８はその後、フォーマットされたパケットを符号化し、該符号化されたパケット内部のシンボルをインターリーブする（即ち、並べ替える）。該例示的な実施形態においては、該インターリーブされたパケットはウォルシュ符号によってカバーされ、短いＰＮＩおよびＰＮＱ符号によって拡散される。拡散されたデータはＲＦユニット１７０へ供給され、該ユニットは信号を直交変調し、フィルタリングし、増幅する。順方向リンク信号はアンテナを通じて順方向リンクへ無線で送信される。
【００２６】
遠隔局１０６において、順方向リンク信号はアンテナによって受信され、受信器へとルーティングされる。該受信器は、該信号をフィルタリングし、増幅し、直交復調し、そして量子化する。デジタル化された信号は復調器（ＤＥＭＯＤ）に供給され、ここでは、該信号は短いＰＮＩおよびＰＮＱ符号によって逆拡散され、ウォルシュ符号によってデカバーされる。復調されたデータは復号化器へと供給され、それはノードＢ１６０において行われた信号処理機能と逆のこと、具体的には、逆インターリーブ、復号化、およびＣＲＣ検査機能を実行する。復号化されたデータはデータ・シンクへと供給される。
【００２７】
図４は本特許出願に従う（３ＧＰＰの文脈における）ＵＥ、すなわち（３ＧＰＰ２の文脈における）ＡＴ１０６の他の実施形態であり、該特許出願においてはＵＥ、すなわちＡＴは、送信回路２６４（ＰＡ３０８を含む）、受信回路４０８、スロットル制御３０６、復号化処理ユニット２５８、処理ユニット３０２、キャリア制御ユニット４１２、およびメモリー４１６を含む。スロットル制御ユニット３０６は、上記で図解されたようなスロットル規則の少なくとも一つの組を実装する。スロットル規則は、ＲＬ上での送信電力を制御することに関する手段と方法を提供する。
【００２８】
下記の議論においては、本発明は主として３ＧＰＰアーキテクチャー参照モデルの文脈において説明されるだろう。しかしながら、開示された情報によれば、当該技術分野における当業者は３ＧＰＰ２ネットワーク・アーキテクチャー、または他のネットワーク・アーキテクチャーにおいて本発明の態様を容易に使用のために適合させ、実装できるだろう。
【００２９】
ＩＩ．アーキテクチャー参照モデル
図５Ａは、ドメイン移動手順を可能とするための（３ＧＰＰ ＴＳ２３．２０６に開示されているとおりの）３ＧＰＰ実装に関する参照モデルを示す。一般的に、ＶＣＣが可能なＵＥ５１６および５１８を使用している際にアクティブな音声セッションを維持しながら、ドメイン移動手順はＣＳドメイン５００とＩＰベースのドメイン５１０の間の音声継続性を可能とする。初期の、および後続する移動を含むＶＣＣ加入者呼と関連付けられた全てのドメイン移動手順は、ユーザーのホームＩＭＳネットワーク内においてドメイン移動機能(Domain Transfer Function)（ＤＴＦ）によって実行され、制御され、該ＤＴＦは図５ＡにおけるＶＣＣアプリケーションの一部を形成する。
【００３０】
図５Ａに示されるとおり、セッションの確立に際してＤＴＦにおいてＶＣＣ可能なＵＥ５１６と５１８を使用してＶＣＣ加入者音声呼に関する３ｐｃｃ（サード・パーティー呼制御(3rd party call control)）を確立するために、静的アンカーリング技法が採用される。ＶＣＣ加入者のＳ−ＣＳＣＦ５１４における初期フィルター基準（ｉＦＣ）の実行の開始動作または終了動作の一部として該ＤＴＦが起動される。ルーティング３ｐｃｃ機能を採用することによりＶＣＣ ＵＥ５１６および５１８を使用して生成されたＶＣＣ加入者の音声呼のシグナリング経路の中に該ＤＴＦは自分自身を挿入する。発呼元の音声セッションに関しては、該ＤＴＦは該ユーザーからのアクセス区間(Access Leg)を終端し、リモート端に向かってリモート区間を確立する。終端側の音声セッションに関しては、該ＤＴＦは、リモート端からのリモート区間を終端し、該ユーザーに向かってアクセス区間を確立する。それに引き続いて、該ＤＴＦは、一のＶＣＣ加入者音声呼に関連付けられたアクセス区間とリモート区間の間の呼制御シグナリングの交換を調整する。
【００３１】
図５Ａに示されるように、アクセス区間がＣＳドメイン５００とＩＭＳ５１０のそれぞれを介して確立される際に３ｐｃｃは該ＤＴＦにおいて存在し、この事はその使用がドメイン移動手順の事前条件に係わることを説明している。図５Ａは該ＤＴＦにおける３ｐｃｃ、およびドメイン移動手順に関するその使用を図解している。従って、それは、ドメイン移動の可能化と実行に関連するシグナリングとビアラーの構成要素のみを示している。
【００３２】
図５Ｂは、３ＧＰＰに関する例示的な参照モデルを示し、該参照モデルは通常のＶＣＣに関する（図５Ａで示され、３ＧＰＰ ＴＳ２３．２０６において開示された）標準的な３ＧＰＰ参照モデルとは異なる。ＩＭＳ（ＶｏＩＰ）緊急呼に関してＶＣＣをサポートすることについての３ＧＰＰ ＴＳ２３．２０６における参照モデルとの相違点には、下記が含まれ得る。すなわち、ホーム内のＶＣＣアプリケーション（図５Ａ内で構成要素５０４として示されている）よりもむしろ訪問されたネットワーク内のＶＣＣアプリケーション５７２を使用すること、および３ＧＰＰ ＴＳ２３．２０６におけるようなホーム・ネットワーク内のサービス中のＣＳＣＦ(Serving CSCF)（Ｓ−ＣＳＣＦ）（図５Ａ内で構成要素５１４として示されている）よりもむしろ訪問されたネットワーク内の緊急呼セッション制御機能(Emergency Call Session Control Function)（３ＧＰＰ ＴＳ２３．１６７において定義されているＥ−ＣＳＣＦ）を使用することである。該訪問されたネットワークのプロキシーＣＳＣＦ(Proxy CSCF)（Ｐ−ＣＳＣＦ）もまた、該モデルの一部であるが、図５Ｂには示されていない。図５ＢにおけるＶＣＣアプリケーション５７２は、ＶＣＣ呼継続性制御機能(Call Continuity Control Function)（ＣＣＣＦ）、ＶＣＣアプリケーション・サーバー（ＶＣＣ ＡＳ）、またはドメイン移動機能(Domain Transfer Function)（ＤＴＦ）とも呼ばれ得ることに注意されたい。
【００３３】
図６Ａは、図５Ａにおけるモデルとは相補的であるが、３ＧＰＰ ＴＳ２３．１６７において定義されているサービスの観点から見た参照モデルを示す。（位置抽出機能(Location Retrieval Function)（ＬＲＦ）６１０、ユーザー装置（ＵＥ）６２０、プロキシーＣＳＣＦ（Ｐ−ＣＳＣＦ）６３０、緊急ＣＳＣＦ（Ｅ−ＣＳＣＦ）６４０、およびＳ−ＣＳＣＦ６５０を含む）複数の構成要素は３ＧＰＰ ＴＳ２３．１６７において定義されているように機能する。
【００３４】
図６Ｂは、図５Ｂと同一の参照モデルを含むが、ＩＭＳ（ＶｏＩＰ）緊急呼をサポートするために３ＧＰＰ ＴＳ２３．１６７において定義されているモデルの観点から見たものを示す。図６Ｂにおいては、３ＧＰＰ ＴＳ２３．１６７において開示されている（そして、図６Ａに示されている）参照モデルとは異なり、ＶＣＣアプリケーション６６０は、訪問されたネットワーク内のＥ−ＣＳＣＦ６４０へのインターフェイス、および訪問されたネットワーク内のＰ−ＣＳＣＦ６３０への可能なインターフェイスを有する。緊急呼は、３ＧＰＰ ＴＳ２３．２０６において定義されているようにＶＣＣアプリケーション内に固定されるだろう。加えて、ＵＥ６２０がそのサービス提供中のネットワークとサービス提供中のドメインをどのように変更するかに関わらず、更新された位置の推定をＰＳＡＰがＬＲＦ６１０から取得し続けることができるように、位置のサポートは訪問されたネットワーク内のＬＲＦ６１０内に固定されるだろう。このＬＲＦ６１０はここではアンカーＬＲＦと呼ばれることができる。
【００３５】
３ＧＰＰ２に適用可能な参照モデルは、図５ＢにおけるＶＣＣアプリケーション（構成要素５７２）、および図６ＢにおけるＶＣＣアプリケーション（構成要素６６０）をＶＣＣ ＡＳで置き換えることにより得られる。３ＧＰＰに適用可能な下記の説明において、３ＧＰＰの文脈から３ＧＰＰ２の文脈への用語法と対象の特定の変更と共に３ＧＰＰ２の緊急呼に関するＶＣＣサポートの方法を定義するために（そうではないと述べられない限り）同一の説明が使用されることが可能であることが理解されるべきである。特に、参照された３ＧＰＰ ＶＣＣアプリケーション・エンティティは３ＧＰＰ２ ＶＣＣ ＡＳによって置き換えられるだろう。下記で参照される特定の他の３ＧＰＰの対象も置き換えられることが可能だろう。例えば、３ＧＰＰ ＧＭＬＣ（Ｇａｔｅｗａｙ Ｍｏｂｉｌｅ Ｌｏｃａｔｉｏｎ Ｃｅｎｔｅｒ）は３ＧＰＰ２ ＭＰＣ（Ｍｏｂｉｌｅ Ｐｏｓｉｔｉｏｎ Ｃｅｎｔｅｒ）によって置き換えられるだろう。
【００３６】
ＩＩＩ．ＶＣＣサポートの交渉
通常のＶＣＣに関して、ホーム・ネットワーク（例えば、ホームのＳ−ＣＳＣＦ）はＵＥのホーム加入者サーバー(home subscriber server)（ＨＳＳ）から取得された加入情報からＵＥのＶＣＣ可能性を認識することができる。該ＵＥは、ＶＣＣのホーム・ネットワーク・サポート、およびドメイン移動のために用いられるＶＤＮ（Ｅ．１６４ 音声ドメイン移動番号(Voice Domain Transfer Number)）およびＶＤＩ（音声ドメイン移動ＳＩＰ ＵＲＩ(Voice Domain Transfer SIP URI)）（またはＶＤＮおよびＶＶＤＩと等価な他の番号およびアドレス）を既に認識していることが可能であり、音声呼が最初に発呼された際に、いかなる明示的な交渉および情報の転送も無しにＶＣＣを可能化する。
【００３７】
同一の明示的なシグナリングの変更が必要とされるかも知れないが、ＣＳとＶｏＩＰの緊急呼に関して同様の態様でＶＣＣをサポートすることが望ましいだろう。例えば、ＶＣＣサポートの如何なる交渉も無しではＶＣＣをサポートすることは難しいだろう。なぜなら、ＵＥがドメインを変更した際に、ローミング状況の下では、古い、および新しいドメインがＶＣＣをサポートするために協働することができるか否かをＵＥは知るよしも無いからであり、従って、ＵＥは既存の呼が継続され得るか否かを知ることは無いだろうからである。下記の議論においては、ＩＭＳ緊急呼に関するＶＣＣサポートは訪問されたネットワーク内において提供されると仮定されている。
【００３８】
ＩＩＩ．Ａ．ＵＥがＶＣＣ可能であることを伝える方法
訪問されたネットワーク（例えば、Ｐ−ＣＳＣＦ、Ｅ−ＣＳＣＦ、または音声移動サービス交換センター(Voice Mobile-Service Switching Center)（ＶＭＳＣ）など）に対してＵＥがＶＣＣ可能であることを伝えるために、下記の選択肢が可能である。
【００３９】
（ａ）訪問されたネットワークがＵＥのホーム・ネットワークである場合、それはホームＨＳＳ内のＵＥに関する加入情報からＵＥのＶＣＣ可能性を発見することが可能である。
【００４０】
（ｂ）訪問されたネットワークは（ＵＥが実際にそうであるか否かに関わらず）ＵＥがＶＣＣ可能であると仮定しても良い。例えば、訪問されたネットワークがホーム・ネットワークではなく、従って選択し（ａ）を採用することができない場合、それはＵＥがＶＣＣ可能であると仮定することが可能である。
【００４１】
（ｃ）訪問されたネットワーク（例えば、Ｐ−ＣＳＣＦまたはＶＭＳＣ）はホーム・ネットワークによる登録の期間中に（例えば、ホームＳ−ＣＳＣＦの２００ ＯＫ応答からセッション・イニシエーション・プロトコル(Session Initiation Protocol)（ＳＩＰ）のＲＥＧＩＳＴＥＲメッセージ（ＩＥＴＦ ＲＦＣ３２６１で定義されている）までの間に）、またはＶＭＳＣに対してＨＬＲ／ＨＳＳによって提供されたＵＥの加入情報の中にＵＥのＶＣＣ可能性を発見することが可能である。
【００４２】
（ｄ）ＵＥは、訪問されたネットワーク（例えば、Ｐ−ＣＳＣＦまたはＥ−ＣＳＣＦ）に、自身のＶＣＣ可能性について、下記の複数の方法のうちの一つにより知らせることができる。
【００４３】
ｉ．登録の期間中に（例えば、ＳＩＰ ＲＥＧＩＳＴＥＲメッセージにおいて）；または
ｉｉ．ＩＭＳ緊急呼を発呼する際（例えば、ＳＩＰ ＩＮＶＩＴＥメッセージにおいて）；または
ｉｉｉ．ＣＳモードの緊急呼を発呼する際（例えば、３ＧＰＰ ＴＳ２４．００８において定義されているEmergency SETUPメッセージにおいて）。
【００４４】
選択肢（ａ）は、ＰＳ（パケット交換）ドメイン内で発呼された緊急呼に対して適用可能であり、ＵＥがローミング中でない（すなわち自身のホーム・ネットワークによってサービスされている）場合に３ＧＰＰ ＴＳ２３．２０６で説明されているように通常のＶＣＣサポートに関して（非緊急呼に関して）使用されているＶＣＣ可能性の発見のために同一の仕組みを使用しても良い。
【００４５】
選択肢（ｂ）に関しては、訪問されたネットワークはＵＥがＶＣＣ可能であると仮定し、（例えば、セクションＩＶおよび図７において後述されるとおりに）緊急呼が発呼された際にＶＣＣリソースを割り当てる。しかしながら、ＶＣＣリソースは、該ＵＥが実際にＶＣＣ可能であり、緊急呼がＩＭＳ（ＶｏＩＰ）および回線交換ドメインの間で遷移する必要がある場合のみ使用されるだろう。従って、（ＶＣＣリソースは呼のシグナリングを中継するためだけに使用されることから、緊急呼それ自体は必ずしも損なわれないけれども）ＶＣＣ可能でないＵＥに関するＶＣＣリソースの一定の無駄が存在するだろう。ＰＳドメインにおいて発呼された緊急呼に関しては、無駄は小さいかもしれない。なぜなら、一般にその様な呼の数は全てのＶｏＩＰ呼（緊急、および非緊急の両者の）の中の非常に小さい比率であろうからである。加えて、選択肢（ａ）と選択肢（ｂ）が組み合わされ、それにより訪問されたネットワークがホーム・ネットワークでない場合にだけ、該訪問されたネットワークがＵＥのＶＣＣ可能性を仮定するようにする場合、無駄のレベルは更に削減される。しかしながら、ＣＳで発呼された緊急呼に関しては、おそらくはより高いレベルの無駄が存在するだろう。なぜなら、少なくとも初期においては、殆どのＣＳ緊急呼はＶＣＣをサポートすることが不可能であるレガシーＵＥから来るだろうからである。
【００４６】
選択肢（ａ）と選択肢（ｂ）の両者はＵＥに大きな影響を与えることを回避し、このことは、緊急、および非緊急の両方の呼に関して（ＵＥの観点から）共通のＶＣＣソリューションを可能とするために望ましい。
【００４７】
選択肢（ｃ）もまた、ＵＥに大きな影響を与えることを回避する。しかしながら、選択肢（ｃ）はオーサライズされたＵＥだけに限定される可能性がある。
【００４８】
選択肢（ｄ．ｉ）はホーム・ネットワークに対して大きな影響を与えることを回避するが、しかしこれもまたオーサライズされたＵＥのみに限定され、その一方で、選択肢（ｄ．ｉｉ）および（ｄ．ｉｉｉ）はＵＥの観点からＶＣＣの新しい変形を必要とするけれども、全てのＵＥに関して有効である。
【００４９】
ＩＩＩ．Ｂ．訪問されたネットワークがＶＣＣ可能であることを伝える方法
訪問されたネットワークがＶＣＣ可能であることをＵＥに伝え、必要ならばＶＤＮとＶＤＩを転送するために、下記の選択肢が可能である。
【００５０】
（ｅ）その性質上固定的であり、いかなるＵＥにとっても特有のものではないシステム・ブロードキャスト・メッセージ、または他のメッセージ（例えば、特定の訪問されたネットワークに関連付けられたＷＬＡＮの広告）から、ＵＥは訪問されたネットワークのＶＣＣ可能性（そして場合によっては任意のＶＤＮおよびＶＤＩ）を発見する。これらのメッセージは同一のメッセージであることが可能であり、該メッセージは全てのＵＥに対してネットワーク情報（ネットワーク識別子、およびサポートされる機能）を提供する全てのネットワーク基地局、および／またはアクセスポイントから現在送信されているものである。
【００５１】
（ｆ）訪問されたネットワーク内のサーバーからＤＨＣＰを使用して、またはＨｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）またはセキュアＨＴＴＰ（ＨＴＴＰＳ）を使用して、ＵＥはＶＣＣ可能性、および必要ならばＶＤＮとＶＤＩを発見する、ここで、前記サーバーの役割は緊急呼に関係した情報（例えば、局所緊急番号(local Emergency numbers)も含む）を提供することである。
【００５２】
（ｇ）訪問されたネットワークはＵＥに対してそのＶＣＣ可能性を下記の何れかにおいて示す。
【００５３】
ｉ．登録の期間中（例えば、ＳＩＰ ２００ ＯＫメッセージ中において）；または
ｉｉ．ＩＭＳ緊急呼の発呼に対して応答する際（例えば、ＳＩＰ ２００ ＯＫメッセージ中において）；または
ｉｉｉ．ＰＳモード・アタッチ要求に対して応答する際（例えば、３ＧＰＰ ＴＳ２４．００８におけるネットワーク特性サポート・パラメータ(Network Feature support parameter)を使用して）；または
ｉｖ．ＣＳ緊急呼の発呼に対して応答する際（例えば、３ＧＰＰ ＴＳ２４．００８において定義されているＣＯＮＮＥＣＴメッセージ内のファシリティ・パラメータ(Facility parameter)内において）
（ｈ）緊急呼のためにＶＣＣをサポートすることが既知であるネットワークに関して、ＵＥに対し、またはＵＥ内のユニバーサル集積回路カード(Universal Integrated Circuit Card)（ＵＩＣＣ）に対してホーム・ネットワークは情報をダウンロードする。例えば、ホーム・ネットワークはそのような全てのＶＣＣ可能なネットワークに関するモバイル国コード(mobile country code)（ＭＣＣ）、およびモバイル・ネットワーク・コード(mobile network code)（ＭＮＣ）をＵＥに提供することができるだろう。その様なネットワークによって使用されるＶＤＮやＶＤＩのような追加的情報もまた、提供されることが可能だろう。
【００５４】
選択肢（ｅ）は（ＵＭＴＳ、ＧＰＲＳ、およびＧＳＭネットワークのような）無線ネットワークに適しているであろうし、ＷＬＡＮに関しても可能であり得るだろう。それはまた、ＵＥに対する如何なるポイント・ツー・ポイントのシグナリングの影響をも回避する。ＩＭＳが発生した呼に対して適用可能な選択肢（ｆ）は、ＳＩＰの影響を回避し、訪問されたネットワーク内のあるサーバーからＵＥに対して局所緊急番号(local emergency numbers)を提供する必要性と適合し得るだろう。このサーバーのアドレスは、ＤＨＣＰ、または既知のFully Qualified Domain Name（ＦＱＤＮ）の上でのＤＮＳ問い合わせの何れか一方を使用してＵＥによって取得され、ここで該ＦＱＤＮは、訪問されたネットワークの既知のドメイン名（例えば、訪問されたネットワークのＭＣＣ、およびＭＮＣに基づいたもの）、および何らかの固定的なユーザー名（例えば、”emergency-support@＜訪問されたネットワークのドメイン＞”など）を含む。一の変形として、ＶＣＣ機能（および必要ならばＶＤＮとＶＤＩアドレス）は、Ｐ−ＣＳＣＦとＤＮＳサーバー・アドレスを発見するためにＵＥがＤＨＣＰを使用する際に直接的にシグナリングされることが可能であろう。
【００５５】
選択肢（ｇ．ｉ）はオーサライズされたＵＥに関してのみ有効である可能性があり、その一方で、選択肢（ｇ．ｉｉ）、（ｇ．ｉｉｉ）、および（ｇ．ｉｖ）はオーサライズされた、およびオーサライズされていないＵＥに関して有効である。
【００５６】
選択肢（ｈ）は全てのＵＥに関して有効であることが可能であり、各ホーム・ネットワークに専用のシグナリングを使用しても良い。
【００５７】
ＩＩＩ．Ｃ．必要とされるシグナリングの変更
（上記のセクションＩＩＩ．ＡとＩＩＩ．Ｂで説明された）選択肢（ｃ）、（ｄ）および（ｇ）をサポートするために必要とされるＳＩＰシグナリングの変更は少なくとも四つの異なる方法によりサポートされ得るだろう。
【００５８】
（ｉ）既存のＳＩＰヘッダー・フィールド（例えば、Record-Route、Route、Contactなど）は新たなシグナリングを転送するために使用される。
【００５９】
（ｊ）ＳＩＰ ＲＥＧＩＳＴＥＲ、ＳＩＰ ＩＮＶＩＴＥ、およびＳＩＰ ２００ ＯＫにおけるサポートされたＳＩＰヘッダー・フィールドはＶＣＣサポートを表示する新しいオプション・タグを生成するために拡張される。追加のＶＣＣ情報（例えば、ＶＤＮ、およびＶＤＩ）の転送のために、新たなＳＩＰの拡張が、サポートされたＶＣＣオプション・タグと関連付けられて使用されるだろう。
【００６０】
（ｋ）ＳＩＰ ＩＮＶＩＴＥ、およびＳＩＰ ２００ ＯＫのセッション記述プロトコル(Session Description Protocol)（ＩＥＴＦ ２３２７において定義されているＳＤＰ）の部分が、ＩＡＮＡに登録された、または登録されていない新たな属性を定義することにより拡張される。例えば、新たなプロパティ属性がＶＣＣサポートを表示するために使用されることが可能であろうし、一つのまたは２つの異なる値の属性が（例えば、Ｅ−ＣＳＣＦ、またはＶＣＣアプリケーションから）ＵＥに対してＶＤＮ、およびＶＤＩを運ぶために割り当てられることが可能であろう。媒体レベル属性は（セッション・レベルの属性とは反対に）（例えば、マルチメディア緊急呼を確立する際に）ＶＣＣがサポートされる特定の媒体（例えば、オーディオのみ）を選択的に定義するためにより適切であるかもしれない。
【００６１】
（ｌ）選択肢（ｉ）、（ｊ）、および（ｋ）の中の２つ、またはそれ以上の組み合わせが使用されても良いだろう。例えば、（ｊ）におけるような新たにサポートされたオプション・タグを使用しただけのＳＩＰ機能の伝達と、（ｋ）におけるような新たなＳＤＰレベルの値の属性を使用した任意の更なるＶＣＣ情報（例えば、ＶＤＮ、およびＶＤＩなど）の伝達である。
【００６２】
選択肢（ｊ）の一例として、ＶＣＣサポートを表示する新たなオプション・タグを含むサポートされたＳＩＰヘッダー・フィールドを包含することによって、ＳＩＰ ＲＥＧＩＳＴＥＲメッセージの中において、ＵＥは自身のＶＣＣのサポートを表示することができるだろう。訪問されたネットワークがＶＣＣに加えて、新たなＳＩＰの拡張の中において（必要ならば）ＶＤＮとＶＤＩをサポートするならば、訪問されたネットワークのＰ−ＣＳＣＦにより返された２００ ＯＫは、その後、同一のオプション・タグを包含することができるだろう。もう一つの例として、ＳＩＰ ＩＮＶＩＴＥ、および２００ ＯＫにおける呼の確立の期間中に同一のやり取りが生起し得るだろう。ＶＣＣの表示、および／またはＶＣＣに関係した情報が新たなＳＤＰ属性を使用して伝達されることを除いて、同一の例が選択肢（ｋ）と（ｌ）に当てはまる。
【００６３】
無線インターフェイス上でのＵＥと訪問されたネットワークとの間のＳＩＰ、および他のポイント・ツー・ポイント・シグナリングの影響を回避するために、選択肢（ａ）、（ｂ）、（ｃ）、（ｅ）、（ｆ）、および（ｈ）の何らかの組み合わせが使用され得る。しかしながら、ＵＥに関してＳＩＰ、およびＣＳドメインのシグナリングの影響を許すことは、ホーム・ネットワークに対する影響を回避することができ、例えば選択肢（ｄ．ｉｉ）、（ｄ．ｉｉｉ）、（ｇ．ｉｉ）、（ｇ．ｉｉｉ）、および（ｇ．ｉｖ）を使用してオーサライズされていないＵＥに関してＶＣＣをサポートする。
【００６４】
ＩＶ．ＩＭＳ緊急呼の発呼
緊急呼の発呼は３ＧＰＰ ＴＳ２３．１６７において定義されるように発生し得るが、ＶＣＣの使用の交渉をするための幾らかの変更を伴う。特に、任意のドメイン移動に続く音声呼の継続性と同様に、位置のサポートの継続性も保存するために、訪問されたネットワーク内のＥ−ＣＳＣＦ、またはＰ−ＣＳＣＦの何れか一方は、位置を取得、または検証するため、および宛先のＰＳＡＰを選択するためにＬＲＦを起動する前に、（ＩＭＳ緊急呼に関する）ＳＩＰ ＩＮＶＩＴＥを送信する必要があるだろう。その後、ＶＣＣアプリケーションは入って来る呼の区間を固定し、Ｅ−ＣＳＣＦを通じてＰＳＡＰに向かって新たな出て行く呼の区間を発生する。ＶＣＣアプリケーションからＳＩＰ ＩＮＶＩＴＥを受信する時に、Ｅ−ＣＳＣＦは、ＴＳ２３．１６７で定義されているように通常の位置付け操作とルーティングを実行し、ＩＰを介して、または媒体ゲートウェイ制御機能(Media Gateway Control Function)（ＭＧＣＦ）、および公衆交換電話網(Public Switched Telephone Network)（ＰＳＴＮ）を通じて該呼をＰＳＡＰへと転送する。ＶＣＣアプリケーションから出て行く呼の区間の一部として位置付け操作とルーティングを実行することは、アンカー位置抽出機能（ＬＲＦ）との関連付けが該呼の継続期間全体を通じて保存されたままであるようにするために必須のものである。アンカーＬＲＦとの継続的な関連付けは位置のサポートの継続性を可能とするだろう。特に該呼が最終的に解放される際に、先行するドメイン移動の数とは無関係に、Ｅ−ＣＳＣＦは依然として呼のシグナリング経路上にあり、従って、該呼が解放されたことをＬＲＦに知らせることができ、それにより、３ＧＰＰ ＴＳ２３．１６７における要件に従って、ＬＲＦが自身の呼の記録を解放することを可能とするだろう。
【００６５】
図７は、例示的な引き続く呼の発生の手順を図解し、ＶＣＣの使用を交渉することと任意のＶＣＣに関係する情報を転送することに関して既に説明された選択肢のうちの幾つかを可能なオプションとして含む。
【００６６】
ステップ１（緊急呼を開始する）：このステップではユーザーは緊急呼を開始する。
【００６７】
ステップ２（登録）：ユーザー装置（ＵＥ）７１０は、もしもそれが適格証明を含むならば、３ＧＰＰ ＴＳ２３．１６７において説明されているように、訪問されたネットワークＰ−ＣＳＣＦ７２０、およびホーム・ネットワークＳ−ＣＳＣＦ（図示されず）と共に緊急登録手順を実行しても良い。ＵＥ７１０によって送信されたＳＩＰ ＲＥＧＩＳＴＥＲメッセージ、またはホームＳ−ＣＳＣＦによって返されたＳＩＰ ２００ ＯＫメッセージは訪問されたネットワークＰ−ＣＳＣＦ７２０に対してＵＥ７１０がＶＣＣ可能であることを示すことが可能である。訪問されたネットワークＰ−ＣＳＣＦ７２０によってＵＥ７１０に返された「２００ ＯＫ」は、訪問されたネットワークがＶＣＣ可能であり、（必要ならば）ＶＤＮとＶＤＩを提供する可能性があることを示しても良い。
【００６８】
ステップ３（INVITE(emergency,VCC)）：ユーザー装置（ＵＥ）７１０訪問されたネットワークＰ−ＣＳＣＦ７２０に対して緊急の表示と共にＩＮＶＩＴＥを送信する。該ＩＮＶＩＴＥは、ＵＥが有する如何なる位置オブジェクトを含んでいても良い。該位置オブジェクトはアクセス・ネットワーク技術に依存している。ステップ２においてＶＣＣに関するＵＥのサポートが訪問されたネットワークに伝えられていなかった場合には、該ＩＮＶＩＴＥはそれを表示しても良く、ＵＥに関する識別子情報（例えば、ＳＩＰ、および電話のコールバックのアドレスまたは番号など）をも含んでいても良い。
【００６９】
ステップ４ａ、４ｂ、および４ｃ：ＩＮＶＩＴＥ内のＶＣＣサポートの何らかの表示、またはステップ２において取得されたＶＣＣサポートの知識、または（上記のセクションＩＩＩ．Ａで説明された）選択肢（ａ）および／または（ｂ）に従ったＶＣＣサポートの知識または仮定に基づいてＰ−ＣＳＣＦ７２０は、２つの異なる方法により該ＩＮＶＩＴＥを中継する。
【００７０】
ｉ．ステップ４ａ(INVITE(emergency,VCC))：Ｐ−ＣＳＣＦはＥ−ＣＳＣＦに対して、場合によってはＶＣＣサポートの表示と共にＳＩＰ ＩＮＶＩＴＥを中継する；そして、ステップ４ｂ(INVITE(emergency,VCC))において、ステップ４ａにおけるＶＣＣサポートの表示に基づいて、またはネットワーク・ポリシー（例えば、全てのＵＥによるＶＣＣサポートの仮定）に起因して、Ｅ−ＣＳＣＦ７４０は、ＶＣＣアプリケーション７６０に対してＳＩＰ ＩＮＶＩＴＥを中継する。
【００７１】
ｉｉ．ステップ４ｃ(INVITE(emergency,VCC))：代替的に、Ｐ−ＣＳＣＦは、ＳＩＰ ＩＮＶＩＴＥを直接的にＶＣＣアプリケーションに中継する。
【００７２】
ステップ５(INVITE(emergency))：ＶＣＣアプリケーション７６０は、Ｅ−ＣＳＣＦに対してＩＮＶＩＴＥを送信する（またはそこへ返送する）ことにより、入って来る呼の区間を固定し、出て行く区間を発生する。該ＩＮＶＩＴＥは依然として緊急の表示を伝達するが、もはやＶＣＣに関するサポートは表示しない。
【００７３】
ステップ６（位置を抽出する）：Ｅ−ＣＳＣＦ７４０は、３ＧＰＰ ＴＳ２３．１６７において定義されているように、緊急呼のセットアップに関して通常の取り扱いを実行する。ＩＮＶＩＴＥの中で提供された位置オブジェクトが正確なＰＳＡＰを決定するのに不充分である場合、またはＩＭＳコアがルーティング決定機能(Routing Determination Function)（ＲＤＦ）の支援を必要とする場合、またはＩＭＳコアが位置オブジェクトを検証することを要求されている場合、位置抽出機能を実行するためにＬＲＦ７３０に対して位置抽出要求(retrieve location request)が送信される。位置抽出要求は、ＵＥ７１０を識別する情報（例えば、ＭＳＩＳＤＮ、ＩＭＳＩ、および／またはＩＭＥＩなど）、およびＩＰ接続性アクセス・ネットワーク(IP Connectivity Access Network)（ＩＰ−ＣＡＮ）を含んでも良く、ＵＥをアクセスするための手段（例えば、ＵＥのＩＰアドレス）を含んでも良い。位置抽出要求はまた、ステップ３におけるＩＮＶＩＴＥの中で提供される任意の位置オブジェクトをも含んでも良い。位置抽出要求は、ＶＣＣサポートに関する表示、およびＶＣＣアプリケーション７６０に関する識別子情報（例えば、ＶＤＮ、およびＶＤＩなど）をさらに含んでも良い。しかしながら、セクションＶＩ．Ｂ．１、およびＶＩ．Ｂ．２において後述される手順ＣとＤに関してのみ、これは必要とされるかもしれない。
【００７４】
ステップ７（仮の位置を取得する）：ＬＲＦ７３０は仮の位置の推定を取得しても良い。仮の位置の推定を取得するための手段は、ＩＭＳをアクセスするためにＵＥ７１０が使用しているアクセス技術に依存しており、3GPP TS 23.271において定義されているPS-NI-LRまたはPS-MT-LR手順、OMA AD SUPL: "Secure User Plane Location Architecture"において定義されているSecure User Plane Location (SUPL)手順、OMA TS ULP: "User Plane Location Protocol"、または他の手順を使用することを含んでも良い。該仮の位置またはステップ６において受信された任意の位置オブジェクトをＰＳＡＰのアドレスへと変換するために、ＬＲＦ７３０は、ルーティング決定機能(Routing Determination Function)（ＲＤＦ）を起動しても良い。該ＬＲＦはステップ６において受信された情報を記録しても良い。
【００７５】
ステップ８（位置を返す）：（ステップ７で取得された）位置情報および／またはＰＳＡＰアドレスは、Ｅ−ＣＳＣＦ７４０に返される。ＬＲＦ７３０は自分自身とステップ７において記憶された任意の記録を識別する相関情報（例えば、ＥＳＱＫ）をさらに返しても良い。該呼の残りの部分に関しては、ＬＲＦ７３０はアンカーＬＲＦとしての役割を果たす。
【００７６】
ステップ９ａ、９ｂ、および９ｃ：Ｅ−ＣＳＣＦ７４０はステップ８において提供されたＰＳＡＰアドレスを使用し、または、場合によってはステップ８において提供された位置情報に基づいて、緊急センター、またはＰＳＡＰ自身を選択し、該位置情報および任意の相関情報を含む要求を該緊急センター、またはＰＳＡＰ７８０へと送信する。
【００７７】
ステップ９ａ（INVITE(emergency)）：MGCF/MGW (Media Gateway Control Function/Media Gateway) ７７０に対してINVITEが送信される；
および、ステップ９ｂ（ＩＡＭ）：緊急センターまたはＰＳＡＰへ向かってSS7 ISUP IAMが継続される；
または、ステップ９ｃ（INVITE(emergency)）：INVITEが緊急センターまたはＰＳＡＰ７８０に対して直接に送信される。
【００７８】
ステップ１０ａ、１０ｂ、および１０ｃ：図示されていない呼の確立のための中間のシグナリングが生起しても良い（例えば、PSTN機能を有するPSAPからSS7 ISUP ACMを返すこと）。ＰＳＡＰが該呼に応答するとき、下記のステップが生起する。
【００７９】
ステップ１０ａ（ＡＮＭ）：ＰＳＡＰ７８０はMGCF/MGW７７０に対してSS7 ISUP ANMを返す；
および、ステップ１０ｂ（200 OK）：該MGCF/MGWは”200 OK”を該Ｅ−ＣＳＣＦに対して返す；
または、ステップ１０ｃ（200 OK）：ＰＳＡＰ７８０は、Ｅ−ＣＳＣＦ７６０に対して直接に”200 OK”を返す。
【００８０】
ステップ１１（200 OK）：Ｅ−ＣＳＣＦ７４０は（ステップ５において開始した出て行く呼のレグの上の）該ＶＣＣアプリケーション７６０に対して“200 OK”を返す。
【００８１】
ステップ１２（200 OK）：ステップ４ｃが以前に使用されたならば、ＶＣＣアプリケーション７６０は、（ステップ４において使用された入って来る呼のレグの上の）Ｅ−ＣＳＣＦ、または（図７に図示されていない）Ｐ−ＣＳＣＦ７２０の何れか一方に対して”200 OK”を返す。もしも、ＵＥ７１０がＶＣＣに関する訪問されたネットワークのサポート、およびステップ２またはステップ２以前における関連付けられた如何なるＶＣＣ情報（例えば、ＶＤＮ、ＶＤＩなど）も発見しなかった場合、ＶＣＣアプリケーション７６０によって返された”200 OK”はＶＣＣに関するサポートを表示している可能性があり、ＶＤＮおよび／またはＶＤＩを含む可能性がある。
【００８２】
ステップ１３（200 OK）：（該Ｅ−ＣＳＣＦからである場合は、例えば、Ｐ−ＣＳＣＦ７２０を介して）Ｅ−ＣＳＣＦ７４０またはＰ−ＣＳＣＦ７２０はＵＥ７１０に対して”200 OK”を返す。ＶＣＣアプリケーション７６０への影響を減らすために、ステップ１２において、Ｅ−ＣＳＣＦ７４０により、またはＰ−ＣＳＣＦ７２０により、かつＶＣＣアプリケーション７６０によらずに、如何なるＶＣＣ表示およびＶＤＮ／ＶＤＩも”200 OK”の中に置かれることができるだろう。その後、ＵＥ７１０は任意の受信されたＶＤＮおよび／またはＶＤＩを記憶する。ＵＥ７１０と図７の緊急センター７８０の間に緊急呼が確立された後に、3GPP TS 23.167およびTS23.271において既に定義されている手順を使用して該緊急センターはＬＲＦ７３０からより正確な位置を要求しても良い。
【００８３】
Ｖ．ＣＳ緊急呼の発呼
ＣＳ（回線交換）ドメインにおいて発呼されたＶＣＣ呼をサポートするための例示的な解決法が図８に図解されている。この場合、該Ｅ−ＣＳＣＦもまた、出て行く呼のレグの上のＶＣＣアプリケーションから起動され、加えて、下記で説明されるように該ＶＣＣアプリケーションに対して入って来る呼のレグを正しくルーティングするために、該ＶＣＣアプリケーションへの入って来る呼のレグの上で該ＭＳＣによって既存のGMLC MAP問い合わせが使用されることができる。この例において、該入って来る呼のレグをＶＣＣアプリケーションに対してルーティングするために、該ＧＭＬＣはＩＰマルチメディア・ルーティング番号(IP Multimedia Routing Number)（ＩＭＲＮ）を使用する。該ＧＭＬＣ問い合わせとＩＭＲＮの使用は下記に示されるように該ＭＳＣに対して、部分的または完全に透過的であることが可能である。
【００８４】
ステップ１（緊急呼を開始する）：このステップにおいては、ユーザーは緊急呼を開始する。
【００８５】
ステップ２（Emergency Setup）：（3GPP TS24.008において定義されているような）ＶＭＳＣ８３０に対してEmergency Setupメッセージを送信することにより、ＵＥ８１０はＣＳドメインにおいて、緊急音声呼び出しを発呼する。該Setupメッセージは該ＵＥがＶＣＣをサポートすることを表示しても良い。
【００８６】
ステップ３（位置付け・手順）：3GPP TS23.271において定義され、可能とされている通り、ＵＥ８１０に関する仮の位置の推定を取得するためにＶＭＳＣ８３０は該ＲＡＮにおける手順を開始しても良い。
【００８７】
ステップ４（ＭＡＰ加入者位置の報告）：局所的なＶＭＳＣ８３０のポリシーに基づいて、またはＵＥのホームＨＬＲ／ＨＳＳから取得された加入情報に基づいて、またはステップ２において受信された任意のＶＣＣ表示に基づいて、ＶＭＳＣ８３０は、（例えば、サービス中のセルのＩＤ、およびダイアルされた緊急番号に基づいて）該呼が通常はそこに向けて送信されるであろう緊急サービス・プロバイダー（ＰＳＡＰ）に関連付けられたＧＭＬＣに対してＭＡＰ加入者位置の報告を送信する。該ＭＡＰ加入者位置の報告はＩＭＳＩ、ＭＳＩＳＤＮ、ＩＭＥＩ、ＶＭＳＣアドレス、およびサービス中のセルの識別子、またはＵＥに関するＳＡＩを搬送する。それはまた、ステップ３において取得された任意の仮の位置の推定をも含む。通常、ＧＭＬＣ８５０ではなく、ＶＭＳＣ８３０が該ＰＳＡＰを決定する地域（例えば、欧州共同体など）においては該メッセージは意図された宛先ＰＳＡＰのアドレスを搬送しても良い。もしも、ステップ２において、ＭＳがＶＣＣサポートの表示を提供したならば、ＭＡＰ加入者位置の報告はさらにそのような表示をも搬送しても良い。
【００８８】
ステップ５（ＭＡＰ加入者位置の報告のＡＣＫ）：ＵＥ８１０がＶＣＣをサポートする、さもなくばＵＥ８１０がホームネットワークによりサービスされているならば、加入情報からこれを決定し、さもなくば、ステップ４において提供された任意のＶＣＣ表示からGMLC８５０がこれを決定することをGMLC８５０は仮定している。GMLC８５０は、ステップ４において受信された全ての情報を含むＵＥ８１０に関する呼記録を記憶する。GMLC８５０は該呼に対してＩＰマルチメディア・ルーティング番号(IP Multimedia Routing Number)(IMRN)を割り当てる。該IMRNは国際ITU E.164 ISDN/電話番号、国際ISDN/電話番号、または何らかの他の番号、または複数の番号または複数のパラメータの組み合わせ（例えば、１０進数の一の系列または幾つかの系列から構成されている）であっても良い。該IMRNはさらに他の名前で−例えば「ルーティング番号」と呼ばれても良い。少なくとも、該IMRNはステップ６と７においてＶＣＣアプリケーション８７０への呼のルーティングを可能にし、該GMLCを識別する。付加的に、該IMRNはさらに、該GMLCの中に記憶された呼記録を一時的に識別してもよく、および／またはＰＳＡＰを表示しても良い。NA-ESRD、またはNA-ESRKパラメータの中で、または何らかの他のパラメータまたは複数のパラメータの組の中でIMRNを搬送しながら、該GMLCはVMSC８３０に対してＭＡＰ加入者位置の報告のＡＣＫを返す。ルーティングのための仮の位置の推定、またはＰＳＡＰへの後の提供のための正確な位置の推定を取得するために、GMLC８５０は、VMSC８３０によるCS-MT-LR（図４には示されていない）を引き起こしても良い。ステップ３ではなく、このステップにおいて仮の位置の推定が取得されるならば、セクションVIでさらに説明されるように、ＩＭＳからＣＳへのドメイン移動をサポートするために、図８の手順が再利用されることが可能となるだろう。
【００８９】
ステップ６（ＩＡＭ）：VMSC８３０はステップ５において受信されたIMRNに基づいて該呼をルーティングする。もしも、既存のNA-ESRKまたはNA-ESRDパラメータを使用してIMRNが搬送されるならばVMSC８３０における呼のルーティングの手順は3GPP TS23.271における通常の緊急呼の発呼のために使用されるものと同じもので有りうる。IMRNルーティングに基づいて、VMSC８３０は訪問されたネットワーク内のＭＧＣＦ８４０に対して該呼をルーティングする。
【００９０】
ステップ７（INVITE(MRN)）：ＭＧＣＦ８４０は訪問されたＩＭＳ内のＩ−ＣＳＣＦ（図８には図示されていない）に向かってINVITEを送り出し、または場合によってはＭＧＣＦ８４０はＥ−ＣＳＣＦ８６０、Ｓ−ＣＳＣＦ（図８において図示されていない）、またはＶＣＣアプリケーション８７０に対して直接にルーティングする。INVITEはＵＥ８１０の識別子（例えば、コンタクトアドレスとして、MSISDN Tel URIなど）を含む。該Ｉ−ＣＳＣＦまたは該Ｓ−ＣＳＣＦ（図示なし）、またはＥ−ＣＳＣＦ８６０はIMRNに基づいて、ＰＳＩに基づくアプリケーションサーバの終了をＶＣＣアプリケーション８７０に対して引き起こす。
【００９１】
ステップ８（ＩＮＶＩＴＥ）：ＩＮＶＩＴＥをＥ−ＣＳＣＦ８６０へ送信し、またはＥ−ＣＳＣＦに戻すことにより、ＶＣＣアプリケーション８７０は入って来る呼のレグをアンカーリングし出て行くレグを発生させる。該ＩＮＶＩＴＥは、（例えば、ＳＩＰ ＩＮＶＩＴＥ ＴＯヘッダーの中で）緊急呼を識別し、該IMRNの復元を可能にする（例えば、IMRNの中の一意の数字が含まれても良く、既知の固定された数字が除かれても良い）情報を搬送する。位置情報（例えば、pidf-lo）は含まれている必要はない。
【００９２】
ステップ９（位置を抽出する）：例えば、ステップ８におけるIMRN情報の包含に基づいて、Ｅ−ＣＳＣＦ８６０はIMRNによって識別され、または関連付けられたＬＲＦ８５０に対して位置抽出要求を送信しても良い。該位置抽出要求はステップ８において受信されたIMRN情報、および任意のＵＥの識別子（例えば、MSISDN Tel URI）を含む。位置抽出要求は、ＶＣＣサポートの表示およびＶＣＣアプリケーションに関する識別情報−例えば、ＶＤＮおよびＶＤＩをさらに含んでも良い。しかしながら、これはセクションVI.B.1およびVI.B.2で後述する手順ＣおよびＤに関してのみ必要とされるかもしれない。
【００９３】
ステップ１０（位置を返す）：ステップ９において受信されたＵＥの任意の識別子（例えば、MSISDN）、および／またはIMRN情報に基づいて、ＬＲＦ８５０はＧＭＬＣ８５０と相互作用し、ステップ５においてＧＭＬＣ８５０によって記憶された呼記録を抽出する。既に該呼記録の中にある任意の仮の位置の情報、または（一旦これが完了したならば）ステップ５に従って取得された任意の仮の位置、または意図されたＰＳＡＰの宛先の識別子を使用して、ＬＲＦ８５０はＰＳＡＰアドレス、そして場合によっては位置情報をＥ−ＣＳＣＦ８６０に対して返す。該ＬＲＦと該ＧＭＬＣとが別個のものであるならば、該ＬＲＦは、位置の更なるサポートのためにアンカーポイントを提供するだろうし、該ＧＭＬＣから取得された呼記録をコピーしてもよく、ステップ９において該Ｅ−ＣＳＣＦから受信した情報を格納しても良い。該ＬＲＦはＥ−ＣＳＣＦ８６０に対して相関情報（例えば、ＥＳＱＫなど）を返して、自分自身と該呼記録を識別しても良い。該ＬＲＦはさらに、ＵＥに関する正確な位置の推定を取得するために（3GPP TS23.271において定義されているとおりの）ＶＭＳＣ８３０によってCS-MT-LR手順を引き起こすために、該ＧＭＬＣと相互作用しても良い。もしも、ステップ５においてＧＭＬＣ８５０によって提供されたＩＭＲＮがＰＳＡＡＰを表示し、該ＬＲＦと該ＧＭＬＣが密接に関連付けられている（例えば、同一のエンティティの複数の部分であるなど）場合には、ステップ９と１０は実行されないかも知れず、該Ｅ−ＣＳＣＦは該ＰＳＡＰアドレスを取得するために該ＩＭＲＮを使用しても良い。
【００９４】
ステップ１１（ＩＮＶＩＴＥ）：Ｅ−ＣＳＣＦ８６０は、ステップ１０において取得されたＰＳＡＰアドレスを使用し、緊急センターまたはＰＳＡＰに対して任意の位置情報および任意の相関情報（例えば、ＥＳＱＫまたはＩＭＲＮなど）を含む呼要求を送信し続ける。該呼要求はＭＧＣＦ／ＭＧＷを介してＰＳＴＮ（図示なし）の中へと送信されるか、またはＩＰ機能を有する緊急センターまたはＰＳＡＰに向かってＳＩＰ ＩＮＶＩＴＥとして直接に送信されるかの何れかである。
【００９５】
ステップ１２（ＣＳ緊急呼の残りの部分を確立する）：呼の確立手順の残りは、3GPP TS23.206において記載されたVCC CS発呼手順に基づいて、ＵＥ８１０、ＶＭＳＣ８３０、ＭＧＣＦ８４０、ＶＣＣアプリケーション８７０、Ｅ−ＣＳＣＦ８６０、およびＰＳＡＰの間で生起する。
【００９６】
図８のステップ２において、新しいサービスのカテゴリーとして（3GPP TS24.008において定義されている）Emergency Setupメッセージの中の緊急カテゴリー・パラメーターの中には任意のＶＣＣ表示が含まれているかもしれない（何故なら、現状では、最大で３つまでの新しいサービスカテゴリーが定義されることを可能とする３個の予備のビットが存在するからである）。ＣＳモードの残りの予想されるライフタイムの期間中に、新しい緊急カテゴリーが全く予期されない場合、これは機能することが可能であるかもしれない。
【００９７】
図８におけるＵＥ８１０と該ＰＳＡＰの間で緊急呼が確立された後に、3GPP TS23.167およびTS23.271において既に定義されている手順を使用して該ＰＳＡＰはＬＲＦ８５０からのより正確な位置を要求しても良い。特に、ＬＲＦ８５０を識別するために、例えばＥＳＱＫやＩＭＲＮのような、図８のステップ１１においてＥ−ＣＳＣＦ８６０から受信された任意の相関情報を該ＰＳＡＰは使用できる。ステップ９と１０が実行されていない場合には、図８のステップ５においてＧＭＬＣ８５０内で確立されたＵＥに関する記録を抽出するために、ＬＲＦ８５０は図８におけるステップ１０に関して説明されたとおり、ＧＭＬＣ８５０と相互作用する必要があるだろう。
【００９８】
上記の手順は（例えば、セルＩＤまたは仮の位置の推定を使用して）既存のＰＳＡＰルーティング・オプションに関するサポートを保存し、ＭＳＣに対する如何なる新しい影響も必要としない可能性があり、そして3GPP TS23.167およびTS23.271において現在定義されている方法で、該ＰＳＡＰによる正確な位置の抽出をサポートする。それはさらに、ＣＳが発呼した緊急呼がＩＰ機能を有するＰＳＡＰに対して送信されることを可能にする。
【００９９】
3GPP2の場合、該ＶＣＣアプリケーションを3GPP2における同等のエンティティによって置き換えることに加えて、ステップ４と５において示された3GPP MAPメッセージもまた3GPP2における同等のメッセージによって置き換えられることを除いて、ＣＳ緊急呼の発呼を記述するためにもまた図８は適用可能である。この場合、ステップ４と５における3GPP2メッセージはそれぞれ3GPP2 MAP発呼要求、およびMAP発呼要求ＡＣＫであり、ステップ４におけるMSISDNは移動機識別番号(Mobile Identification Number)(MIN)、または移動機ディレクトリ番号(Mobile Directory Number)(MDN)により置き換えられ、図８における該ＧＭＬＣは3GPP2移動機位置センター(Mobile Position Center)(MPC)によって置き換えられるだろう。
【０１００】
ＶＩ．ドメイン移動
ドメイン移動は、3GPP TS23.206において定義されているような通常のＶＣＣに関するものと非常に良く似た方法で生起する。図９Ａと９Ｂはユーザープレーンの切り替えを示している3GPP TS23.206中の図面に基づいている。ＩＭＳ緊急呼に関するＶＣＣのサポートに関しては、図９Ａと９Ｂにおいて示されたＳ−ＣＳＣＦ９１０は（訪問されたネットワーク内にあり、図１０Ａと１０Ｂにおいて示される）Ｅ−ＣＳＣＦ１０５０によって置き換えられ、ＵＥ＃Ｂ９２０および９３０（それぞれ図９Ａと９Ｂに示されている）は（図１０Ａと１０Ｂにおいて示される）ＰＳＡＰ１０６０に対応するだろう。
【０１０１】
ＶＩ．Ａ． ＩＭＳからＣＳへのドメイン移動
ＵＥがＩＭＳのカバー範囲から出てＣＳのカバー範囲の中へと移動したとき、ＩＭＳドメインからＣＳドメインへのＩＭＳ緊急呼に関するドメイン移動をサポートするために２つの代替的な手順がここで説明される。このセクションで説明されている手順Ａにおいては、ＶＣＣ機能を有するＵＥは（3GPP TS23.206において説明されている）通常のＶＣＣに関するものとして振る舞い、上記セクションIII.Bにおいて説明された選択肢(e)、(f)、(g)または(h)のいずれかを使用して訪問されたネットワークまたはホームネットワークから取得されたＶＤＮを使用して該ＶＣＣアプリケーションに対してＣＳドメイン内の新たな呼のレグを発生させる。
【０１０２】
ＶＩ．Ａ．１． ＩＭＳからＣＳへのドメイン移動 − 手順Ａ
一実施例において、ＣＳドメインをサポートする新たな訪問されたネットワークにおいて登録するための充分な信任状を有するＵＥ１１１０に対して、手順Ａは適用可能であり、該ＰＳＡＰに対するさらなるＵＥ位置の更新を提供するためのサポートの継続性について制限を加える。しかしながら該手順は、ＵＥから見て、通常のＶＣＣに関するＩＭＳからＣＳへのドメイン移動と互換性があるという有利な点を有している。図１１は手順Ａの例示的な実装を図解している。
【０１０３】
ステップ１（Setup(VDN)）：ＵＥがＣＳへのドメイン移動の必要性を判断した際にユーザーがＣＳドメインに関係付けられていなかった場合には、該ＵＥは、そのHLR/HSSに対する位置の更新を含むCS Attachを実行する。ＣＳドメインを介してアクセス・レグを確立するために、元の訪問されたネットワーク、またはホームネットワークから以前に取得されたＶＤＮを使用してＣＳドメインにおける音声呼を、それは引き続いて発呼する。この手順においては、該ＵＥはＣＳドメインにおいて認証されることが可能であると仮定されている。
【０１０４】
ステップ２（ＣＳ発呼手順）：発生する呼はＣＳネットワーク内での通常のＣＳ発呼に関するものとして処理される。
【０１０５】
ステップ３（IAM(VDN)）：訪問された移動交換センター（ＶＭＳＣ）１１３０は元の訪問されたネットワーク内のＭＧＣＦ１１４０を介して元の訪問されたＩＭＳネットワークに向かって該呼をルーティングする。
【０１０６】
ステップ４（INVITE(VCCアプリケーション)）：ＭＧＣＦ１１４０は元の訪問されたＩＭＳ内の問い合わせを行っているＣＳＣＦ（Ｉ−ＣＳＣＦ；図１１には示されていない）に向かってＩＮＶＩＴＥを送り出す、または場合によっては、Ｅ−ＣＳＣＦ１１６０、Ｓ−ＣＳＣＦ、またはＶＣＣアプリケーション１１７０に対して直接にルーティングする。該Ｉ−ＣＳＣＦ、または該Ｓ−ＣＳＣＦ（図示なし）、またはＥ−ＣＳＣＦ１１６０は、ＶＤＮに基づいて、ＶＣＣアプリケーション１１７０に対してＰＳＩに基づくアプリケーション・サーバーの終了を引き起こす。
【０１０７】
ステップ５（更新、または再度のINVITE）：Ｅ−ＣＳＣＦ１１６０を介してリモート端に対して、移動して入ってきたドメイン内で確立されたアクセス・レグのＳＤＰを通信することにより、ＶＣＣアプリケーション１１７０は、出て行くアクセス・レグを更新する。アクセス・レグの更新は、ＩＥＴＦ ＲＦＣ３２６１におけるＳＩＰセッション修正手順に従って生起する。ＶＣＣアプリケーション１１７０はまた、Ｅ−ＣＳＣＦ１１６０に対してドメイン移動を明示的に表示しても良い。
【０１０８】
ステップ６（位置の更新）：Ｅ−ＣＳＣＦ１１６０は新たなＳＤＰ情報と共にアンカーＬＲＦ１１５０に対して位置の更新を送信する。少なくとも、Ｅ−ＣＳＣＦ１１６０は、ＬＲＦ１１５０に対してＣＳドメイン移動があったことを表示する（例えば、ＶＤＩではなく、ＶＤＮを使用することから、および／またはＭＧＣＦ１１４０を伴うドメイン移動から、この事はＶＣＣアプリケーション１１７０によって知られることができる）。
【０１０９】
ステップ７（更新、または再度のＩＮＶＩＴＥ）：該ＰＳＡＰが（図１０Ａにおいて図解されるように）ＩＰ機能を有するならば、該ＰＳＡＰに向かって、または該ＰＳＡＰが（図１０Ｂにおいて図解されるように）ＣＳ機能のみを有するならば該ＭＧＣＦに向かって、該更新は継続する。
【０１１０】
ステップ８（ＣＳドメインの呼のレグの完了）：移動して入って来るＣＳドメインの中の新たな呼のレグはＶＣＣアプリケーション１１７０、Ｅ−ＣＳＣＦ１１６０、またはもし有ればＳ−ＣＳＣＦ、もし有ればＩ−ＣＳＣＦ、ＭＧＣＦ１１４０、ＶＭＳＣ１１３０、およびＵＥ１１１０の間で確立される。
【０１１１】
ステップ９（ソース・アクセス・レグの解放）：ＩＭＳの上で以前に確立されたアクセス・レグである以前の入って来るアクセス・レグが解放される。ＵＥ１１１０は、訪問されたネットワークのＰ−ＣＳＣＦとホームネットワークのＳ−ＣＳＣＦにおいて、可能であれば登録を抹消すべきである。
【０１１２】
一実施例において、手順ＡがＵＥをＣＳドメインへと移動させた後の位置のサポートの継続性は下記のとおりに制限される可能性がある。もしも、ＵＥの位置を取得するためにＰＳＡＰがアンカーＬＲＦに対して要求を送信するならば、ＵＥがＩＭＳドメイン内にあった間に使用していた（または使用すると予期していた）のと同一の位置の取得のための手順を使用し続けることは該ＬＲＦにとっては不可能であるかもしれない。例えば、該ＬＲＦとＵＥの間でUDP/IP、TCP/IP、および／またはSIPトランスポートに基づいたOMA SUPLを該ＬＲＦが使用していたならば、ＩＭＳからＣＳドメインへのドメイン移動に続いて起こる、ＵＥによるＰＳドメインに対するアクセスの喪失は、ＳＵＰＬのそれ以降の使用を妨げるかもしれない。加えて、該ＬＲＦは（例えば、3GPP TS23.271の9.1.3節におけるような）ＣＳ緊急呼に関して3GPP TS23.271において定義されている制御プレーンの位置解決法を使用することができないかもしれない。何故なら、それはＶＭＳＣアドレスを知らないかもしれないからである。しかしながら、該ＬＲＦは、3GPP TS23.271の9.1.1節および9.1.2節において説明されているより一般的なCS-MT-LR手順を使用でき、該手順においてはＧＭＬＣ（Gateway Mobile Location Center）として振舞う、またはＧＭＬＣにアクセスする該ＬＲＦは、ＵＥのホームHLR/HSSを問い合わせることによりＶＭＳＣアドレスを取得する。しかしながら、これの不利な点は、ＵＥのHLR/HSSがCS-MT-LR問い合わせ手順をサポートする必要性があるであろうこと、および、（ホームネットワークは緊急呼の重要性に気付いていない可能性があるため）訪問されたネットワークとホームネットワークとの間で課金上の問題が存在する可能性があることである。
【０１１３】
ＶＩ．Ａ．２ ＩＭＳからＣＳへのドメイン移動 − 手順Ｂ
代替的な実施例において、ＩＭＳからＣＳへのドメイン移動を可能にする手順Ｂは、ＵＥが新たな訪問されたネットワークにおいて登録するための充分な信任状を有するか否かにかかわらず、ＵＥに適用可能であり、制限なしに位置のサポートの継続性を可能にする。しかしながら、一実施例においては、この手順は同一の通信事業者に属するネットワークの間でのドメイン移動に制限される可能性がある。さらに、手順Ｂは、ＶＤＮの知識が必要とされないようなＵＥにおけるＶＣＣドメイン移動の新しい変形を必要とする。図１２は、手順Ｂの例示的な実装を図解する。
【０１１４】
ステップ１（Emergency SETUP(VCC)）：ＣＳヘのドメイン移動の必要性をＵＥが判断した時点で、ユーザーがＣＳドメインに関連付けられていない場合、ＵＥ１２１０は、それが信任状を含んでいるならば、CS Attachを実行しても良い。（3GPP TS24.008において定義されているとおり）Emergency SetupメッセージをＶＭＳＣ１２３０に送信することにより、ＣＳドメインにおいて、それは緊急音声呼を引き続いて発呼する。該Emergency SetupメッセージはＶＣＣサポートの表示を含んでも良い。しかしながら、ＶＤＮは一切含まれる必要がない。
【０１１５】
ステップ２（MAP加入者位置(IMSI,IMEI)）：局所的なＶＭＳＣのポリシーに基づいて、またはＵＥのホームHLR/HSSから取得された加入情報に基づいて、またはステップ１において受信された任意のＶＣＣ表示に基づいて、該呼が通常はそこへ向けて送信される緊急サービス・プロバイダー（ＰＳＡＰ）と関連付けられたＧＭＬＣ１２５０に対してＶＭＳＣ１２３０はMAP加入者位置の報告を送信する。該MAP加入者位置の報告は（例えば図８におけるステップ４などの）通常の緊急呼の発呼に関して送信されるであろうものと同一の情報を搬送し、それはＩＭＳＩ、ＭＳＩＳＤＮ、ＩＭＥＩ、ＶＭＳＣアドレス、および、サービス中のセルの識別子またはＳＡＩを含む。一実施例においては、位置の推定は全く含まれていないが、ＶＣＣの使用の表示は含まれていても良い。
【０１１６】
ステップ３（MAP加入者位置のＡＣＫ(VDN)）：局所的なポリシーに基づいて、またはステップ２におけるＶＣＣ表示の受信に起因して、（例えば、図７または図８において説明された手順を使用して）アンカーＬＲＦ１２５０内で最初に確立されたＵＥ１２１０に関する呼記録を探索するために、該ＧＭＬＣは関連付けられたＬＲＦ（該ＧＭＬＣと同一の物理的エンティティ内の論理的なＬＲＦ）、または関連付けられたＬＲＦの集合と相互作用する。正しい呼記録を識別するために、アンカーＬＲＦ１２５０はステップ２で受信されたＩＭＳＩ、ＭＳＩＳＤＮ、および／またはＩＭＥＩを使用しても良い。呼記録が全く見つからず、ステップ１においてＵＥがＶＣＣドメイン移動を表示しなかったならば、ＧＭＬＣ１２５０は、ＣＳ緊急呼の発呼に関するＶＣＣがサポートされている場合に、例えば図８におけるように、これは新しい緊急呼であると仮定し、それを確立するために処理を実行する。呼記録が見つからず、ステップ１においてＵＥがＶＣＣドメイン移動を表示したならば、ＧＭＬＣ１２５０は代わりにＶＭＳＣ（図示なし）に対してMAP加入者位置の報告のリターンエラーを返し、該ＶＭＳＣは呼の試行を解放するだろう。この事は、ＵＥがユーザーの観点から該呼を解放することを可能にし、ＶＣＣドメイン移動が失敗してからユーザーが緊急呼を再試行することを可能にするだろう。さもなくば、呼記録が見つかった場合、ＧＭＬＣ１２５０は、ＶＭＳＣ１２３０に対してMAP加入者位置の報告のＡＣＫを返し、新しいアクセス・レグを確立するのに必要とされるＶＤＮを搬送する。（例えば、図７のステップ６において、または図８のステップ９において）該呼が最初に発呼された時に、該ＶＤＮはＬＲＦ１２５０によって取得されているであろうし、それが該ＬＲＦ内の呼記録の位置を特定した際に、ＧＭＬＣ１２５０に対して提供されるだろう。該ＶＤＮは該MAP加入者位置の報告のＡＣＫ内の既存のNA-ESRKまたは既存のNA-ESRDパラメーターによって搬送されることが可能だろう。ＧＭＬＣ１２５０はまた、ステップ２においてＶＭＳＣ１２３０から受信された情報を記憶する。
【０１１７】
ステップ４(IAM(VDN))：ＶＭＳＣ１２３０は、ステップ３において受信されたＶＤＮに基づいて新たなレグをルーティングする。該ＶＤＮが既存のNA-ESRKまたはNA-ESRDパラメータを使用して搬送されるならば、該呼のルーティングは通常の緊急呼の発呼に関して使用するものと同一であることが可能である。ＶＤＮのルーティングに基づいて、ＶＭＳＣ１２３０は、訪問されたネットワーク内でＭＧＣＦ１２４０を介して最初の訪問されたＩＭＳネットワークに向かって該呼をルーティングする。
【０１１８】
ステップ５（INVITE(VCCアプリケーション)）：ＭＧＣＦ１２４０は訪問されたＩＭＳ（図示なし）内のＩ−ＣＳＣＦに向かってINVITEを送り出し、または場合によってはＭＧＣＦ１２４０は、Ｅ−ＣＳＣＦ１２６０、Ｓ−ＣＳＣＦ（図示なし）、またはＶＣＣアプリケーション１２７０に対して直接にルーティングする。該Ｉ−ＣＳＣＦ、またはＳ−ＣＳＣＦ（図示なし）、またはＥ−ＣＳＣＦ１２６０は該ＶＤＮに基づいて、ＶＣＣアプリケーション１２７０に対し、ＰＳＩに基づくアプリケーションサーバーの終了を引き起こす。
【０１１９】
ステップ６（更新、または再度のINVITE）：移動して入ってきたドメインにおいて確立されたアクセス・レグのＳＤＰをＥ−ＣＳＣＦ１２６０を介してリモート端に対して通信することにより、ＶＣＣアプリケーション１２７０は、出て行くアクセス・レグを更新する。アクセス・レグの更新はＩＥＴＦ３２６１におけるＳＩＰセッション修正手順に従って生起する。ＶＣＣアプリケーション１２７０はまた、Ｅ−ＣＳＣＦ１２６０に対してＣＳドメイン移動を明示的に表示しても良い。
【０１２０】
ステップ７（位置の更新）：Ｅ−ＣＳＣＦ１２６０は、新たなＳＤＰ情報と共に、アンカーＬＲＦ１２５０に対して位置の更新を送信する。少なくとも、Ｅ−ＣＳＣＦ１２６０はＬＲＦ１２５０に対してＣＳドメイン移動があったことを表示する。ＬＲＦ１２５０は、この表示をステップ３において決定されたドメイン移動の表示と相関させ、今やＵＥ１２１０はステップ２において表示されたものへとドメインを変更したことを判定する。ＬＲＦ１２５０は、ステップ２においてＶＭＳＣ１２３０によって選択されたＧＭＬＣに対してこの情報を通信する。
【０１２１】
ステップ８（更新、または再度のINVITE）：（図１０Ａにおいて図解されたような）ＰＳＡＰに向かって、または（図１０Ｂにおいて図解されたような）ＭＧＣＦに向かって更新は継続する。
【０１２２】
ステップ９（ソース・アクセス・レグの解放）：移動して入ってきたＣＳドメインの中の新たな呼のレグはＶＣＣアプリケーション１２７０、Ｅ−ＣＳＣＦ１２６０またはもし存在するならＳ−ＣＳＣＦ、もし存在するならＩ−ＣＳＣＦ、ＭＧＣＦ１２４０、ＶＭＳＣ１２３０、およびＵＥ１２１０の間で確立される。
【０１２３】
ステップ１０（ＣＳ呼の確立の残りの部分）：ＩＭＳ上で以前に確立されたアクセス・レグであるソース・アクセス・レグが解放される。もしも可能なら、訪問されたネットワークＰ−ＣＳＣＦおよびホームネットワークＳ−ＣＳＣＦにおいて、ＵＥ１２１０は登録を抹消すべきである。
【０１２４】
一実施例では、図１２のステップ１において、Emergency Setupメッセージ中の緊急カテゴリー・パラメーター内に、新しいサービス・カテゴリーとして、ＶＣＣ表示が含まれることが可能だろう（何故なら、最大で３つまでの新しいサービス・カテゴリーが定義されることを可能とする３個の予備のビットが現在存在するからである）。この実施例においては、（両方の手順が可能とされている場合は）下記の情報に基づいて手順Ａの代わりに手順ＢがＵＥによって開始されることが可能である。
【０１２５】
（ｍ）元の訪問されたネットワークからＵＥへの手順Ｂがサポートされることの表示。
【０１２６】
（ｎ）新たな訪問されたＣＳドメイン、および元の訪問されたＩＭＳまたはＣＳドメインが同一の通信事業者によって所有され、またはそれらが同一のネットワークの部分であり、または手順Ｂをサポートするための用意ができていることのＵＥによる判定。
【０１２７】
（ｏ）手順Ｂがサポートされているとの（例えば、ホームネットワークの通信事業者によって提供された）既にＵＥ内部にある情報。
【０１２８】
ＵＥに対するＶＣＣ関連の情報を搬送するためのセクションIII.Bにおいて説明された選択肢（選択肢(e)、(f)、または(g)）の何れかを使用して、（ｍ）における表示は、ＵＥに対して明示的または暗黙的に搬送されることが可能である。
【０１２９】
（ｎ）における判定は元の訪問されたドメインと新たな訪問されたＣＳドメインにおいて同一の通信事業者識別子（例えば、同一のＭＣＣ−ＭＮＣなど）を検出することに基づくことが可能であろう。その代わりに決定は新たな訪問されたネットワークから受信されたシステム・ブロードキャスト情報（例えば、該新たな訪問されたネットワークが手順Ｂをサポートすることの情報、および場合によっては、手順Ｂがサポートされる他のネットワークの識別子）に基づいているかもしれない。代替的に、（ｍ）と（ｎ）の両者の決定は、手順Ｂをサポートする用意がある全ての通信事業者を識別し、ＵＥに関するＳＩＭ／ＵＳＩＭ内に記憶された情報（例えば、（ｏ）において可能とされているような）に基づくかもしれない。
【０１３０】
登録されていないＵＥに関するドメイン移動を可能とすることとは別に、手順Ｂはさらに、緊急呼を発呼したＵＥを位置付けるために3GPP TS23.271（例えば、9.1.3節）において定義されている通常の位置付け手順をアンカーＬＲＦが活用することを可能にする。この事は、図１２におけるステップ２および３によって可能とされ、該ステップにおいては、該ＶＭＳＣは、該ＧＭＬＣに関連した情報を取得して記憶し、該ＬＲＦと該ＧＭＬＣは、該ＶＭＳＣに関連した情報を取得して記憶する。これはその後、ＵＥのホームHSS/HLRを問い合わせする必要性なしにCS-MT-LRを許可する。
【０１３１】
一実施例においては、手順Ｂのさらなる態様は次のとおりである。該ＶＭＳＣにおける該呼の発呼の手順は、通常の回線モードの緊急呼（例えば、3GPP TS 23.271、および関連するTIA/EIA/ATIS J-STD-036において定義されているようなもの）に関するものと同一であることが可能であり、および／または、図８において説明されたようなＣＳから発呼された緊急呼に関するＶＣＣサポートに関するものと同一であることが可能である。該ＧＭＬＣの観点から、該手順はさらに、該ＶＭＳＣを伴うMAPシグナリング・トランザクションに関連する通常の回線モードの緊急呼に関するものとも殆ど同一である。
【０１３２】
3GPP2の場合においては、ＶＣＣアプリケーションを3GPP2における同等のエンティティによって置き換えることに加えて、ステップ２と３において示された3GPP MAPメッセージもまた、3GPP2における同等のメッセージによって置き換えられるであろうことを除いて、図１２はさらに、ＩＭＳからＣＳへのドメイン移動に関する手順Ｂを説明するためにも適用可能である。この場合において、ステップ２と３における3GPP2メッセージはそれぞれ3GPP2 MAP発呼要求、およびMAP発呼要求のＡＣＫであり、ステップ２と３におけるＭＳＩＳＤＮは移動機識別番号(Mobile Identification Number)(MIN)、または移動機ディレクトリー番号(Mobile Directory Number)(MDN)によって置き換えられ、図１２における該ＧＭＬＣは3GPP2位動機位置センター(Mobile Position Center)(MPC)によって置き換えられる。
【０１３３】
ＶＩ．Ｂ ＣＳからＩＭＳへのドメイン移動
ＣＳドメインからＩＭＳドメインへの緊急呼に関するドメイン移動をサポートするために、ここにおいて、２つの代替的な手順が説明される。
【０１３４】
ＶＩ．Ｂ．１ ＣＳからＩＭＳへのドメイン移動 − 手順Ｃ
このセクションにおいて説明される手順Ｃにおいては、ＶＣＣ機能を有するＵＥは通常のＶＣＣ（3GPP TS23.206において説明されている）に関するものとして振る舞い、上記セクションIII.Bにおいて説明された選択肢(e)、(f)、(g)、または(h)の何れかを使用して訪問されたネットワークまたはホームネットワークから取得されたＶＤＩを使用して該ＶＣＣアプリケーションに対してＩＭＳドメインにおける新たな呼のレグを発呼する。該呼は通常の発生するＳＩＰ呼であるかのように扱われ、従って、新たな訪問されたネットワークにおいて登録するのに充分な信任状を有するＵＥに対してのみ適用可能である。それは図１３に図解されている。
【０１３５】
ステップ１（INVITE(VDI)）：ＵＥがＩＭＳへのドメイン移動の必要性を判断した時点においてユーザーがＩＭＳにより登録されていない場合は、ＵＥ１３１０は3GPP TS 23.206において指定されているとおり、ＩＭＳによる登録を開始する。ＩＭＳを経由してアクセス・レグを確立するために訪問されたネットワークから以前に取得されたＶＤＩ（例えば、上記セクションＩＶ、および図７と８において説明されたようなもの）を使用して、それは引き続いて、元の訪問されたネットワーク内のＶＣＣアプリケーション１３５０に向かってＩＭＳが発呼したセッションを開始し、ＩＭＳに対してアクティブなＣＳセッションのドメイン移動を要求する。新たな訪問されたネットワーク、またはホームネットワークの何れか一方の中のＰ−ＣＳＣＦ（図示なし）、およびホームネットワークの中のＳ−ＣＳＣＦ（図示なし）を経由して該SIP INVITEはルーティングされても良く、最終的にはＳ−ＣＳＣＦ（図示なし）または好ましくは元の訪問されたネットワーク内のＥ−ＣＳＣＦ１３４０の何れか一方に到達する。
【０１３６】
ステップ２（INVITE(VDI)）：該ＩＭＳセッションはＳ−ＣＳＣＦ（図示なし）または元の訪問されたネットワーク内のＥ−ＣＳＣＦ１３４０において処理され、ＶＣＣアプリケーション１３５０に対して配送される。
【０１３７】
ステップ３（更新、または再度のINVITE）：ＶＣＣアプリケーション１３５０は、ＩＭＳを経由した新たな入って来るアクセス・レグの確立を完了する。３ＧＰＰ TS23.206において指定されているアクセス・レグ更新手順を使用して新たに確立されたアクセス・レグのコネクション情報によりリモート・レグを更新することにより、ＶＣＣアプリケーション１３５０は、ドメイン移動を実行する。（例えば、図７、または図８に従って）該呼を発呼するために使用されたＥ−ＣＳＣＦ１３４０に対してUPDATEまたはReINVITEが送信される。ＶＣＣアプリケーション１３５０はさらにＥ−ＣＳＣＦ１３４０に対してドメイン移動を明示的に表示することもできる。
【０１３８】
ステップ４（位置の更新）：Ｅ−ＣＳＣＦ１３４０は、新たなＳＤＰ情報によってアンカーＬＲＦ１３３０を更新する − 例えば、ＵＥ１３１０は今や、ＩＭＳドメインを使用していることを表示し、ＵＥのＩＰアドレスを提供する。
【０１３９】
ステップ５（更新、または再度のINVITE）：（図１０Ａに示されるような）ＰＳＡＰ、または（図１０Ｂに示されるような）ＭＧＣＦに向かって更新は継続する。
【０１４０】
ステップ６（ソース・アクセス・レグの解放）：３ＧＰＰ ＴＳ２３．２０６において指定されているように、ＣＳ上で以前に確立されたアクセス・レグであるソース・アクセス・レグが引き続いて解放される。これは、Ｅ−ＣＳＣＦ１３４０を経由して以前の入って来るＣＳレグを解放することを含む。
【０１４１】
一旦、手順Ｃが完了したならば、ＵＥに関する位置のサポートを継続することが可能になるだろう。何故ならば、該ＬＲＦは今やＵＥのＩＰアドレスを持っているであろうし、従って、OMA SUPL（または、3GPP2 X.S0024のようなＩＰトランスポートを必要とする任意の他の位置解決法）を起動することができるからである。しかしながら、ＧＰＲＳアクセスに関してＵＥの位置づけを可能にする３ＧＰＰ制御プレーン解決法の使用は、3GPP TS23.271の9.1.1節および9.1.6節において説明されているより一般的なPS-MT-LR手順を使用する場合にのみ、可能となるだろし、該手順においては、該ＬＲＦは訪問されたＳＧＳＮアドレスに関するＵＥのホームHLR/HSSを問い合わせする。
【０１４２】
ＶＩ．Ｂ．２． ＣＳからＩＭＳへのドメイン移動 − 手順Ｄ
代替的な実施例において、ＣＳからＩＭＳへのドメイン移動をサポートしている手順Ｄは、ＵＥ１４１０が新しいＰＬＭＮにおいて登録するための充分な信任状を有しているか否かにかかわらず、適用可能であるだろう。該手順は継続的な位置のサポートに関して殆ど制限を加えない。図１４は手順Ｄの例示的な実装を図解する。
【０１４３】
ステップ１（INVITE(emergency)）：INVITEを送信するのに先立って、もしも、ＵＥ１４１０が3GPP TS23.167において定義されているような適切な信任状を含んでいる（即ち、通常の登録は使用されない）ならば、該ＵＥは新たな訪問されたＩＭＳネットワーク内で緊急の登録を実行する。この事は、（新たな訪問されたネットワークを経由して）ＵＥ１４２０に対するコールバックをサポートし、新たな訪問されたＩＭＳにおいてＵＥ１４２０を認証するために必要とされるだろう。その後、ＵＥ１４１０は、新たな訪問されたネットワーク内のＰ−ＣＳＣＦ（図１４には示されていない）に対してＩＭＳ緊急呼を表示するINVITEを送信する。該INVITE内の”SIP TO”
ヘッダーは既存の緊急呼に関するＶＣＣドメイン移動を表示するSIP URIを含んでも良い。SIPシグナリングの如何なる新たな変更も必要とすることなく、そのようなSIP
URIは、緊急呼をサポートする必要のある他のSIP URIに対して容易に追加されることができる。該SIP INVITEはさらに、元の訪問されたネットワークに関するアドレス情報（例えば、元の訪問されたネットワークに関するMCC-MNC (Mobile Country Code、およびMobile Network Code)、および場合によっては、そこから該呼が最初に発呼したセルのＩＤおよび位置領域）を含むRouteヘッダーを含んでも良い。既存の緊急呼に関するＶＣＣドメイン移動の表示に基づいて、Ｐ−ＣＳＣＦはＶＣＣサポートを（例えば、図７において可能とされているように新たな訪問されたネットワーク内でＶＣＣアプリケーションに対してSIP INVITEを転送することによって）起動しない代わりに、該INVITEを局所的なＥ−ＣＳＣＦ１４３０に渡す。
【０１４４】
ステップ２（位置を抽出する）：ＶＣＣドメイン移動の表示に基づいて、ステップ１において受信された元の訪問されたネットワークに関する任意のアドレス情報が、後続するルーティングに必要とされるＶＤＩを決定するのに充分に正確である場合、Ｅ−ＣＳＣＦ１４３０はステップ５に進んでも良い。さもなければ、Ｅ−ＣＳＣＦ１４３０は、ＬＲＦ１４４０（局所的なＬＲＦ１４４０、または好ましくは、ステップ１においてＵＥ１４２０によって提供されたRouteヘッダー情報によって表示された元の訪問されたネットワーク内のＬＲＦ１４５０の何れか一方）から位置とルーティング情報を要求する。Ｅ−ＣＳＣＦ１４３０は、ＬＲＦ１４４０に対してＵＥの識別情報（例えば、ＩＭＳＩ、ＭＳＩＳＤＮ、ＩＭＥＩなど）を提供する。Ｅ−ＣＳＣＦ１４３０はさらに、ＶＣＣドメイン移動も表示する。
【０１４５】
ステップ３（呼記録を抽出する）：図７または図８に従って、緊急呼が最初に発呼された際の該アンカーＬＲＦ内に確立された元の呼記録を探索するために、ＬＲＦ１４４０は他のＬＲＦ１４５０と相互作用しても良い。もしも、ＬＲＦ１４３０が元の訪問されたネットワーク内に有る（即ち、元の訪問されたネットワークをサポートする）場合、該相互作用と該探索は、より制限される（例えば、該ＬＲＦは自分自身がアンカーＬＲＦであるかもしれない）。
【０１４６】
ステップ４（位置を返す（ＶＤＩ））：呼記録が見つかった場合、ＬＲＦ１４３０は、ＶＤＩの形式でＥ−ＣＳＣＦ１４２０に対してルーティング情報を返す。
【０１４７】
ステップ５（INVITE(VDI)）：ステップ２において決定された、またはステップ４においてＬＲＦ１４４０によって提供されたＶＤＩを使用して、元の訪問されたネットワーク内のＶＣＣアプリケーション１４７０に対して直接に、または元の訪問されたネットワーク内のＩＭＳコア（例えば、Ｅ−ＣＳＣＦ１４６０）に対して、Ｅ−ＣＳＣＦ１４３０はINVITEを中継する。
【０１４８】
ステップ６（INVITE(VDI)）：もし必要ならば、元の訪問されたネットワーク内のＩＭＳコア（例えば、Ｅ−ＣＳＣＦ１４６０）は、ＶＣＣアプリケーション１４７０に対してINVITEを中継する。
【０１４９】
ステップ７（更新、または再度のINVITE）：Ｅ−ＣＳＣＦ１４６０を経由して、リモート端に対して、移動して入ってきたドメインにおいて確立されたアクセス・レグのＳＤＰを通信することにより、ＶＣＣアプリケーション１４７０は、出て行くアクセス・レグを更新する。ＶＣＣアプリケーション１４７０はさらに、Ｅ−ＣＳＣＦ１４６０に対してドメイン移動を明示的に表示しても良い。
【０１５０】
ステップ８（位置の更新）：Ｅ−ＣＳＣＦ１４６０は、新たなＳＤＰ情報により、アンカーＬＲＦ１４５０を更新する（例えば、ＵＥ１４２０が今やＩＭＳドメインを使用していることを表示し、ＵＥのＩＰアドレスを提供する）。
【０１５１】
ステップ９（更新、または再度のINVITE）：（図１０Ａに示されるような）ＰＳＡＰ、または（図１０Ｂに示されるような）ＭＧＣＦに向かって更新は継続する。
【０１５２】
ステップ１０（ソース・アクセス・レグの解放）：3GPP TS23.206において指定されたとおりに、ＣＳの上で以前に確立されたアクセス・レグであるソース・アクセス・レグは引き続いて解放される。これは、該Ｅ−ＣＳＣＦを経由して以前の入って来るＣＳレグを解放することを含む。図１４の手順は登録されたＵＥ、および登録されていないＵＥの両者に対して適用可能である。位置のサポートを継続することはまた、手順Ｃに関するものと同一である（例えば、図１４のステップ８においてアンカーＬＲＦ１４５０に対して提供されたＵＥのＩＰアドレスと共にOMA SUPLを使用することによって、またはGPRSによる位置付けに関して3GPP PS-MT-LR手順を使用することによって）。しかしながら、追加される利点として、3GPP TS23.271（9.1.6A節、および9.1.7節）において定義された緊急呼に特有の3GPP PS-NI-LRおよびPS-MT-LR手順を使用することが可能であるかもしれない。もしもＵＥが、GPRSアクセスに関する緊急呼、および／またはGPRS PDPコンテキストの確立を表示するならば、これは可能にされうる。これは、位置を取得するため、またはＳＧＳＮのアドレスをＧＭＬＣに提供するための何れか一方のためにＳＧＳＮがPS-NI-LRを引き起こす切っ掛けとなる。該ＧＭＬＣが該アンカーＬＲＦと関係付けられているならば、サービス中のGPRSサポート・ノード（ＳＧＳＮ）のアドレスを該アンカーＬＲＦに提供することが可能であろうし、それによって、ホームHLR/HSSを問い合わせする必要なく（そしてさらに、場合によってはHLR/HSSを伴わずに、オーサライズされていないＵＥに関する位置付けをも可能にしながら）PS-MT-LRの使用を可能にする。しかしながら、この機能は、新しい訪問されたネットワークと元の訪問されたネットワークの両方を同一の通信事業者が所有する場合に限定されるかもしれない。
【０１５３】
本開示の様々な態様が上記で説明された。本明細書における教示が広範な形態において具現化されることが可能であり、本明細書で開示された任意の特定の構造、機能、または両者が単に代表的なものであることは明らかであろう。本明細書における教示に基づいて、本明細書において開示された一の態様は他の任意の態様とは独立に実装されることが可能であり、２つまたはそれ以上のこれらの態様は様々な方法で組み合わされ得ることを当業者は理解するだろう。例えば、本明細書において上記された任意の数の態様を使用して装置は実装され、方法は実施されることが可能である。加えて、他の構造、機能、または本明細書で上記された一つ以上の態様に追加する、またはそれ以外の構造、および機能を使用して、そのような装置は実装され、そのような方法は実施されることが可能である。上記の複数の概念の中の幾つかの例として、幾つかの態様においては、パルス反復周波数に基づいて並列チャネルが確立されても良い。幾つかの態様においては、並列チャネルはパルス位置、またはオフセットに基づいて確立されても良い。幾つかの態様においては、並列チャネルは時間ホッピング系列に基づいて確立されても良い。幾つかの態様において、並列チャネルはパルス反復周波数、パルス位置、またはオフセット、および時間ホッピング系列に基づいて確立されても良い。
【０１５４】
情報、および信号が複数の異なる技術、および技法の何れのバラエティーを使用して表すこともできることを当業者は理解するだろう。例えば、上記の説明の全体を通じて参照される可能性のあるデータ、命令、コマンド、情報、信号、ビット、シンボル、およびチップは、電圧、電流、電磁波、磁場または粒子、光場または粒子、またはこれらの任意の組み合わせによって表されることが可能である。
【０１５５】
本明細書において開示された実施例に関連して説明された様々な例示的な論理ブロック、モジュール、回路、およびアルゴリズムのステップは電子的ハードウェア、コンピューター・ソフトウェア、または両者の組み合わせとして実装されうることが当業者にはさらに理解されるであろう。ハードウェアとソフトウェアのこの交換可能性を明確に例示するために、様々な例示的なコンポーネント、ブロック、モジュール、回路、およびステップはそれらの機能の観点から上記で一般的に説明された。そのような機能がハードウェアとして、またはソフトウェアとして実装されるかは、特定のアプリケーション、および全体のシステムに課される設計上の制約に依存する。特定のアプリケーションの各々に関して当業者は説明された機能を異なる方法で実装しても良いが、そのような実装上の判断は本願発明の技術的範囲からの逸脱をもたらすものと解釈されるべきではない。
【０１５６】
本明細書において開示された実施例に関連して説明された様々な例示的な論理的ブロック、モジュール、回路は汎用プロセッサー、デジタル信号プロセッサ(Digital Signal Processor)（ＤＳＰ）、特定用途向け集積回路(Application Specific Integrated Circuit)（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ(Field Programmable Gate Array)（ＦＰＧＡ）、または他のプログラム可能な論理的デバイス、離散的なゲート、またはトランジスターロジック、離散的なハードウェアコンポーネント、または本明細書において説明された機能を実行するために設計されたこれらの任意の組み合わせによって実装され、実行されることが可能である。汎用プロセッサーはマイクロプロセッサーであることが可能であるが、代替例においては、該プロセッサーは任意の従来型のプロセッサー、コントローラー、マイクロコントローラー、または状態機械であることが可能である。プロセッサーはさらに、（例えば、ＤＳＰとマイクロプロセッサーの組み合わせ、複数のマイクロプロセッサー、ＤＳＰコアと繋がった一つ以上のマイクロプロセッサー、または他の任意のそのような構成などの）複数の計算デバイスの組み合わせとして実装されても良い。
【０１５７】
任意の開示された方法における複数のステップの任意の特定の順序、または階層構造は例示的なアプローチの一例であることが理解される。設計上の好みに基づいて、該方法における複数のステップの特定の順序、または階層構造は、本願の開示の技術的範囲の中から外れることなく、並べ替えられることが可能である。随伴する方法の請求項は例示的な順序での様々なステップの要素を提供し、提供された特定の順序、または階層構造に限定されることを意味するものではない。
【０１５８】
本明細書において開示された実施例に関連して説明された方法、またはアルゴリズムの複数のステップは、ハードウェア中に直接的に、またはプロセッサーによって実行されるソフトウェア・モジュール中に、またはこれら２つの組み合わせの中に具現化されることが可能である。ソフトウェア・モジュールはランダム・アクセス・メモリー（ＲＡＭ）、フラッシュメモリー、リード・オンリー・メモリー（ＲＯＭ）、電子的プログラム可能ＲＯＭ（ＥＰＲＯＭ）、電子的消去・プログラム可能ＲＯＭ（ＥＥＰＲＯＭ）、レジスター、ハードディスク、可搬ディスク、ＣＤ−ＲＯＭ，または当該技術分野において知られている他の形態の記憶媒体の中に存在することができる。例示的な記憶媒体はプロセッサーに結合され、そのようなプロセッサーは該記憶媒体から情報を読み出し、該記憶媒体へ情報を書き込むことができる。代替例においては、該記憶媒体は該プロセッサーに統合化されていても良い。該プロセッサーと該記憶媒体はＡＳＩＣの中に存在しても良い。該ＡＳＩＣはユーザー端末（即ち、ＵＥ）の中に存在しても良い。代替例においては、該プロセッサーと該記憶媒体はユーザー端末（即ち、ＵＥ）の中に別個のコンポーネントとして存在しても良い。
【０１５９】
開示された実施例の上記の説明は、当業者が本願発明を作成し、または使用することを可能とするために提供される。これらの実施例の様々な変形例が当業者には直ちに明らかであり、本明細書で定義された一般的な原理は本願発明の精神と範囲から逸脱することなく、他の実施例に対しても適用されることが可能である。従って、本願発明は、本明細書において示された実施例に限定されるようには意図されておらず、本明細書において開示された原理と新規な特徴と整合する最も広い範囲が与えられるべきである。
【図面の簡単な説明】
【０１６０】
【図１】多数のユーザーをサポートし、本発明の少なくとも幾つかの態様と実施形態を実装することができる例示的な通信システム１００。
【図２】例示的なＣＤＭＡ通信システムの簡単化された機能ブロック図。
【図３】ＨＤＲ伝送をサポートし、多数のユーザーへの伝送をスケジューリングするように適応された例示的な通信システム。
【図４】例示的なＡＴ
【図５Ａ】（３ＧＰＰ ＴＳ ２３．２０６に開示されているような）３ＧＰＰ実装に関する標準的参照モデル。
【図５Ｂ】通常のＶＣＣに関して（図５Ａに示され、３ＧＰＰ ＴＳ ２３．２０６に開示されているような）標準的モデルとは異なる、本発明に従った修正された参照モデル。
【図６Ａ】図５Ａにおいて示されたモデルとは相補的であるが、３ＧＰＰ ＴＳ ２３．１６７において定義されているサービスの観点から見た参照モデル。
【図６Ｂ】図５Ｂにおいて示されたモデルとは相補的であるが、３ＧＰＰ ＴＳ ２３．１６７において定義されているサービスの観点から見た参照モデル。
【図７】例示的な呼の発生の手順。
【図８】ＣＳ（回線交換）ドメインにおいて発生したＶＣＣ呼をサポートする例示的なソリューション。
【図９Ａ】（３ＧＰＰ ＴＳ ２３．２０６に開示されているような）ユーザー・プレーンの切り替えの例示的なモデル。
【図９Ｂ】（３ＧＰＰ ＴＳ ２３．２０６に開示されているような）ユーザー・プレーンの切り替えの例示的なモデル。
【図１０Ａ】（３ＧＰＰ ＴＳ ２３．２０６に開示され、図９Ａ、図９Ｂに示されるような）標準モデルとは異なる、本発明に従った、ユーザー・プレーンの切り替えの修正されたモデル。
【図１０Ｂ】（３ＧＰＰ ＴＳ ２３．２０６に開示され、図９Ａ、図９Ｂに示されるような）標準モデルとは異なる、本発明に従った、ユーザー・プレーンの切り替えの修正されたモデル。
【図１１】ＩＭＳからＣＳへのドメイン移動の例示的な実装。
【図１２】ＩＭＳからＣＳへのドメイン移動の例示的で代替的な実装。
【図１３】ＣＳからＩＭＳへのドメイン移動の例示的な実装。
【図１４】ＣＳからＩＭＳへのドメイン移動の例示的で代替的な実装。
【特許請求の範囲】
【請求項１】
無線アクセス環境において緊急呼に関するＶＣＣをサポートするためのシステム、該システムは下記を備える：
訪問されたＩＭＳサブシステムとＣＳサブシステムとの間のドメイン移動を容易にするための前記訪問されたＩＭＳサブシステムにおけるＶＣＣアプリケーション；
ＶＣＣアプリケーションに動作可能に結合され、前記ＩＭＳサブシステムと前記ＣＳサブシステムとの間のドメイン移動を容易にするための前記訪問されたＩＭＳサブシステムにおけるＥ−ＣＳＣＦサブシステム。
【請求項２】
請求項１記載のシステム、ここにおいて、
前記訪問されたＩＭＳサブシステムは、前記Ｅ−ＣＳＣＦサブシステムに動作可能に結合されたＭＧＣＦサブシステムをさらに備える。
【請求項３】
請求項２記載のシステム、ここにおいて、
前記訪問されたＩＭＳサブシステムは、前記ＭＧＣＦサブシステムに動作可能に結合されたＭＧＷサブシステムをさらに備える。
【請求項４】
請求項２記載のシステム、ここにおいて、
前記ＣＳサブシステムは、ＭＧＣＦサブシステムと通信することが可能なＶＭＳＣサブシステムをさらに備える。
【請求項５】
さらに下記を備える請求項１記載のシステム：
少なくとも一つのＵＥユニット。
【請求項６】
さらに下記を備える請求項５記載のシステム：
通信を容易にするために前記ＵＥユニットに動作可能に結合されたＰ−ＣＳＣＦ。
【請求項７】
さらに下記を備える請求項１記載のシステム：
前記Ｅ−ＣＳＣＦサブシステムに動作可能に結合され、位置情報の抽出に関連した機能を実行するＬＲＦサブシステム。
【請求項８】
請求項１記載のシステム、ここにおいて、
前記訪問されたＩＭＳサブシステムは、訪問されたネットワークの中にある。
【請求項９】
請求項１記載のシステム、ここにおいて、
前記訪問されたＩＭＳサブシステムは、ホームネットワークの中にある。
【請求項１０】
無線アクセス環境において緊急呼に関するＶＣＣをサポートするための方法、該方法は下記を備える：
ＶＣＣアプリケーションを介してＩＭＳサブシステムとＣＳサブシステムとの間でドメイン移動を容易にすること；
Ｅ−ＣＳＣＦを介してＩＭＳサブシステムとＣＳサブシステムとの間でドメイン移動を容易にすること。
【請求項１１】
さらに下記を備える請求項１０記載の方法：
オーサライズされたＵＥからの緊急呼をサポートすること。
【請求項１２】
さらに下記を備える請求項１０記載の方法：
オーサライズされていないＵＥからの緊急呼をサポートすること。
【請求項１３】
さらに下記を備える請求項１０記載の方法：
ホームネットワーク内のＵＥからの緊急呼をサポートすること。
【請求項１４】
さらに下記を備える請求項１０記載の方法：
第１の無線アクセスネットワークから第２の無線アクセスネットワークへのＶＣＣ移動に追従するＵＥの位置を抽出すること。
【請求項１５】
さらに下記を備える請求項１４記載の方法：
位置のサポートの継続性を可能にするためにＶＣＣアプリケーションから出て行く呼のレグの上で前記Ｅ−ＣＳＣＦを起動すること。
【請求項１６】
さらに下記を備える請求項１０記載の方法：
ＵＥからＶＣＣに関連した情報を搬送すること。
【請求項１７】
さらに下記を備える請求項１０記載の方法：
ＩＭＳからＣＳへの移動に関するemergency SETUPメッセージの中においてＶＣＣを表示すること。
【請求項１８】
さらに下記を備える請求項１０記載の方法：
ＭＳＣに対して部分的に、または完全に透過的な方法で前記ＶＣＣアプリケーションに対する緊急呼をルーティングするために、前記ＭＳＣからＧＭＬＣへの既存のＭＡＰ問い合わせを使用すること。
【請求項１９】
さらに下記を備える請求項１０記載の方法：
ＬＲＦに対して位置の更新を実行すること。
【請求項２０】
さらに下記を備える請求項１０記載の方法：
ＭＳＣに対して部分的に、または完全に透過的な方法で前記ドメイン移動を容易にするために、前記ＭＳＣからのＧＭＬＣ問い合わせを使用すること。
【請求項２１】
さらに下記を備える請求項１０記載の方法：
緊急呼が設定されるとき、アンカーＬＲＦ内の位置の抽出のアンカーリング。
【請求項２２】
無線アクセス環境における緊急呼に関するＶＣＣをサポートするためのシステム、該システムは下記を備える：
訪問されたＩＭＳサブシステムとＣＳサブシステムとの間でドメイン移動を容易にするための第１の手段；
前記第１の手段に動作可能に結合され、前記ＩＭＳサブシステムと前記ＣＳサブシステムとの間でドメイン移動を容易にするための前記訪問されたＩＭＳサブシステム内の第２の手段。
【請求項２３】
無線アクセス環境における緊急呼に関するＶＣＣのサポートのためのコンピューター読み取り可能媒体、該コンピューター読み取り可能媒体は少なくとも一つの計算装置に下記を実行させるコードを備える：
Ｅ−ＣＳＣＦを介してＩＭＳサブシステムとＣＳサブシステムとの間でドメイン移動を容易にすること；
第１の無線アクセスネットワークから第２の無線アクセスネットワークへのＶＣＣ移動に追従するＵＥの位置を抽出すること。
【請求項２４】
請求項２３記載のコンピューター読み取り可能媒体、ここにおいて、
前記ＵＥはオーサライズされたＵＥである。
【請求項２５】
請求項２３記載のコンピューター読み取り可能媒体、ここにおいて、
前記ＵＥはオーサライズされていないＵＥである。
【請求項２６】
請求項２３記載のコンピューター読み取り可能媒体、ここにおいて、
前記ＵＥはホームネットワーク内にある。
【請求項１】
無線アクセス環境において緊急呼に関するＶＣＣをサポートするためのシステム、該システムは下記を備える：
訪問されたＩＭＳサブシステムとＣＳサブシステムとの間のドメイン移動を容易にするための前記訪問されたＩＭＳサブシステムにおけるＶＣＣアプリケーション；
ＶＣＣアプリケーションに動作可能に結合され、前記ＩＭＳサブシステムと前記ＣＳサブシステムとの間のドメイン移動を容易にするための前記訪問されたＩＭＳサブシステムにおけるＥ−ＣＳＣＦサブシステム。
【請求項２】
請求項１記載のシステム、ここにおいて、
前記訪問されたＩＭＳサブシステムは、前記Ｅ−ＣＳＣＦサブシステムに動作可能に結合されたＭＧＣＦサブシステムをさらに備える。
【請求項３】
請求項２記載のシステム、ここにおいて、
前記訪問されたＩＭＳサブシステムは、前記ＭＧＣＦサブシステムに動作可能に結合されたＭＧＷサブシステムをさらに備える。
【請求項４】
請求項２記載のシステム、ここにおいて、
前記ＣＳサブシステムは、ＭＧＣＦサブシステムと通信することが可能なＶＭＳＣサブシステムをさらに備える。
【請求項５】
さらに下記を備える請求項１記載のシステム：
少なくとも一つのＵＥユニット。
【請求項６】
さらに下記を備える請求項５記載のシステム：
通信を容易にするために前記ＵＥユニットに動作可能に結合されたＰ−ＣＳＣＦ。
【請求項７】
さらに下記を備える請求項１記載のシステム：
前記Ｅ−ＣＳＣＦサブシステムに動作可能に結合され、位置情報の抽出に関連した機能を実行するＬＲＦサブシステム。
【請求項８】
請求項１記載のシステム、ここにおいて、
前記訪問されたＩＭＳサブシステムは、訪問されたネットワークの中にある。
【請求項９】
請求項１記載のシステム、ここにおいて、
前記訪問されたＩＭＳサブシステムは、ホームネットワークの中にある。
【請求項１０】
無線アクセス環境において緊急呼に関するＶＣＣをサポートするための方法、該方法は下記を備える：
ＶＣＣアプリケーションを介してＩＭＳサブシステムとＣＳサブシステムとの間でドメイン移動を容易にすること；
Ｅ−ＣＳＣＦを介してＩＭＳサブシステムとＣＳサブシステムとの間でドメイン移動を容易にすること。
【請求項１１】
さらに下記を備える請求項１０記載の方法：
オーサライズされたＵＥからの緊急呼をサポートすること。
【請求項１２】
さらに下記を備える請求項１０記載の方法：
オーサライズされていないＵＥからの緊急呼をサポートすること。
【請求項１３】
さらに下記を備える請求項１０記載の方法：
ホームネットワーク内のＵＥからの緊急呼をサポートすること。
【請求項１４】
さらに下記を備える請求項１０記載の方法：
第１の無線アクセスネットワークから第２の無線アクセスネットワークへのＶＣＣ移動に追従するＵＥの位置を抽出すること。
【請求項１５】
さらに下記を備える請求項１４記載の方法：
位置のサポートの継続性を可能にするためにＶＣＣアプリケーションから出て行く呼のレグの上で前記Ｅ−ＣＳＣＦを起動すること。
【請求項１６】
さらに下記を備える請求項１０記載の方法：
ＵＥからＶＣＣに関連した情報を搬送すること。
【請求項１７】
さらに下記を備える請求項１０記載の方法：
ＩＭＳからＣＳへの移動に関するemergency SETUPメッセージの中においてＶＣＣを表示すること。
【請求項１８】
さらに下記を備える請求項１０記載の方法：
ＭＳＣに対して部分的に、または完全に透過的な方法で前記ＶＣＣアプリケーションに対する緊急呼をルーティングするために、前記ＭＳＣからＧＭＬＣへの既存のＭＡＰ問い合わせを使用すること。
【請求項１９】
さらに下記を備える請求項１０記載の方法：
ＬＲＦに対して位置の更新を実行すること。
【請求項２０】
さらに下記を備える請求項１０記載の方法：
ＭＳＣに対して部分的に、または完全に透過的な方法で前記ドメイン移動を容易にするために、前記ＭＳＣからのＧＭＬＣ問い合わせを使用すること。
【請求項２１】
さらに下記を備える請求項１０記載の方法：
緊急呼が設定されるとき、アンカーＬＲＦ内の位置の抽出のアンカーリング。
【請求項２２】
無線アクセス環境における緊急呼に関するＶＣＣをサポートするためのシステム、該システムは下記を備える：
訪問されたＩＭＳサブシステムとＣＳサブシステムとの間でドメイン移動を容易にするための第１の手段；
前記第１の手段に動作可能に結合され、前記ＩＭＳサブシステムと前記ＣＳサブシステムとの間でドメイン移動を容易にするための前記訪問されたＩＭＳサブシステム内の第２の手段。
【請求項２３】
無線アクセス環境における緊急呼に関するＶＣＣのサポートのためのコンピューター読み取り可能媒体、該コンピューター読み取り可能媒体は少なくとも一つの計算装置に下記を実行させるコードを備える：
Ｅ−ＣＳＣＦを介してＩＭＳサブシステムとＣＳサブシステムとの間でドメイン移動を容易にすること；
第１の無線アクセスネットワークから第２の無線アクセスネットワークへのＶＣＣ移動に追従するＵＥの位置を抽出すること。
【請求項２４】
請求項２３記載のコンピューター読み取り可能媒体、ここにおいて、
前記ＵＥはオーサライズされたＵＥである。
【請求項２５】
請求項２３記載のコンピューター読み取り可能媒体、ここにおいて、
前記ＵＥはオーサライズされていないＵＥである。
【請求項２６】
請求項２３記載のコンピューター読み取り可能媒体、ここにおいて、
前記ＵＥはホームネットワーク内にある。
【図１】
【図２】
【図３】
【図４】
【図５Ａ】
【図５Ｂ】
【図６Ａ】
【図６Ｂ】
【図７】
【図８】
【図９Ａ】
【図９Ｂ】
【図１０Ａ】
【図１０Ｂ】
【図１１】
【図１２】
【図１３】
【図１４】
【図２】
【図３】
【図４】
【図５Ａ】
【図５Ｂ】
【図６Ａ】
【図６Ｂ】
【図７】
【図８】
【図９Ａ】
【図９Ｂ】
【図１０Ａ】
【図１０Ｂ】
【図１１】
【図１２】
【図１３】
【図１４】
【公表番号】特表２００９−５３５９４４（Ｐ２００９−５３５９４４Ａ）
【公表日】平成２１年１０月１日（２００９．１０．１）
【国際特許分類】
【出願番号】特願２００９−５０８００９（Ｐ２００９−５０８００９）
【出願日】平成１９年４月３０日（２００７．４．３０）
【国際出願番号】ＰＣＴ／ＵＳ２００７／０６７８２５
【国際公開番号】ＷＯ２００７／１２７９９１
【国際公開日】平成１９年１１月８日（２００７．１１．８）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＧＳＭ
２．ＥＥＰＲＯＭ
【出願人】（５９５０２０６４３）クゥアルコム・インコーポレイテッド (7,166)
【氏名又は名称原語表記】ＱＵＡＬＣＯＭＭ ＩＮＣＯＲＰＯＲＡＴＥＤ
【Ｆターム（参考）】
【公表日】平成２１年１０月１日（２００９．１０．１）
【国際特許分類】
【出願日】平成１９年４月３０日（２００７．４．３０）
【国際出願番号】ＰＣＴ／ＵＳ２００７／０６７８２５
【国際公開番号】ＷＯ２００７／１２７９９１
【国際公開日】平成１９年１１月８日（２００７．１１．８）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＧＳＭ
２．ＥＥＰＲＯＭ
【出願人】（５９５０２０６４３）クゥアルコム・インコーポレイテッド (7,166)
【氏名又は名称原語表記】ＱＵＡＬＣＯＭＭ ＩＮＣＯＲＰＯＲＡＴＥＤ
【Ｆターム（参考）】
[ Back to top ]