JP5384581B2 - 緊急回線モード呼のサポート - Google Patents

Description

優先権の主張

本出願は、本願明細書の譲渡人に譲渡された、２００５年９月１５日出願の米国仮特許出願第６０／７１７，６２０号、発明の名称「Ｅ９１１／Ｅ１１２用ロケーション・サービス（ＬＣＳ）ユーザ・プレーンのサポート（LOCATION SERVICES (LCS) USER PLANE SUPPORT FOR E911/E112）」、２００５年１０月２５日出願の米国仮特許出願第６０／７３０，３１２号、発明の名称「ＳＵＰＬ１．０を用いた回線切替緊急サービス呼のサポート（SUPPORT OF CIRCUIT SWITCHED EMERGENCY SERVICES CALLS WITH SUPL 1.0）」、２００５年１２月９日出願の米国仮特許出願第６０／７４９，２９４号、発明の名称「ＳＵＰＬを用いた緊急回線モード呼のサポート（SUPPORT FOR EMERGENCY CIRCUIT MODE CALLS USING SUPL）」、および２００５年１２月９日出願の米国仮特許出願第６０／７４９，２３３号、発明の名称「緊急呼のサポートに必要なＳＵＰＬ２．０の拡張（ENHANCEMENTS IN SUPL 2.0 NEEDED TO SUPPORT EMERGENCY CALLS）」の優先権を主張するものであり、その内容を本願明細書中で参照として援用する。

本開示は、一般的に通信に関し、特に緊急呼をサポートする技術に関する。

無線通信ネットワークは、音声、映像、パケット・データ、メッセージング、ブロードキャストなどのような様々な通信サービスを提供するために広く導入されている。これらの無線ネットワークは、使用可能なネットワーク・リソースを共有することによって多数のユーザの通信をサポートすることができる多元接続ネットワークであればよい。このような多元接続ネットワークの例として、符号分割多重接続（Code Division Multiple Access：ＣＤＭＡ）ネットワーク、時分割多元接続（Time Division Multiple Access：ＴＤＭＡ）ネットワーク、周波数分割多元接続（Frequency Division Multiple Access：ＦＤＭＡ）ネットワーク、および直交ＦＤＭＡ（Orthogonal FDMA：ＯＦＤＭＡ）ネットワークが挙げられる。

無線ネットワークは一般的に、これらのネットワークにサービス加入しているユーザに対して通信をサポートする。サービス加入は、セキュリティ、ルーティング、サービス品質（ＱｏＳ）、課金などについての情報に関連付けることができる。加入関連の情報は、無線ネットワークを用いた呼の確立に使用することができる。

ユーザは、ユーザのサービス加入しているホーム・ネットワーク、またはホーム・ネットワーク以外のこともある無線ネットワークで緊急の音声電話をかけることができる。主要な課題としては、電話を受けることができる適切な緊急通報受信センター（Public Safety Answering Point：ＰＳＡＰ）へ緊急呼をルーティングすることである。これには、ユーザの仮の位置推定を取得し、この仮の位置推定に基づいて適切なＰＳＡＰを決定することが伴うであろう。ユーザがローミング中および／または任意のネットワークにサービス加入がない場合、複雑な問題となる。

したがって、当技術分野において緊急呼をサポートする技術の必要性がある。

本願明細書では、緊急回線モード呼（emergency circuit-mode call）をサポートする技術を説明する。本技術は、様々な３ＧＰＰおよび３ＧＰＰ２ネットワーク、様々なロケーション・アーキテクチャ、ならびにサービス加入のあるユーザ機器（User Equipments：ＵＥｓ）およびサービス加入のないＵＥｓに使用すればよい。

一実施形態において、ＵＥは緊急サービス用の無線ネットワークを用いて緊急回線モード呼を確立する。ＵＥは、無線ネットワークによって示されたロケーション・サーバ（location server）と対話する。ＵＥは、ＵＥの位置推定（position estimate）を取得するために、回線モード呼（circuit-mode call）の間、ロケーション・サーバを用いてユーザ・プレーン・ロケーション（user plane location）を実行する。ユーザ・プレーン・ロケーションとは、ターゲットＵＥのロケーションを決定する処理のことであり、ここではサービング中の無線ネットワークおよび／または他のネットワークによって提供されるデータ通信性能を使用して、ＵＥとロケーション・サーバとの間でシグナリングが伝達される。ユーザ・プレーン・ロケーションは、ＯＭＡセキュア・ユーザ・プレーン・ロケーション（Secure User Plane Location：ＳＵＰＬ）または３ＧＰＰ２ Ｘ．Ｓ００２４のようなユーザ・プレーン・ソリューション／アーキテクチャに基づいていてもよい。ユーザ・プレーン・ロケーションのシグナリングは、パケット・モード通信を介して実現されてもよい。ＵＥは、ＵＥの位置推定に基づいて選択されればよいＰＳＡＰへの緊急回線モード呼を確立する。ＵＥは、例えばＰＳＡＰによって要求されたときはいつでも、ＵＥの最新の位置推定を取得するように、ロケーション・サーバを用いて測位を行ってもよい。

本開示の様々な態様および実施形態を以下でさらに詳しく説明する。

緊急回線モード呼をサポートする配置１００を示す図である。 ３ＧＰＰおよび３ＧＰＰ２ネットワーク・アーキテクチャを示す図である。 ＳＵＰＬロケーションのネットワーク・アーキテクチャを示す図である。 ＳＵＰＬロケーションを用いた緊急回線モード呼のいくつかのメッセージ・フローを示す図である。 ＳＵＰＬロケーションを用いた緊急回線モード呼のいくつかのメッセージ・フローを示す図である。 ＳＵＰＬロケーションを用いた緊急回線モード呼のいくつかのメッセージ・フローを示す図である。 Ｘ．Ｓ００２４ロケーションのネットワーク・アーキテクチャを示す図である。 Ｘ．Ｓ００２４ロケーションを用いた緊急回線モード呼のメッセージ・フローを示す図である。 様々なエンティティ間の通信プロトコルを示す図である。 図２の様々なエンティティのブロック図である。

本願明細書では、回線モード緊急呼をサポートする技術を説明する。回線モード呼とは、専用のリソース（例えば、無線トラフィック・チャネル）が呼に対して割り当てられる呼をいう。回線モード呼は、回線切替呼とも称されるが、共有リソースを使用してデータがパケットで送られるパケット交換呼とは異なる。緊急回線モード呼は、緊急サービス向けの回線モード呼である。緊急回線モード呼は、緊急回線モード呼として識別されてもよく、以下で説明するようないくつかの方法において、通常の回線モード呼とは区別されればよい。緊急回線モード呼は、例えば、ユーザの適切な位置推定を取得し、緊急回線モード呼を適切なＰＳＡＰへルーティング（routing）し、サービス加入のないユーザでもサポートするなど、通常の回線モード呼とは異なる様々な特性に関連付けられてもよい。

本願明細書の説明において、「ロケーション（location）」という用語は一般的に、ターゲットのＵＥの地理的位置を取得して提供する処理のことをいう。「測位（positioning）」という用語は一般的に、ターゲットのＵＥの地理的位置推定を測定／算出する処理のことをいう。ロケーションは、適切な位置推定が既に使用可能であるかどうかによって、測位を呼び出しても呼び出さなくてもよい。位置推定は、ロケーション推定、位置決定などとも称される。

図1は、緊急回線モード呼をサポートする配置１００を示している。ユーザ機器（ＵＥ）１１０は、通信サービスを取得するため、無線アクセス・ネットワーク（radio access network：ＲＡＮ）１２０と通信する。ＵＥ１１０は、据え置き型であっても携帯型であってもよく、移動局（mobile station：ＭＳ）、端末、加入者ユニット、局、または他の用語で称されてもよい。ＵＥ１１０は、携帯電話、パーソナル・デジタル・アシスタント（ＰＤＡ）、無線デバイス、ラップトップ・コンピュータ、遠隔測定デバイス、トラッキング・デバイスなどでもよい。ＵＥ１１０は、ＲＡＮ１２０の１つ以上の基地局と通信してもよい。ＵＥ１１０はさらに、１つ以上の衛星１９０からの信号を受信してもよい。衛星１９０は、米国の全地球測位システム（Global Positioning System：ＧＰＳ）、ヨーロッパのガリレオシステム、ロシアのＧＬＯＮＡＳＳシステム、または他の衛星測位システム（satellite positioning system：ＳＰＳ）の一部でもよい。ＵＥ１１０は、ＲＡＮ１２０の基地局からの信号および／または衛星１９０からの信号を測定すればよい。ＵＥ１１０は、衛星用の擬似距離測定および／または基地局用のタイミング測定を取得すればよい。擬似距離測定および／またはタイミング測定は、アシストＧＰＳ（assisted GPS：Ａ−ＧＰＳ）、スタンドアロンＧＰＳ、アドバンスト順方向リンク三辺測量（Advanced Forward Link Trilateration：Ａ−ＦＬＴ）、強化観測時間差法（Enhanced Observed Time Difference：Ｅ−ＯＴＤ）、観測到着時間差法（Observed Time Difference Of Arrival：ＯＴＤＯＡ）、強化セルＩＤ（Enhanced Cell ID）などのような１つ以上の測位方法を用いてＵＥ１１０の位置推定を導き出すために使用されればよい。

ＲＡＮ１２０は、ＲＡＮのカバレッジ・エリア内に置かれたＵＥｓに対し無線通信を提供する。ＲＡＮ１２０は、現在ＵＥ１１０にサービング中の訪問先ネットワーク１３０に関連付けられている。訪問先ネットワークは、訪問先公衆陸上移動通信ネットワーク（Visited Public Land Mobile Network：Ｖ−ＰＬＭＮ）と呼ぶこともできる。ホームＰＬＭＮ（Ｈ−ＰＬＭＮ）と呼ぶこともできるホーム・ネットワーク１５０は、ＵＥ１１０が加入しているネットワークである。訪問先ネットワーク１３０およびホーム・ネットワーク１５０は、同じネットワークであっても別のネットワークであってもよく、別のネットワークの場合、ローミング契約があってもなくてもよい。

ネットワーク１６０は、公衆交換電話網（Public Switched Telephone Network：ＰＳＴＮ）および／または他の音声およびデータ網であればよい。ＰＳＴＮは、従来の一般旧式電話サービス（plain old telephone service：ＰＯＴＳ）用の通信をサポートする。ＰＳＡＰ１８０は、（例えば、警察、消防署、および医療機関への）緊急呼に応答する役割を担うエンティティ（entity）であり、緊急センター（Emergency Center：ＥＣ）と称することもできる。緊急呼は、ユーザが北米では９１１またはヨーロッパでは１１２のような周知の固定番号をダイアルすることで、開始されてもよい。ＰＳＡＰ１８０は、一般的に例えば国や市などの政府機関によって管理および所有されている。ＰＳＡＰ１８０は、ＰＳＴＮ１６０との通信をサポートする。

本願明細書に記載の技術は、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、およびＯＦＤＭＡネットワーク、無線ローカル・エリア・ネットワーク（wireless local area networks：ＷＬＡＮｓ）、および／または他のネットワークのような様々な無線通信ネットワークにおける緊急回線モード呼に使用すればよい。ＣＤＭＡネットワークは、広帯域符号分割多元接続（Ｗ−ＣＤＭＡ）、ｃｄｍａ２０００などのような１つ以上の無線技術を実装すればよい。ｃｄｍａ２０００は、ＩＳ−２０００、ＩＳ−８５６、およびＩＳ−９５規格をカバーする。ＴＤＭＡネットワークは、移動通信用グローバル・システム（Global System for Mobile Communications：ＧＳＭ（登録商標））、デジタル・アドバンスト移動電話システム（Digital Advanced Mobile Phone System：Ｄ−ＡＭＰＳ）などのような１つ以上の無線技術を実装すればよい。Ｄ−ＡＭＰＳは、ＩＳ−２４８およびＩＳ−５４をカバーする。Ｗ−ＣＤＭＡおよびＧＳＭは、「第３世代・パートナーシップ・プロジェクト（3rd Generation Partnership Project）」（３ＧＰＰ）という名の組織からの文書に記載されている。ｃｄｍａ２０００は、「第３世代・パートナーシップ・プロジェクト２（3rd Generation Partnership Project 2）」（３ＧＰＰ２）という名の組織からの文書に記載されている。３ＧＰＰおよび３ＧＰＰ２の文書は、公的に入手可能である。これら様々な無線技術および規格は、当技術分野では周知である。３ＧＰＰ汎用アクセス・ネットワーク（Generic Access Network：ＧＡＮ）は、３ＧＰＰ ＴＳ ４３．３１８に記載のように、回線モード接続の提供にＷＬＡＮを使用してもよい。

図２は、３ＧＰＰおよび３ＧＰＰ２ネットワーク・アーキテクチャを示している。ＵＥ１１０は、ＧＳＭ ＥＤＧＥ無線接続ネットワーク（GSM EDGE Radio Access Network：ＧＥＲＡＮ）、ユニバーサル地上無線接続ネットワーク（Universal Terrestrial Radio Access Network：ＵＴＲＡＮ）、進化型ＵＴＲＡＮ（Evolved UTRAN：Ｅ−ＵＴＲＡＮ）、ＷＬＡＮ、または他の接続ネットワークであればよい３ＧＰＰのＲＡＮ１２０ａを介して無線接続を得てもよい。３ＧＰＰ ＲＡＮ１２０ａは、基地局２２０ａ、無線ネットワーク・コントローラ／基地局コントローラ（ＲＮＣｓ／ＢＳＣｓ）２２２ａ、および図２に示されていない他のエンティティを含む。基地局は、ノードＢ、拡張ノードＢ（ｅ−Ｎｏｄｅ Ｂ）、無線基地局装置（Base Transceiver Station：ＢＴＳ）、アクセス・ポイント（ＡＰ）、または他の用語で称されてもよい。

３ＧＰＰ Ｖ−ＰＬＭＮ １３０ａは、図１の訪問先ネットワーク１３０の一実施形態であり、移動交換局（Mobile Switching Center：ＭＳＣ）２３０ａ、ゲートウェイ移動ロケーション・センター（Gateway Mobile Location Center：ＧＭＬＣ）２３２ａ、緊急サービスＳＵＰＬロケーション・プラットフォーム（Emergency Services SUPL Location Platform：Ｅ−ＳＬＰ）２３４ａ、および訪問先ＳＬＰ（Visited SLP：Ｖ−ＳＬＰ）２３６ａを含めばよい。ＧＭＬＣ２３２ａ、Ｅ−ＳＬＰ２３４ａ、およびＶ−ＳＬＰ２３６ａは、Ｖ−ＰＬＭＮ１３０ａと通信中のＵＥｓにロケーション・サービスを提供する。ＧＭＬＣ２３２ａは、（例えば、３ＧＰＰ ＴＳ ２３．２７１およびＪ−ＳＴＤ−０３６で定義されているような）従来のＧＭＬＣのいくつかの機能、ならびにロケーション用のＳＵＰＬの使用および緊急呼のルーティングに関連するいくつかの機能をサポートする。Ｅ−ＳＬＰ２３４ａおよびＶ−ＳＬＰ２３６ａは、オープン・モバイル・アライアンス（Open Mobile Alliance：ＯＭＡ）からのＳＵＰＬをサポートする。Ｅ−ＳＬＰ２３４ａは、緊急呼のロケーションの場合にホームＳＬＰ（Ｈ−ＳＬＰ）の代わりになり、ＧＭＬＣ２３２ａと結合されればよい。Ｖ−ＳＬＰ２３６ａは、Ｖ−ＰＬＭＮ１３０ａの内部または外部に置かれてもよく、ＵＥ１１０に地理的に近くにあってもよい。

ＵＥ１１０は、ＣＤＭＡ２０００ ＩＸネットワークまたは他の接続ネットワークであればよい３ＧＰＰ２ ＲＡＮ１２０ｂを介して無線アクセスを得ることもできる。３ＧＰＰ２ ＲＡＮ１２０ｂは、基地局２２０ｂ、ＢＳＣｓ２２２ｂ、および図２に示されていない他のエンティティを含む。

３ＧＰＰ２ Ｖ−ＰＬＭＮ１３０ｂは、図１の訪問先ネットワーク１３０の別の実施形態であり、ＭＳＣ２３０ｂ、移動測位センター（Mobile Positioning Center：ＭＰＣ）２３２ｂ、Ｅ−ＳＬＰ２３４ｂ、Ｖ−ＳＬＰ２３６ｂを含めばよい。ＭＰＣ２３２ｂ、Ｅ−ＳＬＰ２３４ｂ、およびＶ−ＳＬＰ２３６ｂは、Ｖ−ＰＬＭＮ１３０ｂと通信中のＵＥｓにロケーション・サービスを提供する。ＭＰＣＣ２３２ｂは、（例えば、３ＧＰＰ２ Ｘ．Ｓ０００２、ＴＩＡ−８８１、およびＪ−ＳＴＤ−０３６で定義されているような）従来のＭＰＣのいくつかの機能、ならびにロケーション用のＳＵＰＬの使用および緊急呼のルーティングに関連するいくつかの機能をサポートする。Ｅ−ＳＬＰ２３４ｂおよびＶ−ＳＬＰ２３６ｂは、ＯＭＡからのＳＵＰＬをサポートする。Ｅ−ＳＬＰ２３４ｂは、ＭＰＣ２３２ｂと結合することもできる。代替的に、または、付加的に、Ｖ−ＰＬＭＮ１３０ｂは、緊急サービス・ポジション・サーバ（Emergency Services Position Server：Ｅ−ＰＳ）２３８および訪問先ＰＳ（Ｖ−ＰＳ）２４０を含んでいてもよい。Ｅ−ＰＳ２３８およびＶ−ＰＳ２４０は、ｃｄｍａ２０００ネットワーク用のＸ．Ｓ００２４ロケーションをサポートし、ＳＵＰＬ用のＥ−ＳＬＰ ２３４ｂおよびＶ−ＳＬＰ ２３６ｂと類似しているロケーション・サーバである。Ｖ−ＳＬＰ２３６ｂおよびＶ−ＰＳ２４０は、Ｖ−ＰＬＭＮ１３０ｂの内部または外部に置かれてもよく、ＵＥ１１０に地理的に近くにあってもよい。Ｖ−ＰＬＭＮ１３０ｂは、位置決定エンティティ（Position Determining Entity：ＰＤＥ）および／または他のエンティティを含んでいてもよい。

３ＧＰＰ Ｈ−ＰＬＭＮ１５０ａは、図１のホーム・ネットワーク１５０の一実施形態であり、Ｈ−ＳＬＰ２５２ａおよび／または他のネットワーク・エンティティを含んでいればよい。３ＧＰＰ２ Ｈ−ＰＬＭＮ１５０ｂは、図１のホーム・ネットワーク１５０の別の実施形態であり、Ｈ−ＳＬＰ２５２ｂ、Ｈ−ＰＳ２５４、および／または他のネットワーク・エンティティを含んでいればよい。

ＳＵＰＬにおけるエンティティは、「セキュア・ユーザ・プレーン・ロケーション・アーキテクチャ（Secure User Plane Location Architecture）」と題されたＯＭＡ−ＡＤ−ＳＵＰＬ−Ｖ２＿０−２００６０８２３−Ｄ（Ｄｒａｆｔ Ｖｅｒｓｉｏｎ ２．０、２００６年８月２３日）、および「ユーザ・プレーン・ロケーション・プロトコル（User Plane Location Protocol）」と題されたＯＭＡ−ＴＳ−ＵＬＰ− Ｖ２＿０−２００６０９０７−Ｄ（Ｄｒａｆｔ Ｖｅｒｓｉｏｎ ２．０、２００６年９月７日）に記載されている。Ｘ．Ｓ００２４ロケーションにおけるエンティティは、「ＩＰベースのロケーション・サービス（IP-Based Location Services）」と題された３ＧＰＰ２ Ｘ．Ｓ００２４（Ｖｅｒｓｉｏｎ１．０、２００５年１０月）に記載されている。これらの文書は、公的に入手可能である。

簡略化のため、図２では、以下の説明に関係する３ＧＰＰおよび３ＧＰＰ２のエンティティのいくつかのみを示している。３ＧＰＰおよび３ＧＰＰ２ネットワークは、それぞれ３ＧＰＰおよび３ＧＰＰ２によって定義されている他のエンティティを含んでいてもよい。

無線ネットワークは、制御プレーン（control plane：ＣＰ）ソリューションおよび／またはユーザ・プレーン（user plane：ＵＰ）ソリューションを使用して、ロケーション・サービス（ＬＣＳ）をサポートすればよい。制御プレーン（シグナリング・プレーンとも呼ばれる）は、上位層のアプリケーション用にシグナリングを搬送するメカニズムであり、一般的にネットワーク特有のプロトコル、インターフェース、およびシグナリング・メッセージを用いて実装される。ユーザ・プレーンは、上位層のアプリケーション用にシグナリングを搬送するメカニズムであり、ユーザ・データグラム・プロトコル（User Datagram Protocol：ＵＤＰ）、伝送制御プロトコル（Transmission Control Protocol：ＴＣＰ）、およびインターネット・プロトコル（Internet Protocol：ＩＰ）のようなプロトコルを用いて実装されるユーザ・プレーン・ベアラを使用するメカニズムである。ロケーション・サービスおよび測位をサポートするメッセージは、制御プレーン・アーキテクチャにおいてはシグナリングの一部として、ユーザ・プレーン・アーキテクチャにおいてはデータ（ネットワークの観点から）の一部として搬送される。ただし、メッセージの内容は、双方のアーキテクチャにおいて同一または同様であってもよい。３ＧＰＰ制御プレーンは、３ＧＰＰ ＴＳ ２３．２７１、ＴＳ ４３．０５９、およびＴＳ ２５．３０５に記載されている。３ＧＰＰ２制御プレーンは、ＩＳ−８８１および３ＧＰＰ２ Ｘ．Ｓ０００２に記載されている。ＳＵＰＬおよびｐｒｅ−ＳＵＰＬは、ＯＭＡからの文書に記載されている。

無線ネットワークにおける緊急回線モード呼は、一般的にユーザ・プレーン・ソリューションよりも、制御プレーン・ソリューションを使用してサポートされる。このことは、すべてのロケーション関連のアプリケーションをサポートするためには、ネットワーク・オペレータは制御プレーンおよびユーザ・プレーン・ソリューションの両方を導入する必要があり得ることを意味している。

本願明細書に記載の技術は、制御プレーンおよびユーザ・プレーン・ソリューションの両方を使用して、緊急回線モード呼をサポートする。これについては、多くの３ＧＰＰおよび３ＧＰＰ２ネットワーク・オペレータが制御プレーンＬＣＳの一部をサポートするエンティティを導入およびサポートしているので、実装を簡素化するうえでメリットとなるであろう。ただし、この技術はごく一部の制御プレーン・ソリューションを組み込んでいるだけなので、コストの大幅な増加およびユーザ・プレーン・ソリューションへのアップグレード時の複雑化を避けられる。特に、ネットワーク・オペレータは、完全な制御プレーン・ソリューションを導入しなくても、すべてのロケーション関連のアプリケーションをサポートできるであろう。

この技術は、登録されたＵＥｓの他に未登録のＵＥｓもサポートする。登録されたＵＥとは、ホーム・ネットワークに登録したＵＥであり、ホーム・ネットワークを介して認証されることができる。未登録のＵＥは、どのネットワークにも登録していないＵＥであり、認証されない。３ＧＰＰ ＵＥには、汎用ＩＣカード（Universal Integrated Circuit Card：ＵＩＣＣ）または加入者識別モジュール（Subscriber Identity Module：ＳＩＭ）が装備されていればよい。３ＧＰＰ２ ＵＥには、ユーザ識別モジュール（User Identity Module：ＵＩＭ）が装備されているとよい。ＵＩＣＣ、ＳＩＭ、またはＵＩＭは、一般的に１人の加入者に特有のものであり、個人情報、加入情報、および／または他の情報を格納すればよい。ＵｌＣＣレスＵＥは、ＵＩＣＣまたはＳＩＭのないＵＥである。ＵＩＭレスＵＥは、ＵＩＭのないＵＥである。ＵＩＣＣ／ＵＩＭレスＵＥは、どのネットワークにも登録されておらず、加入がなく、ホーム・ネットワークがなく、認証証明書がなく（例えば、秘密鍵がない）、主張されているいかなる識別も確認できないため、ロケーション・サービスのリスク傾向をさらに高める。

図３は、ＳＵＰＬロケーションを用いた緊急回線モード呼のネットワーク・アーキテクチャ３００の実施形態を示している。ネットワーク・アーキテクチャ３００は、３ＧＰＰおよび３ＧＰＰ２ネットワークの両方に適用できる。簡略化するために、図３では、ＳＵＰＬを使用した緊急回線モード呼のサポートに関連するエンティティおよびインターフェースのみを示している。一般に、ネットワーク・アーキテクチャ３００は、回線モード呼および／またはロケーションをサポートする他のエンティティを含んでいてもよい。

ＵＥ１１０は、ＳＵＰＬにおいてＳＵＰＬ有効端末（SUPL enabled terminal：ＳＥＴ）と称される。ＲＡＮ１２０は、３ＧＰＰ ＲＡＮ１２０ａ、３ＧＰＰ２ ＲＡＮ１２０ｂ、または他の接続ネットワークとすればよい。Ｅ−ＳＬＰ２３４は、ロケーション・サービス向けの様々な機能を実行するＳＵＰＬロケーション・センター（SUPL Location Center：Ｅ−ＳＬＣ）３１２、およびＵＥｓの測位をサポートするＳＵＰＬ測位センター（SUPL Positioning Center：Ｅ−ＳＰＣ）３１４を含んでいてもよい。Ｖ−ＳＬＰ２３６は、同様に、Ｖ−ＳＬＣ３２２およびＶ−ＳＰＣ３２４を含んでいてもよい。Ｅ−ＳＬＰ２３４は、ＭＰＣ／ＧＭＬＣ２３２と関連付けられ、緊急呼用のロケーションの場合、Ｈ−ＰＬＭＮ１５０のＨ−ＳＬＰ２５２と置き換わる。Ｖ−ＳＬＰ２３６は、ＵＥ１１０のさらに近くにあり、および／またはＵＥ１１０をさらに良くロケートできればよい。ほとんどの場合、Ｅ−ＳＬＰ２３４だけで十分であり、Ｖ−ＳＬＰ２３６は必要ない。

ＳＵＰＬは、ＳＰＣを用いた測位用に、ＳＥＴとＳＬＰとの間で２つの通信モードをサポートしている。プロキシ・モードでは、ＳＰＣはＳＥＴと直接通信せず、ＳＬＰがＳＥＴとＳＰＣとの間のプロキシとして動作する。非プロキシ・モードでは、ＳＰＣはＳＥＴと直接通信する。

ＰＳＴＮ１６０は、ＭＳＣ２３０からＰＳＡＰ１８０へ緊急回線モード呼を確立するために使用される、選択ルータ（Ｓ／Ｒ）２６０および／または他のタンデムを含んでいてもよい。Ｓ／Ｒ２６０は、ＰＳＡＰ１８０に属せばよく、ＰＳＡＰｓのセットによって共有され、ＰＳＡＰのセットに接続されればよい。ＵＥ１１０は、ＭＳＣ２３０およびＳ／Ｒ２６０を介してＰＳＡＰ１８０と通信すればよい。

図３は、様々なエンティティ間のインターフェースも示している。ＵＥ１１０とＲＡＮ１２０との間、およびＲＡＮ１２０とＭＳＣ２３０との間の呼関連のインターフェースは、ネットワーク特有のものである。ＭＳＣ２３０と、Ｓ／Ｒ２６０と、ＰＳＡＰ１８０との間の呼関連のインターフェースは、多周波／ＩＳＤＮユーザ・パート／ＩＳＤＮ（Multi Frequency/ISDN User Part/ISDN：ＭＦ／ＩＳＵＰ／ＩＳＤＮ）であってもよい。

ＵＥ１１０と、Ｅ−ＳＬＰ２３４と、Ｖ−ＳＬＰ２３６との間のロケーション関連のインターフェースは、ＳＵＰＬユーザ・プレーン・ロケーション・プロトコル（UserPlane Location Protocol：ＵＬＰ）であればよい。Ｅ−ＳＬＰ２３４とＶ−ＳＬＰ２３６との間のインターフェースは、ローミング・ロケーション・プロトコル（Roaming Location Protocol：ＲＬＰ）であればよい。ＭＳＣ２３０とＧＭＬＣ／ＭＰＣ２３２との間のインターフェースは、移動通信応用部（Mobile Application Part：ＭＡＰ）であればよい。ＭＰＣ／ＧＭＬＣ２３２とＥ−ＳＬＰ２３４との間のインターフェースは、ＳＵＰＬエージェントとＨ−ＳＬＰとの間のＬｅ／Ｌｌインターフェース、およびＳＵＰＬ１．０におけるＳＬＰｓのペア間のＬｒ／ＬＣＳ−zインターフェースの両方に似ている。したがって、ＭＰＣ／ＧＭＬＣ２３２とＥ−ＳＬＰ２３４との間のインターフェースは、移動ロケーションプロトコル（Mobile Location Protocol：ＭＬＰ）、ＲＬＰ、ＭＬＰまたはＲＬＰの拡張バージョン、または他のインターフェースを使用してサポートされればよい。ＲＬＰについては、ＲＬＰトランザクション開始に関してＧＭＬＣサポートが既に定義されている。ＭＬＰについては、ＧＭＬＣが通常トランザクション受信者として動作する。Ｅ−ＳＬＰ２３４とＰＳＡＰ１８０との間のインターフェースは、Ｊ−ＳＴＤ−０３６ ｒｅｖ．Ｂで定義されているＥ２インターフェース、ＭＬＰ、ＨＴＴＰインターフェース、または他の何らかのインターフェースであればよい。

ＳＵＰＬロケーションを用いた３ＧＰＰおよび３ＧＰＰ２での緊急回線モード呼用のメッセージ・フローの例を以下でいくつか説明する。明確にするために、関連性の少ない（例えば、ＲＡＮ１２０およびＳ／Ｒ２６０）エンティティは、これらのメッセージ・フローから省略されているが、説明には含まれる。これらのメッセージ・フローでは、ＵＥ１１０にＵＩＣＣまたはＵＩＭがあり、Ｖ−ＰＬＭＮ１３０とＨ−ＰＬＭＮ１５０との間にはローミング契約があることを前提としている。さらにメッセージ・フローは、ＵＥ１１０が、（緊急呼用の）回線モード、および（例えばロケーション用の）パケット・モード通信の両方を並列でサポートしていることを前提としている。この性能は現在、ＵＭＴＳおよびＧＳＭ／ＧＰＲＳにおける３ＧＰＰ、およびｃｄｍａ２０００における３ＧＰＰ２によって、登録されたユーザに対して有効になっている。

１．ＳＵＰＬロケーションを用いた３ＧＰＰでの緊急回線モード呼
図４は、呼設定の前にロケーションが開始されている、ＳＵＰＬを使用した３ＧＰＰでの緊急回線モード呼のメッセージ・フロー４００の実施形態を示している。ステップ１において、ＵＥ１１０は、緊急サービス呼の要求（北米ではＥ９１１またはヨーロッパではＥ１１２）を３ＧＰＰのＶ−ＰＬＭＮ１３０ａのＭＳＣ２３０ａに送る。この要求は、緊急サービス呼（emergency services call：ＥＳＣ）呼出しと称する。

ステップ２において、ＭＳＣ２３０ａは、例えばＵＥから受信されるＵＥ加入情報またはＵＥ機能情報に基づいて、あるいはＶ−ＰＬＭＮ１３０ａのポリシーとして、ＵＥ１１０がＳＵＰＬ測位をサポートしていると見なすか、または決定すればよい。次いで、ＭＳＣ２３０ａは、Ｅ−ＳＬＰ２３４ａと関連する（例えば、Ｅ−ＳＬＰ２３４ａを含む、またはＥ−ＳＬＰ２３４ａに接続されている）ネットワーク中にあるＧＭＬＣ２３２ａに、ＭＡＰ加入者ロケーション・レポート（Subscriber Location Report：ＳＬＲ）メッセージを送る。ＭＡＰ ＳＬＲは、ＧＭＬＣ２３２ａの中に緊急呼記録（およびＭＳＣ２３０ａとの関連）を作成するため、およびＧＭＬＣからＰＳＡＰルーティング情報を取得するために使用される。ＭＡＰ ＳＬＲは、ＵＥの識別、サービング・セルの識別（ＩＤ）、および／または他の情報を含んでいればよい。ＵＥの識別は、国際移動加入者識別（International Mobile Subscriber Identity：ＩＭＳＩ）、移動加入者ＩＳＤＮ番号（Mobile Subscriber ISDN number：ＭＳＩＳＤＮ）、国際移動機器識別（International Mobile Equipment Identity：ＩＭＥＩ）、および／または他の何らかの識別であればよい。他の情報には、ＵＥまたはネットワークからの測定値が含まれていればよい。この測定値は、ＵＥの位置推定を算出するために使用されればよい。北米での呼では、ＭＳＣ２３０ａが、緊急サービス・ルーティング・キー（Emergency Services Routing Key：ＥＳＲＫ）または緊急サービス・ルーティング・ディジット（Emergency Services Routing Digits：ＥＳＲＤ）を割り当てればよく、次いでこれをＭＡＰ ＳＬＲに含めることになる。ＥＳＲＤは、ＰＳＡＰを識別するダイアルできない加入者番号である。ＥＳＲＫは、ＰＳＡＰへのルーティングに使用されればよい、ダイアルできない加入者番号である。各ＰＳＡＰは、１つのＥＳＲＤおよびＥＳＲＫのプールに関連付けられればよい。ＵＥによるこのＰＳＡＰへの緊急呼では、緊急呼の間プールからの１つのＥＳＲＫがＵＥに割り当てられ、ＰＳＡＰ、ＧＭＬＣおよび／またはＭＳＣ、なら
びにＵＥの識別に使用されればよい。

ステップ３において、ＧＭＬＣ２３２ａは、呼の記録を作成する。ＧＭＬＣ２３２ａは、ステップ２において受信されたロケーション情報に基づいて、ＵＥ１１０の仮の位置推定を決定すればよい。ロケーション情報は、セルＩＤ、測定値、位置推定などを含んでいればよい。仮の位置推定とは、一般的に呼のルーティングに使用されるおおよその位置のことをいう。ＧＭＬＣ２３２ａは、ＵＥ１１０の仮の位置推定を取得する前に、ステップ８からステップ１３を開始してもよい。ＧＭＬＣ２３２ａは、（取得された場合）仮の位置推定に基づいて、またはステップ２において受信されたサービング・セルＩＤに基づいて、ＰＳＡＰを選択すればよい。これによって、選択されたＰＳＡＰは、ＵＥ１１０が置かれている地理的エリアからの緊急呼に確実に対応できるようになる。北米での呼では、ＧＭＬＣ２３２ａは、ＥＳＲＤまたはＥＳＲＫを割り当てて、選択されたＰＳＡＰを示せばよい。以下の説明において、ＰＳＡＰ１８０が選択されたＰＳＡＰである。ＧＭＬＣ２３２ａは、後でＰＳＡＰからのロケーション要求に使用される正確な初期位置推定を取得するために、ステップ８からステップ１３を事前に開始してもよい。初期位置推定とは、一般的に最初の正確な位置推定のことをいう。ステップ４において、ＧＭＬＣ２３２ａは、ＭＳＣ２３０ａにＭＡＰ ＳＬＲ肯定応答を返す。北米での呼では、この肯定応答は、ステップ３でＧＭＬＣ２３２ａによって割り当てられた任意のＥＳＲＤまたはＥＳＲＫを含んでいればよい。

ステップ５において、ＭＳＣ２３０ａは、ＰＳＡＰ１８０に緊急回線モード呼を送る。北米での呼では、ステップ４でＥＳＲＫまたはＥＳＲＤが返されていた場合、ステップ３でＧＭＬＣ２３２ａによってＰＳＡＰ１８０が選択される。それ以外の場合、ＭＳＣ２３０ａは、例えばＵＥ１１０の現在のまたは最初のサービング・セルに基づいて、ＰＳＡＰを決定すればよい。北米での呼では、ＭＳＣ２３０ａによってＰＳＡＰ１８０に送られる呼設定メッセージまたは指示には、ステップ４でＧＭＬＣ２３２ａによって返された、またはステップ２もしくはステップ５でＭＳＣ２３０ａによって割り当てられた任意のＥＳＲＤもしくはＥＳＲＫが含まれる。呼設定メッセージには、ＵＥ１１０へのコールバック番号（例えば、ＭＳＩＳＤＮ）が含まれていてもよい。

ステップ６において、ＭＳＣ２３０ａを介してＵＥ１１０とＰＳＡＰ１８０との間に呼が確立する。ステップ７において、ＰＳＡＰ１８０は、ＧＭＬＣ２３２ａに緊急サービス位置要求（Emergency Services Position Request）を送り、ＵＥ１１０の正確な初期位置推定を要求する。北米での呼では、ＰＳＡＰ１８０は、ステップ５で受信したＥＳＲＫまたはＥＳＲＤを使用して、ＧＭＬＣ２３２ａを識別すればよい。その場合、緊急サービス位置要求には、ＥＳＲＫおよび／またはＥＳＲＤ、ならびにコールバック番号が含まれる。ＰＳＡＰ１８０は、ＳＵＰＬがロケーション用に使用されていることを認識する必要はない。

ステップ８において、ＧＭＬＣ２３２ａは、（ａ）北米の呼についてはステップ７で受信されたＥＳＲＫまたはコールバック番号、または（ｂ）他の場所での呼については他の発呼者情報（例えば、ＭＳＩＳＤＮまたはＩＭＳＩ）を使用して、ステップ３で作成された呼記録を識別する。ＧＭＬＣ２３２ａが、（例えば、ステップ８からステップ１３を事前に実行することで）ステップ３において正確な位置推定を取得していた場合、ＧＭＬＣ２３２ａは、ステップ１４においてＰＳＡＰ１８０に対してこの位置推定を直ちに返すことができ、ステップ８からステップ１３を省くことができる。それ以外の場合、ＧＭＬＣ２３２ａは、ＵＥの識別（例えば、ＭＳＩＳＤＮおよび／またはＩＭＳＩ）、セルＩＤ（分かっている場合）、要求される位置品質（quality of position：ＱｏＰ）、および／または他の情報を含めばよい緊急サービス位置要求をＥ−ＳＬＰ２３４ａに送る。ＱｏＰは、例えば位置推定の正確さおよび経過時間など、位置推定に対する要求を伝える。ＱｏＰは、ＱｏＳとも称される。

ステップ９において、Ｅ−ＳＬＰ２３４ａは、例えば（ある場合は）ステップ８で受信されたセルＩＤに基づいて、ＵＥのさらに近くにある、および／またはＵＥ１１０の測位をさらに良くサポートできるようなＶ−ＳＬＰによって測位がサポートされるべきかを判断する。サポートされるべきであれば、Ｅ−ＳＬＰ２３４ａは、Ｖ−ＳＬＰ（図４に示されていない）とシグナリングを交換する。そうでない場合、Ｅ−ＳＬＰがＨ−ＳＬＰに取って代わり、Ｅ−ＳＬＰ２３４ａは、ネットワークで始められたＳＵＰＬロケーション手順を開始させる。Ｅ−ＳＬＰ２３４ａは、まずＵＥ１１０にＳＵＰＬ ＩＮＩＴを送り、ＳＵＰＬロケーション手順を開始させる。ＳＵＰＬ ＩＮＩＴは、例えば無線アプリケーション・プロトコル（Wireless Application Protocol：ＷＡＰ）プッシュ、ショート・メッセージ・サービス（Short Message Service：ＳＭＳ）トリガを使用して、またはＥ−ＳＬＰ２３４ａがＵＥ１１０のＩＰアドレスを知っているか取得できる場合はＵＤＰ／ＩＰを使用して送信されればよい。ＳＵＰＬ ＩＮＩＴは、例えばＵＥ１１０がホーム・ネットワークにない場合、Ｅ−ＳＬＰ２３４ａがＵＥ用のＨ−ＳＬＰではない場合、または（例えば、実装を簡素化するために）Ｅ−ＳＬＰ２３４ａがＨ−ＳＬＰとして振る舞わないことを選択した場合に、Ｅ−ＳＬＰ２３４ａのＩＰアドレスを含んでいればよい。ＳＵＰＬ ＩＮＩＴは、例えばＳＵＰＬ ＩＮＩＴ通知パラメータなど、緊急サービスの表示を含んでいてもよい。非プロキシ・モードが使用される場合、ＳＵＰＬ ＩＮＩＴは、Ｅ−ＳＬＰ２３４ａまたは別のＶ−ＳＬＰに関連付けられたＳＰＣのＩＰアドレスを含んでいてもよい。その場合ＵＥ１１０は、このＳＰＣと対話して測位を実行することになる。

ステップ１０において、Ｅ−ＳＬＰ２３４ａがＵＥのＨ−ＳＬＰの場合（およびＵＥのＨ−ＳＬＰとして振る舞うように選択する場合）、ＵＥ１１０はそのＨ−ＳＬＰへの安全なＩＰ接続（secure IP connection）を確立する。しかし、Ｅ−ＳＬＰ２３４ａがＵＥ１１０のＨ−ＳＬＰではない場合、および／またはステップ９でＥ−ＳＬＰ２３４ａがＳＵＰＬ ＩＮＩＴにそのＩＰアドレスを含めている場合、ＵＥ１１０は、Ｈ−ＳＬＰの代わりにＥ−ＳＬＰ２３４ａへのＩＰ接続または安全なＩＰ接続を確立する。非プロキシ・モードでは、続いて認証に関連するＳＵＰＬメッセージが、ＵＥ１１０とＥ−ＳＬＰ２３４ａとの間、およびＥ−ＳＬＰ２３４ａとステップ９で選択された任意のＶ−ＳＬＰ（図４に示されていない）との間で交換されればよく、次いでＵＥ１１０は、ステップ９でＳＵＰＬ ＩＮＩＴによって示されたＳＰＣへのＩＰ接続または安全なＩＰ接続を確立する。プロキシ・モードでは、ＵＥ１１０は、Ｅ−ＳＬＰ２３４ａにＳＵＰＬ ＰＯＳ ＩＮＩＴを返す。非プロキシ・モードでは、ＵＥ１１０は、ＳＰＣ（図４に示されていない）にＳＵＰＬ ＰＯＳ ＩＮＩＴを送る。ＳＵＰＬ ＰＯＳ ＩＮＩＴは、ＵＥ１１０によってサポートされている測位方法および測位プロトコル、サービング・セルＩＤ、ロケーションの算出を支援するネットワーク測定値、ＵＥ１１０が支援データを必要な場合には（例えば、Ａ−ＧＰＳへの）支援データの要求、ＵＥ１１０に既にある場合には位置推定、および／または他の情報を含んでいればよい。Ｅ−ＳＬＰ２３４ａまたはＳＰＣが、ＳＵＰＬ ＰＯＳ ＩＮＩＴにおいて受信された情報から必要とされる精度の位置推定を取得できる場合、Ｅ−ＳＬＰまたはＳＰＣは直ちにステップ１２へ進めばよい。

ステップ１１において、ＵＥ１１０は、プロキシ・モードではＥ−ＳＬＰ２３４ａを用いて、非プロキシ・モードではＳＰＣを用いて、ＳＵＰＬロケーション手順を続ける。ＵＥ１１０は、（プロキシ・モードでは）Ｅ−ＳＬＰ２３４ａと、または（非プロキシ・モードでは）ＳＰＣと、１つ以上のＳＵＰＬ ＰＯＳメッセージを交換すればよい。各ＳＵＰＬ ＰＯＳメッセージは、３ＧＰＰ無線リソースＬＣＳプロトコル（Radio Resource LCS Protocol：ＲＲＬＰ）、３ＧＰＰ無線リソース制御（Radio Resource Control：ＲＲＣ）、または他の何らかの測位プロトコルに応じた測位メッセージを含んでいればよい。Ｅ−ＳＬＰ２３４ａまたはＳＰＣは、これらのメッセージの中でＵＥ１１０へ支援データを提供すればよく、ＵＥ１１０は、ロケーション関連の測定値または位置推定を後に返せばよい。

ステップ１２において、Ｅ−ＳＬＰ２３４ａまたはＳＰＣは、ステップ１１でＵＥ１１０から受信された測定値から算出する、またはステップ１１でＵＥから受信された位置推定を検証することのいずれかによって、位置推定を取得する。次いでＥ−ＳＬＰ２３４ａまたはＳＰＣは、ＵＥ１１０にＳＵＰＬ ＥＮＤを送り、ＳＵＰＬロケーション手順を終了させる。ステップ１３において、Ｅ−ＳＬＰ２３４ａは、緊急サービス位置応答（Emergency Services Position Response）において、（図４に示されていない選択されたＶ−ＳＬＰからから回送（forward）されたものでもよい）位置推定をＧＭＬＣ２３２ａへ返す。ステップ１４において、ＧＭＬＣ２３２ａは、緊急サービス位置要求応答（Emergency Services Position Request Response）において、ＰＳＡＰ１８０に位置推定を返す。

ステップ１５において、しばらくして、ＰＳＡＰ１８０は、ＧＭＬＣ２３２ａに別の緊急サービス位置要求を送り、ＵＥ１１０の最新の位置推定を取得すればよい。その場合、ＧＭＬＣ２３２ａは、ステップ８からステップ１３を繰り返して、ＳＵＰＬを使用して新しい位置推定を取得し、これを緊急サービス位置要求応答の中でＰＳＡＰ１８０に返せばよい。ステップ８を繰り返して、Ｅ−ＳＬＰ２３４ａからの位置推定を要求するとき、オプションでサポートされているなら、ＧＭＬＣ２３２ａは最後に取得した位置推定をＥ−ＳＬＰ２３４ａに転送（transfer）して、Ｖ−ＳＬＰの決定においてＥ−ＳＬＰ２３４ａを支援してもよい。

ステップ１６において、しばらくして、ＵＥ１１０とＰＳＡＰ１８０との間の呼が切断される。ステップ１７において、ＭＳＣ２３０ａは、（例えばＭＳＩまたはＭＳＩＳＤＮを介して）ＵＥ１１０を識別し、呼が切断されたことを示すＭＡＰ加入者ロケーション・レポートをＧＭＬＣ２３２ａに送る。ステップ１８において、ＧＭＬＣ２３２ａは、ステップ３で作成された呼記録を削除し、ＭＡＰ加入者ロケーション・レポートの肯定応答をＭＳＣ２３０ａに返せばよい。

図５は、呼設定の後にロケーションが開始された、ＳＵＰＬを用いた３ＧＰＰでの緊急回線モード呼のメッセージ・フロー５００の実施形態を示している。ステップ１において、ＵＥ１１０はＭＳＣ２３０ａに緊急サービス呼の要求を送る。ステップ２において、緊急呼手順が適用される。ＭＳＣ２３０ａは、サービング・セルＩＤに基づいて、適切なＰＳＡＰ（または緊急サービス・クライアント）を判断する。以下の説明において、ＰＳＡＰ１８０が選択されたＰＳＡＰである。ＭＳＣ２３０ａ、ＲＡＮ１２０ａ、およびＵＥ１１０は、ＰＳＡＰ１８０への緊急呼発生の通常の手順を続ける。（例えば、ＰＳＴＮ１６０を介して）ＰＳＡＰ１８０に送られた呼設定情報は、（既に取得されている場合）ＵＥのロケーション、緊急サービス・プロバイダが後でＵＥのロケーションを要求できるようにする情報（例えば、ヨーロッパでは、ＭＳＣ番号に設定されたロケーション番号パラメータ、ＭＳＩＳＤＮに設定された発呼者パラメータを伴うＩＳＵＰ／ＢＩＣＣ ＩＡＭメッセージ）、および／または他の情報を含んでいればよい。

ステップ３において、ＭＳＣ２３０ａは、ＵＥ１１０がＳＵＰＬロケーションをサポートしていると見なすか、判断すればよい。続いてＭＳＣ２３０ａは、ステップ３で緊急呼が送られた、または送られるＥ−ＳＬＰ２３４ａおよびＰＳＡＰ１８０に関連付けられるＧＭＬＣ２３２ａにＭＡＰ ＳＬＲを送る。ＭＡＰ ＳＬＲは、ＵＥの識別、サービング・セルＩＤ、サービス・エリア識別子（Service Area Identifier：ＳＡＩ）および／または他の情報を含んでいればよい。ＳＩＭレス緊急呼、または未登録の（Ｕ）ＳＩＭ緊急呼の場合、ＩＭＥＩが常に送信されるとよく、ＭＳＩＳＤＮは、ダイアルできないコールバック番号で埋められていればよい。ヨーロッパでは、ＭＳＣ２３０ａは、緊急呼が接続されるＰＳＡＰ１８０の識別を提供すればよい。

ステップ４において、ＧＭＬＣ２３２ａは、呼の記録を作成する。ステップ５において、ＧＭＬＣ２３２ａは、ＭＳＣ２３０ａにＭＡＰ ＳＬＲの肯定応答を返す。ステップ６において、ＧＭＬＣ２３２ａは、ＵＥの識別（例えば、ＭＳＩＳＤＮおよび／またはＩＭＳＩ）、セルＩＤまたは（分かっている場合）ＳＡＩ、要求されるＱｏＰ、および／または他の情報を含めばよい緊急サービス位置要求をＥ−ＳＬＰ２３４ａに送る。

ステップ７からステップ１０において、Ｅ−ＳＬＰ２３４ａおよびＵＥ１１０は、図４のステップ９からステップ１２について上記で説明したように、ＳＵＰＬロケーション手順を行う。Ｖ−ＳＬＰが必要かどうかは、ステップ６において受信されたセルＩＤまたは（ある場合）ＳＡＩから判断されればよい。ステップ１０において、Ｅ−ＳＬＰ２３４ａ（プロキシ・モード用）、あるいはＥ−ＳＬＰ２３４ａまたは選択されたＶ−ＳＬＰに関連付けられたＳＰＣ（非プロキシ・モード用）は、ＵＥ１１０の位置推定を取得する。次いでＥ−ＳＬＰ２３４ａまたはＳＰＣは、ＵＥ１１０にＳＵＰＬ ＥＮＤを送り、ＳＵＰＬロケーション手順を終了させる。ステップ１１において、Ｅ−ＳＬＰ２３４ａは、（図５に示されていない選択されたＶ−ＳＬＰからから回送されたものでもよい）位置推定をＧＭＬＣ２３２ａへ返す。ステップ１２において、ＧＭＬＣ２３２ａは、ステップ１１で受信されたロケーション情報、使用された測位方法についての情報、および／または他の情報をＰＳＡＰ１８０へ回送すればよい。それ以外の場合、ＰＳＡＰ１８０は、ロケーション情報を要求して、ＧＭＬＣ２３２ａからその情報を取得することを期待される。

ステップ１３において、しばらくして、ＵＥ１１０とＰＳＡＰ１８０との間の呼が切断される。ステップ１４において、ＭＳＣ２３０ａは、ＵＥ１１０を識別し呼が切断されたことを示すＭＡＰ加入者ロケーション・レポートをＧＭＬＣ２３２ａに送る。ステップ１５において、ＧＭＬＣ２３２ａは、ステップ４で作成された呼記録を削除し、ＭＡＰ加入者ロケーション・レポートの肯定応答をＭＳＣ２３０ａに返せばよい。

２．ＳＵＰＬロケーションを用いた３ＧＰＰ２での緊急回線モード呼
図６は、ＳＵＰＬを用いた３ＧＰＰ２での緊急回線モード呼のメッセージ・フロー６００の実施形態を示している。ステップ１において、ＵＥ１１０は、３ＧＰＰ２のＰＬＭＮ１３０ｂ内のＭＳＣ２３０ｂに緊急サービス呼の要求を送る。ステップ２において、ＭＳＣ２３０ｂは、例えばＵＥから受信されたＵＥ加入情報またはＵＥの性能情報、あるいはＰＬＭＮ１３０ｂのポリシーに基づいて、ＵＥ１１０がＳＵＰＬ測位をサポートしていると見なすか、または判断すればよい。次いで、ＭＳＣ２３０ｂは、Ｅ−ＳＬＰ２３４ｂと関連する（例えば、Ｅ−ＳＬＰ２３４ｂを含む、またはＥ−ＳＬＰ２３４ｂに接続されている）ネットワーク中にあるＭＰＣ２３２ｂに、ＡＮＳＩ−４１ ＭＡＰ開始要求（Origination Request）を送る。開始要求は、ＵＥの識別（例えば、ＩＭＳＩおよび／またはＭＩＮ）、サービング・セルＩＤ、および／または他の情報（例えば、位置推定の算出に使用されればよいＵＥまたはネットワークからの測定値）を含んでいればよい。

ステップ３において、ＭＰＣ２３２ｂは、呼の記録を作成する。ＭＰＣ２３２ｂは、ステップ２において受信されたセルＩＤおよび任意の測定値に基づいて、ＵＥ１１０の仮の位置推定を決定すればよい。ＭＰＣ２３２ｂは、ステップ８からステップ１３を事前に開始して、ＵＥ１１０の仮の位置推定を取得してもよい。ＭＰＣ２３２ｂは、（取得された場合）仮の位置推定、またはステップ２において受信されたサービング・セルＩＤに基づいてＰＳＡＰを選択すればよい。その場合、ＭＰＣ２３２ｂは、ＥＳＲＤまたはＥＳＲＫを割り当てて、選択されたＰＳＡＰを示せばよい。以下の説明において、ＰＳＡＰ１８０が選択されたＰＳＡＰである。ステップ４において、ＭＰＣ２３２ｂは、ステップ３で割り当てられた任意のＥＳＲＤまたはＥＳＲＫを含むＡＮＳＩ−４１ ＭＡＰ開始要求の肯定応答をＭＳＣ２３０ｂに返す。

ステップ５において、ＭＳＣ２３０ｂは、ＰＳＡＰ１８０に緊急サービス呼を送る。ステップ４でＥＳＲＫまたはＥＳＲＤが返されていた場合、ステップ３でＭＰＣ２３２ｂによってＰＳＡＰ１８０が選択される。それ以外の場合、ＭＳＣ２３０ｂは、（例えばＵＥ１１０の現在のまたは最初のサービング・セルに基づいて）ＰＳＡＰを決定し、ＥＳＲＤおよび／またはＥＳＲＫを割り当てればよい。ＭＳＣ２３０ｂによってＰＳＡＰ１８０に送信される呼設定メッセージは、ステップ４で返されたかステップ５で割り当てられた任意のＥＳＲＤまたはＥＳＲＫ、およびＵＥ１１０用のコールバック番号（例えば、ＭＳＩＳＤＮ）を含んでいればよい。

ステップ６において、ＭＳＣ２３０ｂを介してＵＥ１１０とＰＳＡＰ１８０との間に呼が確立される。ステップ７において、ＰＳＡＰ１８０は、ＭＰＣ２３２ｂに緊急サービス位置要求を送り、ＵＥ１１０の正確な初期位置推定を要求する。ＰＳＡＰ１８０は、ステップ５で受信したＥＳＲＫまたはＥＳＲＤを使用して、ＭＰＣ２３２ｂを識別してもよい。その場合、緊急サービス位置要求には、ＥＳＲＫおよび／またはＥＳＲＤ、ならびにコールバック番号が含まれる。ステップ８において、ＭＰＣ２３２ｂは、ステップ７で受信されたＥＳＲＫまたはコールバック番号を使用して、ステップ３で作成された呼記録を識別する。ＭＰＣ２３２ｂが、（例えばステップ８からステップ１３を事前に実行することで）ステップ３において正確な位置推定を取得していた場合、ＭＰＣ２３２ｂは、ステップ１４においてＰＳＡＰ１８０に対してこの位置推定を直ちに返すことができ、ステップ８からステップ１３を省くことができる。それ以外の場合、ＭＰＣ２３２ｂは、ＵＥの識別（例えば、ＭＩＮおよび／またはＩＭＳＩ）、セルＩＤ（分かっている場合）、要求されたＱｏＰ、および／または他の情報を含めばよい緊急サービス位置要求をＥ−ＳＬＰ２３４ｂへ送る。

ステップ９からステップ１２において、Ｅ−ＳＬＰ２３４ｂおよびＵＥ１１０は、図４のステップ９からステップ１２について上記で説明したように、ＳＵＰＬロケーション手順を行う。Ｅ−ＳＬＰ２３４ｂ（プロキシ・モード用）またはＳＰＣ（非プロキシ・モード用）が、ステップ１０でＳＵＰＬ ＰＯＳ ＩＮＩＴの中で受信された情報から必要とされる精度の位置推定を取得できる場合、Ｅ−ＳＬＰまたはＳＰＣは直ちにステップ１２へ進めばよい。それ以外の場合、ステップ１１において、ＵＥ１１０は、（プロキシ・モードでは）Ｅ−ＳＬＰ２３４ｂと、または（非プロキシ・モードでは）ＳＰＣと、１つ以上のＳＵＰＬ ＰＯＳメッセージを交換すればよい。各ＳＵＰＬ ＰＯＳメッセージは、３ＧＰＰ２ Ｃ．Ｓ００２２、ＴＩＡ−８０１、３ＧＰＰ ＲＲＬＰ、ＲＲＣ、または他の測位プロトコルに応じた測位メッセージを含んでいればよい。Ｅ−ＳＬＰ２３４ｂまたはＳＰＣは、これらのメッセージにおいてＵＥへの支援データを提供すればよく、ＵＥはロケーション関連の測定値または位置推定を後に返せばよい。ステップ１２において、Ｅ−ＳＬＰ２３４ｂまたはＳＰＣは、位置推定を取得し、ＵＥ１１０にＳＵＰＬ ＥＮＤを送り、ＳＵＰＬロケーション手順を終了させる。

ステップ１３において、Ｅ−ＳＬＰ２３４ｂは、（図６に示されていない選択されたＶ−ＳＬＰからから回送されたものでもよい）位置推定をＭＰＣ２３２ｂへ返す。ステップ１４において、ＭＰＣ２３２ｂは、緊急サービス位置要求応答メッセージの中で、ＰＳＡＰ１８０に位置推定を返す。ステップ１５において、しばらくして、ＰＳＡＰ１８０は、ＭＰＣ２３２ｂへ別の緊急サービス位置要求を送り、ＵＥ１１０の最新の位置推定を取得すればよい。その場合、ＭＰＣ２３２ｂは、ステップ８からステップ１３を繰り返して、ＳＵＰＬを使用して新しい位置推定を取得し、これを緊急サービス位置要求応答の中でＰＳＡＰ１８０に返せばよい。ステップ８を繰り返して、Ｅ−ＳＬＰ２３４ｂからの位置推定を要求するとき、オプションでサポートされているなら、ＭＰＣ２３２ｂは最後に取得した位置推定をＥ−ＳＬＰ２３４ｂに転送して、Ｖ−ＳＬＰの決定においてそれを支援すればよい。

ステップ１６において、しばらくして、ＵＥ１１０とＰＳＡＰ１８０との間の呼が切断される。ステップ１７において、ＭＳＣ２３０ｂは、ＵＥ１１０を識別し呼が切断されたことを示す、ＡＮＳＩ−４１ ＭＡＰ呼終了レポート（Call Termination Report）メッセージを（例えばＩＭＳＩまたはＭＳＩＳＤＮを介して）ＭＰＣ２３２ｂへ送る。ステップ１８において、ＭＰＣ２３２ｂは、ステップ３で作成された呼記録を削除し、ＡＮＳＩ−４１ ＭＡＰ呼終了レポートの肯定応答をＭＳＣ２３０ｂに返せばよい。

３．Ｘ．Ｓ００２４ロケーションを用いた３ＧＰＰ２での緊急回線モード呼
図７は、Ｘ．Ｓ００２４ロケーションを用いた緊急回線モード呼のネットワーク・アーキテクチャ７００の実施形態を示している。３ＧＰＰ２では、ＳＵＰＬの代わりに、３ＧＰＰ２ Ｘ．Ｓ００２４で定義されるユーザ・プレーン・ロケーション・ソリューションが使用される。したがって、ネットワーク・アーキテクチャ７００は、３ＧＰＰ２ネットワークに適用できる。ＲＡＮ１２０は、３ＧＰＰ２のＲＡＮ１２０ｂまたは他の接続ネットワークであればよい。Ｖ−ＰＬＭＮ１３０ｂは、ＭＳＣ２３０ｂ、ＭＰＣ２３２ｂ、Ｅ−ＰＳ２３８、およびＶ−ＰＳ２４０を含んでいればよい。ＭＰＣ２３２ｂは、Ｅ−ＰＳ２３８を呼出し、Ｘ．Ｓ００２４を使用して、緊急呼を発しているＵＥのロケーションを決定すればよい。

ＵＥ１１０と、Ｅ−ＰＳ２３８と、Ｖ−ＰＳ２４０との間のロケーションに関連するインターフェースは、３ＧＰＰ２ Ｘ．Ｓ００２４に記載されている、図７に示されるようなＬＣＳ−ｘ、ＬＣＳ−ｙ、およびＬＣＳ−ｚであればよい。ＭＳＣ２３０ｂとＭＰＣ２３２ｂとの間のインターフェースは、ＡＮＳＩ−４１ ＭＡＰであればよい。ＭＰＣ２３２ｂとＥ−ＰＳ２３８との間のインターフェースは、ＭＬＰ、ＲＬＰ、または他の何らかのインターフェースであればよい。

図８は、Ｘ．Ｓ００２４を用いた３ＧＰＰ２での緊急回線モード呼のメッセージ・フロー８００の実施形態を示している。ステップ１において、ＵＥ１１０は、３ＧＰＰ２ ＰＬＭＮ１３０ｂ内のＭＳＣ２３０ｂに緊急サービス呼の要求を送る。ステップ２において、ＭＳＣ２３０ｂは、例えばＵＥから受信されるＵＥ加入情報またはＵＥ性能情報、あるいはＰＬＭＮ１３０ｂのポリシーに基づいて、ＵＥ１１０がＸ．Ｓ００２４測位をサポートしていると見なすか、または判断すればよい。次いでＭＳＣ２３０ｂは、ＡＮＳＩ−４１ ＭＡＰ開始要求メッセージをＭＰＣ２３２ｂに送る。開始要求は、ＵＥの識別（例えば、ＩＭＳＩおよび／またはＭＩＮ）、サービング・セルＩＤ、および／または他の情報（例えば、位置推定の算出に使用されればよいＵＥまたはネットワークからの測定値）を含んでいればよい。

ステップ３において、ＭＰＣ２３２ｂは、呼の記録を作成する。ＭＰＣ２３２ｂは、ステップ２において受信されたセルＩＤおよび任意の測定値に基づいて、ＵＥ１１０の仮の位置推定を決定すればよい。ＭＰＣ２３２ｂは、ステップ８からステップ１５を事前に開始して、ＵＥ１１０の仮の位置推定を取得してもよい。ＭＰＣ２３２ｂは、（取得された場合）仮の位置推定に基づいて、またはステップ２において受信されたサービング・セルＩＤに基づいて、ＰＳＡＰを選択すればよい。その場合、ＭＰＣ２３２ｂは、ＥＳＲＤまたはＥＳＲＫを割り当てて、選択されたＰＳＡＰを示せばよい。以下の説明において、ＰＳＡＰ１８０は選択されたＰＳＡＰである。ステップ４において、ＭＰＣ２３２ｂは、ステップ３で割り当てられた任意のＥＳＲＤまたはＥＳＲＫを含むＡＮＳＩ−４１ ＭＡＰ開始要求肯定応答をＭＳＣ２３０ｂに返す。ステップ５において、ＭＳＣ２３０ｂは、ＰＳＡＰ１８０に緊急サービス呼を送る。ステップ４でＥＳＲＫまたはＥＳＲＤが返されていた場合、ステップ３でＭＰＣ２３２ｂによってＰＳＡＰ１８０が選択される。それ以外の場合、ＭＳＣ２３０ｂは、（例えばＵＥ１１０の現在のまたは最初のサービング・セルに基づいて）ＰＳＡＰを決定し、ＥＳＲＤおよび／またはＥＳＲＫを割り当てればよい。ＭＳＣ２３０ｂによってＰＳＡＰ１８０に送信される呼設定メッセージは、ステップ４で返されたまたはステップ５で割り当てられた任意のＥＳＲＤまたはＥＳＲＫ、およびＵＥ１１０用のコールバック番号（例えば、移動体電話番号（Mobile Directory Number：ＭＤＮ）を含んでいればよい。ＭＳＣ２３０ｂは、呼の遅延を避けるために、ステップ２より前にＰＳＡＰ１８０に呼を送信すればよい。

ステップ６において、ＭＳＣ２３０ｂを介してＵＥ１１０とＰＳＡＰ１８０との間に呼が確立される。ステップ７において、ＰＳＡＰ１８０は、ＭＰＣ２３２ｂに緊急サービス位置要求を送り、ＵＥ１１０の正確な初期位置推定を要求する。ＰＳＡＰ１８０は、ステップ５で受信したＥＳＲＫまたはＥＳＲＤを使用して、ＭＰＣ２３２ｂを識別すればよい。その場合、緊急サービス位置要求には、ＥＳＲＫおよび／またはＥＳＲＤ、ならびにコールバック番号が含まれる。ステップ８において、ＭＰＣ２３２ｂは、ステップ７で受信されたＥＳＲＫまたはコールバック番号を使用して、ステップ３で作成された呼記録を識別する。ＭＰＣ２３２ｂが、ステップ３において正確な位置推定を取得していた場合、ＭＰＣ２３２ｂは、ステップ１６においてＰＳＡＰ１８０に対してこの位置推定を直ちに返すことができ、ステップ８からステップ１５を省くことができる。それ以外の場合、ＭＰＣ２３２ｂは、ＵＥの識別（例えば、ＭＩＮおよび／またはＩＭＳＩ）、セルＩＤ（分かっている場合）、要求されたＱｏＰ、および／または他の情報を含めばよい緊急サービス位置要求をＥ−ＰＳ２３８に送る。

ステップ９において、Ｅ−ＰＳ２３８がＵＥ１１０のＩＰアドレスを知っているか取得できる場合、Ｅ−ＰＳ２３８は、Ｘ．Ｓ００２４ロケーション手順を開始し、ＳＭＳ、ＷＡＰプッシュ、またはＵＤＰ／ＩＰを使用して、ＵＥ１１０にＸ．Ｓ００２４ ＳＵＰＬ＿ＩＮＩＴを送る。ＳＵＰＬ＿ＩＮＩＴは、例えば、ＵＥ１１０がホーム・ネットワークにない場合、Ｅ−ＰＳ２３８がＵＥのＨ−ＰＳではない場合、またはＥ−ＰＳ２３８がＨ−ＰＳとして振る舞わないことを選択した場合に、必要とされるＱｏＰ、サポートされる測位方法、およびＥ−ＰＳ２３８のＩＰアドレスを含んでいればよい。ＳＵＰＬ＿ＩＮＩＴは、例えばＳＵＰＬ＿ＩＮＩＴ通知パラメータの中に、緊急サービスの表示を含んでいてもよい。ステップ８での緊急サービス位置要求は、ステップ７でのＰＳＡＰ１８０からの緊急サービス位置要求を待たずに、ステップ４の後に直ちに送信されればよい。その場合、ステップ８からステップ１５は、ステップ７でＭＰＣ２３２ｂがＰＳＡＰ１８０からの緊急サービス位置要求を受信する前に完了すればよく、ＭＰＣ２３２ｂはステップ７からステップ１６へ直接進めばよい。

ステップ１０において、ＵＥ１１０は、Ｅ−ＰＳ２３８がＵＥのＨ−ＰＳである場合、Ｅ−ＰＳ２３８への安全なＩＰ接続を確立する。しかし、Ｅ−ＰＳ２３８がＵＥ１１０のＨ−ＰＳではない場合、またはステップ９でＥ−ＰＳ２３８がＳＵＰＬ＿ＩＮＩＴにそのＩＰアドレスを含んでいる場合、ＵＥ１１０は、Ｈ−ＰＳの代わりにＥ−ＰＳ２３８へのＩＰ接続または安全なＩＰ接続を確立する。次いでＵＥ１１０は、ＵＥ１１０によってサポートされる測位方法および性能、サービング・セルＩＤ、測定値、位置推定、支援データの要求、および／または他の情報を含んでいればよいＳＵＰＬ＿ＳＴＡＲＴをＥ−ＰＳ２３８に送る。

ステップ１１において、Ｅ−ＰＳ２３８は、Ｅ−ＰＳ２３８またはＶ−ＰＳに関連付けられたＰＤＥであればよい、選択されたＰＤＥに測位手順を拡張すればよい。次いで選択されたＰＤＥは、測位手順を管理し、位置の算出を支援することになる。この拡張は、（ａ）ＵＥ１１０がＥ−ＰＳ２３８を介して選択されたＰＤＥと通信するプロキシ・モード（図８に示される）、または（ｂ）ＵＥ１１０が選択されたＰＤＥと直接通信する非プロキシ・モード（図８に示されていない）のいずれかを使用すればよい。

ステップ１２において、Ｅ−ＰＳ２３８は、ＵＥ１１０にＳＵＰＬ＿ＲＥＳＰＯＮＳＥを送る。プロキシ・モードでは、ステップ１３において、ＵＥ１１０は、サービング・セル情報、（例えば、３ＧＰＰ２ Ｃ．Ｓ００２２またはＴＩＡ−８０１プロトコルを使用して）組み込まれた測位メッセージ、および／または他の情報を搬送すればよいＳＵＰＬ＿ＰＯＳをＥ−ＰＳ２３８に送る。次いで、Ｅ−ＰＳ２３８は、選択されたＰＤＥ（図８に示されていない）にＳＵＰＬ＿ＰＯＳを回送する。非プロキシ・モードでは、ステップ１２のＳＵＰＬ＿ＲＥＳＰＯＮＳＥが、選択されたＰＤＥのアドレスを搬送し、ＵＥ１１０が選択されたＰＤＥへの安全なＩＰ接続を確立し、ステップ１３でこのＰＤＥに直接ＳＵＰＬ＿ＰＯＳを送る。

ステップ１４において、ＵＥ１１０は、（プロキシ・モードでは）Ｅ−ＰＳ２３８と、または（非プロキシ・モードでは）ＰＤＥと、さらなるＳＵＰＬ＿ＰＯＳメッセージを交換すればよい。Ｅ−ＰＳ２３８またはＰＤＥは、これらのメッセージの中でＵＥ１１０に支援データを提供すればよく、ＵＥは、ロケーション測定値（例えば、Ａ−ＧＰＳおよび／またはＡ−ＦＬＴ測定値）または位置推定をＥ−ＰＳまたはＰＤＥに提供すればよい。ステップ１５において、選択されたＰＤＥは、ステップ１３およびステップ１４でＵＥ１１０から受信された測定値から算出すること、またはＵＥから受信された位置推定を検証することのいずれかによって、位置推定を取得する。次いでＰＤＥは、ＰＤＥがＥ−ＰＳ２３８に関連付けられている場合は直接的に、またはＰＤＥがＶ−ＰＳに関連付けられている場合には間接的に（図８に示されていない）、Ｅ−ＰＳ２３８に位置推定を返す。次いでＥ−ＰＳ２３８は、緊急サービス位置応答の中で位置推定をＭＰＣ２３２ｂへ回送する。ステップ１６において、ＭＰＣ２３２ｂは、緊急サービス位置要求応答の中で、ＰＳＡＰ１８０に位置推定を返す。

ステップ１７において、しばらくして、ＰＳＡＰ１８０は、ＭＰＣ２３２ｂに別の緊急サービス位置要求を送り、ＵＥ１１０の最新の位置推定を取得すればよい。その場合、ＭＰＣ２３２ｂは、ステップ８からステップ１５を繰り返して、Ｘ．Ｓ００２４を使用して新しい位置推定を取得し、これを緊急サービス位置要求応答の中でＰＳＡＰ１８０に返せばよい。ステップ１８において、しばらくして、ＵＥ１１０とＰＳＡＰ１８０との間の呼が切断される。ステップ１９において、ＭＳＣ２３０ｂは、ＵＥ１１０を識別し呼が切断されたことを示す、ＡＮＳＩ−４１ ＭＡＰ呼終了レポート（Call Termination Report）メッセージを（例えばＩＭＳＩまたはＭＩＮを介して）ＭＰＣ２３２ｂに送る。ステップ２０において、ＭＰＣ２３２ｂは、ステップ３で作成された呼記録を削除し、ＡＮＳＩ−４１ ＭＡＰ呼終了レポートの肯定応答をＭＳＣ２３０ｂに返せばよい。

４．ＳＵＰＬ１．０またはＸ．Ｓ００２４バージョン１．０の使用
Ｖ−ＰＬＭＮ１３０は、緊急回線モード呼用にＳＵＰＬまたはＸ．Ｓ００２４のロケーションをサポートするために、Ｅ−ＳＬＰまたはＥ−ＰＳを使用しなくてもよい、または常には使用しなくてもよい。代わりに、Ｖ−ＰＬＭＮ１３０は、ＯＭＡ ＳＵＰＬ（例えば、ＳＵＰＬ１．０）の以前のバージョン、またはＸ．Ｓ００２４の以前のバージョンを使用してもよい。これらは、どちらも緊急呼に対する特別なロケーションのサポートがない。これは、上記のＥ−ＳＬＰまたはＥ−ＰＳを使用できるようにする緊急呼用の特別なロケーション・サポートを含むＳＵＰＬまたはＸ．Ｓ００２４のバージョンをまだ導入していないネットワーク・オペレータにとって好都合であろう。さらに、ネットワーク・オペレータが、（例えば、ネットワーク・オペレータがＳＵＰＬまたはＸ．Ｓ００２４の新しいバージョンをサポートしている可能性のある場合でも）ＳＵＰＬまたはＸ．Ｓ００２４の以前のバージョンだけをサポートしているＵＥ向けに緊急回線モード呼をサポートしたい場合にも好都合であろう。

一実施形態によれば、Ｖ−ＰＬＭＮ１３０は、ＧＭＬＣ２３２ａまたはＭＰＣ２３２ｂと関連付けられた、またはＧＭＬＣ２３２ａまたはＭＰＣ２３２ｂと結合されたＥ−ＳＬＰではなく、要求ＳＬＰ（Requesting SLP：Ｒ−ＳＬＰ）を使用してもよい。この場合の緊急回線モード呼のサポートでも、図４、図５、および図６について上記で説明したように発生すればよいが、以下の点が異なる。第１に、各図において、Ｒ−ＳＬＰがＥ−ＳＬＰ２３４ａまたはＥ−ＳＬＰ２３４ｂに取って代わることになる。第２に、図４および図６のステップ８、ならびに図５のステップ６において、Ｒ−ＳＬＰは、ＧＭＬＣ２３２ａまたはＭＰＣ２３２ｂから位置要求を受信することになる。図４および図６のステップ１３、ならびに図５のステップ１１において、Ｒ−ＳＬＰは、取得したＵＥの位置をＧＭＬＣ２３２ａまたはＭＰＣ２３２ｂに返すことになる。第３に、図４および図６のステップ９からステップ１２、ならびに図５のステップ７からステップ１０で説明したＳＵＰＬロケーション手順は、Ｒ−ＳＬＰが最初にＵＥのＨ−ＳＬＰからロケーションを要求する別のロケーション手順に代わることになる。続いてＨ−ＳＬＰは、ＳＵＰＬを使用してＵＥ１１０と対話してＵＥのロケーションを取得し、Ｒ−ＳＬＰへＵＥのロケーションを返すことになる。この別のＳＵＰＬロケーション手順は、公的に入手可能な「セキュア・ユーザ・プレーン・ロケーション・アーキテクチャ候補バージョン１．０（Secure User Plane Location Architecture Candidate Version 1.0）」（２００６年９月６日）と題されるＯＭＡ−ＡＤ−ＳＵＰＬ−Ｖ１＿０−２００６０９０６−Ｃで定義されている。

Ｖ−ＰＬＭＮ１３０がＵＥ１１０のＨ−ＰＬＭＮ１５０の場合、Ｒ−ＳＬＰはＵＥ１１０のＨ−ＳＬＰであればよく、Ｒ−ＳＬＰとＨ−ＳＬＰはここでは同一のエンティティになっているため、これらの間でのどんなロケーション要求および応答も必要とせずに、上記の変更された手順を使用することができる。

Ｘ．Ｓ００２４の場合、この実施形態を同様の方法で使用すればよいが、要求ＰＳ（Ｒ−ＰＳ）が、Ｖ−ＰＬＭＮ１３０ｂにおいてＭＰＣ２３２ｂに関連付けられた、またはＭＰＣ２３２ｂに結合されたＥ−ＰＳ２３８に取って代わる。この場合、図８においてステップ９からステップ１４について説明したロケーション手順は、「ＩＰベースのロケーション・サービス（IP Based Location Services）」（２００５年１０月、バージョン１．０、リビジョン０）と題されるＸ．Ｓ００２４に記載されているように、Ｒ−ＰＳがＵＥ１１０のＨ−ＰＳからＵＥ１１０のロケーションを要求し、Ｈ−ＰＳがＵＥ１１０と対話してロケーションを取得する（および、それをＲ−ＰＳへ返す）手順に代えられることになる。ＳＵＰＬについては、ＵＥ１１０が自身のＨ−ＰＬＭＮにある場合、Ｒ−ＰＳはＨ−ＰＳであればよい。

５．未登録、ＵＩＣＣレス、ＳＩＭレス、およびＵＩＭレスのＵＥｓのサポート
ＳＵＰＬロケーション（例えば、図４および図６のステップ９、ならびに図５のステップ７）を開始するためには、Ｅ−ＳＬＰは、ＷＡＰプッシュ、ＳＭＳ、ＵＤＰ／ＩＰ、または他の何らかの手段を使用して、ＵＥにＳＵＰＬ ＩＮＩＴを送る。Ｘ．Ｓ００２４ロケーション（例えば、図８のステップ９）を開始するためには、Ｅ−ＰＳは、ＷＡＰプッシュ、ＳＭＳ、ＵＤＰ／ＩＰ、または他の何らかの手段を使用して、ＵＥにＳＵＰＬ＿ＩＮＩＴを送る。（例えば、ＷＡＰプッシュまたはＳＭＳを使用した）ＳＵＰＬ ＩＮＩＴの送信は、ＵＥが自身のＨ−ＰＬＭＮからローミング中の場合、不都合であったり時間を要したりする場合がいくらかあり、Ｈ−ＰＬＭＮとの相互作用によって信頼性がなくなることもある。一実施形態において、Ｅ−ＳＬＰまたはＥ−ＰＳは、サービング中のＭＳＣに直接ＳＭＳメッセージを送り、３ＧＰＰではＳＭＳゲートウェイＭＳＣ、または３ＧＰＰ２ではＳＭＳメッセージ・センターをエミュレート（emulate）する。

別の実施形態では、Ｅ−ＳＬＰまたはＥ−ＰＳは、Ｅ−ＳＬＰまたはＥ−ＰＳへの影響を緩和させるため、ＧＭＬＣまたはＭＰＣを介して、ＳＭＳメッセージをサービング中のＭＳＣに送る。これらの実施形態は、未登録のＵＥ、３ＧＰＰでのＵＩＣＣレスＵＥ、ＧＳＭでのＳＩＭレスＵＥ、３ＧＰＰ２でのＵＴＭレスＵＥに使用してもよい。この場合、ＭＳＣは、通常のＩＭＳＩ、ＭＳＩＳＤＮ、またはＭＩＮに代えて、一時的なＵＥ識別子をＧＭＬＣまたはＭＰＣに提供すればよい。一時的なＵＥ識別子は、３ＧＰＰでは図４のステップ２および図５のステップ３で送信されるＭＡＰ加入者ロケーション・レポート、３ＧＰＰ２では図６および図８のステップ２で送信されるＡＮＳＩ−４１開始要求に含まれていればよい。ＵＥがＳＵＰＬ ＩＮＩＴを受信すると、Ｅ−ＳＬＰまたはＥ−ＰＳへのＩＰ接続または安全なＩＰ接続を確立することができる。未登録、ＵＩＣＣレス、ＳＩＭレス、またはＵＩＭレスのＵＥは、同じネットワーク内のＥ−ＳＬＰまたはＥ−ＰＳへのＩＰ接続を可能にすることになる緊急呼に限られたアクセスでのＩＰ接続を確立すればよい。ＩＰ接続は、例えば、公表されている３ＧＰＰ ＳＡ２コントリビューションＳ２−０５１９５０「ＶｏＩＰ緊急呼サポート（VoIP Emergency Call Support）」について説明されている手順を使用して確立すればよい。この場合、別のＶ−ＳＬＰは使用されないこともある。

上記の説明の多くは、ＵＥが同時の回線モード呼（音声用）、およびパケット・モード・データ転送（ロケーション用）をサポートするものと想定している。ＵＥはたはネットワークが、同時の回線モード呼およびパケット・モード通信をサポートしていない場合、ＵＥとＥ−ＳＬＰまたはＥ−ＰＳとの間のシグナリングが別の方法でサポートされればよい。

図９は、様々なエンティティ間の通信のいくつかの実施形態を示している。一実施形態において、すべてのＳＵＰＬ通信にＳＭＳが使用される。ＳＭＳでは、ロケーション用のシグナリングおよび情報（例えば、ＳＵＰＬメッセージ）は、３ＧＰＰおよび３ＧＰＰ２における既存のＳＭＳ２地点間伝送プロトコル（point-to-point transport protocols）（例えば、ＳＭＳ ＭＡＰメッセージ）を使用して、ＭＰＣ／ＧＭＬＣとＭＳＣとの間、およびＭＳＣとＵＥとの間で伝えられる、ＳＭＳメッセージの中で送信される。ＳＭＳシグナリングは、ＭＳＣとＧＭＬＣまたはＭＰＣとの間で直接送信されればよい。Ｅ−ＳＬＰとＧＭＬＣまたはＭＰＣとの間は、例えば緊急サービス位置要求と応答の交換で使用されるのと同じＴＣＰ／ＩＰ接続、または別の接続であるＴＣＰ／ＩＰを使用して、ＳＵＰＬメッセージを伝送すればよい。

図９で（ａ）として示されている実施形態において、ＳＵＰＬ ＵＬＰ（ＴＣＰまたはＩＰではない）は、ＵＥとＥ−ＳＬＰまたはＥ−ＰＳとの間でエンドツーエンドで使用される。図９で（ｂ）として示されている別の実施形態では、ＳＵＰＬ ＵＬＰは、エンドツーエンドのＴＣＰ接続を使用して伝えられる。図９で（ｃ）として示されているさらに別の実施形態では、ＳＵＰＬ ＵＬＰは、途中にいくつかのプロトコルが重複しているエンドツーエンドのＴＣＰ／ＩＰを使用して伝えられる。この性能は、ＵＥから送信されるＳＭＳメッセージ用のＭＳＣにおける特別なＳＭＳ処理によってサポートされればよい。例えば、ＭＳＣは、ＳＵＰＬが使用されている緊急呼の間にＵＥによって送信される任意のＳＭＳメッセージがＳＵＰＬを対象とするものであると想定すればよく、よってＧＭＬＣまたはＭＰＣにＳＭＳメッセージを送ることになる。

６．セキュリティ
ＳＵＰＬでは、訪問先ネットワークにおいて、ローミングおよび非ローミングのシナリオおよびプロキシ・モードまたは非プロキシ・モードで、ロケーション用にＨ−ＳＬＰをＥ−ＳＬＰに代えることをサポートするために、セキュリティ手順が確立されればよい。既存のＳＵＰＬセキュリティ手順は、一般的に、ＵＥおよびＨ−ＳＬＰの両方にある共有鍵に基づき、および／またはＵＥ内に用意されたＨ−ＳＬＰに関する他の情報（例えば、完全修飾ドメイン名、ルートＸ．５０９公開鍵証明書など）に基づいている。このような情報は、ＵＥがたまたまホーム・ネットワークにいない限り、Ｅ−ＳＬＰでは有効ではないことがある。Ｅ−ＳＬＰでは、プロキシ・モードおよび非プロキシ・モードの認証が、以下で説明するようにサポートされればよい。

Ｘ．Ｓ００２４でも、ロケーション用にＨ−ＰＳをＥ−ＰＳに代えることをサポートするために、セキュリティ手順が確立されればよい。既存のＸ．Ｓ００２４セキュリティ手順は、３ＧＰＰ２ Ｘ．Ｓ００２４−０および３ＧＰＰ２ Ｓ．Ｐ０１１０−０に記載されている。これらの手順では、ユーザのＨ−ＰＳおよびユーザのＵＩＭの両方の中に用意されている共通のルート鍵を使用する。以下のような、用意されているルート鍵から、さらなる鍵を導き出すこともできる。

（ａ）セキュア蓄積交換カプセル化（Secure Store and Forward Encapsulation：Ｓ−ＳＡＦＥ）をサポートする鍵。Ｓ−ＳＡＦＥでは、ＳＭＳまたはＷＡＰプッシュを使用してＳＵＰＬ ＩＮＩＴがＵＥに送信され、（Ｈ−ＰＳから来るとき）認証され、任意で暗号化される。

（ｂ）暗号化および認証を用いてＵＥとＨ−ＰＳとの間でＸ．Ｓ００２４メッセージが送信される、ＵＥとＨ−ＰＳとの間の安全なＩＰ接続をサポートする鍵。

（ｃ）Ｘ．Ｓ００２４メッセージが暗号化および認証を用いてＵＥと非プロキシ・モードのＰＤＥとの間で送信される、ＵＥとＰＤＥとの間の安全なＩＰ接続をサポートする鍵。

上記３つの各鍵は、ルート鍵の任意の値について確定値があるという意味では固定である。しかし、ＵＥおよびＨ−ＰＳまたはＰＤＥによる特定の測位セッション用に提供された乱数によって値が決まる暗号化および認証用に、これらの各固定鍵から、さらなる鍵を導き出すこともできる。この鍵の導出およびこれに伴うセキュリティ手順は、ＩＥＴＦ ＲＦＣ ２２４６に記載されたトランスポート層セキュリティ（Transport Layer Security：ＴＬＳ）手順、およびＩＥＴＦドラフト「トランスポート層セキュリティ（ＴＬＳ）のための事前共有鍵暗号スウィート（Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)）」に記載されたこの別のＰＳＫ−ＴＬＳを使用する。緊急回線モード呼での測位にＸ．Ｓ００２４が使用され、Ｅ−ＰＳがＨ−ＰＳではない場合、ＵＥおよびＥ−ＰＳの両方における相互認証および暗号化に、共通の設定済みのルート鍵を利用することはできなくなる。

ＳＵＰＬでは、緊急呼の間であっても、ＵＥロケーションへの認証されていないアクセスを避けるため、ＵＥはＥ−ＳＬＰを認証すればよい。Ｘ．Ｓ００２４では、ＵＥおよびＥ−ＰＳは、相互に認証を行えばよい。表１は、方法Ａ、Ｂ、Ｃ、Ｄ、およびＥとして示される５つの認証方法、および各方法の特徴を一覧している。

注：公開鍵ルート証明書が移動機器（Mobile Equipment：ＭＥ）に用意されているものとする。

方法Ａでは、最小の認証を提供する。ＳＵＰＬ ＩＮＩＴが緊急セッションのロケーションを示し、ＵＥが緊急セッションを現在行っている場合、ＵＥは、未認証のＥ−ＳＬＰまたはＥ−ＰＳからのネットワークで開始されたＳＵＰＬまたはＸ．Ｓ００２４ロケーションを許可する。緊急セッションへ制限をかければ、いくつか保護を提供できる。さらに、ＳＭＳまたはＷＡＰプッシュを介してＳＵＰＬ ＩＮＩＴを転送すれば、ＵＥの認証においてさらに信頼性を高めることができるであろう。これは、ＳＭＳまたはＷＡＰ転送は、Ｖ−ＰＬＭＮおよび／またはＨ−ＰＬＭＮからのサポートおよび検証を利用しているためである。ＵＥは、Ｅ−ＳＬＰまたはＥ−ＰＳを用いたセキュリティ手順を呼び出さずに、方法Ａを選択してもよい。この場合、ＳＵＰＬでは、Ｅ−ＳＬＰは、ＳＵＰＬ ＰＯＳ ＩＮＩＴに含まれるＳＵＰＬ ＩＮＩＴハッシュ・コードによって、限られた範囲内でＵＥを検証できる。

方法Ｂは、ＴＬＳ公開鍵認証用である。ＵＥおよびＥ−ＳＬＰまたはＥ−ＰＳは、ＩＥＴＦ ＲＦＣ２２４６に記載され、さらに「セキュア・ユーザ・プレーン・ロケーション・アーキテクチャ（Secure User Plane Location Architecture）」と題されるＯＭＡ ＳＵＰＬ１．０の別のクライアント認証メカニズムについて記載されているようなＴＬＳを使用して公開鍵認証をサポートする。このメカニズムでは、ＴＬＳハンドシェイク・フェーズの間に、Ｅ−ＳＬＰまたはＥ−ＰＳによってＵＥに送信されたＩＴＵ Ｘ．５０９公開鍵証明書とともにＴＬＳを使用して、Ｅ−ＳＬＰまたはＥ−ＰＳの認証をＵＥによってサポートする。公開鍵証明書は、一連の電子署名を提供する。各署名は、ＵＥには少なくとも１つのルート認証機関の公開鍵が用意されているならば、ＵＥがＥ−ＳＬＰまたはＥ−ＰＳの公開鍵を認証できるように、次の署名を認証している。公開鍵認証ＴＬＳ手順は、例えば、次のＳＵＰＬまたはＸ．Ｓ００２４メッセージ用の、次のシグナリングの暗号化および認証で使用する対称鍵の転送をサポートする。非プロキシ・モードでのＵＥとＳＰＣまたはＤＰＥとの間の認証および暗号化は、これらの鍵、またはこれらの鍵からさらなる鍵を導き出すことによってサポートされてもよい。

方法Ｂは、１つ以上のルート認証機関（例えば、ＯＭＡで定義されている）によるＥ−ＳＬＰまたはＥ−ＰＳ公開鍵証明書の証明、および緊急呼用のＳＵＰＬまたはＸ．Ｓ００２４をサポートしているＵＥｓに証明書を用意することを利用する。ＵＥは、例えばＥ−ＳＬＰまたはＥ−ＰＳの完全修飾ドメイン名、またはサービング・ネットワークについての既知の情報にＵＥが一致することができるＭＣＣ−ＭＮＣ識別を使用して、証明書中のＥ−ＳＬＰまたはＥ−ＰＳ名を認識する。これは、ＵＥによるＥ−ＳＬＰまたはＥ−ＰＳの認証を確実にし、ＳＵＰＬでは、ＳＵＰＬ ＰＯＳ ＩＮＩＴに含まれ、ＵＥによってＥ−ＳＬＰへ送られる６４ビットＳＵＰＬ ＩＮＩＴハッシュを介した、Ｅ−ＳＬＰによるＵＥの制限された認証を確実にする。

方法Ｂでは、Ｅ−ＳＬＰまたはＥ−ＰＳの（複数の）公開鍵をＵＥが検証できるルート公開鍵証明書がＵＥ（例えば、ＵＩＣＣまたはＵＩＭ）に用意されていればよい。ＵＥおよびＥ−ＳＬＰまたはＥ−ＰＳは、ＲＦＣ２２４６に記載のＴＬＳ手順、および例えばＲＳＡ、ＤＳＳまたはＤｉｆｆｉｅ−Ｈｅｌｌｍａｎなどの１つ以上の安全な公開鍵転送手順を使用して、共有暗号鍵およびメッセージ認証コード（message authentication code：ＭＡＣ）鍵を確立すればよい。ＳＵＰＬメッセージまたはＸ．Ｓ００２４メッセージの暗号化および認証は、安全なＴＬＣ接続の確立の後に行われればよい。非プロキシ・モードでは、ＳＵＰＬ１．０の３ＧＰＰ２非プロキシ・モード用に定義された方法を使用し、ＩＥＴＦのＰＳＫ−ＴＬＳに従って、ＳＵＰＬではＵＥとＳＰＣとの間、またはＸ．Ｓ００２４ではＵＥとＰＤＥとの間の認証および暗号化用の共通鍵を生成すればよい。

方法Ｃは、ＰＳＫ−ＴＬＳ認証用である。ＵＥおよびＥ−ＳＬＰまたはＥ−ＰＳは、ＩＥＴＦドラフト「トランスポート層セキュリティ（ＴＬＳ）用の事前共有鍵暗号スウィート」に従って、（例えば、３ＧＰＰ２ ＳＥＴｓ、または３ＧＰＰ２ Ｘ．Ｓ００２４−０およびＳ．Ｐ０１１０−０用のＳＵＰＬ１．０に記載されるような）ＰＳＫ−ＴＬＳをサポートする。事前共有鍵（pre-shared key：ＰＳＫ）は、（ａ）ＵＥ、ネットワーク（例えば、ＭＳＣまたはＨＬＲ）、および／またはＥ−ＳＬＰまたはＥ−ＰＳによって与えられる情報（例えば、ランダムな情報）、（ｂ）緊急呼の確立の間に、ＵＥによって、またはＵＥに対して送信される情報（例えば、パラメータ）、（ｃ）ＵＥからの安全な回線モードアクセスをサポートするために、ＭＳＣおよびＵＥに既にあるセキュリティ情報（例えば、暗号鍵）、および／または（ｄ）他の情報から生成されればよい。（ｃ）のセキュリティ情報は、ＵＥがＶ−ＰＬＭＮに登録している場合に利用可能であればよい。

ＰＳＫまたはＰＳＫを導き出す情報は、緊急呼確立の間、ＵＥおよびＥ−ＳＬＰ（あるいはＭＰＣまたはＧＭＬＣ）またはＥ−ＰＳ（またはＭＰＣ）で利用可能とすればよい。これらのエンティティ間での呼設定の間に確立される信頼関係は、安全な鍵または安全な鍵を導き出し得る共通の情報を取得するために使用される。ＵＥおよびＥ−ＳＬＰは、続いて導き出されたＰＳＫ（ｓ）を用いて、ＳＵＰＬロケーションのためにＰＳＫ−ＴＬＳを使用すればよい。ＰＳＫ（ｓ）は、非プロキシ・モードのための認証用のさらなるＰＳＫｓを取得するために使用すればよい。ＳＵＰＬでは、Ｅ−ＳＬＰからＵＥへのＳＵＰＬ ＩＮＩＴの転送に続いて、ＵＥがＥ−ＳＬＰへのＩＰ（ＰＳＫ−ＴＬＳ）接続を確立するときに、ＰＳＫ−ＴＬＳを使用して、ＵＥおよびＥ−ＳＬＰの相互認証をサポートすればよい。Ｘ．Ｓ００２４では、３ＧＰＰ２ Ｘ．Ｓ００２４−０およびＳ．Ｐ０１１０−０に記載されているように残りのセキュリティ情報が導き出されるルート鍵として、安全なＰＳＫを使用すればよい。

方法Ｃは、緊急呼設定の間、ＵＥとＶ−ＰＬＭＮとの間の安全な接続を利用する。これはＶ−ＰＬＭＮにおいてのＵＥの登録およびＵＥおよびＶ−ＰＬＭＮの相互認証を意味している。ＵＥにＵＩＣＣ／ＵＩＭがない場合、またはＶ−ＰＬＭＮとＨ−ＰＬＭＮとの間にローミング契約がない場合、Ｖ−ＰＬＭＮとＵＥとの間の相互認証および安全な伝送は、緊急呼設定の間に実現できないことがあり、生成された任意のＰＳＫは、さらに制限された保護を提供することになる。

方法Ｄは、３ＧＰＰ ＴＳ ３３．２２０または３ＧＰＰ２ ＴＳＧ−ＳドラフトＳ．Ｐ０１０９に記載の汎用ブートストラップ・アーキテクチャ（Generic Bootstrap Architecture：ＧＢＡ）を用いた認証用である。ＵＥおよびＥ−ＳＬＰまたはＥ−ＰＳは、ＧＢＡをサポートする。これは、ＵＥおよびＥ−ＳＬＰまたはＥ−ＰＳが、Ｈ−ＰＬＭＮから安全な共有鍵を取得できるようにする。ＳＵＰＬでは、この鍵は、３ＧＰＰ ＴＳ ３３．２２２または３ＧＰＰ２ ＴＳＧ−ＳドラフトＳ．Ｐ０１１４に記載されているように、ＵＥとＥ−ＳＬＰとの間のＰＳＫ−ＴＬＳ相互認証をサポートするために使用すればよい。この方法は、３ＧＰＰのプロキシ・モードをサポートするためにＳＵＰＬ１．０において使用される。この鍵は、（例えば、３ＧＰＰ ＴＳ ３３．２２２に記載されているような）ＨＴＴＰダイジェスト（Digest）認証、（例えば、３ＧＰＰ２ ＴＳＧ−ＳドラフトＳ．Ｐ０１１４に記載されているような）ＵＥとＥ−ＳＬＰとの間の正しいＨＴＴＰダイジェスト認証、または他の形式の認証を用いたＴＬＳのサポートに使用されればよい。Ｘ．Ｓ００２４では、この鍵は、残りのセキュリティ情報が導き出されるルート鍵として使用されればよい。

方法Ｄは、Ｈ−ＰＬＭＮおよびＶ−ＰＬＭＮにおいてのＧＢＡのサポート、ならびにＨ−ＰＬＭＮとＶ−ＰＬＭＮとの間のローミング契約を利用して、Ｈ−ＰＬＭＮのブートストラッピング・サービング機能（Bootstrapping Serving Function：ＢＳＦ）からＶ−ＰＬＭＮのＥ−ＳＬＰネットワーク・アプリケーション機能（Network Application Function：ＮＡＦ）への鍵情報の転送を可能にする。

方法Ｅは、ＳＵＰＬ１．０またはＸ．Ｓ００２４の認証用である。ＳＵＰＬでは、ＵＥがＨ−ＰＬＭＮ内にある場合、Ｅ−ＳＬＰがＨ−ＳＬＰであればよく、ＳＵＰＬ１．０で定義されている既存の認証メカニズムを使用すればよい。Ｘ．Ｓ００２４では、ＵＥがＨ−ＰＬＭＮ内にある場合、Ｅ−ＰＳがＨ−ＰＳであればよく、Ｘ．Ｓ００２４で定義されている既存の認証メカニズムを使用すればよい。

図１０は、ＵＥ１１０、ＲＡＮ１２０、ＭＳＣ２３０、ロケーション・センター２４２、およびロケーション・サーバ２４４の実施形態のブロック図を示している。ロケーション・センター２４２は、ＧＭＬＣ２３２ａ、ＭＰＣ２３２ｂ、および／または他のエンティティであってもよい。ロケーション・サーバ２４４は、Ｅ−ＳＬＰ２３４ａ、Ｅ−ＳＬＰ２３４ｂ、Ｅ−ＰＳ２３８、および／または他のエンティティであってもよい。簡略化のため、図１０では、ＵＥ１１０に対して１つのプロセッサ１０１０、１つのメモリ１０１２、および１つのトランシーバ１０１４、ＲＡＮ１２０に対して１つのプロセッサ１０２０、１つのメモリ１０２２、１つのトランシーバ１０２４、および１つの通信（Ｃｏｍｍ）ユニット１０２６、ＭＳＣ２３０に対して１つのプロセッサ１０３０、１つのメモリ１０３２、および１つの通信ユニット１０３４、ロケーション・センター２４２に対して１つのプロセッサ１０４０、１つのメモリ１０４２、および１つの通信ユニット１０４４、ロケーション・サーバ２４４に対して１つのプロセッサ１０５０、１つのメモリ１０５２、および１つの通信ユニット１０５４を示している。一般的に、各エンティティは、任意の数のプロセッサ、メモリ、トランシーバ、通信ユニット、コントローラなどを含んでいればよい。

ダウンリンクで、ＲＡＮ１２０の基地局は、トラフィック・データ、シグナリング、およびパイロットを自身のカバレッジ・エリア内のＵＥｓへ送信する。これら様々なタイプのデータは、アンテナを介して送信されるダウンリンク信号を生成するために、プロセッサ１０２０によって処理され、トランシーバ１０２４によって調整される。ＵＥ１１０では、回線モード呼、ロケーション、および他のサービス用の様々なタイプの情報を取得するため、基地局からのダウンリンク信号がアンテナを介して受信され、トランシーバ１０１４によって調整され、プロセッサ１０１０によって処理される。例えば、プロセッサ１０１０は、上記のメッセージ・フローにおいて、ＵＥ１１０用の処理を行えばよい。メモリ１０１２および１０２２は、ＵＥ１１０およびＲＡＮ１２０のプログラム・コードおよびデータをそれぞれ格納する。アップリンクで、ＵＥ１１０は、トラフィック・データ、シグナリング、およびパイロットをＲＡＮ１２０の基地局へ送信すればよい。これら様々なタイプのデータは、ＵＥのアンテナを介して送信されるアップリンク信号を生成するために、プロセッサ１０１０によって処理され、トランシーバ１０１４によって調整される。ＲＡＮ１２０では、様々なタイプの情報（例えば、データ、シグナリング、レポートなど）を取得するため、ＵＥ１１０または他のＵＥｓからのアップリンク信号が受信され、トランシーバ１０２４によって調整され、さらにプロセッサ１０２０によって処理される。ＲＡＮ１２０は、通信ユニット１０２６を介して、ＭＳＣ２３０および他のエンティティと通信する。

ＭＳＣ２３０内において、プロセッサ１０３０はＭＳＣ用の処理を行い、メモリ１０３２はＭＳＣ用のプログラム・コードおよびデータを格納し、通信ユニット１０３４はＭＳＣが他のエンティティと通信できるようにする。プロセッサ１０３０は、上記のメッセージ・フローにおいて、ＭＳＣ２３０用の処理を行えばよい。

ロケーション・センター２４２内において、プロセッサ１０４０はＵＥｓのロケーションをサポートし、メモリ１０４２はロケーション・センター用のプログラム・コードおよびデータを格納し、通信ユニット１０４４はロケーション・センターが他のエンティティと通信できるようにする。プロセッサ１０４０は、上記のメッセージ・フローにおいて、ＧＭＬＣ２３２ａおよび／またはＭＰＣ２３２ｂ用の処理を行えばよい。

ロケーション・サーバ２４４内において、プロセッサ１０５０はＵＥｓのロケーションおよび／または測位処理を行い、メモリ１０５２はロケーション・サーバ用のプログラム・コードおよびデータを格納し、通信ユニット１０５４はロケーション・サーバが他のエンティティと通信できるようにする。プロセッサ１０５０は、上記のメッセージ・フローにおいて、Ｅ−ＳＬＰ２３４ａ、Ｅ−ＳＬＰ２３４ｂ、および／またはＥ−ＰＳ２３８用の処理を行えばよい。

本願明細書に記載の技術は、様々な手段によって実施できる。例えば、これらの技術は、ハードウェア、ファームウェア、ソフトウェア、またはそれらの組み合わせに実装されてもよい。ハードウェア実装では、この技術を実施するために使用される処理ユニットは、１つ以上の特定用途向け集積回路（application specific integrated circuits：ＡＳＩＣｓ）、デジタル信号プロセッサ（digital signal processors：ＤＳＰｓ）、デジタル信号処理デバイス（digital signal processing devices：ＤＳＰＤｓ）、プログラマブル・ロジック・デバイス（programmable logic devices：ＰＬＤｓ）、フィールド・プログラマブル・ゲートアレー（field programmable gate arrays：ＦＰＧＡｓ）、プロセッサ、コントローラ、マイクロコントローラ、マイクロプロセッサ、電子デバイス、本願明細書に記載の機能を実行するように設計された他の電子ユニット、またはそれらの組み合わせに実装すればよい。

ファームウェアおよび／またはソフトウェア実装では、本技術は、本願明細書に記載の機能を実行するモジュール（例えば、プロシージャ、関数など）を用いて実装することができる。ファームウェアおよび／またはソフトウェアコードは、メモリ（例えば、図１０のメモリ１０１２、１０２２、１０３２、１０４２、および／または１０５２）に格納され、プロセッサ（例えば、プロセッサ１０１０、１０２０、１０３０、１０４０、および／または１０５０）によって実行されればよい。メモリは、プロセッサの内部、またはプロセッサの外部に実装されればよい。

本願明細書には、参照用および特定の節を探しやすくするために見出しが含まれている。これらの見出しは、その下に記載されている概念の範囲を制限するものではなく、これらの概念は、本願明細書全体を通して他の節においても適用可能であり得る。

上記で開示された実施形態の説明は、当業者が本開示を作成または使用できるように提供されたものである。これらの実施形態に対して様々な変更ができることは当業者であれば容易に分かることであり、本願明細書で定義された一般的な原理は、本開示の精神または範囲から逸脱することなく、他の実施形態に適用し得る。したがって、本開示は本願明細書で示された実施形態に限定されるものではなく、本願明細書で開示された原理および新規な特徴に則って、幅広い範囲に適合されるものとする。

Claims (18)

1. 第２のロケーション・サーバであって、
   通信ユニットと、
   前記通信ユニットに結合されたプロセッサと
   を含み、前記プロセッサは、
   無線ネットワークとの緊急サービスのための緊急回線モード呼を有するユーザ機器（ＵＥ）の位置推定の要求を受信し、
   前記位置推定を得るために、第１のロケーション・サーバが前記ＵＥの仮の位置推定を得た後に前記ＵＥを用いてユーザ・プレーン・ロケーションを実行し、
   前記位置推定を前記第１のロケーション・サーバに返信する
   ように構成される、第２のロケーション・サーバ。
2. 前記プロセッサは、前記位置推定を得るために、セキュア・ユーザ・プレーン・ロケーション（ＳＵＰＬ）に従って、前記ＵＥを用いて前記ユーザ・プレーン・ロケーションを実行するようにさらに構成される、請求項１に記載の第２のロケーション・サーバ。
3. 前記プロセッサは、前記位置推定を得るために、Ｘ．Ｓ００２４に従って、前記ＵＥを用いて前記ユーザ・プレーン・ロケーションを実行するようにさらに構成される、請求項１に記載の第２のロケーション・サーバ。
4. 前記プロセッサは、前記ＵＥを用いて前記ユーザ・プレーン・ロケーションを開始するためのメッセージを送信するようにさらに構成され、前記メッセージは、前記ユーザ・プレーン・ロケーションの間、前記第２のロケーション・サーバと通信することを前記ＵＥに可能にさせるための、前記第２のロケーション・サーバのインターネット・プロトコル（ＩＰ）アドレスを含む、請求項１に記載の第２のロケーション・サーバ。
5. 前記プロセッサは、前記緊急サービスのための緊急回線モード呼の間、前記ＵＥのホームロケーション・サーバの代わりとしての役割を果たすようにさらに構成される、請求項１に記載の第２のロケーション・サーバ。
6. 前記プロセッサは、前記ＵＥの前記ユーザ・プレーン・ロケーションをサポートするために訪問先ロケーション・サーバを選択するようにさらに構成され、前記訪問先ロケーション・サーバと前記ＵＥとの間で交換されたメッセージを転送するように構成される、請求項１に記載の第２のロケーション・サーバ。
7. 第２のロケーション・サーバにおいて、第１のロケーション・サーバから、無線ネットワークとの緊急サービスのための緊急回線モード呼を有するユーザ機器（ＵＥ）の補足的な位置推定の要求を受信することと、
   前記補足的な位置推定を得るために、前記第１のロケーション・サーバが前記ＵＥの仮の位置推定を得た後に前記ＵＥを用いてユーザ・プレーン・ロケーションを実行することと、
   前記補足的な位置推定を前記第１のロケーション・サーバに返信することと
   を含む方法。
8. 前記ユーザ・プレーン・ロケーションを実行することは、前記ＵＥを用いて前記ユーザ・プレーン・ロケーションを開始するために、前記ＵＥにメッセージを送信することを含み、前記メッセージは、前記ユーザ・プレーン・ロケーションの間、前記第２のロケーション・サーバと通信することを前記ＵＥに可能にさせるための前記第２のロケーション・サーバのインターネット・プロトコル（ＩＰ）アドレスを含む、請求項７に記載の方法。
9. 命令を記憶した非一時的なコンピュータ読取可能な媒体であって、前記命令がプロセッサによって実行されると、前記プロセッサは、
   ユーザ機器（ＵＥ）からの緊急サービスのための緊急回線モード呼をルーティングするための情報の要求を、第１のロケーション・サーバにおいて、第１のエンティティから受信し、
   前記要求に基づいて前記ＵＥの仮の位置推定を得て、
   前記情報を前記第１のエンティティに提供し、
   前記ＵＥの位置推定の要求を第２のエンティティから受信し、
   前記位置推定を得るために、ユーザ・プレーン・ロケーションをサポートする第２のロケーション・サーバと通信し、
   前記位置推定を前記第２のエンティティに提供する、
   非一時的なコンピュータ読取可能な媒体。
10. 命令を記憶した非一時的なコンピュータ読取可能な媒体であって、前記命令がプロセッサによって実行されると、前記プロセッサは、
    無線ネットワークとの緊急サービスのための緊急回線モード呼を有するユーザ機器（ＵＥ）の補助的な位置推定の要求を、第２のロケーション・サーバにおいて、第１のロケーション・サーバから受信し、
    前記第１のロケーション・サーバが前記ＵＥの仮の位置推定を得た後に、前記補助的な位置推定を得るために前記ＵＥを用いてユーザ・プレーン・ロケーションを実行し、
    前記補助的な位置推定を前記第１のロケーション・サーバに返信する、
    非一時的なコンピュータ読取可能な媒体。
11. 前記第１のロケーション・サーバは、ゲートウェイ移動ロケーション・センターである、請求項１に記載の第２のロケーション・サーバ。
12. 前記第１のロケーション・サーバは、移動測位センターである、請求項１に記載の第２のロケーション・サーバ。
13. 前記第１のロケーション・サーバは、ゲートウェイ移動ロケーション・センターである、請求項７に記載の方法。
14. 前記第１のロケーション・サーバは、移動測位センターである、請求項７に記載の方法。
15. 前記第１のロケーション・サーバは、移動測位センターである、請求項９に記載の非一時的なコンピュータ読取可能な媒体。
16. 前記第１のロケーション・サーバは、ゲートウェイ移動ロケーション・センターである、請求項９に記載の非一時的なコンピュータ読取可能な媒体。
17. 前記第１のロケーション・サーバは、移動測位センターである、請求項１０に記載の非一時的なコンピュータ読取可能な媒体。
18. 前記第１のロケーション・サーバは、ゲートウェイ移動ロケーション・センターである、請求項１０に記載の非一時的なコンピュータ読取可能な媒体。

Images