ハンドオーバ後にＵＥのロケーション連続性を維持するための方法及び装置
ハンドオーバ後にユーザ機器（ＵＥ）のロケーション連続性を維持するための技法について説明する。ＵＥは、第１の無線アクセス・ネットワーク（ＲＡＮ）と通信し、ハンドオーバより前にソース・サービング・ノードとソース・ロケーション・サーバとによってサービスされる。ＵＥは、第２のＲＡＮと通信し、ハンドオーバ後にターゲット・サービング・ノードとターゲット・ロケーション・サーバとによってサービスされる。一態様では、ＵＥのハンドオーバ中にターゲット・サービング・ノードの識別情報をロケーション・サーバに転送することによって、ＵＥのロケーション連続性が維持され得る。１つの設計では、ターゲット・サービング・ノードは、その識別情報をターゲット・ロケーション・サーバに送信し、ターゲット・ロケーション・サーバは、ＵＥをサービスするロケーション及びルーティング機能（ＬＲＦ）を更新する。パケット交換領域から回線交換領域へのハンドオーバのための別の設計では、ソース・サービング・ノードはターゲット・サービング・ノード識別情報をソース・ロケーション・サーバに送信し、ソース・ロケーション・サーバはＬＲＦを更新する。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、一般に通信に関し、より詳細には、ユーザ機器（ＵＥ）のロケーション・サービスをサポートするための技法に関する。
【０００２】
米国特許法第１１９条に基づく優先権の主張
本特許出願は、以下の仮出願の優先権を主張する。
【０００３】
・２００９年２月９日に出願された「Location Continuity for Emergency Calls」と題する米国仮出願第６１／１５１，１２３号、
・２００９年２月１１日に出願された「Location Continuity for Emergency Calls」と題する米国仮出願第６１／１５１，７２６号、
・２００９年３月２３日に出願された「Location Continuity for Emergency Calls」と題する米国仮出願第６１／１６２，６０６号、
・２００９年３月２６日に出願された「Location Continuity for Emergency Calls」と題する米国仮出願第６１／１６３，６６４号、及び
・２００９年５月４日に出願された「Location Continuity for Emergency Calls」と題する米国仮出願第６１／１７５，４５２号。
【０００４】
上記に記載した仮出願のすべてが、本出願の譲受人に譲渡され、参照により本明細書に明確に組み込まれる。
【背景技術】
【０００５】
ワイヤレス通信ネットワークは、ボイス、ビデオ、パケットデータ、メッセージング、ブロードキャストなどの様々な通信サービスを提供するために広く展開されている。これらのワイヤレス・ネットワークは、利用可能なネットワークリソースを共有することによって複数のユーザをサポートすることが可能な多元接続ネットワークであり得る。そのような多元接続ネットワークの例には、符号分割多元接続（ＣＤＭＡ）ネットワーク、時分割多元接続（ＴＤＭＡ）ネットワーク、周波数分割多元接続（ＦＤＭＡ）ネットワーク、直交ＦＤＭＡ（ＯＦＤＭＡ）ネットワーク、及びシングル・キャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）ネットワークがある。
【０００６】
ＵＥは、呼、例えば、緊急呼のために、ワイヤレス・ネットワークと通信することがある。例えば、緊急要員が適切なロケーションにディスパッチされ得るように、呼中にＵＥのロケーションを判断することが望ましいことがある。ＵＥのロケーションは、ＵＥにロケーション・サービスを提供することができる１つまたは複数のネットワーク・エンティティからのサポートを用いて判断され得る。ＵＥは、モバイルであり得、呼中に、あるワイヤレス・ネットワークから別のワイヤレス・ネットワークにハンドオーバされ得る。ハンドオーバ後にＵＥのロケーション・サービスを維持することが望ましいことがある。
【発明の概要】
【０００７】
本明細書では、ハンドオーバ後にＵＥのロケーション連続性を維持するための技法について説明する。ロケーション連続性は、あるワイヤレス・ネットワークから別のワイヤレス・ネットワークへのハンドオーバ後にＵＥのロケーション・サービスをサポートし続ける能力を指す。ロケーション連続性は、例えば、緊急呼の場合に特に望ましいことがあり、それにより、ＵＥの初期ロケーション推定値及び／または更新されたロケーション推定値を、緊急呼をサービスするPublic Safety Answering Point（ＰＳＡＰ）に与えることができる。
【０００８】
ＵＥは、呼中に第１の無線アクセス・ネットワーク（ＲＡＮ）から第２のＲＡＮにハンドオーバされ得る。ＵＥは、第１のＲＡＮと通信し、ハンドオーバより前にソース・サービング・ノードとソース・ロケーション・サーバとによってサービスされ得る。ＵＥは、第２のＲＡＮと通信し、ハンドオーバ後にターゲット・サービング・ノードとターゲット・ロケーション・サーバとによってサービスされ得る。各ＲＡＮは、ＵＥの無線通信をサポートし得る。各サービング・ノードは、ＵＥの通信サービスをサポートし得る。各ロケーション・サーバは、ＵＥのロケーション・サービスをサポートし得る。
【０００９】
一態様では、ＵＥのハンドオーバ中にターゲット・サービング・ノードの識別情報またはアドレスをロケーション・サーバに転送することによって、ＵＥのロケーション連続性が維持され得る。１つの設計では、ターゲット・サービング・ノードは、その識別情報をターゲット・ロケーション・サーバに送信し得、次いで、ターゲット・ロケーション・サーバは、ＵＥをサービスするロケーション及びルーティング機能（ＬＲＦ）を更新し得る。パケット交換領域から回線交換領域へのハンドオーバに適用可能であり得る別の設計では、ソース・サービング・ノードはターゲット・サービング・ノードの識別情報をソース・ロケーション・サーバに送信し得、次いで、ソース・ロケーション・サーバはＬＲＦを更新し得る。どちらの設計についても、ＬＲＦは、必要な場合、ターゲット・サービング・ノード識別情報を使用して、ＵＥのロケーション・セッションを開始し得る。ＬＲＦは、ソース・ロケーション・サーバがターゲット・ロケーション・サーバとは異なる場合、ハンドオーバ後にそのソース・ロケーション・サーバを除去し得る。
【００１０】
本開示の様々な態様及び特徴について以下でさらに詳細に説明する。
【図面の簡単な説明】
【００１１】
【図１】異なるワイヤレス・ネットワークの例示的な展開を示す図。
【図２】異なるワイヤレス・ネットワークの例示的な展開を示す図。
【図３】ＵＥのロケーション連続性を維持するための方式を示す図。
【図４】ＵＥのロケーション連続性を維持するための方式を示す図。
【図５】ＵＥのロケーション連続性を維持するための方式を示す図。
【図６】ＵＥのロケーション連続性を維持するための方式を示す図。
【図７】ＵＥのロケーション連続性を維持するためのメッセージ・フローを示す図。
【図８】ＵＥの例示的なハンドオーバ・シナリオを示す図。
【図９】サービング・ノードによってロケーション・サービスをサポートするためのプロセスを示す図。
【図１０】ロケーション・サーバによってロケーション・サービスをサポートするためのプロセスを示す図。
【図１１】ＬＲＦによってロケーション・サービスをサポートするためのプロセスを示す図。
【図１２】ＵＥによってロケーション・サービスを取得するためのプロセスを示す図。
【図１３】ＵＥと様々なネットワーク・エンティティとのブロック図。
【発明を実施するための形態】
【００１２】
本明細書では、ハンドオーバ後にＵＥのロケーション連続性を維持するための技法について説明する。本技法は、「3rd Generation Partnership Project」（３ＧＰＰ）という名称の組織によって定義された３ＧＰＰワイヤレス・ネットワーク、及び「3rd Generation Partnership Project 2」（３ＧＰＰ２）という名称の組織によって定義された３ＧＰＰ２ワイヤレス・ネットワークなど、様々なワイヤレス・ネットワークに使用され得る。
【００１３】
本技法は、回線交換（ＣＳ）呼及びパケット交換（ＰＳ）呼など、様々なタイプの呼にも使用され得る。ＣＳ呼は、その持続時間全体にわたって、その呼に専用リソース（例えば、トラフィック・チャネル）が割り当てられる、呼である。ＰＳ呼は、共用リソースを使用してパケットにおいてデータが送信される、呼である。ワイヤレス・ネットワークは、ＣＳ呼のみ、またはＰＳ呼のみ、またはＣＳ呼とＰＳ呼の両方をサポートし得る。
【００１４】
本技法は、ユーザ・プレーン及びコントロール・プレーン・ロケーション・ソリューション／アーキテクチャにも使用され得る。ユーザ・プレーン・ロケーション・ソリューションは、ユーザ・プレーンを介してロケーション・サービスのためのメッセージを送信するロケーション・ソリューションである。ユーザ・プレーンは、上位レイヤ・アプリケーションのためのシグナリング及びデータを搬送し、ユーザ・プレーンベアラを採用するための機構であり、一般に、ユーザ・データグラム・プロトコル（ＵＤＰ）、伝送制御プロトコル（ＴＣＰ）、及びインターネット・プロトコル（ＩＰ）など、標準プロトコルを用いて実装される。コントロール・プレーン・ロケーション・ソリューションは、コントロール・プレーンを介してロケーション・サービスのためのメッセージを送信するロケーション・ソリューションである。コントロール・プレーンは、上位レイヤ・アプリケーションのためのシグナリングを搬送するための機構であり、一般に、ネットワーク固有のプロトコル、インターフェース、及びシグナリング・メッセージを用いて実装される。ロケーション・サービスをサポートするメッセージは、コントロール・プレーン・ロケーション・ソリューションではシグナリングの一部として搬送され、ユーザ・プレーン・ロケーション・ソリューションでは（ネットワークから見て）データの一部として搬送される。ただし、そのメッセージのコンテンツは、ユーザ・プレーン・ロケーション・ソリューションとコントロール・プレーン・ロケーション・ソリューションの両方において同じまたは同様であり得る。
【００１５】
表１に、いくつかの例示的なロケーション・ソリューションを記載する。セキュアユーザ・プレーン・ロケーション（ＳＵＰＬ）は、オープン・モバイル・アライアンス（ＯＭＡ）から公的に入手可能な文書に記載されている。ＴＳ２３．２７１及び他の「ＴＳ」文書は、３ＧＰＰから公的に入手可能である。ＡＮＳＩ Ｊ−ＳＴＤ−０３６は、米国規格協会（ＡＮＳＩ）から公的に入手可能な文書に記載されている。３ＧＰＰ２ Ｘ．Ｓ０００２は、３ＧＰＰ２から公的に入手可能な文書に記載されている。
【表１】
【００１６】
図１に、３ＧＰＰワイヤレス・ネットワーク１０２及び１０４の例示的な展開を示す。一般に、ワイヤレス・ネットワークは、（ｉ）無線通信をサポートすることができるＲＡＮと、（ｉｉ）様々な通信サービスをサポートすることができるコア・ネットワークとを含み得る。ＲＡＮは、アクセス・ネットワーク、無線ネットワークなどと呼ばれることもある。ワイヤレス・ネットワーク１０２は、ＲＡＮ１２２とコア・ネットワーク１３０とを含む。ワイヤレス・ネットワーク１０４は、ＲＡＮ１２４とコア・ネットワーク１４０とを含む。
【００１７】
ＲＡＮ１２２は、Wideband Code Division Multiple Access（ＷＣＤＭＡ）をサポートするUniversal Terrestrial Radio Access Network（ＵＴＲＡＮ）、またはGlobal System for Mobile Communications（ＧＳＭ（登録商標））とEnhanced Data rates for GSM Evolution（ＥＤＧＥ）とをサポートするGSM EDGE Radio Access Network（ＧＥＲＡＮ）、または何らかの他の無線アクセス技術（ＲＡＴ）をサポートするＲＡＮであり得る。ＲＡＮ１２４は、Long Term Evolution（ＬＴＥ）をサポートするEvolved UTRAN（Ｅ−ＵＴＲＡＮ）、または何らかの他のＲＡＴをサポートするＲＡＮであり得る。ＲＡＴは、無線技術、エアリンク・インターフェース、ワイヤレス・アクセス・タイプなどと呼ばれることもある。各ＲＡＮは、基地局及び／または他のネットワーク・エンティティを含み得る。基地局は、ノードＢ、進化型ノードＢ（ｅＮＢ）などと呼ばれることもある。例えば、ＵＴＲＡＮ１２２は、ノードＢと、ノードＢの協調及び制御を行い得る無線ネットワーク・コントローラ（ＲＮＣ）とを含み得る。Ｅ−ＵＴＲＡＮ１２４はｅＮＢを含み得る。
【００１８】
コア・ネットワーク１３０は、ＲＡＮ１２２と通信するＵＥの様々な通信サービスをサポートし得る。コア・ネットワーク１３０内で、モバイル交換センター（ＭＳＣ）１３２は、そのカバレージ・エリア内のＵＥのＣＳ呼のためのスイッチング及びシグナリング機能を実行し得る。ＭＳＣサーバ１３４は、そのカバレージ・エリア内のＵＥのＣＳ呼のためのシグナリング機能を実行し得る。サービングＧＰＲＳサポートノード（ＳＧＳＮ）１３６は、ＲＡＮ１２２と通信するＵＥのＰＳ接続及びセッションのための、シグナリング、スイッチング、及びルーティング機能を実行し得る。ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）１３７は、ＵＥのデータ接続性の維持、ＩＰアドレス割振り、ＩＰルーティングなど、様々な機能を実行し得る。サービング・モバイル・ロケーション・センター（ＳＭＬＣ）またはスタンドアロンＳＭＬＣ（ＳＡＳ）１２８は、ＲＡＮ１２２と通信するＵＥの測位をサポートし得る。測位とは、ターゲットＵＥの地理的ロケーションを判断する機能を指す。ゲートウェイ・モバイル・ロケーション・センター（ＧＭＬＣ）１３８は、ロケーション・サービスをサポートし、外部ロケーション・サービス（ＬＣＳ）クライアントとインターフェースし、加入者プライバシ、許可、認証、ビリングなどのサービスを提供するための、様々な機能を実行し得る。ＳＭＬＣ／ＳＡＳ１２８及びＧＭＬＣ１３８は、３ＧＰＰのためのコントロール・プレーン・ロケーション・ソリューション、例えば、ＴＳ２３．２７１をサポートし得る。
【００１９】
ワイヤレス・ネットワーク１０２はＰＳ呼及びＣＳ呼をサポートし得る。ＵＴＲＡＮ ＰＳの場合、ＰＳ呼は、ＵＴＲＡＮ１２２とＳＧＳＮ１３６とによってサポートされ得る。ＵＴＲＡＮ ＣＳの場合、ＣＳ呼は、ＵＴＲＡＮ１２２と、ＭＳＣ１３２またはＭＳＣサーバ１３４のいずれかとによってサポートされ得る。ＧＥＲＡＮ ＣＳの場合、ＣＳ呼は、ＧＥＲＡＮ１２２と、ＭＳＣ１３２またはＭＳＣサーバ１３４のいずれかとによってサポートされ得る。
【００２０】
コア・ネットワーク１４０は、ＲＡＮ１２４と通信するＵＥの様々な通信サービスをサポートし得る。コア・ネットワーク１４０内で、モビリティ管理エンティティ（ＭＭＥ）１４２は、モビリティ管理、ゲートウェイ選択、認証、ベアラ管理など、様々な制御機能を実行し得る。進化型ＳＭＬＣ（Ｅ−ＳＭＬＣ）１４４は、ＲＡＮ１２４と通信するＵＥの測位をサポートし得る。サービング・ゲートウェイ（Ｓ−ＧＷ）１４６は、データ・ルーティング及びフォワーディング、モビリティアンカリングなど、ＵＥのためのデータ転送に関係する様々な機能を実行し得る。パケット・データ・ネットワーク（ＰＤＮ）ゲートウェイ１５０は、ＵＥのデータ接続性の維持、ＩＰアドレス割振り、ＩＰルーティングなど、様々な機能を実行し得る。
【００２１】
ＧＭＬＣ１４８は、ＲＡＮ１２４と通信するＵＥのロケーション・サービスをサポートし得る。緊急ＳＵＰＬロケーション・プラットフォーム（Ｅ−ＳＬＰ）１５８は、ＳＵＰＬロケーション・センター（ＳＬＣ）、及び場合によってはＳＵＰＬ測位センター（ＳＰＣ）を含み得る。ＳＬＣは、ロケーション・サービスのための様々な機能を実行し、ＳＵＰＬの動作を協調させ、ＳＵＰＬ対応端末（ＳＥＴ）と対話し得る。ＳＰＣは、ＳＥＴの測位と、ＳＥＴへの支援データの配信とをサポートし得、また、位置計算に使用されるメッセージ及びプロシージャを担当し得る。ＧＭＬＣ１４８は、３ＧＰＰのためのコントロール・プレーン・ロケーション・ソリューション、例えば、ＴＳ２３．２７１をサポートし得る。Ｅ−ＳＬＰ１５８はＳＵＰＬをサポートし得る。所与の呼のために、ＲＡＮ１２４を介して、またはＲＡＮ１２２とＳＧＳＮ１３６とを介して、コントロール・プレーン・ロケーション・ソリューションまたはユーザ・プレーン・ロケーション・ソリューションのいずれかが選択され得る。
【００２２】
プロキシ呼セッション制御機能（Ｐ−ＣＳＣＦ）１５２及び緊急ＣＳＣＦ（Ｅ−ＣＳＣＦ）１５４は、ＩＰマルチメディア・サブシステム（ＩＭＳ）サービス、例えば、ボイスオーバーＩＰ（ＶｏＩＰ）をサポートし得る。Ｐ−ＣＳＣＦ１５２は、ＵＥからの要求を受け付け、これらの要求を内部で処理するか、または場合によっては変換の後に、これらの要求を他のエンティティにフォワーディングし得る。Ｅ−ＣＳＣＦ１５４は、ＵＥのセッション制御サービスを実行し得、ＩＭＳ緊急サービスをサポートするために使用されるセッション状態を維持し得、緊急ＶｏＩＰ呼をサポートし得る。緊急サービス集中化及び連続性アプリケーションサーバ（Ｅ−ＳＣＣ ＡＳ）１５６は、ボイス呼のための単一無線ボイス呼連続性（ＳＲＶＣＣ）をサポートし得る。ＳＲＶＣＣでは、ＣＳ ＲＡＮとＰＳ ＲＡＮの両方に同時にアクセスすることができないＵＥのためにＣＳ ＲＡＮとＰＳ ＲＡＮとの間でハンドオーバが行われるとき、呼が保存され得る。
【００２３】
ＰＳＡＰ１８０は、（例えば、警察、消防、及び医療サービスについての）緊急呼に返答することを担当するエンティティであり、緊急センター（ＥＣ）と呼ばれることもある。そのような呼は、ユーザが、北米では「９１１」または欧州では「１１２」など、いくつかの固定のよく知られている番号をダイヤルしたときに、開始され得る。ＰＳＡＰ１８０は、ＰＳ呼（例えば、ＶｏＩＰ呼）とセッション開始プロトコル（ＳＩＰ）とをサポートし得、ＳＩＰは、ＩＰに基づいて対話型ユーザセッションを開始し、変更し、終了するためのシグナリング・プロトコルである。ＰＳＡＰ１８０はＣＳ呼をもサポートし得る。
【００２４】
ＬＲＦ１７０は、ＰＳＡＰ１８０とインターフェースし、ルーティング機能を実行し、緊急呼のためのロケーション・サービス（例えば、ロケーション推定値の検索）をサポートし得る。ＬＲＦ１７０は、ＴＳ２３．１６７に記載されているように、緊急呼がＰＳ領域において発信されたときに、割り当てられ得る。ＬＲＦ１７０は、ロケーション・サービスのためのアンカーポイントであり得、ハンドオーバ後に維持され得る。ＬＲＦ１７０は、図１に示すように、いずれかのロケーション・サーバの外部に実装され得る。ＬＲＦ１７０はまた、例えば、ある接続を介してまたは共通の物理的実装形態を介してロケーション・サーバと重複し得る。
【００２５】
ＵＥ１１０は、ワイヤレス・ネットワーク１０２及び／または１０４と通信して、通信サービスを取得し得る。ＵＥ１１０は、固定でも移動でもよく、移動局、アクセス端末、ＳＥＴ、加入者ユニット、局などと呼ばれることもある。ＵＥ１１０は、セルラー電話、携帯情報端末（ＰＤＡ）、ワイヤレス・デバイス、ワイヤレスモデム、ワイヤレス・ルータ、ラップトップ・コンピュータ、テレメトリ・デバイス、トラッキング・デバイスなどであり得る。ＵＥ１１０は、ＲＡＮ１２２または１２４中の１つまたは複数の基地局と通信し得る。ＵＥ１１０はまた、１つまたは複数の衛星１９０からの信号を受信及び測定し、衛星１９０の擬似距離測定値を取得し得る。ＵＥ１１０はまた、ＲＡＮ１２２及び／またはＲＡＮ１２４中の基地局からの信号を測定し、それらの基地局のタイミング測定値、信号強度測定値、及び／または信号品質測定値を取得し得る。それらの擬似距離測定値、タイミング測定値、信号強度測定値、及び／または信号品質測定値は、ＵＥ１１０のロケーション推定値を導出するために使用され得る。ロケーション推定値は、位置推定値、位置フィックスなどと呼ばれることもある。
【００２６】
衛星１９０は、米国の全地球測位システム（ＧＰＳ）、欧州のGalileoシステム、ロシアのＧＬＯＮＡＳＳシステム、または何らかの他の衛星測位システム（ＳＰＳ）の一部であり得る。ＳＰＳは、一般に、送信機から受信した信号に基づいて地球上または地球上空の受信機のロケーションをそれらの受信機が判断できるように配置された送信機のシステムを含む。
【００２７】
図２に、３ＧＰＰワイヤレス・ネットワーク１０４と３ＧＰＰ２ワイヤレス・ネットワーク１０６との例示的な展開を示す。ワイヤレス・ネットワーク１０６は、ＲＡＮ１２６とコア・ネットワーク１６０とを含む。ＲＡＮ１２６は、ＣＤＭＡ２０００ １ｘＲＴＴをサポートする１ｘＲＴＴ ＲＡＮ、またはＩＳ−８５８をサポートするHigh Rate Packet Data（ＨＲＰＤ）ＲＡＮ、または何らかの他のＲＡＴをサポートするＲＡＮであり得る。１ｘＲＴＴ及びＨＲＰＤはｃｄｍａ２０００の一部である。ＨＲＰＤはEvolution-Data Optimized（ＥＶ−ＤＯ）とも呼ばれる。
【００２８】
コア・ネットワーク１６０は、ＲＡＮ１２６と通信するＵＥの様々な通信サービスをサポートし得る。コア・ネットワーク１６０内で、１ｘＲＴＴ ＭＳＣ１６２は、１ｘＲＴＴ ＲＡＮ１２６と通信するＵＥのＣＳ呼のためのスイッチング機能を実行し得る。１ｘ ＣＳインターワーキングソリューション機能（１ｘＣＳ ＩＷＳ）１６４は、コア・ネットワーク１４０とコア・ネットワーク１６０との間のインターワーキングをサポートし得る。パケット・データ・サービング・ノード（ＰＤＳＮ）１６９は、ＨＲＰＤ ＲＡＮ１２６と通信するＵＥのＰＳ接続及びセッションのための、スイッチング及びルーティング機能を実行し得る。位置判断エンティティ（ＰＤＥ）１６６は、１ｘＲＴＴ／ＨＲＰＤ ＲＡＮ１２６と通信するＵＥの測位をサポートし得る。モバイル測位センター（ＭＰＣ）１６８は、ロケーション・サービスをサポートし、外部ＬＣＳクライアントとインターフェースし、加入者プライバシ、許可、認証、ビリングなどのサービスを提供するための、様々な機能を実行し得る。ＭＰＣ１６８は、３ＧＰＰ２のためのコントロール・プレーン・ロケーション・ソリューション、例えば、ＡＮＳＩ Ｊ−ＳＴＤ−０３６、３ＧＰＰ２ Ｘ．Ｓ０００２などをサポートし得る。
【００２９】
図１及び図２は、各ワイヤレス・ネットワーク中に含まれ得るいくつかのネットワーク・エンティティを示している。図１及び図２はまた、様々なネットワーク・エンティティ間のいくつかのインターフェースを示している。各ワイヤレス・ネットワークは、他の機能及びサービスをサポートすることができる他のネットワーク・エンティティ及びインターフェースを含み得る。
【００３０】
ＵＥ１１０は、呼、例えば、緊急呼のために、ワイヤレス・ネットワークと通信することがある。ＵＥ１１０は、通信サービスに関してＵＥ１１０をサービスするように指定されたサービング・ノードを有し得る。サービング・ノードは、ＵＥ１１０がどのＲＡＮと通信しているかと、呼のタイプとに依存し得る。表２に、ＵＥ１１０のサービング・ノードとして働き得る様々なネットワーク・エンティティを記載する。ＰＤＳＮ１６９は、ＭＰＣなどのロケーション・サーバと直接通信しないという点で、他のサービング・ノードとは異なり得る。
【表２】
【００３１】
ＵＥ１１０は、呼中にロケーション・サーバを介してロケーション・サービスを受信し得る。ロケーション・サーバは、ＵＥ１１０がどのワイヤレス・ネットワークと通信しているかと、コントロール・プレーン・ロケーション・ソリューションが利用されるのか、またはユーザ・プレーン・ロケーション・ソリューションが利用されるのかに依存し得る。表３に、ＵＥ１１０のロケーション・サーバとして働き得る様々なネットワーク・エンティティを記載する。
【表３】
【００３２】
ＵＥ１１０は呼中にハンドオーバを実行し得る。ハンドオーバは、あるＲＡＮから別のＲＡＮへの、ＵＥのための無線接続の転送を指す。無線接続は、ＵＥとＲＡＮとの間のシグナリングとトラフィック・データとをサポートするために使用され得る。トラフィック・データは、ボイス呼、緊急呼、データ呼などのうちの１つまたは複数を備え得る。ＲＡＴに応じて、ボイス呼または緊急呼は、例えば、回路またはＶｏＩＰのいずれかを使用し得る。
【００３３】
ＵＥ１１０は、呼中にソース・ワイヤレス・ネットワークからターゲット・ワイヤレス・ネットワークへのハンドオーバを実行し得る。ＵＥ１１０は、ソースＲＡＮと通信し、ハンドオーバより前にソース・ワイヤレス・ネットワーク中のソース・サービング・ノードとソース・ロケーション・サーバとによってサービスされ得る。ＵＥ１１０は、ターゲットＲＡＮと通信し、ハンドオーバ後にターゲット・ワイヤレス・ネットワーク中のターゲット・サービング・ノードとターゲット・ロケーション・サーバとによってサービスされ得る。ハンドオーバより前のネットワーク・エンティティはソース側にあり、ハンドオーバ後のネットワーク・エンティティはターゲット側にある。呼が、ＰＳＡＰ１８０によってサービスされる緊急呼である場合、ソース・ロケーション・サーバ及びターゲット・ロケーション・サーバは、ＰＳＡＰ１８０へのインターフェースを与え得る共通のＬＲＦ１７０と対話し得る。
【００３４】
ソースＲＡＮ及びターゲットＲＡＮは、それぞれ任意のＲＡＴを利用し得、ＣＳ呼またはＰＳ呼をサポートし得る。ソース・ロケーション・サーバ及びターゲット・ロケーション・サーバは、それぞれコントロール・プレーン・ロケーション・ソリューションまたはユーザ・プレーン・ロケーション・ソリューションをサポートし得る。ソースＲＡＮ及びターゲットＲＡＮと、ソース・ロケーション・ソリューション及びターゲット・ロケーション・ソリューションとの以下の選択肢とともに、多数の可能なハンドオーバ・シナリオがあり得る。
【００３５】
・ソースＲＡＮ：Ｅ−ＵＴＲＡＮ、ＵＴＲＡＮ ＰＳ、ＵＴＲＡＮ ＣＳ、ＧＥＲＡＮ ＰＳ、ＧＥＲＡＮ ＣＳ、１ｘＲＴＴ、ＨＲＰＤ、
・ターゲットＲＡＮ：Ｅ−ＵＴＲＡＮ、ＵＴＲＡＮ ＰＳ、ＵＴＲＡＮ ＣＳ、ＧＥＲＡＮ ＰＳ、ＧＥＲＡＮ ＣＳ、１ｘＲＴＴ、ＨＲＰＤ、
・ソース・ロケーション・ソリューション：ＧＥＲＡＮ、ＵＴＲＡＮ、及びＥ−ＵＴＲＡＮの場合は３ＧＰＰ ＣＰソリューション；１ｘＲＴＴの場合は３ＧＰＰ２ ＣＰソリューション；ＳＵＰＬ、ならびに
・ターゲット・ロケーション・ソリューション：ＧＥＲＡＮ、ＵＴＲＡＮ、及びＥ−ＵＴＲＡＮの場合は３ＧＰＰ ＣＰソリューション；１ｘＲＴＴの場合は３ＧＰＰ２ ＣＰソリューション；ＳＵＰＬ。
【００３６】
表４に、いくつかの例示的なハンドオーバ・シナリオを（最上行に）記載し、各ハンドオーバ・シナリオの場合の、ソースＲＡＮ及びターゲットＲＡＮと、ソース・サービング・ノード及びターゲット・サービング・ノードと、ソース・ロケーション・サーバ及びターゲット・ロケーション・サーバとを与える。
【表４】
【００３７】
できる限り多くのハンドオーバ・シナリオについてＵＥ１１０のロケーション連続性を維持することが望ましいことがある。ハンドオーバ後にＵＥ１１０のロケーション連続性を維持するために、アクションの以下のセットが実行され得る。
【００３８】
（ａ）ソース・ロケーション・サーバ（例えば、ＧＭＬＣ、ＭＰＣ、またはＥ−ＳＬＰ）がターゲット・ロケーション・サーバとは異なる場合、そのソース・ロケーション・サーバを除去する、
（ｂ）ターゲット・ロケーション・サーバ（例えば、ＧＭＬＣ、ＭＰＣ、またはＥ−ＳＬＰ）がソース・ロケーション・サーバとは異なる場合、そのターゲット・ロケーション・サーバを割り当てる、
（ｃ）コントロール・プレーン・ロケーション・ソリューションがターゲット・ロケーション・サーバによってサポートされている場合、ターゲット・サービング・ノード（例えば、ＭＭＥ、ＳＧＳＮ、ＭＳＣサーバ、または１ｘＲＴＴ ＭＳＣ）の識別情報と、場合によってはターゲットセル識別情報（ＩＤ）とをターゲット・ロケーション・サーバに供給する、ならびに
（ｄ）ＳＵＰＬが、ターゲット・ロケーション・サーバによってサポートされているが、ソース・ロケーション・サーバによってサポートされていない場合、（ｉ）ＵＥ１１０にアクセスするための手段、例えば、Ｅ−ＳＬＰからＵＥへのＳＵＰＬ ＩＮＩＴメッセージのＵＤＰ／ＩＰまたはＳＩＰ Ｐｕｓｈ転送をサポートするための手段と、（ｉｉ）場合によっては、相互認証をサポートするための手段とをＥ−ＳＬＰに与える。
【００３９】
ターゲット・サービング・ノード識別情報は、ＩＰアドレス、またはＥ．１６４アドレス、または完全修飾ドメインネーム（ＦＱＤＮ）、またはダイアメーター識別情報（Diameter Identity）であり得る。アクション（ｃ）では、（例えば、ＰＳＡＰ１８０に代わって）ハンドオーバ後にコントロール・プレーンのためのモバイル着ロケーション要求（Mobile Terminated Location Request）（ＭＴ−ＬＲ）ロケーションプロシージャを使用してＵＥ１１０のロケーションを取得することが可能になり得る。アクション（ｄ）では、（例えば、ＰＳＡＰ１８０に代わって）ハンドオーバ後にＳＵＰＬロケーションプロシージャを使用してＵＥ１１０のロケーションを取得することが可能になり得る。これらのロケーションプロシージャは、緊急呼のためのＵＥ１１０の初期ロケーション推定値及び／または更新されたロケーション推定値を取得するために使用され得る。
【００４０】
アクション（ａ）〜（ｄ）を完了することによってＵＥ１１０のロケーション連続性を維持するために、様々な方式が定義され得る。これらの方式は、ＰＳ領域において発信し得るかまたはＰＳ領域にハンドオーバされ得る緊急呼をサポートするために、単一のＬＲＦ１７０を仮定し得るが、潜在的には複数のロケーション・サーバを仮定し得る。これらの方式は、図１中のワイヤレス・ネットワーク１０４からワイヤレス・ネットワーク１０２への（またはその逆も同様）ハンドオーバに使用され得、図２中のワイヤレス・ネットワーク１０４からワイヤレス・ネットワーク１０６への（またはその逆も同様）ハンドオーバにも使用され得る。
【００４１】
図３に、例えば、緊急呼の、ハンドオーバ後にＵＥ１１０のロケーション連続性を維持するための第１の方式の設計を示す。第１の方式は、（ｉ）ソース側ではコントロール・プレーン・ロケーション・ソリューションまたはユーザ・プレーン・ロケーション・ソリューションが使用され、（ｉｉ）ターゲット側ではコントロール・プレーンソリューションが使用される、ハンドオーバ・シナリオに使用され得る。図３に示すように、ＵＥ１１０は、第１のＲＡＮ３１２と通信し、ハンドオーバより前にソース側のソース・サービング・ノード３１４とソース・ロケーション・サーバ３１６とによってサービスされ得る。ＵＥ１１０は、第２のＲＡＮ３２２と通信し、ハンドオーバ後にターゲット側のターゲット・サービング・ノード３２４とターゲット・ロケーション・サーバ３２６とによってサービスされ得る。ソース・サービング・ノード３１４は、図１及び図２中のＭＭＥ１４２、またはＳＧＳＮ１３６、またはＭＳＣサーバ１３４、または１ｘＲＴＴ ＭＳＣ１６２であり得る。ターゲット・サービング・ノード３２４は、ＭＭＥ１４２、またはＳＧＳＮ１３６、またはＭＳＣサーバ１３４、または１ｘＲＴＴ ＭＳＣ１６２であり得る。ソース・ロケーション・サーバ３１６は、（ｉ）コントロール・プレーン・ロケーション・ソリューションのためのＧＭＬＣ１３８、またはＧＭＬＣ１４８、またはＭＰＣ１６８、或いは（ｉｉ）ユーザ・プレーン・ロケーション・ソリューションのためのＥ−ＳＬＰ１５８であり得る。ターゲット・ロケーション・サーバ３２６は、コントロール・プレーン・ロケーション・ソリューションのためのＧＭＬＣ１３８、またはＧＭＬＣ１４８、またはＭＰＣ１６８であり得る。
【００４２】
ＵＥ１１０は、ＲＡＮ３１２からＲＡＮ３２２へのハンドオーバを実行し得る。また、ソース・サービング・ノード３１４は、ターゲット・サービング・ノード３２４とともにＵＥ１１０のハンドオーバを実行し得る。ＲＡＮ３１２中の基地局または何らかの他のネットワーク・エンティティ（例えば、ＲＮＣ）は、（ｉ）ＵＴＲＡＮまたはＥ−ＵＴＲＡＮへのハンドオーバの場合はターゲット基地局またはターゲットＲＮＣ、或いは（ｉｉ）ＧＥＲＡＮまたは１ｘＲＴＴへのハンドオーバの場合はターゲットセル／セクタ、のいずれかの識別情報をソース・サービング・ノード３１４に供給し得る。この識別情報は、ＵＥ１１０によってソース基地局に供給されるハンドオーバ関係の測定値から導出され得る。ソース・サービング・ノード３１４は、その構成情報を使用して、受信した基地局またはセル識別情報をターゲット・サービング・ノード３２４の識別情報に変換し得、ターゲット・サービング・ノード３２４は、識別されたターゲット基地局またはターゲットセル／セクタのためのサービング・ノードであり得る。
【００４３】
第１の方式では、ターゲット・サービング・ノード３２４は、例えば、ターゲット・サービング・ノード３２４において記憶された構成情報またはドメインネームシステム（ＤＮＳ）問合せに基づいて、ターゲット・ロケーション・サーバ３２６を判断し得る。その判断は、例えば、同じサービング・ノードに関連する基地局またはセル／セクタの異なるセットをサポートするために異なるロケーション・サーバが割り当てられ得るように、ターゲット基地局またはターゲットセル／セクタを考慮に入れ得る。ターゲット・サービング・ノード３２４は、ハンドオーバ中に、またはハンドオーバが完了したときに、ターゲット・サービング・ノード３２４の識別情報（例えば、ターゲット・サービング・ノード３２４のアドレス）をターゲット・ロケーション・サーバ３２６に転送し得る（ステップ１）。その転送は、（ｉ）ターゲット・サービング・ノード３２４がＳＧＳＮ１３６またはＭＳＣサーバ１３４である場合はモバイル・アプリケーション・パート（Mobile Application Part）（ＭＡＰ）加入者ロケーション報告（Subscriber Location Report）（ＳＬＲ）メッセージ、或いは（ｉｉ）ターゲット・サービング・ノード３２４が１ｘＲＴＴ ＭＳＣ１６２である場合はＡＮＳＩ−４１発信要求（ＯＲＲＥＱ）、或いは（ｉｉｉ）ターゲット・サービング・ノード３２４がＭＭＥ１４２である場合はＳＬＲまたは何らかの他のメッセージを用いて、達成され得る。ターゲット・サービング・ノード３２４は、通常、ターゲット・ロケーション・サーバ３２６と対話して、ロケーション・サービスをサポートし得る。ステップ１における転送は、ターゲット・サービング・ノード３２４とターゲット・ロケーション・サーバ３２６との間の既存のインターフェースを使用して達成され得る。
【００４４】
ターゲット・ロケーション・サーバ３２６は、例えば、呼記録が維持されている場合、ＵＥ１１０のための呼記録を探すことによって、ターゲット・ロケーション・サーバ３２６がＵＥ１１０のソース・ロケーション・サーバであるかどうかを判断し得る。ターゲット・ロケーション・サーバとソース・ロケーション・サーバが同じであると判断された場合、残りのステップはスキップされ得る。他の場合、ターゲット・ロケーション・サーバ３２６は、ハンドオーバに関する情報を用いてＬＲＦ１７０を更新し得る（ステップ２）。例えば、ターゲット・ロケーション・サーバ３２６は、ターゲット・サービング・ノード３２４の識別情報とＵＥ１１０の識別情報とをＬＲＦ１７０に供給し得る。ＬＲＦ１７０は、その更新をターゲット・ロケーション・サーバ３２６から受信し得、ソース・ロケーション・サーバ３１６が、現在割り当てられており、ターゲット・ロケーション・サーバ３２６とは異なる場合、ソース・ロケーション・サーバ３１６を除去し得る（ステップ３）。
【００４５】
代替として、ターゲット・サービング・ノード３２４が１ｘＲＴＴ ＭＳＣ１６２である場合、ＵＥ１１０及び１ｘＣＳ ＩＷＳ１６４は、例えば、ＴＳ２３．２１６に記載のハンドオーバのための通常呼の発信と同様に、１ｘＲＴＴ ＭＳＣ１６２から見てハンドオーバの一部として１ｘＲＴＴ緊急呼を発信し得る。次いで、これにより、１ｘＲＴＴ ＭＳＣ１６２は、通常１ｘＲＴＴ緊急呼発信の一部としてＭＰＣ１６８に問い合わせ得る。次いで、ＭＰＣ１６８は、（ｉ）呼発信のセル／セクタを識別する緊急サービスルーティングキー（Emergency Services Routing Key）（ＥＳＲＫ）番号、または（ｉｉ）所与のセル／セクタにおいてその呼を一意に識別する緊急サービス・ルーティング桁（Emergency Services Routing Digit）（ＥＳＲＤ）番号を返し得る。ただし、ＭＰＣ１６８は、１ｘＲＴＴ ＭＳＣ１６２からの問合せが、ＵＥ１１０の緊急呼の１ｘＲＴＴへのハンドオーバをサポートするためのものであると判断し得、例えば、ＭＰＣ１６８は、ＬＲＦ１７０に問い合わせて、ＵＥ１１０の緊急呼の記録がすでにＬＲＦ１７０中に存在すると判断し得る。次いで、ＭＰＣ１６８は、ＥＳＲＫ番号またはＥＳＲＤ番号をＳＲＶＣＣのための緊急セッション転送番号（Ｅ−ＳＴＮ−ＳＲ）に設定し得る。Ｊ−ＳＴＤ−０３６に記載の通常の緊急呼設定の一部として、次いで、１ｘＲＴＴ ＭＳＣ１６２は、その呼をＥ−ＳＴＮ−ＳＲにルーティングし得、次いで、Ｅ−ＳＴＮ−ＳＲは、その呼をＥ−ＳＣＣ ＡＳ１５６に転送し得る。
【００４６】
ターゲット・サービング・ノードがステップ１におけるロケーション・サーバの更新と後続のハンドオーバの両方を制御するので、第１の方式は、連続するハンドオーバに対処する際にロバストであり得る。ターゲット・ロケーション・サーバが、ステップ２と同時に（またはステップ２の後に）ステップ１に肯定応答した場合、ターゲット・サービング・ノードは、別のハンドオーバがステップ１の後に、ただしこの肯定応答が受信される前に必要とされる場合でも、その肯定応答が受信されるまで待ってからＵＥ１１０の別のハンドオーバを推進し得る。これにより、ＬＲＦ１７０は、場合によっては後で第２のハンドオーバについて通知される前に（ステップ２において）第１のハンドオーバについて通知されるようになり得、例えば、ＬＲＦ１７０へのハンドオーバ通知は間違った順序で行われないようになる。ステップ１が行われる前に別のハンドオーバが必要とされる場合、ターゲット・サービング・ノードは、ステップ１〜３をスキップし得、新しいターゲット・サービング・ノードが上記更新を実行することを可能にし得、それにより、第１のハンドオーバはロケーション・サーバとＬＲＦ１７０とから見えなくなり得、後続のハンドオーバのみが行われたかのように見え得る。
【００４７】
図４に、例えば、緊急呼の、ハンドオーバ後にＵＥ１１０のロケーション連続性を維持するための第２の方式の設計を示す。第２の方式は、（ｉ）ソース側ではコントロール・プレーン・ロケーション・ソリューションが使用され、（ｉｉ）ターゲット側ではコントロール・プレーンソリューションまたはユーザ・プレーンソリューションが使用される、ハンドオーバ・シナリオに使用され得る。図４に示すように、ＵＥ１１０は、第１のＲＡＮ４１２と通信し、ハンドオーバより前にソース・サービング・ノード４１４とソース・ロケーション・サーバ４１６とによってサービスされ得る。ＵＥ１１０は、第２のＲＡＮ４２２と通信し、ハンドオーバ後にターゲット・サービング・ノード４２４とターゲット・ロケーション・サーバ４２６とによってサービスされ得る。ソース・サービング・ノード４１４は、ＭＭＥ１４２、またはＳＧＳＮ１３６、またはＭＳＣサーバ１３４であり得る。ターゲット・サービング・ノード４２４は、ＭＭＥ１４２、またはＳＧＳＮ１３６、またはＭＳＣサーバ１３４、または１ｘＲＴＴ ＭＳＣ１６２であり得る。ソース・ロケーション・サーバ４１６は、コントロール・プレーン・ロケーション・ソリューションのためのＧＭＬＣ１３８またはＧＭＬＣ１４８であり得る。ターゲット・ロケーション・サーバ４２６は、（ｉ）コントロール・プレーン・ロケーション・ソリューションのためのＧＭＬＣ１３８、またはＧＭＬＣ１４８、またはＭＰＣ１６８、或いは（ｉｉ）ユーザ・プレーン・ロケーション・ソリューションのためのＥ−ＳＬＰ１５８であり得る。
【００４８】
第２の方式では、ソース・サービング・ノード４１４は、ハンドオーバが完了した後にＵＥ１１０の識別情報とターゲット・サービング・ノード４２４の識別情報とをソース・ロケーション・サーバ４１６に転送し得る（ステップ１）。この転送は、（ｉ）ソース・サービング・ノード４１４がＳＧＳＮ１３６またはＭＳＣサーバ１３４である場合はＭＡＰ加入者ロケーション報告（ＳＬＲ）メッセージ、或いは（ｉｉ）ソース・サービング・ノード４１４がＭＭＥ１４２である場合はＳＬＲまたは等価なメッセージを用いて、達成され得る。
【００４９】
ソース・ロケーション・サーバ４１６が、呼記録を維持しており、ソース・ロケーション・サーバ４１６がターゲット・ロケーション・サーバとなると判断することができる場合、後続のステップはスキップされ得る。他の場合、ソース・ロケーション・サーバ４１６は、ハンドオーバに関する情報を用いてＬＲＦ１７０を更新し、例えば、ＵＥ識別情報とターゲット・サービング・ノード識別情報とを与え得る（ステップ２）。ＬＲＦ１７０は、ＵＥ１１０のターゲット・ロケーション・サーバ４２６を判断し、割り当て得る。ターゲット・ロケーション・サーバ４２６がソース・ロケーション・サーバ４１６とは異なる場合、ＬＲＦ１７０は、ＵＥ１１０とターゲット・サービング・ノード４２４とに関する情報をターゲット・ロケーション・サーバ４２６に供給し得る（ステップ３）。次いで、ＬＲＦ１７０は、ソース・ロケーション・サーバ４１６がターゲット・ロケーション・サーバ４２６とは異なる場合、ソース・ロケーション・サーバ４１６を除去し得る（ステップ４）。ターゲット・ロケーション・サーバ４２６は、ＬＲＦ１７０から受信した情報に基づいてターゲット・サービング・ノード４２４と通信し得る。ターゲット・ロケーション・サーバ４２６がＵＥ１１０のロケーション要求をターゲット・サービング・ノード４２４に送信することができる前にターゲット側からの後続のハンドオーバが行われた場合、ターゲット・サービング・ノード４２４は（例えば、構成情報に基づいて）ターゲット・ロケーション・サーバ４２６を判断し得る。次いで、ターゲット・サービング・ノード４２４は、この後続のハンドオーバに関してターゲット・ロケーション・サーバ４２６を更新し得る。
【００５０】
図５に、例えば、緊急呼の、ハンドオーバ後にＵＥ１１０のロケーション連続性を維持するための第３の方式の設計を示す。第３の方式は、（ｉ）ソース側ではコントロール・プレーン・ロケーション・ソリューションが使用され、（ｉｉ）ターゲット側ではコントロール・プレーンソリューションまたはユーザ・プレーンソリューションが使用される、ハンドオーバ・シナリオにおける３ＧＰＰ ＲＡＴ間のハンドオーバに使用され得る。図５に示すように、ＵＥ１１０は、第１のＲＡＮ５１２と通信し、ハンドオーバより前にソース・サービング・ノード５１４とソース・ロケーション・サーバ５１６とによってサービスされ得る。ＵＥ１１０は、第２のＲＡＮ５２２と通信し、ハンドオーバ後にターゲット・サービング・ノード５２４とターゲット・ロケーション・サーバ５２６とによってサービスされ得る。ソース・サービング・ノード５１４は、ＭＭＥ１４２、またはＳＧＳＮ１３６、またはＭＳＣ１３２、またはＭＳＣサーバ１３４であり得る。ターゲット・サービング・ノード５２４は、ＭＭＥ１４２、またはＳＧＳＮ１３６、またはＭＳＣ１３２、またはＭＳＣサーバ１３４であり得る。ソース・ロケーション・サーバ５１６は、コントロール・プレーン・ロケーション・ソリューションのためのＧＭＬＣ１３８またはＧＭＬＣ１４８であり得る。ターゲット・ロケーション・サーバ５２６は、（ｉ）コントロール・プレーン・ロケーション・ソリューションのためのＧＭＬＣ１３８またはＧＭＬＣ１４８、或いは（ｉｉ）ユーザ・プレーン・ロケーション・ソリューションのためのＥ−ＳＬＰ１５８であり得る。
【００５１】
第３の方式では、ソース・サービング・ノード５１４は、ハンドオーバが開始したときにソース・ロケーション・サーバ５１６の識別情報をターゲット・サービング・ノード５２４に転送し得る（ステップ１）。この転送は、ソース・サービング・ノード５１４によってターゲット・サービング・ノード５２４に送信される第１のメッセージにおいて行われ得る。このメッセージは、（ｉ）３ＧＰＰ ＰＳ−ｔｏ−ＰＳハンドオーバの場合はＧＰＲＳトンネリングプロトコル（ＧＴＰ）フォワードリロケーション要求（Forward Relocation Request）メッセージ、または（ｉｉ）Ｅ−ＵＴＲＡＮからＵＴＲＡＮ／ＧＥＲＡＮへのＳＲＶＣＣハンドオーバの場合はＳＲＶＣＣ ＰＳ−ｔｏ−ＣＳ要求メッセージ、または（ｉｉｉ）何らかの他のメッセージであり得る。
【００５２】
次いで、ターゲット・サービング・ノード５２４は、ハンドオーバが完了した後に、（ステップ１において受信したソース・ロケーション・サーバ識別情報に基づいて）ターゲット・サービング・ノード５２４の識別情報とＵＥ１１０の識別情報とをソース・ロケーション・サーバ５１６に転送し得る（ステップ２）。この転送は、ターゲット・サービング・ノード５２４がＳＧＳＮ１３６またはＭＳＣサーバ１３４である場合はＭＡＰ ＳＬＲメッセージを用いて、或いはターゲット・サービング・ノード５２４がＭＭＥ１４２である場合は何らかの他のメッセージを用いて達成され得る。
【００５３】
ソース・ロケーション・サーバ５１６が、呼記録を維持しており、ソース・ロケーション・サーバ５１６がターゲット・ロケーション・サーバとなると判断することができる場合、後続のステップはスキップされ得る。他の場合、ソース・ロケーション・サーバ５１６は、ハンドオーバに関する情報を用いてＬＲＦ１７０を更新し、例えば、ＵＥ識別情報とターゲット・サービング・ノード識別情報とを与え得る（ステップ３）。ＬＲＦ１７０はターゲット・ロケーション・サーバ５２６を判断し得る。ターゲット・ロケーション・サーバ５２６がソース・ロケーション・サーバ５１６とは異なる場合、ＬＲＦ１７０は、ＵＥ１１０とターゲット・サービング・ノード５２４とに関する情報をターゲット・ロケーション・サーバ５２６に供給し得る（ステップ４）。次いで、ＬＲＦ１７０は、ソース・ロケーション・サーバ５１６がターゲット・ロケーション・サーバ５２６とは異なる場合、ソース・ロケーション・サーバ５１６を除去し得る（ステップ５）。
【００５４】
図６に、例えば、緊急呼の、ハンドオーバ後にＵＥ１１０のロケーション連続性を維持するための第４の方式の設計を示す。第４の方式は、Ｅ−ＳＣＣ ＡＳ（例えば、Ｅ−ＳＣＣ ＡＳ１５６）によってＳＲＶＣＣサポートが与えられているときに３ＧＰＰ ＰＳ ＲＡＴと３ＧＰＰ ＣＳ ＲＡＴとの間のハンドオーバに使用され得る。ＣＳ側ではコントロール・プレーン・ロケーション・ソリューションが使用され得、ＰＳ側ではコントロール・プレーン・ロケーション・ソリューションまたはユーザ・プレーン・ロケーション・ソリューションのいずれかが使用され得る。図６に示すように、ＵＥ１１０は、第１のＲＡＮ６１２と通信し、ハンドオーバより前にソース・サービング・ノード６１４とソース・ロケーション・サーバ６１６とによってサービスされ得る。ＵＥ１１０は、第２のＲＡＮ６２２と通信し、ハンドオーバ後にターゲット・サービング・ノード６２４とターゲット・ロケーション・サーバ６２６とによってサービスされ得る。ソース・サービング・ノード６１４は、ＭＭＥ１４２、またはＳＧＳＮ１３６、またはＭＳＣ１３２、またはＭＳＣサーバ１３４であり得る。ターゲット・サービング・ノード６２４は、ＭＭＥ１４２、またはＳＧＳＮ１３６、またはＭＳＣ１３２、またはＭＳＣサーバ１３４であり得る。ソース・ロケーション・サーバ６１６は、コントロール・プレーン・ロケーション・ソリューションのためのＧＭＬＣ１３８またはＧＭＬＣ１４８であり得る。ターゲット・ロケーション・サーバ６２６は、コントロール・プレーン・ロケーション・ソリューションのためのＧＭＬＣ１３８またはＧＭＬＣ１４８であり得る。ソース・ロケーション・サーバ６１６またはターゲット・ロケーション・サーバ６２６のいずれかは、ユーザ・プレーン・ロケーション・ソリューションのためのＥ−ＳＬＰ１５８であり得る。
【００５５】
第４の方式では、ターゲット・サービング・ノード６２４は、ソースＲＡＮからターゲットＲＡＮに無線接続を転送するための（ＴＳ２３．２１６及びＴＳ２３．２３７において定義された）ＳＲＶＣＣハンドオーバ・プロシージャの一部としてＥ−ＳＣＣ ＡＳ１５６にメッセージを送信し得る（ステップ１）。このメッセージは、ＳＩＰ ＩＮＶＩＴＥメッセージまたはＭＧＣＦを介して送信されたＩＳＤＮユーザパート初期アドレスメッセージ（ISDN User Part Initial Address Message）（ＩＳＵＰ ＩＡＭ）メッセージであり得る。ターゲット・サービング・ノード６２４は、その識別情報をこのメッセージ中に含め得る。そのメッセージがＩＳＵＰ ＩＡＭである場合、北米におけるネットワークのためのターゲット・サービング・ノード識別情報を搬送するためにＩＳＵＰ ＩＡＭ中の既存のＥＳＲＫまたはＥＳＲＤパラメータが使用され得る。次いで、Ｅ−ＳＣＣ ＡＳ１５６は、緊急呼のリモートレグを更新するために、ターゲット・サービング・ノード識別情報を含むＳＩＰ ＩＮＶＩＴＥメッセージをＥ−ＣＳＣＦ１５４に送信し得る（ステップ２）。Ｅ−ＣＳＣＦ１５４は、ターゲット・サービング・ノード６２４の識別情報を受信し得、この識別情報をＬＲＦ１７０に供給し得る（ステップ３）。ＬＲＦ１７０は、ＵＥ１１０とターゲット・サービング・ノード６２４とについての情報を用いてターゲット・ロケーション・サーバ６２６を判断し、更新し得る（ステップ４）。ＬＲＦ１７０はまた、ソース・ロケーション・サーバ６１６がターゲット・ロケーション・サーバ６２６とは異なる場合、ソース・ロケーション・サーバ６１６を除去し得る（ステップ５）。
【００５６】
図３〜図６は、ターゲット・サービング・ノードの識別情報をソース・ロケーション・サーバまたはターゲット・ロケーション・サーバに転送することによってＵＥ１１０のロケーション連続性が維持され得る、４つの例示的な方式を示している。第１の方式では、ターゲット・サービング・ノードは、その識別情報をターゲット・ロケーション・サーバに送信し得る。第２の方式では、ソース・サービング・ノードは、ターゲット・サービング・ノード識別情報をソース・ロケーション・サーバに送信し得る。第３の方式では、ターゲット・サービング・ノードは、その識別情報をソース・ロケーション・サーバに送信し得る。第４の方式では、ターゲット・サービング・ノードは、その識別情報をＥ−ＳＣＣ ＡＳに送信し得、そのターゲット・サービング・ノード識別情報はターゲット・ロケーション・サーバにフォワーディングされ得る。ターゲット・サービング・ノード識別情報をソース・ロケーション・サーバまたはターゲット・ロケーション・サーバに（直接または間接的に）転送するための他の方式も実装され得る。すべての方式について、ターゲット・サービング・ノード識別情報は、ＬＲＦ１７０とＵＥ１１０との間にロケーション・セッションを確立してＵＥ１１０のロケーション連続性を維持するために使用され得る。
【００５７】
図７に、ハンドオーバ後にＵＥ１１０のロケーション連続性を維持するためのメッセージ・フロー７００の設計を示す。メッセージ・フロー７００は様々なタイプの呼に使用され得る。ただし、以下の説明では、ＵＥ１１０が緊急呼を有すると仮定する。
【００５８】
ＵＥ１１０は、緊急呼を発信したいという要求を受信し得、緊急接続を確立し得る（ステップ１）。緊急接続は、（ｉ）ＴＳ２３．４０１に記載されているＥ−ＵＴＲＡＮアクセスのための緊急ＰＤＮ接続、または（ｉｉ）ＴＳ２３．０６０に記載されているＵＴＲＡＮ ＰＳアクセスのための緊急ＰＤＰコンテキスト、または（ｉｉｉ）何らかの他のタイプの接続であり得る。次いで、ＵＥ１１０は、ＴＳ２３．１６７に記載されているように、ＩＭＳ緊急呼を確立し得る（同じくステップ１）。緊急呼確立中に、ＬＲＦ１７０は、緊急呼をサービスするために割り当てられ得、ＵＥ１１０のためにロケーション・サーバ７１６（例えば、ＧＭＬＣ１３８または１４８）が選択され得る。
【００５９】
後で、サービング・ノード７１４（例えば、ＭＭＥ１４２またはＳＧＳＮ１３６）は、ＵＥ１１０のロケーションの要求をロケーション・サーバ７１６から受信し得る（ステップ２）。この要求は、国際モバイル加入者識別情報（International Mobile Subscriber Identity）（ＩＭＳＩ）、または移動局国際加入者ディレクトリ番号（Mobile Station International Subscriber Directory Number）（ＭＳＩＳＤＮ）、または国際モバイル機器識別情報（International Mobile Equipment Identity）（ＩＭＥＩ）であり得る、ＵＥ１１０の識別情報を含み得る。ステップ２における上記要求がサービング・ノード７１４によって受信された場合、またはネットワーク開始型ロケーション要求（Network Initiated Location Request）（ＮＩ−ＬＲ）ロケーションプロシージャのサポートが必要とされる場合、サービング・ノード７１４は、ＵＥ１１０のロケーションを取得するために（例えば、サービングＲＮＣまたはＥ−ＳＭＬＣとともに）ロケーション・セッションを開始し得る（ステップ３）。
【００６０】
サービング・ノード７１４は、ＵＥ１１０を現在サービスしているソースＲＡＮからターゲットＲＡＮへのＵＥ１１０のハンドオーバの要求を受信し得る（ステップ４）。ＵＥ１１０は、Ｅ−ＵＴＲＡＮ中のサービングｅＮＢから、またはＵＴＲＡＮ中のサービングＲＮＣから、または何らかの他のＲＡＮ中の何らかの他のネットワーク・エンティティから、ハンドオーバされ得る。ＵＥ１１０は、Ｅ−ＵＴＲＡＮへのハンドオーバの場合はターゲットｅＮＢに、或いはＵＴＲＡＮ ＰＳへのハンドオーバの場合はターゲットＲＮＣに、或いはＵＴＲＡＮ ＣＳまたはＧＥＲＡＮ ＣＳへのハンドオーバの場合はターゲットＭＳＣサーバに、或いは１ｘＲＴＴへのハンドオーバの場合は１ｘＲＴＴ ＭＳＣに関連するターゲットセルに、或いはＨＲＰＤへのハンドオーバの場合はターゲットセルに、ハンドオーバされ得る。上記ハンドオーバに関して、サービング・ノード７１４はソース・サービング・ノードと呼ばれることがあり、ロケーション・サーバ７１６はソース・ロケーション・サーバと呼ばれることがある。Ｅ−ＵＴＲＡＮ、ＵＴＲＡＮ ＰＳ、ＵＴＲＡＮ ＣＳ、またはＧＥＲＡＮ ＣＳへのハンドオーバの場合、ソース・サービング・ノード７１４は、ＴＳ２３．４０１、ＴＳ２３．０６０、またはＴＳ２３．２１６に記載されているように、ハンドオーバ要求メッセージをターゲット・サービング・ノード７２４に送信し得る（ステップ５）。Ｅ−ＵＴＲＡＮから１ｘＲＴＴへのハンドオーバの場合、ソース・サービング・ノード７１４は、ＴＳ２３．２１６に記載されているように、ハンドオーバ要求メッセージをターゲット１ｘＲＴＴ ＩＷＳに送信し得る。Ｅ−ＵＴＲＡＮからＨＲＰＤへのハンドオーバの場合、ステップ５はスキップされ得る。ＴＳ２３．４０１、ＴＳ２３．４０２、ＴＳ２３．０６０、またはＴＳ２３．２１６に記載されているように、ハンドオーバ準備及び実行プロシージャが実行され得る（ステップ６）。
【００６１】
ステップ３において開始されたロケーション・セッションは、通常、ステップ６が完了する前に終了し得る。ロケーション・セッションがステップ６の前に終了しない場合、ソース・サービング・ノード７１４は、ステップ６を完了した後にロケーション・セッションをアボートし得る（ステップ７）。これにより、ＵＥ１１０のロケーション推定値がソース・サービング・ノード７１４に供給され得る。
【００６２】
ステップ２が行われた場合、ソース・サービング・ノード７１４は加入者ロケーション応答供給（Provide Subscriber Location Response）メッセージをソース・ロケーション・サーバ７１６に返し得る（ステップ８ａ）。このメッセージは、ＵＥ１１０のロケーション推定値とターゲット・サービング・ノード７２４の識別情報とを含み得る。そのメッセージ中にターゲット・サービング・ノード識別情報が含まれるか否かは、ソース・サービング・ノード７１４における構成情報に基づいて決定され得る。この構成情報は、ソース・サービング・ノード識別情報及びターゲット・サービング・ノード識別情報、ＵＥ（例えば、ＵＥ１１０）のロケーション機能、ＵＥがローミングしているか否か、などを含み得る。
【００６３】
ステップ２及び８ａが行われなかった場合、ソース・サービング・ノード７１４は、ＵＥ１１０の識別情報、ターゲット・サービング・ノード７２４の識別情報、ハンドオーバを示すイベント・タイプ、ＵＥ１１０のロケーション推定値などを含み得る、加入者ロケーション報告メッセージをソース・ロケーション・サーバ７１６に送信し得る（ステップ８ｂ）。ステップ８ｂが行われるか否かは、ソース・サービング・ノード７１４における構成情報に依存し得る。ソース・ロケーション・サーバ７１６は、ソース・サービング・ノード７１４から加入者ロケーション報告メッセージが受信された場合、その加入者ロケーション報告メッセージに肯定応答し得る（ステップ９）。
【００６４】
ステップ６におけるハンドオーバが完了した後に、ターゲット・サービング・ノード７２４は、ＵＥ１１０の識別情報、ターゲット・サービング・ノード７２４の識別情報、ハンドオーバを示すイベント・タイプなどを含み得る、加入者ロケーション報告メッセージをターゲット・ロケーション・サーバ７２６（例えば、ＧＭＬＣ１３８または１４８）に送信し得る（ステップ１０）。ターゲット・サービング・ノード７２４は、その構成情報からターゲット・ロケーション・サーバ７２６のアドレスを判断し得る。ステップ１０が行われるか否かは、ターゲット・サービング・ノード７２４における構成情報に基づいてターゲット・サービング・ノード７２４によって決定され得る。この構成情報は、ソース・サービング・ノード識別情報及びターゲット・サービング・ノード識別情報、ＵＥ（例えば、ＵＥ１１０）のロケーション機能、ＵＥがローミングしているか否か、などを含み得る。効率及び信頼性のために、その構成情報は、ソース・サービング・ノード７１４とターゲット・サービング・ノード７２４とにおいて使用される場合、ステップ８ａまたはステップ８ｂが行われた場合はステップ１０が行われないことを保証すべきであり、その逆も同様である。ターゲット・ロケーション・サーバ７２６はターゲット・サービング・ノード７２４からの加入者ロケーション報告メッセージに肯定応答し得る（ステップ１１）。
【００６５】
以下で表５において説明するように、ＬＲＦ１７０と、ソース・ロケーション・サーバ７１６と、ターゲット・ロケーション・サーバ７２６との再構成が行われ得る（ステップ１２）。その再構成は、ソース・ロケーション・サーバ７１６の除去と、ターゲット・ロケーション・サーバ７２６の割当てと、ＬＲＦ１７０、ソース・ロケーション・サーバ７１６、及び／またはターゲット・ロケーション・サーバ７２６における情報の更新とを含み得る。
【００６６】
その後、ハンドオーバが行われた後にＬＲＦ１７０がＵＥ１１０のロケーション推定値を必要とする場合、ＬＲＦ１７０はターゲット・ロケーション・サーバ７２６を介してＭＴ−ＬＲロケーションプロシージャを推進し得る（ステップ１３）。これは、ターゲット側でのステップ２の繰り返しを必要とし得る。また、ステップ２〜１２は、前のハンドオーバがＥ−ＵＴＲＡＮまたはＵＴＲＡＮ ＰＳのいずれかへのハンドオーバであった場合、ＵＥ１１０の別のハンドオーバをサポートするためにターゲット側で繰り返され得る。
【００６７】
表５に、異なるハンドオーバ・シナリオにおいてＵＥ１１０のロケーション連続性を維持するために様々なネットワーク・エンティティによって実行されるアクションを記載する。表５において、第１の列には、ソース側で使用されるアクセスタイプとロケーション・ソリューションとが与えられている。第２の列には、ターゲット側で使用されるアクセスタイプとロケーション・ソリューションとが与えられている。第３の列には、各ハンドオーバ・シナリオについて様々なネットワーク・エンティティによって実行されるアクションが記載されている。表５に示す、すべてのハンドオーバ・シナリオについて、最初に緊急呼に割り当てられたＬＲＦは、ＰＳＡＰへの影響を回避するためにハンドオーバ後に保持され得る。ただし、表５において説明するように、ハンドオーバ後に他のロケーション・サーバの変更（例えば、ＧＭＬＣの追加または除去）が行われ得る。
【表５−１】
【表５−２】
【００６８】
注１：イントラＥ−ＵＴＲＡＮハンドオーバ、イントラＵＴＲＡＮ ＰＳハンドオーバ、及びインターＲＡＴハンドオーバの場合、ロケーション・ソリューションは変更され得る。
【００６９】
表５中の第１のハンドオーバ・シナリオでは、ステップ（ａ）におけるソース・サービング・ノードによる転送は、図７中のメッセージ・フロー７００中のステップ８ａまたは８ｂにおいて実行され得る。ステップ（ｂ）におけるターゲット・サービング・ノードによる転送は、メッセージ・フロー７００中のステップ１０において実行され得る。ＬＲＦの更新及びソース・ロケーション・サーバの交換は、メッセージ・フロー７００中のステップ１２において実行され得る。表５中のステップとメッセージ・フロー７００中のステップとの間の同様のマッピングは、表５中の他のハンドオーバ・シナリオに適用され得る。
【００７０】
表５に示すように、メッセージ・フロー７００は、異なるＲＡＴのＲＡＮ間のハンドオーバに使用され得る。メッセージ・フロー７００はまた、同じＲＡＴのＲＡＮ間のハンドオーバに使用され得、例えば、Ｅ−ＵＴＲＡＮからＥ−ＵＴＲＡＮへのハンドオーバ、またはＵＴＲＡＮ ＰＳからＵＴＲＡＮ ＰＳへのハンドオーバなどに使用され得る。同じＲＡＴのＲＡＮ間のハンドオーバは、基地局及び場合によっては他のネットワーク・エンティティ（例えば、ＲＮＣ）の変更と、サービング・ノード（例えば、ＭＭＥまたはＳＧＳＮ）の変更とを意味し得るが、各ネットワーク・エンティティのタイプは同じままである。
【００７１】
ＨＲＰＤへのハンドオーバが行われる場合、ターゲット側でＳＵＰＬが使用され得る。その場合は、ソース側でコントロール・プレーン・ロケーション・ソリューションが使用された場合、ソース側更新が実行され得る。
【００７２】
Ｅ−ＳＬＰ１５８はターゲット・サービング・ノード識別情報を受信することができないことがある。Ｅ−ＳＬＰ１５８は、他のロケーション・サーバの更新に基づいて、ＬＲＦ１７０によって割り当てられ、除去され得る。
【００７３】
確立されたＩＭＳ緊急呼またはまだ確立されていないＩＭＳ緊急呼のためのＩＰベアラのハンドオーバは、ＰＳ領域内で、例えば、イントラＥ−ＵＴＲＡＮ、イントラＵＴＲＡＮ、Ｅ−ＵＴＲＡＮからＵＴＲＡＮへ、ＵＴＲＡＮからＥ−ＵＴＲＡＮへ、またはＥ−ＵＴＲＡＮからＨＲＰＤへ、行われ得る。すでに確立されたＩＭＳ緊急呼のハンドオーバはまた、ＴＳ２３．２１６に記載されているように、ＳＲＶＣＣを使用してＰＳ領域からＣＳ領域へ行われ得る。ソース側で緊急呼のロケーションサポートが必要とされる状況でそのようなイベントが起こると、ターゲット側ではロケーション・サービスの連続性が必要とされ得る。この場合、ソース側及びターゲット側で採用されるロケーション・ソリューションは、同じままであるか、または変わり得る。さらに、ロケーション・ソリューションが変わるか否かにかかわらず、関連する（１つまたは複数の）ロケーション・サーバ（例えば、ＧＭＬＣ、ＬＲＦ、Ｅ−ＳＬＰ）の何らかの再構成が実行され得る。
【００７４】
上記の説明の大部分では、ネットワーク事業者が１つのＬＲＦを採用して緊急呼をサポートする場合を仮定した。ネットワーク事業者は、複数のＬＲＦを採用して、異なる地理的領域においてＰＳＡＰの異なるグループとインターフェースし、及び／または負荷分散をサポートし得る。複数のＬＲＦが存在するときでも、ＬＲＦを除いては、コア・ネットワーク中のネットワーク・エンティティ（例えば、ＭＭＥ、ＳＧＳＮ、ＭＳＣ、及びＧＭＬＣ）に影響を及ぼすことなしにロケーション連続性が維持され得る。
【００７５】
１つの設計では、中央エンティティが、ある接続（例えば、緊急ＩＰ接続）を有する各ＵＥであって、コントロール・プレーン・ロケーション・ソリューションが必要とされ得る各ＵＥの現在のサービング・ノードの識別情報を維持し得る。中央エンティティは、物理的にＬＲＦの一部でもよく、ＬＲＦとは別個でもよい。中央エンティティは、中央ロケーション・レジスタ（ＣＬＲ）と呼ばれることがあり、１つまたは複数のＬＲＦが存在するときにＵＥのロケーション連続性をサポートし得る。
【００７６】
図８に、ＵＥ１１０が、コントロール・プレーン・ロケーション・ソリューションが各サービング・ノードのために使用される複数のハンドオーバに関与する例示的なシナリオ８００を示す。ＵＥ１１０は、ＰＤＮゲートウェイまたはＧＧＳＮ８５０を介して緊急ＩＰ接続（例えば、緊急ＰＤＰコンテキストまたは緊急ＰＤＮ接続）を確立し得る（ステップ１）。ＩＰ接続確立中に、ＵＥ１１０のサービング・ノード８１４（例えば、ＭＭＥまたはＳＧＳＮ）は、ＵＴＲＡＮ／ＧＥＲＡＮアクセスまたはＥ−ＵＴＲＡＮアクセスのためのＮＩ−ＬＲロケーションプロシージャを呼び出し得、ＮＩ−ＬＲロケーションプロシージャは、サービング・ノード８１４とＵＥ１１０との識別情報の更新をＭＡＰ ＳＬＲメッセージ中でロケーション・サーバ８１６（例えば、ＧＭＬＣ）に転送させ得る（ステップ２ａ）。次いで、ロケーション・サーバ８１６は、例えば、ＬＲＦへの更新と同様の方法で、更新をＣＬＲ８９０に転送し得る（ステップ２ｂ）。
【００７７】
１つの設計では、Ｅ−ＣＳＣＦ８５４は、（Ｅ−ＣＳＣＦ８５４に知られている場合）現在のサービングセルまたは現在のＵＥロケーションに基づいてすべての利用可能なＬＲＦの中からＬＲＦ８７０を選択し得、ＵＥ１１０のＩＭＳ緊急呼にＬＲＦ８７０を割り当て得る。この設計により、ＬＲＦを、ワイヤレス・ネットワークの特定の領域をサービスすることに限定することが可能になり得る。別の設計では、Ｅ−ＣＳＣＦ８５４は、サービング・ノード（例えば、ＭＭＥまたはＳＧＳＮ）に、固定の関連付けのないＬＲＦを動的に割り当て得る。この設計により、利用可能なＬＲＦがワイヤレス・ネットワーク中の負荷を共有することが可能になり得る。いずれの場合も、ＵＥ１１０は、ＩＭＳ緊急呼のためにＰＤＮゲートウェイ／ＧＧＳＮ８５０、Ｐ−ＣＳＣＦ８５２、Ｅ−ＣＳＣＦ８５４、及びＭＧＣＦ８５６を介してＰＳＡＰ８８０と通信し得る（ステップ３）。
【００７８】
ＵＥ１１０は、サービング・ノード８１４から新しいサービング・ノード８２４（例えば、ＭＭＥ、ＳＧＳＮ、またはＭＳＣサーバ）にハンドオーバされ得る（ステップ４）。図７中のメッセージ・フロー７００を使用して、サービング・ノード８２４とＵＥ１１０との識別情報の更新をソース側のロケーション・サーバ８１６（図８に図示せず）に、またはターゲット側のロケーション・サーバ８２６（例えば、ＧＭＬＣ）に転送し得る（ステップ５ａ）。更新を受信したロケーション・サーバは、更新をＣＬＲ８９０にフォワーディングし、次いで、ＣＬＲ８９０は、ＵＥ１１０の現在のサービング・ノードに関して通知され得る（ステップ５ｂ）。
【００７９】
ＵＥ１１０はサービング・ノード８２４から新しいサービング・ノード８３４にハンドオーバされ得る（ステップ６）。サービング・ノード８２４が、サービング・ノード８３４とＵＥ１１０との識別情報の更新をソース側のロケーション・サーバ８２６（図８に図示せず）に転送し得るか、または、サービング・ノード８３４が、この情報をターゲット側のロケーション・サーバ８３６（例えば、ＧＭＬＣ）に転送し得る（ステップ７ａ）。更新を受信したロケーション・サーバは、更新をＣＬＲ８９０にフォワーディングし得る（ステップ７ｂ）。
【００８０】
ＬＲＦ８７０は、ＵＥ１１０のＩＭＳ緊急呼のためにＥ−ＣＳＣＦ８５４によって割り当てられ得る。ＰＳＡＰ８８０は、ＵＥ１１０のロケーション推定値が望まれるときはいつでも、ロケーション要求をＬＲＦ８７０に送信し得る（ステップ８）。ＬＲＦ８７０は、その識別情報とＵＥ識別情報とともに問合せをＣＬＲ８９０に送信し得る（ステップ９）。ＣＬＲ８９０は、サービング・ノードの識別情報がある場合、ＵＥ１１０の最も現在のサービング・ノードの識別情報を返し得る（ステップ１０）。ＣＬＲ８９０は、ＬＲＦ８７０の識別情報を記憶し得る。ＣＬＲ８９０はまた、その後、新しいサービング・ノードへの緊急ＩＰ接続または緊急呼のいずれかのハンドオーバのためにロケーション・サーバから受信され得るＵＥ１１０のサービング・ノード識別情報の任意のさらなる更新をＬＲＦ８７０にフォワーディングし得る。ＣＬＲ８９０によるこの自動更新は、ＬＲＦ８７０がロケーション要求のためにＣＬＲ８９０に問合せを送信する必要を回避し得る。ＬＲＦ８７０はＣＬＲ８９０に呼がリリースされたときを通知し得、次いで、ＣＬＲ８９０は、サービング・ノード更新をＬＲＦ８７０にフォワーディングすることを停止し得る。ＬＲＦ８７０は、ＵＥ１１０のロケーション推定値を取得するために、ロケーション・サーバ８３６を介して、及びコントロール・プレーンソリューションが使用される場合サービング・ノード８３４を介してＵＥ１１０に対してＭＴ−ＬＲロケーションプロシージャを実行し得る（ステップ１１）。
【００８１】
図８に示す方式は、ＩＭＳ緊急呼をサポートしているＬＲＦが、常にＵＥの最も現在のサービング・ノードの識別情報を有することを保証し得る。コントロール・プレーン・ロケーション・ソリューションをこのサービング・ノードのために使用する必要があるときはいつでも、この情報はハンディーになり得る。本方式はまた、ＬＲＦが、コントロール・プレーン・ロケーション・ソリューションに関連するサービング・ノードから、ユーザ・プレーン・ロケーション・ソリューションのみが使用されるサービング・ノードへのいかなるハンドオフにも気づくようになる（そのようなハンドオーバのためのソース側の更新があり得るので）ことを保証し得る。コントロール・プレーン・ロケーション・ソリューションが使用され得る新しいサービング・ノードを用いてＣＬＲによって更新されるまで、ＬＲＦは、次いでＵＥのためにユーザ・プレーン・ロケーション・ソリューションを利用し得る。ＵＥの初期サービング・ノード（すなわち、最初に緊急ＩＰ接続を与えるサービング・ノード）がユーザ・プレーン・ロケーション・ソリューションのみをサポートする場合、ＮＩ−ＬＲロケーションプロシージャは、サービング・ノード（例えば、ＳＧＳＮまたはＭＭＥ）によって呼び出されないことがあり、したがって、ＣＬＲ及びＬＲＦは更新されないことがある。しかしながら、この場合、ＬＲＦは、サービングセルに関連するアクセスタイプからユーザ・プレーン・ロケーション・ソリューションの必要を判断することができ、コントロール・プレーン・ロケーション・ソリューションが使用され得るかまたは使用されなければならないサービング・ノード（例えば、ＳＲＶＣＣ ＭＳＣサーバ）の識別情報を用いてＣＬＲによって更新されるまで、この情報を使用し続けることができる。
【００８２】
図９に、サービング・ノードによってロケーション・サービスをサポートするためのプロセス９００の設計を示す。サービング・ノードは、第１のＲＡＮから第２のＲＡＮへのＵＥのハンドオーバの指示を受信する（ブロック９１２）。ＵＥは、ハンドオーバより前に第１のＲＡＮを介してソース・サービング・ノードによってサービスされ得、ハンドオーバ後に第２のＲＡＮを介してターゲット・サービング・ノードによってサービスされ得る。ハンドオーバ後に第２のＲＡＮを介してＵＥのロケーション・サービスをサポートするために、サービング・ノードは、ターゲット・サービング・ノードの識別情報をロケーション・サーバに送信する（ブロック９１４）。
【００８３】
第１のＲＡＮは第１のＲＡＴをサポートし得、第２のＲＡＮは第２のＲＡＴをサポートし得る。１つの設計では、第１のＲＡＴは第２のＲＡＴとは異なり得る。別の設計では、第１のＲＡＴは第２のＲＡＴと同じであり得る。
【００８４】
ハンドオーバが行われるとき、ＵＥは、緊急呼または何らかの他のタイプの呼を有し得る。１つの設計では、第１のＲＡＮ及び第２のＲＡＮがＰＳ呼をサポートし得、ＵＥはＰＳ−ｔｏ−ＰＳハンドオーバを実行し得る。別の設計では、第１のＲＡＮはＰＳ呼をサポートし得、第２のＲＡＮはＣＳ呼をサポートし得、ＵＥはＰＳ−ｔｏ−ＣＳハンドオーバを実行し得る。さらに別の設計では、第１のＲＡＮはＣＳ呼をサポートし得、第２のＲＡＮはＰＳ呼をサポートし得、ＵＥはＣＳ−ｔｏ−ＰＳハンドオーバを実行する。さらに別の設計では、第１のＲＡＮ及び第２のＲＡＮはＣＳ呼をサポートし得、ＵＥはＣＳ−ｔｏ−ＣＳハンドオーバを実行し得る。
【００８５】
１つの設計では、サービング・ノードはターゲット・サービング・ノードであり得、ロケーション・サーバはハンドオーバ後にＵＥのロケーション・サービスをサポートするターゲット・ロケーション・サーバであり得る。ターゲット・サービング・ノードは、ターゲット・サービング・ノードにおいて記憶された構成情報またはＤＮＳ問合せに基づいて、ターゲット・ロケーション・サーバを判断し得る。別の設計では、サービング・ノードは、ソース・サービング・ノードであり得、ロケーション・サーバは、ハンドオーバより前にＵＥのロケーション・サービスをサポートするソース・ロケーション・サーバであり得る。
【００８６】
ターゲット・サービング・ノードは、第２のＲＡＮとアクセスタイプとに依存し得る。例えば、ターゲット・サービング・ノードは、Ｅ−ＵＴＲＡＮのＭＭＥ、ＵＴＲＡＮ ＰＳのＳＧＳＮ、ＧＥＲＡＮまたは１ｘＲＴＴのＭＳＣ、ＵＴＲＡＮ ＣＳまたはＧＥＲＡＮのＭＳＣサーバ、または何らかの他のネットワーク・エンティティであり得る。ロケーション・サーバは、ＧＭＬＣ、ＭＰＣ、ＬＲＦ、または何らかの他のネットワーク・エンティティであり得る。Ｅ−ＳＬＰは、ソース側またはターゲット側のロケーション・サーバとして働き得るが、ロケーション・サーバからＬＲＦによって受信された更新に基づいてＬＲＦによって割り当てられ、除去され得る。
【００８７】
図１０に、ロケーション・サーバによってロケーション・サービスをサポートするためのプロセス１０００の設計を示す。ロケーション・サーバは、第１のＲＡＮから第２のＲＡＮへのハンドオーバを実行するＵＥのターゲット・サービング・ノードの識別情報を受信する（ブロック１０１２）。例えば、緊急呼のために、ＵＥは、ハンドオーバより前に第１のＲＡＮを介してソース・サービング・ノードによってサービスされ得、ハンドオーバ後に第２のＲＡＮを介してターゲット・サービング・ノードによってサービスされ得る。ロケーション・サーバは、ハンドオーバ前に、またはハンドオーバ後に、またはその両方にＵＥのロケーション・サービスをサポートする（ブロック１０１４）。ロケーション・サーバは、ターゲット・サービング・ノードの識別情報を用いてＬＲＦを更新する（ブロック１０１６）。
【００８８】
１つの設計では、ロケーション・サーバは、ハンドオーバ後にＵＥのロケーション・サービスをサポートするターゲット・ロケーション・サーバであり得る。ターゲット・ロケーション・サーバは、ターゲット・サービング・ノードからターゲット・サービング・ノードの識別情報を受信し得る。別の設計では、ロケーション・サーバは、ハンドオーバ前にＵＥのロケーション・サービスをサポートするソース・ロケーション・サーバであり得る。ソース・ロケーション・サーバは、ソース・サービング・ノードからターゲット・サービング・ノードの識別情報を受信し得る。
【００８９】
図１１に、ＬＲＦによってロケーション・サービスをサポートするためのプロセス１１００の設計を示す。ＬＲＦは、第１のＲＡＮから第２のＲＡＮへのハンドオーバを実行するＵＥのターゲット・サービング・ノードの識別情報を受信する（ブロック１１１２）。ＵＥは、ハンドオーバより前に第１のＲＡＮを介してソース・サービング・ノードによってサービスされ得、ハンドオーバ後に第２のＲＡＮを介してターゲット・サービング・ノードによってサービスされ得る。ＬＲＦは、ハンドオーバ前及び後にＵＥの緊急呼をサポートし得る。ＬＲＦは、ハンドオーバ後にＵＥのロケーション・サービスをサポートするためのターゲット・ロケーション・サーバを判断する（ブロック１１１４）。ＬＲＦは、ターゲット・サービング・ノード識別情報、ＬＲＦにおいて記憶された構成情報、及び／または他の情報に基づいてターゲット・ロケーション・サーバを判断し得る。ソース・ロケーション・サーバがターゲット・ロケーション・サーバとは異なる場合、ＬＲＦは（ハンドオーバより前にＵＥのロケーション・サービスをサポートし得る）ソース・ロケーション・サーバをターゲット・ロケーション・サーバと交換する（ブロック１１１６）。ＬＲＦは、その後ターゲット・サービング・ノードの識別情報に基づいてＵＥのロケーション・セッションを開始する（ブロック１１１８）。
【００９０】
１つの設計では、ＬＲＦは、ターゲット・ロケーション・サーバからターゲット・サービング・ノードの識別情報を受信し得る。別の設計では、ＬＲＦは、ソース・ロケーション・サーバからターゲット・サービング・ノードの識別情報を受信し得る。この設計では、ＬＲＦは、ソース・ロケーション・サーバからＵＥの識別情報を受信し得、ＵＥ識別情報をターゲット・ロケーション・サーバに転送し得る。
【００９１】
図１２に、ＵＥによってロケーション・サービスを取得するためのプロセス１２００の設計を示す。ＵＥは、第１のＲＡＮから第２のＲＡＮへのハンドオーバを実行する（ブロック１２１２）。ＵＥは、ハンドオーバより前に第１のＲＡＮを介してソース・サービング・ノードによってサービスされ得、ハンドオーバ後に第２のＲＡＮを介してターゲット・サービング・ノードによってサービスされ得る。緊急呼または何らかの他のタイプの呼のために、ＵＥは、ハンドオーバより前に第１のＲＡＮと通信し、ハンドオーバ後に第２のＲＡＮと通信し得る。ハンドオーバ後にＵＥのロケーション・サービスをサポートするために、ターゲット・サービング・ノードの識別情報がハンドオーバ中にロケーション・サーバに送信され得る。ＵＥは、ハンドオーバ前に第１のＲＡＮを介してロケーション・サービスを取得する（ブロック１２１４）。ＵＥは、ハンドオーバ後に第２のＲＡＮを介してロケーション・サービスを取得する（ブロック１２１６）。ＵＥは、ターゲット・サービング・ノードの識別情報に基づいて、ハンドオーバ後に開始されるロケーション・セッションに関与する（ブロック１２１８）。
【００９２】
ＵＥはＰＳＡＰを用いた緊急呼を有し得、その呼は第１のＲＡＮから第２のＲＡＮにハンドオーバされ得る。ＵＥは、例えば、ハンドオーバ前または後に、ＵＥのロケーション推定値を取得するために、ロケーション・セッションに関与し得る。この場合、ＵＥはロケーション・サービスを取得したと考えられ得、それはＵＥのためにＰＳＡＰへのＵＥのロケーション推定値の転送を伴うことがある。
【００９３】
１つの設計では、ＵＥは、ハンドオーバより前にコントロール・プレーン・ロケーション・ソリューション（例えば、ＴＳ２３．２７１またはＪ−ＳＴＤ−０３６Ｂ）を介してロケーション・サービスを取得し、ハンドオーバ後にコントロール・プレーン・ロケーション・ソリューションを介してロケーション・サービスを取得し得る。別の設計では、ＵＥは、ハンドオーバより前にコントロール・プレーン・ロケーション・ソリューションを介してロケーション・サービスを取得し、ハンドオーバ後にユーザ・プレーン・ロケーション・ソリューション（例えば、ＳＵＰＬ）を介してロケーション・サービスを取得し得る。さらに別の設計では、ＵＥは、ハンドオーバより前にユーザ・プレーン・ロケーション・ソリューションを介してロケーション・サービスを取得し、ハンドオーバ後にコントロール・プレーン・ロケーション・ソリューションを介してロケーション・サービスを取得し得る。
【００９４】
図１３に、ＵＥ１１０、ＲＡＮ１１２、サービング・ノード１１４、ロケーション・サーバ１１６、及びＬＲＦ１７０の設計のブロック図を示す。ＲＡＮ１１２は、ＵＴＲＡＮ、Ｅ−ＵＴＲＡＮ、ＧＥＲＡＮ、１ｘＲＴＴ ＲＡＮ、ＨＲＰＤ ＲＡＮ、または何らかの他のＲＡＮであり得る。サービング・ノード１１４は、ＭＭＥ、ＳＧＳＮ、ＭＳＣ、ＭＳＣサーバ、または何らかの他のネットワーク・エンティティであり得る。ロケーション・サーバ１１６は、ＧＭＬＣ、ＭＰＣ、Ｅ−ＳＬＰ、または何らかの他のネットワーク・エンティティであり得る。簡単のために、図１３に（ｉ）ＵＥ１１０について１つコントローラ／プロセッサ１３１０、１つのメモリ１３１２、及び１つの送信機／受信機（ＴＭＴＲ／ＲＣＶＲ）１３１４、（ｉｉ）ＲＡＮ１１２について１つのコントローラ／プロセッサ１３２０、１つのメモリ１３２２、１つの送信機／受信機１３２４、及び１つの通信（Ｃｏｍｍ）ユニット１３２６、（ｉｉｉ）サービング・ノード１１４について１つのコントローラ／プロセッサ１３４０、１つのメモリ１３４２、及び１つの通信ユニット１３４４、（ｉｖ）ロケーション・サーバ１１６について１つのコントローラ／プロセッサ１３５０、１つのメモリ１３５２、及び１つの通信ユニット１３５４、ならびに（ｖ）ＬＲＦ１７０について１つのコントローラ／プロセッサ１３６０、１つのメモリ１３６２、及び１つの通信ユニット１３６４を示す。一般に、各エンティティは、任意の数のコントローラ、プロセッサ、メモリ、トランシーバ、通信ユニットなどを含み得る。
【００９５】
ダウンリンクでは、ＲＡＮ１１２中の基地局は、トラフィック・データ、メッセージ／シグナリング、及びパイロットをそれらのカバレージ・エリア内のＵＥに送信し得る。これらの様々なタイプのデータは、プロセッサ１３２０によって処理され、ダウンリンク信号を生成するために送信機１３２４によって調整され得、ダウンリンク信号はＵＥに送信され得る。ＵＥ１１０において、基地局からのダウンリンク信号は、受信され、受信機１３１４によって調整され、通信、ロケーション、及び他のサービスのための様々なタイプの情報を取得するためにプロセッサ１３１０によってさらに処理され得る。プロセッサ１３１０は、図１２中のプロセス１２００を実行し得る。メモリ１３１２及び１３２２は、それぞれＵＥ１１０及びＲＡＮ１１２のためのプログラムコード及びデータを記憶し得る。アップリンクでは、ＵＥ１１０は、トラフィック・データ、メッセージ／シグナリング、及びパイロットをＲＡＮ１１２中の基地局に送信し得る。これらの様々なタイプのデータは、プロセッサ１３１０によって処理され、アップリンク信号を生成するために送信機１３１４によって調整され得、アップリンク信号はＲＡＮ１１２に送信され得る。ＲＡＮ１１２において、ＵＥ１１０及び他のＵＥからのアップリンク信号は、受信機１３２４によって受信され、調整され、ＵＥによって送信された様々なタイプの情報を取得するために、プロセッサ１３２０によってさらに処理され得る。ＲＡＮ１１２は、通信ユニット１３２６を介して他のネットワーク・エンティティと通信し得る。
【００９６】
サービング・ノード１１４内で、プロセッサ１３４０は、ＵＥ１１０の通信及び他のサービスをサポートするための様々な機能を実行し得る。メモリ１３４２は、サービング・ノード１１４のプログラム・コード及びデータを記憶し得る。通信ユニット１３４４は、サービング・ノード１１４が他のネットワーク・エンティティと通信することを可能にし得る。プロセッサ１３４０は、図９中のプロセス９００を実行し得る。ロケーション・サーバ１１６内で、プロセッサ１３５０は、ロケーション・サーバ１１６のロケーション及び／または測位処理を実行し得る。メモリ１３５２は、ロケーション・サーバ１１６のプログラムコード及びデータを記憶し得る。通信ユニット１３５４は、ロケーション・サーバ１１６が他のエンティティと通信することを可能にし得る。プロセッサ１３５０は、図１０中のプロセス１０００を実行し得る。ＬＲＦ１７０内で、プロセッサ１３６０は、ＵＥのルーティング及びロケーションをサポートするための処理を実行し得る。メモリ１３６２は、ＬＲＦ１７０のプログラムコード及びデータを記憶し得る。通信ユニット１３６４は、ＬＲＦ１７０が他のネットワーク・エンティティと通信することを可能にし得る。プロセッサ１３６０は、図１１中のプロセス１１００を実行し得る。
【００９７】
情報及び信号は多種多様な技術及び技法のいずれかを使用して表され得ることを、当業者は理解されよう。例えば、上記の説明全体にわたって言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、及びチップは、電圧、電流、電磁波、磁界または磁性粒子、光場または光学粒子、或いはそれらの任意の組合せによって表され得る。
【００９８】
さらに、本明細書の開示に関連して説明した様々な例示的な論理ブロック、モジュール、回路、及びアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、または両方の組合せとして実装され得ることを、当業者は諒解されよう。ハードウェアとソフトウェアのこの互換性を明確に示すために、様々な例示的な構成要素、ブロック、モジュール、回路、及びステップを、上記では概してそれらの機能に関して説明した。そのような機能をハードウェアとして実装するか、ソフトウェアとして実装するかは、特定の適用例及び全体的なシステムに課せられた設計制約に依存する。当業者は、説明した機能を特定の適用例ごとに様々な方法で実装し得るが、そのような実装の決定は、本開示の範囲からの逸脱を生じるものと解釈すべきではない。
【００９９】
本明細書で説明する位置判断技法は、ワイヤレス・ワイドエリア・ネットワーク（ＷＷＡＮ）、ワイヤレス・ローカルエリア・ネットワーク（ＷＬＡＮ）、ワイヤレス・パーソナルエリア・ネットワーク（ＷＰＡＮ）などの様々なワイヤレス通信ネットワークに関連して実装され得る。「ネットワーク」及び「システム」という用語は、しばしば互換的に使用される。ＷＷＡＮは、符号分割多元接続（ＣＤＭＡ）ネットワーク、時間分割多元接続（ＴＤＭＡ）ネットワーク、周波数分割多元接続（ＦＤＭＡ）ネットワーク、直交周波数分割多元接続（ＯＦＤＭＡ）ネットワーク、シングル・キャリア周波数分割多元接続（ＳＣ−ＦＤＭＡ）ネットワーク、Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ（ＬＴＥ）ネットワーク、ＷｉＭＡＸ（ＩＥＥＥ８０２．１６）ネットワークなどであり得る。ＣＤＭＡネットワークは、ｃｄｍａ２０００、広帯域ＣＤＭＡ（Ｗ−ＣＤＭＡ）などの１つまたは複数の無線アクセス技術（ＲＡＴ）を実装し得る。ｃｄｍａ２０００は、ＩＳ−９５、ＩＳ−２０００、及びＩＳ−８５６規格を含む。ＴＤＭＡネットワークは、Global System for Mobile Communications（ＧＳＭ）、Digital Advanced Mobile Phone System（Ｄ−ＡＭＰＳ）、または何らかの他のＲＡＴを実装し得る。ＧＳＭ及びＷ−ＣＤＭＡは、「3rd Generation Partnership Project」（３ＧＰＰ）という名称の組織からの文書に記載されている。ｃｄｍａ２０００は、「3rd Generation Partnership Project 2」（３ＧＰＰ２）という名称の組織からの文書に記載されている。３ＧＰＰ及び３ＧＰＰ２の文書は公的に入手可能である。ＷＬＡＮは、ＩＥＥＥ８０２．１１ｘネットワークであり得、ＷＰＡＮは、Ｂｌｕｅｔｏｏｔｈ（登録商標）ネットワーク、ＩＥＥＥ８０２．１５ｘネットワーク、または他の何らかのタイプのネットワークであり得る。本技法はまた、ＷＷＡＮ、ＷＬＡＮ、及び／またはＷＰＡＮの任意の組合せに関して実装され得る。
【０１００】
衛星測位システム（ＳＰＳ）は、一般に、送信機から受信した信号に少なくとも部分的に基づいて地球上または地球上空のエンティティのロケーションをそれらのエンティティが判断できるように配置された送信機のシステムを含む。そのような送信機は、一般に、設定された数のチップの反復する擬似雑音（ＰＮ）コードでマークされた信号を送信し、地上ベースの制御局、ユーザ機器、及び／または宇宙ビークル上に配置され得る。特定の例では、そのような送信機は地球周回軌道衛星ビークル（ＳＶ）上に配置され得る。例えば、全地球測位システム（ＧＰＳ）、Galileo、Glonass、またはCompassなどの全地球航法衛星システム（ＧＮＳＳ）のコンスタレーション中のＳＶは、（例えば、ＧＰＳの場合のように各衛星について異なるＰＮコードを使用して、またはＧｌｏｎａｓｓの場合のように異なる周波数上の同じコードを使用して）コンスタレーション中の他のＳＶによって送信されたＰＮコードとは区別可能なＰＮコードでマーキングされた信号を送信し得る。いくつかの態様によれば、本明細書で提示した技法は、ＳＰＳについての全地球システム（例えば、ＧＮＳＳ）に限定されない。例えば、本明細書に記載する技法は、日本のQuasi-Zenith Satellite System（ＱＺＳＳ）、インドのIndian Regional Navigational Satellite System（ＩＲＮＳＳ）、中国のＢｅｉｄｏｕなどの様々な地域システム、及び／または１つまたは複数の全地球及び／または地域ナビゲーション衛星システムに関連付けられ得るか、または場合によってはそれらのシステムとともに使用することが可能な、様々なオーグメンテーション・システム（例えば、Satellite Based Augmentation System（ＳＢＡＳ））に適用され得るか、または場合によってはこれらのシステムとともに使用することが可能である。限定ではなく例として、ＳＢＡＳは、例えば、Wide Area Augmentation System（ＷＡＡＳ）、European Geostationary Navigation Overlay Service（ＥＧＮＯＳ）、Multi-functional Satellite Augmentation System（ＭＳＡＳ）、GPS Aided Geo Augmented NavigationまたはＧＰＳ及びGeo Augmented Navigation System（ＧＡＧＡＮ）など、完全性情報、差分補正などを与える（１つまたは複数の）オーグメンテーション・システムを含み得る。したがって、本明細書で使用するＳＰＳは、１つまたは複数のグローバルナビゲーション衛星システム及び／または領域ナビゲーション衛星システム、ならびに／或いは１つまたは複数のグローバル・オーグメンテーション・システム及び／または領域オーグメンテーション・システムの任意の組合せを含み得、ＳＰＳ信号は、ＳＰＳ信号、ＳＰＳ様の信号、及び／またはそのような１つまたは複数のＳＰＳに関連する他の信号を含み得る。
【０１０１】
本明細書で使用するＵＥは、セルラーまたは他のワイヤレス通信デバイス、パーソナル通信システム（ＰＣＳ）デバイス、パーソナル・ナビゲーション・デバイス（ＰＮＤ）、個人情報マネージャ（ＰＩＭ）、携帯情報端末（ＰＤＡ）、ラップトップ或いはワイヤレス通信及び／またはナビゲーション信号を受信することが可能な他の適切なモバイル・デバイスなどのデバイスを指す。また、「ユーザ機器」という用語は、衛星信号受信、支援データ受信、及び／または位置に関係する処理が当該デバイスで発生するかパーソナル・ナビゲーション・デバイス（ＰＮＤ）で発生するかにかかわらず、短距離ワイヤレス、赤外線、ワイヤライン接続、または他の接続などによってＰＮＤと通信するデバイスを含むものとする。また、「ユーザ機器」は、インターネット、Ｗｉ−Ｆｉ、フェムトセル、または他のネットワークなどを介してサーバとの通信が可能で、衛星信号受信、支援データ受信、及び／または位置に関係する処理が当該デバイスで発生するか、サーバで発生するか、またはネットワークに結び付いた別のデバイスで発生するかにかかわらず、ワイヤレス通信デバイス、コンピュータ、ラップトップなどを含むすべてのデバイスを含むものとする。上記の任意の動作可能な組合せも「ユーザ機器」と見なされる。
【０１０２】
本明細書で説明する方法／実装形態は、適用例に応じて様々な手段によって実装され得る。例えば、それらは、ハードウェア、ファームウェア、ソフトウェア、またはそれらの組合せで実装され得る。ハードウェアに関与する実装形態の場合、プロセッサは、１つまたは複数の特定用途向け集積回路（ＡＳＩＣ）、デジタル信号プロセッサ（ＤＳＰ）、デジタル信号処理デバイス（ＤＳＰＤ）、プログラマブル論理デバイス（ＰＬＤ）、フィールド・プログラマブル・ゲートアレイ（ＦＰＧＡ）、汎用プロセッサ、コントローラ、マイクロコントローラ、マイクロプロセッサ、状態機械、電子デバイス、本明細書で説明する機能を実行するように設計された他の電子ユニット、或いはそれらの組合せ、例えば、ＤＳＰコアと連携する１つまたは複数のマイクロプロセッサ、複数のマイクロプロセッサ、または任意の他の好適な構成を用いて実装され得る。
【０１０３】
ファームウェア及び／またはソフトウェアに関与する実装形態の場合、本方法は、本明細書で説明する機能を実行するモジュール（例えば、プロシージャ、機能など）を用いて実装され得る。命令を有形に実施するいずれの機械可読媒体も、本明細書で説明する方法の実装において使用され得る。例えば、ファームウェア／ソフトウェアコードは、メモリに記憶され、プロセッサ／コンピュータに機能を実行させるために、プロセッサ／コンピュータによって実行され得る。メモリは、プロセッサの内部またはプロセッサの外部に実装され得る。本明細書で使用する「メモリ」という用語は、長期メモリ、短期メモリ、揮発性メモリ、不揮発性メモリ、または他のメモリのいずれかのタイプを指し、メモリの特定のタイプまたはメモリの数、或いはメモリが記憶される媒体のタイプに限定されない。
【０１０４】
ファームウェア及び／またはソフトウェアで実装する場合、機能は、１つまたは複数の命令またはコードとしてコンピュータ可読媒体上に記憶され得る。例としては、データ構造で符号化されたコンピュータ可読媒体、及びコンピュータプログラムで符号化されたコンピュータ可読媒体がある。コンピュータ可読媒体は、コンピュータプログラム製品の形態をとり得る。コンピュータ可読媒体は物理的コンピュータ記憶媒体を含む。記憶媒体は、コンピュータによってアクセスできる任意の利用可能な媒体であり得る。限定ではなく、例として、そのようなコンピュータ可読媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭまたは他の光ディスク（disk）ストレージ、磁気ディスク（disk）ストレージ、半導体ストレージ、または他の記憶デバイス、或いは命令またはデータ構造の形態で所望のプログラムコードを記憶するために使用でき、コンピュータによってアクセスできる任意の他の媒体を備えることができ、本明細書で使用するディスク（disk）及びディスク（disc）は、コンパクトディスク（disc）（ＣＤ）、レーザディスク（disc）、光ディスク（disc）、デジタル多用途ディスク（disc）（ＤＶＤ）、フロッピー(登録商標）ディスク（disk）及びブルーレイディスク（disc）を含み、ディスク（disk）は、通常、データを磁気的に再生し、ディスク（disc）は、データをレーザで光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲内に含めるべきである。
【０１０５】
コンピュータ可読媒体上での記憶に加えて、命令及び／またはデータを通信装置中に含まれる伝送媒体上の信号として与え得る。例えば、通信装置は、命令とデータとを示す信号を有するトランシーバを含み得る。命令及びデータは、１つまたは複数のプロセッサに、特許請求の範囲で概説する機能を実装させるように構成される。すなわち、通信装置は、開示した機能を実行するための情報を示す信号をもつ伝送媒体を含む。初めに、通信装置中に含まれる伝送媒体は、開示した機能を実行するための情報の第１の部分を含み得、次に、通信装置中に含まれる伝送媒体は、開示した機能を実行するための情報の第２の部分を含み得る。
【０１０６】
本開示の前述の説明は、いかなる当業者でも本開示を作成または使用することができるように提供される。本開示への様々な修正が当業者には容易に理解されるであろうが、本明細書で定義した一般的な原理は、本開示の範囲から逸脱することなく他の変形形態に適用され得る。したがって、本開示は、本明細書で説明する例及び設計に限定されるものではなく、本明細書で開示する原理及び新規の特徴に合致する最も広い範囲を与えられるべきである。
【技術分野】
【０００１】
本開示は、一般に通信に関し、より詳細には、ユーザ機器（ＵＥ）のロケーション・サービスをサポートするための技法に関する。
【０００２】
米国特許法第１１９条に基づく優先権の主張
本特許出願は、以下の仮出願の優先権を主張する。
【０００３】
・２００９年２月９日に出願された「Location Continuity for Emergency Calls」と題する米国仮出願第６１／１５１，１２３号、
・２００９年２月１１日に出願された「Location Continuity for Emergency Calls」と題する米国仮出願第６１／１５１，７２６号、
・２００９年３月２３日に出願された「Location Continuity for Emergency Calls」と題する米国仮出願第６１／１６２，６０６号、
・２００９年３月２６日に出願された「Location Continuity for Emergency Calls」と題する米国仮出願第６１／１６３，６６４号、及び
・２００９年５月４日に出願された「Location Continuity for Emergency Calls」と題する米国仮出願第６１／１７５，４５２号。
【０００４】
上記に記載した仮出願のすべてが、本出願の譲受人に譲渡され、参照により本明細書に明確に組み込まれる。
【背景技術】
【０００５】
ワイヤレス通信ネットワークは、ボイス、ビデオ、パケットデータ、メッセージング、ブロードキャストなどの様々な通信サービスを提供するために広く展開されている。これらのワイヤレス・ネットワークは、利用可能なネットワークリソースを共有することによって複数のユーザをサポートすることが可能な多元接続ネットワークであり得る。そのような多元接続ネットワークの例には、符号分割多元接続（ＣＤＭＡ）ネットワーク、時分割多元接続（ＴＤＭＡ）ネットワーク、周波数分割多元接続（ＦＤＭＡ）ネットワーク、直交ＦＤＭＡ（ＯＦＤＭＡ）ネットワーク、及びシングル・キャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）ネットワークがある。
【０００６】
ＵＥは、呼、例えば、緊急呼のために、ワイヤレス・ネットワークと通信することがある。例えば、緊急要員が適切なロケーションにディスパッチされ得るように、呼中にＵＥのロケーションを判断することが望ましいことがある。ＵＥのロケーションは、ＵＥにロケーション・サービスを提供することができる１つまたは複数のネットワーク・エンティティからのサポートを用いて判断され得る。ＵＥは、モバイルであり得、呼中に、あるワイヤレス・ネットワークから別のワイヤレス・ネットワークにハンドオーバされ得る。ハンドオーバ後にＵＥのロケーション・サービスを維持することが望ましいことがある。
【発明の概要】
【０００７】
本明細書では、ハンドオーバ後にＵＥのロケーション連続性を維持するための技法について説明する。ロケーション連続性は、あるワイヤレス・ネットワークから別のワイヤレス・ネットワークへのハンドオーバ後にＵＥのロケーション・サービスをサポートし続ける能力を指す。ロケーション連続性は、例えば、緊急呼の場合に特に望ましいことがあり、それにより、ＵＥの初期ロケーション推定値及び／または更新されたロケーション推定値を、緊急呼をサービスするPublic Safety Answering Point（ＰＳＡＰ）に与えることができる。
【０００８】
ＵＥは、呼中に第１の無線アクセス・ネットワーク（ＲＡＮ）から第２のＲＡＮにハンドオーバされ得る。ＵＥは、第１のＲＡＮと通信し、ハンドオーバより前にソース・サービング・ノードとソース・ロケーション・サーバとによってサービスされ得る。ＵＥは、第２のＲＡＮと通信し、ハンドオーバ後にターゲット・サービング・ノードとターゲット・ロケーション・サーバとによってサービスされ得る。各ＲＡＮは、ＵＥの無線通信をサポートし得る。各サービング・ノードは、ＵＥの通信サービスをサポートし得る。各ロケーション・サーバは、ＵＥのロケーション・サービスをサポートし得る。
【０００９】
一態様では、ＵＥのハンドオーバ中にターゲット・サービング・ノードの識別情報またはアドレスをロケーション・サーバに転送することによって、ＵＥのロケーション連続性が維持され得る。１つの設計では、ターゲット・サービング・ノードは、その識別情報をターゲット・ロケーション・サーバに送信し得、次いで、ターゲット・ロケーション・サーバは、ＵＥをサービスするロケーション及びルーティング機能（ＬＲＦ）を更新し得る。パケット交換領域から回線交換領域へのハンドオーバに適用可能であり得る別の設計では、ソース・サービング・ノードはターゲット・サービング・ノードの識別情報をソース・ロケーション・サーバに送信し得、次いで、ソース・ロケーション・サーバはＬＲＦを更新し得る。どちらの設計についても、ＬＲＦは、必要な場合、ターゲット・サービング・ノード識別情報を使用して、ＵＥのロケーション・セッションを開始し得る。ＬＲＦは、ソース・ロケーション・サーバがターゲット・ロケーション・サーバとは異なる場合、ハンドオーバ後にそのソース・ロケーション・サーバを除去し得る。
【００１０】
本開示の様々な態様及び特徴について以下でさらに詳細に説明する。
【図面の簡単な説明】
【００１１】
【図１】異なるワイヤレス・ネットワークの例示的な展開を示す図。
【図２】異なるワイヤレス・ネットワークの例示的な展開を示す図。
【図３】ＵＥのロケーション連続性を維持するための方式を示す図。
【図４】ＵＥのロケーション連続性を維持するための方式を示す図。
【図５】ＵＥのロケーション連続性を維持するための方式を示す図。
【図６】ＵＥのロケーション連続性を維持するための方式を示す図。
【図７】ＵＥのロケーション連続性を維持するためのメッセージ・フローを示す図。
【図８】ＵＥの例示的なハンドオーバ・シナリオを示す図。
【図９】サービング・ノードによってロケーション・サービスをサポートするためのプロセスを示す図。
【図１０】ロケーション・サーバによってロケーション・サービスをサポートするためのプロセスを示す図。
【図１１】ＬＲＦによってロケーション・サービスをサポートするためのプロセスを示す図。
【図１２】ＵＥによってロケーション・サービスを取得するためのプロセスを示す図。
【図１３】ＵＥと様々なネットワーク・エンティティとのブロック図。
【発明を実施するための形態】
【００１２】
本明細書では、ハンドオーバ後にＵＥのロケーション連続性を維持するための技法について説明する。本技法は、「3rd Generation Partnership Project」（３ＧＰＰ）という名称の組織によって定義された３ＧＰＰワイヤレス・ネットワーク、及び「3rd Generation Partnership Project 2」（３ＧＰＰ２）という名称の組織によって定義された３ＧＰＰ２ワイヤレス・ネットワークなど、様々なワイヤレス・ネットワークに使用され得る。
【００１３】
本技法は、回線交換（ＣＳ）呼及びパケット交換（ＰＳ）呼など、様々なタイプの呼にも使用され得る。ＣＳ呼は、その持続時間全体にわたって、その呼に専用リソース（例えば、トラフィック・チャネル）が割り当てられる、呼である。ＰＳ呼は、共用リソースを使用してパケットにおいてデータが送信される、呼である。ワイヤレス・ネットワークは、ＣＳ呼のみ、またはＰＳ呼のみ、またはＣＳ呼とＰＳ呼の両方をサポートし得る。
【００１４】
本技法は、ユーザ・プレーン及びコントロール・プレーン・ロケーション・ソリューション／アーキテクチャにも使用され得る。ユーザ・プレーン・ロケーション・ソリューションは、ユーザ・プレーンを介してロケーション・サービスのためのメッセージを送信するロケーション・ソリューションである。ユーザ・プレーンは、上位レイヤ・アプリケーションのためのシグナリング及びデータを搬送し、ユーザ・プレーンベアラを採用するための機構であり、一般に、ユーザ・データグラム・プロトコル（ＵＤＰ）、伝送制御プロトコル（ＴＣＰ）、及びインターネット・プロトコル（ＩＰ）など、標準プロトコルを用いて実装される。コントロール・プレーン・ロケーション・ソリューションは、コントロール・プレーンを介してロケーション・サービスのためのメッセージを送信するロケーション・ソリューションである。コントロール・プレーンは、上位レイヤ・アプリケーションのためのシグナリングを搬送するための機構であり、一般に、ネットワーク固有のプロトコル、インターフェース、及びシグナリング・メッセージを用いて実装される。ロケーション・サービスをサポートするメッセージは、コントロール・プレーン・ロケーション・ソリューションではシグナリングの一部として搬送され、ユーザ・プレーン・ロケーション・ソリューションでは（ネットワークから見て）データの一部として搬送される。ただし、そのメッセージのコンテンツは、ユーザ・プレーン・ロケーション・ソリューションとコントロール・プレーン・ロケーション・ソリューションの両方において同じまたは同様であり得る。
【００１５】
表１に、いくつかの例示的なロケーション・ソリューションを記載する。セキュアユーザ・プレーン・ロケーション（ＳＵＰＬ）は、オープン・モバイル・アライアンス（ＯＭＡ）から公的に入手可能な文書に記載されている。ＴＳ２３．２７１及び他の「ＴＳ」文書は、３ＧＰＰから公的に入手可能である。ＡＮＳＩ Ｊ−ＳＴＤ−０３６は、米国規格協会（ＡＮＳＩ）から公的に入手可能な文書に記載されている。３ＧＰＰ２ Ｘ．Ｓ０００２は、３ＧＰＰ２から公的に入手可能な文書に記載されている。
【表１】
【００１６】
図１に、３ＧＰＰワイヤレス・ネットワーク１０２及び１０４の例示的な展開を示す。一般に、ワイヤレス・ネットワークは、（ｉ）無線通信をサポートすることができるＲＡＮと、（ｉｉ）様々な通信サービスをサポートすることができるコア・ネットワークとを含み得る。ＲＡＮは、アクセス・ネットワーク、無線ネットワークなどと呼ばれることもある。ワイヤレス・ネットワーク１０２は、ＲＡＮ１２２とコア・ネットワーク１３０とを含む。ワイヤレス・ネットワーク１０４は、ＲＡＮ１２４とコア・ネットワーク１４０とを含む。
【００１７】
ＲＡＮ１２２は、Wideband Code Division Multiple Access（ＷＣＤＭＡ）をサポートするUniversal Terrestrial Radio Access Network（ＵＴＲＡＮ）、またはGlobal System for Mobile Communications（ＧＳＭ（登録商標））とEnhanced Data rates for GSM Evolution（ＥＤＧＥ）とをサポートするGSM EDGE Radio Access Network（ＧＥＲＡＮ）、または何らかの他の無線アクセス技術（ＲＡＴ）をサポートするＲＡＮであり得る。ＲＡＮ１２４は、Long Term Evolution（ＬＴＥ）をサポートするEvolved UTRAN（Ｅ−ＵＴＲＡＮ）、または何らかの他のＲＡＴをサポートするＲＡＮであり得る。ＲＡＴは、無線技術、エアリンク・インターフェース、ワイヤレス・アクセス・タイプなどと呼ばれることもある。各ＲＡＮは、基地局及び／または他のネットワーク・エンティティを含み得る。基地局は、ノードＢ、進化型ノードＢ（ｅＮＢ）などと呼ばれることもある。例えば、ＵＴＲＡＮ１２２は、ノードＢと、ノードＢの協調及び制御を行い得る無線ネットワーク・コントローラ（ＲＮＣ）とを含み得る。Ｅ−ＵＴＲＡＮ１２４はｅＮＢを含み得る。
【００１８】
コア・ネットワーク１３０は、ＲＡＮ１２２と通信するＵＥの様々な通信サービスをサポートし得る。コア・ネットワーク１３０内で、モバイル交換センター（ＭＳＣ）１３２は、そのカバレージ・エリア内のＵＥのＣＳ呼のためのスイッチング及びシグナリング機能を実行し得る。ＭＳＣサーバ１３４は、そのカバレージ・エリア内のＵＥのＣＳ呼のためのシグナリング機能を実行し得る。サービングＧＰＲＳサポートノード（ＳＧＳＮ）１３６は、ＲＡＮ１２２と通信するＵＥのＰＳ接続及びセッションのための、シグナリング、スイッチング、及びルーティング機能を実行し得る。ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）１３７は、ＵＥのデータ接続性の維持、ＩＰアドレス割振り、ＩＰルーティングなど、様々な機能を実行し得る。サービング・モバイル・ロケーション・センター（ＳＭＬＣ）またはスタンドアロンＳＭＬＣ（ＳＡＳ）１２８は、ＲＡＮ１２２と通信するＵＥの測位をサポートし得る。測位とは、ターゲットＵＥの地理的ロケーションを判断する機能を指す。ゲートウェイ・モバイル・ロケーション・センター（ＧＭＬＣ）１３８は、ロケーション・サービスをサポートし、外部ロケーション・サービス（ＬＣＳ）クライアントとインターフェースし、加入者プライバシ、許可、認証、ビリングなどのサービスを提供するための、様々な機能を実行し得る。ＳＭＬＣ／ＳＡＳ１２８及びＧＭＬＣ１３８は、３ＧＰＰのためのコントロール・プレーン・ロケーション・ソリューション、例えば、ＴＳ２３．２７１をサポートし得る。
【００１９】
ワイヤレス・ネットワーク１０２はＰＳ呼及びＣＳ呼をサポートし得る。ＵＴＲＡＮ ＰＳの場合、ＰＳ呼は、ＵＴＲＡＮ１２２とＳＧＳＮ１３６とによってサポートされ得る。ＵＴＲＡＮ ＣＳの場合、ＣＳ呼は、ＵＴＲＡＮ１２２と、ＭＳＣ１３２またはＭＳＣサーバ１３４のいずれかとによってサポートされ得る。ＧＥＲＡＮ ＣＳの場合、ＣＳ呼は、ＧＥＲＡＮ１２２と、ＭＳＣ１３２またはＭＳＣサーバ１３４のいずれかとによってサポートされ得る。
【００２０】
コア・ネットワーク１４０は、ＲＡＮ１２４と通信するＵＥの様々な通信サービスをサポートし得る。コア・ネットワーク１４０内で、モビリティ管理エンティティ（ＭＭＥ）１４２は、モビリティ管理、ゲートウェイ選択、認証、ベアラ管理など、様々な制御機能を実行し得る。進化型ＳＭＬＣ（Ｅ−ＳＭＬＣ）１４４は、ＲＡＮ１２４と通信するＵＥの測位をサポートし得る。サービング・ゲートウェイ（Ｓ−ＧＷ）１４６は、データ・ルーティング及びフォワーディング、モビリティアンカリングなど、ＵＥのためのデータ転送に関係する様々な機能を実行し得る。パケット・データ・ネットワーク（ＰＤＮ）ゲートウェイ１５０は、ＵＥのデータ接続性の維持、ＩＰアドレス割振り、ＩＰルーティングなど、様々な機能を実行し得る。
【００２１】
ＧＭＬＣ１４８は、ＲＡＮ１２４と通信するＵＥのロケーション・サービスをサポートし得る。緊急ＳＵＰＬロケーション・プラットフォーム（Ｅ−ＳＬＰ）１５８は、ＳＵＰＬロケーション・センター（ＳＬＣ）、及び場合によってはＳＵＰＬ測位センター（ＳＰＣ）を含み得る。ＳＬＣは、ロケーション・サービスのための様々な機能を実行し、ＳＵＰＬの動作を協調させ、ＳＵＰＬ対応端末（ＳＥＴ）と対話し得る。ＳＰＣは、ＳＥＴの測位と、ＳＥＴへの支援データの配信とをサポートし得、また、位置計算に使用されるメッセージ及びプロシージャを担当し得る。ＧＭＬＣ１４８は、３ＧＰＰのためのコントロール・プレーン・ロケーション・ソリューション、例えば、ＴＳ２３．２７１をサポートし得る。Ｅ−ＳＬＰ１５８はＳＵＰＬをサポートし得る。所与の呼のために、ＲＡＮ１２４を介して、またはＲＡＮ１２２とＳＧＳＮ１３６とを介して、コントロール・プレーン・ロケーション・ソリューションまたはユーザ・プレーン・ロケーション・ソリューションのいずれかが選択され得る。
【００２２】
プロキシ呼セッション制御機能（Ｐ−ＣＳＣＦ）１５２及び緊急ＣＳＣＦ（Ｅ−ＣＳＣＦ）１５４は、ＩＰマルチメディア・サブシステム（ＩＭＳ）サービス、例えば、ボイスオーバーＩＰ（ＶｏＩＰ）をサポートし得る。Ｐ−ＣＳＣＦ１５２は、ＵＥからの要求を受け付け、これらの要求を内部で処理するか、または場合によっては変換の後に、これらの要求を他のエンティティにフォワーディングし得る。Ｅ−ＣＳＣＦ１５４は、ＵＥのセッション制御サービスを実行し得、ＩＭＳ緊急サービスをサポートするために使用されるセッション状態を維持し得、緊急ＶｏＩＰ呼をサポートし得る。緊急サービス集中化及び連続性アプリケーションサーバ（Ｅ−ＳＣＣ ＡＳ）１５６は、ボイス呼のための単一無線ボイス呼連続性（ＳＲＶＣＣ）をサポートし得る。ＳＲＶＣＣでは、ＣＳ ＲＡＮとＰＳ ＲＡＮの両方に同時にアクセスすることができないＵＥのためにＣＳ ＲＡＮとＰＳ ＲＡＮとの間でハンドオーバが行われるとき、呼が保存され得る。
【００２３】
ＰＳＡＰ１８０は、（例えば、警察、消防、及び医療サービスについての）緊急呼に返答することを担当するエンティティであり、緊急センター（ＥＣ）と呼ばれることもある。そのような呼は、ユーザが、北米では「９１１」または欧州では「１１２」など、いくつかの固定のよく知られている番号をダイヤルしたときに、開始され得る。ＰＳＡＰ１８０は、ＰＳ呼（例えば、ＶｏＩＰ呼）とセッション開始プロトコル（ＳＩＰ）とをサポートし得、ＳＩＰは、ＩＰに基づいて対話型ユーザセッションを開始し、変更し、終了するためのシグナリング・プロトコルである。ＰＳＡＰ１８０はＣＳ呼をもサポートし得る。
【００２４】
ＬＲＦ１７０は、ＰＳＡＰ１８０とインターフェースし、ルーティング機能を実行し、緊急呼のためのロケーション・サービス（例えば、ロケーション推定値の検索）をサポートし得る。ＬＲＦ１７０は、ＴＳ２３．１６７に記載されているように、緊急呼がＰＳ領域において発信されたときに、割り当てられ得る。ＬＲＦ１７０は、ロケーション・サービスのためのアンカーポイントであり得、ハンドオーバ後に維持され得る。ＬＲＦ１７０は、図１に示すように、いずれかのロケーション・サーバの外部に実装され得る。ＬＲＦ１７０はまた、例えば、ある接続を介してまたは共通の物理的実装形態を介してロケーション・サーバと重複し得る。
【００２５】
ＵＥ１１０は、ワイヤレス・ネットワーク１０２及び／または１０４と通信して、通信サービスを取得し得る。ＵＥ１１０は、固定でも移動でもよく、移動局、アクセス端末、ＳＥＴ、加入者ユニット、局などと呼ばれることもある。ＵＥ１１０は、セルラー電話、携帯情報端末（ＰＤＡ）、ワイヤレス・デバイス、ワイヤレスモデム、ワイヤレス・ルータ、ラップトップ・コンピュータ、テレメトリ・デバイス、トラッキング・デバイスなどであり得る。ＵＥ１１０は、ＲＡＮ１２２または１２４中の１つまたは複数の基地局と通信し得る。ＵＥ１１０はまた、１つまたは複数の衛星１９０からの信号を受信及び測定し、衛星１９０の擬似距離測定値を取得し得る。ＵＥ１１０はまた、ＲＡＮ１２２及び／またはＲＡＮ１２４中の基地局からの信号を測定し、それらの基地局のタイミング測定値、信号強度測定値、及び／または信号品質測定値を取得し得る。それらの擬似距離測定値、タイミング測定値、信号強度測定値、及び／または信号品質測定値は、ＵＥ１１０のロケーション推定値を導出するために使用され得る。ロケーション推定値は、位置推定値、位置フィックスなどと呼ばれることもある。
【００２６】
衛星１９０は、米国の全地球測位システム（ＧＰＳ）、欧州のGalileoシステム、ロシアのＧＬＯＮＡＳＳシステム、または何らかの他の衛星測位システム（ＳＰＳ）の一部であり得る。ＳＰＳは、一般に、送信機から受信した信号に基づいて地球上または地球上空の受信機のロケーションをそれらの受信機が判断できるように配置された送信機のシステムを含む。
【００２７】
図２に、３ＧＰＰワイヤレス・ネットワーク１０４と３ＧＰＰ２ワイヤレス・ネットワーク１０６との例示的な展開を示す。ワイヤレス・ネットワーク１０６は、ＲＡＮ１２６とコア・ネットワーク１６０とを含む。ＲＡＮ１２６は、ＣＤＭＡ２０００ １ｘＲＴＴをサポートする１ｘＲＴＴ ＲＡＮ、またはＩＳ−８５８をサポートするHigh Rate Packet Data（ＨＲＰＤ）ＲＡＮ、または何らかの他のＲＡＴをサポートするＲＡＮであり得る。１ｘＲＴＴ及びＨＲＰＤはｃｄｍａ２０００の一部である。ＨＲＰＤはEvolution-Data Optimized（ＥＶ−ＤＯ）とも呼ばれる。
【００２８】
コア・ネットワーク１６０は、ＲＡＮ１２６と通信するＵＥの様々な通信サービスをサポートし得る。コア・ネットワーク１６０内で、１ｘＲＴＴ ＭＳＣ１６２は、１ｘＲＴＴ ＲＡＮ１２６と通信するＵＥのＣＳ呼のためのスイッチング機能を実行し得る。１ｘ ＣＳインターワーキングソリューション機能（１ｘＣＳ ＩＷＳ）１６４は、コア・ネットワーク１４０とコア・ネットワーク１６０との間のインターワーキングをサポートし得る。パケット・データ・サービング・ノード（ＰＤＳＮ）１６９は、ＨＲＰＤ ＲＡＮ１２６と通信するＵＥのＰＳ接続及びセッションのための、スイッチング及びルーティング機能を実行し得る。位置判断エンティティ（ＰＤＥ）１６６は、１ｘＲＴＴ／ＨＲＰＤ ＲＡＮ１２６と通信するＵＥの測位をサポートし得る。モバイル測位センター（ＭＰＣ）１６８は、ロケーション・サービスをサポートし、外部ＬＣＳクライアントとインターフェースし、加入者プライバシ、許可、認証、ビリングなどのサービスを提供するための、様々な機能を実行し得る。ＭＰＣ１６８は、３ＧＰＰ２のためのコントロール・プレーン・ロケーション・ソリューション、例えば、ＡＮＳＩ Ｊ−ＳＴＤ−０３６、３ＧＰＰ２ Ｘ．Ｓ０００２などをサポートし得る。
【００２９】
図１及び図２は、各ワイヤレス・ネットワーク中に含まれ得るいくつかのネットワーク・エンティティを示している。図１及び図２はまた、様々なネットワーク・エンティティ間のいくつかのインターフェースを示している。各ワイヤレス・ネットワークは、他の機能及びサービスをサポートすることができる他のネットワーク・エンティティ及びインターフェースを含み得る。
【００３０】
ＵＥ１１０は、呼、例えば、緊急呼のために、ワイヤレス・ネットワークと通信することがある。ＵＥ１１０は、通信サービスに関してＵＥ１１０をサービスするように指定されたサービング・ノードを有し得る。サービング・ノードは、ＵＥ１１０がどのＲＡＮと通信しているかと、呼のタイプとに依存し得る。表２に、ＵＥ１１０のサービング・ノードとして働き得る様々なネットワーク・エンティティを記載する。ＰＤＳＮ１６９は、ＭＰＣなどのロケーション・サーバと直接通信しないという点で、他のサービング・ノードとは異なり得る。
【表２】
【００３１】
ＵＥ１１０は、呼中にロケーション・サーバを介してロケーション・サービスを受信し得る。ロケーション・サーバは、ＵＥ１１０がどのワイヤレス・ネットワークと通信しているかと、コントロール・プレーン・ロケーション・ソリューションが利用されるのか、またはユーザ・プレーン・ロケーション・ソリューションが利用されるのかに依存し得る。表３に、ＵＥ１１０のロケーション・サーバとして働き得る様々なネットワーク・エンティティを記載する。
【表３】
【００３２】
ＵＥ１１０は呼中にハンドオーバを実行し得る。ハンドオーバは、あるＲＡＮから別のＲＡＮへの、ＵＥのための無線接続の転送を指す。無線接続は、ＵＥとＲＡＮとの間のシグナリングとトラフィック・データとをサポートするために使用され得る。トラフィック・データは、ボイス呼、緊急呼、データ呼などのうちの１つまたは複数を備え得る。ＲＡＴに応じて、ボイス呼または緊急呼は、例えば、回路またはＶｏＩＰのいずれかを使用し得る。
【００３３】
ＵＥ１１０は、呼中にソース・ワイヤレス・ネットワークからターゲット・ワイヤレス・ネットワークへのハンドオーバを実行し得る。ＵＥ１１０は、ソースＲＡＮと通信し、ハンドオーバより前にソース・ワイヤレス・ネットワーク中のソース・サービング・ノードとソース・ロケーション・サーバとによってサービスされ得る。ＵＥ１１０は、ターゲットＲＡＮと通信し、ハンドオーバ後にターゲット・ワイヤレス・ネットワーク中のターゲット・サービング・ノードとターゲット・ロケーション・サーバとによってサービスされ得る。ハンドオーバより前のネットワーク・エンティティはソース側にあり、ハンドオーバ後のネットワーク・エンティティはターゲット側にある。呼が、ＰＳＡＰ１８０によってサービスされる緊急呼である場合、ソース・ロケーション・サーバ及びターゲット・ロケーション・サーバは、ＰＳＡＰ１８０へのインターフェースを与え得る共通のＬＲＦ１７０と対話し得る。
【００３４】
ソースＲＡＮ及びターゲットＲＡＮは、それぞれ任意のＲＡＴを利用し得、ＣＳ呼またはＰＳ呼をサポートし得る。ソース・ロケーション・サーバ及びターゲット・ロケーション・サーバは、それぞれコントロール・プレーン・ロケーション・ソリューションまたはユーザ・プレーン・ロケーション・ソリューションをサポートし得る。ソースＲＡＮ及びターゲットＲＡＮと、ソース・ロケーション・ソリューション及びターゲット・ロケーション・ソリューションとの以下の選択肢とともに、多数の可能なハンドオーバ・シナリオがあり得る。
【００３５】
・ソースＲＡＮ：Ｅ−ＵＴＲＡＮ、ＵＴＲＡＮ ＰＳ、ＵＴＲＡＮ ＣＳ、ＧＥＲＡＮ ＰＳ、ＧＥＲＡＮ ＣＳ、１ｘＲＴＴ、ＨＲＰＤ、
・ターゲットＲＡＮ：Ｅ−ＵＴＲＡＮ、ＵＴＲＡＮ ＰＳ、ＵＴＲＡＮ ＣＳ、ＧＥＲＡＮ ＰＳ、ＧＥＲＡＮ ＣＳ、１ｘＲＴＴ、ＨＲＰＤ、
・ソース・ロケーション・ソリューション：ＧＥＲＡＮ、ＵＴＲＡＮ、及びＥ−ＵＴＲＡＮの場合は３ＧＰＰ ＣＰソリューション；１ｘＲＴＴの場合は３ＧＰＰ２ ＣＰソリューション；ＳＵＰＬ、ならびに
・ターゲット・ロケーション・ソリューション：ＧＥＲＡＮ、ＵＴＲＡＮ、及びＥ−ＵＴＲＡＮの場合は３ＧＰＰ ＣＰソリューション；１ｘＲＴＴの場合は３ＧＰＰ２ ＣＰソリューション；ＳＵＰＬ。
【００３６】
表４に、いくつかの例示的なハンドオーバ・シナリオを（最上行に）記載し、各ハンドオーバ・シナリオの場合の、ソースＲＡＮ及びターゲットＲＡＮと、ソース・サービング・ノード及びターゲット・サービング・ノードと、ソース・ロケーション・サーバ及びターゲット・ロケーション・サーバとを与える。
【表４】
【００３７】
できる限り多くのハンドオーバ・シナリオについてＵＥ１１０のロケーション連続性を維持することが望ましいことがある。ハンドオーバ後にＵＥ１１０のロケーション連続性を維持するために、アクションの以下のセットが実行され得る。
【００３８】
（ａ）ソース・ロケーション・サーバ（例えば、ＧＭＬＣ、ＭＰＣ、またはＥ−ＳＬＰ）がターゲット・ロケーション・サーバとは異なる場合、そのソース・ロケーション・サーバを除去する、
（ｂ）ターゲット・ロケーション・サーバ（例えば、ＧＭＬＣ、ＭＰＣ、またはＥ−ＳＬＰ）がソース・ロケーション・サーバとは異なる場合、そのターゲット・ロケーション・サーバを割り当てる、
（ｃ）コントロール・プレーン・ロケーション・ソリューションがターゲット・ロケーション・サーバによってサポートされている場合、ターゲット・サービング・ノード（例えば、ＭＭＥ、ＳＧＳＮ、ＭＳＣサーバ、または１ｘＲＴＴ ＭＳＣ）の識別情報と、場合によってはターゲットセル識別情報（ＩＤ）とをターゲット・ロケーション・サーバに供給する、ならびに
（ｄ）ＳＵＰＬが、ターゲット・ロケーション・サーバによってサポートされているが、ソース・ロケーション・サーバによってサポートされていない場合、（ｉ）ＵＥ１１０にアクセスするための手段、例えば、Ｅ−ＳＬＰからＵＥへのＳＵＰＬ ＩＮＩＴメッセージのＵＤＰ／ＩＰまたはＳＩＰ Ｐｕｓｈ転送をサポートするための手段と、（ｉｉ）場合によっては、相互認証をサポートするための手段とをＥ−ＳＬＰに与える。
【００３９】
ターゲット・サービング・ノード識別情報は、ＩＰアドレス、またはＥ．１６４アドレス、または完全修飾ドメインネーム（ＦＱＤＮ）、またはダイアメーター識別情報（Diameter Identity）であり得る。アクション（ｃ）では、（例えば、ＰＳＡＰ１８０に代わって）ハンドオーバ後にコントロール・プレーンのためのモバイル着ロケーション要求（Mobile Terminated Location Request）（ＭＴ−ＬＲ）ロケーションプロシージャを使用してＵＥ１１０のロケーションを取得することが可能になり得る。アクション（ｄ）では、（例えば、ＰＳＡＰ１８０に代わって）ハンドオーバ後にＳＵＰＬロケーションプロシージャを使用してＵＥ１１０のロケーションを取得することが可能になり得る。これらのロケーションプロシージャは、緊急呼のためのＵＥ１１０の初期ロケーション推定値及び／または更新されたロケーション推定値を取得するために使用され得る。
【００４０】
アクション（ａ）〜（ｄ）を完了することによってＵＥ１１０のロケーション連続性を維持するために、様々な方式が定義され得る。これらの方式は、ＰＳ領域において発信し得るかまたはＰＳ領域にハンドオーバされ得る緊急呼をサポートするために、単一のＬＲＦ１７０を仮定し得るが、潜在的には複数のロケーション・サーバを仮定し得る。これらの方式は、図１中のワイヤレス・ネットワーク１０４からワイヤレス・ネットワーク１０２への（またはその逆も同様）ハンドオーバに使用され得、図２中のワイヤレス・ネットワーク１０４からワイヤレス・ネットワーク１０６への（またはその逆も同様）ハンドオーバにも使用され得る。
【００４１】
図３に、例えば、緊急呼の、ハンドオーバ後にＵＥ１１０のロケーション連続性を維持するための第１の方式の設計を示す。第１の方式は、（ｉ）ソース側ではコントロール・プレーン・ロケーション・ソリューションまたはユーザ・プレーン・ロケーション・ソリューションが使用され、（ｉｉ）ターゲット側ではコントロール・プレーンソリューションが使用される、ハンドオーバ・シナリオに使用され得る。図３に示すように、ＵＥ１１０は、第１のＲＡＮ３１２と通信し、ハンドオーバより前にソース側のソース・サービング・ノード３１４とソース・ロケーション・サーバ３１６とによってサービスされ得る。ＵＥ１１０は、第２のＲＡＮ３２２と通信し、ハンドオーバ後にターゲット側のターゲット・サービング・ノード３２４とターゲット・ロケーション・サーバ３２６とによってサービスされ得る。ソース・サービング・ノード３１４は、図１及び図２中のＭＭＥ１４２、またはＳＧＳＮ１３６、またはＭＳＣサーバ１３４、または１ｘＲＴＴ ＭＳＣ１６２であり得る。ターゲット・サービング・ノード３２４は、ＭＭＥ１４２、またはＳＧＳＮ１３６、またはＭＳＣサーバ１３４、または１ｘＲＴＴ ＭＳＣ１６２であり得る。ソース・ロケーション・サーバ３１６は、（ｉ）コントロール・プレーン・ロケーション・ソリューションのためのＧＭＬＣ１３８、またはＧＭＬＣ１４８、またはＭＰＣ１６８、或いは（ｉｉ）ユーザ・プレーン・ロケーション・ソリューションのためのＥ−ＳＬＰ１５８であり得る。ターゲット・ロケーション・サーバ３２６は、コントロール・プレーン・ロケーション・ソリューションのためのＧＭＬＣ１３８、またはＧＭＬＣ１４８、またはＭＰＣ１６８であり得る。
【００４２】
ＵＥ１１０は、ＲＡＮ３１２からＲＡＮ３２２へのハンドオーバを実行し得る。また、ソース・サービング・ノード３１４は、ターゲット・サービング・ノード３２４とともにＵＥ１１０のハンドオーバを実行し得る。ＲＡＮ３１２中の基地局または何らかの他のネットワーク・エンティティ（例えば、ＲＮＣ）は、（ｉ）ＵＴＲＡＮまたはＥ−ＵＴＲＡＮへのハンドオーバの場合はターゲット基地局またはターゲットＲＮＣ、或いは（ｉｉ）ＧＥＲＡＮまたは１ｘＲＴＴへのハンドオーバの場合はターゲットセル／セクタ、のいずれかの識別情報をソース・サービング・ノード３１４に供給し得る。この識別情報は、ＵＥ１１０によってソース基地局に供給されるハンドオーバ関係の測定値から導出され得る。ソース・サービング・ノード３１４は、その構成情報を使用して、受信した基地局またはセル識別情報をターゲット・サービング・ノード３２４の識別情報に変換し得、ターゲット・サービング・ノード３２４は、識別されたターゲット基地局またはターゲットセル／セクタのためのサービング・ノードであり得る。
【００４３】
第１の方式では、ターゲット・サービング・ノード３２４は、例えば、ターゲット・サービング・ノード３２４において記憶された構成情報またはドメインネームシステム（ＤＮＳ）問合せに基づいて、ターゲット・ロケーション・サーバ３２６を判断し得る。その判断は、例えば、同じサービング・ノードに関連する基地局またはセル／セクタの異なるセットをサポートするために異なるロケーション・サーバが割り当てられ得るように、ターゲット基地局またはターゲットセル／セクタを考慮に入れ得る。ターゲット・サービング・ノード３２４は、ハンドオーバ中に、またはハンドオーバが完了したときに、ターゲット・サービング・ノード３２４の識別情報（例えば、ターゲット・サービング・ノード３２４のアドレス）をターゲット・ロケーション・サーバ３２６に転送し得る（ステップ１）。その転送は、（ｉ）ターゲット・サービング・ノード３２４がＳＧＳＮ１３６またはＭＳＣサーバ１３４である場合はモバイル・アプリケーション・パート（Mobile Application Part）（ＭＡＰ）加入者ロケーション報告（Subscriber Location Report）（ＳＬＲ）メッセージ、或いは（ｉｉ）ターゲット・サービング・ノード３２４が１ｘＲＴＴ ＭＳＣ１６２である場合はＡＮＳＩ−４１発信要求（ＯＲＲＥＱ）、或いは（ｉｉｉ）ターゲット・サービング・ノード３２４がＭＭＥ１４２である場合はＳＬＲまたは何らかの他のメッセージを用いて、達成され得る。ターゲット・サービング・ノード３２４は、通常、ターゲット・ロケーション・サーバ３２６と対話して、ロケーション・サービスをサポートし得る。ステップ１における転送は、ターゲット・サービング・ノード３２４とターゲット・ロケーション・サーバ３２６との間の既存のインターフェースを使用して達成され得る。
【００４４】
ターゲット・ロケーション・サーバ３２６は、例えば、呼記録が維持されている場合、ＵＥ１１０のための呼記録を探すことによって、ターゲット・ロケーション・サーバ３２６がＵＥ１１０のソース・ロケーション・サーバであるかどうかを判断し得る。ターゲット・ロケーション・サーバとソース・ロケーション・サーバが同じであると判断された場合、残りのステップはスキップされ得る。他の場合、ターゲット・ロケーション・サーバ３２６は、ハンドオーバに関する情報を用いてＬＲＦ１７０を更新し得る（ステップ２）。例えば、ターゲット・ロケーション・サーバ３２６は、ターゲット・サービング・ノード３２４の識別情報とＵＥ１１０の識別情報とをＬＲＦ１７０に供給し得る。ＬＲＦ１７０は、その更新をターゲット・ロケーション・サーバ３２６から受信し得、ソース・ロケーション・サーバ３１６が、現在割り当てられており、ターゲット・ロケーション・サーバ３２６とは異なる場合、ソース・ロケーション・サーバ３１６を除去し得る（ステップ３）。
【００４５】
代替として、ターゲット・サービング・ノード３２４が１ｘＲＴＴ ＭＳＣ１６２である場合、ＵＥ１１０及び１ｘＣＳ ＩＷＳ１６４は、例えば、ＴＳ２３．２１６に記載のハンドオーバのための通常呼の発信と同様に、１ｘＲＴＴ ＭＳＣ１６２から見てハンドオーバの一部として１ｘＲＴＴ緊急呼を発信し得る。次いで、これにより、１ｘＲＴＴ ＭＳＣ１６２は、通常１ｘＲＴＴ緊急呼発信の一部としてＭＰＣ１６８に問い合わせ得る。次いで、ＭＰＣ１６８は、（ｉ）呼発信のセル／セクタを識別する緊急サービスルーティングキー（Emergency Services Routing Key）（ＥＳＲＫ）番号、または（ｉｉ）所与のセル／セクタにおいてその呼を一意に識別する緊急サービス・ルーティング桁（Emergency Services Routing Digit）（ＥＳＲＤ）番号を返し得る。ただし、ＭＰＣ１６８は、１ｘＲＴＴ ＭＳＣ１６２からの問合せが、ＵＥ１１０の緊急呼の１ｘＲＴＴへのハンドオーバをサポートするためのものであると判断し得、例えば、ＭＰＣ１６８は、ＬＲＦ１７０に問い合わせて、ＵＥ１１０の緊急呼の記録がすでにＬＲＦ１７０中に存在すると判断し得る。次いで、ＭＰＣ１６８は、ＥＳＲＫ番号またはＥＳＲＤ番号をＳＲＶＣＣのための緊急セッション転送番号（Ｅ−ＳＴＮ−ＳＲ）に設定し得る。Ｊ−ＳＴＤ−０３６に記載の通常の緊急呼設定の一部として、次いで、１ｘＲＴＴ ＭＳＣ１６２は、その呼をＥ−ＳＴＮ−ＳＲにルーティングし得、次いで、Ｅ−ＳＴＮ−ＳＲは、その呼をＥ−ＳＣＣ ＡＳ１５６に転送し得る。
【００４６】
ターゲット・サービング・ノードがステップ１におけるロケーション・サーバの更新と後続のハンドオーバの両方を制御するので、第１の方式は、連続するハンドオーバに対処する際にロバストであり得る。ターゲット・ロケーション・サーバが、ステップ２と同時に（またはステップ２の後に）ステップ１に肯定応答した場合、ターゲット・サービング・ノードは、別のハンドオーバがステップ１の後に、ただしこの肯定応答が受信される前に必要とされる場合でも、その肯定応答が受信されるまで待ってからＵＥ１１０の別のハンドオーバを推進し得る。これにより、ＬＲＦ１７０は、場合によっては後で第２のハンドオーバについて通知される前に（ステップ２において）第１のハンドオーバについて通知されるようになり得、例えば、ＬＲＦ１７０へのハンドオーバ通知は間違った順序で行われないようになる。ステップ１が行われる前に別のハンドオーバが必要とされる場合、ターゲット・サービング・ノードは、ステップ１〜３をスキップし得、新しいターゲット・サービング・ノードが上記更新を実行することを可能にし得、それにより、第１のハンドオーバはロケーション・サーバとＬＲＦ１７０とから見えなくなり得、後続のハンドオーバのみが行われたかのように見え得る。
【００４７】
図４に、例えば、緊急呼の、ハンドオーバ後にＵＥ１１０のロケーション連続性を維持するための第２の方式の設計を示す。第２の方式は、（ｉ）ソース側ではコントロール・プレーン・ロケーション・ソリューションが使用され、（ｉｉ）ターゲット側ではコントロール・プレーンソリューションまたはユーザ・プレーンソリューションが使用される、ハンドオーバ・シナリオに使用され得る。図４に示すように、ＵＥ１１０は、第１のＲＡＮ４１２と通信し、ハンドオーバより前にソース・サービング・ノード４１４とソース・ロケーション・サーバ４１６とによってサービスされ得る。ＵＥ１１０は、第２のＲＡＮ４２２と通信し、ハンドオーバ後にターゲット・サービング・ノード４２４とターゲット・ロケーション・サーバ４２６とによってサービスされ得る。ソース・サービング・ノード４１４は、ＭＭＥ１４２、またはＳＧＳＮ１３６、またはＭＳＣサーバ１３４であり得る。ターゲット・サービング・ノード４２４は、ＭＭＥ１４２、またはＳＧＳＮ１３６、またはＭＳＣサーバ１３４、または１ｘＲＴＴ ＭＳＣ１６２であり得る。ソース・ロケーション・サーバ４１６は、コントロール・プレーン・ロケーション・ソリューションのためのＧＭＬＣ１３８またはＧＭＬＣ１４８であり得る。ターゲット・ロケーション・サーバ４２６は、（ｉ）コントロール・プレーン・ロケーション・ソリューションのためのＧＭＬＣ１３８、またはＧＭＬＣ１４８、またはＭＰＣ１６８、或いは（ｉｉ）ユーザ・プレーン・ロケーション・ソリューションのためのＥ−ＳＬＰ１５８であり得る。
【００４８】
第２の方式では、ソース・サービング・ノード４１４は、ハンドオーバが完了した後にＵＥ１１０の識別情報とターゲット・サービング・ノード４２４の識別情報とをソース・ロケーション・サーバ４１６に転送し得る（ステップ１）。この転送は、（ｉ）ソース・サービング・ノード４１４がＳＧＳＮ１３６またはＭＳＣサーバ１３４である場合はＭＡＰ加入者ロケーション報告（ＳＬＲ）メッセージ、或いは（ｉｉ）ソース・サービング・ノード４１４がＭＭＥ１４２である場合はＳＬＲまたは等価なメッセージを用いて、達成され得る。
【００４９】
ソース・ロケーション・サーバ４１６が、呼記録を維持しており、ソース・ロケーション・サーバ４１６がターゲット・ロケーション・サーバとなると判断することができる場合、後続のステップはスキップされ得る。他の場合、ソース・ロケーション・サーバ４１６は、ハンドオーバに関する情報を用いてＬＲＦ１７０を更新し、例えば、ＵＥ識別情報とターゲット・サービング・ノード識別情報とを与え得る（ステップ２）。ＬＲＦ１７０は、ＵＥ１１０のターゲット・ロケーション・サーバ４２６を判断し、割り当て得る。ターゲット・ロケーション・サーバ４２６がソース・ロケーション・サーバ４１６とは異なる場合、ＬＲＦ１７０は、ＵＥ１１０とターゲット・サービング・ノード４２４とに関する情報をターゲット・ロケーション・サーバ４２６に供給し得る（ステップ３）。次いで、ＬＲＦ１７０は、ソース・ロケーション・サーバ４１６がターゲット・ロケーション・サーバ４２６とは異なる場合、ソース・ロケーション・サーバ４１６を除去し得る（ステップ４）。ターゲット・ロケーション・サーバ４２６は、ＬＲＦ１７０から受信した情報に基づいてターゲット・サービング・ノード４２４と通信し得る。ターゲット・ロケーション・サーバ４２６がＵＥ１１０のロケーション要求をターゲット・サービング・ノード４２４に送信することができる前にターゲット側からの後続のハンドオーバが行われた場合、ターゲット・サービング・ノード４２４は（例えば、構成情報に基づいて）ターゲット・ロケーション・サーバ４２６を判断し得る。次いで、ターゲット・サービング・ノード４２４は、この後続のハンドオーバに関してターゲット・ロケーション・サーバ４２６を更新し得る。
【００５０】
図５に、例えば、緊急呼の、ハンドオーバ後にＵＥ１１０のロケーション連続性を維持するための第３の方式の設計を示す。第３の方式は、（ｉ）ソース側ではコントロール・プレーン・ロケーション・ソリューションが使用され、（ｉｉ）ターゲット側ではコントロール・プレーンソリューションまたはユーザ・プレーンソリューションが使用される、ハンドオーバ・シナリオにおける３ＧＰＰ ＲＡＴ間のハンドオーバに使用され得る。図５に示すように、ＵＥ１１０は、第１のＲＡＮ５１２と通信し、ハンドオーバより前にソース・サービング・ノード５１４とソース・ロケーション・サーバ５１６とによってサービスされ得る。ＵＥ１１０は、第２のＲＡＮ５２２と通信し、ハンドオーバ後にターゲット・サービング・ノード５２４とターゲット・ロケーション・サーバ５２６とによってサービスされ得る。ソース・サービング・ノード５１４は、ＭＭＥ１４２、またはＳＧＳＮ１３６、またはＭＳＣ１３２、またはＭＳＣサーバ１３４であり得る。ターゲット・サービング・ノード５２４は、ＭＭＥ１４２、またはＳＧＳＮ１３６、またはＭＳＣ１３２、またはＭＳＣサーバ１３４であり得る。ソース・ロケーション・サーバ５１６は、コントロール・プレーン・ロケーション・ソリューションのためのＧＭＬＣ１３８またはＧＭＬＣ１４８であり得る。ターゲット・ロケーション・サーバ５２６は、（ｉ）コントロール・プレーン・ロケーション・ソリューションのためのＧＭＬＣ１３８またはＧＭＬＣ１４８、或いは（ｉｉ）ユーザ・プレーン・ロケーション・ソリューションのためのＥ−ＳＬＰ１５８であり得る。
【００５１】
第３の方式では、ソース・サービング・ノード５１４は、ハンドオーバが開始したときにソース・ロケーション・サーバ５１６の識別情報をターゲット・サービング・ノード５２４に転送し得る（ステップ１）。この転送は、ソース・サービング・ノード５１４によってターゲット・サービング・ノード５２４に送信される第１のメッセージにおいて行われ得る。このメッセージは、（ｉ）３ＧＰＰ ＰＳ−ｔｏ−ＰＳハンドオーバの場合はＧＰＲＳトンネリングプロトコル（ＧＴＰ）フォワードリロケーション要求（Forward Relocation Request）メッセージ、または（ｉｉ）Ｅ−ＵＴＲＡＮからＵＴＲＡＮ／ＧＥＲＡＮへのＳＲＶＣＣハンドオーバの場合はＳＲＶＣＣ ＰＳ−ｔｏ−ＣＳ要求メッセージ、または（ｉｉｉ）何らかの他のメッセージであり得る。
【００５２】
次いで、ターゲット・サービング・ノード５２４は、ハンドオーバが完了した後に、（ステップ１において受信したソース・ロケーション・サーバ識別情報に基づいて）ターゲット・サービング・ノード５２４の識別情報とＵＥ１１０の識別情報とをソース・ロケーション・サーバ５１６に転送し得る（ステップ２）。この転送は、ターゲット・サービング・ノード５２４がＳＧＳＮ１３６またはＭＳＣサーバ１３４である場合はＭＡＰ ＳＬＲメッセージを用いて、或いはターゲット・サービング・ノード５２４がＭＭＥ１４２である場合は何らかの他のメッセージを用いて達成され得る。
【００５３】
ソース・ロケーション・サーバ５１６が、呼記録を維持しており、ソース・ロケーション・サーバ５１６がターゲット・ロケーション・サーバとなると判断することができる場合、後続のステップはスキップされ得る。他の場合、ソース・ロケーション・サーバ５１６は、ハンドオーバに関する情報を用いてＬＲＦ１７０を更新し、例えば、ＵＥ識別情報とターゲット・サービング・ノード識別情報とを与え得る（ステップ３）。ＬＲＦ１７０はターゲット・ロケーション・サーバ５２６を判断し得る。ターゲット・ロケーション・サーバ５２６がソース・ロケーション・サーバ５１６とは異なる場合、ＬＲＦ１７０は、ＵＥ１１０とターゲット・サービング・ノード５２４とに関する情報をターゲット・ロケーション・サーバ５２６に供給し得る（ステップ４）。次いで、ＬＲＦ１７０は、ソース・ロケーション・サーバ５１６がターゲット・ロケーション・サーバ５２６とは異なる場合、ソース・ロケーション・サーバ５１６を除去し得る（ステップ５）。
【００５４】
図６に、例えば、緊急呼の、ハンドオーバ後にＵＥ１１０のロケーション連続性を維持するための第４の方式の設計を示す。第４の方式は、Ｅ−ＳＣＣ ＡＳ（例えば、Ｅ−ＳＣＣ ＡＳ１５６）によってＳＲＶＣＣサポートが与えられているときに３ＧＰＰ ＰＳ ＲＡＴと３ＧＰＰ ＣＳ ＲＡＴとの間のハンドオーバに使用され得る。ＣＳ側ではコントロール・プレーン・ロケーション・ソリューションが使用され得、ＰＳ側ではコントロール・プレーン・ロケーション・ソリューションまたはユーザ・プレーン・ロケーション・ソリューションのいずれかが使用され得る。図６に示すように、ＵＥ１１０は、第１のＲＡＮ６１２と通信し、ハンドオーバより前にソース・サービング・ノード６１４とソース・ロケーション・サーバ６１６とによってサービスされ得る。ＵＥ１１０は、第２のＲＡＮ６２２と通信し、ハンドオーバ後にターゲット・サービング・ノード６２４とターゲット・ロケーション・サーバ６２６とによってサービスされ得る。ソース・サービング・ノード６１４は、ＭＭＥ１４２、またはＳＧＳＮ１３６、またはＭＳＣ１３２、またはＭＳＣサーバ１３４であり得る。ターゲット・サービング・ノード６２４は、ＭＭＥ１４２、またはＳＧＳＮ１３６、またはＭＳＣ１３２、またはＭＳＣサーバ１３４であり得る。ソース・ロケーション・サーバ６１６は、コントロール・プレーン・ロケーション・ソリューションのためのＧＭＬＣ１３８またはＧＭＬＣ１４８であり得る。ターゲット・ロケーション・サーバ６２６は、コントロール・プレーン・ロケーション・ソリューションのためのＧＭＬＣ１３８またはＧＭＬＣ１４８であり得る。ソース・ロケーション・サーバ６１６またはターゲット・ロケーション・サーバ６２６のいずれかは、ユーザ・プレーン・ロケーション・ソリューションのためのＥ−ＳＬＰ１５８であり得る。
【００５５】
第４の方式では、ターゲット・サービング・ノード６２４は、ソースＲＡＮからターゲットＲＡＮに無線接続を転送するための（ＴＳ２３．２１６及びＴＳ２３．２３７において定義された）ＳＲＶＣＣハンドオーバ・プロシージャの一部としてＥ−ＳＣＣ ＡＳ１５６にメッセージを送信し得る（ステップ１）。このメッセージは、ＳＩＰ ＩＮＶＩＴＥメッセージまたはＭＧＣＦを介して送信されたＩＳＤＮユーザパート初期アドレスメッセージ（ISDN User Part Initial Address Message）（ＩＳＵＰ ＩＡＭ）メッセージであり得る。ターゲット・サービング・ノード６２４は、その識別情報をこのメッセージ中に含め得る。そのメッセージがＩＳＵＰ ＩＡＭである場合、北米におけるネットワークのためのターゲット・サービング・ノード識別情報を搬送するためにＩＳＵＰ ＩＡＭ中の既存のＥＳＲＫまたはＥＳＲＤパラメータが使用され得る。次いで、Ｅ−ＳＣＣ ＡＳ１５６は、緊急呼のリモートレグを更新するために、ターゲット・サービング・ノード識別情報を含むＳＩＰ ＩＮＶＩＴＥメッセージをＥ−ＣＳＣＦ１５４に送信し得る（ステップ２）。Ｅ−ＣＳＣＦ１５４は、ターゲット・サービング・ノード６２４の識別情報を受信し得、この識別情報をＬＲＦ１７０に供給し得る（ステップ３）。ＬＲＦ１７０は、ＵＥ１１０とターゲット・サービング・ノード６２４とについての情報を用いてターゲット・ロケーション・サーバ６２６を判断し、更新し得る（ステップ４）。ＬＲＦ１７０はまた、ソース・ロケーション・サーバ６１６がターゲット・ロケーション・サーバ６２６とは異なる場合、ソース・ロケーション・サーバ６１６を除去し得る（ステップ５）。
【００５６】
図３〜図６は、ターゲット・サービング・ノードの識別情報をソース・ロケーション・サーバまたはターゲット・ロケーション・サーバに転送することによってＵＥ１１０のロケーション連続性が維持され得る、４つの例示的な方式を示している。第１の方式では、ターゲット・サービング・ノードは、その識別情報をターゲット・ロケーション・サーバに送信し得る。第２の方式では、ソース・サービング・ノードは、ターゲット・サービング・ノード識別情報をソース・ロケーション・サーバに送信し得る。第３の方式では、ターゲット・サービング・ノードは、その識別情報をソース・ロケーション・サーバに送信し得る。第４の方式では、ターゲット・サービング・ノードは、その識別情報をＥ−ＳＣＣ ＡＳに送信し得、そのターゲット・サービング・ノード識別情報はターゲット・ロケーション・サーバにフォワーディングされ得る。ターゲット・サービング・ノード識別情報をソース・ロケーション・サーバまたはターゲット・ロケーション・サーバに（直接または間接的に）転送するための他の方式も実装され得る。すべての方式について、ターゲット・サービング・ノード識別情報は、ＬＲＦ１７０とＵＥ１１０との間にロケーション・セッションを確立してＵＥ１１０のロケーション連続性を維持するために使用され得る。
【００５７】
図７に、ハンドオーバ後にＵＥ１１０のロケーション連続性を維持するためのメッセージ・フロー７００の設計を示す。メッセージ・フロー７００は様々なタイプの呼に使用され得る。ただし、以下の説明では、ＵＥ１１０が緊急呼を有すると仮定する。
【００５８】
ＵＥ１１０は、緊急呼を発信したいという要求を受信し得、緊急接続を確立し得る（ステップ１）。緊急接続は、（ｉ）ＴＳ２３．４０１に記載されているＥ−ＵＴＲＡＮアクセスのための緊急ＰＤＮ接続、または（ｉｉ）ＴＳ２３．０６０に記載されているＵＴＲＡＮ ＰＳアクセスのための緊急ＰＤＰコンテキスト、または（ｉｉｉ）何らかの他のタイプの接続であり得る。次いで、ＵＥ１１０は、ＴＳ２３．１６７に記載されているように、ＩＭＳ緊急呼を確立し得る（同じくステップ１）。緊急呼確立中に、ＬＲＦ１７０は、緊急呼をサービスするために割り当てられ得、ＵＥ１１０のためにロケーション・サーバ７１６（例えば、ＧＭＬＣ１３８または１４８）が選択され得る。
【００５９】
後で、サービング・ノード７１４（例えば、ＭＭＥ１４２またはＳＧＳＮ１３６）は、ＵＥ１１０のロケーションの要求をロケーション・サーバ７１６から受信し得る（ステップ２）。この要求は、国際モバイル加入者識別情報（International Mobile Subscriber Identity）（ＩＭＳＩ）、または移動局国際加入者ディレクトリ番号（Mobile Station International Subscriber Directory Number）（ＭＳＩＳＤＮ）、または国際モバイル機器識別情報（International Mobile Equipment Identity）（ＩＭＥＩ）であり得る、ＵＥ１１０の識別情報を含み得る。ステップ２における上記要求がサービング・ノード７１４によって受信された場合、またはネットワーク開始型ロケーション要求（Network Initiated Location Request）（ＮＩ−ＬＲ）ロケーションプロシージャのサポートが必要とされる場合、サービング・ノード７１４は、ＵＥ１１０のロケーションを取得するために（例えば、サービングＲＮＣまたはＥ−ＳＭＬＣとともに）ロケーション・セッションを開始し得る（ステップ３）。
【００６０】
サービング・ノード７１４は、ＵＥ１１０を現在サービスしているソースＲＡＮからターゲットＲＡＮへのＵＥ１１０のハンドオーバの要求を受信し得る（ステップ４）。ＵＥ１１０は、Ｅ−ＵＴＲＡＮ中のサービングｅＮＢから、またはＵＴＲＡＮ中のサービングＲＮＣから、または何らかの他のＲＡＮ中の何らかの他のネットワーク・エンティティから、ハンドオーバされ得る。ＵＥ１１０は、Ｅ−ＵＴＲＡＮへのハンドオーバの場合はターゲットｅＮＢに、或いはＵＴＲＡＮ ＰＳへのハンドオーバの場合はターゲットＲＮＣに、或いはＵＴＲＡＮ ＣＳまたはＧＥＲＡＮ ＣＳへのハンドオーバの場合はターゲットＭＳＣサーバに、或いは１ｘＲＴＴへのハンドオーバの場合は１ｘＲＴＴ ＭＳＣに関連するターゲットセルに、或いはＨＲＰＤへのハンドオーバの場合はターゲットセルに、ハンドオーバされ得る。上記ハンドオーバに関して、サービング・ノード７１４はソース・サービング・ノードと呼ばれることがあり、ロケーション・サーバ７１６はソース・ロケーション・サーバと呼ばれることがある。Ｅ−ＵＴＲＡＮ、ＵＴＲＡＮ ＰＳ、ＵＴＲＡＮ ＣＳ、またはＧＥＲＡＮ ＣＳへのハンドオーバの場合、ソース・サービング・ノード７１４は、ＴＳ２３．４０１、ＴＳ２３．０６０、またはＴＳ２３．２１６に記載されているように、ハンドオーバ要求メッセージをターゲット・サービング・ノード７２４に送信し得る（ステップ５）。Ｅ−ＵＴＲＡＮから１ｘＲＴＴへのハンドオーバの場合、ソース・サービング・ノード７１４は、ＴＳ２３．２１６に記載されているように、ハンドオーバ要求メッセージをターゲット１ｘＲＴＴ ＩＷＳに送信し得る。Ｅ−ＵＴＲＡＮからＨＲＰＤへのハンドオーバの場合、ステップ５はスキップされ得る。ＴＳ２３．４０１、ＴＳ２３．４０２、ＴＳ２３．０６０、またはＴＳ２３．２１６に記載されているように、ハンドオーバ準備及び実行プロシージャが実行され得る（ステップ６）。
【００６１】
ステップ３において開始されたロケーション・セッションは、通常、ステップ６が完了する前に終了し得る。ロケーション・セッションがステップ６の前に終了しない場合、ソース・サービング・ノード７１４は、ステップ６を完了した後にロケーション・セッションをアボートし得る（ステップ７）。これにより、ＵＥ１１０のロケーション推定値がソース・サービング・ノード７１４に供給され得る。
【００６２】
ステップ２が行われた場合、ソース・サービング・ノード７１４は加入者ロケーション応答供給（Provide Subscriber Location Response）メッセージをソース・ロケーション・サーバ７１６に返し得る（ステップ８ａ）。このメッセージは、ＵＥ１１０のロケーション推定値とターゲット・サービング・ノード７２４の識別情報とを含み得る。そのメッセージ中にターゲット・サービング・ノード識別情報が含まれるか否かは、ソース・サービング・ノード７１４における構成情報に基づいて決定され得る。この構成情報は、ソース・サービング・ノード識別情報及びターゲット・サービング・ノード識別情報、ＵＥ（例えば、ＵＥ１１０）のロケーション機能、ＵＥがローミングしているか否か、などを含み得る。
【００６３】
ステップ２及び８ａが行われなかった場合、ソース・サービング・ノード７１４は、ＵＥ１１０の識別情報、ターゲット・サービング・ノード７２４の識別情報、ハンドオーバを示すイベント・タイプ、ＵＥ１１０のロケーション推定値などを含み得る、加入者ロケーション報告メッセージをソース・ロケーション・サーバ７１６に送信し得る（ステップ８ｂ）。ステップ８ｂが行われるか否かは、ソース・サービング・ノード７１４における構成情報に依存し得る。ソース・ロケーション・サーバ７１６は、ソース・サービング・ノード７１４から加入者ロケーション報告メッセージが受信された場合、その加入者ロケーション報告メッセージに肯定応答し得る（ステップ９）。
【００６４】
ステップ６におけるハンドオーバが完了した後に、ターゲット・サービング・ノード７２４は、ＵＥ１１０の識別情報、ターゲット・サービング・ノード７２４の識別情報、ハンドオーバを示すイベント・タイプなどを含み得る、加入者ロケーション報告メッセージをターゲット・ロケーション・サーバ７２６（例えば、ＧＭＬＣ１３８または１４８）に送信し得る（ステップ１０）。ターゲット・サービング・ノード７２４は、その構成情報からターゲット・ロケーション・サーバ７２６のアドレスを判断し得る。ステップ１０が行われるか否かは、ターゲット・サービング・ノード７２４における構成情報に基づいてターゲット・サービング・ノード７２４によって決定され得る。この構成情報は、ソース・サービング・ノード識別情報及びターゲット・サービング・ノード識別情報、ＵＥ（例えば、ＵＥ１１０）のロケーション機能、ＵＥがローミングしているか否か、などを含み得る。効率及び信頼性のために、その構成情報は、ソース・サービング・ノード７１４とターゲット・サービング・ノード７２４とにおいて使用される場合、ステップ８ａまたはステップ８ｂが行われた場合はステップ１０が行われないことを保証すべきであり、その逆も同様である。ターゲット・ロケーション・サーバ７２６はターゲット・サービング・ノード７２４からの加入者ロケーション報告メッセージに肯定応答し得る（ステップ１１）。
【００６５】
以下で表５において説明するように、ＬＲＦ１７０と、ソース・ロケーション・サーバ７１６と、ターゲット・ロケーション・サーバ７２６との再構成が行われ得る（ステップ１２）。その再構成は、ソース・ロケーション・サーバ７１６の除去と、ターゲット・ロケーション・サーバ７２６の割当てと、ＬＲＦ１７０、ソース・ロケーション・サーバ７１６、及び／またはターゲット・ロケーション・サーバ７２６における情報の更新とを含み得る。
【００６６】
その後、ハンドオーバが行われた後にＬＲＦ１７０がＵＥ１１０のロケーション推定値を必要とする場合、ＬＲＦ１７０はターゲット・ロケーション・サーバ７２６を介してＭＴ−ＬＲロケーションプロシージャを推進し得る（ステップ１３）。これは、ターゲット側でのステップ２の繰り返しを必要とし得る。また、ステップ２〜１２は、前のハンドオーバがＥ−ＵＴＲＡＮまたはＵＴＲＡＮ ＰＳのいずれかへのハンドオーバであった場合、ＵＥ１１０の別のハンドオーバをサポートするためにターゲット側で繰り返され得る。
【００６７】
表５に、異なるハンドオーバ・シナリオにおいてＵＥ１１０のロケーション連続性を維持するために様々なネットワーク・エンティティによって実行されるアクションを記載する。表５において、第１の列には、ソース側で使用されるアクセスタイプとロケーション・ソリューションとが与えられている。第２の列には、ターゲット側で使用されるアクセスタイプとロケーション・ソリューションとが与えられている。第３の列には、各ハンドオーバ・シナリオについて様々なネットワーク・エンティティによって実行されるアクションが記載されている。表５に示す、すべてのハンドオーバ・シナリオについて、最初に緊急呼に割り当てられたＬＲＦは、ＰＳＡＰへの影響を回避するためにハンドオーバ後に保持され得る。ただし、表５において説明するように、ハンドオーバ後に他のロケーション・サーバの変更（例えば、ＧＭＬＣの追加または除去）が行われ得る。
【表５−１】
【表５−２】
【００６８】
注１：イントラＥ−ＵＴＲＡＮハンドオーバ、イントラＵＴＲＡＮ ＰＳハンドオーバ、及びインターＲＡＴハンドオーバの場合、ロケーション・ソリューションは変更され得る。
【００６９】
表５中の第１のハンドオーバ・シナリオでは、ステップ（ａ）におけるソース・サービング・ノードによる転送は、図７中のメッセージ・フロー７００中のステップ８ａまたは８ｂにおいて実行され得る。ステップ（ｂ）におけるターゲット・サービング・ノードによる転送は、メッセージ・フロー７００中のステップ１０において実行され得る。ＬＲＦの更新及びソース・ロケーション・サーバの交換は、メッセージ・フロー７００中のステップ１２において実行され得る。表５中のステップとメッセージ・フロー７００中のステップとの間の同様のマッピングは、表５中の他のハンドオーバ・シナリオに適用され得る。
【００７０】
表５に示すように、メッセージ・フロー７００は、異なるＲＡＴのＲＡＮ間のハンドオーバに使用され得る。メッセージ・フロー７００はまた、同じＲＡＴのＲＡＮ間のハンドオーバに使用され得、例えば、Ｅ−ＵＴＲＡＮからＥ−ＵＴＲＡＮへのハンドオーバ、またはＵＴＲＡＮ ＰＳからＵＴＲＡＮ ＰＳへのハンドオーバなどに使用され得る。同じＲＡＴのＲＡＮ間のハンドオーバは、基地局及び場合によっては他のネットワーク・エンティティ（例えば、ＲＮＣ）の変更と、サービング・ノード（例えば、ＭＭＥまたはＳＧＳＮ）の変更とを意味し得るが、各ネットワーク・エンティティのタイプは同じままである。
【００７１】
ＨＲＰＤへのハンドオーバが行われる場合、ターゲット側でＳＵＰＬが使用され得る。その場合は、ソース側でコントロール・プレーン・ロケーション・ソリューションが使用された場合、ソース側更新が実行され得る。
【００７２】
Ｅ−ＳＬＰ１５８はターゲット・サービング・ノード識別情報を受信することができないことがある。Ｅ−ＳＬＰ１５８は、他のロケーション・サーバの更新に基づいて、ＬＲＦ１７０によって割り当てられ、除去され得る。
【００７３】
確立されたＩＭＳ緊急呼またはまだ確立されていないＩＭＳ緊急呼のためのＩＰベアラのハンドオーバは、ＰＳ領域内で、例えば、イントラＥ−ＵＴＲＡＮ、イントラＵＴＲＡＮ、Ｅ−ＵＴＲＡＮからＵＴＲＡＮへ、ＵＴＲＡＮからＥ−ＵＴＲＡＮへ、またはＥ−ＵＴＲＡＮからＨＲＰＤへ、行われ得る。すでに確立されたＩＭＳ緊急呼のハンドオーバはまた、ＴＳ２３．２１６に記載されているように、ＳＲＶＣＣを使用してＰＳ領域からＣＳ領域へ行われ得る。ソース側で緊急呼のロケーションサポートが必要とされる状況でそのようなイベントが起こると、ターゲット側ではロケーション・サービスの連続性が必要とされ得る。この場合、ソース側及びターゲット側で採用されるロケーション・ソリューションは、同じままであるか、または変わり得る。さらに、ロケーション・ソリューションが変わるか否かにかかわらず、関連する（１つまたは複数の）ロケーション・サーバ（例えば、ＧＭＬＣ、ＬＲＦ、Ｅ−ＳＬＰ）の何らかの再構成が実行され得る。
【００７４】
上記の説明の大部分では、ネットワーク事業者が１つのＬＲＦを採用して緊急呼をサポートする場合を仮定した。ネットワーク事業者は、複数のＬＲＦを採用して、異なる地理的領域においてＰＳＡＰの異なるグループとインターフェースし、及び／または負荷分散をサポートし得る。複数のＬＲＦが存在するときでも、ＬＲＦを除いては、コア・ネットワーク中のネットワーク・エンティティ（例えば、ＭＭＥ、ＳＧＳＮ、ＭＳＣ、及びＧＭＬＣ）に影響を及ぼすことなしにロケーション連続性が維持され得る。
【００７５】
１つの設計では、中央エンティティが、ある接続（例えば、緊急ＩＰ接続）を有する各ＵＥであって、コントロール・プレーン・ロケーション・ソリューションが必要とされ得る各ＵＥの現在のサービング・ノードの識別情報を維持し得る。中央エンティティは、物理的にＬＲＦの一部でもよく、ＬＲＦとは別個でもよい。中央エンティティは、中央ロケーション・レジスタ（ＣＬＲ）と呼ばれることがあり、１つまたは複数のＬＲＦが存在するときにＵＥのロケーション連続性をサポートし得る。
【００７６】
図８に、ＵＥ１１０が、コントロール・プレーン・ロケーション・ソリューションが各サービング・ノードのために使用される複数のハンドオーバに関与する例示的なシナリオ８００を示す。ＵＥ１１０は、ＰＤＮゲートウェイまたはＧＧＳＮ８５０を介して緊急ＩＰ接続（例えば、緊急ＰＤＰコンテキストまたは緊急ＰＤＮ接続）を確立し得る（ステップ１）。ＩＰ接続確立中に、ＵＥ１１０のサービング・ノード８１４（例えば、ＭＭＥまたはＳＧＳＮ）は、ＵＴＲＡＮ／ＧＥＲＡＮアクセスまたはＥ−ＵＴＲＡＮアクセスのためのＮＩ−ＬＲロケーションプロシージャを呼び出し得、ＮＩ−ＬＲロケーションプロシージャは、サービング・ノード８１４とＵＥ１１０との識別情報の更新をＭＡＰ ＳＬＲメッセージ中でロケーション・サーバ８１６（例えば、ＧＭＬＣ）に転送させ得る（ステップ２ａ）。次いで、ロケーション・サーバ８１６は、例えば、ＬＲＦへの更新と同様の方法で、更新をＣＬＲ８９０に転送し得る（ステップ２ｂ）。
【００７７】
１つの設計では、Ｅ−ＣＳＣＦ８５４は、（Ｅ−ＣＳＣＦ８５４に知られている場合）現在のサービングセルまたは現在のＵＥロケーションに基づいてすべての利用可能なＬＲＦの中からＬＲＦ８７０を選択し得、ＵＥ１１０のＩＭＳ緊急呼にＬＲＦ８７０を割り当て得る。この設計により、ＬＲＦを、ワイヤレス・ネットワークの特定の領域をサービスすることに限定することが可能になり得る。別の設計では、Ｅ−ＣＳＣＦ８５４は、サービング・ノード（例えば、ＭＭＥまたはＳＧＳＮ）に、固定の関連付けのないＬＲＦを動的に割り当て得る。この設計により、利用可能なＬＲＦがワイヤレス・ネットワーク中の負荷を共有することが可能になり得る。いずれの場合も、ＵＥ１１０は、ＩＭＳ緊急呼のためにＰＤＮゲートウェイ／ＧＧＳＮ８５０、Ｐ−ＣＳＣＦ８５２、Ｅ−ＣＳＣＦ８５４、及びＭＧＣＦ８５６を介してＰＳＡＰ８８０と通信し得る（ステップ３）。
【００７８】
ＵＥ１１０は、サービング・ノード８１４から新しいサービング・ノード８２４（例えば、ＭＭＥ、ＳＧＳＮ、またはＭＳＣサーバ）にハンドオーバされ得る（ステップ４）。図７中のメッセージ・フロー７００を使用して、サービング・ノード８２４とＵＥ１１０との識別情報の更新をソース側のロケーション・サーバ８１６（図８に図示せず）に、またはターゲット側のロケーション・サーバ８２６（例えば、ＧＭＬＣ）に転送し得る（ステップ５ａ）。更新を受信したロケーション・サーバは、更新をＣＬＲ８９０にフォワーディングし、次いで、ＣＬＲ８９０は、ＵＥ１１０の現在のサービング・ノードに関して通知され得る（ステップ５ｂ）。
【００７９】
ＵＥ１１０はサービング・ノード８２４から新しいサービング・ノード８３４にハンドオーバされ得る（ステップ６）。サービング・ノード８２４が、サービング・ノード８３４とＵＥ１１０との識別情報の更新をソース側のロケーション・サーバ８２６（図８に図示せず）に転送し得るか、または、サービング・ノード８３４が、この情報をターゲット側のロケーション・サーバ８３６（例えば、ＧＭＬＣ）に転送し得る（ステップ７ａ）。更新を受信したロケーション・サーバは、更新をＣＬＲ８９０にフォワーディングし得る（ステップ７ｂ）。
【００８０】
ＬＲＦ８７０は、ＵＥ１１０のＩＭＳ緊急呼のためにＥ−ＣＳＣＦ８５４によって割り当てられ得る。ＰＳＡＰ８８０は、ＵＥ１１０のロケーション推定値が望まれるときはいつでも、ロケーション要求をＬＲＦ８７０に送信し得る（ステップ８）。ＬＲＦ８７０は、その識別情報とＵＥ識別情報とともに問合せをＣＬＲ８９０に送信し得る（ステップ９）。ＣＬＲ８９０は、サービング・ノードの識別情報がある場合、ＵＥ１１０の最も現在のサービング・ノードの識別情報を返し得る（ステップ１０）。ＣＬＲ８９０は、ＬＲＦ８７０の識別情報を記憶し得る。ＣＬＲ８９０はまた、その後、新しいサービング・ノードへの緊急ＩＰ接続または緊急呼のいずれかのハンドオーバのためにロケーション・サーバから受信され得るＵＥ１１０のサービング・ノード識別情報の任意のさらなる更新をＬＲＦ８７０にフォワーディングし得る。ＣＬＲ８９０によるこの自動更新は、ＬＲＦ８７０がロケーション要求のためにＣＬＲ８９０に問合せを送信する必要を回避し得る。ＬＲＦ８７０はＣＬＲ８９０に呼がリリースされたときを通知し得、次いで、ＣＬＲ８９０は、サービング・ノード更新をＬＲＦ８７０にフォワーディングすることを停止し得る。ＬＲＦ８７０は、ＵＥ１１０のロケーション推定値を取得するために、ロケーション・サーバ８３６を介して、及びコントロール・プレーンソリューションが使用される場合サービング・ノード８３４を介してＵＥ１１０に対してＭＴ−ＬＲロケーションプロシージャを実行し得る（ステップ１１）。
【００８１】
図８に示す方式は、ＩＭＳ緊急呼をサポートしているＬＲＦが、常にＵＥの最も現在のサービング・ノードの識別情報を有することを保証し得る。コントロール・プレーン・ロケーション・ソリューションをこのサービング・ノードのために使用する必要があるときはいつでも、この情報はハンディーになり得る。本方式はまた、ＬＲＦが、コントロール・プレーン・ロケーション・ソリューションに関連するサービング・ノードから、ユーザ・プレーン・ロケーション・ソリューションのみが使用されるサービング・ノードへのいかなるハンドオフにも気づくようになる（そのようなハンドオーバのためのソース側の更新があり得るので）ことを保証し得る。コントロール・プレーン・ロケーション・ソリューションが使用され得る新しいサービング・ノードを用いてＣＬＲによって更新されるまで、ＬＲＦは、次いでＵＥのためにユーザ・プレーン・ロケーション・ソリューションを利用し得る。ＵＥの初期サービング・ノード（すなわち、最初に緊急ＩＰ接続を与えるサービング・ノード）がユーザ・プレーン・ロケーション・ソリューションのみをサポートする場合、ＮＩ−ＬＲロケーションプロシージャは、サービング・ノード（例えば、ＳＧＳＮまたはＭＭＥ）によって呼び出されないことがあり、したがって、ＣＬＲ及びＬＲＦは更新されないことがある。しかしながら、この場合、ＬＲＦは、サービングセルに関連するアクセスタイプからユーザ・プレーン・ロケーション・ソリューションの必要を判断することができ、コントロール・プレーン・ロケーション・ソリューションが使用され得るかまたは使用されなければならないサービング・ノード（例えば、ＳＲＶＣＣ ＭＳＣサーバ）の識別情報を用いてＣＬＲによって更新されるまで、この情報を使用し続けることができる。
【００８２】
図９に、サービング・ノードによってロケーション・サービスをサポートするためのプロセス９００の設計を示す。サービング・ノードは、第１のＲＡＮから第２のＲＡＮへのＵＥのハンドオーバの指示を受信する（ブロック９１２）。ＵＥは、ハンドオーバより前に第１のＲＡＮを介してソース・サービング・ノードによってサービスされ得、ハンドオーバ後に第２のＲＡＮを介してターゲット・サービング・ノードによってサービスされ得る。ハンドオーバ後に第２のＲＡＮを介してＵＥのロケーション・サービスをサポートするために、サービング・ノードは、ターゲット・サービング・ノードの識別情報をロケーション・サーバに送信する（ブロック９１４）。
【００８３】
第１のＲＡＮは第１のＲＡＴをサポートし得、第２のＲＡＮは第２のＲＡＴをサポートし得る。１つの設計では、第１のＲＡＴは第２のＲＡＴとは異なり得る。別の設計では、第１のＲＡＴは第２のＲＡＴと同じであり得る。
【００８４】
ハンドオーバが行われるとき、ＵＥは、緊急呼または何らかの他のタイプの呼を有し得る。１つの設計では、第１のＲＡＮ及び第２のＲＡＮがＰＳ呼をサポートし得、ＵＥはＰＳ−ｔｏ−ＰＳハンドオーバを実行し得る。別の設計では、第１のＲＡＮはＰＳ呼をサポートし得、第２のＲＡＮはＣＳ呼をサポートし得、ＵＥはＰＳ−ｔｏ−ＣＳハンドオーバを実行し得る。さらに別の設計では、第１のＲＡＮはＣＳ呼をサポートし得、第２のＲＡＮはＰＳ呼をサポートし得、ＵＥはＣＳ−ｔｏ−ＰＳハンドオーバを実行する。さらに別の設計では、第１のＲＡＮ及び第２のＲＡＮはＣＳ呼をサポートし得、ＵＥはＣＳ−ｔｏ−ＣＳハンドオーバを実行し得る。
【００８５】
１つの設計では、サービング・ノードはターゲット・サービング・ノードであり得、ロケーション・サーバはハンドオーバ後にＵＥのロケーション・サービスをサポートするターゲット・ロケーション・サーバであり得る。ターゲット・サービング・ノードは、ターゲット・サービング・ノードにおいて記憶された構成情報またはＤＮＳ問合せに基づいて、ターゲット・ロケーション・サーバを判断し得る。別の設計では、サービング・ノードは、ソース・サービング・ノードであり得、ロケーション・サーバは、ハンドオーバより前にＵＥのロケーション・サービスをサポートするソース・ロケーション・サーバであり得る。
【００８６】
ターゲット・サービング・ノードは、第２のＲＡＮとアクセスタイプとに依存し得る。例えば、ターゲット・サービング・ノードは、Ｅ−ＵＴＲＡＮのＭＭＥ、ＵＴＲＡＮ ＰＳのＳＧＳＮ、ＧＥＲＡＮまたは１ｘＲＴＴのＭＳＣ、ＵＴＲＡＮ ＣＳまたはＧＥＲＡＮのＭＳＣサーバ、または何らかの他のネットワーク・エンティティであり得る。ロケーション・サーバは、ＧＭＬＣ、ＭＰＣ、ＬＲＦ、または何らかの他のネットワーク・エンティティであり得る。Ｅ−ＳＬＰは、ソース側またはターゲット側のロケーション・サーバとして働き得るが、ロケーション・サーバからＬＲＦによって受信された更新に基づいてＬＲＦによって割り当てられ、除去され得る。
【００８７】
図１０に、ロケーション・サーバによってロケーション・サービスをサポートするためのプロセス１０００の設計を示す。ロケーション・サーバは、第１のＲＡＮから第２のＲＡＮへのハンドオーバを実行するＵＥのターゲット・サービング・ノードの識別情報を受信する（ブロック１０１２）。例えば、緊急呼のために、ＵＥは、ハンドオーバより前に第１のＲＡＮを介してソース・サービング・ノードによってサービスされ得、ハンドオーバ後に第２のＲＡＮを介してターゲット・サービング・ノードによってサービスされ得る。ロケーション・サーバは、ハンドオーバ前に、またはハンドオーバ後に、またはその両方にＵＥのロケーション・サービスをサポートする（ブロック１０１４）。ロケーション・サーバは、ターゲット・サービング・ノードの識別情報を用いてＬＲＦを更新する（ブロック１０１６）。
【００８８】
１つの設計では、ロケーション・サーバは、ハンドオーバ後にＵＥのロケーション・サービスをサポートするターゲット・ロケーション・サーバであり得る。ターゲット・ロケーション・サーバは、ターゲット・サービング・ノードからターゲット・サービング・ノードの識別情報を受信し得る。別の設計では、ロケーション・サーバは、ハンドオーバ前にＵＥのロケーション・サービスをサポートするソース・ロケーション・サーバであり得る。ソース・ロケーション・サーバは、ソース・サービング・ノードからターゲット・サービング・ノードの識別情報を受信し得る。
【００８９】
図１１に、ＬＲＦによってロケーション・サービスをサポートするためのプロセス１１００の設計を示す。ＬＲＦは、第１のＲＡＮから第２のＲＡＮへのハンドオーバを実行するＵＥのターゲット・サービング・ノードの識別情報を受信する（ブロック１１１２）。ＵＥは、ハンドオーバより前に第１のＲＡＮを介してソース・サービング・ノードによってサービスされ得、ハンドオーバ後に第２のＲＡＮを介してターゲット・サービング・ノードによってサービスされ得る。ＬＲＦは、ハンドオーバ前及び後にＵＥの緊急呼をサポートし得る。ＬＲＦは、ハンドオーバ後にＵＥのロケーション・サービスをサポートするためのターゲット・ロケーション・サーバを判断する（ブロック１１１４）。ＬＲＦは、ターゲット・サービング・ノード識別情報、ＬＲＦにおいて記憶された構成情報、及び／または他の情報に基づいてターゲット・ロケーション・サーバを判断し得る。ソース・ロケーション・サーバがターゲット・ロケーション・サーバとは異なる場合、ＬＲＦは（ハンドオーバより前にＵＥのロケーション・サービスをサポートし得る）ソース・ロケーション・サーバをターゲット・ロケーション・サーバと交換する（ブロック１１１６）。ＬＲＦは、その後ターゲット・サービング・ノードの識別情報に基づいてＵＥのロケーション・セッションを開始する（ブロック１１１８）。
【００９０】
１つの設計では、ＬＲＦは、ターゲット・ロケーション・サーバからターゲット・サービング・ノードの識別情報を受信し得る。別の設計では、ＬＲＦは、ソース・ロケーション・サーバからターゲット・サービング・ノードの識別情報を受信し得る。この設計では、ＬＲＦは、ソース・ロケーション・サーバからＵＥの識別情報を受信し得、ＵＥ識別情報をターゲット・ロケーション・サーバに転送し得る。
【００９１】
図１２に、ＵＥによってロケーション・サービスを取得するためのプロセス１２００の設計を示す。ＵＥは、第１のＲＡＮから第２のＲＡＮへのハンドオーバを実行する（ブロック１２１２）。ＵＥは、ハンドオーバより前に第１のＲＡＮを介してソース・サービング・ノードによってサービスされ得、ハンドオーバ後に第２のＲＡＮを介してターゲット・サービング・ノードによってサービスされ得る。緊急呼または何らかの他のタイプの呼のために、ＵＥは、ハンドオーバより前に第１のＲＡＮと通信し、ハンドオーバ後に第２のＲＡＮと通信し得る。ハンドオーバ後にＵＥのロケーション・サービスをサポートするために、ターゲット・サービング・ノードの識別情報がハンドオーバ中にロケーション・サーバに送信され得る。ＵＥは、ハンドオーバ前に第１のＲＡＮを介してロケーション・サービスを取得する（ブロック１２１４）。ＵＥは、ハンドオーバ後に第２のＲＡＮを介してロケーション・サービスを取得する（ブロック１２１６）。ＵＥは、ターゲット・サービング・ノードの識別情報に基づいて、ハンドオーバ後に開始されるロケーション・セッションに関与する（ブロック１２１８）。
【００９２】
ＵＥはＰＳＡＰを用いた緊急呼を有し得、その呼は第１のＲＡＮから第２のＲＡＮにハンドオーバされ得る。ＵＥは、例えば、ハンドオーバ前または後に、ＵＥのロケーション推定値を取得するために、ロケーション・セッションに関与し得る。この場合、ＵＥはロケーション・サービスを取得したと考えられ得、それはＵＥのためにＰＳＡＰへのＵＥのロケーション推定値の転送を伴うことがある。
【００９３】
１つの設計では、ＵＥは、ハンドオーバより前にコントロール・プレーン・ロケーション・ソリューション（例えば、ＴＳ２３．２７１またはＪ−ＳＴＤ−０３６Ｂ）を介してロケーション・サービスを取得し、ハンドオーバ後にコントロール・プレーン・ロケーション・ソリューションを介してロケーション・サービスを取得し得る。別の設計では、ＵＥは、ハンドオーバより前にコントロール・プレーン・ロケーション・ソリューションを介してロケーション・サービスを取得し、ハンドオーバ後にユーザ・プレーン・ロケーション・ソリューション（例えば、ＳＵＰＬ）を介してロケーション・サービスを取得し得る。さらに別の設計では、ＵＥは、ハンドオーバより前にユーザ・プレーン・ロケーション・ソリューションを介してロケーション・サービスを取得し、ハンドオーバ後にコントロール・プレーン・ロケーション・ソリューションを介してロケーション・サービスを取得し得る。
【００９４】
図１３に、ＵＥ１１０、ＲＡＮ１１２、サービング・ノード１１４、ロケーション・サーバ１１６、及びＬＲＦ１７０の設計のブロック図を示す。ＲＡＮ１１２は、ＵＴＲＡＮ、Ｅ−ＵＴＲＡＮ、ＧＥＲＡＮ、１ｘＲＴＴ ＲＡＮ、ＨＲＰＤ ＲＡＮ、または何らかの他のＲＡＮであり得る。サービング・ノード１１４は、ＭＭＥ、ＳＧＳＮ、ＭＳＣ、ＭＳＣサーバ、または何らかの他のネットワーク・エンティティであり得る。ロケーション・サーバ１１６は、ＧＭＬＣ、ＭＰＣ、Ｅ−ＳＬＰ、または何らかの他のネットワーク・エンティティであり得る。簡単のために、図１３に（ｉ）ＵＥ１１０について１つコントローラ／プロセッサ１３１０、１つのメモリ１３１２、及び１つの送信機／受信機（ＴＭＴＲ／ＲＣＶＲ）１３１４、（ｉｉ）ＲＡＮ１１２について１つのコントローラ／プロセッサ１３２０、１つのメモリ１３２２、１つの送信機／受信機１３２４、及び１つの通信（Ｃｏｍｍ）ユニット１３２６、（ｉｉｉ）サービング・ノード１１４について１つのコントローラ／プロセッサ１３４０、１つのメモリ１３４２、及び１つの通信ユニット１３４４、（ｉｖ）ロケーション・サーバ１１６について１つのコントローラ／プロセッサ１３５０、１つのメモリ１３５２、及び１つの通信ユニット１３５４、ならびに（ｖ）ＬＲＦ１７０について１つのコントローラ／プロセッサ１３６０、１つのメモリ１３６２、及び１つの通信ユニット１３６４を示す。一般に、各エンティティは、任意の数のコントローラ、プロセッサ、メモリ、トランシーバ、通信ユニットなどを含み得る。
【００９５】
ダウンリンクでは、ＲＡＮ１１２中の基地局は、トラフィック・データ、メッセージ／シグナリング、及びパイロットをそれらのカバレージ・エリア内のＵＥに送信し得る。これらの様々なタイプのデータは、プロセッサ１３２０によって処理され、ダウンリンク信号を生成するために送信機１３２４によって調整され得、ダウンリンク信号はＵＥに送信され得る。ＵＥ１１０において、基地局からのダウンリンク信号は、受信され、受信機１３１４によって調整され、通信、ロケーション、及び他のサービスのための様々なタイプの情報を取得するためにプロセッサ１３１０によってさらに処理され得る。プロセッサ１３１０は、図１２中のプロセス１２００を実行し得る。メモリ１３１２及び１３２２は、それぞれＵＥ１１０及びＲＡＮ１１２のためのプログラムコード及びデータを記憶し得る。アップリンクでは、ＵＥ１１０は、トラフィック・データ、メッセージ／シグナリング、及びパイロットをＲＡＮ１１２中の基地局に送信し得る。これらの様々なタイプのデータは、プロセッサ１３１０によって処理され、アップリンク信号を生成するために送信機１３１４によって調整され得、アップリンク信号はＲＡＮ１１２に送信され得る。ＲＡＮ１１２において、ＵＥ１１０及び他のＵＥからのアップリンク信号は、受信機１３２４によって受信され、調整され、ＵＥによって送信された様々なタイプの情報を取得するために、プロセッサ１３２０によってさらに処理され得る。ＲＡＮ１１２は、通信ユニット１３２６を介して他のネットワーク・エンティティと通信し得る。
【００９６】
サービング・ノード１１４内で、プロセッサ１３４０は、ＵＥ１１０の通信及び他のサービスをサポートするための様々な機能を実行し得る。メモリ１３４２は、サービング・ノード１１４のプログラム・コード及びデータを記憶し得る。通信ユニット１３４４は、サービング・ノード１１４が他のネットワーク・エンティティと通信することを可能にし得る。プロセッサ１３４０は、図９中のプロセス９００を実行し得る。ロケーション・サーバ１１６内で、プロセッサ１３５０は、ロケーション・サーバ１１６のロケーション及び／または測位処理を実行し得る。メモリ１３５２は、ロケーション・サーバ１１６のプログラムコード及びデータを記憶し得る。通信ユニット１３５４は、ロケーション・サーバ１１６が他のエンティティと通信することを可能にし得る。プロセッサ１３５０は、図１０中のプロセス１０００を実行し得る。ＬＲＦ１７０内で、プロセッサ１３６０は、ＵＥのルーティング及びロケーションをサポートするための処理を実行し得る。メモリ１３６２は、ＬＲＦ１７０のプログラムコード及びデータを記憶し得る。通信ユニット１３６４は、ＬＲＦ１７０が他のネットワーク・エンティティと通信することを可能にし得る。プロセッサ１３６０は、図１１中のプロセス１１００を実行し得る。
【００９７】
情報及び信号は多種多様な技術及び技法のいずれかを使用して表され得ることを、当業者は理解されよう。例えば、上記の説明全体にわたって言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、及びチップは、電圧、電流、電磁波、磁界または磁性粒子、光場または光学粒子、或いはそれらの任意の組合せによって表され得る。
【００９８】
さらに、本明細書の開示に関連して説明した様々な例示的な論理ブロック、モジュール、回路、及びアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、または両方の組合せとして実装され得ることを、当業者は諒解されよう。ハードウェアとソフトウェアのこの互換性を明確に示すために、様々な例示的な構成要素、ブロック、モジュール、回路、及びステップを、上記では概してそれらの機能に関して説明した。そのような機能をハードウェアとして実装するか、ソフトウェアとして実装するかは、特定の適用例及び全体的なシステムに課せられた設計制約に依存する。当業者は、説明した機能を特定の適用例ごとに様々な方法で実装し得るが、そのような実装の決定は、本開示の範囲からの逸脱を生じるものと解釈すべきではない。
【００９９】
本明細書で説明する位置判断技法は、ワイヤレス・ワイドエリア・ネットワーク（ＷＷＡＮ）、ワイヤレス・ローカルエリア・ネットワーク（ＷＬＡＮ）、ワイヤレス・パーソナルエリア・ネットワーク（ＷＰＡＮ）などの様々なワイヤレス通信ネットワークに関連して実装され得る。「ネットワーク」及び「システム」という用語は、しばしば互換的に使用される。ＷＷＡＮは、符号分割多元接続（ＣＤＭＡ）ネットワーク、時間分割多元接続（ＴＤＭＡ）ネットワーク、周波数分割多元接続（ＦＤＭＡ）ネットワーク、直交周波数分割多元接続（ＯＦＤＭＡ）ネットワーク、シングル・キャリア周波数分割多元接続（ＳＣ−ＦＤＭＡ）ネットワーク、Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ（ＬＴＥ）ネットワーク、ＷｉＭＡＸ（ＩＥＥＥ８０２．１６）ネットワークなどであり得る。ＣＤＭＡネットワークは、ｃｄｍａ２０００、広帯域ＣＤＭＡ（Ｗ−ＣＤＭＡ）などの１つまたは複数の無線アクセス技術（ＲＡＴ）を実装し得る。ｃｄｍａ２０００は、ＩＳ−９５、ＩＳ−２０００、及びＩＳ−８５６規格を含む。ＴＤＭＡネットワークは、Global System for Mobile Communications（ＧＳＭ）、Digital Advanced Mobile Phone System（Ｄ−ＡＭＰＳ）、または何らかの他のＲＡＴを実装し得る。ＧＳＭ及びＷ−ＣＤＭＡは、「3rd Generation Partnership Project」（３ＧＰＰ）という名称の組織からの文書に記載されている。ｃｄｍａ２０００は、「3rd Generation Partnership Project 2」（３ＧＰＰ２）という名称の組織からの文書に記載されている。３ＧＰＰ及び３ＧＰＰ２の文書は公的に入手可能である。ＷＬＡＮは、ＩＥＥＥ８０２．１１ｘネットワークであり得、ＷＰＡＮは、Ｂｌｕｅｔｏｏｔｈ（登録商標）ネットワーク、ＩＥＥＥ８０２．１５ｘネットワーク、または他の何らかのタイプのネットワークであり得る。本技法はまた、ＷＷＡＮ、ＷＬＡＮ、及び／またはＷＰＡＮの任意の組合せに関して実装され得る。
【０１００】
衛星測位システム（ＳＰＳ）は、一般に、送信機から受信した信号に少なくとも部分的に基づいて地球上または地球上空のエンティティのロケーションをそれらのエンティティが判断できるように配置された送信機のシステムを含む。そのような送信機は、一般に、設定された数のチップの反復する擬似雑音（ＰＮ）コードでマークされた信号を送信し、地上ベースの制御局、ユーザ機器、及び／または宇宙ビークル上に配置され得る。特定の例では、そのような送信機は地球周回軌道衛星ビークル（ＳＶ）上に配置され得る。例えば、全地球測位システム（ＧＰＳ）、Galileo、Glonass、またはCompassなどの全地球航法衛星システム（ＧＮＳＳ）のコンスタレーション中のＳＶは、（例えば、ＧＰＳの場合のように各衛星について異なるＰＮコードを使用して、またはＧｌｏｎａｓｓの場合のように異なる周波数上の同じコードを使用して）コンスタレーション中の他のＳＶによって送信されたＰＮコードとは区別可能なＰＮコードでマーキングされた信号を送信し得る。いくつかの態様によれば、本明細書で提示した技法は、ＳＰＳについての全地球システム（例えば、ＧＮＳＳ）に限定されない。例えば、本明細書に記載する技法は、日本のQuasi-Zenith Satellite System（ＱＺＳＳ）、インドのIndian Regional Navigational Satellite System（ＩＲＮＳＳ）、中国のＢｅｉｄｏｕなどの様々な地域システム、及び／または１つまたは複数の全地球及び／または地域ナビゲーション衛星システムに関連付けられ得るか、または場合によってはそれらのシステムとともに使用することが可能な、様々なオーグメンテーション・システム（例えば、Satellite Based Augmentation System（ＳＢＡＳ））に適用され得るか、または場合によってはこれらのシステムとともに使用することが可能である。限定ではなく例として、ＳＢＡＳは、例えば、Wide Area Augmentation System（ＷＡＡＳ）、European Geostationary Navigation Overlay Service（ＥＧＮＯＳ）、Multi-functional Satellite Augmentation System（ＭＳＡＳ）、GPS Aided Geo Augmented NavigationまたはＧＰＳ及びGeo Augmented Navigation System（ＧＡＧＡＮ）など、完全性情報、差分補正などを与える（１つまたは複数の）オーグメンテーション・システムを含み得る。したがって、本明細書で使用するＳＰＳは、１つまたは複数のグローバルナビゲーション衛星システム及び／または領域ナビゲーション衛星システム、ならびに／或いは１つまたは複数のグローバル・オーグメンテーション・システム及び／または領域オーグメンテーション・システムの任意の組合せを含み得、ＳＰＳ信号は、ＳＰＳ信号、ＳＰＳ様の信号、及び／またはそのような１つまたは複数のＳＰＳに関連する他の信号を含み得る。
【０１０１】
本明細書で使用するＵＥは、セルラーまたは他のワイヤレス通信デバイス、パーソナル通信システム（ＰＣＳ）デバイス、パーソナル・ナビゲーション・デバイス（ＰＮＤ）、個人情報マネージャ（ＰＩＭ）、携帯情報端末（ＰＤＡ）、ラップトップ或いはワイヤレス通信及び／またはナビゲーション信号を受信することが可能な他の適切なモバイル・デバイスなどのデバイスを指す。また、「ユーザ機器」という用語は、衛星信号受信、支援データ受信、及び／または位置に関係する処理が当該デバイスで発生するかパーソナル・ナビゲーション・デバイス（ＰＮＤ）で発生するかにかかわらず、短距離ワイヤレス、赤外線、ワイヤライン接続、または他の接続などによってＰＮＤと通信するデバイスを含むものとする。また、「ユーザ機器」は、インターネット、Ｗｉ−Ｆｉ、フェムトセル、または他のネットワークなどを介してサーバとの通信が可能で、衛星信号受信、支援データ受信、及び／または位置に関係する処理が当該デバイスで発生するか、サーバで発生するか、またはネットワークに結び付いた別のデバイスで発生するかにかかわらず、ワイヤレス通信デバイス、コンピュータ、ラップトップなどを含むすべてのデバイスを含むものとする。上記の任意の動作可能な組合せも「ユーザ機器」と見なされる。
【０１０２】
本明細書で説明する方法／実装形態は、適用例に応じて様々な手段によって実装され得る。例えば、それらは、ハードウェア、ファームウェア、ソフトウェア、またはそれらの組合せで実装され得る。ハードウェアに関与する実装形態の場合、プロセッサは、１つまたは複数の特定用途向け集積回路（ＡＳＩＣ）、デジタル信号プロセッサ（ＤＳＰ）、デジタル信号処理デバイス（ＤＳＰＤ）、プログラマブル論理デバイス（ＰＬＤ）、フィールド・プログラマブル・ゲートアレイ（ＦＰＧＡ）、汎用プロセッサ、コントローラ、マイクロコントローラ、マイクロプロセッサ、状態機械、電子デバイス、本明細書で説明する機能を実行するように設計された他の電子ユニット、或いはそれらの組合せ、例えば、ＤＳＰコアと連携する１つまたは複数のマイクロプロセッサ、複数のマイクロプロセッサ、または任意の他の好適な構成を用いて実装され得る。
【０１０３】
ファームウェア及び／またはソフトウェアに関与する実装形態の場合、本方法は、本明細書で説明する機能を実行するモジュール（例えば、プロシージャ、機能など）を用いて実装され得る。命令を有形に実施するいずれの機械可読媒体も、本明細書で説明する方法の実装において使用され得る。例えば、ファームウェア／ソフトウェアコードは、メモリに記憶され、プロセッサ／コンピュータに機能を実行させるために、プロセッサ／コンピュータによって実行され得る。メモリは、プロセッサの内部またはプロセッサの外部に実装され得る。本明細書で使用する「メモリ」という用語は、長期メモリ、短期メモリ、揮発性メモリ、不揮発性メモリ、または他のメモリのいずれかのタイプを指し、メモリの特定のタイプまたはメモリの数、或いはメモリが記憶される媒体のタイプに限定されない。
【０１０４】
ファームウェア及び／またはソフトウェアで実装する場合、機能は、１つまたは複数の命令またはコードとしてコンピュータ可読媒体上に記憶され得る。例としては、データ構造で符号化されたコンピュータ可読媒体、及びコンピュータプログラムで符号化されたコンピュータ可読媒体がある。コンピュータ可読媒体は、コンピュータプログラム製品の形態をとり得る。コンピュータ可読媒体は物理的コンピュータ記憶媒体を含む。記憶媒体は、コンピュータによってアクセスできる任意の利用可能な媒体であり得る。限定ではなく、例として、そのようなコンピュータ可読媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭまたは他の光ディスク（disk）ストレージ、磁気ディスク（disk）ストレージ、半導体ストレージ、または他の記憶デバイス、或いは命令またはデータ構造の形態で所望のプログラムコードを記憶するために使用でき、コンピュータによってアクセスできる任意の他の媒体を備えることができ、本明細書で使用するディスク（disk）及びディスク（disc）は、コンパクトディスク（disc）（ＣＤ）、レーザディスク（disc）、光ディスク（disc）、デジタル多用途ディスク（disc）（ＤＶＤ）、フロッピー(登録商標）ディスク（disk）及びブルーレイディスク（disc）を含み、ディスク（disk）は、通常、データを磁気的に再生し、ディスク（disc）は、データをレーザで光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲内に含めるべきである。
【０１０５】
コンピュータ可読媒体上での記憶に加えて、命令及び／またはデータを通信装置中に含まれる伝送媒体上の信号として与え得る。例えば、通信装置は、命令とデータとを示す信号を有するトランシーバを含み得る。命令及びデータは、１つまたは複数のプロセッサに、特許請求の範囲で概説する機能を実装させるように構成される。すなわち、通信装置は、開示した機能を実行するための情報を示す信号をもつ伝送媒体を含む。初めに、通信装置中に含まれる伝送媒体は、開示した機能を実行するための情報の第１の部分を含み得、次に、通信装置中に含まれる伝送媒体は、開示した機能を実行するための情報の第２の部分を含み得る。
【０１０６】
本開示の前述の説明は、いかなる当業者でも本開示を作成または使用することができるように提供される。本開示への様々な修正が当業者には容易に理解されるであろうが、本明細書で定義した一般的な原理は、本開示の範囲から逸脱することなく他の変形形態に適用され得る。したがって、本開示は、本明細書で説明する例及び設計に限定されるものではなく、本明細書で開示する原理及び新規の特徴に合致する最も広い範囲を与えられるべきである。
【特許請求の範囲】
【請求項１】
ロケーション・サービスをサポートする方法であって、
第１の無線アクセス・ネットワーク（ＲＡＮ）から第２のＲＡＮへのユーザ機器（ＵＥ）のハンドオーバの指示を受信することであって、前記ＵＥが、前記ハンドオーバより前に前記第１のＲＡＮを介してソース・サービング・ノードによってサービスされ、前記ハンドオーバ後に前記第２のＲＡＮを介してターゲット・サービング・ノードによってサービスされる、受信することと、
前記ハンドオーバ後に前記第２のＲＡＮを介して前記ＵＥのロケーション・サービスをサポートするために、前記ターゲット・サービング・ノードの識別情報をロケーション・サーバに送信することと、
を備える方法。
【請求項２】
前記ハンドオーバが行われるとき、前記ＵＥが緊急呼を有する請求項１に記載の方法。
【請求項３】
ハンドオーバの前記指示を前記受信することと、前記ターゲット・サービング・ノードの前記識別情報を前記送信することとが、前記ターゲット・サービング・ノードによって実行される請求項１に記載の方法。
【請求項４】
前記ロケーション・サーバが、前記ハンドオーバ後に前記ＵＥのロケーション・サービスをサポートするターゲット・ロケーション・サーバである請求項３に記載の方法。
【請求項５】
前記第１のＲＡＮがパケット交換呼をサポートし、前記第２のＲＡＮが回線交換呼をサポートし、ハンドオーバの前記指示を前記受信することと、前記ターゲット・サービング・ノードの前記識別情報を前記送信することとが前記ソース・サービング・ノードによって実行される請求項１に記載の方法。
【請求項６】
前記ロケーション・サーバが、前記ハンドオーバより前に前記ＵＥのロケーション・サービスをサポートするソース・ロケーション・サーバである請求項５に記載の方法。
【請求項７】
前記ターゲット・サービング・ノードが、モビリティ管理エンティティ（ＭＭＥ）、またはサービングＧＰＲＳサポートノード（ＳＧＳＮ）、またはモバイル交換センター（ＭＳＣ）、またはＭＳＣサーバを備える請求項１に記載の方法。
【請求項８】
前記ロケーション・サーバが、ゲートウェイモバイルロケーション・センター（ＧＭＬＣ）、またはモバイル測位センター（ＭＰＣ）、またはロケーション及びルーティング機能（ＬＲＦ）を備える請求項１に記載の方法。
【請求項９】
前記第１のＲＡＮと前記第２のＲＡＮとがパケット交換呼をサポートするか、または前記第１のＲＡＮがパケット交換呼をサポートし、前記第２のＲＡＮが回線交換呼をサポートする請求項１に記載の方法。
【請求項１０】
前記第１のＲＡＮが第１の無線アクセス技術（ＲＡＴ）をサポートし、前記第２のＲＡＮが、前記第１のＲＡＴとは異なる第２のＲＡＴをサポートする請求項１に記載の方法。
【請求項１１】
ロケーション・サービスをサポートするための装置であって、
第１の無線アクセス・ネットワーク（ＲＡＮ）から第２のＲＡＮへのユーザ機器（ＵＥ）のハンドオーバの指示を受信するための手段であって、前記ＵＥが、前記ハンドオーバより前に前記第１のＲＡＮを介してソース・サービング・ノードによってサービスされ、前記ハンドオーバ後に前記第２のＲＡＮを介してターゲット・サービング・ノードによってサービスされる、受信するための手段と、
前記ハンドオーバ後に前記第２のＲＡＮを介して前記ＵＥのロケーション・サービスをサポートするために、前記ターゲット・サービング・ノードの識別情報をロケーション・サーバに送信するための手段と、
を備える装置。
【請求項１２】
ハンドオーバの前記指示を受信するための前記手段と前記ターゲット・サービング・ノードの前記識別情報を送信するための前記手段とが前記ターゲット・サービング・ノード用である請求項１１に記載の装置。
【請求項１３】
前記ロケーション・サーバが、前記ハンドオーバ後に前記ＵＥのロケーション・サービスをサポートするターゲット・ロケーション・サーバである請求項１２に記載の装置。
【請求項１４】
ロケーション・サービスをサポートするための装置であって、
第１の無線アクセス・ネットワーク（ＲＡＮ）から第２のＲＡＮへのユーザ機器（ＵＥ）のハンドオーバの指示を受信することであって、前記ＵＥが、前記ハンドオーバより前に前記第１のＲＡＮを介してソース・サービング・ノードによってサービスされ、前記ハンドオーバ後に前記第２のＲＡＮを介してターゲット・サービング・ノードによってサービスされる、受信することと、前記ハンドオーバ後に前記第２のＲＡＮを介して前記ＵＥのロケーション・サービスをサポートするために前記ターゲット・サービング・ノードの識別情報をロケーション・サーバに送信することと、を行うように構成された少なくとも１つのプロセッサ
を備える、装置。
【請求項１５】
前記装置が前記ターゲット・サービング・ノード用である請求項１４に記載の装置。
【請求項１６】
前記ロケーション・サーバが、前記ハンドオーバ後に前記ＵＥのロケーション・サービスをサポートするターゲット・ロケーション・サーバである請求項１５に記載の装置。
【請求項１７】
少なくとも１つのコンピュータに、第１の無線アクセス・ネットワーク（ＲＡＮ）から第２のＲＡＮへのユーザ機器（ＵＥ）のハンドオーバの指示を受信させるためのコードであって、前記ＵＥが、前記ハンドオーバより前に前記第１のＲＡＮを介してソース・サービング・ノードによってサービスされ、前記ハンドオーバ後に前記第２のＲＡＮを介してターゲット・サービング・ノードによってサービスされる、受信させるためのコードと、
前記少なくとも１つのコンピュータに、前記ハンドオーバ後に前記第２のＲＡＮを介して前記ＵＥのロケーション・サービスをサポートするために前記ターゲット・サービング・ノードの識別情報をロケーション・サーバに送信させるためのコードと、
を備えるコンピュータ可読媒体
を備える、コンピュータプログラム製品。
【請求項１８】
ロケーション・サービスをサポートする方法であって、
ロケーション・サーバにおいてユーザ機器（ＵＥ）のターゲット・サービング・ノードの識別情報を受信することであって、前記ＵＥが、第１の無線アクセス・ネットワーク（ＲＡＮ）から第２のＲＡＮへのハンドオーバを実行し、前記ＵＥが、前記ハンドオーバより前に前記第１のＲＡＮを介してソース・サービング・ノードによってサービスされ、前記ハンドオーバ後に前記第２のＲＡＮを介して前記ターゲット・サービング・ノードによってサービスされる、受信することと、
前記ロケーション・サーバによって、前記ハンドオーバ前に、または前記ハンドオーバ後に、またはその両方に、前記ＵＥのロケーション・サービスをサポートすることと
を備える、方法。
【請求項１９】
前記ハンドオーバが行われるとき、前記ＵＥが緊急呼を有する請求項１８に記載の方法。
【請求項２０】
前記ロケーション・サーバが、前記ハンドオーバ後に前記ＵＥのロケーション・サービスをサポートするターゲット・ロケーション・サーバである請求項１８に記載の方法。
【請求項２１】
前記ターゲット・サービング・ノードの前記識別情報が前記ターゲット・サービング・ノードから受信される請求項２０に記載の方法。
【請求項２２】
前記第１のＲＡＮがパケット交換呼をサポートし、前記第２のＲＡＮが回線交換呼をサポートし、前記ロケーション・サーバが、前記ハンドオーバ前に前記ＵＥのロケーション・サービスをサポートするソース・ロケーション・サーバである請求項１８に記載の方法。
【請求項２３】
前記ターゲット・サービング・ノードの前記識別情報が前記ソース・サービング・ノードから受信される請求項２２に記載の方法。
【請求項２４】
前記ロケーション・サーバによって前記ターゲット・サービング・ノードの前記識別情報を用いてロケーション及びルーティング機能（ＬＲＦ）を更新すること
をさらに備える請求項１８に記載の方法。
【請求項２５】
ロケーション・サービスをサポートするための装置であって、
ロケーション・サーバにおいてユーザ機器（ＵＥ）のターゲット・サービング・ノードの識別情報を受信するための手段であって、前記ＵＥが、第１の無線アクセス・ネットワーク（ＲＡＮ）から第２のＲＡＮへのハンドオーバを実行し、前記ＵＥが、前記ハンドオーバより前に前記第１のＲＡＮを介してソース・サービング・ノードによってサービスされ、前記ハンドオーバ後に前記第２のＲＡＮを介して前記ターゲット・サービング・ノードによってサービスされる、受信するための手段と、
前記ロケーション・サーバによって、前記ハンドオーバ前に、または前記ハンドオーバ後に、またはその両方に前記ＵＥのロケーション・サービスをサポートするための手段と、
を備える装置。
【請求項２６】
前記ロケーション・サーバが、前記ハンドオーバ後に前記ＵＥのロケーション・サービスをサポートするターゲット・ロケーション・サーバであり、前記ターゲット・サービング・ノードの前記識別情報が前記ターゲット・サービング・ノードから受信される請求項２５に記載の装置。
【請求項２７】
前記ロケーション・サーバによって前記ターゲット・サービング・ノードの前記識別情報を用いてロケーション及びルーティング機能（ＬＲＦ）を更新するための手段をさらに備える請求項２５に記載の装置。
【請求項２８】
ロケーション・サービスをサポートする方法であって、
ロケーション及びルーティング機能（ＬＲＦ）においてユーザ機器（ＵＥ）のターゲット・サービング・ノードの識別情報を受信することであって、前記ＵＥが、第１の無線アクセス・ネットワーク（ＲＡＮ）から第２のＲＡＮへのハンドオーバを実行し、前記ＵＥが、前記ハンドオーバより前に前記第１のＲＡＮを介してソース・サービング・ノードによってサービスされ、前記ハンドオーバ後に前記第２のＲＡＮを介して前記ターゲット・サービング・ノードによってサービスされる、受信することと、
前記ハンドオーバ後に前記ＵＥのロケーション・サービスをサポートするためのターゲット・ロケーション・サーバを判断することと
を備える方法。
【請求項２９】
前記ＬＲＦが、前記ハンドオーバの前及び後に前記ＵＥの緊急呼をサポートする請求項２８に記載の方法。
【請求項３０】
前記ターゲット・サービング・ノードの前記識別情報が前記ターゲット・ロケーション・サーバから受信される請求項２８に記載の方法。
【請求項３１】
前記第１のＲＡＮがパケット交換呼をサポートし、前記第２のＲＡＮが回線交換呼をサポートし、前記ターゲット・サービング・ノードの前記識別情報が、前記ハンドオーバより前に前記ＵＥのロケーション・サービスをサポートするソース・ロケーション・サーバから受信される請求項２８に記載の方法。
【請求項３２】
前記ソース・ロケーション・サーバから前記ＵＥの識別情報を受信することと、
前記ＵＥの前記識別情報を前記ＬＲＦから前記ターゲット・ロケーション・サーバに転送することとをさらに備える請求項３１に記載の方法。
【請求項３３】
ソース・ロケーション・サーバが前記ターゲット・ロケーション・サーバとは異なる場合、前記ソース・ロケーション・サーバを前記ターゲット・ロケーション・サーバと交換することをさらに備える請求項２８に記載の方法。
【請求項３４】
前記ターゲット・サービング・ノードの前記識別情報に基づいて前記ＵＥのロケーション・セッションを開始すること
をさらに備える請求項２８に記載の方法。
【請求項３５】
ロケーション・サービスをサポートするための装置であって、
ロケーション及びルーティング機能（ＬＲＦ）においてユーザ機器（ＵＥ）のターゲット・サービング・ノードの識別情報を受信するための手段であって、前記ＵＥが、第１の無線アクセス・ネットワーク（ＲＡＮ）から第２のＲＡＮへのハンドオーバを実行し、前記ＵＥが、前記ハンドオーバより前に前記第１のＲＡＮを介してソース・サービング・ノードによってサービスされ、前記ハンドオーバ後に前記第２のＲＡＮを介して前記ターゲット・サービング・ノードによってサービスされる、受信するための手段と、
前記ハンドオーバ後に前記ＵＥのロケーション・サービスをサポートするためのターゲット・ロケーション・サーバを判断するための手段と、
を備える装置。
【請求項３６】
前記ターゲット・サービング・ノードの前記識別情報が前記ターゲット・ロケーション・サーバから受信される請求項３５に記載の装置。
【請求項３７】
前記ソース・ロケーション・サーバから前記ＵＥの識別情報を受信するための手段と、
前記ＵＥの前記識別情報を前記ＬＲＦから前記ターゲット・ロケーション・サーバに転送するための手段と、
をさらに備える請求項３５に記載の装置。
【請求項３８】
前記ターゲット・サービング・ノードの前記識別情報に基づいて前記ＵＥのロケーション・セッションを開始するための手段をさらに備える請求項３５に記載の装置。
【請求項３９】
ロケーション・サービスを取得する方法であって、
ユーザ機器（ＵＥ）によって第１の無線アクセス・ネットワーク（ＲＡＮ）から第２のＲＡＮへのハンドオーバを実行することであって、前記ＵＥが、前記ハンドオーバより前に前記第１のＲＡＮを介してソース・サービング・ノードによってサービスされ、前記ハンドオーバ後に前記第２のＲＡＮを介してターゲット・サービング・ノードによってサービスされ、前記ハンドオーバ後に前記ＵＥのロケーション・サービスをサポートするために、前記ターゲット・サービング・ノードの識別情報がロケーション・サーバに送信される、実行することと、
前記ハンドオーバ前に前記第１のＲＡＮを介して前記ＵＥによってロケーション・サービスを取得することと、
前記ハンドオーバ後に前記第２のＲＡＮを介して前記ＵＥによってロケーション・サービスを取得することと、
を備える方法。
【請求項４０】
緊急呼のために、前記ハンドオーバより前に前記第１のＲＡＮと通信し、前記ハンドオーバ後に前記第２のＲＡＮと通信することをさらに備える請求項３９に記載の方法。
【請求項４１】
前記ハンドオーバ後に前記第２のＲＡＮを介して前記ＵＥによってロケーション・サービスを前記取得することが、
前記ターゲット・サービング・ノードの前記識別情報に基づいて前記ハンドオーバ後に開始されるロケーション・セッションのためのメッセージを交換することを備える請求項３９に記載の方法。
【請求項４２】
前記ＵＥが、前記ハンドオーバより前にユーザ・プレーン・ロケーション・ソリューションを介してロケーション・サービスを取得し、前記ハンドオーバ後にコントロール・プレーン・ロケーション・ソリューションを介してロケーション・サービスを取得する請求項３９に記載の方法。
【請求項４３】
前記ＵＥが、前記ハンドオーバより前にコントロール・プレーン・ロケーション・ソリューションを介してロケーション・サービスを取得し、前記ハンドオーバ後にユーザ・プレーン・ロケーション・ソリューションを介してロケーション・サービスを取得する請求項３９に記載の方法。
【請求項４４】
ロケーション・サービスを取得するための装置であって、
ユーザ機器（ＵＥ）によって第１の無線アクセス・ネットワーク（ＲＡＮ）から第２のＲＡＮへのハンドオーバを実行するための手段であって、前記ＵＥが、前記ハンドオーバより前に前記第１のＲＡＮを介してソース・サービング・ノードによってサービスされ、前記ハンドオーバ後に前記第２のＲＡＮを介してターゲット・サービング・ノードによってサービスされ、前記ハンドオーバ後に前記ＵＥのロケーション・サービスをサポートするために、前記ターゲット・サービング・ノードの識別情報がロケーション・サーバに送信される、実行するための手段と、
前記ハンドオーバ前に前記第１のＲＡＮを介して前記ＵＥによってロケーション・サービスを取得するための手段と、
前記ハンドオーバ後に前記第２のＲＡＮを介して前記ＵＥによってロケーション・サービスを取得するための手段と、
を備える装置。
【請求項４５】
前記ハンドオーバ後に前記第２のＲＡＮを介して前記ＵＥによってロケーション・サービスを取得するための前記手段が、
前記ターゲット・サービング・ノードの前記識別情報に基づいて前記ハンドオーバ後に開始されるロケーション・セッションのためのメッセージを交換するための手段を備える請求項４４に記載の装置。
【請求項４６】
ロケーション・サービスを取得するための装置であって、
ユーザ機器（ＵＥ）によって第１の無線アクセス・ネットワーク（ＲＡＮ）から第２のＲＡＮへのハンドオーバを実行することであって、前記ＵＥが、前記ハンドオーバより前に前記第１のＲＡＮを介してソース・サービング・ノードによってサービスされ、前記ハンドオーバ後に前記第２のＲＡＮを介してターゲット・サービング・ノードによってサービスされ、前記ハンドオーバ後に前記ＵＥのロケーション・サービスをサポートするために、前記ターゲット・サービング・ノードの識別情報がロケーション・サーバに送信される、実行することと、
前記ハンドオーバ前に前記第１のＲＡＮを介して前記ＵＥによってロケーション・サービスを取得することと、
前記ハンドオーバ後に前記第２のＲＡＮを介して前記ＵＥによってロケーション・サービスを取得することと、
を行うように構成された少なくとも１つのプロセッサを備える装置。
【請求項４７】
前記少なくとも１つのプロセッサが、前記ターゲット・サービング・ノードの前記識別情報に基づいて前記ハンドオーバ後に開始されるロケーション・セッションのためのメッセージを交換するようにさらに構成された請求項４６に記載の装置。
【請求項４８】
少なくとも１つのコンピュータに、ユーザ機器（ＵＥ）によって第１の無線アクセス・ネットワーク（ＲＡＮ）から第２のＲＡＮへのハンドオーバを実行させるためのコードであって、前記ＵＥが、前記ハンドオーバより前に前記第１のＲＡＮを介してソース・サービング・ノードによってサービスされ、前記ハンドオーバ後に前記第２のＲＡＮを介してターゲット・サービング・ノードによってサービスされ、前記ハンドオーバ後に前記ＵＥのロケーション・サービスをサポートするために、前記ターゲット・サービング・ノードの識別情報がロケーション・サーバに送信される、実行させるためのコードと、
前記少なくとも１つのコンピュータに、前記ハンドオーバ前に前記第１のＲＡＮを介して前記ＵＥによってロケーション・サービスを取得させるためのコードと、
前記少なくとも１つのコンピュータに、前記ハンドオーバ後に前記第２のＲＡＮを介して前記ＵＥによってロケーション・サービスを取得させるためのコードと
を備えるコンピュータ可読媒体を備えるコンピュータプログラム製品。
【請求項１】
ロケーション・サービスをサポートする方法であって、
第１の無線アクセス・ネットワーク（ＲＡＮ）から第２のＲＡＮへのユーザ機器（ＵＥ）のハンドオーバの指示を受信することであって、前記ＵＥが、前記ハンドオーバより前に前記第１のＲＡＮを介してソース・サービング・ノードによってサービスされ、前記ハンドオーバ後に前記第２のＲＡＮを介してターゲット・サービング・ノードによってサービスされる、受信することと、
前記ハンドオーバ後に前記第２のＲＡＮを介して前記ＵＥのロケーション・サービスをサポートするために、前記ターゲット・サービング・ノードの識別情報をロケーション・サーバに送信することと、
を備える方法。
【請求項２】
前記ハンドオーバが行われるとき、前記ＵＥが緊急呼を有する請求項１に記載の方法。
【請求項３】
ハンドオーバの前記指示を前記受信することと、前記ターゲット・サービング・ノードの前記識別情報を前記送信することとが、前記ターゲット・サービング・ノードによって実行される請求項１に記載の方法。
【請求項４】
前記ロケーション・サーバが、前記ハンドオーバ後に前記ＵＥのロケーション・サービスをサポートするターゲット・ロケーション・サーバである請求項３に記載の方法。
【請求項５】
前記第１のＲＡＮがパケット交換呼をサポートし、前記第２のＲＡＮが回線交換呼をサポートし、ハンドオーバの前記指示を前記受信することと、前記ターゲット・サービング・ノードの前記識別情報を前記送信することとが前記ソース・サービング・ノードによって実行される請求項１に記載の方法。
【請求項６】
前記ロケーション・サーバが、前記ハンドオーバより前に前記ＵＥのロケーション・サービスをサポートするソース・ロケーション・サーバである請求項５に記載の方法。
【請求項７】
前記ターゲット・サービング・ノードが、モビリティ管理エンティティ（ＭＭＥ）、またはサービングＧＰＲＳサポートノード（ＳＧＳＮ）、またはモバイル交換センター（ＭＳＣ）、またはＭＳＣサーバを備える請求項１に記載の方法。
【請求項８】
前記ロケーション・サーバが、ゲートウェイモバイルロケーション・センター（ＧＭＬＣ）、またはモバイル測位センター（ＭＰＣ）、またはロケーション及びルーティング機能（ＬＲＦ）を備える請求項１に記載の方法。
【請求項９】
前記第１のＲＡＮと前記第２のＲＡＮとがパケット交換呼をサポートするか、または前記第１のＲＡＮがパケット交換呼をサポートし、前記第２のＲＡＮが回線交換呼をサポートする請求項１に記載の方法。
【請求項１０】
前記第１のＲＡＮが第１の無線アクセス技術（ＲＡＴ）をサポートし、前記第２のＲＡＮが、前記第１のＲＡＴとは異なる第２のＲＡＴをサポートする請求項１に記載の方法。
【請求項１１】
ロケーション・サービスをサポートするための装置であって、
第１の無線アクセス・ネットワーク（ＲＡＮ）から第２のＲＡＮへのユーザ機器（ＵＥ）のハンドオーバの指示を受信するための手段であって、前記ＵＥが、前記ハンドオーバより前に前記第１のＲＡＮを介してソース・サービング・ノードによってサービスされ、前記ハンドオーバ後に前記第２のＲＡＮを介してターゲット・サービング・ノードによってサービスされる、受信するための手段と、
前記ハンドオーバ後に前記第２のＲＡＮを介して前記ＵＥのロケーション・サービスをサポートするために、前記ターゲット・サービング・ノードの識別情報をロケーション・サーバに送信するための手段と、
を備える装置。
【請求項１２】
ハンドオーバの前記指示を受信するための前記手段と前記ターゲット・サービング・ノードの前記識別情報を送信するための前記手段とが前記ターゲット・サービング・ノード用である請求項１１に記載の装置。
【請求項１３】
前記ロケーション・サーバが、前記ハンドオーバ後に前記ＵＥのロケーション・サービスをサポートするターゲット・ロケーション・サーバである請求項１２に記載の装置。
【請求項１４】
ロケーション・サービスをサポートするための装置であって、
第１の無線アクセス・ネットワーク（ＲＡＮ）から第２のＲＡＮへのユーザ機器（ＵＥ）のハンドオーバの指示を受信することであって、前記ＵＥが、前記ハンドオーバより前に前記第１のＲＡＮを介してソース・サービング・ノードによってサービスされ、前記ハンドオーバ後に前記第２のＲＡＮを介してターゲット・サービング・ノードによってサービスされる、受信することと、前記ハンドオーバ後に前記第２のＲＡＮを介して前記ＵＥのロケーション・サービスをサポートするために前記ターゲット・サービング・ノードの識別情報をロケーション・サーバに送信することと、を行うように構成された少なくとも１つのプロセッサ
を備える、装置。
【請求項１５】
前記装置が前記ターゲット・サービング・ノード用である請求項１４に記載の装置。
【請求項１６】
前記ロケーション・サーバが、前記ハンドオーバ後に前記ＵＥのロケーション・サービスをサポートするターゲット・ロケーション・サーバである請求項１５に記載の装置。
【請求項１７】
少なくとも１つのコンピュータに、第１の無線アクセス・ネットワーク（ＲＡＮ）から第２のＲＡＮへのユーザ機器（ＵＥ）のハンドオーバの指示を受信させるためのコードであって、前記ＵＥが、前記ハンドオーバより前に前記第１のＲＡＮを介してソース・サービング・ノードによってサービスされ、前記ハンドオーバ後に前記第２のＲＡＮを介してターゲット・サービング・ノードによってサービスされる、受信させるためのコードと、
前記少なくとも１つのコンピュータに、前記ハンドオーバ後に前記第２のＲＡＮを介して前記ＵＥのロケーション・サービスをサポートするために前記ターゲット・サービング・ノードの識別情報をロケーション・サーバに送信させるためのコードと、
を備えるコンピュータ可読媒体
を備える、コンピュータプログラム製品。
【請求項１８】
ロケーション・サービスをサポートする方法であって、
ロケーション・サーバにおいてユーザ機器（ＵＥ）のターゲット・サービング・ノードの識別情報を受信することであって、前記ＵＥが、第１の無線アクセス・ネットワーク（ＲＡＮ）から第２のＲＡＮへのハンドオーバを実行し、前記ＵＥが、前記ハンドオーバより前に前記第１のＲＡＮを介してソース・サービング・ノードによってサービスされ、前記ハンドオーバ後に前記第２のＲＡＮを介して前記ターゲット・サービング・ノードによってサービスされる、受信することと、
前記ロケーション・サーバによって、前記ハンドオーバ前に、または前記ハンドオーバ後に、またはその両方に、前記ＵＥのロケーション・サービスをサポートすることと
を備える、方法。
【請求項１９】
前記ハンドオーバが行われるとき、前記ＵＥが緊急呼を有する請求項１８に記載の方法。
【請求項２０】
前記ロケーション・サーバが、前記ハンドオーバ後に前記ＵＥのロケーション・サービスをサポートするターゲット・ロケーション・サーバである請求項１８に記載の方法。
【請求項２１】
前記ターゲット・サービング・ノードの前記識別情報が前記ターゲット・サービング・ノードから受信される請求項２０に記載の方法。
【請求項２２】
前記第１のＲＡＮがパケット交換呼をサポートし、前記第２のＲＡＮが回線交換呼をサポートし、前記ロケーション・サーバが、前記ハンドオーバ前に前記ＵＥのロケーション・サービスをサポートするソース・ロケーション・サーバである請求項１８に記載の方法。
【請求項２３】
前記ターゲット・サービング・ノードの前記識別情報が前記ソース・サービング・ノードから受信される請求項２２に記載の方法。
【請求項２４】
前記ロケーション・サーバによって前記ターゲット・サービング・ノードの前記識別情報を用いてロケーション及びルーティング機能（ＬＲＦ）を更新すること
をさらに備える請求項１８に記載の方法。
【請求項２５】
ロケーション・サービスをサポートするための装置であって、
ロケーション・サーバにおいてユーザ機器（ＵＥ）のターゲット・サービング・ノードの識別情報を受信するための手段であって、前記ＵＥが、第１の無線アクセス・ネットワーク（ＲＡＮ）から第２のＲＡＮへのハンドオーバを実行し、前記ＵＥが、前記ハンドオーバより前に前記第１のＲＡＮを介してソース・サービング・ノードによってサービスされ、前記ハンドオーバ後に前記第２のＲＡＮを介して前記ターゲット・サービング・ノードによってサービスされる、受信するための手段と、
前記ロケーション・サーバによって、前記ハンドオーバ前に、または前記ハンドオーバ後に、またはその両方に前記ＵＥのロケーション・サービスをサポートするための手段と、
を備える装置。
【請求項２６】
前記ロケーション・サーバが、前記ハンドオーバ後に前記ＵＥのロケーション・サービスをサポートするターゲット・ロケーション・サーバであり、前記ターゲット・サービング・ノードの前記識別情報が前記ターゲット・サービング・ノードから受信される請求項２５に記載の装置。
【請求項２７】
前記ロケーション・サーバによって前記ターゲット・サービング・ノードの前記識別情報を用いてロケーション及びルーティング機能（ＬＲＦ）を更新するための手段をさらに備える請求項２５に記載の装置。
【請求項２８】
ロケーション・サービスをサポートする方法であって、
ロケーション及びルーティング機能（ＬＲＦ）においてユーザ機器（ＵＥ）のターゲット・サービング・ノードの識別情報を受信することであって、前記ＵＥが、第１の無線アクセス・ネットワーク（ＲＡＮ）から第２のＲＡＮへのハンドオーバを実行し、前記ＵＥが、前記ハンドオーバより前に前記第１のＲＡＮを介してソース・サービング・ノードによってサービスされ、前記ハンドオーバ後に前記第２のＲＡＮを介して前記ターゲット・サービング・ノードによってサービスされる、受信することと、
前記ハンドオーバ後に前記ＵＥのロケーション・サービスをサポートするためのターゲット・ロケーション・サーバを判断することと
を備える方法。
【請求項２９】
前記ＬＲＦが、前記ハンドオーバの前及び後に前記ＵＥの緊急呼をサポートする請求項２８に記載の方法。
【請求項３０】
前記ターゲット・サービング・ノードの前記識別情報が前記ターゲット・ロケーション・サーバから受信される請求項２８に記載の方法。
【請求項３１】
前記第１のＲＡＮがパケット交換呼をサポートし、前記第２のＲＡＮが回線交換呼をサポートし、前記ターゲット・サービング・ノードの前記識別情報が、前記ハンドオーバより前に前記ＵＥのロケーション・サービスをサポートするソース・ロケーション・サーバから受信される請求項２８に記載の方法。
【請求項３２】
前記ソース・ロケーション・サーバから前記ＵＥの識別情報を受信することと、
前記ＵＥの前記識別情報を前記ＬＲＦから前記ターゲット・ロケーション・サーバに転送することとをさらに備える請求項３１に記載の方法。
【請求項３３】
ソース・ロケーション・サーバが前記ターゲット・ロケーション・サーバとは異なる場合、前記ソース・ロケーション・サーバを前記ターゲット・ロケーション・サーバと交換することをさらに備える請求項２８に記載の方法。
【請求項３４】
前記ターゲット・サービング・ノードの前記識別情報に基づいて前記ＵＥのロケーション・セッションを開始すること
をさらに備える請求項２８に記載の方法。
【請求項３５】
ロケーション・サービスをサポートするための装置であって、
ロケーション及びルーティング機能（ＬＲＦ）においてユーザ機器（ＵＥ）のターゲット・サービング・ノードの識別情報を受信するための手段であって、前記ＵＥが、第１の無線アクセス・ネットワーク（ＲＡＮ）から第２のＲＡＮへのハンドオーバを実行し、前記ＵＥが、前記ハンドオーバより前に前記第１のＲＡＮを介してソース・サービング・ノードによってサービスされ、前記ハンドオーバ後に前記第２のＲＡＮを介して前記ターゲット・サービング・ノードによってサービスされる、受信するための手段と、
前記ハンドオーバ後に前記ＵＥのロケーション・サービスをサポートするためのターゲット・ロケーション・サーバを判断するための手段と、
を備える装置。
【請求項３６】
前記ターゲット・サービング・ノードの前記識別情報が前記ターゲット・ロケーション・サーバから受信される請求項３５に記載の装置。
【請求項３７】
前記ソース・ロケーション・サーバから前記ＵＥの識別情報を受信するための手段と、
前記ＵＥの前記識別情報を前記ＬＲＦから前記ターゲット・ロケーション・サーバに転送するための手段と、
をさらに備える請求項３５に記載の装置。
【請求項３８】
前記ターゲット・サービング・ノードの前記識別情報に基づいて前記ＵＥのロケーション・セッションを開始するための手段をさらに備える請求項３５に記載の装置。
【請求項３９】
ロケーション・サービスを取得する方法であって、
ユーザ機器（ＵＥ）によって第１の無線アクセス・ネットワーク（ＲＡＮ）から第２のＲＡＮへのハンドオーバを実行することであって、前記ＵＥが、前記ハンドオーバより前に前記第１のＲＡＮを介してソース・サービング・ノードによってサービスされ、前記ハンドオーバ後に前記第２のＲＡＮを介してターゲット・サービング・ノードによってサービスされ、前記ハンドオーバ後に前記ＵＥのロケーション・サービスをサポートするために、前記ターゲット・サービング・ノードの識別情報がロケーション・サーバに送信される、実行することと、
前記ハンドオーバ前に前記第１のＲＡＮを介して前記ＵＥによってロケーション・サービスを取得することと、
前記ハンドオーバ後に前記第２のＲＡＮを介して前記ＵＥによってロケーション・サービスを取得することと、
を備える方法。
【請求項４０】
緊急呼のために、前記ハンドオーバより前に前記第１のＲＡＮと通信し、前記ハンドオーバ後に前記第２のＲＡＮと通信することをさらに備える請求項３９に記載の方法。
【請求項４１】
前記ハンドオーバ後に前記第２のＲＡＮを介して前記ＵＥによってロケーション・サービスを前記取得することが、
前記ターゲット・サービング・ノードの前記識別情報に基づいて前記ハンドオーバ後に開始されるロケーション・セッションのためのメッセージを交換することを備える請求項３９に記載の方法。
【請求項４２】
前記ＵＥが、前記ハンドオーバより前にユーザ・プレーン・ロケーション・ソリューションを介してロケーション・サービスを取得し、前記ハンドオーバ後にコントロール・プレーン・ロケーション・ソリューションを介してロケーション・サービスを取得する請求項３９に記載の方法。
【請求項４３】
前記ＵＥが、前記ハンドオーバより前にコントロール・プレーン・ロケーション・ソリューションを介してロケーション・サービスを取得し、前記ハンドオーバ後にユーザ・プレーン・ロケーション・ソリューションを介してロケーション・サービスを取得する請求項３９に記載の方法。
【請求項４４】
ロケーション・サービスを取得するための装置であって、
ユーザ機器（ＵＥ）によって第１の無線アクセス・ネットワーク（ＲＡＮ）から第２のＲＡＮへのハンドオーバを実行するための手段であって、前記ＵＥが、前記ハンドオーバより前に前記第１のＲＡＮを介してソース・サービング・ノードによってサービスされ、前記ハンドオーバ後に前記第２のＲＡＮを介してターゲット・サービング・ノードによってサービスされ、前記ハンドオーバ後に前記ＵＥのロケーション・サービスをサポートするために、前記ターゲット・サービング・ノードの識別情報がロケーション・サーバに送信される、実行するための手段と、
前記ハンドオーバ前に前記第１のＲＡＮを介して前記ＵＥによってロケーション・サービスを取得するための手段と、
前記ハンドオーバ後に前記第２のＲＡＮを介して前記ＵＥによってロケーション・サービスを取得するための手段と、
を備える装置。
【請求項４５】
前記ハンドオーバ後に前記第２のＲＡＮを介して前記ＵＥによってロケーション・サービスを取得するための前記手段が、
前記ターゲット・サービング・ノードの前記識別情報に基づいて前記ハンドオーバ後に開始されるロケーション・セッションのためのメッセージを交換するための手段を備える請求項４４に記載の装置。
【請求項４６】
ロケーション・サービスを取得するための装置であって、
ユーザ機器（ＵＥ）によって第１の無線アクセス・ネットワーク（ＲＡＮ）から第２のＲＡＮへのハンドオーバを実行することであって、前記ＵＥが、前記ハンドオーバより前に前記第１のＲＡＮを介してソース・サービング・ノードによってサービスされ、前記ハンドオーバ後に前記第２のＲＡＮを介してターゲット・サービング・ノードによってサービスされ、前記ハンドオーバ後に前記ＵＥのロケーション・サービスをサポートするために、前記ターゲット・サービング・ノードの識別情報がロケーション・サーバに送信される、実行することと、
前記ハンドオーバ前に前記第１のＲＡＮを介して前記ＵＥによってロケーション・サービスを取得することと、
前記ハンドオーバ後に前記第２のＲＡＮを介して前記ＵＥによってロケーション・サービスを取得することと、
を行うように構成された少なくとも１つのプロセッサを備える装置。
【請求項４７】
前記少なくとも１つのプロセッサが、前記ターゲット・サービング・ノードの前記識別情報に基づいて前記ハンドオーバ後に開始されるロケーション・セッションのためのメッセージを交換するようにさらに構成された請求項４６に記載の装置。
【請求項４８】
少なくとも１つのコンピュータに、ユーザ機器（ＵＥ）によって第１の無線アクセス・ネットワーク（ＲＡＮ）から第２のＲＡＮへのハンドオーバを実行させるためのコードであって、前記ＵＥが、前記ハンドオーバより前に前記第１のＲＡＮを介してソース・サービング・ノードによってサービスされ、前記ハンドオーバ後に前記第２のＲＡＮを介してターゲット・サービング・ノードによってサービスされ、前記ハンドオーバ後に前記ＵＥのロケーション・サービスをサポートするために、前記ターゲット・サービング・ノードの識別情報がロケーション・サーバに送信される、実行させるためのコードと、
前記少なくとも１つのコンピュータに、前記ハンドオーバ前に前記第１のＲＡＮを介して前記ＵＥによってロケーション・サービスを取得させるためのコードと、
前記少なくとも１つのコンピュータに、前記ハンドオーバ後に前記第２のＲＡＮを介して前記ＵＥによってロケーション・サービスを取得させるためのコードと
を備えるコンピュータ可読媒体を備えるコンピュータプログラム製品。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【公表番号】特表２０１２−５１７７４８（Ｐ２０１２−５１７７４８Ａ）
【公表日】平成２４年８月２日（２０１２．８．２）
【国際特許分類】
【出願番号】特願２０１１−５４９３４０（Ｐ２０１１−５４９３４０）
【出願日】平成２２年２月９日（２０１０．２．９）
【国際出願番号】ＰＣＴ／ＵＳ２０１０／０２３６７０
【国際公開番号】ＷＯ２０１０／０９１４２６
【国際公開日】平成２２年８月１２日（２０１０．８．１２）
【出願人】（５９５０２０６４３）クゥアルコム・インコーポレイテッド (7,166)
【氏名又は名称原語表記】ＱＵＡＬＣＯＭＭ ＩＮＣＯＲＰＯＲＡＴＥＤ
【Ｆターム（参考）】
【公表日】平成２４年８月２日（２０１２．８．２）
【国際特許分類】
【出願日】平成２２年２月９日（２０１０．２．９）
【国際出願番号】ＰＣＴ／ＵＳ２０１０／０２３６７０
【国際公開番号】ＷＯ２０１０／０９１４２６
【国際公開日】平成２２年８月１２日（２０１０．８．１２）
【出願人】（５９５０２０６４３）クゥアルコム・インコーポレイテッド (7,166)
【氏名又は名称原語表記】ＱＵＡＬＣＯＭＭ ＩＮＣＯＲＰＯＲＡＴＥＤ
【Ｆターム（参考）】
[ Back to top ]