JP2018519712A - 非補償気圧情報の転送 - Google Patents

Abstract

非補償気圧（ＵＢＰ）を公共安全応答ポイント（ＰＳＡＰ）に提供するための技法が開示される。ユーザ機器（ＵＥ）とＰＳＡＰとの間でＵＢＰを提供するための装置の一例は、ロケーションサーバとゲートウェイとを含む。ロケーションサーバは、ＵＥから非補償気圧（ＵＢＰ）を受信し、ＵＢＰを含む都市または地理的ロケーションレコードを生成し、ＵＢＰを含む都市または地理的ロケーションレコードをゲートウェイに提供するように構成される。ゲートウェイは、ＵＢＰを含む都市または地理的ロケーションレコードをロケーションサーバから受信することと、ＵＢＰを含む都市ロケーションレコードをＰＳＡＰに転送すること、あるいは都市または地理的ロケーションレコードからＵＢＰを抽出することのいずれかと、ＵＢＰをＰＳＡＰに別個に提供することとを行うように構成される。

Description

関連出願の相互参照
[0001]本出願は、本出願の譲受人に譲渡され、その内容全体が参照により本明細書に組み込まれる、その両方が「Ｔｒａｎｓｆｅｒ ｏｆ Ｕｎｃｏｍｐｅｎｓａｔｅｄ Ｂａｒｏｍｅｔｒｉｃ Ｐｒｅｓｓｕｒｅ Ｉｎｆｏｒｍａｔｉｏｎ」と題する２０１５年５月４日に出願された米国仮出願第６２／１５６，８４５号および２０１５年９月２１日に出願された米国非仮出願第１４／８６０，４５２号の利益を主張する。

[0002]音声およびデータなどの様々なタイプの通信コンテンツを提供するために、ワイヤレス通信システムが広く展開されている。一般のワイヤレス通信システムは、利用可能なシステムリソース（たとえば、帯域幅、送信電力）を共有することによって複数のユーザとの通信をサポートできる多元接続システムであり得る。そのような多元接続システムの例は、符号分割多元接続（ＣＤＭＡ）システム、時分割多元接続（ＴＤＭＡ）システム、周波数分割多元接続（ＦＤＭＡ）システム、直交周波数分割多元接続（ＯＦＤＭＡ）システムなどを含み得る。追加として、システムは、ロングタームエボリューション（ＬＴＥ（登録商標））のための第３世代パートナーシッププロジェクト（３ＧＰＰ（登録商標））、ＬＴＥアドバンスト（ＬＴＥ−Ａ）、ユニバーサル移動電気通信システム（ＵＭＴＳ）、汎用パケット無線サービス（ＧＰＲＳ）、モバイル通信用グローバルシステム（ＧＳＭ（登録商標））などからの仕様などの仕様に適合することができる。

[0003]通常、現代のワイヤレス通信システムは、ワイヤレス端末による受信無線信号（たとえば、ナビゲーション衛星、基地局、アクセスポイントからの信号）および場合によっては他の情報（たとえば、気圧の空気圧）の測定に基づいてワイヤレス端末の位置を特定するための、位置特定機能を含む。緊急事態の間、モバイルデバイスは、９１１または１１２に電話をかけることなどの、公共安全応答ポイント（ＰＳＡＰ：Public Safety Answering Point）と接続するために使用され得る。適切なリソースを経路指定し緊急呼に対応する際にＰＳＡＰを支援するために、ワイヤレス通信システムは、ロケーション関連情報をモバイルデバイスに提供し得る。ロケーション関連情報は、気圧の測定値などの、モバイルデバイスによって作成されたいくつかの測定値を含み得る。ロケーション関連情報をＰＳＡＰに提供するためのモバイルデバイスまたはネットワークの能力の改善は、緊急要員（emergency personnel）にとって低減された対応時間につながり得る。

[0004]本開示に従って非補償気圧（ＵＢＰ：uncompensated barometric pressure）情報を公共安全応答ポイント（ＰＳＡＰ）に提供するための方法の一例は、ユーザ機器に対する出動可能都市ロケーションを取得することと、ユーザ機器から非補償気圧を取得することと、ＵＢＰを出動可能都市ロケーションと組み合わせることと、ＵＢＰと出動可能都市ロケーションとをＰＳＡＰへ送ることとを含む。

[0005]そのような方法の実装形態は、以下の特徴のうちの１つまたは複数を含み得る。ＵＢＰおよび出動可能都市ロケーションは、ロケーションサーバによって取得され得る。ロケーションサーバは、拡張サービングモバイルロケーションセンター（Ｅ−ＳＭＬＣ：Enhanced Serving Mobile Location Center）、緊急安全ロケーションユーザプレーン位置特定（ＳＵＰＬ：Secure Location User Plane Location）ロケーションプラットフォーム（Ｅ−ＳＬＰ：Enhanced SUPL Location Platform）、またはスタンドアロンサービングモバイルロケーションセンター（ＳＡＳ：Standalone SMLC）のうちの１つであってよい。ＵＢＰは、ＯＭＡ ＬＴＥ測位プロトコル拡張（ＬＰＰｅ：LTE（登録商標） Positioning Protocol Extensions）プロトコル、３ＧＰＰ ＬＴＥ測位プロトコル（ＬＰＰ：LTE Positioning Protocol）、ＬＴＥ用の３ＧＰＰ無線リソース制御（ＲＲＣ：Radio Resource Control）プロトコル、ＵＭＴＳ用の３ＧＰＰ ＲＲＣプロトコル、３ＧＰＰ ＬＴＥ測位プロトコルＡ（ＬＰＰａ：LTE Positioning Protocol A）プロトコル、または３ＧＰＰ測位計算アプリケーションパート（ＰＣＡＰ：Positioning Calculation Application Part）プロトコルのうちの少なくとも１つを介してユーザ機器から取得され得る。出動可能都市ロケーションは、プレゼンス情報データフォーマットロケーションオブジェクト（ＰＩＤＦ−ＬＯ：Presence Information Data Format Location Object）を含み得る。ＰＩＤＦ−ＬＯは、国家緊急アドレスデータベース（ＮＥＡＤ：National Emergency Address Database）から取得され得る。ＵＢＰと出動可能都市ロケーションとをＰＳＡＰに提供することは、３ＧＰＰ Ｉｕｐｃ、Ｉｕ−ｃｓ、Ｉｕ−ｐｓ、ＳＬｓ、ＳＬｇ、Ｌｇ、Ｌｇｄ、またはＬ０インターフェースのうちの少なくとも１つを介して、ＵＢＰと出動可能都市ロケーションとをゲートウェイに提供する
ことと、ＨＴＴＰ対応ロケーション配信（ＨＥＬＤ：HTTP Enabled Location Delivery）プロトコル、ＯＭＡモバイルロケーションプロトコル（ＭＬＰ：Mobile Location Protocol）、またはＴＩＡ／ＡＴＩＳ Ｊ−ＳＴＤ−０３６ Ｅ２プロトコルのうちの少なくとも１つを介して、少なくともＵＢＰをゲートウェイからＰＳＡＰに提供することとを含み得る。

[0006]本開示に従ってユーザ機器（ＵＥ）と公共安全応答ポイント（ＰＳＡＰ）との間で非補償気圧を提供するための装置の一例は、それぞれが少なくとも１つのプロセッサとメモリとを備える、ロケーションサーバとゲートウェイとを含む。ロケーションサーバは、ＵＥから非補償気圧（ＵＢＰ）を取得し、ＵＢＰを含む都市ロケーションレコードを生成し、ＵＢＰを含む都市ロケーションレコードをゲートウェイに提供するように構成される。ゲートウェイは、ＵＢＰを含む都市ロケーションレコードをロケーションサーバから取得し、都市ロケーションレコードからＵＢＰを抽出し、ＵＢＰをＰＳＡＰに提供するように構成される。

[0007]そのような装置の実装形態は、以下の特徴のうちの１つまたは複数を含み得る。ロケーションサーバは、拡張サービングモバイルロケーションセンター（Ｅ−ＳＭＬＣ）、緊急安全ロケーションユーザプレーン位置特定（ＳＵＰＬ）ロケーションプラットフォーム（Ｅ−ＳＬＰ）、またはスタンドアロンサービングモバイルロケーションセンター（ＳＡＳ）のうちの１つであってよい。ロケーションサーバは、３ＧＰＰ ＳＬｓ、ＳＬｇ、Ｌ０、Ｌｇ、Ｌｇｄ、Ｉｕｐｃ、Ｉｕ−ｃｓ、またはＩｕ−ｐｓインターフェースのうちの少なくとも１つを介してゲートウェイに提供するように構成され得る。ロケーションサーバは、空き都市ロケーションレコードを生成し、空き都市ロケーションレコードとＵＢＰとを組み合わせ、空き都市ロケーションレコードとＵＢＰとをゲートウェイに提供するようにさらに構成され得る。ＵＢＰは、ＯＭＡ ＬＴＥ測位プロトコル拡張（ＬＰＰｅ）、３ＧＰＰ ＬＴＥ測位プロトコル（ＬＰＰ）、ＬＴＥ用の３ＧＰＰ無線リソース制御（ＲＲＣ）プロトコル、ＵＭＴＳ用の３ＧＰＰ ＲＲＣプロトコル、３ＧＰＰ ＬＴＥ測位プロトコルＡ（ＬＰＰａ）プロトコル、または３ＧＰＰ測位計算アプリケーションパート（ＰＣＡＰ）プロトコルのうちの少なくとも１つを介してＵＥから取得され得る。ゲートウェイは、ＨＴＴＰ対応ロケーション配信（ＨＥＬＤ）プロトコル、ＯＭＡモバイルロケーションプロトコル（ＭＬＰ）、もしくはＴＩＡ／ＡＴＩＳ Ｊ−ＳＴＤ−０３６ Ｅ２プロトコル、またはそれらの組合せを介してＵＢＰをＰＳＡＰに提供するように構成され得る。ゲートウェイは、都市ロケーションレコードをＰＳＡＰに提供するようにさらに構成され得る。

[0008]本開示に従ってユーザ機器（ＵＥ）と公共安全応答ポイント（ＰＳＡＰ）との間で非補償気圧（ＵＢＰ）を提供するための装置の一例は、ＵＥに対するロケーション情報を決定するための手段と、ＵＥからＵＢＰを受信するための手段と、ＵＢＰをロケーション情報と組み合わせるための手段と、ＵＢＰとロケーション情報とをゲートウェイに提供するための手段と、ロケーション情報からＵＢＰを抽出するための手段と、ＵＢＰをＰＳＡＰに提供するための手段とを含む。

[0009]そのような装置の実装形態は、以下の特徴のうちの１つまたは複数を含み得る。ＵＥからＵＢＰを受信するための手段は、ＯＭＡ ＬＴＥ測位プロトコル拡張（ＬＰＰｅ）、３ＧＰＰ ＬＴＥ測位プロトコル（ＬＰＰ）、ＬＴＥ用の３ＧＰＰ無線リソース制御（ＲＲＣ）プロトコル、ＵＭＴＳ用の３ＧＰＰ ＲＲＣプロトコル、３ＧＰＰ ＬＴＥ測位プロトコルＡ（ＬＰＰａ）プロトコル、または３ＧＰＰ測位計算アプリケーションパート（ＰＣＡＰ）プロトコルのうちの少なくとも１つを含み得る。ＵＢＰとロケーション情報とをゲートウェイに提供するための手段は、３ＧＰＰ ＳＬｓ、ＳＬｇ、Ｌ０、Ｌｇ、Ｌｇｄ、Ｉｕｐｃ、Ｉｕ−ｃｓ、またはＩｕ−ｐｓインターフェースのうちの少なくとも１つを含み得る。ＵＥに対するロケーション情報を決定するための手段は、ＳＰＳ受信機を含み得る。ＵＢＰをＰＳＡＰに提供するための手段は、ＨＥＬＤ、ＭＬＰ、またはＥ２プロトコルのうちの少なくとも１つを含む。ＵＢＰをロケーション情報と組み合わせるための手段は、ＵＢＰを表す２つの追加オクテットのデータフィールドに地理的ロケーション列を連結することを含み得る。

[0010]本開示による非一時的プロセッサ可読記憶媒体の一例は、非補償気圧情報を公共安全応答ポイント（ＰＳＡＰ）に提供するための命令を含み、命令は、ユーザ機器から非補償気圧（ＵＢＰ）を受信するためのコードと、ユーザ機器に対する出動可能都市ロケーションを受信するためのコードと、ＵＢＰを出動可能都市ロケーションと組み合わせるためのコードと、ＵＢＰと出動可能都市ロケーションとをＰＳＡＰへ送るためのコードとを含む。

[0011]そのような非一時的プロセッサ可読記憶媒体の実装形態は、以下の特徴のうちの１つまたは複数を含み得る。ＵＢＰと出動可能都市ロケーションとをロケーションサーバを用いて受信するためのコード。ロケーションサーバは、発展型サービングモバイルロケーションセンター（Ｅ−ＳＭＬＣ）、緊急安全ユーザプレーン位置特定（ＳＵＰＬ）ロケーションプラットフォーム（Ｅ−ＳＬＰ）、またはスタンドアロンサービングモバイルロケーションセンター（ＳＡＳ）のうちの１つであってよい。ユーザ機器からＵＢＰを受信するためのコードは、ＯＭＡ ＬＴＥ測位プロトコル拡張（ＬＰＰｅ）、３ＧＰＰ ＬＴＥ測位プロトコル（ＬＰＰ）、ＬＴＥ用の３ＧＰＰ無線リソース制御（ＲＲＣ）プロトコル、ＵＭＴＳ用の３ＧＰＰ ＲＲＣプロトコル、３ＧＰＰ ＬＴＥ測位プロトコルＡ（ＬＰＰａ）プロトコル、または３ＧＰＰ測位計算アプリケーションパート（ＰＣＡＰ）プロトコルのうちの少なくとも１つを介してＵＢＰを取得するように構成され得る。出動可能都市ロケーションは、プレゼンス情報データフォーマットロケーションオブジェクト（ＰＩＤＦ−ＬＯ）を含み得、ＰＩＤＦ−ＬＯは、国家緊急アドレスデータベース（ＮＥＡＤ）から取得され得る。ＵＢＰと出動可能都市ロケーションとをＰＳＡＰへ送るためのコードは、３ＧＰＰ Ｉｕｐｃ、Ｉｕ−ｃｓ、Ｉｕ−ｐｓ、ＳＬｓ、ＳＬｇ、Ｌｇ、Ｌｇｄ、またはＬ０インターフェースのうちの少なくとも１つを介して、ＵＢＰと出動可能都市ロケーションとをゲートウェイに提供するためのコードと、ＨＥＬＤ、ＭＬＰ、またはＥ２プロトコルのうちの少なくとも１つを介して、少なくともＵＢＰをゲートウェイからＰＳＡＰに提供するためのコードとを含み得る。

[0012]本開示に従ってユーザ機器（ＵＥ）と公共安全応答ポイント（ＰＳＡＰ）との間で非補償気圧を提供するためのゲートウェイの一例は、非補償気圧（ＵＢＰ）を含む出動可能都市ロケーションレコードを取得するように構成されたネットワークインターフェースと、出動可能都市ロケーションレコードからＵＢＰを抽出するように構成されたプロセッサおよびメモリとを含み、ネットワークインターフェースは、ＵＢＰをＰＳＡＰに提供するようにさらに構成される。

[0013]そのようなゲートウェイの実装形態は、以下の特徴のうちの１つまたは複数を含み得る。ネットワークインターフェースは、ＨＴＴＰ対応ロケーション配信（ＨＥＬＤ）プロトコル、ＯＭＡモバイルロケーションプロトコル（ＭＬＰ）、もしくはＴＩＡ／ＡＴＩＳ Ｊ−ＳＴＤ−０３６ Ｅ２プロトコル、またはそれらの組合せを介してＵＢＰをＰＳＡＰに提供するように構成され得る。ネットワークインターフェースは、出動可能都市ロケーションレコードをＰＳＡＰに提供するようにさらに構成され得る。

[0014]本開示に従ってユーザ機器（ＵＥ）に対する非補償気圧をゲートウェイに提供するためのロケーションサーバの一例は、ＵＥから非補償気圧（ＵＢＰ）を取得し、ＵＥに対する出動可能都市ロケーションを取得するように構成されたネットワークインターフェースと、ＵＢＰを含む出動可能都市ロケーションレコードを生成するために、ＵＢＰを出動可能都市ロケーションと組み合わせるように構成されたプロセッサおよびメモリとを含み、さらに構成されたネットワークインターフェースは、ＵＢＰを含む出動可能都市ロケーションレコードをゲートウェイに提供する。

[0015]そのようなロケーションサーバの実装形態は、以下の特徴のうちの１つまたは複数を含み得る。ロケーションサーバは、発展型サービングモバイルロケーションセンター（Ｅ−ＳＭＬＣ）、緊急安全ユーザプレーン位置特定（ＳＵＰＬ）ロケーションプラットフォーム（Ｅ−ＳＬＰ）、またはスタンドアロンサービングモバイルロケーションセンター（ＳＡＳ）のうちの１つであってよい。ネットワークインターフェースは、３ＧＰＰ ＳＬｓ、ＳＬｇ、Ｌ０、Ｌｇ、Ｌｇｄ、Ｉｕｐｃ、Ｉｕ−ｃｓ、またはＩｕ−ｐｓインターフェースのうちの少なくとも１つを介して、ＵＢＰを含む出動可能都市ロケーションレコードをゲートウェイに提供するように構成され得る。プロセッサおよびメモリは、空き都市ロケーションレコードを生成するとともに空き都市ロケーションレコードとＵＢＰとを組み合わせるように構成され得、ネットワークインターフェースは、空き都市ロケーションレコードとＵＢＰとをゲートウェイに提供するようにさらに構成され得る。ＵＢＰは、ＯＭＡ ＬＴＥ測位プロトコル拡張（ＬＰＰｅ）プロトコル、３ＧＰＰ ＬＴＥ測位プロトコル（ＬＰＰ）、ＬＴＥ用の３ＧＰＰ無線リソース制御（ＲＲＣ）プロトコル、ＵＭＴＳ用の３ＧＰＰ ＲＲＣプロトコル、３ＧＰＰ ＬＴＥ測位プロトコルＡ（ＬＰＰａ）プロトコル、または３ＧＰＰ測位計算アプリケーションパート（ＰＣＡＰ）プロトコルのうちの少なくとも１つを介してＵＥから取得され得る。

[0016]本開示に従ってロングタームエボリューション（ＬＴＥ）アーキテクチャまたはユニバーサル移動体電気通信システム（ＵＭＴＳ）アーキテクチャにおいて非補償気圧をユーザ機器（ＵＥ）からゲートウェイに提供するための方法の一例は、ＵＥから非補償気圧（ＵＢＰ）を取得することと、ＵＥに対する出動可能都市ロケーションを取得することと、ＵＢＰを含む出動可能都市ロケーションレコードを生成するために、ＵＢＰを出動可能都市ロケーションと組み合わせることと、ＵＢＰを含む出動可能都市ロケーションレコードをゲートウェイに提供することとを含む。

[0017]そのような方法の実装形態は、以下の特徴の上に、または以下の特徴のうちのより多くを含み得る。ＵＢＰおよび出動可能都市ロケーションは、拡張サービングモバイルロケーションセンター（Ｅ−ＳＭＬＣ）、緊急安全ユーザプレーン位置特定（ＳＵＰＬ）ロケーションプラットフォーム（Ｅ−ＳＬＰ）、またはスタンドアロンサービングモバイルロケーションセンター（ＳＡＳ）のうちの１つを介して取得され得る。ＵＢＰを含む出動可能都市ロケーションレコードをゲートウェイに提供することは、３ＧＰＰ ＳＬｓ、ＳＬｇ、Ｌ０、Ｌｇ、Ｌｇｄ、Ｉｕｐｃ、Ｉｕ−ｃｓ、またはＩｕ−ｐｓインターフェースのうちの少なくとも１つを介し得る。出動可能都市ロケーションを取得することは、空き都市ロケーションレコードを生成することと、空き都市ロケーションレコードとＵＢＰとを組み合わせることと、ＵＢＰを含む空き都市ロケーションレコードをゲートウェイに提供することとを含み得る。ＵＢＰは、ＯＭＡ ＬＴＥ測位プロトコル拡張（ＬＰＰｅ）プロトコル、３ＧＰＰ ＬＴＥ測位プロトコル（ＬＰＰ）、ＬＴＥ用の３ＧＰＰ無線リソース制御（ＲＲＣ）プロトコル、ＵＭＴＳ用の３ＧＰＰ ＲＲＣプロトコル、３ＧＰＰ ＬＴＥ測位プロトコルＡ（ＬＰＰａ）プロトコル、または３ＧＰＰ測位計算アプリケーションパート（ＰＣＡＰ）プロトコルのうちの少なくとも１つを介してＵＥから取得され得る。ＵＢＰは、出動可能都市ロケーションレコードから抽出され得、公共安全応答ポイント（ＰＳＡＰ）に提供され得る。ＵＢＰは、ＨＴＴＰ対応ロケーション配信（ＨＥＬＤ）プロトコル、ＯＭＡモバイルロケーションプロトコル（ＭＬＰ）、もしくはＴＩＡ／ＡＴＩＳ Ｊ−ＳＴＤ−０３６ Ｅ２プロトコル、またはそれらの組合せを介してＰＳＡＰに提供され得る。出動可能都市ロケーションレコードは、ＰＳＡＰに提供され得る。

[0018]本明細書で説明する項目および／または技法は、以下の能力のうちの１つまたは複数、ならびに言及されていない他の能力を与え得る。モバイルデバイス（たとえば、ユーザ機器（ＵＥ））が非補償気圧情報（ＵＢＰ）を捕捉し得る。モバイルデバイスユーザが緊急呼を開始し得る。ＵＢＰがサービングコアネットワークに提供される。ＵＥの現在のロケーションに基づく出動可能都市ロケーション情報が取得され得る。ＵＥの現在の地理的ロケーションが決定され得る。ロケーションサーバは、ＵＢＰを出動可能都市ロケーション情報および／または地理的ロケーションと組み合わせる。ＵＢＰは、既存のインターフェースとプロトコルとを使用して、通信ネットワークを通じて転送される。ＵＢＰは、公共安全応答ポイント（ＰＳＡＰ）に提供される。既存のネットワーク基盤の最低限の再構成を用いて連邦命令（federal mandates）が満たされる。さらに、上述の効果が、言及した手段以外の手段によって達成されることが可能であり得、言及した項目／技法は、必ずしも言及した効果を生み出すとは限らない。

[0019]ユーザ機器の一実施形態の構成要素のブロック図。 [0020]非補償気圧（ＵＢＰ）情報を転送するための例示的なワイヤレス通信システムの高レベルアーキテクチャを示す図。 [0021]３ＧＰＰロングタームエボリューション（ＬＴＥ）アクセスを用いてＵＢＰ情報を転送するためのアーキテクチャを示す図。 [0022]ユニバーサル移動電気通信システム（ＵＭＴＳ）アクセスを用いてＵＢＰ情報を転送するためのアーキテクチャを示す図。 [0023]都市ロケーション情報を用いた例示的なＵＢＰ転送手順のメッセージフロー図。 [0024]地理的ロケーション情報を用いた別の例示的なＵＢＰ転送手順のメッセージコールフロー図。 [0025]ＵＢＰと都市ロケーション情報とを公共安全応答ポイント（ＰＳＡＰ）に提供するプロセスのブロックフロー図。 [0026]都市情報を用いずにＵＢＰ情報をＰＳＡＰに提供するプロセスのブロックフロー図。 [0027]ゲートウェイを用いてＵＢＰ情報をＰＳＡＰに提供するプロセスのブロックフロー図。 [0028]ＵＢＰを含む出動可能都市ロケーションレコードをゲートウェイに提供するプロセスのブロックフロー図。 [0029]ロケーション情報メッセージングを介してＵＢＰをＰＳＡＰに提供するためのプロセスのブロックフロー図。 [0030]ＵＢＰ情報を転送する際に使用するためのコンピュータシステムの一実施形態の構成要素のブロック図。

[0031]異なる図における同じ番号のエンティティは、対応するエンティティ、− たとえば、同じエンティティを指す。

[0032]米国では、連邦通信委員会（ＦＣＣ）は、ＵＢＰを測定できるデバイスが緊急９１１呼出しを行うとき、ネットワーク事業者が非補償気圧（ＵＢＰ）の測定値を転送することを義務づけている。ＦＣＣはまた、ワイヤレスデバイスから緊急９１１呼出しがかけられるとき、ネットワーク事業者が、屋内で行われた緊急呼のための確度向上型位置特定情報（ＨＡＬＩ：Heightened Accuracy Location Information）を、緊急発呼者に対する出動可能都市ロケーション、または緊急発呼者に対して水平に５０メートルまで正確な地理的ロケーションのいずれかの形態で提供することを義務づけている。常に実現可能であり、信頼でき、または正確であるとは限らない、対応する高度（たとえば、建築物フロアレベル）にＵＢＰが変換される必要があるので、公共安全側へのＵＢＰの有用性は、都市ロケーションまたは地理的ロケーションのいずれかの有用性よりも低いことがある。加えて、ＵＢＰは、高度座標を公共安全応答ポイント（ＰＳＡＰ）に提供する事業者によって、あと数年のうちに置き換えられる場合がある。したがって、− たとえば、ワイヤレスデバイスからＰＳＡＰまでの介在する制御プレーンおよび／またはユーザプレーンインターフェースにわたってＵＢＰ情報の転送をサポートするように既存のプロトコルを修正することによって、ＵＢＰをサポートすることに過度に大きく投資することに、ネットワーク事業者の一部には抵抗があり得る。たとえば、ＵＢＰ情報転送のサポートは、ロングタームエボリューション（ＬＴＥ）、ユニバーサル移動電気通信システム（ＵＭＴＳ）のための、また国家緊急番号協会（たとえば、ＮＥＮＡ（National Emergency Number Association） ｉ３）対応ＰＳＡＰへの、ならびにレガシーＰＳＡＰへのアクセスのための、既存のプロトコルおよびインターフェースの修正を必要とし得る。緊急９１１呼出しのためにＵＢＰ情報を含めることの有用性があまり期待されていないことが、既存のプロトコルおよびインターフェースへの大きい規格および実装の影響を正当化し得ない。

[0033]より効率的に非補償気圧（ＵＢＰ）情報をＰＳＡＰに提供するための技法が、本明細書で説明される。ＵＢＰ情報は、モバイルデバイス（たとえば、ユーザ機器（ＵＥ））によって、測位プロトコル（たとえば、３ＧＰＰによって規定されるＬＴＥ測位プロトコル（ＬＰＰ）、またはオープンモバイルアライアンス（ＯＭＡ：Open Mobile Alliance）によって規定されるＬＰＰ拡張（ＬＰＰｅ）プロトコル）を使用してロケーションサーバ（たとえば、拡張サービングモバイルロケーションセンター（Ｅ−ＳＭＬＣ）または緊急安全ユーザプレーン位置特定（ＳＵＰＬ）ロケーションプラットフォーム（Ｅ−ＳＬＰ））に提供され得る。ＵＢＰは、パスカル（Ｐａ）、ミリバール、または水銀柱などの単位でサポートされ得る。たとえば、ＬＰＰｅでは、範囲を３０，０００〜１１５，０００ＰａとしてＰａという単位が使用され、そのことは概して、見込みのある任意の高度において、見込みのある任意の屋内または屋外の圧力を表すのに十分と見なされる。そのようなＵＢＰ情報をＰＳＡＰに提供することが可能であり得るが、既存のサービングネットワークによってサポートされる多くのインターフェースおよびプロトコルは、転送をサポートするように拡張される必要があり得る。そのような変更をネットワークにわたって実施するのではなく、ＵＢＰ情報を運搬する効率を改善するための１つの方法は、ＵＢＰをいくつかの他の確度向上型位置特定情報（ＨＡＬＩ）コンテンツと組み合わせることであることになる。たとえば、ＵＢＰは、出動可能都市ロケーション（たとえば、ストリートアドレスまたは建築物名称）と、または水平座標（たとえば、緯度および経度）および場合によっては高度、不確実レベルおよび／または信頼レベルを含み得る、地理的ロケーションと組み合わせられてよい。この組合せは、通信ネットワーク内の影響を及ぼされるプロトコルおよびインターフェースごとに別個のＵＢＰパラメータを標準化および実装する必要を回避し得る。

[0034]図１を参照すると、本明細書の様々な技法が利用され得るユーザ機器（ＵＥ）１００が図示される。ＵＥ１００は、一般に、モバイルデバイスであり、様々なモバイル通信および／またはコンピューティングデバイスの機能を含むことができるかまたは実施することができ、例は、限定はしないが、現在存在するにせよ将来開発されるにせよ、セルフォン、携帯情報端末（ＰＤＡ）、スマートフォン、ラップトップ、デスクトップ、またはタブレットコンピュータなどのコンピューティングデバイス、自動車コンピューティングシステムなどを含む。ＵＥ１００は、移動局、モバイルデバイス、端末、ワイヤレス端末、ワイヤレスデバイス、アクセス端末、加入者ユニット、ステーションと呼ばれることがあり、またはいくつかの他の名称によって呼ばれることもある。

[0035]ＵＥ１００は、プロセッサ１１１（または、プロセッサコア）とメモリ１４０とを含む。ＵＥ１００は、随意に、パブリックバス１０１またはプライベートバス（図示せず）によってメモリ１４０に動作可能に接続された信頼環境（trusted environment）を含み得る。ＵＥ１００はまた、通信インターフェース１２０と、ワイヤレスネットワーク上でワイヤレスアンテナ１２２を介してワイヤレス信号１２３を送り取得するように構成されたワイヤレストランシーバ１２１とを含み得る。ワイヤレストランシーバ１２１は、通信インターフェース１２０を介してバス１０１に接続されている。ここで、ＵＥ１００は、単一のワイヤレストランシーバ１２１を有するものとして示される。しかしながら、ＵＥ１００は、代替として、ＷｉＦｉ（登録商標）（たとえば、ＩＥＥＥ８０２．１１）、ＣＤＭＡ、ワイドバンドＣＤＭＡ（ＷＣＤＭＡ（登録商標））、ロングタームエボリューション（ＬＴＥ）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、短距離ワイヤレス通信技術などの複数の通信規格をサポートするために、複数のワイヤレストランシーバ１２１および／または複数のワイヤレスアンテナ１２２を有することができる。

[0036]通信インターフェース１２０および／またはワイヤレストランシーバ１２１は、複数のキャリア（異なる周波数の波形信号）上での動作をサポートし得る。マルチキャリア送信機は、複数のキャリア上で同時に被変調信号を送信することができる。各被変調信号は、符号分割多元接続（ＣＤＭＡ）信号、時分割多元接続（ＴＤＭＡ）信号、直交周波数分割多元接続（ＯＦＤＭＡ）信号、シングルキャリア周波数分割多元接続（ＳＣ−ＦＤＭＡ）信号などであってよい。各被変調信号は、異なるキャリア上で送られ得、パイロット、オーバーヘッド情報、データなどを搬送し得る。

[0037]ＵＥ１００はまた、ユーザインターフェース１５０（たとえば、ディスプレイ、キーボード、タッチスクリーン、マイクロフォン、スピーカー）と、（たとえば、ワイヤレスアンテナ１２２と同じであってよく、または異なってもよい）ＳＰＳアンテナ１５８を介して衛星測位システム（ＳＰＳ：satellite positioning system）信号１５９を（たとえば、ＳＰＳ衛星から）受信するＳＰＳ受信機１５５とを含み得る。ＳＰＳ受信機１５５は、単一のグローバルナビゲーション衛星システム（ＧＮＳＳ：global navigation satellite system）、または複数のそのようなシステムと通信することができる。ＧＮＳＳは、限定はしないが、全地球測位システム（ＧＰＳ）、Ｇａｌｉｌｅｏ、Ｇｌｏｎａｓｓ、Ｂｅｉｄｏｕ（Ｃｏｍｐａｓｓ）などを含むことができる。ＳＰＳ衛星は、衛星、スペースビークル（ＳＶ：space vehicles）などとも呼ばれる。ＳＰＳ受信機１５５は、ＳＰＳ信号１５９を全体的または部分的に処理し、ＵＥ１００のロケーションを決定するためにこれらのＳＰＳ信号１５９を使用し得るか、またはＵＥ１００がＳＰＳ信号の測定値をロケーションサーバ（たとえば、Ｅ−ＳＭＬＣまたはＥ−ＳＬＰ）に転送することを可能にし得、ロケーションサーバは、ＵＥ１００に対するロケーションを測定値から算出する。プロセッサ１１１、メモリ１４０、デジタル信号プロセッサ（ＤＳＰ）１１２、および／または専用プロセッサ（図示せず）も、ＳＰＳ信号１５９を全体的もしくは部分的に処理するために、および／またはＵＥ１００のロケーションを計算するために、ＳＰＳ受信機１５５とともに利用され得る。ＳＰＳ信号１５９または他のロケーション信号からの情報の記憶は、メモリ１４０またはレジスタ（図示せず）を使用して実行される。１つのプロセッサ１１１、１つのＤＳＰ１１２、および１つのメモリ１４０しか図１に示されないが、これらの構成要素のいずれか、ペア、またはすべてのうちの２つ以上が、ＵＥ１００によって使用されてよい。ＵＥ１００に関連するプロセッサ１１１およびＤＳＰ１１２は、バス１０１に接続されている。

[0038]メモリ１４０は、１つまたは複数の命令またはコードとして機能を記憶する非一時的コンピュータ可読記憶媒体（または、媒体）を含むことができる。メモリ１４０を構成することができる媒体は、限定はしないが、ＲＡＭ、ＲＯＭ、ＦＬＡＳＨ、ディスクドライブなどを含む。概して、メモリ１４０によって記憶される機能は、汎用プロセッサ１１１、専用プロセッサ、またはＤＳＰ１１２によって実行される。したがって、メモリ１４０は、説明する機能をプロセッサ１１１および／またはＤＳＰ１１２に実行させるように構成されたソフトウェア（プログラミングコード、命令など）を記憶するプロセッサ可読メモリおよび／またはコンピュータ可読メモリである。代替として、ＵＥ１００の１つまたは複数の機能は、全体的または部分的にハードウェアで実行されてもよい。

[0039]ロケーション、位置、ロケーション推定値、および位置推定値という用語は、地理的（測地とも呼ばれる）または都市的であり得るロケーションを指すために、本明細書で互換的に使用される。ＵＥ１００に対する地理的ロケーションは、緯度、経度、および場合によっては高度（たとえば、平均海面の上もしくは下、または局所的な地上レベルの上もしくは下）などの座標、またはいくつかの近傍固定点に対して規定される局所的な座標（たとえば、局所的なＸ、Ｙ、Ｚ直交座標）を含み得る。ＵＥ１００に対する都市ロケーション（都市アドレスとも呼ばれる）は、郵便アドレス、ストリートアドレス、よく知られている場所または建築物の名前、建築物または構造物の一部（たとえば、フロアレベル、部屋番号、アパート番号、空港にとってのゲート番号）への参照を含み得る。ＵＥ１００に対する地理的ロケーションおよび都市ロケーションは、ＵＥ１００に対する同じロケーションを指すことがあるが、異なる方法で表現されてよい。ＵＥ１００からＰＳＡＰへの緊急呼の場合、ＵＥ１００に対する都市ロケーションは、出動可能都市ロケーションまたは出動可能ロケーションと呼ばれることがあり、公共安全対応者をＵＥ１００のロケーションに出動させるために、ＰＳＡＰによって使用され得る。

[0040]ＵＥ１００は、視界内の他の通信エンティティおよび／またはＵＥ１００にとって利用可能な情報に基づいて、様々な技法を使用して、その現在位置を推定し得るか、またはＵＥ１００のロケーションを推定するためにロケーションサーバ（たとえば、Ｅ−ＳＭＬＣまたはＥ−ＳＬＰ）などの別のエンティティによって使用され得る情報を取得し得る。たとえば、ＵＥ１００は、その位置を推定することができ、あるいは１つもしくは複数のワイヤレスローカルエリアネットワーク（ＷＬＡＮ）に関連する近くのアクセスポイント（ＡＰ）、ＢｌｕｅｔｏｏｔｈもしくはＺＩＧＢＥＥ（登録商標）などの短距離ワイヤレス通信技術を利用するパーソナルエリアネットワーク（ＰＡＮ）、グローバルナビゲーション衛星システム（ＧＮＳＳ）もしくは他の衛星測位システム（ＳＰＳ）衛星、および／またはマップサーバから取得されたマップデータから取得された情報を使用して、別のエンティティがＵＥ１００の位置を推定することを可能にすることができる。場合によっては、ロケーションサーバは、Ｅ−ＳＭＬＣ、Ｅ−ＳＬＰ、またはスタンドアロンサービングモバイルロケーションセンター（ＳＡＳ）であってよく、ＵＥ１００がロケーション関連測定値（たとえば、ＷＬＡＮ ＡＰ、セルラー基地局、ＧＮＳＳ衛星の測定値）を作成することを可能にするかまたは支援するために、支援データをＵＥ１００に提供し得る。ＵＥ１００は、次いで、ロケーション推定値を算出するために測定値をロケーションサーバに提供し得るか、または測定値に基づいて、場合によってはロケーションサーバによって提供される（たとえば、ＧＮＳＳ衛星に対する軌道データおよびタイミングデータ、またはＷＬＡＮ ＡＰおよび／もしくはセルラー基地局の正確なロケーション座標などの）他の支援データにも基づいて、ロケーション推定値をそれ自体で算出し得る。

[0041]圧力センサー１３０は、ＵＥ１００内に（たとえば、内部的に）含まれてよく、または周辺デバイスとして（たとえば、外部的に）ＵＥ１００に動作可能に結合されてもよい。圧力センサー１３０は、気圧情報（たとえば、１０〜１２００ｍｂａｒ）をプロセッサ１１１に提供するように構成される。例示的な圧力センサーは、Ｍｅａｓｕｒｅｍｅｎｔ ＳｐｅｃｉａｌｔｉｅｓのＭＳ５６０７、ＢｏｓｃｈのＢＭＰ０８５またはＢＭＰ２８０、およびＳＴＭｉｃｒｏｅｌｅｃｔｒｏｎｉｃｓのＬＰＳ２２ＨＢまたはＬＳＰ３３１ＡＰを含み得る。大気圧を検出するように構成された他のそのような圧電抵抗性圧力センサーが使用され得るので、これらの例は限定でない。圧力センサー１３０は、周辺気圧を検出するように構成され、ＵＥ１００は、そのような非補償気圧（ＵＢＰ）情報を通信システム（たとえば、Ｅ−ＳＭＬＣ、Ｅ−ＳＬＰ、またはＳＡＳなどのロケーションサーバ）に提供し得る。気圧（barometric pressure）、気圧の空気圧（barometric air pressure）、大気圧（atmospheric pressure）という用語は、− たとえば、ＵＥ１００のロケーションにおいて、大気圧を指すために本明細書で互換的に使用される。ＵＢＰという用語は、ＵＥによる（たとえば、圧力センサー１３０を使用するＵＥ１００による）大気圧の測定値を指し、圧力測定値は、必ずしも測定値における任意の誤差を補償するようにＵＥによって調整されるとは限らない。

[0042]図１をさらに参照しながら図２を参照すると、非補償気圧（ＵＢＰ）情報を転送するための例示的な通信システム２００が示される。ＵＥ１００は、通信サービスを取得するためにアクセスネットワーク２０２と通信し得る。ＵＥ１００は、アクセスネットワーク２０２の中の１つもしくは複数の基地局および／または１つもしくは複数のアクセスポイントと通信し得る。ＵＥ１００はまた、米国の全地球測位システム（ＧＰＳ）、欧州のＧａｌｉｌｅｏシステム、ロシアのＧＬＯＮＡＳＳシステムなどの一部であってよい１つまたは複数の衛星２９０から、信号を受信し得る。ＵＥ１００は、アクセスネットワーク２０２の中の基地局および／またはＡＰからの信号を測定し得、基地局および／またはＡＰに対する信号タイミング、信号強度、および／または信号品質の測定値を取得し得る。ＵＥ１００はまた、衛星２９０からの信号を測定し得、衛星に対する擬似距離（または、コード位相もしくはキャリア位相）測定値を取得し得る。擬似距離測定値および／またはタイミング測定値は、ＵＥ１００によるかまたはロケーションサーバ２０６によるかのいずれかで、ＵＥ１００に対する位置推定値を導出するために使用され得る。ＵＥ１００はまた、（たとえば、圧力センサー１３０によって測定されるような）非補償気圧（ＵＢＰ）情報をロケーションサーバ２０６に提供するように構成される。

[0043]アクセスネットワーク２０２は、そのカバレージエリア内に位置するＵＥに無線通信を提供する。アクセスネットワーク２０２は、無線ネットワーク、無線アクセスネットワーク（ＲＡＮ：radio access network）などと呼ばれることもある。アクセスネットワーク２０２は、以下で説明するように、基地局、アクセスポイント、ネットワークコントローラ、および／または他のエンティティを含み得る。サービングコアネットワーク２０４は、コアネットワークまたは発展型パケットコア（ＥＰＣ：evolved packet core）と呼ばれることがあり、様々な通信サービスをサポートし得るネットワークエンティティを含み得る。ロケーションサーバ２０６は、サービングコアネットワーク２０４と通信するＵＥのための位置特定サービスをサポートし得（たとえば、ＵＥがサービングコアネットワーク２０４へローミングすることを含む）、ＵＥがロケーションサーバ２０６への任意のサービス加入もしくは任意の事前関係を有することを必要とすることがあり、または必要としないこともある。サービングコアネットワーク２０４はまた、レガシー緊急サービスネットワーク（ＥＳＮ：Emergency Services Network）／ＰＳＡＰ２１０ａおよびｉ３緊急サービスＩＰネットワーク（ＥＳＩｎｅｔ：Emergency Services IP network）／ＰＳＡＰ２１０ｂなどのＰＳＡＰとのメッセージングをサポートするように構成されたゲートウェイ２０８を含み得る。

[0044]ロケーションサーバ２０６は、Ｅ−ＳＭＬＣ、Ｅ−ＳＬＰ、またはＳＡＳに相当し得、制御プレーン位置特定解決策（たとえば、ロケーションサーバ２０６がＥ−ＳＭＬＣまたはＳＡＳである場合）、またはオープンモバイルアライアンス（ＯＭＡ）ＳＵＰＬ解決策などのユーザプレーン位置特定解決策（たとえば、ロケーションサーバ２０６がＥ−ＳＬＰである場合）をサポートし得る。ロケーションサーバ２０６は、（ｉ）ＵＥ１００がロケーション関連測定値を作成および／またはそのような測定値からロケーション推定値を算出することを支援するために、支援データをＵＥ１００に転送し、（ｉｉ）ロケーション関連測定値および／またはロケーション推定値をＵＥ１００に要求し、ならびに／あるいは（ｉｉｉ）ロケーション関連測定値および／またはロケーション推定値をＵＥ１００から受信するために、ＵＥ１００と相互作用し得る。ロケーションサーバ２０６は、ＵＥ１００に対するロケーション推定値（たとえば、緯度、経度、および場合によっては高度）を、ＵＥ１００から受信されたロケーション関連測定値から算出し得る。ロケーションサーバ２０６は、（ｉ）３ＧＰＰによって規定されるＬＴＥ測位プロトコル（ＬＰＰ）と、（ｉｉ）ＯＭＡによって規定されるＬＰＰ拡張（ＬＰＰｅ）プロトコルと、（ｉｉｉ）３ＧＰＰによって規定されるＵＭＴＳ用の測位計算アプリケーションパート（ＰＣＡＰ）＋無線リソース制御（ＲＲＣ）プロトコルと、（ｉｖ）ＯＭＡによって規定されるＳＵＰＬユーザプレーン位置特定プロトコル（ＵＬＰ：UserPlane Location Protocol）と、（ｖ）３ＧＰＰによって規定されるＬＴＥ用のＬＴＥ測位プロトコルＡ（ＬＰＰａ）＋ＲＲＣプロトコルとを含む、いくつかの異なる測位プロトコルのうちの１つまたは複数を使用してＵＥ１００と相互作用し得る。たとえば、ロケーションサーバがＥ−ＳＭＬＣまたはＥ−ＳＬＰであるとき、ＵＥ１００およびロケーションサーバ２０６は、ＬＰＰｅと組み合わせられたＬＰＰを使用して相互作用し得る。ＬＰＰｅと組み合わせられたＬＰＰの使用は、ＬＰＰ／ＬＰＰｅと呼ばれることがあり、ＬＰＰメッセージを転送することを含み得、ここで、各ＬＰＰメッセージは、− たとえば、３ＧＰＰ ＴＳ３６．３５５においてＬＰＰに対して規定されるように、単一のＬＰＰｅメッセージを埋め込む。

[0045]ゲートウェイ２０８は、３ＧＰＰによって規定されるような（たとえば、３ＧＰＰ技術仕様（ＴＳ）２３．１６７および２３．２７１における）ゲートウェイモバイルロケーションセンター（ＧＭＬＣ：Gateway Mobile Location Center）またはロケーション検索機能（ＬＲＦ：Location Retrieval Function）に相当し得、− たとえば、ゲートウェイ２０８がＵＥ１００のためのロケーション要求をレガシーＥＳＮ／ＰＳＡＰ２１０ａまたはｉ３ ＥＳＩｎｅｔ／ＰＳＡＰ２１０ｂから受信したとき、ロケーションサーバ２０６を経由してＵＥ１００の測位を誘発し得る。ゲートウェイ２０８は、次いで、ロケーションサーバ２０６からサービングコアネットワークの中の１つもしくは複数の中間エンティティを経由して、または直接ロケーションサーバ２０６から、ＵＥ１００に対するロケーション情報（たとえば、出動可能都市ロケーションおよび／または地理的ロケーションを備え得るＨＡＬＩ）を受信し得、ロケーション情報をレガシーＥＳＮ／ＰＳＡＰ２１０ａまたはｉ３ ＥＳＩｎｅｔ／ＰＳＡＰ２１０ｂへ送り得る。

[0046]ロケーションサーバ２０６、ゲートウェイ２０８、またはサービングコアネットワーク２０４の中のいくつかの他のエンティティは、ＵＥ１００に対する都市ロケーション用の国家緊急アドレスデータベース（ＮＥＡＤ）２１２を照会し得る。たとえば、ＵＥ１００は、ＵＥ１００にとって認識できる１つまたは複数のＷＬＡＮ ＡＰおよび／またはＢｌｕｅｔｏｏｔｈビーコンの識別情報（たとえば、ＭＡＣアドレス）をロケーションサーバ２０６に提供し得、ロケーションサーバ２０６またはサービングコアネットワーク２０４の中のいくつかの他のエンティティは、これらの識別情報をＮＥＡＤ２１２に提供し得る。ＮＥＡＤ２１２は、次いで、対応する都市ロケーション情報（たとえば、ストリートアドレスおよび／または建築物名称、フロアレベル、ならびに場合によっては部屋番号またはアパート番号）が前に構成されていた、知られているＷＬＡＮ ＡＰおよび／またはＢｌｕｅｔｏｏｔｈビーコンのデータベースを探索し得、識別されたＡＰおよび／またはビーコンのうちの１つまたは複数の各々に対する都市ロケーションを戻し得る。ロケーションサーバ２０６は、次いで、− たとえば、識別されたＷＬＡＮ ＡＰおよび／またはＢｌｕｅｔｏｏｔｈビーコンからの信号の、ＵＥ１００による（たとえば、ＲＳＳＩまたはＲＴＴに対する）測定値から推定されるような、ＵＥ１００のロケーションに最も近いように見えるＷＬＡＮ ＡＰまたはＢｌｕｅｔｏｏｔｈビーコンに対する、ＮＥＡＤ２１２によって戻された都市ロケーションを選択することによって、ＮＥＡＤ２１２によって戻された１つまたは複数の都市ロケーションを出動可能都市ロケーションに変換し得る。この出動可能都市ロケーション情報は、たとえば、次いで、ＵＥ１００のためのＨＡＬＩの一部としてゲートウェイ２０８に転送され得る。

[0047]ＮＥＡＤ２１２は、運用機能と、管理機能と、保守機能と、供給機能とを、国家緊急アドレスマネージャ（ＮＥＡＭ：National Emergency Address Manager）２１４から受信し得る。ＮＥＡＭ２１４は、１つまたは複数の外部データソース２１６から都市ロケーション情報を受信し得る。外部データソース２１６は、１つまたは複数のアクセスネットワークを形成し得る１つまたは複数の基準点（たとえば、ＷＬＡＮ ＡＰおよび／またはＢｌｕｅｔｏｏｔｈビーコン）を所有または運用する事業者、ユーザ、または組織に相当し得る。提供される都市ロケーション情報は、所有または運用される基準点に対する都市ロケーション情報に相当し得る。一例では、外部データソース２１６は、ＮＥＡＭ２１４によって認証され得る一意の識別情報を有し得、都市ロケーション情報を提供するための許可を受信するために、いくらかの最小レベルの信用を確立し得る。ＮＥＡＭ２１４は、外部データソースの識別および認証、受信された都市ロケーション情報の検証、ならびにＮＥＡＤ２１２の中の都市ロケーション情報の供給をサポートするように構成され得る。

[0048]動作において、ＵＥ１００は、ＵＥ１００のユーザからの緊急呼要求を検出した後（たとえば、ユーザが「９１１」に電話をかけたとき）、緊急呼要求を開始する。サービングコアネットワーク２０４は、ＵＥ１００からレガシーまたは国家緊急番号協会（ＮＥＮＡ）ｉ３対応緊急サービスネットワークおよびそのＰＳＡＰ（たとえば、２１０ａ、２１０ｂ）への緊急呼の確立をサポートするように構成される。サービングコアネットワーク２０４によってサポートされる機能は、緊急呼検出と、呼経路設定と、出動可能ロケーションの供給とを含み得る。一例では、有効な加入を有するＵＥ１００に対して、サービングコアネットワーク２０４はまた、ＰＳＡＰからのコールバックをサポートし得る。レガシーＥＳＮ／ＰＳＡＰ２１０ａは、米国電気通信工業会（ＴＩＡ：Telecommunications Industry Association）とアライアンスフォーテレコミュニケーションインダストリソリューション（ＡＴＩＳ：Alliance for Telecommunications Industry Solutions）との共同規格Ｊ−ＳＴＤ−０３６において規定されるように、サービングコアネットワーク２０４から（たとえば、ゲートウェイ２０８から）緊急呼と、関連する出動可能ロケーション情報とを受信するように構成される。ｉ３ ＥＳＩｎｅｔ／ＰＳＡＰ２１０ｂは、次世代手段（たとえば、ＮＥＮＡ ｉ３において規定されるような）を使用して、サービングコアネットワーク２０４から（たとえば、ゲートウェイ２０８から）緊急呼と出動可能ロケーション情報とを受信するように構成される。

[0049]図１および図２をさらに参照しながら図３Ａを参照すると、３ＧＰＰ ＬＴＥアクセスを用いてＵＢＰ情報を転送するためのロングタームエボリューション（ＬＴＥ）アーキテクチャ３００が示される。ＵＥ１００は、通信サービスを取得するために無線アクセスネットワーク（ＲＡＮ）の中のサービング発展型ノードＢ（ｅＮＢ）３０２と通信し得る。ＲＡＮは、図２におけるアクセスネットワーク２０２に相当し得、簡単のために図３Ａに示されない他のネットワークエンティティを含み得、発展型ユニバーサル地上波無線アクセスネットワーク（Ｅ−ＵＴＲＡＮ：Evolved Universal Terrestrial Radio Access Network）と呼ばれることがある。ｅＮＢ３０２は、ノードＢ、基地局、アクセスポイントなどと呼ばれることがある。ＵＥ１００は、近くのｅＮＢ（たとえば、ｅＮＢ３０２）からの信号を測定し得、ｅＮＢの識別情報、（たとえば、到来時間（ＴＯＡ：time of arrival）、観測到来時間差（ＯＴＤＯＡ：observed time difference of arrival）に対する）タイミング測定値、信号強度測定値、および／またはｅＮＢに対する（たとえば、拡張セルＩＤ（ＥＣＩＤ：Enhanced Cell ID）に対する）信号品質測定値を取得し得る。ＵＥ１００は同様に、または代わりに、ＳＰＳ衛星２９０に対する擬似距離を測定し得る。ｅＮＢ識別情報、ｅＮＢタイミング測定値、ｅＮＢ信号強度測定値、ｅＮＢ信号品質測定値、および／またはＳＰＳ擬似距離測定値は、ＵＥ１００に対するロケーション推定値を（たとえば、ＵＥ１００によって、またはＥ−ＳＭＬＣ３０８もしくはＥ−ＳＬＰ３３２などのロケーションサーバによって）導出するために使用され得る。ＵＥ１００は同様に、または代わりに、ＷＬＡＮ３９０の中の近くのＡＰからの信号を受信するとともに随意に測定し得、そのことは、その信号がＵＥ１００によって受信され得る、ＷＬＡＮ３９０の中の（ビーコンと呼ばれることもある）ＷｉＦｉまたはＢｌｕｅｔｏｏｔｈ（ＢＴ）ＡＰ用の識別情報（たとえば、ＭＡＣアドレス）を取得することと、場合によっては受信信号強度表示（ＲＳＳＩ：Received Signal Strength Indication）またはラウンドトリップ信号伝搬時間（ＲＴＴ：Round Trip signal propagation Time）などのこれらの受信信号の特性を測定することとを含み得る。ＷＬＡＮ ＡＰ識別情報および測定値は、− たとえば、ＵＥ１００によって、またはＥ−ＳＭＬＣ３０８もしくはＥ−ＳＬＰ３３２などのロケーションサーバによって、ＵＥ１００に対するロケーションを取得するために使用され得る。ｅＮＢおよび／またはＷＬＡＮ ＡＰ識別情報は、前に説明したようなＵＥ１００に対する都市ロケーションを得るために、（たとえば、Ｅ−ＳＭＬＣ３０８またはＥ−ＳＬＰ３３２などのロケーションサーバによって）ＮＥＡＤ２１２に照会するために使用され得る。１つのＷＬＡＮ３９０しか図３Ａに示されないが、ＵＥ１００にとって認識できるＷｉＦｉおよび／またはＢＴ ＡＰを含む他のＷＬＡＮ（図３Ａに示さず）があり得、したがって、本明細書におけるＷＬＡＮ３９０への参照は、場合によっては２つ以上のＷＬＡＮを参照するものと見なされるべきである。

[0050]ｅＮＢ３０２は、ＵＥ１００用のサービングＭＭＥ３０４と通信し得、サービングＭＭＥ３０４は、モビリティ管理、ゲートウェイ選択、認証、ベアラ管理などの様々な制御機能を実行し得る。ＭＭＥ３０４は、拡張サービングモバイルロケーションセンター（Ｅ−ＳＭＬＣ）３０８およびゲートウェイモバイルロケーションセンター（ＧＭＬＣ）３０６と通信し得る。Ｅ−ＳＭＬＣ３０８は、ＵＥ１００のためのＵＥベース、ＵＥ支援型、ネットワークベース、および／またはネットワーク支援型の測位方法をサポートし得、１つまたは複数のＭＭＥ（たとえば、ＭＭＥ３０４）をサポートし得る。Ｅ−ＳＭＬＣ３０８は、ロケーションサーバ（ＬＳ）、スタンドアロンＳＭＬＣ（ＳＡＳ）などと呼ばれることもある。Ｅ−ＳＭＬＣ３０８は、位置特定サービスをサポートするためにＮＥＡＤ２１２と通信し得る。Ｅ−ＳＭＬＣ３０８は、図２におけるロケーションサーバ２０６に相当し得る。ＧＭＬＣ３０６は、位置特定サービスをサポートするための様々な機能を実行し得、外部クライアント（たとえば、ＮＥＡＤ２１２）とインターフェースし得、加入者プライバシー、許可、認証、課金などのサービスを提供し得る。ロケーション検索機能（ＬＲＦ）３３０は、ＧＭＬＣ３０６と通信し得、ｉ３ ＥＳＩｎｅｔ３４２およびｉ３ ＰＳＡＰ３４４などの公共安全応答ポイント（ＰＳＡＰ）、ならびにレガシーＥＳネットワーク３４６およびレガシーＰＳＡＰ３４８などのレガシーシステムへの、経路ＩＰベースの緊急呼を経路設定または支援し得る。ＳＵＰＬ測位センター（ＳＰＣ：SUPL Positioning Center）３３４とＳＵＰＬロケーションセンター（ＳＬＣ：SUPL Location Center）３３６とを含む緊急ＳＵＰＬロケーションプラットフォーム（Ｅ−ＳＬＰ）３３２も、ＬＲＦ３３０とロケーション情報を通信するように構成される。Ｅ−ＳＬＰ３３２は、ロケーションサーバ２０６の一例であり、ＬＲＦ３３０は、サービングコアネットワーク２０４の中のゲートウェイ２０８の一例である。いくつかのネットワークでは、Ｅ−ＳＬＰ３３２が展開されることがあるがＥ−ＳＭＬＣ３０８が展開されないことがあり、またはその逆も同様である。

[0051]サービングゲートウェイ３１６は、データ経路設定および転送、モビリティアンカリング（mobility anchoring）などの、ＵＥのためのＩＰデータ転送に関係する様々な機能を実行し得る。パケットデータネットワーク（ＰＤＮ）ゲートウェイ３１８は、ＵＥのためのデータ接続性の保守、ＩＰアドレス割振りなどの様々な機能を実行し得る。ＩＰマルチメディアサブシステム（ＩＭＳ：IP Multimedia Subsystem）ネットワークは、ボイスオーバーＩＰ（ＶｏＩＰ）通話などのＩＭＳサービスをサポートするための様々なネットワークエンティティを含み得る。ＩＭＳネットワークは、ＬＲＦ３３０と、プロキシ呼セッション制御機能（Ｐ−ＣＳＣＦ：Proxy Call Session Control Function）３２０と、サービング呼セッション制御機能（Ｓ−ＣＳＣＦ：Serving Call Session Control Function）３２２と、緊急呼セッション制御機能（Ｅ−ＣＳＣＦ：Emergency Call Session Control Function）３２４と、ブレークアウトゲートウェイ制御機能３４０と、メディアゲートウェイ制御機能（ＭＧＣＦ：media gateway control function）３３８と、相互接続境界制御機能（ＩＢＣＦ：Interconnection Border Control Function）３２６と、経路設定決定機能（ＲＤＦ：Routing Determination Function）３２８とを含み得る。

[0052]動作において、ＬＴＥアーキテクチャ３００は、制御プレーン位置特定のためにＬＴＥインターフェースとＬＴＥプロトコルとを利用し得る。Ｅ−ＳＭＬＣ３０８によるＵＥ１００の測位のために、ＯＭＡ ＬＰＰｅプロトコルと組み合わせられた、３ＧＰＰ ＴＳ３６．３５５において規定されるＬＰＰプロトコルが、Ｕｕインターフェースを介してＵＥ１００とｅＮＢ３０２との間で使用され得る。ＬＰＰ／ＬＰＰｅメッセージは、３ＧＰＰ ＴＳ２３．２７１および３６．３０５に記載されるように、ＵＥ１００用のＭＭＥ３０４およびｅＮＢ３０２を経由してＵＥ１００とＥ−ＳＭＬＣ３０８との間で転送され得る。確度向上型位置特定情報（ＨＡＬＩ）をサポートするために、Ｅ−ＳＭＬＣ３０８は、認識できるＷＬＡＮ ＡＰの識別情報と、認識できるＷＬＡＮ ＡＰの信号測定値（たとえば、ＲＳＳＩ、ＲＴＴ）と、ＵＥ１００によってサポートされる場合は非補償気圧（ＵＢＰ）とを、（たとえば、ＬＰＰ／ＬＰＰｅ要求ロケーション情報メッセージをＵＥ１００へ送ることによって）要求するように構成され得、ＵＥ１００は、それらを（たとえば、ＬＰＰ／ＬＰＰｅ提供ロケーション情報メッセージをＥ−ＳＭＬＣ３０８へ送ることによって）提供するように構成され得る。この情報は、ＯＭＡ ＬＰＰｅバージョン１．０、バージョン１．１、およびバージョン２．０のプロトコルにおいてサポートされる。

[0053]代替実施形態では、Ｅ−ＳＭＬＣ３０８によるＵＥ１００の測位のために、（ｉ）ＬＰＰｅなしのＬＰＰプロトコル単独、または（ｉｉ）３ＧＰＰ ３６．３３１において規定されるＬＴＥ用の無線リソース制御（ＲＲＣ）プロトコルのいずれかが、Ｕｕインターフェースを介してＵＥ１００とサービングｅＮＢ３０２との間で使用され得る。ＬＰＰ（代替（ｉ））の場合、３ＧＰＰ ＴＳ２３．２７１および３６．３０５に記載されるように、ＬＰＰメッセージがＵＥ１００用のＭＭＥ３０４およびサービングｅＮＢ３０２を経由してＵＥ１００とＥ−ＳＭＬＣ３０８との間で転送され得る。ＲＲＣの場合（代替（ｉｉ））、３ＧＰＰ ＴＳ２３．２７１および３６．３０５に記載されるように、ＲＲＣメッセージがＵＥ１００とサービングｅＮＢ３０２との間で転送され得、ＬＴＥ測位プロトコルＡ（ＬＰＰａ）メッセージがＵＥ１００用のＭＭＥ３０４を経由してｅＮＢ３０２とＥ−ＳＭＬＣ３０８との間で転送され得る。確度向上型位置特定情報（ＨＡＬＩ）をサポートするために、Ｅ−ＳＭＬＣ３０８は、認識できるＷＬＡＮ ＡＰの識別情報と、認識できるＷＬＡＮ ＡＰの信号測定値（たとえば、ＲＳＳＩ、ＲＴＴ）と、ＵＥ１００によってサポートされる場合は非補償気圧（ＵＢＰ）とを、（たとえば、ＬＰＰ要求ロケーション情報メッセージをＵＥ１００へ送ることによって、またはＵＥ１００へのＲＲＣ要求メッセージをｅＮＢ３０２に送らせ得るＬＰＰａ要求メッセージをｅＮＢ３０２へ送ることによって）要求するように構成され得、ＵＥ１００は、それらを（たとえば、ＬＰＰ提供ロケーション情報メッセージをＥ−ＳＭＬＣ３０８へ送ることによって、またはＥ−ＳＭＬＣ３０８へのＬＰＰａ応答をｅＮＢ３０２に送らせるＲＲＣ応答をｅＮＢ３０２へ送ることによって）提供するように構成され得る。

[0054]ＭＭＥ３０４が３ＧＰＰ制御プレーン解決策を使用してＵＥ１００に対するロケーション情報をＥ−ＳＭＬＣ３０８に要求することを可能にするために、３ＧＰＰ ＴＳ２９．１７１において規定される位置特定サービス（ＬＣＳ：Location Services）アプリケーションプロトコル（ＬＣＳ−ＡＰ：LCS Application Protocol）が、ＳＬｓインターフェースを介してＭＭＥ３０４とＥ−ＳＭＬＣ３０８との間で使用され得る。ＨＡＬＩ交換をサポートするために、ＬＣＳ−ＡＰプロトコルは、Ｅ−ＳＭＬＣ３０８がＨＡＬＩをＭＭＥ３０４に戻すことを可能にし得る。ＧＭＬＣ３０６が３ＧＰＰ制御プレーン解決策を使用してＵＥ１００に対するロケーション情報を要求および取得することを可能にするために、３ＧＰＰ ＴＳ２９．１７２において規定される発展型パケットコア（ＥＰＣ）ＬＣＳプロトコル（ＥＬＰ）が、ＳＬｇインターフェースを介してＭＭＥ３０４とＧＭＬＣ３０６との間で使用され得る。ＨＡＬＩをサポートするために、ＥＬＰプロトコルは、ＭＭＥ３０４がＨＡＬＩをＧＭＬＣ３０６に戻すことを可能にし得る。ＵＥ１００がＰＳＡＰ（たとえば、ｉ３ ＰＳＡＰ３４４またはレガシーＰＳＡＰ３４８）へのＩＭＳ緊急呼を確立しつつあるかまたは確立している場合には、ＬＲＦ３３０が制御プレーン解決策を使用してＵＥ１００に対するロケーション情報をＧＭＬＣ３０６に要求することを可能にするために、Ｌ０インターフェースがＬＲＦ３３０とＧＭＬＣ３０６との間で使用され得る。ＨＡＬＩをサポートするために、Ｌ０インターフェースは、ＧＭＬＣ３０６がＨＡＬＩをＬＲＦ３３０に戻すことを可能にし得る。Ｌ０インターフェースのために規定される可能なプロトコルは、ＯＭＡによって規定されるモバイルロケーションプロトコル（ＭＬＰ）と、インターネットエンジニアリングタスクフォース（ＩＥＴＦ）によって規定されるハイパーテキスト転送プロトコル（ＨＴＴＰ）対応ロケーション配信（ＨＥＬＤ）プロトコルと、ＴＩＡ／ＡＮＳＩ共同規格Ｊ−ＳＴＤ−０３６において規定されるＥ２インターフェースプロトコルとを含み得る。ＵＥ１００がレガシーＰＳＡＰ３４８への緊急呼を確立する場合には、レガシーＥＳネットワーク３４６がＵＥ１００に対するロケーション情報をＬＲＦ３３０に要求することを可能にするために、Ｌｅ Ｅ２インターフェースが、ＬＲＦ３３０とレガシー緊急サービス（ＥＳ：emergency services）ネットワーク３４６の中のエンティティ（たとえば、自動ロケーション識別（ＡＬＩ：Automatic Location Identification）エンティティ）との間で使用され得る。Ｌｅ Ｅ２インターフェースは、ＴＩＡ／ＡＮＳＩ共同規格Ｊ−ＳＴＤ−０３６およびＮＥＮＡからのＮＥＮＡ−０５−００１規格において規定されるＥ２プロトコル、またはＯＭＡによって規定されるモバイルロケーションプロトコル（ＭＬＰ）のいずれかを使用し得る。ＵＥがｉ３ ＥＳＩｎｅｔ３４２への緊急呼を確立するかまたは確立している場合には、ＥＳＩｎｅｔ３４２（たとえば、緊急サービス経路設定プロキシ（ＥＳＲＰ：Emergency Services Routing Proxy）またはｉ３ ＰＳＡＰ３４４）の中の、またはそれに接続されたエンティティがＵＥ１００に対するロケーション情報をＬＲＦ３３０に要求することを可能にするために、Ｌｅ ｉ３インターフェースが、ＬＲＦ３３０と緊急サービスｉ３ネットワーク（ＥＳＩｎｅｔ）３４２との間で使用され得る。一例では、Ｌｅ ｉ３インターフェースは、ＨＥＬＤ、ＭＬＰ、またはＩＥＴＦセッション開始プロトコル（ＳＩＰ）ＳＵＢＳＣＲＩＢＥ／ＮＯＴＩＦＹプロトコルを使用し得る。

[0055]ＬＴＥアーキテクチャ３００は同様に、または代わりに、ＳＵＰＬユーザプレーン位置特定用のインターフェースとプロトコルとを利用し得る。ＯＭＡ ＳＵＰＬユーザプレーン解決策を使用してＵＥ１００の測位をサポートするために、ＯＭＡ ＴＳ ＯＭＡ−ＡＤ−ＳＵＰＬ−Ｖ２＿０において規定されるようなＬｕｐインターフェースが、ＵＥ１００（ＳＵＰＬ対応端末（ＳＥＴ：SUPL Enabled Terminal）と呼ばれる）とＥ−ＳＬＰ３３２との間で使用され得る。緊急呼に関連するロケーションの場合には、Ｅ−ＳＬＰ３３２が、ＵＥ１００のためのサービングコアネットワークの中で使用されるように構成され得る。Ｌｕｐインターフェースは、ＵＥ１００とＥ−ＳＬＰ３３２との間で、ＯＭＡ−ＴＳ−ＵＬＰ−Ｖ２＿０＿３において規定されるＵＬＰメッセージの交換を可能にする。Ｅ−ＳＬＰ３３２は、論理的または物理的に、ＳＬＣ３３６およびＳＰＣ３３４に分割され得る。ＳＬＣ３３６は、ＵＥ１００とのＳＵＰＬセッションを確立および制御するように構成される。ＳＰＣ３３４は、ＵＥ１００のロケーションを取得するように構成される。その時、ＵＬＰメッセージが制御およびサービス供給のために使用されるのか、それとも測位のために使用されるのかに応じて、任意のＵＬＰメッセージ用のエンドポイントは、それぞれ、ＳＬＣ３３６またはＳＰＣ３３４のいずれかである。ＵＥ１００（たとえば、ＬＴＥアクセスを有する）の場合には、測位のために使用されるＵＬＰメッセージは、通常、１つまたは複数のＬＰＰメッセージをカプセル化する。カプセル化された各ＬＰＰメッセージは、１つのＬＰＰｅメッセージをさらにカプセル化することができる。確度向上型位置特定をサポートするために、ＬＰＰ、ＬＰＰ／ＬＰＰｅ、またはＲＲＣ／ＬＰＰａを使用して上記で制御プレーン位置特定に対して説明されたのと同じ情報をＳＰＣ３３４が要求し、ＵＥ１００が戻すことを可能にするために、ＬＰＰ／ＬＰＰｅが使用され得る。

[0056]ＳＬＣ３３６がＳＰＣ３３４を使用してＵＥ１００の測位を誘発するとともにＵＥ１００に対するロケーション情報をＳＰＣ３３４から取得することを可能にするために、ＯＭＡ ＴＳ ＯＭＡ−ＴＳ−ＩＬＰ−Ｖ２＿０＿３において規定される内部ロケーションプロトコル（ＩＬＰ：Internal Location Protocol）が、Ｌｌｐインターフェースを介してＳＬＣ３３６とＳＰＣ３３４との間で使用され得る。確度向上型位置特定をサポートするために、ＩＬＰプロトコルは、ＳＰＣ３３４がＨＡＬＩをＳＬＣ３３６に戻すことを可能にし得る。ＵＥ１００がＰＳＡＰ（たとえば、レガシーＰＳＡＰ３４８またはｉ３ ＰＳＡＰ３４４）へのＩＭＳ緊急呼を確立するかまたは確立している場合には、ＬＲＦ３３０がＳＵＰＬ解決策を使用してＵＥ１００に対するロケーション情報をＥ−ＳＬＰ３３２に要求することを可能にするために、Ｌ０インターフェースが、ＬＲＦ３３０とＥ−ＳＬＰ３３２との間で使用され得る。確度向上型位置特定をサポートするために、Ｌ０インターフェースは、Ｅ−ＳＬＰ３３２が確度向上型位置特定情報をＬＲＦ３３０に戻すことを可能にする。Ｌ０インターフェースのために規定される可能なプロトコルは、ＭＬＰと、ＨＥＬＤと、ＴＩＡ／ＡＴＩＳ共同規格Ｊ−ＳＴＤ−０３６において規定されるＥ２インターフェースプロトコルとを含み得る。ユーザプレーンの中のＬｅ Ｅ２およびＬｅ ｉ３インターフェースは、上の制御プレーン位置特定に対して説明したものと同じであってよい。

[0057]図１〜図３Ａをさらに参照しながら図３Ｂを参照すると、ユニバーサル移動電気通信システム（ＵＭＴＳ）アクセスを用いてＵＢＰ情報を転送するためのＵＭＴＳアーキテクチャ３５０が示される。ＵＭＴＳアーキテクチャ３５０は、図３Ａに示し前に説明したような、図３Ｂにも存在する要素に加えて、ノードＢ３５２を有するキャリアネットワークと、無線ネットワークコントローラ（ＲＮＣ：radio network controller）３５６と、スタンドアロンＳＭＬＣ（ＳＡＳ）３５４と、モバイル交換センター（ＭＳＣ：mobile switching center）サーバ３５８と、ＧＭＬＣ３０６と、サービングＧＰＲＳサポートノード（ＳＧＳＮ：serving GPRS support node）３６０と、ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ：gateway GPRS support node）３６２とを含む。ＵＭＴＳアーキテクチャでは、ＳＡＳ３５４は、サービングコアネットワーク２０４の中のロケーションサーバ２０６の一例である。

[0058]回線交換（ＣＳ：Circuit Switched）アクセスを有する制御プレーン位置特定の場合には、３ＧＰＰ ＴＳ２５．３３１において規定されるＵＭＴＳ用のＲＲＣプロトコルが、ＲＮＣ３５６によるＵＥ１００の測位のためにＵｕインターフェースを介して使用され得る。確度向上型位置特定をサポートするために、ＲＮＣ３５６は、認識できるＷＬＡＮ ＡＰ（たとえば、ＷＬＡＮ３９０の中のＡＰ）の識別情報と、ＵＥ１００によってサポートされる場合は非補償気圧（ＵＢＰ）とを要求するように構成され、ＵＥ１００は、それらを提供するように構成される。ＲＮＣ３５６が３ＧＰＰ制御プレーン解決策を使用してＵＥ１００に対するロケーション情報をＳＡＳ３５４に要求することを可能にするために、３ＧＰＰ ＴＳ２５．４５３において規定されるような測位計算アプリケーションパート（ＰＣＡＰ）プロトコルが、Ｉｕｐｃインターフェースを介してＵＥ１００用のＲＮＣ３５６とＳＡＳ３５４との間で使用され得る。ＲＮＣ３５６およびＳＡＳ３５４は、異なる位置方法の使用と、ＵＥ１００とのＲＮＣ３５６相互作用とをＳＡＳ３５４が制御するＳＡＳ中心モード、または異なる位置方法の使用とＵＥ１００とのすべての相互作用とをＲＮＣ３５６が制御するＲＮＣ中心モードのいずれかで、ＰＣＡＰを使用して相互作用することができ、ＵＥ１００のための支援データを提供すること、またはＵＥ１００によってＲＮＣ３５６に提供されるロケーション関連測定値からロケーションを算出することだけのために、ＳＡＳ３５４を呼び出す。確度向上型位置特定をサポートするために、ＰＣＡＰプロトコルは、ＲＲＣを使用してＵＥ１００によって提供される追加のロケーション情報（たとえば、ＷＬＡＮ３９０および／またはＵＢＰの測定値）をＲＮＣ３５６が転送することを可能にし得る。ＭＳＣサーバ３５８が３ＧＰＰ制御プレーン解決策を使用してＵＥ１００に対するロケーション情報をＲＮＣ３５６に要求することを可能にするために、３ＧＰＰ ＴＳ２５．４１３において規定される無線アクセスネットワークアプリケーションパート（ＲＡＮＡＰ：Radio Access Network Application Part）プロトコルが、Ｉｕ−ｃｓインターフェースを介してＵＥ１００用のＭＳＣサーバ３５８とＲＮＣ３５６との間で使用され得る。ＧＭＬＣ３０６が３ＧＰＰ制御プレーン解決策を使用してＵＥ１００に対するロケーション情報を要求および取得することを可能にするために、３ＧＰＰ ＴＳ２９．００２において規定されるようなモバイルアプリケーションパート（ＭＡＰ：Mobile Application Part）プロトコルが、Ｌｇインターフェースを介してＵＥ１００用のＭＳＣサーバ３５８とＧＭＬＣ３０６との間で使用され得る。ＵＥ１００がＣＳ領域を使用してレガシーＰＳＡＰ３４８への緊急呼を確立している場合には、レガシーＥＳネットワーク３４６がＵＥ１００に対するロケーション情報をＧＭＬＣ３０６に要求することを可能にするために、Ｌｅ Ｅ２インターフェースが、ＧＭＬＣ３０６とレガシーＥＳネットワーク３４６の中のエンティティ（たとえば、ＡＬＩ）との間で使用され得る。Ｌｅ Ｅ２インターフェースは、ＴＩＡ／ＡＴＩＳ共同規格Ｊ−ＳＴＤ−０３６および（ＮＥＮＡからの）ＮＥＮＡ−０５−００１規格において規定される。

[0059]パケット交換（ＰＳ：Packet Switched）アクセスおよび制御プレーン位置特定の場合には、ＵＭＴＳアーキテクチャ３５０はまた、確度向上型位置特定をサポートするために、サービングＵＭＴＳネットワーク内での、およびサービングＵＭＴＳネットワークへの、インターフェースとプロトコルとをサポートする。ＰＳアクセスを有する制御プレーン位置特定の場合には、３ＧＰＰ ＴＳ２５．３３１において規定されるようなＲＲＣプロトコルが、ＲＮＣ３５６によるＵＥ１００の測位のためにＵｕインターフェースを介して使用され得る。ＲＮＣ３５６が３ＧＰＰ制御プレーン解決策を使用してＵＥ１００に対するロケーション情報をＳＡＳ３５４に要求することを可能にするために、３ＧＰＰ ＴＳ２５．４５３において規定されるようなＰＣＡＰプロトコルが、Ｉｕｐｃインターフェースを介してＵＥ１００用のＲＮＣ３５６とＳＡＳ３５４との間で使用され得る。ＳＧＳＮ３６０が３ＧＰＰ制御プレーン解決策を使用してＵＥ１００に対するロケーション情報をＲＮＣ３５６に要求することを可能にするために、３ＧＰＰ ＴＳ２５．４１３において規定されるＲＡＮＡＰプロトコルが、Ｉｕ−ｐｓインターフェースを介してＵＥ１００用のＳＧＳＮ３６０とＲＮＣ３５６との間で使用され得る。ＧＭＬＣ３０６が３ＧＰＰ制御プレーン解決策を使用してＵＥ１００に対するロケーション情報を要求および取得することを可能にするために、３ＧＰＰ ＴＳ２９．００２において規定されるＭＡＰプロトコルが、Ｌｇインターフェースを介してＵＥ１００用のＳＧＳＮ３６０とＧＭＬＣ３０６との間で使用され得る。ＧＭＬＣ３０６が３ＧＰＰ制御プレーン解決策を使用してＵＥ１００に対するロケーション情報を要求および取得することを可能にするために、３ＧＰＰ ＴＳ２９．１７２において規定されるＥＬＰプロトコルが、Ｌｇｄインターフェースを介してＵＥ１００用のＳＧＳＮ３６０とＧＭＬＣ３０６との間で使用され得る。Ｌｇｄインターフェースは、３ＧＰＰ発展型パケットシステム（ＥＰＳ）ベースのインターフェースとプロトコルとをサポートするＳＧＳＮに適用可能である。ＵＥ１００がＰＳアクセスを使用してＰＳＡＰ（たとえば、レガシーＰＳＡＰ３４８またはｉ３ ＰＳＡＰ３４４）への緊急呼を確立しつつあるかまたは確立している場合には、ＬＲＦ３３０が３ＧＰＰ制御プレーン解決策を使用してＵＥ１００に対するロケーション情報をＧＭＬＣ３０６に要求することを可能にするために、Ｌ０インターフェースが、ＬＲＦ３３０とＧＭＬＣ３０６との間で使用され得る。確度向上型位置特定をサポートするために、Ｌ０インターフェースは、ＧＭＬＣ３０６が確度向上型位置特定情報をＬＲＦ３３０に戻すことを可能にし得る。Ｌ０インターフェースのために規定される可能なプロトコルは、ＭＬＰと、ＨＥＬＤと、Ｊ−ＳＴＤ−０３６において規定されるＥ２インターフェースプロトコルとを含む。ＵＥ１００がＰＳアクセスを使用してレガシーＰＳＡＰ３４８への緊急呼を確立している場合には、レガシーＥＳネットワーク３４６がＵＥ１００に対するロケーション情報をＬＲＦ３３０に要求することを可能にするために、Ｌｅ Ｅ２インターフェースが、ＬＲＦ３３０とレガシー緊急サービスネットワークの中のレガシーＥＳネットワーク３４６との間で使用され得る。Ｌｅ Ｅ２インターフェースは、ＴＩＡ／ＡＴＩＳ共同規格Ｊ−ＳＴＤ−０３６およびＮＥＮＡ−０５−００１において規定されるＥ２プロトコル、またはＯＭＡ ＭＬＰプロトコルを使用し得る。ＵＥ１００がＰＳアクセスを使用してＥＳＩｎｅｔ３４２への緊急呼を確立しつつあるかまたは確立している場合には、ＥＳＩｎｅｔの中の、またはＥＳＩｎｅｔに接続されたエンティティ（たとえば、ＥＳＲＰまたはｉ３ ＰＳＡＰ３４４）がＵＥ１００に対するロケーション情報をＬＲＦ３３０に要求することを可能にするために、Ｌｅ ｉ３インターフェースが、ＬＲＦ３３０と緊急サービスｉ３ネットワーク（ＥＳＩｎｅｔ）３４２との間で使用され得る。Ｌｅ ｉ３インターフェースは、ＨＥＬＤ、ＭＬＰ、またはＳＩＰ ＳＵＢＳＣＲＩＢＥ／ＮＯＴＩＦＹを使用し得る。

[0060]ユーザプレーン位置特定の場合には、ＵＭＴＳアーキテクチャ３５０は同様に、または代わりに、確度向上型位置特定をサポートするために、ＵＭＴＳ ＰＳアクセス内のインターフェースとプロトコルとをサポートする。ＯＭＡ ＳＵＰＬユーザプレーン解決策を使用してＵＥ１００の測位をサポートするために、ＯＭＡ仕様ＯＭＡ−ＡＤ−ＳＵＰＬ−Ｖ２＿０において規定されるようなＬｕｐインターフェースが、ＵＥ１００とＥ−ＳＬＰ３３２との間で使用され得る。Ｌｕｐインターフェースは、ＯＭＡ ＴＳ ＯＭＡ−ＴＳ−ＵＬＰ−Ｖ２＿０＿３において規定されるＳＵＰＬ ＵＬＰメッセージの、測位されているＵＥ１００とＥ−ＳＬＰ３３２との間での交換を可能にする。Ｅ−ＳＬＰ３３２は、ＳＬＣ３３６およびＳＰＣ３３４に分割され、ＵＥ１００とＥ−ＳＬＰ３３２との間のＳＵＰＬセッションを確立および制御するためにＳＬＣ３３６が使用され、ＵＥ１００のロケーションを取得するためにＳＰＣ３３４が使用される。ＵＬＰメッセージが制御およびサービス供給のために使用されるのか（エンドポイントがＳＬＣ３３６であるとき）、それとも測位のために使用されるのか（エンドポイントがＳＰＣ３３４であるとき）に応じて、任意のＳＵＰＬ ＵＬＰメッセージ用のエンドポイントは、ＳＬＣ３３６またはＳＰＣ３３４のいずれかである。ＵＭＴＳアクセスを有するＵＥ１００の場合には、測位のために使用されるＵＬＰメッセージは、３ＧＰＰ ＴＳ２５．３３１において規定されるＲＲＣプロトコルのための１つもしくは複数のＬＰＰメッセージまたは１つもしくは複数のＲＲＣメッセージをカプセル化し得る。ＬＰＰメッセージの場合には、カプセル化された各ＬＰＰメッセージは、１つのＬＰＰｅメッセージをさらにカプセル化することができる。確度向上型位置特定をサポートするために、制御プレーン位置特定に対して説明されたのと同じ情報（たとえば、ＷＬＡＮ３９０および／またはＵＢＰに対する測定値）をＳＰＣ３３４が要求し、ＵＥ１００が戻すことを可能にするために、ＬＰＰ、ＬＰＰ／ＬＰＰｅ、またはＲＲＣが使用され得る。ＳＬＣ３３６がＳＰＣ３３４を使用してＵＥ１００の測位を誘発するとともにＵＥ１００に対するロケーション情報をＳＰＣ３３４から取得することを可能にするために、ＯＭＡ ＴＳ ＯＭＡ−ＴＳ−ＩＬＰ−Ｖ２＿０＿３において規定されるようなＩＬＰプロトコルが、Ｌｌｐインターフェースを介してＳＬＣ３３６とＳＰＣ３３４との間で使用され得る。ＵＥ１００がＰＳＡＰ（たとえば、レガシーＰＳＡＰ３４８またはｉ３ ＰＳＡＰ３４４）へのＩＭＳ緊急呼を確立しつつあるかまたは確立している場合には、ＬＲＦ３３０がＵＥ１００に対するロケーション情報をＥ−ＳＬＰ３３２に要求することを可能にするために、Ｌ０インターフェースが、ＬＲＦ３３０とＥ−ＳＬＰ３３２との間で使用され得る。Ｌ０インターフェースのために規定される可能なプロトコルは、ＭＬＰと、ＨＥＬＤと、Ｊ−ＳＴＤ−０３６において規定されるＥ２インターフェースプロトコルとを含む。Ｌｅ Ｅ２およびＬｅ ｉ３インターフェースにとっての影響は、前に説明したＵＭＴＳ制御プレーン位置特定に対する影響と同じである。

[0061]図１〜図３Ｂをさらに参照しながら図４を参照すると、都市ロケーション情報を用いた例示的なＵＢＰ転送手順のメッセージフロー図４００が示される。メッセージフローの中のノードは、ＵＥ４０２と、サービングネットワーク４０４と、ＰＳＡＰ４０６とを含む。ＵＥ４０２は、図１〜図３ＢにおけるＵＥ１００に相当し得る。サービングネットワーク４０４は、図２におけるサービングコアネットワーク２０４ならびに／または図３Ａおよび３Ｂに示すようなＬＴＥおよびＵＭＴＳアーキテクチャ３００、３５０の１つもしくは複数の要素を含み得る。ＰＳＡＰ４０６は、レガシーＰＳＡＰ３４８またはｉ３ ＰＳＡＰ３４４に相当し得る。たとえば、非補償気圧（ＵＢＰ）は、サービングネットワーク４０４の中のロケーションサーバ（たとえば、ロケーションサーバ２０６、Ｅ−ＳＭＬＣ３０８、Ｅ−ＳＬＰ３３２、またはＳＡＳ３５４）およびサービングネットワーク４０４の中のゲートウェイ（たとえば、ゲートウェイ２０８、ＧＭＬＣ３０６、またはＬＲＦ３３０）を経由して、ＵＥ４０２からＰＳＡＰ４０６（たとえば、ｉ３ ＰＳＡＰ３４４、レガシーＰＳＡＰ３４８）に転送され得る。ＵＥ４０２における圧力センサー１３０は、ＵＢＰを測定するように構成され得、プロセッサ１１１およびワイヤレストランシーバ１２１は、第１のメッセージ４０８を介してＵＢＰをサービングコアネットワーク４０４に提供するように構成され得る。一例では、第１のメッセージ４０８は、ＬＰＰｅを使用してＵＥ４０２によってロケーションサーバ（たとえば、Ｅ−ＳＭＬＣ３０８、Ｅ−ＳＬＰ３３２、またはＳＡＳ３５４）に提供され得、ここで、ＬＰＰｅは、ＬＰＰと組み合わせて（すなわち、ＬＰＰ／ＬＰＰｅとして）使用され得る。ＬＰＰｅにおいてサポートされるＵＢＰは、一実施形態では、範囲を３０，０００〜１１５，０００Ｐａとしてパスカル（Ｐａ）という単位であってよい。ＵＢＰに対して他の測定単位（たとえば、ミリバール）および範囲も使用されてよい。概して、ＵＢＰ範囲は、ＵＥ４０２とって見込みのある任意の高度において、可能な屋内または屋外の大気圧を表すのに十分であるべきである。別の例では、第１のメッセージ４０８は、（ｉ）ＬＰＰ、（ｉｉ）（たとえば、ＵＥ４０２とｅＮＢ３０２のようなサービングｅＮＢとの間の）ＬＴＥ用のＲＲＣ＋（たとえば、サービングｅＮＢとＥ−ＳＭＬＣ３０８との間の）ＬＰＰａ、または（ｉｉｉ）（たとえば、ＵＥ４０２とＲＮＣ３５６のようなサービングＲＮＣとの間の）ＵＭＴＳ用のＲＲＣ＋（たとえば、サービングＲＮＣとＳＡＳ３５４との間の）ＰＣＡＰを使用して、ＵＥ４０２によってロケーションサーバ（たとえば、Ｅ−ＳＭＬＣ３０８、Ｅ−ＳＬＰ３３２、またはＳＡＳ３５４）に提供され得る。

[0062]ステージ４１０において、サービングネットワーク４０４（たとえば、Ｅ−ＳＭＬＣ３０８、Ｅ−ＳＬＰ３３２、ＳＰＣ３３４、またはＳＡＳ３５４などの、サービングネットワーク４０４の中のロケーションサーバ２０６）は、第１のメッセージ４０８を介して受信されたＵＢＰをＵＥ４０２に対する都市ロケーション情報と組み合わせるように構成される。都市ロケーション情報は、前に説明したようなＮＥＡＤ２１２などのＮＥＡＤによって提供され得る。既存のインターネット規格（たとえば、ＩＥＴＦ ＲＦＣ６８４８）は、プレゼンス情報データフォーマットロケーションオブジェクト（ＰＩＤＦ−ＬＯ）ドキュメントとともにまたは動的ホスト構成プロトコル（ＤＨＣＰ）によって使用されるような、都市ロケーション用の拡張タイプを定義し、インターネット番号割当て機関（ＩＡＮＡ：Internet Assigned Numbers Authority）に登録するための仕組みを提供する。数値（たとえば、パスカルまたはミリバールという単位での１０進数または２進数）としてＵＢＰを運搬するために、この仕組みに基づく都市アドレスタイプが登録され得る。ＵＥ４０２に対する出動可能都市ロケーションが、ＮＥＡＤ２１２から受信されたＵＥ４０２に対する１つまたは複数の都市ロケーションを使用してロケーションサーバ（たとえば、ロケーションサーバ２０６、Ｅ−ＳＭＬＣ３０８、ＳＡＳ３５４、ＳＰＣ３３４、またはＥ−ＳＬＰ３３２）において決定される場合（たとえば、図２に関連して前に説明したように）、およびＵＢＰもロケーションサーバにおいてＵＥ４０２から受信される場合、ステージ４１０において、サービングネットワーク４０４の中のロケーションサーバは、ＵＢＰを運搬するために、ＩＡＮＡに登録された都市アドレスタイプを使用してＵＢＰを都市ロケーションの中に組み合わせることができる。組み合わせられた出動可能都市ロケーションとＵＢＰパラメータ４１２とを含むメッセージは、中間エンティティ（たとえば、ＭＭＥ３０４、ＧＭＬＣ３０６、ＳＬＣ３３６、ＲＮＣ３５６、ＭＳＣサーバ３５８、ＳＧＳＮ３６０のうちの１つまたは複数）を通じてゲートウェイ〜ＰＳＡＰ（たとえば、ＧＭＬＣ３０６またはＬＲＦ３３０のいずれか）まで透過的に転送および処理され得る。一例では、組み合わせられた出動可能都市ロケーションおよびＵＢＰパラメータ４１２は、ＩＥＴＦ ＨＥＬＤプロトコル、ＯＭＡ ＭＬＰ、またはＪ−ＳＴＤ−０３６ Ｅ２プロトコルを使用してＰＳＡＰ４０６に転送され、ＰＳＡＰ４０６が出動可能都市ロケーションとＵＢＰ測定値の両方をＰＳＡＰ４０６の事業者（図４に示さず）に提示する。別の例では、サービングネットワーク４０４の中のゲートウェイ（たとえば、ＧＭＬＣ３０６またはＬＲＦ３３０）が、受信された出動可能都市ロケーションおよびＵＢＰパラメータ４１２からＵＢＰを抽出してよく、ＵＢＰをＰＳＡＰ４０６に（たとえば、ＨＥＬＤ、ＭＬＰ、またはＥ２プロトコルにとって新たなパラメータを使用して）別個に転送してよい。出動可能都市ロケーションがサービングネットワーク４０４の中のロケーションサーバによってＮＥＡＤ２１２から取得されない場合には、サービングネットワーク４０４の中のロケーションサーバは、空き出動可能都市ロケーションパラメータ４１２を構築するように構成され得、空き出動可能都市ロケーションパラメータ４１２はＵＢＰのみを含む。この空き出動可能都市ロケーション（たとえば、単にＵＢＰ）は、前に説明したような組み合わせられた出動可能都市ロケーションおよびＵＢＰパラメータ４１２用と同様の方法で運搬され得る。

[0063]フロー図４００は、データフォーマットと、インターフェースと、プロトコルとを発展させることに基づいて修正され得る。たとえば、上記で説明したように特にＵＢＰを運ぶために、新たな都市アドレス（ＣＡ）タイプがＩＡＮＡに登録されてよい。代替として、温度、湿度などのＵＥのロケーションに対する環境データならびにＵＢＰを運ぶために、新たな都市アドレスタイプがＩＡＮＡに登録されてよい。再び代替として、都市ロケーション内の他の所に適合せず、その内容がＩＡＮＡによって制約または規定されない種々の情報を運搬するために、新たな種々の都市アドレスタイプがＩＡＮＡに登録されてよい。この新たな種々の都市アドレスタイプは、文字列を備えることができ、（たとえば、ｎｎｎｎｎｎが１０進数で表現されたＵＢＰの値を表す一連の１０進数字である場合）ＵＢＰを運搬するための「ＵｎｃｏｍｐｅｎｓａｔｅｄＢａｒｏＰｒｅｓｓｕｒｅ＝ｎｎｎｎｎｎＰａ」などの特定の文字列を運搬するために使用され得る。すでにＩＡＮＡに登録されている既存の都市アドレスタイプも、ＵＢＰを運搬するために使用され得る。たとえば、ＵＢＰを運搬するために使用され得るＰＩＤＦ−ＬＯ用の２つの既存の都市アドレスタイプがある。詳細には、都市アドレスタイプ２２（ＬＯＣと呼ばれる）が、追加の（すなわち、指定されていない）ロケーション情報を含み、都市アドレスタイプ３２（ＡＤＤＣＯＤＥと呼ばれる）が、追加の数字コードを許容する。タイプ２２およびタイプ３２の都市アドレスタイプは、（たとえば、ｎｎｎｎｎｎが１０進数でＵＢＰ値を表す一連の１０進数字である場合）ＵＢＰを運搬するための「ＵｎｃｏｍｐｅｎｓａｔｅｄＢａｒｏＰｒｅｓｓｕｒｅ＝ｎｎｎｎｎｎＰａ」などの文字列を含むように拡張され得る。

[0064]図１〜図３Ｂをさらに参照しながら図５を参照すると、メッセージコールフロー図５００は、地理的ロケーション情報を用いたＵＢＰ転送手順の別の例を示す。メッセージコールフローの中のノードは、ＵＥ５０２と、ロケーションサーバ５０４と、ゲートウェイ５０６と、ＰＳＡＰ５０８とを含む。ＵＥ５０２は、図１〜図３ＢにおけるＵＥ１００に相当し得る。ロケーションサーバ５０４およびゲートウェイ５０６は、図２、図３Ａ、および図３Ｂに示すような通信システム２００ならびに／またはＬＴＥおよびＵＭＴＳアーキテクチャ３００、３５０の１つもしくは複数の要素に相当し得る。たとえば、ロケーションサーバ５０４は、ロケーションサーバ２０６、Ｅ−ＳＭＬＣ３０８、Ｅ−ＳＬＰ３３２、ＳＰＣ３３４、またはＳＡＳ３５４に相当し得る。ゲートウェイ５０６は、ゲートウェイ２０８、ＬＲＦ３３０、またはＧＭＬＣ３０６に相当し得る。ＰＳＡＰ５０８は、レガシーＰＳＡＰ３４８またはｉ３ ＰＳＡＰ３４４に相当し得る。たとえば、非補償気圧（ＵＢＰ）は、ロケーションサーバ５０４（たとえば、ロケーションサーバ２０６、Ｅ−ＳＭＬＣ３０８、ＳＡＳ３５４、またはＥ−ＳＬＰ３３２）およびゲートウェイ５０６（たとえば、ゲートウェイ２０８、ＧＭＬＣ３０６、またはＬＲＦ３３０）を経由して、ＵＥ５０２からＰＳＡＰ５０８（たとえば、ｉ３ ＰＳＡＰ３４４、レガシーＰＳＡＰ３４８）に転送され得る。ＵＥ５０２における圧力センサー１３０は、ＵＢＰを測定するように構成され得、プロセッサ１１１およびワイヤレストランシーバ１２１は、第１のメッセージ５１０を介してＵＢＰをロケーションサーバ５０４に提供するように構成され得る。一例では、第１のメッセージ５１０は、ＬＰＰｅを使用してＵＥ５０２によってロケーションサーバ５０４（たとえば、Ｅ−ＳＭＬＣ３０８、ＳＡＳ３５４、またはＥ−ＳＬＰ３３２）に提供され、ここで、ＬＰＰｅは、ＬＰＰと組み合わせて（たとえば、ＬＰＰ／ＬＰＰｅとして）使用され得る。別の例では、第１のメッセージ５１０は、（ｉ）ＬＰＰ、（ｉｉ）（たとえば、ＵＥ５０２とｅＮＢ３０２のようなサービングｅＮＢとの間の）ＬＴＥ用のＲＲＣ＋（たとえば、サービングｅＮＢとＥ−ＳＭＬＣ３０８との間の）ＬＰＰａ、または（ｉｉｉ）（たとえば、ＵＥ５０２とＲＮＣ３５６のようなサービングＲＮＣとの間の）ＵＭＴＳ用のＲＲＣ＋（たとえば、サービングＲＮＣとＳＡＳ３５４との間の）ＰＣＡＰを使用して、ＵＥ５０２によってロケーションサーバ５０４（たとえば、Ｅ−ＳＭＬＣ３０８、Ｅ−ＳＬＰ３３２、またはＳＡＳ３５４）に提供され得る。ＵＥ５０２の地理的ロケーションは、ロケーションサーバ５０４によって決定されてよく、またはロケーションサーバ５０４においてＵＥ５０２から受信されてもよい。ステージ５１２において、ロケーションサーバ５０４は、地理的ロケーションを（たとえば、第１のメッセージ５１０の中でＵＥ５０２から受信されるような）ＵＢＰと組み合わせるように構成される。組み合わせられた地理的ロケーションおよびＵＢＰパラメータ５１４は、次いで、ゲートウェイ５０６（たとえば、ＧＭＬＣ３０６またはＬＲＦ３３０）に転送され得る。組み合わせられた地理的ロケーションおよびＵＢＰパラメータの転送は、サービングネットワークの中の中間エンティティにとって透過的であり得る（たとえば、ＭＭＥ３０４、ＧＭＬＣ３０６、ＳＬＣ３３６、ＲＮＣ３５６、ＭＳＣサーバ３５８、ＳＧＳＮ３６０のうちの１つまたは複数にとって透過的であり得る）。組み合わせられた地理的ロケーションおよびＵＢＰパラメータ５１４は、図３Ａおよび図３Ｂに関連して前に説明された３ＧＰＰ制御プレーン位置特定解決策またはＳＵＰＬユーザプレーン位置特定解決策のための既存のインターフェースとプロトコルとを使用して、ロケーションサーバ５０４からゲートウェイ５０６に透過的にさらに転送され得る。これらのインターフェースは、３ＧＰＰ ＳＬｓ、ＳＬｇ、Ｌ０、Ｌｇ、Ｌｇｄ、Ｉｕｐｃ、Ｉｕ−ｃｓ、およびＩｕ−ｐｓインターフェースのうちの１つまたは複数を含み得る）。一例では、地理的ロケーションがロケーションサーバ５０４によってＵＥ５０２から受信されないか、またはロケーションサーバ５０４によって決定されない場合、ゲートウェイ５０６（たとえば、ＧＭＬＣ３０６またはＬＲＦ３３０）〜ＰＳＡＰ５０８までＵＢＰを転送するために、任意の空き（ヌル）地理的ロケーションがロケーションサーバ５０４によって作成されてよい。ステージ５１６において、ゲートウェイ５０６（たとえば、ＧＭＬＣ３０６またはＬＲＦ３３０）は、組み合わせられた地理的ロケーションとＵＢＰパラメータ５１４とを構文解析し、地理的ロケーションから（または、地理的ロケーションが空である場合はヌル地理的ロケーションから）ＵＢＰを除去するように構成される。除去されたＵＢＰは、別個のパラメータとしてＰＳＡＰ５０８へ送られてよい。たとえば、ゲートウェイ５０６は、除去されたＵＢＰをメッセージ５１８の中のパラメータとしてＰＳＡＰ５０８へ送ってよい。

[0065]通常、地理的ロケーションは、３ＧＰＰプロトコルでは３ＧＰＰ ＴＳ２３．０３２において規定されるオクテット列によって表され得る。ＵＢＰを３ＧＰＰ地理的ロケーションの中に組み合わせるために、ロケーションサーバ５０４は、ＵＢＰを運搬するための小さい定数個の（たとえば、２つまたは３つの）追加オクテットを地理的ロケーションオクテット列に連結するように構成され得る。一例では、ＵＢＰは、地理的ロケーション列に加えられる３つの追加オクテットを使用して、Ｐａの単位でのバイナリ値として符号化され得る。追加オクテットは、地理的ロケーション列の末尾において連結されてよく、組み合わせられた地理的ロケーション列およびＵＢＰの長さが、（たとえば、地理的ロケーション列の中の第１のオクテットによって示されるような）地理的ロケーションのタイプに対して規定された長さを、ＵＢＰを符号化するために使用されたオクテットとしての既知の固定数だけ上回ると決定することによって、（たとえば、ゲートウェイ５０６によって）検出され得る。ゲートウェイ５０６は、次いで、組み合わせられた地理的ロケーションおよびＵＢＰパラメータから追加ＵＢＰオクテットを構文解析するように構成され得る。

[0066]一例では、ＵＢＰは、ロケーションサーバ５０４によって地理的ロケーションの高度座標の中に含められ得る。３ＧＰＰネットワークの場合、（たとえば、ＴＳ２３．０３２で標準化されるような）高度を含む２つのタイプの地理的ロケーション形状がある。２つの地理的ロケーション形状は、高度を有する楕円点と、高度および不確実楕円を有する楕円点とを含む。両方の地理的ロケーション形状に対して、高度座標は、２Ｐａの精度までＰａの単位でＵＢＰを含めることをサポートすることになる２オクテットである。一実施形態では、ＵＢＰは、ステージ５１２において、知られているアルゴリズムを使用してロケーションサーバ５０４（たとえば、Ｅ−ＳＭＬＣ３０８、ＳＡＳ３５４、またはＥ−ＳＬＰ３３２）によって、いくらかの不変の基準海面気圧（いかなる現在の海面気圧にも関係しない）に対する等価高度（または、深度）に変換され得、ステージ５１６において、ゲートウェイ５０６（たとえば、ＧＭＬＣ３０６またはＬＲＦ３３０）によって元通りにＵＢＰに変換され得る。サービングネットワークは、地理的ロケーションの高度座標がＵＢＰ情報を表すのか、それとも実際の高度を現すのかを決定するように構成され得る。一例では、ネットワークは、すべてのＵＥに対して１つのタイプの高度座標、− たとえば、高度符号化ＵＢＰまたは実際の高度のいずれかのみをサポートしてよい。別の例では、ＵＢＰを運ぶ高度座標を実際の高度を表す高度座標から区別するために、ネットワークにおいて表記法が採用され得る。そのような表記法は、サービングネットワークが、実際の高度と、ＵＢＰを符号化する高度の両方をサポートすることを可能にすることになる。一例として、限定ではなく、ＵＢＰを符号化する高度値から実際の高度を区別するための１つの可能な表記法は、高度不確実楕円を有する楕円点の場合に７ビットの不確実高度を使用することを含み得る（たとえば、ＵＢＰを示すために、不確実の値を、通常は誤差がないことを意味する０に設定する）。高度を有する楕円点と高度および不確実楕円を有する楕円点の両方に適用可能な別の例示的な表記法は、普通はＵＢＰを符号化するために発生しない高度値の範囲を予約することを含む。たとえば、範囲−２＊＊１４〜−２＊＊１５メートルの中の深度は、ＵＢＰを符号化するために再割り当てされてよく、そのことは、事実上、ＵＢＰを符号化するために１４ビットを割り当てることを意味し得、約８Ｐａの精度を可能にし得る。一実施形態では、モバイルロケーションプロトコル（ＭＬＰ）データ構造が、ＵＢＰパラメータを規定するために使用され得る。たとえば、ＭＬＰでは、地理的ロケーション形状が、ＸＭＬを使用する文字列として規定され得る。既存または新規のＸＭＬタグが、ＵＢＰパラメータを規定するために使用され得る。

[0067]一実施形態では、ロケーションサーバ（たとえば、Ｅ−ＳＭＬＣ３０８、Ｅ−ＳＬＰ３３２、またはＳＡＳ３５４）は、ＮＥＡＤ２１２から受信された、ＵＥに対する１つまたは複数の都市ロケーションを使用して、ＵＥ（たとえば、ＵＥ１００）に対する出動可能都市ロケーションを決定し得る（たとえば、図２に関連して前に説明したように）。ロケーションサーバは、次いで、決定された出動可能都市ロケーションをＰＩＤＦ−ＬＯロケーションオブジェクト（たとえば、ＲＦＣ５１３９および６８４８において規定されるような）内に運搬し得、ＰＩＤＦ−ＬＯロケーションオブジェクトは、ゲートウェイ（たとえば、ＧＭＬＣ３０６またはＬＲＦ３３０）に転送され得、次いで、変更なしにＰＳＡＰに（たとえば、ＨＥＬＤ、ＭＬＰ、またはＪ−ＳＴＤ−０３６におけるＥ２プロトコルを使用してｉ３ ＰＳＡＰ３４４またはレガシーＰＳＡＰ３４８に）転送され得るか、または（たとえば、ＨＥＬＤ、ＭＬＰ、またはＪ−ＳＴＤ−０３６ Ｅ２プロトコルによってサポートされるフリーフォーマットの都市ロケーションを使用して）ＰＳＡＰに転送され得る出動可能都市ロケーション部を抽出するために使用され得るかのいずれかである。ＰＩＤＦ−ＬＯロケーションオブジェクトは、都市ロケーション、地理的ロケーション、または都市ロケーション＋地理的ロケーション、ならびに日付／タイムスタンプおよびプライバシー要件などのいくつかの他のロケーション関連パラメータを含み得る。ＰＩＤＦ−ＬＯの地理的ロケーションコンポーネントは、サービングネットワークの中でのロケーションサーバからゲートウェイへの地理的ロケーション転送として使用される必要がなくてよく、３ＧＰＰ制御プレーン位置特定解決策およびＯＭＡ ＳＵＰＬユーザプレーン位置特定解決策にとって適用可能な、３ＧＰＰおよびＯＭＡプロトコルにおける他の既存のパラメータによってサポートされ得る。ロケーションサーバ（たとえば、Ｅ−ＳＭＬＣ３０８、Ｅ−ＳＬＰ３３２、またはＳＡＳ３５４）は、ＵＢＰを含めることをサポートするために、ＰＩＤＦ−ＬＯの中の新規または既存のパラメータ、新規または既存のフィールド、あるいは他の新規または既存の値を使用して、（たとえば、ＵＥ１００またはＵＥ５０２から受信された）ＵＢＰをＰＩＤＦ−ＬＯの中に組み合わせ得る。ＵＢＰを含むＰＩＤＦ−ＬＯは、次いで、ゲートウェイ（たとえば、ゲートウェイ２０８、ＬＲＦ３３０、またはＧＭＬＣ３０６）を経由してＰＳＡＰに転送され得、またはＵＢＰがＰＩＤＦ−ＬＯから抽出されＰＳＡＰに別個に転送される場合、ゲートウェイまで転送され得る。

[0068]図１〜図５をさらに参照しながら図６を参照すると、ＵＢＰと都市ロケーション情報とをＰＳＡＰに提供するためのプロセス６００は、図示のステージを含む。ただし、プロセス６００は例にすぎず、限定的でない。プロセス６００は、たとえば、ステージを追加させ、削除させ、並べ替えさせ、組み合わせ、および／または並行して実行させることによって改変されてよい。たとえば、ＵＢＰ情報は、都市ロケーション情報を取得する前にサービングネットワークによって取得されてよい。ＵＢＰおよび都市ロケーション情報は、１つまたは複数のメッセージの中でＰＳＡＰに提供され得る。一実施形態では、プロセス６００は、図９に示すような１つまたは複数のコンピュータシステム上で実行され得る。

[0069]ステージ６０２において、サービングコアネットワーク２０４は、ユーザ機器（ＵＥ）１００に対する出動可能都市ロケーションを取得するように構成される。サービングコアネットワーク２０４は、ＵＥ１００に対する（たとえば、１つまたは複数の都市ロケーションを備える）都市ロケーション情報をＮＥＡＤ２１２から取得し、この都市ロケーション情報から出動可能都市ロケーションを取得するための手段として、Ｅ−ＳＭＬＣ３０８、Ｅ−ＳＬＰ３３２、および／またはＳＡＳ３５４などのロケーションサーバ２０６を含み得る（たとえば、図２に関連して前に説明したように）。都市ロケーション情報は、（ｉ）ＵＥ１００にとって認識できる１つまたは複数のＷｉＦｉおよび／またはＢＴ ＡＰに関連する１つまたは複数のメディアアクセス制御（ＭＡＣ）アドレスおよび／または他のアドレス、（ｉｉ）ＵＥ１００にとって認識できる基地局ＩＤ（たとえば、ｅＮＢまたはホームｅＮＢセル識別情報（ＩＤ））、あるいは（ｉｉｉ）ＵＥ１００の現在のロケーションなどの他の地理情報に基づいて、ＮＥＡＤ２１２によって取得され得る。ＮＥＡＤ２１２へのアクセスは、Ｎｑインターフェースによってサポートされ得る。Ｎｑインターフェースは、現在のロケーションなどのロケーション情報に関連する都市ロケーション情報、または（緊急呼を発信した）ＵＥ１００にとって認識できる１つまたは複数の基準点を得るための、サービングコアネットワーク２０４による照会をサポートし得る。

[0070]ステージ６０４において、サービングコアネットワーク２０４は、ＵＥ１００から非補償気圧（ＵＢＰ）を取得するように構成される。ＵＥ１００における圧力センサー１３０は、気圧を検出するための手段であり、プロセッサ１１１およびワイヤレストランシーバ１２１は、ＵＢＰをサービングコアネットワーク２０４に提供するための手段である。一例では、ＵＢＰ情報は、ＵＥ１００と（ｉ）Ｅ−ＳＬＰ３３２または（ｉｉ）Ｅ−ＳＭＬＣ３０８（たとえば、Ｅ−ＳＭＬＣ３０８の場合にはＭＭＥ３０４およびｅＮＢ３０２を経由して）のいずれかとの間で（たとえば、ＬＰＰ／ＬＰＰｅ組合せプロトコルを使用して）転送されるＬＰＰｅメッセージの中に含まれ得る。別の例では、ＵＢＰ情報は、（ｉ）ＬＰＰ（たとえば、ＬＰＰメッセージが、ＵＥ１００とＥ−ＳＬＰ３３２またはＥ−ＳＭＬＣ３０８のいずれかとの間で、Ｅ−ＳＭＬＣ３０８の場合にはＭＭＥ３０４およびｅＮＢ３０２を経由して転送される）、（ｉｉ）ＬＴＥ用のＲＲＣ（たとえば、ＲＲＣメッセージが、ＵＥ１００とｅＮＢ３０２のようなサービングｅＮＢとの間で転送され、サービングｅＮＢが、次いで、Ｅ−ＳＭＬＣ３０８などのＥ−ＳＭＬＣにＵＢＰ情報を運搬するためにＬＰＰａメッセージを使用する）、または（ｉｉｉ）ＵＭＴＳ用のＲＲＣ（たとえば、ＲＲＣメッセージが、ＵＥ１００とＲＮＣ３５６のようなサービングＲＮＣとの間で転送され、サービングＲＮＣが、次いで、ＳＡＳ３５４などのＳＡＳにＵＢＰ情報を運搬するためにＰＣＡＰメッセージを使用する）のためのメッセージの中に含まれ得る。

[0071]ステージ６０６において、サービングコアネットワーク２０４内のロケーションサーバ２０６は、ＵＢＰを出動可能都市ロケーションと組み合わせるように構成される。Ｅ−ＳＭＬＣ３０８、Ｅ−ＳＬＰ３３２、および／またはＳＡＳ３５４は、ＵＢＰを出動可能都市ロケーションと組み合わせるための手段である。一例では、ＵＢＰは、新たなＣＡタイプ（たとえば、ＵＢＰに対して規定されるＣＡタイプ、または環境データもしくは種々のデータとして規定されるＣＡタイプ）を使用するか、または既存のＣＡタイプ（たとえば、タイプ２２ＬＯＣまたはタイプ３２ＡＤＤＣＯＤＥ）の中に含まれる、（たとえば、ＰＩＤＦ−ＬＯオブジェクトの一部であってよい）都市アドレス（ＣＡ）内に含まれ得る。ＵＢＰを含む都市ロケーションまたはＰＩＤＦ−ＬＯは（たとえば、ＵＢＰを含む都市ロケーションがＰＩＤＦ−ＬＯ内に含まれるとき）、中間エンティティを通じてゲートウェイ２０８〜ＰＳＡＰ（たとえば、ＧＭＬＣ３０６またはＬＲＦ３３０のいずれか）まで透過的に転送および処理され得る。

[0072]ステージ６０８において、サービングコアネットワーク２０４の中のゲートウェイ２０８は、組み合わせられたＵＢＰと出動可能都市ロケーションとをＰＳＡＰに提供するように構成される。ＧＭＬＣ３０６またはＬＲＦ３３０は、ＵＢＰと出動可能都市ロケーションとをＰＳＡＰに提供するための手段である。一例では、（たとえば、両方がＰＩＤＦ−ＬＯ内に含まれ得る）都市ロケーションおよびＵＢＰは、ＨＥＬＤ、ＭＬＰ、またはＪ−ＳＴＤ−０３６ Ｅ２プロトコルを使用してＰＳＡＰ（たとえば、ｉ３ ＰＳＡＰ３４４またはレガシーＰＳＡＰ３４８）に転送される。代替実施形態では、サービングコアネットワーク２０４の中のゲートウェイ２０８は、出動可能都市ロケーションからＵＢＰを抽出し、ＵＢＰをＰＳＡＰに別個に提供するように構成される。一例では、抽出されたＵＢＰは、ＨＥＬＤ、ＭＬＰ、またはＪ−ＳＴＤ−０３６ Ｅ２プロトコルのうちの１つを使用してＰＳＡＰに転送される。

[0073]図１〜図６をさらに参照しながら図７Ａを参照すると、都市ロケーション情報を用いずにＵＢＰをＰＳＡＰに提供するためのプロセス７００は、図示のステージを含む。ただし、プロセス７００は例にすぎず、限定的でない。プロセス７００は、たとえば、ステージを追加させ、削除させ、並べ替えさせ、組み合わせ、および／または並行して実行させることによって改変されてよい。たとえば、ＵＢＰ情報は、都市ロケーション情報を取得する前にサービングネットワークによって取得されてよい。一実施形態では、プロセス７００は、図９に示すような１つまたは複数のコンピュータシステム上で実行され得る。

[0074]ステージ７０２において、サービングコアネットワーク２０４は、ＵＥ１００から非補償気圧（ＵＢＰ）を取得するように構成される。ＵＥ１００における圧力センサー１３０は、気圧を検出するための手段であり、プロセッサ１１１およびワイヤレストランシーバ１２１は、ＵＢＰをサービングコアネットワーク２０４に提供するための手段である。一例では、ＵＢＰ情報は、ＵＥ１００と（ｉ）Ｅ−ＳＬＰ３３２、または（ｉｉ）Ｅ−ＳＭＬＣ３０８（たとえば、Ｅ−ＳＭＬＣ３０８の場合にはＭＭＥ３０４およびｅＮＢ３０２を経由して）のいずれかとの間で（たとえば、ＬＰＰ／ＬＰＰｅを使用して）転送されるＬＰＰｅメッセージの中に含まれ得る。ロケーションサーバ２０６（たとえば、Ｅ−ＳＭＬＣ３０８、Ｅ−ＳＬＰ３３２、および／またはＳＡＳ３５４）は、ＵＥ１００からＵＢＰを取得するための手段である。別の例では、ＵＢＰ情報は、（ｉ）ＬＰＰ（たとえば、ＬＰＰメッセージが、ＵＥ１００とＥ−ＳＬＰ３３２またはＥ−ＳＭＬＣ３０８のいずれかとの間で、Ｅ−ＳＭＬＣ３０８の場合にはＭＭＥ３０４およびｅＮＢ３０２を経由して転送される）、（ｉｉ）ＬＴＥ用のＲＲＣ（たとえば、ＲＲＣメッセージが、ＵＥ１００とｅＮＢ３０２のようなサービングｅＮＢとの間で転送され、サービングｅＮＢが、次いで、Ｅ−ＳＭＬＣ３０８などのＥ−ＳＭＬＣにＵＢＰ情報を運搬するためにＬＰＰａメッセージを使用する）、または（ｉｉｉ）ＵＭＴＳ用のＲＲＣ（たとえば、ＲＲＣメッセージが、ＵＥ１００とＲＮＣ３５６のようなサービングＲＮＣとの間で転送され、サービングＲＮＣが、次いで、ＳＡＳ３５４などのＳＡＳにＵＢＰ情報を運搬するためにＰＣＡＰメッセージを使用する）のためのメッセージの中に含まれ得る。

[0075]ステージ７０４において、サービングコアネットワーク２０４は、ＵＢＰを含む都市ロケーションレコードを生成するように構成される。一例では、サービングコアネットワーク２０４は、前に説明したようにＵＥ１００用のＮＥＡＤ２１２から都市ロケーション情報（たとえば、１つまたは複数の都市ロケーション）を受信し、この都市ロケーション情報からＵＥ１００に対する出動可能都市ロケーションを取得するための手段として、Ｅ−ＳＭＬＣ３０８、Ｅ−ＳＬＰ３３２、またはＳＡＳ３５４などのロケーションサーバ２０６を含み得る。ＵＢＰは、新たなＣＡタイプにおけるフィールドとして（たとえば、環境データとして、種々のデータとして、または特にＵＢＰとして）含まれてよく、または既存の都市アドレスタイプ（たとえば、タイプ２２ＬＯＣまたはタイプ３２ＡＤＤＣＯＤＥ）の中に含まれてもよい。いくつかの実施形態では、ＵＢＰを含む出動可能都市ロケーションは、ＰＩＤＦ−ＬＯオブジェクト内に含まれ得る。別の例では、出動可能都市ロケーションが取得されない場合、ロケーションサーバ２０６は、空き都市ロケーションレコードを構築するように構成され得、空き都市ロケーションレコードはＵＢＰのみを含む。

[0076]ステージ７０６において、ロケーションサーバ２０６は、ＵＢＰを含む都市ロケーションレコードをゲートウェイ２０８に提供するように構成される。一実施形態では、（ＵＢＰを含む）都市ロケーションレコードは、ＰＩＤＦ−ＬＯの一部であってよい。一例では、ロケーションサーバ２０６（たとえば、Ｅ−ＳＭＬＣ３０８、Ｅ−ＳＬＰ３３２、および／またはＳＡＳ３５４）は、ＵＢＰを含む都市ロケーションレコード（または、ＰＩＤＦ−ＬＯ）をゲートウェイ２０８（たとえば、ＧＭＬＣ３０６またはＬＲＦ３３０）に提供するために、既存のインターフェースおよびそれらの関連する既存のプロトコル（たとえば、３ＧＰＰ ＳＬｓ、ＳＬｇ、Ｌ０、Ｌｇ、Ｌｇｄ、Ｉｕｐｃ、Ｉｕ−ｃｓ、Ｉｕ−ｐｓインターフェースのうちの１つまたは複数）を利用し得る。ＵＢＰ情報が（さらにＰＩＤＦ−ＬＯ内に埋め込まれ得る）都市ロケーションレコード内に埋め込まれるので、ＵＢＰは、中間エンティティを通じて透過的に転送および処理され得る。

[0077]ステージ７０８において、サービングコアネットワーク２０４の中のゲートウェイ２０８は、都市ロケーションレコードからＵＢＰを抽出するように構成される。ＧＭＬＣ３０６および／またはＬＲＦ３３０は、都市ロケーションレコードからＵＢＰを抽出するための例示的な手段である。ＵＢＰを抽出することは、ステージ７０４において説明したようなプロセスの逆であり得る。たとえば、ＵＢＰを含む新たなＣＡタイプ、またはＵＢＰを含む既存の都市アドレスタイプが、このＣＡタイプからゲートウェイ２０８によって抽出されたＵＢＰを用いて決定され得る。出動可能都市ロケーションが７０４の一部として取得されなかった場合、ゲートウェイ２０８は、空き都市ロケーションレコード（すなわち、空きであるがＵＢＰデータ用の）からＵＢＰを抽出するように構成され得る。

[0078]ステージ７１０において、サービングコアネットワーク２０４の中のゲートウェイ２０８は、ＵＢＰロケーションをＰＳＡＰ（たとえば、レガシーＰＳＡＰ３４８またはｉ３ ＰＳＡＰ３４４）に提供するように構成される。ＧＭＬＣ３０６またはＬＲＦ３３０は、ＵＢＰをＰＳＡＰに提供するための手段である。サービングコアネットワーク２０４の中のゲートウェイ２０８（たとえば、ＧＭＬＣ３０６またはＬＲＦ３３０）は、受信された都市ロケーションレコードからのＵＢＰを（たとえば、ＨＥＬＤ、ＭＬＰ、またはＪ−ＳＴＤ−０３６ Ｅ２プロトコル用の新たなパラメータを使用して）ＰＳＡＰに提供する。都市ロケーション情報は、ＵＢＰと同じメッセージの中、または１つもしくは複数の別個のメッセージの中で提供されてよい。

[0079]図１〜図７Ａをさらに参照しながら図７Ｂを参照すると、ゲートウェイ２０８を用いてＵＢＰをＰＳＡＰに提供するためのプロセス７２０は、図示のステージを含む。ただし、プロセス７２０は例にすぎず、限定的でない。プロセス７２０は、たとえば、ステージを追加させ、削除させ、並べ替えさせ、組み合わせ、および／または並行して実行させることによって改変されてよい。一実施形態では、プロセス７２０は、図９に示すようなコンピュータシステム上で実行され得る。

[0080]ステージ７２２において、ゲートウェイ２０８は、非補償気圧（ＵＢＰ）を含む出動可能都市ロケーションレコードを受信するように構成される。一例では、ロケーションサーバ２０６（たとえば、Ｅ−ＳＭＬＣ３０８、Ｅ−ＳＬＰ３３２、および／またはＳＡＳ３５４）は、ＵＢＰを含む都市ロケーションレコードをゲートウェイ２０８（たとえば、ＧＭＬＣ３０６またはＬＲＦ３３０）に提供するために、既存のインターフェースおよびそれらの関連する既存のプロトコル（たとえば、３ＧＰＰ ＳＬｓ、ＳＬｇ、Ｌ０、Ｌｇ、Ｌｇｄ、Ｉｕｐｃ、Ｉｕ−ｃｓ、Ｉｕ−ｐｓインターフェースのうちの１つまたは複数）を利用し得る。都市ロケーションレコードは、ＰＩＤＦ−ＬＯの一部であってよい。埋め込まれたＵＢＰ情報は、中間エンティティを通じて透過的に転送および処理され得る。

[0081]ステージ７２４において、ゲートウェイ２０８は、出動可能都市ロケーションレコードからＵＢＰを抽出するように構成される。ＧＭＬＣ３０６および／またはＬＲＦ３３０は、出動可能都市ロケーションレコードからＵＢＰを抽出するための例示的な手段である。ＵＢＰを抽出することは、たとえば、新たなＣＡタイプを識別すること、または既存の都市アドレスタイプを識別するとともにこのＣＡタイプのための情報からＵＢＰを抽出することを含み得る。ゲートウェイ２０８は、空き都市ロケーションレコード（すなわち、空きであるがＵＢＰデータ用の）からＵＢＰを抽出するように構成され得る。

[0082]ステージ７２６において、ゲートウェイ２０８は、ＵＢＰをＰＳＡＰ（たとえば、レガシーＰＳＡＰ３４８またはｉ３ ＰＳＡＰ３４４）に提供するように構成される。ＧＭＬＣ３０６またはＬＲＦ３３０は、ＵＢＰをＰＳＡＰに提供するための手段である。サービングコアネットワーク２０４の中のゲートウェイ２０８（たとえば、ＧＭＬＣ３０６またはＬＲＦ３３０）は、受信された都市ロケーションレコード（すなわち、都市ロケーション情報を有しない）からのＵＢＰを（たとえば、ＨＥＬＤ、ＭＬＰ、またはＪ−ＳＲＤ−０３６ Ｅ２プロトコル用の新たなパラメータを使用して）ＰＳＡＰに提供する。都市ロケーション情報は、ＵＢＰと同じメッセージの中、または１つもしくは複数の別個のメッセージの中で提供されてよい。

[0083]一実施形態では、ゲートウェイ２０８は、ステージ７２４において、出動可能都市ロケーションレコードからＵＢＰを抽出せず、代わりに、ステージ７２６において、依然として都市ロケーションレコード内に含まれるＵＢＰをＰＳＡＰに転送する。

[0084]図１〜図６をさらに参照しながら図７Ｃを参照すると、ＵＢＰを含む出動可能都市ロケーションレコードをゲートウェイに提供するためのプロセス７３０は、図示のステージを含む。ただし、プロセス７３０は例にすぎず、限定的でない。プロセス７３０は、たとえば、ステージを追加させ、削除させ、並べ替えさせ、組み合わせ、および／または並行して実行させることによって改変されてよい。一実施形態では、プロセス７３０は、図９に示すようなコンピュータシステム上で実行され得る。

[0085]ステージ７３２において、サービングコアネットワーク２０４の中のロケーションサーバ２０６は、ＵＥ１００から非補償気圧（ＵＢＰ）とロケーション情報とを取得するように構成される。ＵＥ１００における圧力センサー１３０は、気圧を検出するための手段であり、プロセッサ１１１およびワイヤレストランシーバ１２１は、ＵＢＰとロケーション情報とをサービングコアネットワーク２０４に提供するための手段である。ロケーション情報は、ＵＥ１００にとって認識できる１つまたは複数のＷｉＦｉおよび／またはＢＴ ＡＰの各々に対する１つまたは複数のＭＡＣアドレスを備え得る。一例では、ＵＢＰおよびロケーション情報は、（たとえば、ＬＰＰ／ＬＰＰｅを使用して）ＵＥ１００とＥ−ＳＬＰ３３２またはＥ−ＳＭＬＣ３０８のいずれかとの間で（たとえば、Ｅ−ＳＭＬＣ３０８の場合にはＭＭＥ３０４およびｅＮＢ３０２を経由して）転送される１つまたは複数のＬＰＰｅメッセージの中に含まれ得る。ロケーションサーバ２０６（たとえば、Ｅ−ＳＭＬＣ３０８、Ｅ−ＳＬＰ３３２、および／またはＳＡＳ３５４）は、ＵＥ１００からＵＢＰとロケーション情報とを取得するための手段である。別の例では、ＵＢＰおよびロケーション情報は、（ｉ）ＬＰＰ（たとえば、ＬＰＰメッセージが、ＵＥ１００とＥ−ＳＬＰ３３２またはＥ−ＳＭＬＣ３０８のいずれかとの間で、Ｅ−ＳＭＬＣ３０８の場合にはＭＭＥ３０４およびｅＮＢ３０２を経由して転送される）、（ｉｉ）ＬＴＥ用のＲＲＣ（たとえば、ＲＲＣメッセージが、ＵＥ１００とｅＮＢ３０２のようなサービングｅＮＢとの間で転送され、サービングｅＮＢが、次いで、Ｅ−ＳＭＬＣ３０８などのＥ−ＳＭＬＣにＵＢＰとロケーション情報とを運搬するためにＬＰＰａメッセージを使用する）、または（ｉｉｉ）ＵＭＴＳ用のＲＲＣ（たとえば、ＲＲＣメッセージが、ＵＥ１００とＲＮＣ３５６のようなサービングＲＮＣとの間で転送され、サービングＲＮＣが、次いで、ＳＡＳ３５４などのＳＡＳにＵＢＰとロケーション情報とを運搬するためにＰＣＡＰメッセージを使用する）のためのメッセージの中に含まれ得る。

[0086]ステージ７３４において、ロケーションサーバ２０６は、ステージ７３２において取得されたロケーション情報に基づいて、ＵＥに対する出動可能都市ロケーションを取得するように構成される。たとえば、ステージ７３２において取得されるロケーション情報は、ＵＥ１００にとって認識できる、ＷＬＡＮ３９０の中の１つまたは複数のＷｉＦｉおよび／またはＢＴ ＡＰの識別情報（たとえば、ＭＡＣアドレス）を含み得る。ロケーションサーバ２０６は、ＡＰ識別情報（たとえば、ＭＡＣアドレス）をＮＥＡＤ２１２に提供し得る。ＮＥＡＤ２１２は、次いで、対応する都市ロケーション情報（たとえば、市、ストリートアドレスおよび／または建築物名称、フロアレベル、ならびに場合によっては部屋番号またはアパート番号）が前に構成されていた、知られているＷＬＡＮ ＡＰのデータベースを（たとえば、外部データソース２１６およびＮＥＡＭ２１４を経由して）探索し得、提供されたＡＰ識別情報のうちの１つまたは複数の各々に対応する１つまたは複数の都市ロケーションをロケーションサーバ２０６に戻し得る。ロケーションサーバ２０６は、次いで、図２に関連して前に説明したように、出動可能都市ロケーションを（たとえば、ＮＥＡＤ２１２によって戻された都市ロケーションのうちの１つを使用して）取得し得る。一例では、Ｅ−ＳＭＬＣ３０８、Ｅ−ＳＬＰ３３２、および／またはＳＡＳ３５４などのロケーションサーバ２０６は、出動可能都市ロケーションを取得するための手段である。

[0087]ステージ７３６において、ロケーションサーバ２０６は、ＵＢＰを含む出動可能都市ロケーションレコードを生成するために、ＵＢＰをステージ７３４において取得された出動可能都市ロケーションと組み合わせるように構成される。ＵＢＰは、新たなＣＡタイプにおけるフィールドとして（たとえば、環境データとして、種々のデータとして、または特にＵＢＰとして）含まれてよく、または既存の都市アドレスタイプ（たとえば、タイプ２２ＬＯＣまたはタイプ３２ＡＤＤＣＯＤＥ）の中に含まれてもよい。別の例では、ステージ７３４において出動可能都市ロケーションが取得されない場合、ロケーションサーバ２０６は、ステージ７３６において、空き都市ロケーションレコードを構築するように構成され得、空き都市ロケーションレコードはＵＢＰのみを含む。一実施形態では、（ＵＢＰを含む）出動可能都市ロケーションレコードは、ＰＩＤＦ−ＬＯの一部として含まれ得る。

[0088]ステージ７３８において、ロケーションサーバ２０６は、ＵＢＰを含む都市ロケーションレコードをゲートウェイ２０８に提供するように構成される。一実施形態では、（ＵＢＰを含む）都市ロケーションレコードは、ＰＩＤＦ−ＬＯの一部として提供され得る。一例では、ロケーションサーバ２０６（たとえば、Ｅ−ＳＭＬＣ３０８、Ｅ−ＳＬＰ３３２、および／またはＳＡＳ３５４）は、ＵＢＰを含む都市ロケーションレコードをゲートウェイ２０８（たとえば、ＧＭＬＣ３０６またはＬＲＦ３３０）に提供するために、既存のインターフェースおよび関連する既存のプロトコル（たとえば、３ＧＰＰ ＳＬｓ、ＳＬｇ、Ｌ０、Ｌｇ、Ｌｇｄ、Ｉｕｐｃ、Ｉｕ−ｃｓ、Ｉｕ−ｐｓインターフェースのうちの１つまたは複数）を利用し得る。ＵＢＰ情報が（さらにＰＤＩＦ−ＬＯ内に埋め込まれ得る）都市ロケーションレコード内に埋め込まれるので、ＵＢＰは、中間エンティティを通じて透過的に転送および処理され得る。

[0089]前に説明したように、ＵＢＰは、ＰＩＤＦ−ＬＯ用の新規または既存のパラメータまたはフィールドを使用してＰＩＤＦ−ＬＯ内に含まれ得る。この場合、ＵＢＰは、ＰＩＤＦ−ＬＯ内に含まれてよいが、出動可能都市ロケーション内に含まれなくてよく、または埋め込まれなくてよい。代わりに、ＰＩＤＦ−ＬＯは、（たとえば、ＰＩＤＦ−ＬＯ用の新規もしくは既存のパラメータまたは新規もしくは既存のフィールドを使用して）ＵＢＰを含んでよく、場合によってはＵＥ１００に対する出動可能都市ロケーションおよび／または地理的ロケーションも含んでよいが、ここで、ＵＢＰは、ＰＩＤＦ−ＬＯの一部であるが、出動可能都市ロケーションおよび／または地理的ロケーションとは別個である。この場合、前に説明したプロセス６００、７００、７２０、および７３０は、ＵＢＰをｉ３ ＰＳＡＰ３４４またはレガシーＰＳＡＰ３４８などのＰＳＡＰに提供するために、いくつかの変更を伴ってサービングコアネットワーク２０４によって使用され得る。プロセス６００、７００、７２０、および７３０のこれらの変更が次に説明され、変更されるものとして示されないプロセスステージは前に説明したように使用される。プロセス６００の場合には、（ｉ）ステージ６０２は、オプションとしてのみ実行され、（ｉｉ）ステージ６０４において（たとえば、ロケーションサーバ２０６によって）取得されたＵＢＰは、ステージ６０６において（たとえば、ロケーションサーバ２０６によって）ＰＩＤＦ−ＬＯと組み合わせられ、ステージ６０２が行われる場合、ＰＩＤＦ−ＬＯは、ステージ６０２において取得された任意の出動可能都市ロケーションも含み、（ｉｉｉ）ＵＢＰおよびＰＩＤＦ−ＬＯは、ステージ６０８において（たとえば、ゲートウェイ２０８によって）ＰＳＡＰに提供される。プロセス７００の場合には、（ｉ）都市ロケーションレコードの代わりにまたは都市ロケーションレコードに加えて、ＰＩＤＦ−ＬＯが、ステージ７０４において（たとえば、ロケーションサーバ２０６によって）生成され、ＰＩＤＦ−ＬＯは、ＵＢＰ（および、生成された任意の都市ロケーションレコード）を含み、（ｉｉ）ステージ７０４において生成されたＰＩＤＦ−ＬＯは、ステージ７０６において（たとえば、ロケーションサーバ２０６によって）ゲートウェイ２０８に提供され、（ｉｉｉ）ゲートウェイ２０８は、ステージ７０８においてＰＩＤＦ−ＬＯからＵＢＰを抽出する。プロセス７２０の場合には、（ｉ）ＵＢＰを含むＰＩＤＦ−ＬＯは、ステージ７２２においてゲートウェイ２０８によって受信され、（ｉｉ）ＵＢＰは、ステージ７２４においてゲートウェイ２０８によってＰＩＤＦ−ＬＯから抽出される。プロセス７３０の場合には、（ｉ）ステージ７３４は、随意であり常に行われるとは限らず、（ｉｉ）ステージ７３６において、ステージ７３２において取得されたＵＢＰは、（ステージ７３４が行われる場合、ステージ７３４において取得された任意の出動可能都市ロケーションも含み得る）ＰＩＤＦ−ＬＯと（たとえば、ロケーションサーバ２０６によって）組み合わせられ、（ｉｉｉ）ステージ７３８において、ＵＢＰを含むＰＩＤＦ−ＬＯは、（たとえば、ロケーションサーバ２０６によって）ゲートウェイ（たとえば、ゲートウェイ２０８）に提供される。

[0090]図１〜図５をさらに参照しながら図８を参照すると、ロケーション情報メッセージングを介してＵＢＰをＰＳＡＰに提供するためのプロセス８００は、図示のステージを含む。ただし、プロセス８００は例にすぎず、限定的でない。プロセス８００は、たとえば、ステージを追加させ、削除させ、並べ替えさせ、組み合わせ、および／または並行して実行させることによって改変されてよい。たとえば、ＵＢＰ情報は、ＵＥに対するロケーション情報を決定もしくは受信する前に、それと同じ時間において、またはその後に、サービングネットワークによって受信され得る。一実施形態では、プロセス８００は、図９に示すような１つまたは複数のコンピュータシステム上で実行され得る。

[0091]ステージ８０２において、ＵＥ１００、および／またはサービングコアネットワーク２０４の中のロケーションサーバ２０６は、ＵＥ１００に対するロケーション情報を決定するように構成される。一例では、ＵＥ１００上のＳＰＳ受信機１５５は、ＳＰＳ信号１５９を全体的または部分的に処理し、ＵＥ１００のロケーションを決定するためにこれらのＳＰＳ信号１５９を使用する。プロセッサ１１１、メモリ１４０、ＤＳＰ１１２、および／または専用プロセッサ（図示せず）も、ＳＰＳ信号１５９を全体的もしくは部分的に処理するために、および／またはＵＥ１００のロケーションを計算するために、ＳＰＳ受信機１５５とともに利用され得る。ロケーションサーバ２０６は、ロケーション計算の少なくとも一部を実行するために使用され得る。ＵＥ１００はまた、視界内の他の通信エンティティおよび／またはＵＥ１００にとって利用可能な情報に基づいて、関連するシステム内でのその現在位置を様々な技法を使用して推定し得る。ＵＥ１００は、１つもしくは複数のワイヤレスローカルエリアネットワーク（ＷＬＡＮ）、ＢＬＵＥＴＯＯＴＨ（登録商標）もしくはＺＩＧＢＥＥなどの短距離ワイヤレス通信技術を利用するパーソナルエリアネットワーク（ＰＡＮ）に関連する、アクセスポイント（ＡＰ）から取得された情報、および／またはロケーションサーバ２０６から取得されたマップ制約データを使用して、その位置を推定し得る。

[0092]ステージ８０４において、サービングコアネットワーク２０４（たとえば、ロケーションサーバ２０６）は、ＵＥ１００から非補償気圧（ＵＢＰ）を受信するように構成される。ＵＥ１００における圧力センサー１３０は、気圧を検出するための手段であり、プロセッサ１１１およびワイヤレストランシーバ１２１は、ＵＢＰをサービングコアネットワーク２０４に提供するための手段である。一例では、ＵＢＰ情報は、（たとえば、ＬＰＰ／ＬＰＰｅを使用して）ＵＥ１００とＥ−ＳＬＰ３３２またはＥ−ＳＭＬＣ３０８のいずれかとの間で（Ｅ−ＳＭＬＣ３０８の場合にはＭＭＥ３０４およびｅＮＢ３０２を経由して）転送されるＬＰＰｅメッセージの中に含まれ得る。ロケーションサーバ２０６（たとえば、Ｅ−ＳＭＬＣ３０８、Ｅ−ＳＬＰ３３２、および／またはＳＡＳ３５４）は、ＵＥ１００からＵＢＰを受信するための手段である。別の例では、ＵＢＰ情報は、（ｉ）ＬＰＰ（たとえば、ＬＰＰメッセージが、ＵＥ１００とＥ−ＳＬＰ３３２またはＥ−ＳＭＬＣ３０８のいずれかとの間で（Ｅ−ＳＭＬＣ３０８の場合にはＭＭＥ３０４およびｅＮＢ３０２を経由して）転送される）、（ｉｉ）ＬＴＥ用のＲＲＣ（たとえば、ＲＲＣメッセージがＵＥ１００とｅＮＢ３０２のようなサービングｅＮＢとの間で転送され、サービングｅＮＢが、次いで、Ｅ−ＳＭＬＣ３０８などのＥ−ＳＭＬＣにＵＢＰ情報を運搬するためにＬＰＰａメッセージを使用する）、または（ｉｉｉ）ＵＭＴＳ用のＲＲＣ（たとえば、ＲＲＣメッセージが、ＵＥ１００とＲＮＣ３５６のようなサービングＲＮＣとの間で転送され、サービングＲＮＣが、次いで、ＳＡＳ３５４などのＳＡＳにＵＢＰ情報を運搬するためにＰＣＡＰメッセージを使用する）のためのメッセージの中に含まれ得る。

[0093]ステージ８０６において、ロケーションサーバ２０６は、ＵＢＰをロケーション情報と組み合わせるように構成される。Ｅ−ＳＭＬＣ３０８、Ｅ−ＳＬＰ３３２、および／またはＳＡＳ３５４は、ＵＢＰをロケーション情報と組み合わせるための例示的な手段である。一例では、ロケーション情報は、地理的ロケーションを備えてよく、３ＧＰＰ ＴＳ２３．０３２において規定されるオクテット列によって表されてよい。ＵＢＰを３ＧＰＰロケーション情報の中に組み合わせるために、ロケーションサーバ２０６は、ＵＢＰを運搬するための、ロケーション情報オクテット列のいくつかの（たとえば、２つまたは３つの）追加オクテットを（たとえば、末尾において）連結するか、または別の方法で組み合わせるように構成され得る。ＵＢＰを既存のロケーション情報フォーマットと組み合わせるための他の方法も使用され得る。一例では、（たとえば、３ＧＰＰ ＴＳ２３．０３２において規定されるような）標準的な地理的形状に関連するパラメータが、ＵＢＰ情報（たとえば、上記で説明したような楕円点、高度パラメータ、およびＸＭＬフォーマット）を収容するように修正されてよい。

[0094]ステージ８０８において、ロケーションサーバ２０６は、ＵＢＰとロケーション情報とをゲートウェイ２０８に提供するように構成される。一例では、ロケーションサーバ２０６（たとえば、Ｅ−ＳＭＬＣ３０８、Ｅ−ＳＬＰ３３２、および／またはＳＡＳ３５４）は、ＵＢＰとロケーション情報とをゲートウェイ２０８（たとえば、ＧＭＬＣ３０６またはＬＲＦ３３０）に提供するために、既存のインターフェースおよび関連する既存のプロトコル（たとえば、３ＧＰＰ ＳＬｓ、ＳＬｇ、Ｌ０、Ｌｇ、Ｌｇｄ、Ｉｕｐｃ、Ｉｕ−ｃｓ、Ｉｕ−ｐｓインターフェースのうちの１つまたは複数）を利用し得る。ＵＢＰ情報がロケーション情報内に埋め込まれるので、ＵＢＰは、中間エンティティを通じて透過的に処理され得る。

[0095]ステージ８１０において、サービングコアネットワーク２０４の中のゲートウェイ２０８は、ロケーション情報からＵＢＰを抽出するように構成される。ＧＭＬＣ３０６および／またはＬＲＦ３３０は、ロケーション情報からＵＢＰを抽出するための例示的な手段である。ＵＢＰを抽出することは、ステージ８０６において説明したようなプロセスの逆であり得る。たとえば、ゲートウェイ２０８は、地理的ロケーション列からの追加の（たとえば、２つまたは３つの）オクテットを構文解析し、または上記で説明したオブジェクトフォーマット（たとえば、楕円点、高度パラメータ、およびＸＭＬタグ）からＵＢＰ情報を抽出するように構成され得る。

[0096]ステージ８１２において、サービングコアネットワーク２０４の中のゲートウェイ２０８は、ＵＢＰロケーションをＰＳＡＰ（たとえば、レガシーＰＳＡＰ３４８またはｉ３ ＰＳＡＰ３４４）に提供するように構成される。ＧＭＬＣ３０６またはＬＲＦ３３０は、ＵＢＰをＰＳＡＰに提供するための手段である。サービングコアネットワーク２０４の中のゲートウェイ２０８（たとえば、ＧＭＬＣ３０６またはＬＲＦ３３０）は、ロケーション情報から抽出されたＵＢＰを（たとえば、ＨＥＬＤ、ＭＬＰ、またはＪ−ＳＴＤ−０３６ Ｅ２プロトコル用の新たなパラメータを使用して）ＰＳＡＰに提供する。ロケーション情報は、同じメッセージの中、または１つもしくは複数の別個のメッセージの中で提供され得る。

[0097]（たとえば、図２、図３Ａ、図３Ｂ、図４、図６、図７Ａ、図７Ｂ、図７Ｃに関連するような）前の説明において、ロケーションサーバ（たとえば、Ｅ−ＳＭＬＣ３０８、Ｅ−ＳＬＰ３３２、またはＳＡＳ３５４）によってＵＢＰが組み合わせられ得る出動可能都市ロケーションの決定を言及する際に、ロケーションサーバにおいて都市ロケーションと出動可能都市ロケーションとを取得するための手段としてＮＥＡＤ（たとえば、ＮＥＡＤ２１２）の使用が説明されたことに留意されたい。しかしながら、別の実施形態では、ロケーションサーバ２０６は、ＳＵＰＬ ＵＬＰ、ＬＰＰ／ＬＰＰｅ、ＵＭＴＳ用のＲＲＣ、ＬＴＥ用のＲＲＣ、またはＰＣＡＰなどの測位関連プロトコルを使用して、出動可能都市ロケーションをＵＥ（たとえば、ＵＥ１００）から直接取得し得る。さらなる実施形態では、ロケーションサーバ２０６（たとえば、Ｅ−ＳＭＬＣ３０８、Ｅ−ＳＬＰ３３２、またはＳＡＳ３５４）は、アクセスネットワーク（たとえば、アクセスネットワークの中のｅＮＢ３０２またはＲＮＣ３５６）から、またはＷＬＡＮから（たとえば、ＷＬＡＮ３９０の中のコントローラまたはアクセスポイントから）、出動可能都市ロケーションを取得し得る。また別の実施形態では、ロケーションサーバ２０６（たとえば、Ｅ−ＳＭＬＣ３０８、Ｅ−ＳＬＰ３３２、またはＳＡＳ３５４）は、ＵＥ１００に対する出動可能都市ロケーションを別のロケーションサーバから取得し得、別のロケーションサーバは、ＮＥＡＤ２１２から、ＵＥ１００から、あるいはアクセスネットワークもしくはアクセスネットワークの中の要素（たとえば、ｅＮＢ３０２、ノードＢ３５２、またはＲＮＣ３５６）またはＷＬＡＮ（たとえば、ＷＬＡＮ３９０）から、出動可能都市ロケーションを取得し得る。別の実施形態では、ロケーションサーバ２０６（たとえば、Ｅ−ＳＭＬＣ３０８、Ｅ−ＳＬＰ３３２、またはＳＡＳ３５４）は、（たとえば、ロケーションサーバにおいて構成されるデータを使用して）場合によっては、ＵＥ１００から、ＵＥ１００のためのアクセスネットワークから、またはＵＥ１００から信号を受信するＵＥ１００まで近くのＡＰを含むＷＬＡＮ（たとえば、ＷＬＡＮ３９０）から受信された、ＵＥ１００に対するロケーション関連情報（たとえば、ロケーション関連測定値および／またはロケーション推定値）に基づいて、ＵＥ１００に対する出動可能都市ロケーションをそれ自体で決定し得る。これらの実施形態のすべてに対して、また図２、図３Ａ、図３Ｂ、図４、図６、図７Ａ、図７Ｂ、および図７Ｃに関連して説明したように、ロケーションサーバ２０６は、ＵＥ１００から受信されたＵＢＰ測定値をＵＥ１００に対する出動可能都市ロケーションと組み合わせ得、ＰＳＡＰへの前方転送、またはゲートウェイがＵＢＰを抽出し、ＵＢＰをＰＳＡＰへ別個に送ることのいずれかのために、組み合わせられた出動可能都市ロケーションとＵＢＰとをゲートウェイ２０８に転送し得る。

[0098]図１〜図８をさらに参照しながら図９を参照すると、コンピュータシステム９００は、図３Ａおよび図３Ｂにおける要素の機能を少なくとも部分的に実施することによってＵＢＰ情報を転送するために利用され得る。図９は、本明細書で説明するような様々な他の実施形態によって提供される（たとえば、図２〜図８に関連して説明したような）方法を実行することができ、および／またはモバイルデバイス（たとえば、ＵＥ１００）もしくは他のコンピュータシステムとして機能することができる、コンピュータシステム９００の一実施形態の概略図を提供する。サービングコアネットワーク２０４は、ロケーションサーバ２０６およびゲートウェイ２０８などにおける１つまたは複数のコンピュータシステム９００を含み得る。たとえば、図３Ａおよび図３ＢにおけるｅＮＢ３０２、ＭＭＥ３０４、ＧＭＬＣ３０６、Ｅ−ＳＭＬＣ３０８、Ｅ−ＳＬＰ３３２（ＳＰＣ３３４とＳＬＣ３３６とを含む）、ＳＡＳ３５４、ＬＲＦ３３０、および他のエンティティは、１つまたは複数のコンピュータシステム９００からなり得る。図９は、様々な構成要素の一般化された例を提供し、そのいずれかまたはすべてが適宜に利用され得る。したがって、図９は、個々のシステム要素が、相対的に分離された方法または相対的により統合された方法でどのように実装され得るのかを広く示す。

[0099]バス９０５を介して電気的に結合され得る（または、適宜に別の方法で通信していることがある）ハードウェア要素を備えるコンピュータシステム９００が示される。ハードウェア要素は、限定はしないが、１つもしくは複数の汎用プロセッサおよび／または１つもしくは複数の専用プロセッサ（デジタル信号処理チップ、グラフィックス加速プロセッサなど）を含む１つまたは複数のプロセッサ９１０と、限定はしないが、マウス、キーボードなどを含むことができる１つまたは複数の入力デバイス９１５と、限定はしないが、ディスプレイデバイス、プリンタなどを含むことができる１つまたは複数の出力デバイス９２０とを含み得る。プロセッサ９１０は、たとえば、インテリジェントハードウェアデバイス、たとえば、Ｉｎｔｅｌ（登録商標） ＣｏｒｐｏｒａｔｉｏｎまたはＡＭＤ（登録商標）によって作られるものなどの中央処理装置（ＣＰＵ）、マイクロコントローラ、ＡＳＩＣなどを含むことができる。他のプロセッサタイプも利用され得る。

[00100]コンピュータシステム９００は、１つまたは複数の非一時的記憶デバイス９２５をさらに含み得（および／または、それらと通信していることがあり）、非一時的記憶デバイス９２５は、限定はしないが、ローカルストレージおよび／またはネットワークアクセス可能ストレージを備えることができ、ならびに／あるいは、限定はしないが、ディスクドライブと、ドライブアレイと、光記憶デバイスと、プログラム可能、フラッシュアップデート可能などであり得る、ランダムアクセスメモリ（「ＲＡＭ」）および／または読取り専用メモリ（「ＲＯＭ」）などのソリッドステート記憶デバイスとを含むことができる。そのような記憶デバイスは、限定はしないが、様々なファイルシステム、データベース構造などを含む、任意の適切なデータストアを実装するように構成され得る。

[00101]コンピュータシステム９００はまた、限定はしないが、モデム、ネットワークカード（ワイヤレスまたはワイヤード）、赤外線通信デバイス、（ＢＬＵＥＴＯＯＴＨ短距離ワイヤレス通信技術トランシーバ／デバイス、８０２．１１デバイス、ＷｉＦｉデバイス、ＷｉＭａｘ（登録商標）デバイス、セルラー通信施設などの）ワイヤレス通信デバイスおよび／またはチップセットなどを含むことができる、通信サブシステム９３０とネットワークインターフェース９５０とを含み得る。ネットワークインターフェース９５０は、データが、（一例を挙げれば本明細書で説明したＬＴＥネットワークなどの）ネットワーク、他のコンピュータシステム、および／または本明細書で説明する任意の他のデバイスと交換されることを可能にし得る。多くの実施形態では、コンピュータシステム９００は、上記で説明したように、ＲＡＭまたはＲＯＭデバイスを含むことができる作業メモリ９３５をここではさらに備える。

[00102]コンピュータシステム９００はまた、オペレーティングシステム９４０、デバイスドライバ、実行可能ライブラリ、および／または１つもしくは複数のアプリケーションプログラム９４５などの他のコードを含む、現在作業メモリ９３５内に位置するものとして示されるソフトウェア要素を備えることができ、アプリケーションプログラム９４５は、様々な実施形態によって提供されるコンピュータプログラムを備えてよく、ならびに／あるいは本明細書で説明するように、他の実施形態によって提供される方法を実施し、および／または他の実施形態によって提供されるシステムを構成するように設計されてよい。単に例として、本明細書で説明する１つまたは複数のプロセスは、コンピュータ（および／またはコンピュータ内のプロセッサ）によって実行可能なコードおよび／または命令として実装され得る。そのようなコードおよび／または命令は、説明した方法に従って１つもしくは複数の動作を実行するように汎用コンピュータ（または他のデバイス）を構成し、および／または適合させるために使用され得る。

[00103]これらの命令および／またはコードのセットは、上記で説明した記憶デバイス９２５などのコンピュータ可読記憶媒体上に記憶され得る。場合によっては、記憶媒体は、コンピュータシステム９００などのコンピュータシステム内に組み込まれ得る。他の実施形態では、記憶媒体は、コンピュータシステムとは別個（たとえば、コンパクトディスクなどのリムーバブル媒体）であってよく、ならびに／あるいは、記憶媒体が、その上に記憶された命令／コードを用いて汎用コンピュータをプログラムし、構成し、および／または適合させるために使用され得るようなインストールパッケージで提供され得る。これらの命令は、コンピュータシステム９００によって実行可能である実行可能コードの形態をとり得、ならびに／あるいは、（たとえば、一般に利用可能な様々なコンパイラ、インストールプログラム、圧縮／解凍ユーティリティなどのいずれかを使用して）コンピュータシステム９００上でコンパイルおよび／またはインストールしたときに実行可能コードの形態をとる、ソースコードおよび／またはインストール可能コードの形態をとり得る。

[00104]特定の要望に従って、大幅な変形が行われてよい。たとえば、カスタマイズされたハードウェアも使用されてよく、および／または特定の要素が、ハードウェア、（アプレットなどのポータブルソフトウェアを含む）ソフトウェア、もしくはその両方で実装され得る。さらに、ネットワーク入力／出力デバイスなどの他のコンピューティングデバイスへの接続が採用されてよい。

[00105]コンピュータシステム９００は、本開示に従って方法を実行するために使用され得る。そのような方法の手順の一部または全部は、プロセッサ９１０が、作業メモリ９３５の中に含まれる（オペレーティングシステム９４０、および／またはアプリケーションプログラム９４５などの他のコードに組み込まれ得る）１つまたは複数の命令の１つまたは複数のシーケンスを実行したことに応答して、コンピュータシステム９００によって実行され得る。そのような命令は、記憶デバイス９２５のうちの１つまたは複数などの別のコンピュータ可読媒体から作業メモリ９３５に読み取られてよい。単に例として、作業メモリ９３５の中に含まれる命令のシーケンスの実行は、本明細書で説明した方法の１つまたは複数の手順をプロセッサ９１０に実行させ得る。

[00106]本明細書で使用する「機械可読媒体」および「コンピュータ可読媒体」という用語は、特定の様式で機械を動作させるデータを与えることに関与する任意の媒体を指す。ＵＥ１００および／またはコンピュータシステム９００を使用して実施される実施形態では、様々なコンピュータ可読媒体が、実行のために命令／コードをプロセッサ１１１、９１０に提供することに関連し得、ならびに／または、（たとえば、信号のような）そのような命令／コードなどを記憶および／もしくは搬送するために使用され得る。多くの実装形態では、コンピュータ可読媒体は、物理的および／または有形の記憶媒体である。そのような媒体は、限定はしないが、不揮発性媒体と、揮発性媒体と、伝送媒体とを含む、多くの形態をとり得る。不揮発性媒体は、たとえば、記憶デバイス１４０、９２５などの光ディスクおよび／または磁気ディスクを含む。揮発性媒体は、限定はしないが、作業メモリ１４０、９３５などのダイナミックメモリを含む。伝送媒体は、限定はしないが、同軸ケーブル、バス１０１、９０５を備えるワイヤを含む銅線および光ファイバ、ならびに通信サブシステム９３０の様々な構成要素（および／または通信サブシステム９３０がそれによって他のデバイスとの通信を行う媒体）を含む。したがって、伝送媒体はまた、（限定はしないが、電波通信および赤外線データ通信中に生成されるものなどの、電波、音響波、および／または光波を含む）波の形態をとることができる。

[00107]物理的および／または有形のコンピュータ可読媒体の一般の形態は、たとえば、フロッピー（登録商標）ディスク、フレキシブルディスク、ハードディスク、磁気テープまたは任意の他の磁気媒体、ＣＤ−ＲＯＭ、Ｂｌｕ−Ｒａｙ（登録商標）ディスク、任意の他の光媒体、パンチカード、紙テープ、穴のパターンを有する他の任意の物理媒体、ＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＦＬＡＳＨ−ＥＰＲＯＭ、任意の他のメモリチップまたはカートリッジ、以下で説明するような搬送波、あるいはコンピュータが命令および／またはコードをそこから読み取ることができる他の任意の媒体を含む。

[00108]コンピュータ可読媒体の様々な形態は、実行のために１つまたは複数の命令の１つまたは複数のシーケンスをプロセッサ１１１、９１０に搬送することに関連し得る。単に例として、命令は、最初に、リモートコンピュータの磁気ディスクおよび／または光ディスク上で搬送され得る。リモートコンピュータは、そのダイナミックメモリに命令をロードし得、ＵＥ１００および／またはコンピュータシステム９００によって受信および／または実行されるように、伝送媒体を介して信号として命令を送り得る。これらの信号は、電磁信号、音響信号、光信号などの形態であってよく、様々な実施形態に従って命令がその上で符号化され得る搬送波のすべての例である。

[00109]本開示による非一時的プロセッサ可読記憶媒体の一例は、非補償気圧情報をＰＳＡＰに提供するための命令を含み、命令は、ユーザ機器から非補償気圧（ＵＢＰ）を取得するためのコードと、ユーザ機器に対する出動可能都市ロケーションを取得するためのコードと、ＵＢＰを出動可能都市ロケーションと組み合わせるためのコードと、ＵＢＰと出動可能都市ロケーションとをＰＳＡＰへ送るためのコードとを含む。

[00110]そのような非一時的プロセッサ可読記憶媒体の実装形態は、以下の特徴のうちの１つまたは複数を含み得る。ＵＢＰと出動可能都市ロケーションとをロケーションサーバを用いて取得するためのコード。ロケーションサーバは、拡張サービングモバイルロケーションセンター（Ｅ−ＳＭＬＣ）、緊急ＳＵＰＬロケーションプラットフォーム（Ｅ−ＳＬＰ）、またはスタンドアロンサービングモバイルロケーションセンター（ＳＡＳ）のうちの１つであってよい。ユーザ機器からＵＢＰを取得するためのコードは、ＯＭＡ ＬＴＥ測位プロトコル拡張（ＬＰＰｅ）プロトコル、３ＧＰＰ ＬＴＥ測位プロトコル（ＬＰＰ）、ＬＴＥ用の３ＧＰＰ無線リソース制御（ＲＲＣ）プロトコル、ＵＭＴＳ用の３ＧＰＰ ＲＲＣプロトコル、３ＧＰＰ ＬＴＥ測位プロトコルＡ（ＬＰＰａ）プロトコル、または３ＧＰＰ測位計算アプリケーションパート（ＰＣＡＰ）プロトコルのうちの少なくとも１つを介してＵＢＰを取得するように構成され得る。出動可能都市ロケーションは、プレゼンス情報データフォーマットロケーションオブジェクト（ＰＩＤＦ−ＬＯ）を含み得、ＰＩＤＦ−ＬＯは、国家緊急アドレスデータベース（ＮＥＡＤ）から受信され得る。ＵＢＰと出動可能都市ロケーションとをＰＳＡＰへ送るためのコードは、３ＧＰＰ Ｉｕｐｃ、Ｉｕ−ｃｓ、Ｉｕ−ｐｓ、ＳＬｓ、ＳＬｇ、Ｌｇ、Ｌｇｄ、またはＬ０インターフェースのうちの少なくとも１つを介して、ＵＢＰと出動可能都市ロケーションとをゲートウェイに提供するためのコードと、ＨＥＬＤ、ＭＬＰ、またはＪ−ＳＴＤ−０３６ Ｅ２プロトコルのうちの少なくとも１つを介して、少なくともＵＢＰをゲートウェイからＰＳＡＰに提供するためのコードとを含み得る。

[00111]上記で説明した方法、システム、およびデバイスは例である。様々な代替構成は、様々な手順または構成要素を、適宜に省略、置換、または追加し得る。たとえば、代替方法では、上の説明とは異なる順序でステージが実行されてよく、様々なステージが追加され、省略され、または組み合わせられてよい。また、いくつかの構成に関して説明した特徴は、様々な他の構成では組み合わせられてよい。構成の異なる態様および要素が、同様にして組み合わせられてよい。また、技術は発展し、したがって、要素のうちの多くは例であり、本開示または特許請求の範囲を限定しない。

[00112]本開示に従ってユーザ機器（ＵＥ）とＰＳＡＰとの間で非補償気圧（ＵＢＰ）を提供するための装置の一例は、ＵＥに対するロケーション情報を決定するための手段と、ＵＥからＵＢＰを受信するための手段と、ＵＢＰをロケーション情報と組み合わせるための手段と、ＵＢＰとロケーション情報とをゲートウェイに提供するための手段と、ロケーション情報からＵＢＰを抽出するための手段と、ＵＢＰをＰＳＡＰに提供するための手段とを含む。

[00113]そのような装置の実装形態は、以下の特徴のうちの１つまたは複数を含み得る。ＵＥからＵＢＰを受信するための手段は、ＯＭＡ ＬＴＥ測位プロトコル拡張（ＬＰＰｅ）プロトコル、３ＧＰＰ ＬＴＥ測位プロトコル（ＬＰＰ）、ＬＴＥ用の３ＧＰＰ無線リソース制御（ＲＲＣ）プロトコル、ＵＭＴＳ用の３ＧＰＰ ＲＲＣプロトコル、３ＧＰＰ ＬＴＥ測位プロトコルＡ（ＬＰＰａ）プロトコル、または３ＧＰＰ測位計算アプリケーションパート（ＰＣＡＰ）プロトコルのうちの少なくとも１つを含み得る。ＵＢＰとロケーション情報とをゲートウェイに提供するための手段は、３ＧＰＰ ＳＬｓ、ＳＬｇ、Ｌ０、Ｌｇ、Ｌｇｄ、Ｉｕｐｃ、Ｉｕ−ｃｓ、またはＩｕ−ｐｓインターフェースのうちの少なくとも１つを含み得る。ＵＥに対するロケーション情報を決定するための手段は、ＳＰＳ受信機を含み得る。ＵＢＰをＰＳＡＰに提供するための手段は、ＨＥＬＤ、ＭＬＰ、またはＪ−ＳＴＤ−０３６ Ｅ２プロトコルのうちの少なくとも１つを含む。ＵＢＰをロケーション情報と組み合わせるための手段は、ＵＢＰを表すいくつかの（たとえば、２つまたは３つの）追加オクテットのデータフィールドに地理的ロケーション列を連結することを含み得る。

[00114]（実装形態を含む）例示的な構成の完全な理解を与えるように、説明では具体的な詳細が与えられる。しかしながら、構成は、これらの具体的な詳細を伴わずに実践されてよい。たとえば、構成を不明瞭にすることを避けるために、よく知られている回路、プロセス、アルゴリズム、構造、および技法が、不必要な詳細を伴わずに示される。この説明は、例示的な構成を与えるにすぎず、特許請求の範囲の範囲、適用性、または構成を限定しない。そうではなく、構成の上記の説明は、説明した技法を実施することを可能にする説明を当業者に与えるものである。本開示の趣旨および範囲から逸脱することなく、要素の機能および構成において様々な変更が行われてよい。

[00115]構成は、フロー図またはブロック図として示されるプロセスとして説明されることがある。各々は動作を逐次プロセスとして説明することがあるが、動作の多くは並行してまたは同時に実行されてよい。加えて、動作の順序は、並べ替えられてよい。プロセスは、図に含まれない追加のステップを有してよい。さらに、方法の例は、ハードウェア、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語、またはそれらの任意の組合せによって実装され得る。ソフトウェア、ファームウェア、ミドルウェア、またはマイクロコードで実装されるとき、必要なタスクを実行するためのプログラムコードまたはコードセグメントは、記憶媒体などの非一時的コンピュータ可読媒体に記憶され得る。プロセッサは、説明したタスクを実施し得る。

[00116]特許請求の範囲を含め本明細書で使用するとき、「のうちの少なくとも１つ」で終わる項目の列挙中で使用される「または」は、たとえば、「Ａ、Ｂ、またはＣのうちの少なくとも１つ」の列挙が、ＡまたはＢまたはＣまたはＡＢまたはＡＣまたはＢＣまたはＡＢＣ（すなわち、ＡおよびＢおよびＣ）、あるいは２つ以上の特徴を有する組合せ（たとえば、ＡＡ、ＡＡＢ、ＡＢＢＣなど）を意味するような、選言的列挙を示す。本明細書で使用するとき、Ａ、Ｂ、および／またはＣなどの、項目の列挙中で使用される「および／または」という用語は、ＡまたはＢまたはＣまたはそれらの組合せと等価である。

[00117]特許請求の範囲を含め本明細書で使用するとき、別段に明記されていない限り、機能または動作が項目または状態「に基づく」という文は、機能または動作が、述べられた項目または状態に基づき、述べられた項目または状態に加えて１つまたは複数の項目および／または状態に基づいてよいことを意味する。

[00118]いくつかの例示的な構成を説明したが、本開示の趣旨から逸脱することなく、様々な変更形態、代替構成、および等価物が使用され得る。たとえば、上記の要素は、もっと大きいシステムの構成要素であってよく、他の規則が、様々な実施形態の適用例よりも優先されてよく、または様々な実施形態の適用例を別の方法で修正してもよい。また、いくつかのステップが、上記の要素が考慮される前、考慮されている間、または考慮された後に着手されてよい。したがって、上記の説明は特許請求の範囲を限定しない。

Claims (24)

1. 非補償気圧情報を公共安全応答ポイント（ＰＳＡＰ）に提供するための方法であって、
   ユーザ機器に対する出動可能都市ロケーションを取得することと、
   前記ユーザ機器から非補償気圧（ＵＢＰ）を取得することと、
   前記ＵＢＰを前記出動可能都市ロケーションと組み合わせることと、
   前記ＵＢＰと前記出動可能都市ロケーションとを前記ＰＳＡＰに提供することと
   を備える方法。
2. 前記ＵＢＰおよび前記出動可能都市ロケーションがロケーションサーバによって取得される、請求項１に記載の方法。
3. 前記ロケーションサーバが、拡張サービングモバイルロケーションセンター（Ｅ−ＳＭＬＣ）、緊急安全ロケーションユーザプレーン位置特定（ＳＵＰＬ）ロケーションプラットフォーム（Ｅ−ＳＬＰ）、またはスタンドアロンサービングモバイルロケーションセンター（ＳＡＳ）のうちの１つである、請求項２に記載の方法。
4. 前記ＵＢＰが、ＯＭＡ ＬＴＥ測位プロトコル拡張（ＬＰＰｅ）プロトコル、３ＧＰＰ ＬＴＥ測位プロトコル（ＬＰＰ）、ＬＴＥ用の３ＧＰＰ無線リソース制御（ＲＲＣ）プロトコル、ＵＭＴＳ用の３ＧＰＰ ＲＲＣプロトコル、３ＧＰＰ ＬＴＥ測位プロトコルＡ（ＬＰＰａ）プロトコル、もしくは３ＧＰＰ測位計算アプリケーションパート（ＰＣＡＰ）プロトコル、またはそれらの組合せを介して前記ユーザ機器から取得される、請求項３に記載の方法。
5. 前記出動可能都市ロケーションがプレゼンス情報データフォーマットロケーションオブジェクト（ＰＩＤＦ−ＬＯ）を備える、請求項１に記載の方法。
6. 前記ＰＩＤＦ−ＬＯが国家緊急アドレスデータベース（ＮＥＡＤ）から取得される、請求項５に記載の方法。
7. 前記ＵＢＰと前記出動可能都市ロケーションとを前記ＰＳＡＰに提供することが、
   ３ＧＰＰ Ｉｕｐｃ、Ｉｕ−ｃｓ、Ｉｕ−ｐｓ、ＳＬｓ、ＳＬｇ、Ｌｇ、Ｌｇｄ、もしくはＬ０インターフェース、またはそれらの組合せを介して、前記ＵＢＰと前記出動可能都市ロケーションとをゲートウェイに提供することと、
   ＨＴＴＰ対応ロケーション配信（ＨＥＬＤ）プロトコル、ＯＭＡモバイルロケーションプロトコル（ＭＬＰ）、もしくはＴＩＡ／ＡＴＩＳ Ｊ−ＳＴＤ−０３６ Ｅ２プロトコル、またはそれらの組合せを介して、少なくとも前記ＵＢＰを前記ゲートウェイから前記ＰＳＡＰに提供することと
   を備える、請求項１に記載の方法。
8. ユーザ機器（ＵＥ）と公共安全応答ポイント（ＰＳＡＰ）との間で非補償気圧を提供するためのゲートウェイであって、
   非補償気圧（ＵＢＰ）を含む出動可能都市ロケーションレコードを受信するように構成されたネットワークインターフェースと、
   前記出動可能都市ロケーションレコードから前記ＵＢＰを抽出するように構成されたプロセッサおよびメモリと、
   前記ＵＢＰを前記ＰＳＡＰに提供するようにさらに構成された前記ネットワークインターフェースと
   を備えるゲートウェイ。
9. 前記ネットワークインターフェースが、ＨＴＴＰ対応ロケーション配信（ＨＥＬＤ）プロトコル、ＯＭＡモバイルロケーションプロトコル（ＭＬＰ）、もしくはＴＩＡ／ＡＴＩＳ Ｊ−ＳＴＤ−０３６ Ｅ２プロトコル、またはそれらの組合せを介して前記ＵＢＰを前記ＰＳＡＰに提供するように構成される、請求項８に記載のゲートウェイ。
10. 前記ネットワークインターフェースが前記出動可能都市ロケーションレコードを前記ＰＳＡＰに提供するようにさらに構成される、請求項８に記載のゲートウェイ。
11. ユーザ機器（ＵＥ）に対する非補償気圧をゲートウェイに提供するためのロケーションサーバであって、
    前記ＵＥから非補償気圧（ＵＢＰ）を取得し、
    前記ＵＥに対する出動可能都市ロケーションを取得する
    ように構成されたネットワークインターフェースと、
    前記ＵＢＰを含む出動可能都市ロケーションレコードを生成するために、前記ＵＢＰを前記出動可能都市ロケーションと組み合わせるように構成されたプロセッサおよびメモリと、
    前記ＵＢＰを含む前記出動可能都市ロケーションレコードを前記ゲートウェイに提供するようにさらに構成された前記ネットワークインターフェースと
    を備えるロケーションサーバ。
12. 拡張サービングモバイルロケーションセンター（Ｅ−ＳＭＬＣ）、緊急安全ユーザプレーン位置特定（ＳＵＰＬ）ロケーションプラットフォーム（Ｅ−ＳＬＰ）、またはスタンドアロンサービングモバイルロケーションセンター（ＳＡＳ）のうちの１つを備える、請求項１１に記載のロケーションサーバ。
13. 前記ネットワークインターフェースが、３ＧＰＰ ＳＬｓ、ＳＬｇ、Ｌ０、Ｌｇ、Ｌｇｄ、Ｉｕｐｃ、Ｉｕ−ｃｓ、もしくはＩｕ−ｐｓインターフェース、またはそれらの組合せを介して、前記ＵＢＰを含む前記出動可能都市ロケーションレコードを前記ゲートウェイに提供するように構成される、請求項１１に記載のロケーションサーバ。
14. 前記プロセッサおよび前記メモリが、
    空き都市ロケーションレコードを生成し、
    前記空き都市ロケーションレコードと前記ＵＢＰとを組み合わせるように構成され、
    前記ネットワークインターフェースが、前記空き都市ロケーションレコードとＵＢＰとを前記ゲートウェイに提供するようにさらに構成される、
    請求項１１に記載のロケーションサーバ。
15. 前記ＵＢＰが、ＯＭＡ ＬＴＥ測位プロトコル拡張（ＬＰＰｅ）プロトコル、３ＧＰＰ ＬＴＥ測位プロトコル（ＬＰＰ）、ＬＴＥ用の３ＧＰＰ無線リソース制御（ＲＲＣ）プロトコル、ＵＭＴＳ用の３ＧＰＰ ＲＲＣプロトコル、３ＧＰＰ ＬＴＥ測位プロトコルＡ（ＬＰＰａ）プロトコル、もしくは３ＧＰＰ測位計算アプリケーションパート（ＰＣＡＰ）プロトコル、またはそれらの組合せを介して前記ＵＥから取得される、請求項１１に記載のロケーションサーバ。
16. ロングタームエボリューション（ＬＴＥ）アーキテクチャまたはユニバーサル移動体電気通信システム（ＵＭＴＳ）アーキテクチャにおいて、非補償気圧をユーザ機器（ＵＥ）からゲートウェイに提供するための方法であって、
    前記ＵＥから非補償気圧（ＵＢＰ）とロケーション情報とを取得することと、
    前記ロケーション情報に基づいて、前記ＵＥに対する出動可能都市ロケーションを取得することと、
    前記ＵＢＰを含む出動可能都市ロケーションレコードを生成するために、前記ＵＢＰを前記出動可能都市ロケーションと組み合わせることと、
    前記ＵＢＰを含む前記出動可能都市ロケーションレコードを前記ゲートウェイに提供することと
    を備える方法。
17. 前記ＵＢＰおよび前記出動可能都市ロケーションが、拡張サービングモバイルロケーションセンター（Ｅ−ＳＭＬＣ）、緊急安全ユーザプレーン位置特定（ＳＵＰＬ）ロケーションプラットフォーム（Ｅ−ＳＬＰ）、またはスタンドアロンサービングモバイルロケーションセンター（ＳＡＳ）のうちの１つにおいて取得される、請求項１６に記載の方法。
18. 前記ＵＢＰを含む前記出動可能都市ロケーションレコードを前記ゲートウェイに提供することが、
    ３ＧＰＰ ＳＬｓ、ＳＬｇ、Ｌ０、Ｌｇ、Ｌｇｄ、Ｉｕｐｃ、Ｉｕ−ｃｓ、もしくはＩｕ−ｐｓインターフェース、またはそれらの組合せを介して、前記ＵＢＰを含む前記出動可能都市ロケーションレコードを提供すること
    を備える、請求項１６に記載の方法。
19. 前記出動可能都市ロケーションを取得することが、空き都市ロケーションレコードを生成することを備える、請求項１６に記載の方法。
20. 前記空き都市ロケーションレコードと前記ＵＢＰとを組み合わせることと、
    ＵＢＰを含む前記空き都市ロケーションレコードを前記ゲートウェイに提供することと
    をさらに備える、請求項１９に記載の方法。
21. 前記ＵＢＰおよび前記ロケーション情報が、ＯＭＡ ＬＴＥ測位プロトコル拡張（ＬＰＰｅ）プロトコル、３ＧＰＰ ＬＴＥ測位プロトコル（ＬＰＰ）、ＬＴＥ用の３ＧＰＰ無線リソース制御（ＲＲＣ）プロトコル、ＵＭＴＳ用の３ＧＰＰ ＲＲＣプロトコル、３ＧＰＰ ＬＴＥ測位プロトコルＡ（ＬＰＰａ）プロトコル、もしくは３ＧＰＰ測位計算アプリケーションパート（ＰＣＡＰ）プロトコル、またはそれらの組合せを介して前記ＵＥから取得される、請求項１６に記載の方法。
22. 前記ゲートウェイが、前記ＵＢＰを含む前記出動可能都市ロケーションレコードを受信し、
    前記出動可能都市ロケーションレコードから前記ＵＢＰを抽出し、
    前記ＵＢＰを公共安全応答ポイント（ＰＳＡＰ）に提供する、
    請求項１６に記載の方法。
23. 前記ゲートウェイが、ＨＴＴＰ対応ロケーション配信（ＨＥＬＤ）プロトコル、ＯＭＡモバイルロケーションプロトコル（ＭＬＰ）、もしくはＴＩＡ／ＡＴＩＳ Ｊ−ＳＴＤ−０３６ Ｅ２プロトコル、またはそれらの組合せを介して前記ＵＢＰを前記ＰＳＡＰに提供する、請求項２２に記載の方法。
24. 前記ゲートウェイが、前記出動可能都市ロケーションレコードを前記ＰＳＡＰに提供する、請求項２２に記載の方法。

Images