JP6374110B2 - オーバーザトップサービスプロバイダのために位置特定と緊急呼とをサポートする方法 - Google Patents

オーバーザトップサービスプロバイダのために位置特定と緊急呼とをサポートする方法 Download PDF

Info

Publication number
JP6374110B2
JP6374110B2 JP2017527555A JP2017527555A JP6374110B2 JP 6374110 B2 JP6374110 B2 JP 6374110B2 JP 2017527555 A JP2017527555 A JP 2017527555A JP 2017527555 A JP2017527555 A JP 2017527555A JP 6374110 B2 JP6374110 B2 JP 6374110B2
Authority
JP
Japan
Prior art keywords
location
ott
message
ims
psap
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2017527555A
Other languages
English (en)
Other versions
JP2017536768A (ja
Inventor
エッジ、スティーブン・ウィリアム
ジェレンズ、ランドール・コールマン
ハティビ、ファロック
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Publication of JP2017536768A publication Critical patent/JP2017536768A/ja
Application granted granted Critical
Publication of JP6374110B2 publication Critical patent/JP6374110B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/023—Services making use of location information using mutual or relative location information between multiple location based services [LBS] targets or of distance thresholds
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/256—NAT traversal
    • H04L61/2564—NAT traversal for a higher-layer protocol, e.g. for session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4588—Network directories; Name-to-address mapping containing mobile subscriber information, e.g. home subscriber server [HSS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1045—Proxies, e.g. for session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/029—Location-based management or tracking services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/90—Services for handling of emergency or hazardous situations, e.g. earthquake and tsunami warning systems [ETWS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/18—Selecting a network or a communication service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W60/00—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
    • H04W60/02—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration by periodical registration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/50—Connection management for emergency connections

Description

関連出願の相互参照
[0001]本特許出願は、本出願の譲受人に譲渡され、その全体が参照により本明細書に明確に組み込まれる、２０１４年１１月２４日に出願された、「ＬＯＣＡＴＩＯＮ ＢＹ ＲＥＦＥＲＥＮＣＥ ＦＯＲ ＡＮ ＯＶＥＲ−ＴＨＥ−ＴＯＰ ＥＭＥＲＧＥＮＣＹ ＣＡＬＬ」と題される、米国仮出願第６２／０８３，７６８号、及び２０１５年１月９日に出願された、「ＬＯＣＡＴＩＯＮ ＴＲＡＮＳＦＥＲ ＡＬＴＥＲＮＡＴＩＶＥＳ ＴＯ ＡＮ ＯＶＥＲ−ＴＨＥ−ＴＯＰ ＳＥＲＶＩＣＥ ＰＲＯＶＩＤＥＲ」と題される、米国仮出願第６２／１０１，９７４号の利益を主張する。
[0002]本開示の実施形態は、オーバーザトップ（ＯＴＴ）サービスプロバイダ（ＳＰ）のための位置特定及び緊急呼に対するサポートを提供することに関する。
[0003]ワイヤレス通信システムは、第１世代アナログワイヤレス電話サービス（１Ｇ）、第２世代（２Ｇ）デジタルワイヤレス電話サービス（中間の２．５Ｇネットワークを含む）、並びに第３世代（３Ｇ）及び第４世代（４Ｇ）高速データ／インターネット対応ワイヤレスサービスを含む、様々な世代を通じて発展してきた。
[0004]４Ｇの進化の一部として、ロングタームエボリューション（ＬＴＥ（登録商標）：Long Term Evolution）が、携帯電話及び他のデータ端末向けの高速データのワイヤレス通信のための無線アクセスネットワーク技術として、第３世代パートナーシッププロジェクト（３ＧＰＰ（登録商標））によって開発されてきた。ＬＴＥは、Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（ＧＳＭ（登録商標））から、またＥｎｈａｎｃｅｄ Ｄａｔａ ｒａｔｅｓ ｆｏｒ ＧＳＭ Ｅｖｏｌｕｔｉｏｎ（ＥＤＧＥ）、ユニバーサルモバイルテレコミュニケーションズシステム（ＵＭＴＳ）、高速パケットアクセス（ＨＳＰＡ）などのＧＳＭの派生物から進化した。
[0005]北米では、ＧＳＭ、ＵＭＴＳ及びＬＴＥをサポートするワイヤレス通信システムなどの、パブリックネットワーク事業者によって利用されるワイヤレス通信システムは、緊急通報者と適切な公的機関をつなぐ、Ｅｎｈａｎｃｅｄ ９１１、即ちＥ９１１のための解決法を使用する。この解決法は、通報者、即ち通報者のユーザ機器（ＵＥ）を、物理的な住所又は地理的な座標などの特定の位置と自動的に関連付けることを試みる。高い精度（例えば、５０メートル以下の距離の誤差）で通報者を自動的に位置特定し、その位置を緊急応答機関（ＰＳＡＰ：Public Safety Answering Point）に与えることで、特に通報者が自身の位置を伝えることが不可能であり得る、又はその位置を知らない場合に、公安側が緊急事態の間に応答できる速度が向上し得る。加えて、緊急通報者の概略的な位置（例えば、通報者の機器がアクセスしている特定のネットワークセル）を知ることが、通報者の位置に対して正しいＰＳＡＰに緊急呼をルーティングすることに対して不可欠であり得る。
[0006]オーバーザトップ（ＯＴＴ）サービスプロバイダ（ＳＰ）として知られている幾つかの他のプロバイダは、必ずしもパブリックワイヤレスネットワークを所有若しくは運用することなく、又は仮想移動体通信事業者（ＭＶＮＯ）として働くことなく、音声とデータ関連のサービスとをワイヤレス機器のユーザに提供することもできる。ワイヤレス機器を持つユーザは次いで、幾つかの他のワイヤレスネットワークＳＰ、例えば、ＵＭＴＳ又はＬＴＥネットワークを有するＳＰを介して、及び場合によってはインターネットも介して、ＯＴＴ ＳＰリソース（例えば、１つ又は複数のサーバ）にアクセスし得る。アクセスは通常、（ホームワイヤレスネットワーク又はＭＶＮＯに対するアクセスとは異なり）サービングワイヤレスネットワークＳＰに対して透過的であり、通常はネットワーク及びＩＰプロトコルのレベルより上で行われることがあり、そのため「オーバーザトップ」という名称となっている。この場合、ＯＴＴ ＳＰは、音声とデータの呼（又はセッション）を行うための能力と、場合によっては緊急呼を行うための能力とを、ユーザに与えることがある。
[0007]しかしながら、ＯＴＴ ＳＰは、位置関連情報へのアクセスが限られていることと、位置特定に対応するリソースがないこととが原因で、緊急通報者の正確で信頼できる位置を取得することが、パブリックワイヤレスネットワーク事業者よりも困難であることがある。例えば、サービングワイヤレスネットワークは、ワイヤレス通報者のセル関連情報（例えば、ワイヤレス通報者のサービングセルＩＤ）へのアクセス権を有することがあり、ワイヤレス通報者の正確な位置を取得するために使用され得るネットワークインフラストラクチャ（例えば、ワイヤレス通報者の機器からの信号を測定でき、そのような測定結果を位置推定へと変換するために自身の信号がワイヤレス通報者の機器及び位置サーバによって測定され得る、基地局）を有することがあるが、ＯＴＴ ＳＰは、このインフラストラクチャ又は情報を殆んど、又は全く有しないことがある。このことは、ＯＴＴ ＳＰが、ワイヤレス通報者からの緊急呼を正しいＰＳＡＰにルーティングすること、及び／又は、ワイヤレス通報者の正確な位置をＰＳＡＰに提供するのを妨げることがあり、このことは、信頼できる緊急サービスをＯＴＴ ＳＰが提供するのを妨げることがある。加えて、例えば、ＯＴＴ ＳＰが宛先ＰＳＡＰへの必要な接続を欠いている場合、又は緊急呼を転送するための、若しくは通報者の位置を提供するための権限がない場合、ＯＴＴ ＳＰは、そのＰＳＡＰが知られ得るときであっても緊急呼をそのＰＳＡＰに転送するための通信手段を常に有するとは限らず、又は通報者の位置に対するＰＳＡＰからの質問（query）に常に応答するとは限らない。従って、ＯＴＴ ＳＰに対する位置特定及び緊急サービス呼のサポートを改善することには、利益があり得る。
[0008]以下は、オーバーザトップ（ＯＴＴ）サービスプロバイダに位置移送の代替形態を提供するための、本明細書で開示される機構と関連付けられる１つ又は複数の態様及び／又は実施形態に関する、簡略化された概要を提示する。従って、以下の概要は、全ての企図された態様及び／又は実施形態に関する広範な概要と見なされるべきではなく、また、以下の概要は、全ての企図された態様及び／又は実施形態に関する重要な、又は決定的な要素を識別するか、若しくは特定の態様及び／又は実施形態と関連付けられる範囲を定めるものと見なされるべきではない。従って、以下の概要の唯一の目的は、以下で提示される発明を実施するための形態に先行して、簡略化された形で本明細書において開示される機構に関する１つ又は複数の態様及び／又は実施形態に関する幾つかの概念を提示することである。
[0009]ＯＴＴサービスプロバイダのための位置特定と緊急呼とをサポートするための方法及び装置が開示される。ＯＴＴサービスプロバイダにおいて緊急呼をサポートする方法は、ユーザ機器（ＵＥ）から緊急呼要求を備える第１のメッセージを受信することと、ここにおいて、第１のメッセージがＵＥのサービングモバイルネットワーク事業者（ＭＮＯ）を介してＯＴＴサービスプロバイダに移送され、第１のメッセージがサービングＭＮＯのインターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）のアドレスを含む、このアドレスに基づいて第２のメッセージをＩＭＳに送信することと、ここにおいて、第２のメッセージが緊急呼に対する要求を備える、を含む。
[0010]サービングＭＮＯのＩＭＳエンティティにおいて緊急呼をサポートする方法は、ＵＥに対する緊急呼要求を備える、ＯＴＴサービスプロバイダによって送信される第１のメッセージを受信することと、ここにおいて、緊急呼要求がＵＥのためのＭＮＯデータを含む、このＭＮＯデータに基づいて宛先緊急応答機関（ＰＳＡＰ）のためのルーティング情報を決定することとを含む。
[0011]ＵＥにおいて緊急呼をサポートする方法は、ＵＥのユーザから緊急呼に対する要求を受信することと、ＵＥのサービングＭＮＯのためのＭＮＯデータを取得することと、緊急呼に対する要求を備える第１のメッセージをＯＴＴサービスプロバイダに送信することとを含み、緊急呼に対する要求はＭＮＯデータを含む。
[0012]ＯＴＴサービスプロバイダにおいて緊急呼をサポートするための装置は、少なくとも１つのプロセッサと送受信機とを含み、送受信機は、ＵＥから緊急呼要求を備える第１のメッセージを受信し、ここにおいて、第１のメッセージがＵＥのサービングＭＮＯを介してＯＴＴサービスプロバイダに移送され、第１のメッセージがサービングＭＮＯのＩＭＳのアドレスを含む、このアドレスに基づいて第２のメッセージをＩＭＳに送信し、ここにおいて、第２のメッセージが緊急呼に対する要求を備える、ように構成される。
[0013]サービングＭＮＯのＩＭＳエンティティにおいて緊急呼をサポートするための装置は、少なくとも１つのプロセッサと送受信機とを含み、送受信機は、ＵＥに対する緊急呼要求を備える、ＯＴＴサービスプロバイダによって送信される第１のメッセージを受信するように構成され、緊急呼要求はＵＥのためのＭＮＯデータを含み、少なくとも１つのプロセッサは、このＭＮＯデータに基づいて宛先ＰＳＡＰのためのルーティング情報を決定するように構成される。
[0014]ＵＥにおいて緊急呼をサポートするための装置は、少なくとも１つのプロセッサと送受信機とを含み、送受信機は、ＵＥのユーザから緊急呼に対する要求を受信し、ＵＥのサービングＭＮＯのためのＭＮＯデータを取得し、緊急呼に対する要求を備える第１のメッセージをＯＴＴサービスプロバイダに送信するように構成され、緊急呼に対する要求はＭＮＯデータを含む。
[0015]ＯＴＴサービスプロバイダにおいて緊急呼をサポートするための装置は、ＵＥから緊急呼要求を備える第１のメッセージを受信するための手段と、ここにおいて、第１のメッセージがＵＥのサービングＭＮＯを介してＯＴＴサービスプロバイダに移送され、第１のメッセージがサービングＭＮＯのＩＭＳのアドレスを含む、このアドレスに基づいて第２のメッセージをＩＭＳに送信するための手段と、ここにおいて、第２のメッセージが緊急呼に対する要求を備える、を含む。
[0016]サービングＭＮＯのＩＭＳエンティティにおいて緊急呼をサポートするための装置は、ＵＥに対する緊急呼要求を備える、ＯＴＴサービスプロバイダによって送信される第１のメッセージを受信するための手段と、ここにおいて、緊急呼要求がＵＥのためのＭＮＯデータを含む、このＭＮＯデータに基づいて宛先ＰＳＡＰのためのルーティング情報を決定するための手段とを含む。
[0017]ＵＥにおいて緊急呼をサポートするための装置は、ＵＥのユーザから緊急呼に対する要求を受信するための手段と、ＵＥのサービングＭＮＯのためのＭＮＯデータを取得するための手段と、緊急呼に対する要求を備える第１のメッセージをＯＴＴサービスプロバイダに送信するための手段とを含み、緊急呼に対する要求はＭＮＯデータを含む。
[0018]ＯＴＴサービスプロバイダにおいて緊急呼をサポートするための非一時的コンピュータ可読媒体は、ＵＥから緊急呼要求を備える第１のメッセージを受信するための少なくとも１つの命令と、ここにおいて、第１のメッセージがＵＥのサービングＭＮＯを介してＯＴＴサービスプロバイダに移送され、第１のメッセージがサービングＭＮＯのＩＭＳのアドレスを含む、このアドレスに基づいて第２のメッセージをＩＭＳに送信するための少なくとも１つの命令と、ここにおいて、第２のメッセージが緊急呼に対する要求を備える、を含む。
[0019]サービングＭＮＯのＩＭＳエンティティにおいて緊急呼をサポートするための非一時的コンピュータ可読媒体は、ＵＥのための緊急呼要求を備える、ＯＴＴサービスプロバイダによって送信される第１のメッセージを受信するための少なくとも１つの命令と、ここにおいて、緊急呼要求がＵＥのためのＭＮＯデータを含む、このＭＮＯデータに基づいて宛先ＰＳＡＰのためのルーティング情報を決定するための少なくとも１つの命令とを含む。
[0020]ＵＥにおいて緊急呼をサポートするための非一時的コンピュータ可読媒体は、ＵＥのユーザから緊急呼に対する要求を受信するための少なくとも１つの命令と、ＵＥのサービングＭＮＯのためのＭＮＯデータを取得するための少なくとも１つの命令と、緊急呼に対する要求を備える第１のメッセージをＯＴＴサービスプロバイダに送信するための少なくとも１つの命令とを含み、緊急呼に対する要求はＭＮＯデータを含む。
[0021]本明細書で開示される機構と関連付けられる他の目的及び利点は、添付の図面及び詳細な説明に基づいて当業者には明らかであろう。
[0022]本開示の実施形態とその付随する利点の多くのより完全な諒解は、本開示を限定するためではなく単に例示するために提示される添付の図面に関連して考察されるときに、以下の詳細な説明を参照することでよりよく理解されれば、容易に得られるであろう。
[0023]本開示の少なくとも一態様による、ワイヤレス通信システムのハイレベルシステムアーキテクチャを示す図。 [0024]本開示の少なくとも一態様による、ロングタームエボリューション（ＬＴＥ）ワイヤレスアクセスのための図１Ａにおけるシステムアーキテクチャの例示的な構成を示す図。 [0025]本開示の少なくとも一態様による、基準による位置を提供するための図１Ａに示されるネットワークエンティティの具体的な対話を示す図。 [0026]本開示の少なくとも一態様による、基準による位置を提供するための図１Ｂに示されるネットワークエンティティの具体的な対話を示す図。 [0027]本開示の少なくとも一態様による、緊急サービスを提供するための例示的なアーキテクチャを示す図。 [0028]本開示の少なくとも一態様による、基準による位置特定のサポートのための例示的なアーキテクチャを示す図。 [0029]本開示の少なくとも一態様による、緊急サービスに対するインターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）サポートのための例示的なアーキテクチャを示す図。 [0030]本開示の少なくとも一態様による、緊急サービスに対するＩＭＳサポートのための別の例示的なアーキテクチャを示す図。 [0031]本開示の少なくとも一態様による、値による位置特定及び基準による位置特定のための例示的な呼フローを示す図。 [0032]本開示の少なくとも一態様による、緊急呼のＩＭＳサポートのための更なる例示的な呼フローを示す図。 [0033]本開示の少なくとも一態様による、緊急呼のＩＭＳサポートのための別の例示的な呼フローを示す図。 [0034]本明細書で教示されるような通信をサポートするように構成される構成要素の幾つかの例示的な態様の簡略化されたブロック図。 [0035]本開示の少なくとも一態様による、ユーザ機器（ＵＥ）の例を示す図。 [0036]本明細書で説明される機能を実行するための構造的な構成要素を含む通信機器を示す図。 [0037]本開示のある実施形態による、サーバを示す図。 [0038]本開示の様々な態様による、ＵＥを位置特定するための例示的なフローを示す図。 本開示の様々な態様による、ＵＥを位置特定するための例示的なフローを示す図。 本開示の様々な態様による、ＵＥを位置特定するための例示的なフローを示す図。 本開示の様々な態様による、ＵＥを位置特定するための例示的なフローを示す図。 本開示の様々な態様による、ＵＥを位置特定するための例示的なフローを示す図。 本開示の様々な態様による、ＵＥを位置特定するための例示的なフローを示す図。 本開示の様々な態様による、ＵＥを位置特定するための例示的なフローを示す図。 [0039]本明細書で教示されるような通信をサポートするように構成される装置の幾つかの例示的な態様の他の簡略化されたブロック図。 本明細書で教示されるような通信をサポートするように構成される装置の幾つかの例示的な態様の他の簡略化されたブロック図。 本明細書で教示されるような通信をサポートするように構成される装置の幾つかの例示的な態様の他の簡略化されたブロック図。 本明細書で教示されるような通信をサポートするように構成される装置の幾つかの例示的な態様の他の簡略化されたブロック図。 本明細書で教示されるような通信をサポートするように構成される装置の幾つかの例示的な態様の他の簡略化されたブロック図。 本明細書で教示されるような通信をサポートするように構成される装置の幾つかの例示的な態様の他の簡略化されたブロック図。 本明細書で教示されるような通信をサポートするように構成される装置の幾つかの例示的な態様の他の簡略化されたブロック図。
[0040]図２Ａ、図２Ｂ、図７、図８及び図９に示されるメッセージ及び呼フローでは、動作又はステップと本明細書で呼ばれることがある個々のメッセージ及び活動が、数字のラベルによって示されることに留意されたい。
[0041]オーバーザトップ（ＯＴＴ）サービスプロバイダのための位置特定と緊急呼とをサポートするための方法及び装置が開示される。ユーザ機器（ＵＥ）は、緊急呼に対する要求をＯＴＴサービスプロバイダに送信することができ、ＵＥのサービングモバイルネットワーク事業者（ＭＮＯ）のためのＭＮＯデータを要求に含めることができる。ＭＮＯデータは、サービングＭＮＯのＩＰマルチメディアサブシステム（ＩＭＳ）のアドレスを含み得る。ＯＴＴサービスプロバイダは、緊急呼要求をＩＭＳに転送することができる。ＩＭＳは、ＯＴＴサービスプロバイダが緊急呼を緊急応答機関（ＰＳＡＰ）にルーティングすることを可能にするために、緊急呼のためのルーティング情報を決定し、ルーティング情報をＯＴＴサービスプロバイダに返すことができ、又は、緊急呼自体をＰＳＡＰにルーティングすることができる。ＩＭＳによって、又はＯＴＴサービスプロバイダによってルーティングされる呼要求は、ＰＳＡＰがＩＭＳからＵＥの位置を取得することを可能にし得る参照識別子を含み得る。
[0042]本開示のこれらの態様及び他の態様が、本開示の具体的な実施形態を対象とする以下の説明及び関連する図面において開示される。本開示の範囲から逸脱することなく、代替的な実施形態が考案され得る。加えて、本開示の関連する詳細を不明瞭にしないように、本開示のよく知られている要素は詳細に説明されず、又は省略される。
[0043]「例示的」及び／又は「例」という単語は、本明細書では「例、事例又は例示として機能すること」を意味するために使用される。本明細書で「例示的」及び／又は「例」として説明されるいかなる実施形態も、必ずしも他の実施形態よりも好ましい又は有利であると解釈されるべきであるとは限らない。同様に、「本開示の実施形態」という用語は、本開示の全ての実施形態が、説明される特徴、利点又は動作モードを含むことを必要としない。
[0044]更に、多くの実施形態が、例えば、コンピュータ機器の要素によって実行されるべき一連の活動に関して説明される。本明細書で説明される様々な活動は、特定の回路（例えば、特定用途向け集積回路（ＡＳＩＣ））によって、１つ以上のプロセッサによって実行されるプログラム命令によって、又は両方の組合せによって実行され得ることが認識されるだろう。更に、本明細書で説明されるこれらの一連の活動は、実行されると、本明細書で説明される機能を関連するプロセッサに実行させるであろう、コンピュータ命令の対応するセットを記憶した任意の形態のコンピュータ可読記憶媒体内で全体として具現化されるべきものと見なされ得る。従って、本開示の様々な態様は、全てが請求される主題の範囲内に入ることが企図されている幾つかの異なる形態で具現化され得る。更に、本明細書で説明された実施形態の各々について、任意のそのような実施形態の対応する形態が、本明細書では、例えば、説明される活動を実行する「ように構成された論理」として説明されることがある。
[0045]表１は、本開示で使用される用語及び省略形の用語集を与える。
Figure 0006374110
Figure 0006374110
Figure 0006374110
[0046]本明細書でユーザ機器（ＵＥ）と呼ばれるクライアント機器は、移動式又は固定式であってよく、無線アクセスネットワーク（ＲＡＮ）と通信し得る。本明細書では、「ＵＥ」という用語は、交換可能に、「アクセス端末」又は「ＡＴ」、「ワイヤレス機器」、「ワイヤレス端末」、「加入者機器」、「加入者端末」、「加入者局」、「ユーザ端末」又は「ＵＴ」、「モバイル端末」、「移動局」、「端末」、「機器」、「ユーザ機器」及びそれらの変形として呼ばれることがある。一般に、ＵＥは、ＲＡＮを介してコアネットワークと通信することができ、コアネットワークを通じて、ＵＥは、インターネットなどの外部ネットワークと接続され得る。もちろん、有線アクセスネットワーク、（例えば、ＩＥＥＥ８０２．１１などに基づく）ＷｉＦｉ（登録商標）ネットワークなどを通じたものなどの、コアネットワーク及び／又はインターネットに接続する他の機構もＵＥに対して可能である。ＵＥは、限定はされないが、ＰＣカード、コンパクトフラッシュ（登録商標）機器、外部又は内部モデム、ワイヤレス電話又は有線電話、スマートフォン、タブレットコンピュータ、ラップトップコンピュータなどを含む、幾つかのタイプの機器のいずれかによって具現化され得る。ＵＥがそれを通じてＲＡＮに信号を送ることができる通信リンクは、アップリンクチャネル（例えば、逆方向トラフィックチャネル、逆方向制御チャネル、アクセスチャネルなど）と呼ばれる。ＲＡＮがそれを通じてＵＥに信号を送ることができる通信リンクは、ダウンリンク又は順方向リンクチャネル（例えば、ページングチャネル、制御チャネル、ブロードキャストチャネル、順方向トラフィックチャネルなど）と呼ばれる。本明細書では、トラフィックチャネル（ＴＣＨ）という用語は、アップリンク／逆方向トラフィックチャネル又はダウンリンク／順方向トラフィックチャネルのいずれかを指し得る。
[0047]図１Ａは、本開示のある実施形態による、ワイヤレス通信システム１００Ａのハイレベルシステムアーキテクチャを示す。ワイヤレス通信システム１００Ａは、１．．．Ｎと標識されたある数Ｎ個のＵＥを含む。ＵＥ１．．．Ｎは、携帯電話、携帯情報端末（ＰＤＡ）、ページャ、ラップトップコンピュータ、デスクトップコンピュータなどを含み得る。例えば、図１Ａでは、ＵＥ１．．．２は、発呼する携帯電話として示されており、ＵＥ３．．．５はタッチスクリーン式携帯電話又はスマートフォンとして示されており、ＵＥ Ｎはデスクトップコンピュータ又はＰＣとして示されている。
[0048]図１Ａを参照すると、ＵＥ１．．．Ｎは、エアインターフェース１０４、１０６、１０８として図１Ａに示された物理通信インターフェース若しくはレイヤを通じて、及び／又は、直接有線接続１０２を通じて、アクセスネットワーク（例えば、ＲＡＮ１２０、アクセスポイント１２５など）と通信するように構成される。エアインターフェース１０４及び１０６は、所与のセルラー通信プロトコル（例えば、符号分割多元接続（ＣＤＭＡ）、Ｅｖｏｌｕｔｉｏｎ−Ｄａｔａ Ｏｐｔｉｍｉｚｅｄ（ＥＶＤＯ）、Ｅｎｈａｎｃｅｄ Ｈｉｇｈ Ｒａｔｅ Ｐａｃｋｅｔ Ｄａｔａ（ｅＨＲＰＤ）、Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（ＧＳＭ）、Ｅｎｈａｎｃｅｄ Ｄａｔａ Ｒａｔｅｓ ｆｏｒ ＧＳＭ Ｅｖｏｌｕｔｉｏｎ（ＥＤＧＥ）、Ｗｉｄｅｂａｎｄ ＣＤＭＡ（ＷＣＤＭＡ（登録商標））、Ｌｏｎｇ−Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ（ＬＴＥ）など）に適合してよく、一方、エアインターフェース１０８は、ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）プロトコル（例えば、ＩＥＥＥ ８０２．１１、Ｂｌｕｅｔｏｏｔｈ（登録商標）など）に適合してよい。以下で更に説明されるように、ＲＡＮ１２０は、エアインターフェース１０４及び１０６などのエアインターフェースを通じてＵＥにサービスする複数のアクセスポイントを含む。ＲＡＮ１２０中のアクセスポイントは、アクセスノード（ＡＮ）、アクセスポイント（ＡＰ）、基地局（ＢＳ）、Ｎｏｄｅ Ｂ、ｅｖｏｌｖｅｄ Ｎｏｄｅ Ｂ（ｅＮｏｄｅＢ）などと呼ばれることがある。これらのアクセスポイントは、地上アクセスポイント（又は地上局）又は衛星アクセスポイントであり得る。ＲＡＮ１２０は、ＲＡＮ１２０によってサービスされるＵＥと、ＲＡＮ１２０若しくは異なるＲＡＮ若しくは異なる（非ＲＡＮ）ネットワークによってサービスされる他のＵＥ又は他の非ＵＥエンティティとの間の、回線交換（ＣＳ）呼を一緒にルーティングして接続することを含む様々な機能を実行することができ、また、インターネット１７５などの外部ネットワークを介して他のエンティティとのパケット交換（ＰＳ）データの交換を仲介することができる、パケットコアネットワーク（ＰＣＮ）又は進化型パケットコア（ＥＰＣ）とも呼ばれることがあるコアネットワーク（ＣＮ）１４０に接続するように構成される。ＲＡＮ１２０とＣＮ１４０は、ＵＥ１からＮの１つ又は複数のサービングワイヤレスネットワークとして活動し得る。本明細書のワイヤレスネットワークという用語は、ワイヤレスネットワークとワイヤレスネットワーク内のインフラストラクチャと（例えば、ＲＡＮ１２０及びＣＮ１４０）を指すために、モバイルネットワーク事業者（ＭＮＯ）という用語と交換可能に使用される。
[0049]インターネット１７５は、（便宜上図１Ａには示されていない）幾つかのルーティングエージェントと処理エージェントとを含む。図１Ａでは、ＵＥ Ｎは、インターネット１７５に直接接続するものとして（即ち、ＤＳＬ又はパケットケーブルＳＰなどを介してコアネットワーク１４０とは別に、及びある例では（例えば、ＷｉＦｉルータについて）これはアクセスポイント１２５自体を介するものであり得る）示されている。こうして、インターネット１７５は、インターネット１７５に（例えば、コアネットワーク１４０を介して）アクセスするＵＥ Ｎと他のＵＥとの間のパケット交換データ通信をルーティングするように機能することができる。
[0050]ＲＡＮ１２０とは別個のアクセスポイント１２５も図１Ａに示されている。アクセスポイント１２５は、コアネットワーク（ＣＮ）１４０とは独立に（例えば、ＦｉＯＳなどの光通信システム、ケーブルモデムなどを介して）インターネット１７５に接続され得る。エアインターフェース１０８は、ある例ではＩＥＥＥ８０２．１１又はＢｌｕｅｔｏｏｔｈなどの、ローカルワイヤレス接続を通じてＵＥ４又はＵＥ５にサービスし得る。
[0051]図１Ａを参照すると、位置サーバ１７０が、インターネット１７５、ＣＮ１４０又は両方に接続されるものとして示されている。位置サーバ１７０は、複数の構造的に別個のサーバとして実装されることがあり、又は代替的に、単一のサーバに対応することがある。以下でより詳細に説明されるように、位置サーバ１７０は、位置サーバ１７０にＣＮ１４０及び／又はインターネット１７５を介して接続できるＵＥのための１つ又は複数の位置特定サービス（例えば、測位サービス、基準による測位サービスなど）をサポートするように構成される。
[0052]図１Ａは更に、オーバーザトップ（ＯＴＴ）サービスプロバイダ（ＳＰ）１５０を示す。ＯＴＴ ＳＰは、インターネット１７５を通じて、及び場合によってはＲＡＮ１２０とＣＮ１４０とを通じて、インターネット１７５、ＲＡＮ１２０、及びＣＮ１４０に対して部分的に、又は完全に透過的な方式で、ＵＥ１からＮの１つ以上へ、及び／又はそれらから、オーディオ、ビデオ、及び／又は他のメディアコンテンツを移送することができる。ＯＴＴ ＳＰは通常、Ｓｋｙｐｅ（商標）、Ｈｕｌｕ、Ｎｅｔｆｌｉｘ、Ｇｏｏｇｌｅなどのサードパーティのプロバイダを指す。ＯＴＴ ＳＰ１５０は、インターネット１７５、ＣＮ１４０、ＲＡＮ１２０、及び／又はアクセスポイント１２５を通じて、ＵＥ１．．．Ｎと通信し得る。単一のＯＴＴ ＳＰ１５０だけが図１Ａに示されているが、明らかなように、異なるＯＴＴ ＳＰに各々対応する、インターネット１７５に接続される任意の数のＯＴＴ ＳＰ１５０があり得る。ＯＴＴ ＳＰ１５０は、ＯＴＴ ＳＰ１５０のために本明細書で説明される様々な機能を実行し得る、１つ又は複数のサーバ、ルーティングプロキシ及び／又は他のエンティティ（図１Ａには示されない）を有し得る。同じことが、ＯＴＴ ＳＰ３５０、４５０、５５０、６５０、７５０、８５０及び９５０などの、本明細書において後で参照される他のＯＴＴ ＳＰに当てはまり得る。
[0053]緊急サービスＩＰネットワーク（ＥＳＩｎｅｔ）及び／又は選択的ルータ（ＳＲ）１６０も、図１Ａに示されている。ＥＳＩｎｅｔ１６０は、ＵＥ１からＮのいずれかによって行われ、インターネット１７５を介して受信される、ＣＮ１４０又はＯＴＴ ＳＰ１５０から緊急応答機関（ＰＳＡＰ）１８０などの適切なＰＳＡＰへの、ＩＰベースの緊急呼をルーティングすることが可能であり得る。同様に、ＳＲ１６０は、ＵＥ１からＮのいずれかによって行われ、ＣＮ１４０を介して受信される、ＰＳＡＰ１８０などのＰＳＡＰへの回線交換（ＣＳ）緊急呼をルーティングすることが可能であり得る。幾つかの実施形態では、ＵＥ１からＮのいずれかがＩＰベースの緊急呼を発信することがあり、これは、ＣＮ１４０又はＯＴＴ ＳＰ１５０によってＣＳ緊急呼へと変換され、ＣＳ対応ＰＳＡＰ１８０へのルーティングのために（例えば、図１Ａには示されない公衆交換電話網を介して）ＳＲ１６０に送信され得る。これは、ＳＲ１６０はあるがＥＳＩｎｅｔ１６０がないとき、及び／又は、ＰＳＡＰ１８０がＣＳ緊急呼をサポートするがＩＰベースの緊急呼をサポートしないときに、起こり得る。本明細書のより後におけるＯＴＴ ＳＰ１５０を介した緊急呼の確立の説明では、緊急呼はＵＥ（例えば、ＵＥ１からＮのいずれか）からのＩＰベースの緊急呼として開始し得るが、ＯＴＴ ＳＰ１５０によってＣＳ緊急呼に変換され、ＥＳＩｎｅｔ１６０ではなくＳＲ１６０を介してＰＳＡＰ１８０にルーティングされ得ることを理解されたい。
[0054]図１ＡのＵＥ１．．．Ｎは、インターネット１７５を介して、音声の、テキストの、ビデオの、又は他のデータの緊急呼を行うことが可能であり得る。例えば、ＵＥ１．．．Ｎは、以下で更に説明されるように、ＯＴＴ ＳＰ１５０を介してそのような緊急呼を行うことが可能であり得る。ＥＳＩｎｅｔ／ＳＲ１６０は、これらの音声の、テキストの、ビデオの、及びデータの緊急呼を、例えば緊急呼センターであり得るＰＳＡＰ１８０に配信することができる。これらの緊急呼を配信するために使用されるプロトコルは、インターネットエンジニアリングタスクフォース（ＩＥＴＦ：Internet Engineering Task Force）によって定義されるセッション開始プロトコル（ＳＩＰ）であり得る。加えて、ＳＩＰベースの緊急呼は、ＳＩＰの使用をサポートしＣＮ１４０によってサポートされ得る、３ＧＰＰによって定義されるＩＰマルチメディアサブシステム（ＩＭＳ）を使用して配信され得る。
[0055]ＲＡＮ１２０によりＬＴＥアクセスがサポートされる場合にワイヤレス通信システム１００Ａをより詳細に説明するのを助けるために、ＲＡＮ１２０及びＣＮ１４０のためのプロトコル特有の実装の例が、図１Ｂに関して以下で与えられている。特に、ＲＡＮ１２０及びＣＮ１４０の構成要素は、パケット交換（ＰＳ）通信をサポートすることと関連付けられる構成要素に対応し、それにより、レガシー回線交換（ＣＳ）構成要素もこれらのネットワーク中に存在し得るが、図１Ｂには明示的に示されていない。
[0056]具体的には、図１Ｂは、本開示のある実施形態による、ＬＴＥワイヤレスアクセスをサポートするＥｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｓｙｓｔｅｍ（ＥＰＳ）に基づくＲＡＮ１２０及びＣＮ１４０の例示的な構成１００Ｂを示す。図１Ｂの例では、ＥＰＳ／ＬＴＥネットワーク中のＲＡＮ１２０は、複数のＥｖｏｌｖｅｄ Ｎｏｄｅ Ｂ（ｅＮｏｄｅＢ又はｅＮＢ）１２２、１２４及び１２６を用いて構成される。ＣＮ１４０は、複数のモビリティ管理エンティティ（ＭＭＥ）１４２及び１４４と、改良サービングモバイルロケーションセンター（Ｅ−ＳＭＬＣ）１７２と、サービングゲートウェイ（Ｓ−ＧＷ）１４６と、パケットデータネットワークゲートウェイ（ＰＤＧ）１４８とを含む。図１Ｂの例では、位置サーバ１７０は、ＬＴＥ制御プレーン位置特定解決法をサポートするゲートウェイモバイルロケーションセンター（ＧＭＬＣ）と、オープンモバイルアライアンス（ＯＭＡ）によって定義されるＳＵＰＬ位置特定解決法をサポートするセキュアユーザプレーン位置特定（ＳＵＰＬ）位置特定プラットフォーム（ＳＬＰ）１７０とのいずれかである。幾つかの実施形態では、位置サーバ１７０は、ＧＭＬＣ及び／又はＳＬＰへの接続又はそれらとの関連付けを有する、位置検索機能（ＬＲＦ）であり得る。これらの構成要素と、ＲＡＮ１２０及びインターネット１７５との間のネットワークインターフェースが図１Ｂに示されており、表２において定義される。
Figure 0006374110
[0057]次に、図１ＢのＲＡＮ１２０及びＣＮ１４０の中に示された構成要素のハイレベルな説明がここで行われる。しかしながら、これらの構成要素の幾つかは、様々な３ＧＰＰ技術仕様（ＴＳ）から当技術分野でよく知られており、本明細書に含まれている説明は、これらの構成要素によって実行される全ての機能の網羅的な説明であることは意図されていない。
[0058]図１Ｂを参照すると、ＭＭＥ１４２及び１４４は、ＥＰＳベアラのための制御プレーン信号伝達を管理し、ＣＮ１４０にアクセスするＵＥのモビリティをサポートするように構成される。ＭＭＥ機能は、非アクセス層（ＮＡＳ）信号伝達と、ＮＡＳ信号伝達セキュリティと、技術間及び技術内ハンドオーバーのためのモビリティ管理と、ＰＤＧ及びＳ−ＧＷの選択と、ＭＭＥ変更を伴うハンドオーバーのためのＭＭＥの選択とを含む。
[0059]Ｓ−ＧＷ１４６は、ユーザプレーン信号伝達のためのＲＡＮ１２０に向かうインターフェースを終端するゲートウェイである。ＥＰＳベースのシステムのためのＣＮ１４０に接続される各ＵＥについて、所与の時点おいて、単一のＳ−ＧＷがある。Ｓ−ＧＷ１４６の機能は、プロキシモバイルＩＰｖ６（ＰＭＩＰ：Proxy Mobile IPv6）ベースのＳ５／Ｓ８に対して、モビリティアンカーポイントと、パケットのルーティング及び転送と、関連するＥＰＳベアラのＱｏＳクラス識別子（ＱＣＩ：QoS Class Identifier）に基づいてＤｉｆｆＳｅｒｖコードポイント（ＤＳＣＰ：DiffServ Code Point）を設定することとを含む。
[0060]図１Ｂを参照すると、ＰＤＧ１４８は、パケットデータネットワーク（ＰＤＮ）、例えば、インターネット１７５に向かうＳＧｉインターフェースを終端するゲートウェイである。ＵＥが複数のＰＤＮにアクセスしている場合、そのＵＥに対しては２つ以上のＰＤＧがあり得る。ＰＤＧ１４８の機能は、（ディープパケットインスペクションによる）パケットフィルタリングと、ＵＥ ＩＰアドレス割振りと、関連するＥＰＳベアラのＱＣＩに基づくＤＳＣＰの設定と、事業者間の課金の考慮と、３ＧＰＰ ＴＳ２３．２０３において定義されるようなアップリンク（ＵＬ）及びダウンリンク（ＤＬ）ベアラのバインディングと、３ＧＰＰ ＴＳ２３．２０３において定義されるようなＵＬベアラのバインディングの検証とを含む。ＰＤＧ１４８は、ＧＳＭ／ＥＤＧＥ無線アクセスネットワーク（ＧＥＲＡＮ）／ＵＴＲＡＮ専用ＵＥと、Ｅ−ＵＴＲＡＮ、ＧＥＲＡＮ、又はＵＴＲＡＮのいずれかであり得るＲＡＮ１２０を使用するＬＴＥ対応ＵＥとの両方にＰＤＮ接続性を与える。ＰＤＧ１４８は、Ｓ５／Ｓ８インターフェースを通じた、図１Ｂに示されるものなどのｅＮＢを備えるＲＡＮ１２０（これはＥ−ＵＴＲＡＮと呼ばれる）を使用して、ＬＴＥ対応ＵＥにＰＤＮ接続性を与える。
[0061]図１Ｂを参照すると、ＧＭＬＣ／ＳＬＰ１７０は、ＭＭＥ１４２に、ＣＮ１４０の中のＰＤＧ１４８に、及び／又はインターネット１７５に接続されるものとして示されている。ＧＭＬＣ／ＳＬＰ１７０は、ＧＭＬＣとＳＬＰのいずれかであることがあり、又は、ＧＭＬＣ若しくはＳＬＰへの接続、若しくはそれらとの関連付けを有するＬＲＦであることがある。ＧＭＬＣ１７０（又は関連する、若しくは接続されるＧＭＬＣを有するＬＲＦ１７０）はＬＴＥ制御プレーン位置特定解決法をサポートするが、ＳＬＰ１７０（又は関連する、若しくは接続されるＳＬＰを有するＬＲＦ１７０）はＳＵＰＬ位置特定解決法をサポートする。ＧＭＬＣ／ＳＬＰ１７０がＧＭＬＣであるがＳＬＰではない場合、ＧＭＬＣ／ＳＬＰ１７０は、ＭＭＥ１４２に、及びＰＤＧ１４８とインターネット１７５の一方又は両方に接続することがある。ＧＭＬＣ／ＳＬＰ１７０がＳＬＰであるがＧＭＬＣではない場合、ＧＭＬＣ／ＳＬＰ１７０は、ＭＭＥ１４２に接続することもしないこともあり、ＰＤＧ１４８とインターネット１７５の一方又は両方に接続することがある。ＧＭＬＣ／ＳＬＰ１７０は、ＯＴＴ ＳＰ１５０、ＥＳＩｎｅｔ１６０又はＰＳＡＰ１８０などの外部エンティティが、図１ＡのＵＥ１からＮのいずれかに対する位置要求をＧＭＬＣ／ＳＬＰ１７０に送信することを可能にでき、ＧＭＬＣの場合には３ＧＰＰ制御プレーン位置特定解決法を、又はＳＬＰの場合にはＳＵＰＬを使用してこのＵＥのための位置決定を調整することができ、決定された位置を要求側の外部エンティティに返すことができる。図１Ｂに示されるＥ−ＳＭＬＣ１７２は、ＭＭＥ１４２に接続され、ＬＴＥ制御プレーン位置特定解決法を使用してＵＥの位置推定を取得するために使用される別の位置サーバである。
[0062]制御プレーンの位置特定解決法では、位置サーバ（例えば、図１Ａの位置サーバ１７０又は図１ＢのＧＭＬＣ／ＳＬＰ１７０）は、ネットワーク中の既存の信号伝達インターフェースを介して、ＵＥを含む他の要素によってアクセスされる。ＵＥの位置特定に関する全ての信号伝達が、全てのインターフェース上で信号伝達として明示的に運ばれる。ＬＴＥアクセスの場合、制御プレーンの位置特定解決法は、３ＧＰＰ ＴＳ ２３．２７１及び３６．３０５において定義される。
[0063]ＳＵＰＬ解決法などのユーザプレーンの位置特定解決法では、ＵＥ及び図１ＢのＧＭＬＣ／ＳＬＰ１７０などの位置サーバは、ＩＰ又はＴＣＰ／ＩＰなどを介して、ネットワークの観点からデータを交換することによって通信する。ＳＵＰＬ解決法の場合、ＧＭＬＣ／ＳＬＰ１７０は、ＳＬＰであり、Ｅ−ＳＭＬＣ１７２を使用する代わりに位置を取得するために使用される。幾つかの場合、ネットワークは、制御プレーンの位置特定解決法と、ＳＵＰＬなどのユーザプレーンの位置特定解決法の両方を利用し得る。その場合、Ｅ−ＳＭＬＣ１７２は存在することがあり、ＧＭＬＣ／ＳＬＰ１７０はＧＭＬＣとＳＬＰの両方を備えることがある。ＧＭＬＣ／ＳＬＰ１７０のためのＧＭＬＣ及びＳＬＰはまた、ＵＥを位置特定するために両方の解決法が使用されることを可能にするために、（例えば、同じ物理エンティティの中で）結合されることがあり、又は互いに接続されることがある。すでに言及されたように、ＧＭＬＣ／ＳＬＰ１７０はまた、ＧＭＬＣ及び／又はＳＬＰとの関連付け、又はそれらへの接続を有する、ＬＲＦを備え得る。ＧＭＬＣに接続された、又はＧＭＬＣと関連付けられたＬＲＦ１７０は、ＧＭＬＣと同様に制御プレーンの位置特定をサポートし得るが、ＳＬＰに接続された、又はＳＬＰと関連付けられるＬＲＦ１７０は、ＳＬＰと同様にＳＵＰＬユーザプレーンの位置特定をサポートし得る。
[0064]電気通信標準化連合（ＡＴＩＳ）は、ＯＴＴサービスプロバイダ、例えばＳｋｙｐｅ（商標）を介してＵＥによって確立される、次世代９−１−１番（ＮＧ９１１）通報をサポートするための方法を調査している。１つの主要な問題は、ＯＴＴ ＳＰによる、正しいＰＳＡＰへの、又はそれに向かうＮＧ９１１番通報のルーティングを可能にするために、及び、通報しているユーザの位置への公安の支援というＰＳＡＰによる出動を可能にするために、９１１番通報者の正確で信頼できる位置を取得して提供することである。ＯＴＴ ＳＰ１５０などのＯＴＴ ＳＰは、通報しているＵＥによって使用されるアクセスネットワークに関する情報を殆んど、又は全く有しないことが多いので、ＯＴＴ ＳＰが、通報しているＵＥを直接位置特定するために地上ベースの測位方法（Ｗｉ−Ｆｉ（登録商標）、改良セルＩＤ（Ｅ−ＣＩＤ：Enhanced Cell ID）、及び観測到着時間差（ＯＴＤＯＡ：observed time difference of arrival）など）を利用するのは難しいことがある。その上、通報しているＵＥが屋内にあるとき、全地球測位システム（ＧＰＳ）、何らかの他の全地球的航法衛星システムなどの衛星測位システム（ＳＰＳ）を使用した、又はＯＴＴ ＳＰによるＡｓｓｉｓｔｅｄ ＧＰＳ（Ａ−ＧＰＳ）若しくはａｓｓｉｓｔｅｄ ＧＮＳＳ（Ａ−ＧＮＳＳ）を介したＵＥの位置特定は、ＳＰＳ位置特定を屋内で使用することが本来困難であることにより、及び／又は、ＳＰＳ位置特定の使用を制御及び／又は支援するための能力をＯＴＴ ＳＰが欠いていることにより、信頼できないこともある。
[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]問題セット１：レガシーＰＳＡＰＳ
[00119]レガシーＰＳＡＰ３８０がＥＳＩｎｅｔ３６０によってサポートされない（例えば、その代わりにＳＲ３６０によってサポートされ得る）とき、レガシーＰＳＡＰ３８０に送信される必要のある緊急呼のための位置特定とルーティングとをサポートすることと関連付けられる問題があり得る。１つの問題は、レガシーＰＳＡＰ３８０がＴＩＡとＡＴＩＳの共同規格Ｊ−ＳＴＤ−０３６において定義されるＥ２インターフェースを使用してＯＴＴ ＳＰ３５０からＵＥ３００の位置を検索できないことがあるということである可能性があり、これは、ＯＴＴ ＳＰ３５０がＵＥ３００及びＰＳＡＰ３８０とは異なる国の中にある場合、又は、ＰＳＡＰ３８０がＯＴＴ ＳＰ３５０との通信関係を有しない場合に起こり得る。Ｅ２インターフェースは一般に、緊急呼がレガシーＰＳＡＰにルーティングされる、北米の公衆ワイヤレスネットワークを介して引き起こされる緊急呼の場合に、レガシーＰＳＡＰによる位置の検索のために使用されることに留意されたい。第２の問題は、（例えば、ＵＥ３００に対する緊急呼が、ＰＳＡＰ３８０に到達するためにＭＦトランクを使用するＳＲ３６０を通じてルーティングされる場合）ＯＴＴ ＳＰ３５０がＬｂｙＶを呼信号伝達の一部としてレガシーＰＳＡＰ３８０に送信できないことがあるということであり得る。第３の問題は、ＯＴＴ ＳＰ３５０がＬｂｙＶではなくＬｂｙＲをＰＳＡＰ３８０に提供する場合に、レガシーＰＳＡＰ３８０（又はレガシーＰＳＡＰ３８０と関連付けられるＡＬＩ）が普通はＬｂｙＲの逆参照をサポートしないことがあるということであり得る。
[00120]上の３つの問題は、ＯＴＴ ＳＰ３５０へのＬｂｙＶ又はＬｂｙＲの提供だけに基づく解決法Ｓ１及びＳ２のどのような改良も、レガシーＰＳＡＰ３８０がＥＳＩｎｅｔ３６０によってサポートされない（例えば、ＳＲ３６０によってのみサポートされる）ときには、レガシーＰＳＡＰ３８０への出動可能な位置の提供をサポートできないことを意味し得る。
[00121]問題セット２：サービングＭＮＯにおける制御プレーン位置特定
[00122]（例えば、３ＧＰＰ ＴＳ２３．２７１、２５．３０５及び３６．３０５において定義されるような）ＬＴＥ又はＨＳＰＡアクセスに対する３ＧＰＰ制御プレーン位置特定解決法では、緊急呼を行っているＵＥ３００に対して、ＵＥ３００の位置に対する要求を正しいサービングＭＭＥ又はサービングＳＧＳＮにルーティングするために、現在のサービングＭＭＥ又はサービングＳＧＳＮの識別情報がＬＲＦ又はＧＭＬＣにおいて知られている必要がある。（例えば、ＡＴＩＳ−０７０００１５において説明されるように）ＯＴＴ ＳＰの関与を伴わずにサービングＭＮＯによって確立される緊急呼では、この情報は、ＵＥ３００が緊急ＰＤＮ接続又は緊急ＰＤＰコンテキストを（例えば、緊急呼を確立することの一部として）確立するときにはサービングＭＭＥ又はサービングＳＧＳＮによって、及び、ハンドオーバーが発生するときには新たな若しくは以前のＭＭＥ又はＳＧＳＮによって、（緊急呼を行っているＵＥ３００の位置特定をサポートするために使用されている）ＬＲＦ及びＧＭＬＣにおいて更新された状態に保たれ得る。しかしながら、ＯＴＴ ＳＰ３５０を通じて確立される緊急呼では、サービングＭＮＯが緊急呼を認識しないことがあるので、ＬＲＦ（及びＧＭＬＣ）はサービングＭＭＥ又はサービングＳＧＳＮの識別情報について更新された状態に保たれないことがある。この情報がないと、ＧＭＬＣは、位置要求を正しいサービングＭＭＥ又はサービングＳＧＳＮにルーティングすることが可能ではないことがある。このことは、ＯＴＴ ＳＰ３５０からのＵＥ３００に対する位置逆参照要求にサービスするときに、ＥＬＳ３７０（例えば、ＬＲＦ）がＨＳＳからＵＥ３００の位置について質問するのに十分な情報を持っているホーム加入者の事例を場合によっては除き、ＥＬＳ３７０がＵＥ３００の位置を取得するために制御プレーン位置特定解決法を使用することが可能ではないことがあることを意味する。
[00123]問題セット３：サービングＭＮＯにおけるユーザプレーン位置特定
[00124]サービングＭＮＯ（例えば、ＰＣＮ３４０）とＯＴＴ ＳＰ３５０の中間にあるＶＰＮを介してＵＥ３００がＯＴＴ ＳＰ３５０にアクセスするとき、ＯＴＴ ＳＰ３５０によって見られているＵＥ３００のＩＰアドレスは、ＶＰＮによって割り当てられていることがあるので、サービングＭＮＯ（例えば、ＰＣＮ３４０）によってＵＥに割り当てられた任意のＩＰアドレスとは異なることがある。サービングＭＮＯ（例えば、ＥＬＳ３７０）におけるＳＬＰが、サービングＭＮＯに知られているＩＰアドレス又はサービングＭＮＯによって割り当てられたＩＰアドレスを有するＵＥの代わりに、入来する位置要求を受け入れるだけである場合、このことは、ＶＰＮにより割り当てられたＩＰアドレスがＯＴＴ ＳＰ３５０によってサービングＭＮＯに送信される（例えば、ＥＬＳ３７０に送信される）位置要求に含まれる場合、サービングＭＮＯによるＳＵＰＬ位置特定の使用を妨げ得る。自身のＩＰアドレスがホームネットワーク３８５によって割り当てられる（例えば、この場合ＬＴＥアクセスのためのＰＤＮゲートウェイがホームネットワーク３８５の中にある）ローミングＵＥ３００についても、同様の問題が起こり得る。しかしながら、この場合、サービングＭＮＯ（例えば、サービングＭＮＯの中のＳＬＰ）は、ホームネットワーク３８５などのローミングパートナーによって割り当てられるＩＰアドレス（例えば、アドレス範囲）を用いて構成されることがあり、この場合、ユーザプレーン（例えば、ＳＵＰＬ）位置特定の使用も依然として可能であり得る。
[00125]問題セット４：ＰＳＡＰへの緊急呼のルーティング
[00126]ＰＳＡＰ３８０の正しいアドレス又は識別情報（例えば、ＳＩＰ ＵＲＬ又は電話ＤＮ）が知られている場合、ＯＴＴ ＳＰ３５０がＵＥ３００からＰＳＡＰ３８０に（例えば、ＩＰネットワーク３７５を介して、又はＰＳＴＮを介して）緊急呼をルーティングすることは可能であり得るが、一部のＯＴＴ ＳＰ３５０は、自身のサービスエリアがＵＥ３００のアドレスの位置を含むＰＳＡＰ３８０のアドレス又は識別情報へと、ＵＥ３００の地理的位置をマッピングする能力を欠いていることがある。例えば、この能力の欠如は、ＯＴＴ ＳＰ３５０がＵＥ３００とＰＳＡＰ３８０の両方と異なる国の中にあり、例えばＩＥＴＦによって定義されるＬｏＳＴプロトコルを使用して他の国におけるＰＳＡＰのためのルーティング情報を取得する能力を有しない場合に、発生し得る。幾つかの場合、ＰＳＡＰ３８０のアドレス又は識別情報がＯＴＴ ＳＰ３５０によって知られている場合であっても、ＯＴＴ ＳＰ３５０は、ＰＳＡＰ３８０側の緊急呼の流入に対する制約により、ＵＥ３００のための緊急呼をＰＳＡＰ３８０に転送することが可能ではないことがある。
[00127]上で説明され例示された問題セット１から４は、次に説明されるように、以前に言及された解決法Ｓ１及びＳ２に対する特定の改良によって解決され得る。
[00128]図４は、本開示の少なくとも一態様による、ＯＴＴサービスプロバイダを通じた、緊急サービスのための基準による位置特定のサポートのための例示的なアーキテクチャを示す。図４に示されるアーキテクチャは、ＵＥ４００（ＵＥ２００又はＵＥ３００に対応し得る）と、アクセスネットワーク４２０（ＲＡＮ１２０又はＡＮ３２０に対応し得る）と、ＩＭＳ４４０（コアネットワーク１４０の一部又はＰＣＮ３４０の一部に対応し得る）と、ＯＴＴ ＳＰ４５０（ＯＴＴ ＳＰ１５０又はＯＴＴ ＳＰ３５０に対応し得る）と、ＮＥＮＡ ｉ３対応ＥＳＩｎｅｔ４６０（ＥＳＩｎｅｔ１６０又はＥＳＩｎｅｔ３６０に対応し得る）と、レガシーＥＳＮ４６２と、インターネット４７５と、ＰＳＴＮ４８５と、サービングＭＮＯ４９０（ＡＮ１２０と組み合わされたＣＮ１４０及びＡＮ３２０と組み合わされたＰＣＮ３４０に対応し得る）とを含む。ＩＭＳ４４０は、ＬＲＦ４４８（位置サーバ１７０又はＥＬＳ３７０に対応し得る）と、ＭＧＣＦ４４１と、Ｐ−ＣＳＣＦ４４２と、Ｅ−ＣＳＣＦ４４３と、ＩＢＣＦ４４４と、Ｓ−ＣＳＣＦ４４５とを含む。ＬＲＦ４４８は、ＲＤＦ４４６及びＬＳ４７０（位置サーバ１７０又はＧＭＬＣ／ＳＬＰ１７０に対応し得る）に接続され得る。ｉ３ ＥＳＩｎｅｔ４６０は、ＢＣＦ４６４と、ＥＳＲＰ４６６と、ＥＣＲＦ４６８と、ＮＥＮＡ ｉ３対応ＰＳＡＰ４８０（ＰＳＡＰ１８０又はＰＳＡＰ３８０に対応し得る）とを含む。レガシーＥＳＮ４６２は、ＡＬＩ４６１と、ＳＲ４６３（ＳＲ１６０又はＳＲ３６０に対応し得る）と、レガシーＰＳＡＰ４８２（ＰＳＡＰ１８０又はＰＳＡＰ３８０に対応し得る）とを含む。図４に示される様々なエンティティは、当技術分野においてよく知られており、３ＧＰＰ ＴＳ（例えば、ＴＳ２３．４０１、２３．１６７、２３．２２８）において、ＡＴＩＳ ０７０００１５規格において、及びＮＥＮＡ ｉ３規格において定義されている。
[00129]解決法Ｓ１について図４に示されるように、普通のＬｂｙＲのサポートでは、ＵＥ４００がＬｂｙＲを含む緊急呼要求４０１をＯＴＴ ＳＰ４５０に送信する。ＯＴＴ ＳＰ４５０は次いで、緊急呼要求４０１において受信されるＬｂｙＲによって示されるＥＬＳ（例えば、サービングＭＮＯ４９０の中のＬＲＦ４４８）に位置質問４０２を送信することによって、ＬｂｙＲを逆参照する。ＥＬＳ（図４においてＬＲＦ４４８として示されている）は、ＵＥ４００の位置を取得し、位置及び／又はルーティング情報をＯＴＴ ＳＰ４５０に返す。ＯＴＴ ＳＰ４５０は次いで、ＬＲＦ４４８から受信され、当初受信されたＬＢｙＲを含む、ルーティング情報又は位置に基づいて、緊急呼をＰＳＡＰに（メッセージ４０３ＡにおいてレガシーＰＳＡＰ４８２に、又はメッセージ４０３ＢにおいてＮＥＮＡ ｉ３対応ＰＳＡＰ４８０に）ルーティングする。ＰＳＡＰ４８０／４８２は次いで、受信されたＬＢｙＲを使用して、出動可能な位置に対する、質問４０４Ａ（ＰＳＡＰ４８２のための）又は４０４Ｂ（ＰＳＡＰ４８０のための）をＥＬＳ（例えば、ＬＲＦ４４８）に後で送信し得る。上の問題セット１について論じられたように、位置質問４０４Ａは、ＰＳＡＰがＥＳＩｎｅｔによってサポートされない限り、レガシーＰＳＡＰ４８２に対して可能ではないことがある。
[00130]図４に関連して上で説明された基本的なＬｂｙＲの解決法は、問題セット２及び３について上で説明された問題を克服するように、図３の解決法Ｓ１及びＳ２に対して改良され得る。具体的には、ＵＥ４００に対するＬｂｙＲとしてサービングＭＮＯ４９０によって（例えば、ＬＲＦ４４８によって）割り当てられる位置ＵＲＩは、以下の情報を含むようにフォーマットされ得る。
ａ）サービングＭＮＯ４９０がＵＥ４００を位置特定するためにユーザプレーン位置特定を使用する場合、及び、ローカルＩＰアドレスがサービングＭＮＯ４９０によってＵＥ４００に割り当てられた場合、ＵＥ４００のローカルＩＰアドレス、
ｂ）サービングＭＮＯ４９０がＵＥ４００を位置特定するために制御プレーン位置特定を使用する場合、サービングＭＭＥ（例えば、ＭＭＥ１４２）又はサービングＳＧＳＮのローカル識別情報、及び、
ｃ）サービングＭＮＯ４９０がＵＥ４００を位置特定するために制御プレーン位置特定を使用する場合、ＵＥ４００の識別情報（例えば、ＭＳＩＳＤＮ、ＩＭＳＩ、又はサービングＭＭＥ若しくはＳＧＳＮによって割り当てられるローカルＩＤ）。
[00131]（ａ）、（ｂ）及び（ｃ）における上の情報は、ＵＥ４００に対するローカル基準として普通は使用されるＬｂｙＲの一部として含まれることがあり、（例えば、図１Ａ〜図２Ｂに関連して以前に説明されたように）ＬＲＦ４４８などのＥＬＳではなくサービングＭＮＯ４９０の中のＡＮ４２０又はＰＣＮによるＬｂｙＲの割当てを可能にし、これは実装を簡単にし得る。この情報のフォーマットは、サービングＭＮＯ４９０に対して特有であり得る（例えば、標準化されないことがある）。ＯＴＴ ＳＰ４５０からの要求４０２などのＬｂｙＲに対する逆参照要求においてそのような位置ＵＲＩを受信し、ＬｂｙＲに対するフォーマット規則を知っている、サービングＭＮＯ４９０中のＥＬＳ（例えば、ＬＲＦ４４８）は、上の（ａ）〜（ｃ）の情報を抽出し、ＵＥ４００の制御プレーン位置特定とユーザプレーン位置特定のいずれかを呼び出すためにその情報を使用し得る。追加の利点は、ＥＬＳがＵＥ４００又はＵＥ４００のいずれかからの緊急呼のための情報を保持する必要がなく、各々のそのような要求に含まれる情報だけに基づいて各逆参照要求（例えば、要求４０２）に応答できるということである。
[00132]図４に関連して説明されたような上の改良は、「改良されたＬｂｙＲ」と本明細書で呼ばれ、追加の図面を使用して本明細書で後で例示されるが、上の問題セット２の全ての問題を解決するとは限らない。例えば、ＵＥ４００に対するＬｂｙＲがＵＥ４００の現在のサービングＭＭＥ又は現在のサービングＳＧＳＮの識別情報を含み得るとしても、この情報は、ＵＥ４００が新たなサービングＭＭＥ又はＳＧＳＮにハンドオフされると、ＵＥ４００が新たな情報（例えば、新たなＬｂｙＲ）をＯＴＴ ＳＰ４５０に（例えば、ＳＩＰ ＩＮＦＯにおいて）送信し、次いでＯＴＴ ＳＰ４５０がこれをＰＳＡＰ４８０又は４８２に転送しない限り、古くなることがある。
[00133]ＩＭＳのサポートは、問題セット１、２、３及び４について上で説明された全ての問題を解決するために使用され得る、図３の解決法Ｓ１及びＳ２に対する別の改良である。ＩＭＳのサポートにより、サービングＭＮＯは、図５に関連して次に説明されるようにＬＲＦとして、又は図６に関連して後で説明されるようにＥ−ＣＳＣＦとして、サポートを提供することができる。
[00134]図５は、本開示の少なくとも一態様による、ＯＴＴサービスプロバイダを通じた、緊急サービスのためのＩＭＳ ＬＲＦのサポートのための例示的なアーキテクチャを示す。図４に示されるアーキテクチャと同様に、図５に示されるアーキテクチャは、ＵＥ５００（ＵＥ２００、ＵＥ３００又はＵＥ４００に対応し得る）と、アクセスネットワーク５２０（ＲＡＮ１２０、ＡＮ３２０又はＡＮ４２０に対応し得る）と、ＩＭＳ５４０（コアネットワーク１４０の一部、ＰＣＮ３４０の一部又はＩＭＳ４４０に対応し得る）と、ＯＴＴ ＳＰ５５０（ＯＴＴ ＳＰ１５０、ＯＴＴ ＳＰ３５０又はＯＴＴ ＳＰ４５０に対応し得る）と、ＮＥＮＡ ｉ３対応ＥＳＩｎｅｔ５６０（ＥＳＩｎｅｔ１６０、ＥＳＩｎｅｔ３６０又はＥＳＩｎｅｔ４６０に対応し得る）と、レガシーＥＳＮ５６２と、インターネット５７５と、ＰＳＴＮ５８５と、サービングＭＮＯ５９０（ＡＮ１２０と組み合わされたＣＮ１４０、ＡＮ３２０と組み合わされたＰＣＮ３４０、又はＭＮＯ４９０に対応し得る）とを含む。ＩＭＳ５４０は、ＬＲＦ５４８（位置サーバ１７０、ＥＬＳ３７０又はＬＲＦ４４８に対応し得る）と、ＭＧＣＦ５４１と、Ｐ−ＣＳＣＦ５４２と、Ｅ−ＣＳＣＦ５４３と、ＩＢＣＦ５４４と、Ｓ−ＣＳＣＦ５４５とを含む。ＬＲＦ５４８は、ＲＤＦ５４６及びＬＳ５７０（位置サーバ１７０、ＧＭＬＣ／ＳＬＰ１７０又はＬＳ４７０に対応し得る）に接続され得る。ｉ３ ＥＳＩｎｅｔ５６０は、ＢＣＦ５６４と、ＥＳＲＰ５６６と、ＥＣＲＦ５６８と、ＮＥＮＡ ｉ３対応ＰＳＡＰ５８０（ＰＳＡＰ１８０、ＰＳＡＰ３８０又はＰＳＡＰ４８０に対応し得る）とを含む。レガシーＥＳＮ５６２は、ＡＬＩ５６１と、ＳＲ５６３（ＳＲ１６０、ＳＲ３６０、又はＳＲ４６３に対応し得る）と、レガシーＰＳＡＰ５８２（ＰＳＡＰ１８０、ＰＳＡＰ３８０又はレガシーＰＳＡＰ４８２に対応し得る）とを含む。図４の場合のように、図５に示される様々なエンティティが当技術分野においてよく知られている。
[00135]図３の解決法Ｓ１について図５に示される、ＬＲＦのサポートにより、ＵＥ５００からＰＳＡＰ５８０又はＰＳＡＰ５８２への緊急呼は、図４に関連して説明されるＵＥ４００からＰＳＡＰ４８０又はＰＳＡＰ４８２への緊急呼と同様に確立されることがあり、図４のメッセージ４０１、４０２、４０３Ａ、４０３Ｂ、４０４Ａ及び４０４Ｂはそれぞれ、図５のメッセージ５０１、５０２Ａ、５０３Ａ、５０３Ｂ、５０４Ａ及び５０４Ｂに対応する。しかしながら、図５に示されるＬＲＦのサポートの場合、質問５０２Ａ及び応答５０２ＢにおけるＯＴＴ ＳＰ５５０とＬＲＦ５４８との間の対話は、図４のような位置の逆参照を使用せず、代わりに、位置検索と緊急呼のルーティングとの両方をサポートするためにＬＲＦ能力を利用する。ＯＴＴ ＳＰ５５０は最初に、（ＵＥ５００が例えばネットワーク接続の際にサービングＭＮＯ ＡＮ５２０又はサービングＭＮＯ５９０中のＰＣＮから取得し得る）緊急呼要求５０１において、ＵＥ５００からサービングＭＮＯ５９０中のＬＲＦ５４８のアドレスを受信する。ＯＴＴ ＳＰ５５０は次いで、（例えば、ＡＴＩＳ−０７０００１５規格に対する）Ｅ−ＣＳＣＦと同様に振る舞い、ＳＩＰ ＩＮＶＩＴＥ５０２Ａの形式の緊急呼要求をＬＲＦ５４８に転送し、ＬＲＦ５４８は、ＭｌインターフェースについてＡＴＩＳ−００７０００１５におけるＬＲＦに対して説明されたのと同様に、位置とルーティング情報とを取得する。ＬＲＦ５４８は次いで、（例えば、ＡＴＩＳ−０７０００１５においてＭｌインターフェース上で行われるように）ＳＩＰ ３００ Ｍｕｌｔｉｐｌｅ Ｃｈｏｉｃｅｓ５０２Ｂという形式で、位置とルーティング情報とをＯＴＴ ＳＰ５５０に返す。ＯＴＴ ＳＰ５５０は次いで、ルーティング情報を使用し応答５０２Ｂにおいて受信される位置情報を含み、緊急呼要求をＰＳＡＰに（要求５０３ＡにおいてレガシーＰＳＡＰ５８２に、又は要求５０３ＢにおいてＮＥＮＡ ｉ３対応ＰＳＡＰ５８０に）ルーティングする。応答５０２Ｂにおいて受信される位置情報は、ＬｂｙＶ、ＬｂｙＲ、ＥＳＲＫ又はＥＳＲＤとＭＳＩＳＤＮを含むことがあり、ＡＴＩＳ−０７０００１５において定義される基準識別子に対応し得る。後ろの３つの代替物（即ち、ＬｂｙＲ、ＥＳＲＫ又はＥＳＲＤとＭＳＩＳＤＮ）について、ＰＳＡＰ５８０／５８２は通常、ＵＥ５００に対する出動可能な位置に対して、後の時間に質問５０４Ａ（ＰＳＡＰ５８２のための）又は質問５０４Ｂ（ＰＳＡＰ５８０のための）をＬＲＦ５４８に送信する。
[00136]図５は、ＵＥ５００からＯＴＴ ＳＰ５５０への初期緊急呼要求メッセージ（例えば、ＳＩＰ ＩＮＶＩＴＥ）５０１の経路及び方向と、（転送されるＳＩＰ ＩＮＶＩＴＥ５０２Ａのために）ＬＲＦ５４８へ向かい（ＳＩＰ ３００ Ｍｕｌｔｉｐｌｅ Ｃｈｏｉｃｅｓ５０２Ｂのために）ＯＴＴ ＳＰ５５０へ戻る経路と、転送される緊急呼要求５０３Ａ及び５０３ＢのためのＯＴＴ ＳＰ５５０からＰＳＡＰ５８０／５８２への経路及び方向とを示す。初期呼要求５０１をサービングＭＮＯ５９０からＯＴＴ ＳＰ５５０に運び、転送される呼要求５０３ＢをＯＴＴ ＳＰ５５０からＥＳＩｎｅｔ５６０に運ぶために、インターネット５７５が使用され得るが、レガシーＰＳＡＰ５８２に到達するようにＣＳ呼要求５０３ＡをＯＴＴ ＳＰ５５０からＳＲ５６３に運ぶために、ＰＳＴＮ５８５が使用され得る。図５はまた、レガシーＰＳＡＰ５８２又はＮＥＮＡ ｉ３ ＰＳＡＰ５８０によってそれぞれＬＲＦ５４８に送信される、ＵＥ５００に対する位置要求５０４Ａ又は５０４Ｂのための、経路と方向とを示す。
[00137]図６は、本開示の少なくとも一態様による、ＯＴＴサービスプロバイダを通じた、緊急サービスのためのＩＭＳ Ｅ−ＣＳＣＦのサポートのための例示的なアーキテクチャを示す。図４及び図５に示されるアーキテクチャと同様に、図６に示されるアーキテクチャは、ＵＥ６００（ＵＥ２００、ＵＥ３００、ＵＥ４００又はＵＥ５００に対応し得る）と、アクセスネットワーク６２０（ＲＡＮ１２０、ＡＮ３２０、ＡＮ４２０、又はＡＮ５２０に対応し得る）と、ＩＭＳ６４０（コアネットワーク１４０の一部、ＰＣＮ３４０の一部、ＩＭＳ４４０又はＩＭＳ５４０に対応し得る）と、ＯＴＴ ＳＰ６５０（ＯＴＴ ＳＰ１５０、ＯＴＴ ＳＰ３５０、ＯＴＴ ＳＰ４５０又はＯＴＴ５５０に対応し得る）と、ＮＥＮＡ ｉ３対応ＥＳＩｎｅｔ６６０（ＥＳＩｎｅｔ１６０、ＥＳＩｎｅｔ３６０、ＥＳＩｎｅｔ４６０又はＥＳＩｎｅｔ５６０に対応し得る）と、レガシーＥＳＮ６６２と、インターネット６７５と、ＰＳＴＮ６８５と、サービングＭＮＯ６９０（ＡＮ１２０と組み合わされたＣＮ１４０、ＡＮ３２０と組み合わされたＰＣＮ３４０、ＭＮＯ４９０又はＭＮＯ５９０に対応し得る）とを含む。ＩＭＳ６４０は、ＬＲＦ６４８（位置サーバ１７０、ＥＬＳ３７０、ＬＲＦ４４８又はＬＲＦ５４８に対応し得る）と、ＭＧＣＦ６４１と、Ｐ−ＣＳＣＦ６４２と、Ｅ−ＣＳＣＦ６４３と、ＩＢＣＦ６４４と、Ｓ−ＣＳＣＦ６４５とを含む。ＬＲＦ６４８は、ＲＤＦ６４６及びＬＳ６７０（位置サーバ１７０、ＧＭＬＣ／ＳＬＰ１７０、ＬＳ４７０又はＬＳ５７０に対応し得る）に接続され得る。ｉ３ ＥＳＩｎｅｔ６６０は、ＢＣＦ６６４と、ＥＳＲＰ６６６と、ＥＣＲＦ６６８と、ＮＥＮＡ ｉ３対応ＰＳＡＰ６８０（ＰＳＡＰ１８０、ＰＳＡＰ３８０、ＰＳＡＰ４８０又はＰＳＡＰ５８０に対応し得る）とを含む。レガシーＥＳＮ６６２は、ＡＬＩ６６１と、ＳＲ６６３（ＳＲ１６０、ＳＲ３６０、ＳＲ４６３又はＳＲ５６３に対応し得る）と、レガシーＰＳＡＰ６８２（ＰＳＡＰ１８０、ＰＳＡＰ３８０、レガシーＰＳＡＰ４８２又はレガシーＰＳＡＰ５８２に対応し得る）とを含む。図４及び図５の場合のように、図６に示される様々なエンティティが当技術分野においてよく知られている。
[00138]図３の解決法Ｓ１について図６において示される、Ｅ−ＣＳＣＦのサポートにより、ＯＴＴ ＳＰ６５０は、（ＵＥ６００が例えばネットワーク接続の際にサービングＭＮＯ ＡＮ６２０又はサービングＭＮＯ６９０中のＰＣＮから取得し得る）ＵＥ６００から送信される緊急呼要求６０１において、サービングＭＮＯ６９０中のＥ−ＣＳＣＦ６４３のアドレスを受信する。ＯＴＴ ＳＰ６５０が次いで、Ｓ−ＣＳＣＦと同様に振る舞い、標準のＳＩＰ ＩＮＶＩＴＥ６０２を使用して緊急サービス要求をＥ−ＣＳＣＦ６４３に転送し、Ｅ−ＣＳＣＦ６４３が次いで、転送を実行するために必要とされる応答６０３Ｂ中の任意のルーティング情報と位置情報とを取得するために要求６０３ＡをＬＲＦ６４８に送信した後で、呼要求６０４Ａ又は６０４ＢをＰＳＡＰ６８０又は６８２にそれぞれ転送する。図６に例示されるＥ−ＣＳＣＦのサポートは、サービングＭＮＯ６９０によるより大きな関与と引き換えに、ＰＳＡＰ６８０／６８２への呼（又はサービス）の移送が成功する確率を上げることができる。
[00139]図５と同様に、図６は、ＵＥ６００からＯＴＴ ＳＰ６５０への初期緊急呼要求メッセージ（例えば、ＳＩＰ ＩＮＶＩＴＥ）６０１の経路及び方向と、Ｅ−ＣＳＣＦ６４３への転送される呼要求６０２の経路と、転送される呼要求６０４Ａ又は６０４ＢのそれぞれＰＳＡＰ６８０又は６８２への経路及び方向とを示し、位置特定とルーティングの支援は要求６０３ＡにおいてＥ−ＣＳＣＦ６４３によって要求され、応答６０３ＢにおいてＬＲＦ６４８によって返される。ＬＲＦ６４８への要求６０３Ａ及びＬＲＦ６４８からの応答６０３Ｂは、ＡＴＩＳ−０７０００１５における解決法について定義されるようなものであることがあり、例えば、要求６０３ＡはＳＩＰ ＩＮＶＩＴＥを備え、応答６０３ＢはＳＩＰ ３００ ｍｕｌｔｉｐｌｅ ｃｈｏｉｃｅｓメッセージを備える。図６はまた、レガシーＰＳＡＰ６８２又はＮＥＮＡ ｉ３ ＰＳＡＰ６８０によってそれぞれＬＲＦ６４８に送信される、ＵＥ６００に対する位置要求６０５Ａ又は６０５Ｂのための、経路と方向とを示す。
[00140]３ＧＰＰ（例えば、３ＧＰＰ ＴＳ ２３．１６７）によって、及びＡＴＩＳ−０７０００１５において定義されるＩＭＳ緊急呼解決法と比較すると、図５及び図６に関連してそれぞれ説明されたＬＲＦ６４８とＥ−ＣＳＣＦ６４３の解決法の両方が、図６のＥ−ＣＳＣＦ解決法のために、ＬＲＦ及びＲＤＦに対して、並びにＥ−ＣＳＣＦに対していくらかの変更を必要とし得るが、これらの標準の解決法からの既存の機能を再利用することもできる。
[00141]図５及び図６に関して上で説明された各解決法では、ＵＥ（例えば、ＵＥ５００又は６００）は、（ｉ）サービングＭＮＯ（ＬＲＦ又はＥ−ＣＳＣＦのいずれか）中の正しいエンティティへのＯＴＴ ＳＰからの緊急呼のルーティングを可能にするために、及び（ｉｉ）サービングＭＮＯがＵＥの位置を取得することと呼のルーティングをサポートすることとを可能にするのに、又はそのことを支援するのに十分な情報をＯＴＴ ＳＰがサービングＭＮＯに提供することを可能にするために、ある情報をＯＴＴ ＳＰ（例えば、ＯＴＴ ＳＰ５５０又は６５０）に提供する。ＵＥによってＯＴＴ ＳＰに提供される情報の一部は、普通はＵＥに知られているものから来ることがあるが、他の情報は、例えば、ＵＥの接続において、新たなＭＭＥ若しくはＳＧＳＮへのハンドオーバーの際に、及び／又は、新たなＭＭＥ若しくはＳＧＳＮに対するトラッキングエリア若しくはルーティングエリアの更新が発生するときに常に、ＡＮ（例えば、ＡＮ５２０又は６２０）又はサービングＭＮＯ（例えば、ＭＮＯ５９０又は６９０）中のＰＣＮによってＵＥに提供されなければならないことがある。ＵＥに対する緊急呼要求においてＵＥによってＯＴＴ ＳＰに提供され得る情報が、情報の各項目の可能性の高い源（列２）、ＵＥに対するユーザプレーン（ＵＰ）位置特定又は制御プレーン（ＣＰ）位置特定の適用可能性（列３）及びＵＥとＯＴＴ ＳＰとの間でＳＩＰが使用されるときに各項目をＯＴＴ ＳＰに（及び、従ってサービングＭＮＯに）移送するために使用され得る可能なＳＩＰヘッダ（列４）とともに、表３（列１）に示されている。
Figure 0006374110
[00142]サービングＭＮＯ５９０又は６９０の中のＬＲＦ５４８又はＥ−ＣＳＣＦ６４３は、Ｅ−ＣＳＣＦ６４３の場合には呼を維持するために、又はＬＲＦ５４８の場合にはＰＳＡＰ５８０／５８２若しくはＥＳＩｎｅｔ５６０からの任意の後続の位置要求に応答するために、図５又は図６の方法にそれぞれ関連して、ＯＴＴ ＳＰ５５０又は６５０からそれぞれ初期ＳＩＰ ＩＮＶＩＴＥ５０２Ａ又は６０２を受信した後の状態情報を保持する必要があり得る。ＬＲＦ５４８の場合、これは緊急呼がいつ終了したかを知ることを意味する。加えて、ＵＥ５００又は６００のサービングＭＭＥ又はサービングＳＧＳＮは変わることがあるので、Ｅ−ＣＳＣＦ６４３又はＬＲＦ５４８は、制御プレーン位置特定が使用されるとき、新たなサービングＭＭＥ又はＳＧＳＮアドレス（又はＩＤ）を知る必要があり得る。ＬＲＦ５４８に対して、呼の終了についての、及び、制御プレーン位置特定が使用されるときのサービングＭＭＥ又はＳＧＳＮの変更についての、ＯＴＴ ＳＰ５５０からのイベント通知にＬＲＦ５４８が別々に同意する（subscribe to）場合、上記の目標が達成され得る。Ｅ−ＣＳＣＦ６４３について、サービングＭＭＥ又はＳＧＳＮのアドレスの変更の通知は、ＯＴＴ ＳＰ６５０からのＳＩＰ ＩＮＦＯ更新により可能であり得る。ＵＥ５００又は６００は、ＳＩＰ ＩＮＦＯを使用して（例えば、ＯＴＴ ＳＰがＳＩＰを使用するとき）、又は何らかのプロプライエタリなＯＴＴ ＳＰメッセージを使用して、ＯＴＴ ＳＰ５５０又は６５０をそれぞれ、任意の新しいサービングＭＭＥ又はＳＧＳＮの識別情報を用いて更新された状態に保つことができる。
[00143]図５及び図６に示される解決法はともに、ＵＥ５００又は６００によってＯＴＴ ＳＰ５５０又は６５０にそれぞれ提供されるサービングＭＮＯ中のアドレスが、図５のＬＲＦ方法ではＬＲＦ５４８のアドレスであり、図６のＥ−ＣＳＣＦ方法ではＥ−ＣＳＣＦ６４３のアドレスであり得ることを除き、ＵＥ ５００又はＵＥ６００からＯＴＴ ＳＰ５５０又はＯＴＴ ＳＰ６５０にそれぞれ、表３に示されているものと同じ情報を移送し得る。ＵＥ５００又は６００からそれぞれＯＴＴ ＳＰ５５０又は６５０への、この殆んど同一の情報の移送は、（図５及び図６の）両方の解決法が、ＵＥ５００及び６００によって、並びにＯＴＴ ＳＰ５５０及び６５０によって、共通の方法の一部としてサポートされることを可能にすることがあり、このことは、サービングＭＮＯ５９０又は６９０が２つの方法のいずれを使用すべきかを決断することを可能にすることがあり、ＵＥ５００及び６００並びにＯＴＴ ＳＰ５５０及び６５０によるサポートに影響を及ぼすことなく一方の方法からもう一方の方法への移行をサポートし得る。次に説明される図面は、図５のＬＲＦベースの解決法と図６のＥ−ＣＳＣＦベースの方法をより詳細に例示する。
[00144]図７は、本開示の少なくとも一態様による、値による位置特定及び改良された基準による位置特定のサポートのための例示的なメッセージフローを示す。図７に示されるメッセージフローは、図３及び図４に示されるアーキテクチャにおいて実行されることがあり、図４に関連して説明される基準による位置特定のサポートのための対話に対応し、それを拡張し得る。図７のメッセージフローは更に、又は代わりに、図１Ａ及び図１Ｂに示されるアーキテクチャにおいて実行されることがあり、基準による位置特定のサポートのために、図２Ａ及び図２Ｂに関連して説明される対話を賞賛し、拡張し得る。結果として、図７のＵＥ７００は、図１ＡのＵＥ１からＮ、ＵＥ２００、ＵＥ３００、又はＵＥ４００のいずれかに対応し得る。同様に、ＯＴＴ ＳＰ７５０は、ＯＴＴ ＳＰ１５０、ＯＴＴ ＳＰ３５０又はＯＴＴ ＳＰ４５０に対応し得る。同様に、ＡＮ／ＰＣＮ７９２は、ＡＮ４２０及びＭＮＯ４９０のＰＣＮ部分、ＡＮ３２０及びＰＣＮ３４０又はＡＮ１２０及びＣＮ１４０に対応することがあり、アクセスネットワークノード２４０を含むことがある。同様に、ＥＬＳ７９４は、ＬＲＦ４４８、ＥＬＳ３７０、ＧＭＬＣ／ＳＬＰ１７０又は位置サーバ１７０に対応し得る。同様に、ＳＲ７６３は、ＳＲ４６３、ＳＲ３６０又はＳＲ１６０に対応し得る。同様に、ＥＳＩｎｅｔ７６０は、ＥＳＩｎｅｔ４６０、ＥＳＩｎｅｔ３６０、又はＥＳＩｎｅｔ１６０に対応し得る。同様に、ｉ３ ＰＳＡＰ７８０は、ｉ３ ＰＳＡＰ４８０、ＰＳＡＰ３８０又はＰＳＡＰ１８０に対応し得る。同様に、レガシーＰＳＡＰ７８２は、レガシーＰＳＡＰ４８２、ＰＳＡＰ３８０又はＰＳＡＰ１８０に対応し得る。同様に、サービングＭＮＯ７９０はサービングＭＮＯ４９０に対応し得る。
[00145]図７に示される呼フローは、図３の解決法Ｓ１に直接適用されることがあり、例えば、解決法Ｓ１をサポートするために必要とされる対話の更なる詳細を提供することがある。図３の解決法Ｓ２に対応する呼フローは、７０６における緊急呼要求が（図７について以下で説明されるように）ＬｂｙＶ又はＬｂｙＲを搬送せず、ＯＴＴ ＳＰ７５０が７０６に続いてＬｂｙＶ又はＬｂｙＲについてＵＥ７００に質問することを除き、図７に示される呼フローと殆んど同じであり得る。加えて、図３の解決法Ｓ２では、ＵＥ７００は、７０６においてユーザが緊急呼を引き起こしたことを検出しないことがあり（例えば、「９１１」などの緊急番号をユーザがダイヤルしたことを認識しないことがあり）、緊急呼要求ではなく７０６において普通の呼要求をＯＴＴ ＳＰ７５０に送信することがある。ＯＴＴ ＳＰ７５０は次いで、７０６において送信された呼要求が緊急呼のためのものであることを認識することがあり（例えば、ダイヤルされた数字が「９１１」などの緊急番号のためのものであることを認識することがあり）、７０８に進む前にＵＥ７００からのＬｂｙＲ又はＬｂｙＶを要求することがある。図３の解決法Ｓ２が使用されるとき、図７に示される他の動作が次いで、以下で説明されるように行われ得る。
[00146]図７に示される対話は、ＵＥ７００がサービングＭＮＯ７９０にアクセスしている（例えば、サービングＭＮＯ７９０を介してＯＴＴ ＳＰ７５０にアクセスしている）状況において、ＯＴＴ ＳＰ７５０を介して緊急呼を引き起こすＵＥ７００に対して当てはまる。図７の７０２において、緊急呼をサポートするためにＬｂｙＲがＵＥ７００によって使用される場合、ＵＥ７００は、サービングＡＮ又はＰＣＮ７９２からのＬｂｙＲを要求し得る。例えば、これは、ユーザが緊急呼を引き起こしていることをＵＥ７００が検出するときに発生することがあり、又は、ＵＥ７００がサービングＭＮＯ７９０に接続するとき、若しくは何らかの他の理由で（例えば、ＵＥ７００のモビリティをサポートするために）サービングＭＮＯにアクセスするときに、発生することがある。
[00147]７０４において、７０２に応答して、又は、何らかの条件が発生したとき（例えば、ＵＥ７００がＡＮ／ＰＣＮ７９２に接続する、ＡＮ／ＰＣＮ７９２中の新しいＭＭＥ又はＳＧＳＮへのトラッキングエリア若しくはルーティングエリアの更新を実行する、又は新しいＭＭＥ若しくはＳＧＳＮへのハンドオーバーが発生する）、ＡＮ又はＰＣＮ７９２は、ＬｂｙＲ又は更新されたＬｂｙＲをＵＥ７００に送信する。ＬｂｙＲは、ＡＮ若しくはＰＣＮ７９２によって決定され、又はＥＬＳ７９４（例えば、ＬＲＦ）から取得され得る。幾つかの実施形態では、ブロック７０２及び７０４は、図２Ａのブロック２０２Ａに、又は図２Ｂのブロック２０２Ｂ及び２０６Ｂにそれぞれ、対応し得る。これらの実施形態では、ＡＮ／ＰＣＮ７９２自体が、７０４においてＵＥ７００に返されるＬｂｙＲを割り当てることがあり、又は、図２Ｂのブロック２０４Ｂと同様にＥＬＳ７９４からＬｂｙＲを取得することがある（図７には示されない）。
[00148]７０６において、ＵＥ７００のユーザが緊急呼を引き起こしたことをＵＥ７００が検出したことに応答して（例えば、ユーザが番号「９１１」をダイヤルしたことをＵＥ７００が検出する場合）、ＵＥ７００は、緊急呼要求をＯＴＴ ＳＰ７５０に送信し、７０４において取得されたＬｂｙＶ又はＬＢｙＲを含める。緊急呼要求は、ＳＩＰ ＩＮＶＩＴＥであることがあり、又は、ＯＴＴ ＳＰ７５０に特有の何らかの他のプロトコルのためのメッセージであることがある。ブロック７０６は、図２Ａのブロック２１４Ａ、図２Ｂのブロック２１２Ｂ又は図４の緊急呼要求４０１の送信に対応し得る。
[00149]７０８において、ＬｂｙＲが７０６において受信される場合、ＯＴＴ ＳＰ７５０は、位置要求（例えば、ＨＥＬＤがＬＢｙＲにおいて参照される場合、ＨＥＬＤプロトコルに従ってフォーマットされた位置要求）をＥＬＳ７９４に送信することによってＬｂｙＲを逆参照し、要求にＬｂｙＲを含める。ＯＴＴ ＳＰ７５０は、７０６において受信されたＬｂｙＲ中の情報からＥＬＳ７９４を決定し得る（例えば、ＥＬＳ７９４のアドレス、ＦＱＤＮ又はＵＲＬを決定し得る）。ブロック７０８は、図２Ａのブロック２１６Ａ、図２Ｂのブロック２１４Ｂ又は図４の位置質問４０２の送信に対応し得る。
[00150]７１０において、ＥＬＳ７９４は、例えば制御プレーン位置特定解決法又はユーザプレーン位置特定解決法を使用してＵＥ７００の現在の位置を取得するために、７０８において受信されたＬｂｙＲに含まれる情報（例えば、制御プレーン位置特定ではローカル若しくはグローバルのＵＥ識別情報及びサービングＭＭＥ／ＳＧＳＮ ＩＤ又はユーザプレーン位置特定ではローカルＵＥ ＩＰアドレス）を使用する。ブロック７１０は、図２Ａのブロック２１８Ａ及び／若しくは２２２Ａ、又は、図２Ｂのブロック２１６Ｂから２２６Ｂ若しくはブロック２２８Ｂのいずれかに対応し得る。
[00151]７１２において、ＥＬＳ７９４は、現在のＵＥ７００の位置をＯＴＴ ＳＰ７５０に返し、及び／又は、ＵＥ７００の位置から決定されるＵＥ７００のためのルーティング情報を返す。ブロック７１２は、図２Ａのブロック２２４Ａ又は図２Ｂのブロック２３２Ｂに対応し得る。ブロック７０８〜７１２は、任意選択であるものとして示されており、ＯＴＴ ＳＰ７５０が７０６においてＬｂｙＶを受信する場合は実行されないことがある。
[00152]７１２に続いて、７１２においてＵＥ７００の位置しか返されなかった場合、ＯＴＴ ＳＰ７５０は、ＵＥの位置を使用して（例えば、図７には示されないＬｏＳＴ質問を使用して）宛先ＰＳＡＰを決定する。それ以外の場合、ＯＴＴ ＳＰ７５０は、ＰＳＡＰを決定するために７１２において返される任意のルーティング情報を使用し得る。ＯＴＴ ＳＰ７５０がレガシーＰＳＡＰ７８２を決定するとき、ＯＴＴ ＳＰ７５０は、ＩＳＵＰ ＩＡＭメッセージをＰＳＡＰ７８２のためのＳＲ７６３に送信することによって、ＣＳを使用して呼を転送し得る。
[00153]７１６Ａにおいて、ＳＲ７６３は、呼をレガシーＰＳＡＰ７８２に転送する。
[00154]７１８Ａにおいて、呼の確立の残りが実行される。そうすると、ブロック７１４Ｂ、７１６Ｂ及び７１８Ｂは実行されない。
[00155]ＯＴＴ ＳＰ７５０が７１２に続いてレガシーＰＳＡＰ７８２の代わりにｉ３ ＰＳＡＰ７８０を決定するとき、ブロック７１４Ａ、７１６Ａ及び７１８Ａは実行されない。代わりに、ＯＴＴ ＳＰ７５０は、７０６において受信されたＬｂｙＶ又はＬｂｙＲを含み、場合によっては、７１２が行われる場合には７１２において受信されたＵＥ７００の任意の位置を含む、ＳＩＰ ＩＮＶＩＴＥを送信することによって、呼をＥＳＩｎｅｔ７６０に転送する。
[00156]７１４Ｂに続いて、及び７１６Ｂの前に、ＬｂｙＲが７１４Ｂにおいて提供される場合、ＥＳＩｎｅｔ７６０は、ルーティングを支援するためにＵＥ７００の現在の位置についてＥＬＳ７９４に質問し得る（図７には示されない）。ＥＳＩｎｅｔ７６０は次いで、７１６Ｂにおいて、呼をｉ３ ＰＳＡＰ７８０に転送する。
[00157]７１８Ｂにおいて、呼の確立の残りが実行される。ブロック７１４Ａ及び７１６Ａ並びにブロック７１４Ｂ及び７１６Ｂは、図２Ａのブロック２２６Ａ、図２Ｂのブロック２３４Ｂ又はそれぞれ図４のメッセージ４０３Ａ及び４０３Ｂの送信に対応し得る。ブロック７１８Ａ及びブロック７１８Ｂは各々、図２Ａのブロック２２８Ａ又は図２Ｂのブロック２３６Ｂに対応し得る。
[00158]７２０において、７１６ＢにおいてＵＥ７００に対するＬｂｙＲが受信された場合、ｉ３ ＰＳＡＰ７８０は、ＬｂｙＲにおいて示されるＥＬＳ７９４に位置要求を送信することによってＬｂｙＲを逆参照し、要求にＬｂｙＲを含める。ブロック７２０は、図４の質問４０４Ｂの送信に対応し得る。
[00159]７２２において、ＥＬＳ７９４は、例えば制御プレーン位置特定解決法又はユーザプレーン位置特定解決法を使用してＵＥ７００の現在の位置を取得するために、７２０において受信されたＬｂｙＲに含まれる情報（例えば、制御プレーン位置特定ではＵＥ７００のローカル若しくはグローバルの識別情報及びサービングＭＭＥ／ＳＧＳＮ ＩＤ又はユーザプレーン位置特定ではローカルＵＥ ＩＰアドレス）を使用する。ブロック７２２は、ＵＥ７００の位置を決定することに関して、図２Ａのブロック２１８Ａ及び／若しくは２２２Ａ又は図２Ｂのブロック２１６Ｂから２２６Ｂ若しくはブロック２２８Ｂのいずれかと同様であり、又は同じであり得る。
[00160]７２４において、ＥＬＳ７９４はＵＥ７００の現在の位置をｉ３ ＰＳＡＰ７８０に返す。ブロック７２０及び７２４は、図２Ａのブロック２３２Ａ又は図２Ｂのブロック２３８Ｂに対応し得る。
[00161]図８は、本開示の少なくとも一態様による、図５を参照して上で説明されたような、ＯＴＴ ＳＰを介する緊急呼に対するＩＭＳ ＬＲＦのサポートのための例示的な呼フローを示し、図５に関連して前に説明されたＩＭＳ ＬＲＦのサポートのための対話を拡張し得る。図８に示される呼フローは、図５、図３、図１Ｂ又は図１Ａに示されるアーキテクチャを使用して実行され得る。結果として、図８のＵＥ８００は、図１ＡのＵＥ１からＮのいずれか、ＵＥ２００、ＵＥ３００又はＵＥ５００のいずれかに対応し得る。同様に、ＯＴＴ ＳＰ８５０は、ＯＴＴ ＳＰ１５０、ＯＴＴ ＳＰ３５０又はＯＴＴ ＳＰ５５０に対応し得る。同様に、ＡＮ／ＰＣＮ８９２は、ＡＮ５２０及びＭＮＯ５９０のＰＣＮ部分、ＡＮ３２０及びＰＣＮ３４０又はＡＮ１２０及びＣＮ１４０に対応することがあり、アクセスネットワークノード２４０を含むことがある。同様に、ＩＭＳ８９４は、ＩＭＳ５４０、ＰＣＮ３４０内のＩＭＳ又はＣＮ１４０内のＩＭＳに対応し得る。同様に、中間のＣＳの宛先８６３は、ＳＲ５６３、ＳＲ３６０又はＳＲ１６０に対応し得る。同様に、ＥＳＩｎｅｔ８６０は、ＥＳＩｎｅｔ５６０、ＥＳＩｎｅｔ３６０又はＥＳＩｎｅｔ１６０に対応し得る。同様に、ｉ３ ＰＳＡＰ８８０は、ｉ３ ＰＳＡＰ５８０、ＰＳＡＰ３８０又はＰＳＡＰ１８０に対応し得る。同様に、レガシーＰＳＡＰ８８２は、レガシーＰＳＡＰ５８２、ＰＳＡＰ３８０又はＰＳＡＰ１８０に対応し得る。同様に、サービングＭＮＯ８９０はサービングＭＮＯ５９０に対応し得る。
[00162]図９は、本開示の少なくとも一態様による、図６を参照して上で説明されたような、ＯＴＴ ＳＰを介した緊急呼に対するＩＭＳ Ｅ−ＣＳＣＦのサポートのための例示的な呼フローを示し、図６に関連して前に説明されたＩＭＳ Ｅ−ＣＳＣＦのサポートのための対話を拡張し得る。図９に示される呼フローは、図６、図３、図１Ｂ又は図１Ａに示されるアーキテクチャを使用して実行され得る。結果として、図９のＵＥ９００は、図１ＡのＵＥ１からＮのいずれか、ＵＥ２００、ＵＥ３００又はＵＥ６００のいずれかに対応し得る。同様に、ＯＴＴ ＳＰ９５０は、ＯＴＴ ＳＰ１５０、ＯＴＴ ＳＰ３５０又はＯＴＴ ＳＰ６５０に対応し得る。同様に、ＡＮ／ＰＣＮ９９２は、ＡＮ６２０及びＭＮＯ６９０のＰＣＮ部分、ＡＮ３２０及びＰＣＮ３４０又はＡＮ１２０及びＣＮ１４０に対応することがあり、アクセスネットワークノード２４０を含むことがある。同様に、ＩＭＳ９９４は、ＩＭＳ６４０、ＰＣＮ３４０内のＩＭＳ又はＣＮ１４０内のＩＭＳに対応し得る。同様に、ＳＲ９６３は、ＳＲ６６３、ＳＲ３６０又はＳＲ１６０に対応し得る。同様に、ＥＳＩｎｅｔ９６０は、ＥＳＩｎｅｔ６６０、ＥＳＩｎｅｔ３６０又はＥＳＩｎｅｔ１６０に対応し得る。同様に、ｉ３ ＰＳＡＰ９８０は、ｉ３ ＰＳＡＰ６８０、ＰＳＡＰ３８０又はＰＳＡＰ１８０に対応し得る。同様に、レガシーＰＳＡＰ９８２は、レガシーＰＳＡＰ６８２、ＰＳＡＰ３８０又はＰＳＡＰ１８０に対応し得る。同様に、サービングＭＮＯ９９０はサービングＭＮＯ６９０に対応し得る。
[00163]図８及び図９に示される呼フローは類似しており、ＩＭＳ８９４／９９４の外部のエンティティ（例えば、ＵＥ８００／９００及びＯＴＴ ＳＰ８５０／９５０）の観点からは、単一の共通の解決法の一部として見られることがある。ＩＭＳ８９４／９９４は図８及び図９の呼フローにおいては異なるように振る舞うが、両方の呼フローにおけるＩＭＳ８９４／９９４とＯＴＴ ＳＰ８５０／９５０との間の対話は、ＩＥＴＦによるＳＩＰの定義（例えば、ＩＥＴＦ ＲＦＣ ３２６１における）に適合し得るので、ＳＩＰプロキシとして動作するＯＴＴ ＳＰ８５０／９５０によって両方ともサポートされ得る。その場合、ＯＴＴ ＳＰ８５０／９５０は、サービングＭＮＯ８９０／９９０（又はサービングＭＮＯ８９０／９９０中のＩＭＳ８９４／９９４）が図８のようにＩＭＳ ＬＲＦのサポートを利用するのか、又は図９のようにＩＭＳ Ｅ−ＣＳＣＦのサポートを利用するのかを、前もって知る必要はないことがある。代わりに、ＯＴＴ ＳＰ８５０／９５０は、ＩＭＳ ＬＲＦのサポートが提供されるか、又はＩＭＳ Ｅ−ＣＳＣＦのサポートが提供されるかに応じて、事前に設定されたＳＩＰ規則に従って反応するだけであり得る。このことは、サービングＭＮＯ８９０／９９０が、ＵＥ８００／９００又はＯＴＴ ＳＰ８５０／９５０からのサポートに対する変更を必要とすることなく、ＩＭＳ ＬＲＦのサポートからＩＭＳ Ｅ−ＣＳＣＦのサポートに、又はその逆方向に移行することを可能にし得る。このことはまた、ＯＴＴ ＳＰ８５０／９５０が、１つ又は複数のＭＮＯ（例えば、ＭＮＯ８９０）から図８に従ってＩＭＳ ＬＲＦのサポートを受けることと、１つ又は複数の他のＭＮＯ（例えば、ＭＮＯ９９０）から図９に従ってＩＭＳ Ｅ−ＣＳＣＦのサポートを受けることとが、これらのＭＮＯの１つからＯＴＴ ＳＰ８５０／９５０にアクセスする異なるＵＥ（例えば、ＵＥ８００及びＵＥ９００）によって発信され得る緊急呼について、可能になり得る。
[00164]図８及び図９の呼フローは、図３の解決法Ｓ１に適用される。図３の解決法Ｓ２について、呼フローは、各呼フローの中の８０６／９０６において以下で説明される緊急呼要求がＵＥデータ及び／又はＭＮＯデータの一部若しくは全てを含まないことを除き、殆んど同じであり得る。代わりに、ＯＴＴ ＳＰ８５０／９５０は、８０６／９０６に続いて、（例えば、要求を含むＳＩＰ ＩＮＦＯをＵＥ８００／９００に送信し、ＵＥ８００／９００が要求されたＵＥデータ及び／又はＭＮＯデータをＳＩＰ ＯＫ若しくはＳＩＰ ＩＮＦＯにおいて返すことによって）ＵＥデータ及び／又はＭＮＯデータについてＵＥ８００／９００に質問する。解決法Ｓ２では、ＯＴＴ ＳＰ８５０／９５０はまた、図８の８２６及び図９の９２０においてＵＥ８００／９００が送信する更新されたＭＮＯデータについて、ＵＥ８００／９００に質問する必要があり得る。しかしながら、この要求は、８０６／９０６に続いてＵＥ８００／９００に最初に送信されるＵＥデータ及びＭＮＯデータに対して、（上で言及された）要求と暗黙的又は明示的に組み合わされ得る。
[00165]加えて、図３の解決法Ｓ２では、ＵＥ８００／９００は、図８及び図９の８０６／９０６より前にユーザが緊急呼を引き起こしたことを検出しないことがあり（例えば、「９１１」などの緊急番号をユーザがダイヤルしたことを認識しないことがあり）、緊急呼要求ではなく図８及び図９の８０６／９０６において普通の呼要求をＯＴＴ ＳＰ８５０／９５０に送信することがある。ＯＴＴ ＳＰ８５０／９５０は次いで、８０６／９０６において送信された呼要求が緊急呼のためのものであることを認識することがあり（例えば、ダイヤルされた数字が「９１１」などの緊急番号のためのものであることを検出することがあり）、図８及び図９に示される８０８／９０８に進む前にＵＥ８００／９００からのＭＮＯデータ及び／又はＵＥデータを要求することがある。図３の解決法Ｓ２についてすぐ上で説明されたように修正されない図８及び図９の他の動作は、以下で説明されるように行われ得る。
[00166]図８に示される対話は、ＵＥ８００がサービングＭＮＯ８９０にアクセスしている（例えば、サービングＭＮＯ８９０を介してＯＴＴ ＳＰ８５０にアクセスしている）状況において、ＯＴＴ ＳＰ８５０を介して緊急呼を引き起こすＵＥ８００に対して当てはまり得る。図８の８０２において、ＵＥ８００は、ＯＴＴ ＳＰ８５０を使用して緊急呼をサポートするために、サービングＭＮＯ８９０の中のＡＮ又はＰＣＮ８９２からのデータを要求し得る。例えば、これは、ユーザが緊急呼引き起こしていることをＵＥ８００が検出するときに発生し得る。ブロック８０２は任意選択であり、常に存在するとは限らない。
[00167]８０４において、８０２に応答して、又は、何らかの条件が発生したとき（例えば、ＵＥ８００がＡＮ／ＰＣＮ８９２に接続する、新しいＭＭＥ若しくはＳＧＳＮへのトラッキングエリア若しくはルーティングエリアの更新を実行する、又は新しいＭＭＥ若しくはＳＧＳＮへのハンドオーバーが発生する）、ＡＮ又はＰＣＮ８９２は、ＭＮＯデータをＵＥ８００に送信する。ＭＮＯデータは、（ｉ）サービングＭＮＯ８９０のＩＭＳアドレス（例えば、ＩＭＳ８９４の中のＬＲＦのアドレス）、（ｉｉ）制御プレーン位置特定が使用され得る場合、ＵＥ８００の現在のサービングＭＭＥ若しくは現在のサービングＳＧＳＮの識別情報、（ｉｉｉ）ユーザプレーン位置特定が使用され得る場合、ＵＥ８００のＭＮＯにより割り当てられたＩＰアドレス及び／又は（ｉｖ）ＵＥ８００のグローバル識別情報（例えば、ＩＭＳＩ又はＭＳＩＳＤＮ）と、ＵＥ８００のサービングＭＭＥ若しくはサービングＳＧＳＮによって割り当てられたＵＥ８００のローカル識別情報とのいずれかを含み得る。
[00168]８０６において、ＵＥ８００のユーザが緊急呼を引き起こしたことをＵＥ８００が検出したことに応答して（例えば、ユーザが番号「９１１」をダイヤルしたことをＵＥ８００が検出する場合）、ＵＥ８００は、緊急呼要求をＯＴＴ ＳＰ８５０に送信し、８０４において取得されたＭＮＯデータと、場合によっては、ＵＥ８００に知られている追加のＵＥデータとを含める。ＵＥデータは、ＵＥ８００のグローバル識別情報（例えば、ＩＭＳＩ又はＭＳＩＳＤＮ）と、場合によっては、８０４において受信されない場合にはＵＥ８００のＭＮＯにより割り当てられたＩＰアドレスとを含み得る。８０６における緊急呼要求は、ＳＩＰ ＩＮＶＩＴＥであることがあり、又は、ＯＴＴ ＳＰ８５０に特有の何らかの他のプロトコルのためのメッセージであることがある。ブロック８０６は、図５の緊急要求５０１の送信に対応し得る。
[00169]８０８において、８０６でサービングＭＮＯ８９０においてＩＭＳアドレスを受信したことに基づいて（例えば、ここでＩＭＳアドレスは８０６において受信されたＭＮＯデータの一部であることがあり、８０６において送信されたＳＩＰ ＩＮＶＩＴＥのＲｏｕｔｅヘッダに含まれるＬＲＦアドレスであることがある）、ＯＴＴ ＳＰ８５０は、サービングＭＮＯ８９０の中のＩＭＳアドレスによって示されるＩＭＳ８９４に（例えば、ＩＭＳ８９４の中のＬＲＦに）ＳＩＰ ＩＮＶＩＴＥを送信する。ＳＩＰ ＩＮＶＩＴＥは、ＭＮＯデータと８０６において受信された任意のＵＥデータを含み、緊急呼を示し、ＯＴＴ ＳＰ８５０の識別情報と場合によっては位置（例えば、国）とを含む。ＳＩＰ ＩＮＶＩＴＥは、８０６において受信された任意のＳＩＰ ＩＮＶＩＴＥの部分的な又は完全なコピーであり得る。ブロック８０８は、図５のＳＩＰ ＩＮＶＩＴＥ５０２Ａの送信に対応し得る。
[00170]幾つかの場合、８０８において送信されるＳＩＰ ＩＮＶＩＴＥは、ＩＭＳ８９４中のＬＲＦに転送される前に、セキュリティのためにサービングＭＮＯ ＩＭＳ８９４中の境界制御機能（例えば、ＩＢＣＦ）においてまず受信され得る（図８には示されない）。ＩＭＳ８９４（例えば、ＩＭＳ８９４中のＬＲＦ又はＩＢＣＦ）は、例えば、サービングＭＮＯ８９０とＯＴＴ ＳＰ８５０との間の何らかのビジネス関係に基づく事前に構成されたデータを使用して、及び場合によっては、８０８においてＳＩＰ ＩＮＶＩＴＥを移送するためにＯＴＴ ＳＰ８５０とサービングＭＮＯ ＩＭＳ８９４との間の安全なＩＰ接続を使用して、８０８において送信されるＳＩＰ ＩＮＶＩＴＥが有効なＯＴＴ ＳＰから来ることをまず検証し得る。幾つかの場合、８１０において、ＩＭＳ８９４（例えば、ＩＭＳ８９４中のＬＲＦ）は、例えば制御プレーン位置特定解決法又はユーザプレーン位置特定解決法を使用して、ＵＥ８００の位置を取得するために、ＭＮＯデータと８０８において送信された任意のＵＥデータとを使用する。幾つかの他の場合、ブロック８１０は存在せず、ＩＭＳ８９４は、８０６において送信され８０８においてＯＴＴ ＳＰ８５０によってＩＭＳ８９４に移送される緊急呼要求にＵＥ８００により含められるＬｂｙＶなどの、８０８においてＳＩＰ ＩＮＶＩＴＥの中で受信された他のデータから、ＵＥ８００の位置（例えば、概略的な位置）を決定し得る。
[00171]ＩＭＳ８９４（例えば、ＩＭＳ８９４中のＲＤＦ）は次いで、宛先ＰＳＡＰ８８０／８８２を決定し、又は、ＵＥ８００の位置に対応する宛先ＰＳＡＰ８８０／８８２に向かってルーティングし、宛先ＰＳＡＰ８８０／８８２への、又はそれに向かうＯＴＴ ＳＰ８５０からの呼のルーティングを可能にするように、ルーティングＵＲＩ（ルートＵＲＩとも呼ばれ得る）を導出する。ルーティングＵＲＩは、ＰＳＡＰ８８０／８８２の、又は中間の宛先８６３（例えば、レガシーＰＳＡＰ８８２の場合はＳＲ、ｉ３対応ＰＳＡＰ８８０の場合はＥＳＩｎｅｔ８６０への流入点）の、アドレス若しくは識別情報を含むことがあり、ＯＴＴ ＳＰ８５０の識別情報及び／又はＯＴＴ ＳＰ８５０の位置（例えば、位置がサービングＭＮＯ８９０と同じ国の中にあるか、又は異なる国の中にあるか）に依存し得る。ＩＭＳ８９４（例えば、ＩＭＳ８９４中のＬＲＦ）はまた、より後の時間における、ＥＳＩｎｅｔ８６０からの、又はＰＳＡＰ８８０／８８２からのＵＥ８００に対する後続の位置要求を可能にするために、基準識別子（ＩＤ）を決定する。基準ＩＤは、レガシーＰＳＡＰ８８２の場合は（ｉ）ＥＳＲＫ若しくは（ｉｉ）ＥＳＲＤ及びＭＳＩＳＤＮのいずれかであることがあり、又は、ｉ３対応ＰＳＡＰ８８０の場合は（ｉｉｉ）位置ＵＲＩであることがある。
[00172]８１２において、ＩＭＳ８９４（例えば、ＩＭＳ８９４中のＬＲＦ）は、ＳＩＰ ３００ Ｍｕｌｔｉｐｌｅ Ｃｈｏｉｃｅｓメッセージの中で、ルーティングＵＲＩと基準ＩＤとをＯＴＴ ＳＰ８５０に返す。ＯＴＴ ＳＰ８５０の識別情報が完全には有効ではなかった場合、又は、ＯＴＴ ＳＰ８５０とのビジネス関係がサービングＭＮＯ８９０によるルーティングのサポートを許可するだけである場合、ＩＭＳ８９４は位置（例えば、ＬｂｙＶ）をＯＴＴ ＳＰ８５０に返さないことがあることに留意されたい。ブロック８１２は、図５のＳＩＰ ３００ Ｍｕｌｔｉｐｌｅ Ｃｈｏｉｃｅｓ５０２Ｂの送信に対応し得る。
[00173]８１４において、ＩＭＳ８９４（例えば、ＩＭＳ８９４中のＬＲＦ）が制御プレーン位置特定を使用する必要があり得る場合、ＩＭＳ８９４は、ＭＮＯデータの変化（例えば、サービングＭＭＥ又はサービングＳＧＳＮのアドレスの変化）の通知に同意するために、ＳＩＰ ＳＵＢＳＣＲＩＢＥメッセージをＯＴＴ ＳＰ８５０に送信する。ＩＭＳ８９４はまた、呼の終了の通知に同意するために、別個のＳＩＰ ＳＵＢＳＣＲＩＢＥメッセージをＯＴＴ ＳＰ８５０に送信し得る（図８には示されない）。
[00174]８１６において、８１４が存在する場合、ＯＴＴ ＳＰ８５０は、２００ ＯＫメッセージ（図８には示されない）をＩＭＳ８９４に返し、次いで、８１４におけるＭＮＯデータへの同意の場合には現在のＭＮＯデータを、及び／又は呼の終了への同意の場合には現在の呼の状態を搬送する、受信された各ＳＵＢＳＣＲＩＢＥメッセージに対するＮＯＴＩＦＹメッセージを返す。
[00175]８１２に続いて（及び、場合によっては８１６が存在すれば８１６に続いて）、ＯＴＴ ＳＰ８５０は、宛先ＰＳＡＰがレガシーＰＳＡＰ８８２であるかｉ３対応ＰＳＡＰ８８０であるかを、８１２において返されるルーティングＵＲＩ又は基準ＩＤの内容から決定する。レガシーＰＳＡＰ８８２の場合、ＯＴＴ ＳＰ８５０は、ＣＳを使用して、ＰＳＡＰ８８２に、又はそこに向かって呼を転送し得る。一実施形態では、ＯＴＴ ＳＰ８５０は、８１８Ａにおいて、ＩＳＵＰ ＩＡＭメッセージを、８１２において受信されたルートＵＲＩにおいて示される中間のＣＳ宛先８６３（例えば、ＳＲ）に送信する。ＯＴＴ ＳＰ８５０はまた、８１２において受信された基準ＩＤ中の任意のＥＳＲＫ又はＥＳＲＤ及びＭＳＩＳＤＮを、ＩＳＵＰ ＩＡＭに含める。ブロック８１８Ａは、図５の要求５０３Ａの送信に対応し得る。
[00176]８２０Ａにおいて、中間のＣＳ宛先８６３は、呼をレガシーＰＳＡＰ８８２に転送し、８１８Ａにおいて受信されたＥＳＲＫ又はＥＳＲＤ及びＭＳＩＳＤＮを含める。
[00177]８２２Ａにおいて、呼の確立の残りが実行される。そうすると、ブロック８１８Ｂ、８２０Ｂ、及び８２２Ｂは実行されない。
[00178]ＯＴＴ ＳＰ８５０が８１２に続いてレガシーＰＳＡＰ８８２の代わりにｉ３ ＰＳＡＰ８８０を決定するとき、ブロック８１８Ａ、８２０Ａ、及び８２２Ａは実行されない。代わりに、ＯＴＴ ＳＰ８５０は、ＰＳＡＰ８８０に、又はそこに向かって呼を転送する。一実施形態では、ＯＴＴ ＳＰ８５０は、８１８Ｂにおいて、８１２において基準ＩＤの中で受信された位置ＵＲＩを含むＳＩＰ ＩＮＶＩＴＥを送信することによって、８１２において受信されたルーティングＵＲＩによって示されるＥＳＩｎｅｔ８６０に呼を転送する。ブロック８１８Ｂは、図５の要求５０３Ｂの送信に対応し得る。
[00179]８２０Ｂにおいて、ＥＳＩｎｅｔ８６０は、呼をｉ３ ＰＳＡＰ８８０に転送し、８１８Ｂにおいて受信された位置ＵＲＩを含める。
[00180]８２２Ｂにおいて、呼の確立の残りが実行される。
[00181]８２４において、ＭＮＯデータに変化がある（例えば、ＵＥ８００が新しいＳＧＳＮ又はＭＭＥにハンドオーバーされる）場合、及び、サービングＭＮＯ８９０がＵＥ８００に対する制御プレーン位置特定を使用し得る場合、ＡＮ又はＰＣＮ８９２は、新しいＭＮＯデータ（例えば、ＵＥ８００の新しいサービングＭＭＥ又はＳＧＳＮの識別情報及び新しいサービングＭＭＥ又はＳＧＳＮにおけるＵＥ８００の新しいローカル識別情報）をＵＥ８００に送信する。８２４における新しいＭＮＯデータの送信は、（例えば、ＯＴＴ ＳＰ８５０を介したＵＥ８００のための緊急呼が進行中であることをサービングＭＮＯ８９０中のＡＮ又はＰＣＮ８９２が知らない状態で）ＭＮＯデータが変化するときには常に自動的であることがあり、又は、８０２においてＭＮＯデータに対する要求を以前に送信しているＵＥ８００によって引き起こされることがある。
[00182]８２６において、ＵＥ８００は、例えば、ＵＥ８００とＯＴＴ ＳＰ８５０との間でＳＩＰが使用されるときにはＳＩＰ ＩＮＦＯメッセージを使用して、新しいＭＮＯデータをＯＴＴ ＳＰ８５０に転送する。
[00183]８２８において、ＩＭＳ８９４が８１４においてＭＮＯデータの変化の通知に同意した場合、ＯＴＴ ＳＰ８５０は、ＳＩＰ ＮＯＴＩＦＹメッセージにおいて、新しいＭＮＯデータをＩＭＳ８９４（例えば、ＩＭＳ８９４中のＬＲＦ）に送信する。新しいＭＮＯデータは、ＩＭＳ８９４による今後の使用のために記憶される。例えば、新しいＭＮＯデータは、ＵＥ８００の位置を取得するのを助けるために、ブロック８３２Ａ又はブロック８３２Ｂにおいて後で使用され得る。
[00184]８３０Ａにおいて、レガシーＰＳＡＰ８８２の場合、ＰＳＡＰ８８２又はＡＬＩ（例えば、ＡＬＩ５６１）などのＰＳＡＰ８８２と関連付けられるエンティティは、ＵＥ８００の位置を要求するために、Ｅ２インターフェースＥＳＰＯＳＲＥＱメッセージ（例えば、ＴＩＡ／ＡＴＩＳ共同規格Ｊ−ＳＴＤ−０３６において定義されるような）を、８２０Ａにおいて受信されたＥＳＲＫ又はＥＳＲＤによって示されるＩＭＳ８９４（例えば、ＬＲＦ）に送信することができ、８２０Ａにおいて受信されたＥＳＲＫとＥＳＲＤのいずれかとＭＳＩＳＤＮとを含める。ブロック８３０Ａは、図５の質問５０４Ａの送信に対応し得る。
[00185]８３２Ａにおいて、ＩＭＳ８９４（例えば、ＬＲＦ）は、ＵＥ８００を識別するために８３０Ａにおいて受信されたＥＳＲＫ又はＭＳＩＳＤＮを使用し、制御プレーン位置特定解決法又はユーザプレーン位置特定解決法を使用してＵＥ８００の位置を取得するために、８０８において受信された任意のＵＥデータ、及び／又は８０８で、若しくは８２８が存在する場合には８２８で受信されたＭＮＯデータを使用する。
[00186]８３４Ａにおいて、ＩＭＳ８９４（例えば、ＬＲＦ）は、位置をＰＳＡＰ８８２に（又はＡＬＩなどのＰＳＡＰ８８２と関連付けられるエンティティに）返す。
[00187]８３０Ｂにおいて、ｉ３対応ＰＳＡＰ８８０の場合、ｉ３ ＰＳＡＰ８８０は、位置ＵＲＩにおいて示されるＩＭＳ８９４（例えば、ＩＭＳ８９４中のＬＲＦ）に位置要求を送信し、位置ＵＲＩを搬送することによって、８２０Ｂにおいて受信される位置ＵＲＩを逆参照する。ブロック８３０Ｂは、図５の質問５０４Ｂの送信に対応し得る。
[00188]８３２Ｂにおいて、ＩＭＳ８９４（例えば、ＬＲＦ）は、ＵＥ８００を識別するために８３０Ｂにおいて受信された位置ＵＲＩを使用し、制御プレーン位置特定解決法又はユーザプレーン位置特定解決法を使用してＵＥ８００の位置を取得するために、８０８において受信された任意のＵＥデータ及び／又は８０８で、若しくは８２８が存在する場合には８２８で受信されたＭＮＯデータを使用する。
[00189]８３４Ｂにおいて、ＩＭＳ８９４（例えば、ＬＲＦ）は、位置をＰＳＡＰ８８０に返す。
[00190]ＥＳＩｎｅｔ８６０がＵＥ８００の位置をＩＭＳ８９４から（例えば、ＩＭＳ８９４中のＬＲＦから）取得し、その位置に基づいて８２０Ｂにおいて緊急呼を正しいＰＳＡＰ８８０にルーティングすることを可能にするために、８３０Ｂ、８３２Ｂ及び８３４Ｂに類似する、又はそれらと同じブロックが、８１８Ｂに続いて存在することがある。その場合、ＥＳＩｎｅｔ８６０（例えば、ＥＳＲＰ５６６などのＥＳＩｎｅｔ８６０中のＥＳＲＰ）は、８３０Ｂと同様の、又は同じブロックにおいて、ＵＥ８００に対する位置要求をＩＭＳ８９４に送信することができ、８３４Ｂと同様の、又は同じブロックにおいて、ＵＥ８００の位置をＩＭＳ８９４から受信することができる。
[00191]図９に示される対話は、ＵＥ９００がサービングＭＮＯ９９０にアクセスしている（例えば、サービングＭＮＯ９９０を介してＯＴＴ ＳＰ９５０にアクセスしている）状況において、ＯＴＴ ＳＰ９５０を介して緊急呼を引き起こすＵＥ９００に対して当てはまり得る。図９の９０２において、ＵＥ９００は、ＯＴＴ ＳＰ９５０を使用して緊急呼をサポートするために、サービングＭＮＯ９９０の中のＡＮ又はＰＣＮ９９２からのデータを要求し得る。例えば、これは、ユーザが緊急呼引き起こしていることをＵＥ９００が検出するときに発生し得る。動作９０２は任意選択であり、常に発生するとは限らない。
[00192]９０４において、９０２に応答して、又は、何らかの条件が発生したとき（例えば、ＵＥ９００がＡＮ／ＰＣＮ９９２に接続する、ＡＮ／ＰＣＮ９９２中の新しいＭＭＥ若しくはＳＧＳＮへのトラッキングエリア若しくはルーティングエリアの更新を実行する、又は新しいＭＭＥ若しくはＳＧＳＮへのハンドオーバーが発生する）、ＡＮ又はＰＣＮ９９２は、ＭＮＯデータをＵＥ９００に送信する。ＭＮＯデータは、（ｉ）サービングＭＮＯ９９０のＩＭＳアドレス（例えば、ＩＭＳ９９４の中のＥ−ＣＳＣＦのアドレス）、（ｉｉ）制御プレーン位置特定が使用され得る場合、ＵＥ９００の現在のサービングＭＭＥ若しくは現在のサービングＳＧＳＮの識別情報、（ｉｉｉ）ユーザプレーン位置特定が使用され得る場合、ＵＥ９００のＭＮＯにより割り当てられたＩＰアドレス及び／又は（ｉｖ）ＵＥ９００のグローバル識別情報（例えば、ＩＭＳＩ又はＭＳＩＳＤＮ）と、ＵＥ９００のサービングＭＭＥ若しくはＳＧＳＮによって割り当てられたＵＥ９００のローカル識別情報とのいずれかを含み得る。
[00193]９０６において、ＵＥ９００のユーザが緊急呼を引き起こしたことをＵＥ９００が検出したことに応答して（例えば、ユーザが番号「９１１」をダイヤルしたことをＵＥ９００が検出する場合）、ＵＥ９００は、緊急呼要求をＯＴＴ ＳＰ９５０に送信し、９０４において取得されたＭＮＯデータと、場合によっては、ＵＥ９００に知られている追加のＵＥデータとを含める。ＵＥデータは、ＵＥ９００のグローバル識別情報（例えば、ＩＭＳＩ又はＭＳＩＳＤＮ）と、場合によっては、９０４において受信されない場合にはＵＥ９００のＭＮＯにより割り当てられたＩＰアドレスとを含み得る。９０６における緊急呼要求は、ＳＩＰ ＩＮＶＩＴＥであることがあり、又は、ＯＴＴ ＳＰ９５０に特有の何らかの他のプロトコルのためのメッセージであることがある。ブロック９０６は、図６の緊急呼要求６０１の送信に対応し得る。
[00194]９０８において、９０６で受信されたＭＮＯデータの一部としてＩＭＳアドレスを受信したことに基づいて（例えば、ここでＩＭＳアドレスは９０６において受信されたＳＩＰ ＩＮＶＩＴＥのＲｏｕｔｅヘッダ中のＥ−ＣＳＣＦアドレスである）、ＯＴＴ ＳＰ９５０は、サービングＭＮＯ９９０の中のＩＭＳアドレスによって示されるＩＭＳ９９４に（例えば、ＩＭＳ９９４の中のＥ−ＣＳＣＦに）ＳＩＰ ＩＮＶＩＴＥを送信する。９８０において送信されるＳＩＰ ＩＮＶＩＴＥは、ＭＮＯデータと９０６において受信された任意のＵＥデータとを含み、緊急呼を示し、ＯＴＴ ＳＰ９５０の識別情報と場合によっては位置（例えば、国）とを含む。９０８において送信されるＳＩＰ ＩＮＶＩＴＥは、９０６において受信された任意のＳＩＰ ＩＮＶＩＴＥの部分的な又は完全なコピーであり得る。ブロック９０８は、図６のＳＩＰ ＩＮＶＩＴＥ６０２の送信に対応し得る。
[00195]幾つかの場合、９０８において送信されるＳＩＰ ＩＮＶＩＴＥは、ＩＭＳ９９４中のＥ−ＣＳＣＦに転送される前に、セキュリティのためにサービングＭＮＯ ＩＭＳ９９４中の境界制御機能（例えば、ＩＢＣＦ）においてまず受信され得る（図９には示されない）。ＩＭＳ９９４（例えば、ＩＭＳ９９４中のＥ−ＣＳＣＦ又はＩＢＣＦ）は、例えば、サービングＭＮＯ９９０とＯＴＴ ＳＰ９５０との間の何らかのビジネス関係に基づく事前に構成されたデータを使用して、及び場合によっては、９０８においてＳＩＰ ＩＮＶＩＴＥを移送するためにＯＴＴ ＳＰ９５０とサービングＭＮＯ ＩＭＳ９９４との間の安全なＩＰ接続を使用して、９０８において送信されるＳＩＰ ＩＮＶＩＴＥが有効なＯＴＴ ＳＰ９５０から来ることを検証し得る。幾つかの場合、９１０において、ＩＭＳ９９４（例えば、ＩＭＳ９９４中のＬＲＦ）は、例えば制御プレーン位置特定解決法又はユーザプレーン位置特定解決法を使用して、ＵＥ９００の位置を取得するために、ＭＮＯデータと９０８において受信された任意のＵＥデータとを使用し得る。幾つかの他の場合、ブロック９１０は存在せず、ＩＭＳ９９４は、９０６において送信され９０８においてＯＴＴ ＳＰ９５０によってＩＭＳ９９４に移送される緊急呼要求にＵＥ９００により含められるＬｂｙＶなどの、９０８においてＳＩＰ ＩＮＶＩＴＥの中で受信された他のデータから、ＵＥ９００の位置（例えば、概略的な位置）を決定し得る。
[00196]９０８に続き得る、又は９１０が存在する場合には９１０に続き得る９１１において、ＩＭＳ９９４（例えば、ＩＭＳ９９４中のＲＤＦ）は、宛先ＰＳＡＰ９８０／９８２を決定し、又は、（例えば、９１０において取得されるような）ＵＥ９００の位置に対応する宛先ＰＳＡＰ９８０／９８２に向かってルーティングし、宛先ＰＳＡＰ９８０／９８２への、又はそれに向かうＩＭＳ９９４からの呼のルーティングを可能にするように、ルーティングＵＲＩ（ルートＵＲＩとも呼ばれる）を決定する。ルーティングＵＲＩは、（ｉ）ＰＳＡＰ９８０／９８２のアドレス若しくは識別情報、又は（ｉｉ）レガシーＰＳＡＰ９８２の場合のＳＲ９６３若しくはｉ３対応ＰＳＡＰ９８０の場合のＥＳＩｎｅｔ９６０への流入点などの、中間の宛先のアドレス若しくは識別情報を示し得る。９１１における宛先ＰＳＡＰ９８０／９８２、又は宛先ＰＳＡＰ９８０／９８２に向かうルートを決定することの一部として、ＩＭＳ９９４（例えば、ＩＭＳ９９４中のＬＲＦ）は、より後の時間における、ＥＳＩｎｅｔ９６０又はＰＳＡＰ９８０／９８２からのＵＥ９００に対する後続の位置要求を可能にするために、基準識別子（ＩＤ）を決定する。基準ＩＤは、レガシーＰＳＡＰ９８２の場合は（ｉ）ＥＳＲＫ若しくは（ｉｉ）ＥＳＲＤ及びＭＳＩＳＤＮのいずれか、又は、ｉ３対応ＰＳＡＰ９８０の場合は（ｉｉｉ）位置ＵＲＩであり得る。ＩＭＳ９９４（例えば、ＩＭＳ９９４中のＥ−ＣＳＣＦ）はまた、９１１において、宛先ＰＳＡＰがレガシーＰＳＡＰ９８２であるかｉ３対応ＰＳＡＰ９８０であるかを（例えば、９１１において決定されたルーティングＵＲＩ又は基準ＩＤの内容から）決定する。
[00197]幾つかの実装形態では、９１０が存在するときの９１０におけるＵＥ９００の位置特定及び宛先ＰＳＡＰの決定、又は、９１１においてルーティングＵＲＩと基準ＩＤとを決定することを含む９１１における宛先ＰＳＡＰに向かうルートが、（例えば、ＩＭＳ９９４が図６のＩＭＳ６４０に対応する場合）ＩＭＳ９９４において、ＬＲＦ（例えば、ＬＲＦ６４８）によって実行され、場合によってはＲＤＦ（例えば、ＲＤＦ６４６）によって支援され得る。これらの実装形態では、９０８において送信されるＳＩＰ ＩＮＶＩＴＥは、ＩＭＳ９９４においてＥ−ＣＳＣＦ（例えば、Ｅ−ＣＳＣＦ６４３）によって受信され、次いでＥ−ＣＳＣＦによってＩＭＳ９９４においてＬＲＦ（例えば、ＬＲＦ６４８）に転送され得る。ＩＭＳ９９４中のＬＲＦ（例えば、ＬＲＦ６４８）は次いで、９１０が存在する場合には９１０においてＵＥ９００の位置を取得し、ルーティングＵＲＩと基準ＩＤとを決定することを含めて９１１において宛先ＰＳＡＰを決定し、決定されたルーティングＵＲＩと基準ＩＤとをＳＩＰ ３００ Ｍｕｌｔｉｐｌｅ ＣｈｏｉｃｅｓメッセージにおいてＩＭＳ９９４中のＥ−ＣＳＣＦ（例えば、Ｅ−ＣＳＣＦ６４３）に返し得る。図９には示されていないが、Ｅ−ＣＳＣＦ（例えば、Ｅ−ＣＳＣＦ６４３）とＩＭＳ９９４中のＬＲＦ（例えば、ＬＲＦ６４８）との間のこの対話は、図６に関連して説明されたＥ−ＣＳＣＦ６４３とＬＲＦ６４８との間で要求６０３Ａと応答６０３Ｂとを送信することに対応し得る。
[00198]９１１においてレガシーＰＳＡＰ９８２を決定する場合、９１２Ａにおいて、ＩＭＳ９９４（例えば、ＩＭＳ９９４中のＭＧＣＦ）は、ＣＳを使用して、ＰＳＡＰ９８２に、又はそこに向かって呼を転送し得る。一実施形態では、ＩＭＳ９９４は、９０８又は（９１０が存在する場合は）９１０に続いて決定されるルーティングＵＲＩにおいて示されるＳＲ９６３に、９１２ＡにおいてＩＳＵＰ ＩＡＭメッセージを送信する。ＩＭＳ９９４はまた、９１１において決定された基準ＩＤにおいて示される、任意のＥＳＲＫ又はＥＳＲＤ及びＭＳＩＳＤＮをＩＳＵＰ ＩＡＭに含める。
[00199]９１４Ａにおいて、ＳＲ９６３は、呼をレガシーＰＳＡＰ９８２に転送し、９１２Ａにおいて受信されたＥＳＲＫ又はＥＳＲＤ及びＭＳＩＳＤＮを含める。
[00200]９１６Ａにおいて、呼の確立の残りが、ＵＥ９００と、ＯＴＴ ＳＰ９５０と、ＩＭＳ９９４と、ＳＲ９６３と、レガシーＰＳＡＰ９８２との間で実行される。そうすると、ブロック９１２Ｂ、９１４Ｂ、及び９１６Ｂは実行されない。
[00201]ＩＭＳ９９４が９１１においてレガシーＰＳＡＰ９８２の代わりにｉ３ ＰＳＡＰ９８０を決定するとき、ブロック９１２Ａ、９１４Ａ、及び９１６Ａは実行されない。代わりに、９１２Ｂにおいて、ＩＭＳ９９４（例えば、ＩＭＳ９９４中のＥ−ＣＳＣＦ）は、ＰＳＡＰ９８０に、又はそこに向かって緊急呼を転送する。一実施形態では、ＩＭＳ９９４は、９１１において決定された基準ＩＤからの位置ＵＲＩを含むＳＩＰ ＩＮＶＩＴＥを送信することによって、９１１において決定されたルーティングＵＲＩによって示されるＥＳＩｎｅｔ９６０に緊急呼を転送する。
[00202]９１４Ｂにおいて、ＥＳＩｎｅｔ９６０は、緊急呼をｉ３ ＰＳＡＰ９８０に転送し、９１２Ｂにおいて受信された位置ＵＲＩを含める。
[00203]９１６Ｂにおいて、呼の確立の残りが、ＵＥ９００と、ＯＴＴ ＳＰ９５０と、ＩＭＳ９９４と、ＥＳＩｎｅｔ９６０と、ｉ３ ＰＳＡＰ９８０との間で実行される。
[00204]９１８において、ＭＮＯデータに変化がある（例えば、ＵＥ９００がサービングＭＮＯ９９０の中の新しいＳＧＳＮ又はＭＭＥにハンドオーバーされる）場合、及び、サービングＭＮＯ９９０がＵＥ９００に対する制御プレーン位置特定を使用し得る場合、ＡＮ又はＰＣＮ９９２は、新しいＭＮＯデータ（例えば、ＵＥ９００の新しいサービングＭＭＥ又は新しいサービングＳＧＳＮの識別情報及び新しいサービングＭＭＥ又はＳＧＳＮにおけるＵＥ９００のローカル識別情報）をＵＥ９００に提供する。この新しいＭＮＯデータの送信は、（例えば、ＯＴＴ ＳＰ９５０を介したＵＥ９００のための緊急呼が進行中であることをサービングＭＮＯ９９０中のＡＮ又はＰＣＮ９９２が知らない状態で）ＭＮＯデータが変化するときには常に自動的であることがあり、又は、９０２において要求を以前に送信しているＵＥ９００によって引き起こされることがある。
[00205]９２０において、ＵＥ９００は、例えば、ＵＥ９００とＯＴＴ ＳＰ９５０との間でＳＩＰが使用されるときにはＳＩＰ ＩＮＦＯメッセージを使用して、新しいＭＮＯデータをＯＴＴ ＳＰ９５０に転送する。
[00206]９２２において、ＯＴＴ ＳＰ９５０は、例えばＳＩＰ ＩＮＦＯメッセージを使用して、新たなＭＮＯデータをＩＭＳ９９４に（例えば、ＩＭＳ９９４中のＥ−ＣＳＣＦに）転送する。ＭＮＯデータは、ＩＭＳ９９４による（例えば、ＩＭＳ９９４中のＬＲＦによる）今後の使用のために記憶される。
[00207]９２４Ａにおいて、レガシーＰＳＡＰ９８２の場合、ＰＳＡＰ９８２又はＰＳＡＰ９８２と関連付けられるエンティティ（例えば、ＡＬＩ６６１などのＡＬＩ）は、ＵＥ９００の位置を要求するために、Ｅ２インターフェースＥＳＰＯＳＲＥＱメッセージ（例えば、ＴＩＡ／ＡＴＩＳ規格Ｊ−ＳＴＤ−０３６において定義されるような）を、９１４Ａにおいて受信されたＥＳＲＫ又はＥＳＲＤによって示されるようなＩＭＳ９９４（例えば、ＩＭＳ９９４中のＬＲＦ）に送信することができ、９１４Ａにおいて受信されたＥＳＲＫとＥＳＲＤのいずれかとＭＳＩＳＤＮとを含める。ブロック９２４Ａは、図６の位置要求６０５Ａの送信に対応し得る。
[00208]９２６Ａにおいて、ＩＭＳ９９４（例えば、ＩＭＳ９９４中のＬＲＦ）は、ＵＥ９００を識別するために９２４Ａにおいて受信されたＥＳＲＫ又はＭＳＩＳＤＮを使用し、制御プレーン位置特定解決法又はユーザプレーン位置特定解決法を使用してＵＥ９００の位置を取得するために、９０８において受信された任意のＵＥデータ、及び／又は９０８で、若しくは９２２が存在する場合には９２２で受信されたＭＮＯデータを使用する。
[00209]９２８Ａにおいて、ＩＭＳ９９４（例えば、ＩＭＳ９９４中のＬＲＦ）は、ＵＥ９００の位置をレガシーＰＳＡＰ９８２に（又はＡＬＩなどのＰＳＡＰ９８２と関連付けられるエンティティに）返す。
[00210]９２４Ｂにおいて、ｉ３対応ＰＳＡＰ９８０の場合、ｉ３ ＰＳＡＰ９８０は、位置ＵＲＩにおいて示されるＩＭＳ９９４（例えば、ＩＭＳ９９４中のＬＲＦ）に位置要求を送信し、位置ＵＲＩを搬送することによって、９１４Ｂにおいて受信される位置ＵＲＩを逆参照する。ブロック９２４Ｂは、図６の位置要求６０５Ｂの送信に対応し得る。
[00211]９２６Ｂにおいて、ＩＭＳ９９４（例えば、ＩＭＳ９９４中のＬＲＦ）は、ＵＥ９００を識別するために９２４Ｂにおいて受信された位置ＵＲＩを使用し、制御プレーン位置特定解決法又はユーザプレーン位置特定解決法を使用してＵＥ９００の位置を取得するために、９０８において受信された任意のＵＥデータ及び／又は９０８で、若しくは９２２が存在する場合には９２２で受信されたＭＮＯデータを使用する。
[00212]９２８Ｂにおいて、ＩＭＳ９９４（例えば、ＩＭＳ９９４中のＬＲＦ）は、ＵＥ９００の位置をｉ３対応ＰＳＡＰ９８０に返す。
[00213]ＥＳＩｎｅｔ９６０がＵＥ９００の位置をＩＭＳ９９４から（例えば、ＩＭＳ９９４中のＬＲＦから）取得し、その位置に基づいて９１４Ｂにおいて緊急呼を正しいＰＳＡＰ９８０にルーティングすることを可能にするために、９２４Ｂ、９２６Ｂ及び９２８Ｂに類似する、又はそれらと同じブロックが、９１２Ｂに続いて存在することがある。その場合、ＥＳＩｎｅｔ９６０（例えば、ＥＳＲＰ６６６などのＥＳＩｎｅｔ８６０中のＥＳＲＰ）は、９２４Ｂと同様の、又は同じブロックにおいて、ＵＥ９００に対する位置要求をＩＭＳ９９４に送信することができ、９２８Ｂと同様の、又は同じブロックにおいて、ＵＥ９００の位置をＩＭＳ９９４から受信することができる。
[00214]図４〜図９に関連して説明された手順及び技法は、（例えば、図４及び図７の）ＬｂｙＲへの任意の更新、又は（例えば、図８の８２６及び図９の９２０におけるような）ＭＮＯデータに対する任意の更新をＵＥのＯＴＴ ＳＰに送信する緊急呼を引き起こして、そのＯＴＴ ＳＰが更新をＰＳＡＰに、又はＬＲＦ（例えば、図８の８２８におけるような）若しくはＥ−ＣＳＣＦ（例えば、図９の９２２におけるような）などのＩＭＳエンティティに転送することを可能にする、ＵＥに依存し得ることに留意されたい。しかしながら、代替的な実施形態では、（例えば、緊急呼を引き起こしたＵＥが新しいＳＧＳＮ又は新しいＭＭＥにハンドオーバーされた後で生じ得る）更新されたＬｂｙＲ又は更新されたＭＮＯデータが、ＵＥによってではなく、サービングＭＮＯ中のＡＮ又はＰＣＮによって（例えば、ＡＮ又はＰＣＮ中のＭＭＥ又はＳＧＳＮによって）、ＰＳＡＰ又はサービングＭＮＯ中のＩＭＳエンティティ（ＬＲＦ又はＥ−ＣＳＣＦなど）に送信されることがある。これは、例えば、緊急呼を引き起こしたＵＥのサービングＭＮＯ中のＩＭＳエンティティ又はこれと関連付けられるエンティティ（例えば、ＧＭＬＣ）が、（例えば、図７、図８及び図９の各々においてそれぞれ、７０８、８０８及び９０８に続いて）ＵＥが緊急呼を引き起こしていることを検出した後で、任意の更新されたＬｂｙＲ又は更新されたＭＮＯデータに対する要求をサービングＭＮＯ ＡＮ又はＰＣＮ中のエンティティに（例えば、ＭＭＥ又はＳＧＳＮに）送信する場合に、起こり得る。これらの代替的な実施形態では、更新されたＬｂｙＲ又は更新されたＭＮＯデータが、緊急呼を引き起こしたＵＥによってＯＴＴ ＳＰに送信される必要はないことがあり、ＯＴＴ ＳＰによってＰＳＡＰ又はＬＲＦ若しくはＥ−ＣＳＣＦなどのＩＭＳエンティティに送信される必要はないことがある。
[00215]図１０は、本明細書で教示される動作をサポートするために、（例えば、ＵＥ２００、３００、４００、５００、６００、７００、８００又は９００などのユーザ機器、アクセスネットワークノード２４０などのアクセスネットワークノード、及びＯＴＴ ＳＰ１５０、位置サーバ１７０などのネットワークエンティティなどにそれぞれ対応する）装置１００２、装置１００４及び装置１００６に組み込まれ得る（対応するブロックによって表される）幾つかの例示的な構成要素を示す。これらの構成要素は、異なる実装形態では異なるタイプの装置において（例えば、ＡＳＩＣ、ＳｏＣなどにおいて）実装され得ることを理解されたい。示される構成要素は、通信システム中の他の装置にも組み込まれ得る。例えば、システム中の他の装置は、同様の機能を提供するために説明されるものと同様の構成要素を含み得る。また、所与の装置が、構成要素の１つ又は複数を含むことがある。例えば、装置は、装置が複数のキャリア上で動作し、及び／又は異なる技術によって通信することを可能にする、複数の送受信機構成要素を含み得る。
[00216]装置１００２及び装置１００４は各々、少なくとも１つの指定されたＲＡＴを介して他のノードと通信するための（通信機器１００８及び１０１４（並びに、装置１００４がリレーである場合、通信機器１０２０）によって表される）少なくとも１つのワイヤレス通信機器を含む。各通信機器１００８は、信号（例えば、メッセージ、指示、情報など）を送信及び符号化するための（送信機１０１０によって表される）少なくとも１つの送信機と、信号（例えば、メッセージ、指示、情報、パイロットなど）を受信及び復号するための（受信機１０１２によって表される）少なくとも１つの受信機とを含む。同様に、各通信機器１０１４は、信号（例えば、メッセージ、指示、情報、パイロットなど）を送信するための（送信機１０１６によって表される）少なくとも１つの送信機と、信号（例えば、メッセージ、指示、情報など）を受信するための（受信機１０１８によって表される）少なくとも１つの受信機とを含む。装置１００４が中継局である場合、各通信機器１０２０は、信号（例えば、メッセージ、指示、情報、パイロットなど）を送信するための（送信機１０２２によって表される）少なくとも１つの送信機と、信号（例えば、メッセージ、指示、情報など）を受信するための（受信機１０２４によって表される）少なくとも１つの受信機とを含み得る。
[00217]送信機及び受信機は、幾つかの実装形態では、（例えば、単一の通信機器の送信機回路及び受信機回路として組み込まれる）統合された機器を備えることがあり、幾つかの実装形態では、別個の送信機機器と別個の受信機機器とを備えることがあり、又は他の実装形態では、他の方法で組み込まれることがある。装置１００４のワイヤレス通信機器（例えば、複数のワイヤレス通信機器の１つ）はまた、様々な測定を実行するためのネットワーク聴取モジュール（ＮＬＭ：Network Listen Module）などを備え得る。
[00218]装置１００６（及びそれが中継局ではない場合、装置１００４）は、他のノードと通信するための（通信機器１０２６及び場合によっては１０２０によって表される）少なくとも１つの通信機器を含む。例えば、通信機器１０２６は、有線の、又はワイヤレスのバックホールを介して１つ以上のネットワークエンティティと通信するように構成されるネットワークインターフェースを備え得る。幾つかの態様では、通信機器１０２６は、有線の、又はワイヤレスの信号通信をサポートするように構成された送受信機として実装され得る。この通信は、例えば、メッセージ、パラメータ又は他のタイプの情報を送信及び受信することに関与し得る。従って、図１０の例では、通信機器１０２６は、送信機１０２８と受信機１０３０とを備えるものとして示されている。同様に、装置１００４が中継局ではない場合、通信機器１０２０は、有線の、又はワイヤレスのバックホールを介して１つ以上のネットワークエンティティと通信するように構成されるネットワークインターフェースを備え得る。通信機器１０２６と同様に、通信機器１０２０は、送信機１０２２と受信機１０２４とを備えるものとして示されている。
[00219]装置１００２、１００４及び１００６は、本明細書で教示されるＯＴＴ ＳＰ及びＵＥの位置関連の動作に関連して使用され得る他の構成要素も含む。装置１００２は、例えば、本明細書で教示されるようなＯＴＴ ＳＰ及びＵＥの位置関連の動作をサポートするためのユーザ機器の動作に関する機能を提供するための、及び他の処理機能を提供するための、処理システム１０３２と測位モジュール１０５４とを含む。装置１００４は、例えば、本明細書で教示されるようなＯＴＴ ＳＰ及びＵＥの位置関連の動作をサポートするためのアクセスネットワークノードの動作に関する機能を提供するための、及び他の処理機能を提供するための処理システム１０３４と測位モジュール１０５６とを含む。装置１００６は、例えば、本明細書で教示されるようなＯＴＴ ＳＰ及びＵＥの位置関連の動作をサポートするためのネットワークの動作に関する機能を提供するための、及び他の処理機能を提供するための処理システム１０３６と測位モジュール１０５８とを含む。
[00220]装置１００２、１００４及び１００６は更に、情報（例えば、確保されたリソース、しきい値、パラメータなどを示す情報）を維持するための、メモリ構成要素１０３８、１０４０及び１０４２（例えば、各々がメモリ機器を含む）をそれぞれ含む。更に、装置１００２、１００４及び１００６は、指示（例えば、可聴の指示及び／又は視覚的な表示）をユーザに与えるため、及び／又は（例えば、キーパッド、タッチスクリーン、マイクロフォンなどの感知機器をユーザが作動させると）ユーザ入力を受け取るためのユーザインターフェース機器１０４４、１０４６及び１０４８をそれぞれ含む。
[00221]便宜的に、装置１００２、１００４及び／又は１００６は、図１０では、本明細書で説明される様々な例に従って構成され得る様々な構成要素を含むものとして示されている。しかしながら、図示されたブロックは、異なる設計では異なる機能を有し得ることが理解されるだろう。
[00222]図１０の構成要素は様々な方法で実装され得る。幾つかの実装形態では、図１０の構成要素は、例えば、１つ以上のプロセッサ及び／又は（１つ以上のプロセッサを含み得る）１つ以上のＡＳＩＣなど、１つ以上の回路において実装され得る。ここで、各回路は、この機能を与えるために回路によって使用される情報若しくは実行可能コードを記憶するための少なくとも１つのメモリ構成要素を使用し、及び／又は組み込み得る。例えば、ブロック１００８、１０３２、１０３８、１０４４及び１０５４によって表される機能の一部又は全てが、装置１００２のプロセッサ及びメモリ構成要素によって（例えば、適切なコードの実行によって、及び／又はプロセッサ構成要素の適切な構成によって）実装され得る。同様に、ブロック１０１４、１０２０、１０３４、１０４０、１０４６及び１０５６によって表される機能の一部又は全てが、装置１００４のプロセッサ及びメモリ構成要素によって（例えば、適切なコードの実行によって、及び／又はプロセッサ構成要素の適切な構成によって）実装され得る。また、ブロック１０２６、１０３６、１０４２、１０４８及び１０５８によって表される機能の一部又は全てが、装置１００６のプロセッサ及びメモリ構成要素によって（例えば、適切なコードの実行によって、及び／又はプロセッサ構成要素の適切な構成によって）実装され得る。例えば、測位モジュール１０５４、１０５６及び１０５８は、メモリに記憶される実行可能モジュールであることがあり、又は、処理システム１０３２、１０３４、及び１０３６に結合されたハードウェア／ファームウェア構成要素であることがある。
[00223]図１１は、本開示の少なくとも１つの態様による、ＵＥ１１００の例示的な構成要素を示すブロック図である。ＵＥ１１００は、図１ＡのＵＥ１からＮ、ＵＥ２００、ＵＥ３００、ＵＥ４００、ＵＥ５００、ＵＥ６００、ＵＥ７００、ＵＥ８００若しくはＵＥ９００のいずれかに対応し、又はそれらを表すことがある。図１１のボックス図に示される様々な特徴及び機能は、共通バスを使用して一緒に接続されることがあり（図１１には示されない）、又は、プロセッサ１１３０を介して（図１１に示されるように）接続されることがある。実際のポータブルワイヤレス機器を動作可能に結合し、構成するために、他の接続、機構、特徴、機能などが必要に応じて与えられ、適応され得ることを、当業者は認識されよう。更に、図１１の例に示される特徴又は機能の１つ又は複数は、更に再分割されることがあり、又は図１１に示される特徴又は機能の２つ以上が組み合わされることがあることも認識されたい。
[00224]ＵＥ１１００は、１つ又は複数のアンテナ１１１２に接続され得る１つ又は複数のＢｌｕｅｔｏｏｔｈ送受信機１１１４ａを含み得る。Ｂｌｕｅｔｏｏｔｈ送受信機１１１４ａは、Ｂｌｕｅｔｏｏｔｈアクセスポイント（例えば、図１ＡのＡＰ１２５）と通信するための、及び／又は、Ｂｌｕｅｔｏｏｔｈアクセスポイントへの／からの信号を検出するための、適切な機器、ハードウェア及び／又はソフトウェアを備える。加えて、又は代替的に、ＵＥ１１００は、１つ又は複数のアンテナ１１１２に接続され得る１つ又は複数のワイドエリアネットワーク（ＷＡＮ）ワイヤレス送受信機１１１４ｂを含み得る。ＷＡＮ送受信機１１１４ｂは、ＷＡＮ−ＷＡＰ（ワイヤレスアクセスポイント）と通信するための、及び／又はＷＡＮ−ＷＡＰへの／からの信号を検出するための、及び／又はネットワーク内の他のワイヤレス機器（例えば、図１ＡのＲＡＮ１２０中の機器）と直接通信するための、適切な機器、ハードウェア及び／又はソフトウェアを備える。一態様では、ＷＡＮ送受信機１１１４ｂは、ＬＴＥシステム、ＷＣＤＭＡシステム、ＣＤＭＡ２０００システム、ＴＤＭＡ、ＧＳＭ又は任意の他のタイプのワイドエリアワイヤレスネットワーキング技術と通信するのに適していることがある。加えて、又は代替的に、ＵＥ１１００は、１つ又は複数のアンテナ１１１２に接続され得る１つ又は複数のＷＬＡＮ送受信機１１１４ｃを含み得る。ＷＡＮ送受信機１１１４ｃは、ＷＬＡＮ−ＷＡＰと通信するための、及び／又はＷＬＡＮ−ＷＡＰへの／からの信号を検出するための、及び／又はネットワーク内の他のワイヤレス機器（例えば、図１ＡのＷｉＦｉ ＡＰ１２５）と直接通信するための、適切な機器、ハードウェア及び／又はソフトウェアを備える。一態様では、ＷＬＡＮ送受信機１１１４ｃは、１つ又は複数のワイヤレスアクセスポイントと通信するのに適切なＷｉ−Ｆｉ（８０２．１１ｘ）通信システムを備え得るが、他の態様では、ＷＬＡＮ送受信機１１１４ｃは、別のタイプのローカルエリアネットワーク又はパーソナルエリアネットワークを備え得る。加えて、又は代替的に、ＵＥ１１００はＳＰＳ受信機１１１４ｄを含み得る。ＳＰＳ受信機１１１４ｄは、（例えば、ＧＰＳ又は何らかの他のＧＮＳＳのための）衛星信号を受信するための１つ又は複数のアンテナ１１１２に接続され得る。ＳＰＳ受信機１１１４ｄは、ＳＰＳ信号を受信し処理するための、任意の適切なハードウェア及び／又はソフトウェアを備え得る。ＳＰＳ受信機１１１４ｄは、他のシステムに適宜に情報と動作とを要求し、任意の適切なＳＰＳアルゴリズムによって取得された測定結果を使用してモバイル機器１１００の場所を決定するために必要な計算を実行する。加えて、又は代替的に、任意の他のタイプのワイヤレスネットワーキング技術、例えば、Ｕｌｔｒａ Ｗｉｄｅ Ｂａｎｄ、ＺｉｇＢｅｅ（登録商標）、ワイヤレスＵＳＢなどが使用され得る。
[00225]ＵＥ１１００は、１つ又は複数のセンサ１１２０を含み得る。１つ又は複数のセンサ１１２０は、ユーザの場所、動き、方向、環境、活動、又は生体情報についてのデータを含む、ユーザについてのデータを収集し得る。センサは、例えば、歩数計１１２２ａなどの仮想センサ、加速度計１１２２ｂ、ジャイロスコープ１１２２ｃ、生体センサ１１２０ｄなどの物理センサ及び／又は任意の数の種々のセンサ１１２２ｎ（例えば、温度計、気圧計、湿度計）を含み得る。
[00226]ＵＥ１１００は、１つ又は複数のプロセッサ１１３０を含む。プロセッサ１１３０は、Ｂｌｕｅｔｏｏｔｈ送受信機１１１４ａと、ＷＡＮ送受信機１１１４ｂと、ＷＬＡＮ送受信機１１１４ｃと、ＳＰＳ受信機１１１４ｄと、１つ又は複数のセンサ１１２０とに接続され得る。プロセッサ１１３０はマルチコアプロセッサであることがあり、単一のユニットとして示されるが、処理機能並びに他の計算及び制御の機能を与える１つ又は複数のマイクロプロセッサ、マイクロコントローラ、及び／又はデジタル信号プロセッサを含むことがある。
[00227]プロセッサ１１３０は、データと、ＵＥ１１００内でプログラムされた機能を実行するためのソフトウェア命令とを記憶する、メモリ１１４０に結合され得る。メモリ１１４０は、プロセッサ１１３０に搭載されている（例えば、同じ集積回路パッケージの中にある）ことがあり、及び／又は、メモリ１１４０は、プロセッサ１１３０に対して外部のメモリでありデータバスを通じて機能的に結合されることがある。メモリ１１４０は、任意の数のネイティブアプリケーションモジュール１１４２ａ．．．１１４２ｎと、ｏｖｅｒ ｔｈｅ ａｉｒ更新又は任意の他の手段による幾つかの外部的に供給されるモジュールと、任意の数のデータモジュール１１４４ａ．．．１１４４ｎとを含み得る。図１１に示されるメモリ内容の編成は、例にすぎず、従って、モジュール及び／又はデータ構造の機能は、ＵＥ１１００の実装形態に応じて様々な方法で組み合わされ、分離され、及び／又は構造化され得ることを理解されたい。メモリ１１４０は、ＵＥ１１００が本明細書で説明された様々な手順及び技法の一部又は全てを実行することを可能にするためにプロセッサ１１３０上で実行され得る、プログラムコードを（例えば、アプリケーションモジュール１１４２ａから１１４２ｎの１つ又は複数に）記憶し得る。
[00228]ＵＥ１１００はまた、本明細書で説明されるように、ＯＴＴ ＳＰ及びＵＥに関連する位置特定をサポートするようにユーザ機器の動作を実行するように構成される測位モジュール１１８０を含み得る。測位モジュール１１８０は、メモリ１１４０に記憶されプロセッサ１１３０上で実行される実行可能モジュールであることがあり、又は、プロセッサ１１３０に結合されるハードウェア構成要素若しくはファームウェア構成要素であることがある。
[00229]図１１に示されるモジュールは、メモリ１１４０に含まれているものとして例に示されているが、幾つかの実装形態では、そのような手順は、他の機構又は追加の機構を使用して与えられるか、又は場合によっては動作可能に構成され得ることを認識されたい。例えば、アプリケーションモジュール１１４２ａ．．．１１４２ｎのいずれもがファームウェアにおいて提供され得る。プロセッサ１１３０は、少なくとも本明細書で与えられる技法を実行するのに適した任意の形態の論理を含み得る。例えば、プロセッサ１１３０は、メモリ１１４０中の命令に基づいて、ＵＥ１１００の他の部分において使用するために、動きデータを活用する１つ又は複数のルーチンを選択的に開始するように動作可能に構成可能であり得る。
[00230]ＵＥ１１００は、ＵＥ１１００とのユーザ対話を可能にするマイクロフォン／スピーカー１１５２、タッチパッド１１５３、キーパッド１１５４、ディスプレイ１１５６、カメラ１１５８、近接センサ１１５９などの、任意の適切なインターフェースシステムを与えるユーザインターフェース１１５０を含み得る。マイクロフォン／スピーカー１１５２は、ＷＡＮ送受信機１１１４ｂ及び／又はＷＬＡＮ送受信機１１１４ｃを使用して、音声認識及び／又は音声通信サービスを提供する。キーパッド１１５４は、ユーザ入力のための任意の適切なボタンを備える。ディスプレイ１１５６は、例えば、バックライト付きのＬＣＤディスプレイなどの任意の適切なディスプレイを備え、追加のユーザ入力モードのために、タッチスクリーンディスプレイを更に含み得る。その上、マイクロフォン／スピーカー１１５２、カメラ１１５８又はキーパッド１１５４によって示される機能などの任意の入力機能も、１つ又は複数のセンサ１１２０の入力に類似するセンサ入力であると考えられ得る。
[00231]ＵＥ１１００は更に、例えば、電力をＵＥ１１００の様々な構成要素に供給するための、バッテリーなどの電源１１６０を含む。しかしながら、ＵＥ１１００は、示される要素の全てを含むとは限らず、機器の要件及び設計上の考慮事項に基づいて、要素の部分集合のみを含む可能性が高いことが理解されるだろう。
[00232]上で述べられたように、１つ又は複数のセンサ１１２０は、ユーザの場所、方向、動き、環境、活動又は生体情報についてのデータを含む、ユーザについてのデータを収集し得る。センサは、例えば、歩数計１１２２ａ（個別の機器、又は他のセンサからのデータに基づく機能モジュールであり得る）、加速度計１１２２ｂ、ジャイロスコープ１１２２ｃ、生体センサ１１２０ｄ及び／又は任意の数の種々のセンサ１１２２ｎを含み得る。その上、Ｂｌｕｅｔｏｏｔｈ送受信機１１１４ａ、ＷＡＮ送受信機１１１４ｂ、ＷＬＡＮ送受信機１１１４ｃ及び／又はＳＰＳ受信機１１１４ｄが、ユーザの場所、動き、環境及び／又は活動についてのデータを生成するために使用され得る程度に、センサとして利用されることがある。従って、本開示が１つ又は複数のセンサ１１２０全般に言及するとき、又はセンサ読取値若しくはセンサデータに言及するとき、Ｂｌｕｅｔｏｏｔｈ送受信機１１１４ａ、ＷＡＮ送受信機１１１４ｂ、ＷＬＡＮ送受信機１１１４ｃ及び／又はＳＰＳ受信機１１１４ｄはセンサであると見なされることがあり、それらから取得されるデータはセンサ読取値又はセンサデータであると見なされることがあることを理解されたい。
[00233]ある実施形態では、生体センサ１１２２ｄは、ユーザを識別するためのセンサを含む。例えば、生体センサ１１２２ｄは、音声認識、指紋認識、掌紋認識、顔認識又は虹彩認識のためのセンサであり得る。生体センサ１１２２ｄは、音声認識、指紋認識、掌紋認識、顔認識及び／又は虹彩認識のために特別に設計された、専用センサであり得る。別の可能なシナリオでは、マイクロフォン／スピーカー１１５２が、音声認識のためのセンサとして使用される。別の可能なシナリオでは、キーパッド１１５４が、指紋認識及び／又は掌紋認識のためのセンサとして使用される。更に別の可能なシナリオでは、カメラ１１５８が、顔認識及び／又は虹彩認識のためのセンサとして使用される。
[00234]上で述べられたように、プロセッサ１１３０は、データと、ＵＥ１１００内でプログラムされた機能を実行するためのソフトウェア命令とを記憶する、メモリ１１４０に結合され得る。メモリ１１４０は、任意の数のアプリケーションモジュール１１４２ａ．．．１１４２ｎと、任意の数のデータモジュール１１４４ａ．．．１１４４ｎとを含み得る。ある実施形態では、アプリケーションモジュール１１４２ａ．．．１１４２ｎの１つ又は複数、例えばアプリケーションモジュール１１４２ａが、歩数計１１２２ａ、加速度計１１２２ｂ、ジャイロスコープ１１２２ｃ、生体センサ１１２０ｄ、及び／又は種々のセンサ１１２２ｎの１つ又は複数から集められた、感知されたデータを利用する。感知されたデータは、データモジュール１１４４ａ．．．データモジュール１１４４ｎの１つ又は複数、例えばデータモジュール１１４４ａに記憶され得る。
[00235]従って、本開示のある実施形態は、本明細書で説明される機能を実行する能力を含むＵＥ（例えば、ＵＥ１１００）を含み得る。当業者によって理解されるように、本明細書で開示される機能を達成するために、様々な論理要素が、個別の要素、プロセッサ上で実行されるソフトウェアモジュール又はソフトウェアとハードウェアとの任意の組合せで具現化され得る。例えば、プロセッサ１１３０、メモリ１１４０、ユーザインターフェース１１５０及び測位モジュール１１８０は全て、本明細書で開示される様々な機能をロードし、記憶し、実行するために、協働的に使用されることがあり、従って、これらの機能を実行するための論理は様々な要素に分散され得る。代替的に、機能は１つの個別の構成要素に組み込まれ得る。従って、図１１のＵＥ１１００の特徴は例示的なものにすぎないと見なされるべきであり、本開示は例示された特徴又は構成に限定されない。
[00236]ＵＥ１１００及びＲＡＮ１２０／ＭＭＥ１４２との間のワイヤレス通信は、ＬＴＥ、ＣＤＭＡ、ＷＣＤＭＡ、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、直交周波数分割多重化（ＯＦＤＭ）、ＧＳＭ又はワイヤレス通信ネットワーク若しくはデータ通信ネットワークにおいて使用され得る他のプロトコルなどの、様々な技術に基づき得る。上で論じられたように、及び当技術分野で知られているように、音声送信及び／又はデータは、様々なネットワークと構成とを使用してＲＡＮ１２０からＵＥ１１００に送信され得る。従って、本明細書で与えられる例示は、本開示の実施形態を限定することは意図されず、本開示の実施形態の態様の説明を助けるためのものにすぎない。
[00237]図１２は、機能を実行するための構造的構成要素を含む通信機器１２００を示す。通信機器１２００は、限定はされないが、ＵＥ１１００、ＲＡＮ１２０の任意の構成要素（例えば、ｅＮｏｄｅＢ１２２〜１２６）、コアネットワーク１４０の任意の構成要素（例えば、ＭＭＥ１４２又は１４４、Ｅ−ＳＭＬＣ１７２、Ｓ−ＧＷ１４６、ＰＤＧ１４８、ＥＬＳ３７０／７９４、Ｅ−ＣＳＣＦ４４３／５４３／６４３、ＬＲＦ４４８／５４８／６４８）、コアネットワーク１４０及び／又はインターネット１７５と結合される任意の構成要素（例えば、位置サーバ１７０、ＧＭＬＣ／ＳＬＰ１７０、ＥＳＩｎｅｔ１６０、ＰＳＡＰ１８０）などを含む、上で述べられた通信機器のいずれかに対応し得る。従って、通信機器１２００は、図１Ａのワイヤレス通信システム１００Ａを通じて、又は図１Ｂの特定の構成１００Ｂを使用して、１つ又は複数の他のエンティティと通信する（又はそれらとの通信を容易にする）ように構成された任意の電子機器に対応し得る。
[00238]図１２を参照すると、通信機器１２００は、情報を受信及び／又は送信するように構成された送受信機回路１２０５を含む。ある例では、通信機器１２００がワイヤレス通信機器（例えば、ＵＥ１１００、ｅＮＢ１２２〜１２６の１つなど）に対応する場合、情報を受信及び／又は送信するように構成された送受信機回路１２０５は、ワイヤレス送受信機及び関連するハードウェア（例えば、ＲＦアンテナ、モデム、変調器及び／又は復調器など）などのワイヤレス通信インターフェース（例えば、Ｂｌｕｅｔｏｏｔｈ、ＷｉＦｉ、２Ｇ、ＣＤＭＡ、ＷＣＤＭＡ、３Ｇ、４Ｇ、ＬＴＥなど）を含み得る。別の例では、情報を受信及び／又は送信するように構成された送受信機回路１２０５は、有線通信インターフェース（例えば、シリアル接続、ＵＳＢ又はファイアワイヤ接続、インターネット１７５がそれを通してアクセスされ得るイーサネット（登録商標）接続など）に対応し得る。従って、通信機器１２００が、何らかのタイプのネットワークベースのサーバ（例えば、Ｓ−ＧＷ１４６、ＰＤＧ１４８、ＭＭＥ１４２／１４４、Ｅ−ＳＭＬＣ１７２、位置サーバ１７０、ＥＬＳ３７０／７９４、Ｅ−ＣＳＣＦ４４３／５４３／６４３、ＬＲＦ４４８／５４８／６４８など）に対応する場合、情報を受信及び／又は送信するように構成された送受信機回路１２０５は、ある例では、イーサネットプロトコルを介してネットワークベースのサーバを他の通信エンティティに接続するイーサネットカードに対応し得る。更なる例では、情報を受信及び／又は送信するように構成された送受信機回路１２０５は、通信機器１２００がローカル環境をそれによって監視することができる感知又は測定ハードウェア（例えば、加速度計、温度センサ、光センサ、ローカルＲＦ信号を監視するためのアンテナなど）を含み得る。情報を受信及び／又は送信するように構成された送受信機回路１２０５はまた、実行されると、情報を受信及び／又は送信するように構成された送受信機回路１２０５の関連するハードウェアが受信及び／又は送信機能を実行することを可能にする、ソフトウェアを含み得る。しかしながら、情報を受信及び／又は送信するように構成された送受信機回路１２０５は、ソフトウェアのみに対応せず、情報を受信及び／又は送信するように構成された送受信機回路１２０５は、その機能を達成するために構造的なハードウェアに少なくとも一部依存する。
[00239]図１２を参照すると、通信機器１２００は更に、情報を処理するように構成された少なくとも１つのプロセッサ１２１０を含む。情報を処理するように構成された少なくとも１つのプロセッサ１２１０によって実行され得るタイプの処理の例示的な実装形態は、限定はされないが、決定を行うこと、接続を確立すること、様々な情報の選択肢の間で選択を行うこと、データに関係する評価を行うこと、測定動作を実行するために通信機器１２００に結合されたセンサと対話すること、情報をあるフォーマットから別のフォーマットに（例えば、．ｗｍｖから．ａｖｉなどのように、異なるプロトコル間で）変換することなどを含む。例えば、情報を処理するように構成された少なくとも１つのプロセッサ１２１０は、汎用プロセッサ、ＤＳＰ、ＡＳＩＣ、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）若しくは他のプログラマブル論理機器、個別のゲート若しくはトランジスタ論理、個別のハードウェア構成要素又は本明細書で説明される機能を実行するように設計されたそれらの任意の組合せを含み得る。汎用プロセッサはマイクロプロセッサであり得るが、代替として、情報を処理するように構成された少なくとも１つのプロセッサ３１０は、任意の従来のプロセッサ、コントローラ、マイクロコントローラ又は状態機械であり得る。プロセッサは、コンピュータ機器の組合せ（例えば、ＤＳＰとマイクロプロセッサとの組合せ、複数のマイクロプロセッサ、ＤＳＰコアと連携する１つ以上のマイクロプロセッサ、又は任意の他のそのような構成）として実装されることもある。情報を処理するように構成された少なくとも１つのプロセッサ１２１０はまた、実行されると、情報を処理するように構成された少なくとも１つのプロセッサ１２１０の関連するハードウェアが処理機能を実行することを可能にする、ソフトウェアを含み得る。しかしながら、情報を処理するように構成された少なくとも１つのプロセッサ１２１０は、ソフトウェアのみに対応せず、情報を処理するように構成された少なくとも１つのプロセッサ１２１０は、その機能を達成するために、構造的なハードウェアに少なくとも一部依存する。
[00240]図１２を参照すると、通信機器１２００は更に、情報を記憶するように構成されたメモリ１２１５を含む。ある例では、情報を記憶するように構成されたメモリ１２１５は、少なくとも非一時的メモリと、関連するハードウェア（例えば、メモリコントローラなど）とを含み得る。例えば、情報を記憶するように構成されたメモリ１２１５に含まれる非一時的メモリは、ＲＡＭ、フラッシュメモリ、読取り専用メモリ（ＲＯＭ）、消去可能プログラマブルＲＯＭ（ＥＰＲＯＭ）、電気的消去可能プログラマブルＲＯＭ（ＥＥＰＲＯＭ（登録商標））、レジスタ、ハードディスク、リムーバブルディスク、ＣＤ−ＲＯＭ又は当技術分野で知られている任意の他の形態の記憶媒体に対応し得る。情報を記憶するように構成されたメモリ１２１５はまた、実行されると、情報を記憶するように構成されたメモリ１２１５の関連するハードウェアが記憶機能を実行することを可能にする、ソフトウェアを含み得る。しかしながら、情報を記憶するように構成されたメモリ１２１５は、ソフトウェアのみに対応せず、情報を記憶するように構成されたメモリ１２１５は、その機能を達成するために、構造的なハードウェアに少なくとも一部依存する。
[00241]図１２を参照すると、通信機器１２００は更に、情報を提示するように構成されたユーザインターフェース出力回路１２２０を任意選択で含む。ある例では、情報を提示するように構成されたユーザインターフェース出力回路１２２０は、少なくとも出力機器と、関連するハードウェアとを含み得る。例えば、出力機器は、ビデオ出力機器（例えば、ディスプレイスクリーン、ＵＳＢ、ＨＤＭＩ（登録商標）などの、ビデオ情報を搬送することができるポートなど）、オーディオ出力機器（例えば、スピーカー、マイクロフォンジャック、ＵＳＢ、ＨＤＭＩなどの、オーディオ情報を搬送することができるポートなど）、振動機器及び／又は情報がそれによって出力のためにフォーマットされるか、又は通信機器１２００のユーザ若しくは操作者によって実際に出力され得る、任意の他の機器を含み得る。例えば、通信機器１２００が、図１１に示されているようなＵＥ１１００に対応する場合、情報を提示するように構成されたユーザインターフェース出力回路１２２０は、ディスプレイ１０５６及び／又はスピーカー１０５２を含み得る。更なる例では、情報を提示するように構成されたユーザインターフェース出力回路１２２０は、ローカルユーザを有しないネットワーク通信機器（例えば、ネットワークスイッチ又はルータ、リモートサーバなど）などの、幾つかの通信機器では省略されることがある。情報を提示するように構成されたユーザインターフェース出力回路１２２０はまた、実行されると、情報を提示するように構成されたユーザインターフェース出力回路１２２０の関連するハードウェアが提示機能を実行することを可能にする、ソフトウェアを含み得る。しかしながら、情報を提示するように構成されたユーザインターフェース出力回路１２２０は、ソフトウェアのみに対応せず、情報を提示するように構成されたユーザインターフェース出力回路１２２０は、その機能を達成するために、構造的なハードウェアに少なくとも一部依存する。
[00242]図１２を参照すると、通信機器１２００は更に、ローカルユーザ入力を受け取るように構成されたユーザインターフェース入力回路１２２５を任意選択で含む。ある例では、ローカルユーザ入力を受け取るように構成されたユーザインターフェース入力回路３２５は、少なくともユーザ入力機器と、関連するハードウェアとを含み得る。例えば、ユーザ入力機器は、ボタン、タッチスクリーンディスプレイ、キーボード、カメラ、オーディオ入力機器（例えば、マイクロフォン又はマイクロフォンジャックなどのオーディオ情報を搬送することができるポートなど）、及び／又は情報がそれによって通信機器１２００のユーザ又は操作者から受け取られ得る任意の他の機器を含み得る。例えば、通信機器１２００が、図１１に示されているようなＵＥ１１００に対応する場合、ローカルユーザ入力を受け取るように構成されたユーザインターフェース入力回路１２２５は、タッチパッド１１５３、キーパッド１１５４、マイクロフォン１１５２などを含み得る。更なる例では、ローカルユーザ入力を受け取るように構成されたユーザインターフェース入力回路１２２５は、ローカルユーザを有しないネットワーク通信機器（例えば、ネットワークスイッチ又はルータ、リモートサーバなど）などの、幾つかの通信機器では省略されることがある。ローカルユーザ入力を受け取るように構成されたユーザインターフェース入力回路１２２５はまた、実行されると、ローカルユーザ入力を受け取るように構成されたユーザインターフェース入力回路１２２５の関連するハードウェアが入力受け取り機能を実行することを可能にする、ソフトウェアを含み得る。しかしながら、ローカルユーザ入力を受け取るように構成されたユーザインターフェース入力回路１２２５は、ソフトウェアのみに対応せず、ローカルユーザ入力を受け取るように構成されたユーザインターフェース入力回路１２２５は、その機能を達成するために、構造的なハードウェアに少なくとも一部依存する。
[00243]図１２を参照すると、図１２では、１２０５〜１２２５の構成された構造的な構成要素は、関連する通信バス１２３０を介して互いに結合される、別個の又は異なるブロックとして示されているが、１２０５〜１２２５のそれぞれの構成された構造的な構成要素がそれぞれの機能をそれによって実行するハードウェア及び／又はソフトウェアは、部分的に重複し得ることを理解されたい。例えば、１２０５〜１２２５の構成された構造的な構成要素の機能を容易にするために使用される任意のソフトウェアが、情報を記憶するように構成されたメモリ１２１５と関連付けられる非一時的メモリに記憶され得るので、１２０５〜１２２５の構成された構造的な構成要素は各々、情報を記憶するように構成されたメモリ１２１５によって記憶されたソフトウェアの動作に一部基づいて、それぞれの機能（即ち、この場合はソフトウェア実行）を実行する。同様に、１２０５〜１２２５の構成された構造的な構成要素の１つと直接関連付けられるハードウェアが時々、１２０５〜１２２５の他の構成された構造的な構成要素によって借用又は使用され得る。例えば、情報を処理するように構成された少なくとも１つのプロセッサ１２１０は、データを、情報を受信及び／又は送信するように構成された送受信機回路１２０５によって送信される前に、適切なフォーマットへとフォーマットすることができるので、情報を受信及び／又は送信するように構成された送受信機回路１２０５は、情報を処理するように構成された少なくとも１つのプロセッサ１２１０と関連付けられる構造的なハードウェアの動作に一部基づいて、機能（即ち、この場合はデータの送信）を実行する。
[00244]従って、１２０５〜１２２５の様々な構造的な構成要素は、構造的なハードウェアを用いて少なくとも部分的に実装される態様をもたらすことが意図され、ハードウェアとは独立のソフトウェアのみの実装形態及び／又は非構造的で機能的な解釈に対応することは意図されない。１２０５〜１２２５の構造的な構成要素の間の他の対話又は協働が、以下でより詳細に説明される態様の検討から当業者に明らかになろう。
[00245]様々な実施形態は、図１３に示されるサーバ１３００などの、様々な市販のサーバ機器のいずれでも実装され得る。ある例では、サーバ１３００は、上で説明された、ＭＭＥ１４２、ＯＴＴ ＳＰ１５０／３５０／４５０／５５０／６５０／７５０／８５０／９５０、ＥＳＩｎｅｔ１６０、Ｅ−ＳＭＬＣ１７２、位置サーバ／ＧＭＬＣ／ＳＬＰ１７０、ＥＬＳ３７０／７９４、Ｅ−ＣＳＣＦ４４３／５４３／６４３、ＬＲＦ４４８／５４８／６４８、及びＰＳＡＰ１８０の１つの例示的な構成に対応し得る。図１３では、サーバ１３００は、揮発性メモリ１３０２と、ディスクドライブ１３０３などの大容量の不揮発性メモリとに結合された、プロセッサ１３０１を含む。サーバ１３００はまた、プロセッサ１３０１に結合されたフロッピー（登録商標）ディスクドライブ、コンパクトディスク（ＣＤ）、又はＤＶＤディスクドライブ１３０６を含み得る。サーバ１３００はまた、他のブロードキャストシステムコンピュータ及びサーバに、又はインターネットに結合されたローカルエリアネットワークなどのネットワーク１３０７とのデータ接続を確立するための、プロセッサ１３０１に結合されたネットワークアクセスポート１３０４を含み得る。図１２の状況では、図１３のサーバ１３００は、通信機器１２００の１つの例示的な実装形態を示し、この実装形態によって、情報を送信及び／又は受信するように構成される論理１２０５は、ネットワーク１３０７と通信するためにサーバ１３００によって使用されるネットワークアクセスポート１３０４に対応し、情報を処理するように構成される論理１２１０は、プロセッサ１３０１に対応し、情報を記憶するように構成される論理１２１５は、揮発性メモリ１３０２、ディスクドライブ１３０３及び／又はディスクドライブ１３０６の任意の組合せに対応することが理解されるだろう。情報を提示するように構成された任意選択の論理１２２０及びローカルユーザ入力を受け取るように構成された任意選択の論理１２２５は、図１３には明示的に示されておらず、図１３に含まれることも又は含まれないこともある。従って、図１３は、図１１のようなＵＥの実装形態に加えて、通信機器１２００がサーバとして実装され得ることを例証するのを助ける。従って、本開示のある実施形態は、例えば、ＭＭＥ１４２、ＯＴＴ ＳＰ１５０、ＥＳＩｎｅｔ１６０、Ｅ−ＳＭＬＣ１７２、位置サーバ／ＧＭＬＣ／ＳＬＰ１７０、ＥＬＳ３７０／７９４、Ｅ−ＣＳＣＦ４４３／５４３／６４３、ＬＲＦ４４８／５４８／６４８及びＰＳＡＰ１８０を参照して説明された機能などの、本明細書で説明された機能を実行するための能力を含む、サーバ（例えば、サーバ１３００）を含み得る。
[00246]図１４は、図１Ａ及び図１ＢのＲＡＮ１２０又はＣＮ１４０の任意の構成要素などの、ＵＥにサービスするアクセスネットワークノードによって実行されるＵＥを位置特定するための、例示的なフローを示す。例えば、アクセスネットワークノードは、ＭＭＥ１４２に対応し得る。
[00247]１４１０において、アクセスネットワークノードは、図２Ａの２０６Ａ又は図２Ｂの２０２Ｂなどにおけるように、ＵＥから第１のメッセージを受信する。例えば、アクセスネットワークノードがＬＴＥをサポートするＭＭＥに対応する場合、第１のメッセージは、ＮＡＳ接続要求又はＮＡＳトラッキングエリア更新要求であり得る。アクセスネットワークノードがＵＭＴＳをサポートするＳＧＳＮに対応する場合、第１のメッセージは、ＧＰＲＳ接続要求又はＧＰＲＳルーティングエリア更新要求であり得る。
[00248]１４２０において、アクセスネットワークノードは、ＵＥの位置基準を決定する。位置基準は、図１Ａの位置サーバ１７０又は図１ＢのＧＭＬＣ／ＳＬＰ１７０などの、アクセスネットワークノードの事業者に属す位置サーバのためのものであることがあり、ＵＥが位置特定されることを可能にする。ＵＥの位置基準は、位置サーバのアドレスとＵＥのＵＥ基準とを含み得る。ＵＥ基準は、位置サーバによって割り当てられることがあり、ＩＰアドレス、ＩＭＳＩ、ＴＭＳＩ、アクセスネットワークノードのアドレス又はこれらの任意の組合せを含むことがある。ＵＥ基準は暗号化されることもある。
[00249]図２Ａの２０８Ａ又は図２Ｂの２０４Ｂに関して上で論じられたように、１４２０における決定は、ＵＥの位置基準に対する要求を位置サーバに送信することと、ＵＥの位置基準を位置サーバから受信することとを含み得る。代替的に、上で論じられたように、アクセスネットワークノードは、ＵＥの位置基準自体を生成し得る。その場合、アクセスネットワークノードは、ＵＥの位置基準が事業者のアクセスネットワークノードによって生成されたことを示すために、ＵＥの位置基準にデジタル署名し得る。
[00250]１４３０において、アクセスネットワークノードは、図２Ａの２１２Ａ又は図２Ｂの２０６Ｂなどにおいて、ＵＥに第２のメッセージを送信する。第２のメッセージは位置基準を含み得る。アクセスネットワークノードがＬＴＥをサポートするＭＭＥに対応する場合、第２のメッセージは、ＮＡＳ接続受入れ又はＮＡＳトラッキングエリア更新受入れであり得る。アクセスネットワークノードがＵＭＴＳをサポートするＳＧＳＮに対応する場合、第２のメッセージは、ＧＰＲＳ接続受入れ、又はＧＰＲＳルーティングエリア更新受入れであり得る。
[00251]ＵＥは、ＯＴＴ ＳＰ１５０などのＯＴＴ ＳＰに送信される緊急サービス呼要求に、ＵＥの位置基準を含め得る。ＵＥは、アクセスネットワークノードのアクセスネットワークと異なるアクセスネットワークを介して、緊急サービス呼要求をＯＴＴ ＳＰに送信し得る。ＯＴＴ ＳＰは、位置基準に基づいてＵＥの位置を位置サーバから取得し得る。
[00252]示されていないが、図１４に示されるフローは更に、第２のメッセージを送信する前にＵＥを認証することを含み得る。加えて、図１４に示されるフローは更に、ＵＥがアクセスネットワークノードに接続されている間、ＵＥの新しい位置基準を定期的に決定することと、新しい位置基準をＵＥに送信することとを含み得る。
[00253]図１５は、図１Ａの位置サーバ１７０又は図１ＢのＧＭＬＣ／ＳＬＰ１７０などの位置サーバにおい実行される、ＵＥを位置特定するための例示的なフローを示す。
[00254]１５１０において、位置サーバは、図２Ａの２０８Ａ又は図２Ｂの２０４Ｂなどにおけるように、ＵＥにサービスするアクセスネットワークノードからＵＥの位置基準に対する要求を受信する。
[00255]１５２０において、位置サーバは、図２Ａの２０８Ａ又は図２Ｂの２０４Ｂなどにおけるように、アクセスネットワークノードにＵＥの位置基準を送信する。位置基準は、位置サーバのアドレスとＵＥのローカル基準とを含み得る。
[00256]１５３０において、位置サーバは、図２Ａの２１６Ａ又は図２Ｂの２１４Ｂなどにおけるように、アクセスネットワークノード以外のネットワークエンティティからＵＥの位置に対する位置要求を受信する。位置要求はＵＥの位置基準を含み得る。他のネットワークエンティティは、例えば、ＯＴＴ ＳＰ、ＥＳＩｎｅｔプロバイダ又はＰＳＡＰに属すネットワークエンティティであり得る。
[00257]１５４０において、位置サーバは、図２Ａの２１８Ａ又は図２Ｂの２１６Ｂ〜２２６Ｂ若しくは２２８Ｂなどにおけるように、ＵＥの位置推定を決定し得る。位置サーバがＳＬＰに対応する場合、ＵＥの位置推定を決定することは、ＵＥとのＳＵＰＬセッションを確立することを含み得る。位置サーバがＧＭＬＣに対応する場合、ＵＥの位置推定を決定することは、制御プレーン位置特定解決法を使用して位置推定を決定することを含み得る。その場合、制御プレーン位置特定解決法を使用して位置推定を決定することは、図２Ａの２１８Ａ又は図２Ｂの２１６Ｂ〜２２６Ｂなどにおけるように、位置要求をアクセスネットワークノードに送信することと、位置推定を含む位置応答をアクセスネットワークノードから受信することとを含み得る。
[00258]１５５０において、位置サーバは、図２Ａの２２４Ａ又は図２Ｂの２３２Ｂなどにおいて、ネットワークエンティティにＵＥの位置推定を送信する。
[00259]ＵＥは、ＯＴＴ ＳＰに送信される緊急サービス呼要求に、位置基準を含める。ある実施形態では、ＵＥは、位置サーバの事業者とは異なる事業者のアクセスネットワークを介して、緊急サービス呼要求をＯＴＴ ＳＰに送信し得る。
[00260]図１６は、図１Ａの位置サーバ１７０又は図１ＢのＧＭＬＣ／ＳＬＰ１７０などの位置サーバにおい実行される、ＵＥを位置特定するための例示的なフローを示す。
[00261]１６１０において、位置サーバは、図２Ａの２１６Ａ又は図２Ｂの２１４Ｂなどにおけるように、ＵＥにサービスするアクセスネットワークノード以外のネットワークエンティティからＵＥの位置に対する位置要求を受信する。位置要求はＵＥの位置基準を含み得る。位置基準はＵＥのＵＥ基準を含み得る。ＵＥ基準は、ＩＰアドレス、ＩＭＳＩ、ＴＭＳＩ、アクセスネットワークノードのアドレス又はこれらの任意の組合せであり得る。他のネットワークエンティティは、例えば、ＯＴＴ ＳＰ、ＥＳＩｎｅｔプロバイダ、又はＰＳＡＰに属すネットワークエンティティであり得る。
[00262]１６２０において、位置サーバは、ＵＥの位置基準を認証する。位置基準は、デジタル署名を含むことがあり、その場合、位置基準を認証することはデジタル署名を認証することを含むことがある。
[00263]１６３０において、位置サーバは、図２Ａの２１８Ａ又は図２Ｂの２１６Ｂ〜２２６Ｂ若しくは２２８Ｂなどにおけるように、ＵＥの位置基準の中のＵＥ基準に基づいてＵＥの位置推定を決定する。ある実施形態では、ＵＥ基準は暗号化されることがあり、その場合、ＵＥの位置推定を決定することは、暗号化されたＵＥ基準を復号することを含むことがある。位置サーバがＳＬＰに対応する場合、ＵＥの位置推定を決定することは、ＵＥとのＳＵＰＬセッションを確立することを含み得る。位置サーバがＧＭＬＣに対応する場合、ＵＥの位置推定を決定することは、制御プレーン位置特定解決法を使用して位置推定を決定することを含み得る。その場合、制御プレーン位置特定解決法を使用して位置推定を決定することは、図２Ａの２１８Ａ又は図２Ｂの２１６Ｂ〜２２６Ｂなどにおけるように、位置要求をアクセスネットワークノードに送信することと、位置推定を含む位置応答をアクセスネットワークノードから受信することとを含み得る。
[00264]１６４０において、位置サーバは、図２Ａの２２４Ａ又は図２Ｂの２３２Ｂなどにおけるように、他のネットワークエンティティにＵＥの位置推定を送信する。
[00265]ＵＥは、ＯＴＴ ＳＰなどのＯＴＴ ＳＰに送信される緊急サービス呼要求に、ＵＥの位置基準を含め得る。
[00266]図１７は、ＵＥ１１００などのＵＥによって実行される呼を行うＵＥを位置特定するための、例示的なフローを示す。この呼は緊急呼であり得る。
[00267]１７１０において、ＵＥは、ＵＥにサービスするアクセスネットワークノードに第１のメッセージを送信する。アクセスネットワークノードがＬＴＥをサポートするＭＭＥに対応する場合、第１のメッセージは、ＮＡＳ接続要求又はＮＡＳトラッキングエリア更新要求であり得る。アクセスネットワークノードがＵＭＴＳをサポートするＳＧＳＮに対応する場合、第１のメッセージは、ＧＰＲＳ接続要求又はＧＰＲＳルーティングエリア更新要求であり得る。
[00268]１７２０において、ＵＥは、ＵＥの位置基準を含む第２のメッセージをアクセスネットワークノードから受信する。位置基準は、図１Ａの位置サーバ１７０又は図１ＢのＧＭＬＣ／ＳＬＰ１７０などの、アクセスネットワークノードの事業者に属す位置サーバのためのものであることがあり、呼のためにＵＥが位置特定されることを可能にし得る。ＵＥの位置基準は、位置サーバのアドレスとＵＥのＵＥ基準とを含み得る。アクセスネットワークノードがＬＴＥをサポートするＭＭＥに対応する場合、第１のメッセージは、ＮＡＳ接続要求又はＮＡＳトラッキングエリア更新要求であり得る。アクセスネットワークノードがＵＭＴＳをサポートするＳＧＳＮに対応する場合、第１のメッセージは、ＧＰＲＳ接続要求又はＧＰＲＳルーティングエリア更新要求であり得る。図１７には示されていないが、フローは更に、第２のメッセージを受信する前にアクセスネットワークノードに対してＵＥを認証することを含み得る。
[00269]１７３０において、ＵＥは、ＵＥのユーザから呼に対する要求を受信する。
[00270]１７４０において、ＵＥは、ＯＴＴ ＳＰ１５０などのＯＴＴ ＳＰに、呼に対する要求を送信する。呼に対する要求はＵＥの位置基準を含み得る。ある実施形態では、呼要求は、アクセスネットワークノードのアクセスネットワークと異なるアクセスネットワークを介して、ＵＥによってＯＴＴ ＳＰに送信される。
[00271]図１７には示されていないが、フローは更に、ＵＥがアクセスネットワークノードに接続されている間に、アクセスネットワークノードからＵＥの新しい位置基準を定期的に受信することを含み得る。
[00272]図１８は、ＯＴＴ ＳＰ１５０などのＯＴＴサービスプロバイダにおいて、緊急呼をサポートするための例示的なフローを示す。ある実施形態では、図１８に示されるフローは、測位モジュール１０５８によって実行されることがあり、又は測位モジュール１０５８によって実行されるようにさせられることがある。
[00273]１８１０において、ＯＴＴ ＳＰ１５０は、８０６及び９０６におけるように、ＵＥ２００、３００、４００、５００、６００、７００、８００、９００、１００２及び１１００のいずれかなどのＵＥから、緊急呼要求を備える第１のメッセージを受信する。第１のメッセージは、サービングＭＮＯ７９０、８９０又は９９０などのＵＥのサービングＭＮＯを介して、ＯＴＴ ＳＰ１５０に移送される。第１のメッセージは、ＩＭＳ８９４又は９９４などの、サービングＭＮＯのＩＭＳのアドレスを含む。
[00274]８２０において、ＯＴＴ ＳＰ１５０は、８０８及び９０８におけるように、アドレスに基づいて第２のメッセージをＩＭＳに送信する。第２のメッセージは、緊急呼に対する要求であり得る。第１のメッセージ、第２のメッセージ、又は両方のメッセージが、ＳＩＰ ＩＮＶＩＴＥであり得る。
[00275]図１８には示されていないが、フローは更に、８１２におけるように、宛先ＰＳＡＰのためのルーティング情報を備える第３のメッセージをＩＭＳから受信することと、ルーティング情報に基づいて、ＰＳＡＰに、又はそれに向かって第４のメッセージを送信することとを含み得る。第３のメッセージはＳＩＰ ３００ Ｍｕｌｔｉｐｌｅ Ｃｈｏｉｃｅｓメッセージであることがあり、第４のメッセージは緊急呼に対する要求であることがある。ＩＭＳのアドレスはＬＲＦのためのものであり得る。ルーティング情報は基準ＩＤを含むことがあり、その場合、フローは更に、第４のメッセージに基準ＩＤを含めることを含むことがあり、基準ＩＤは、ＰＳＡＰがＬＲＦからＵＥの位置を取得することを可能にする。
[00276]ＩＭＳは、宛先ＰＳＡＰに、又はそれに向かって第５のメッセージを送信することがあり、第５のメッセージはＵＥに対する緊急呼要求であることがある。ＩＭＳのアドレスはＥ−ＣＳＣＦのためのものであり得る。ＩＭＳは、第５のメッセージに基準識別子を含め、基準識別子は、ＰＳＡＰがＩＭＳからＵＥの位置を取得することを可能にする。
[00277]図１９は、サービングＭＮＯ８９０又は９９０などのサービングＭＮＯのために、ＩＭＳ８９４又は９９４などのＩＭＳエンティティにおいて緊急呼をサポートするための例示的なフローを示す。ある態様では、ＩＭＳエンティティはＬＲＦであり得る。ある実施形態では、図１９に示されるフローは、測位モジュール１０５８によって実行されることがあり、又は測位モジュール１０５８によって実行されるようにさせられることがある。
[00278]１９１０において、ＩＭＳエンティティは、８０８及び９０８におけるように、ＯＴＴ ＳＰ１５０などのＯＴＴサービスプロバイダによって送信される第１のメッセージを受信し、第１のメッセージはＵＥに対する緊急呼要求を備える。緊急呼要求はＵＥのためのＭＮＯデータを含む。第１のメッセージはＳＩＰ ＩＮＶＩＴＥメッセージであり得る。
[00279]１９２０において、ＩＭＳエンティティは、図９の９１１におけるように、ＭＮＯデータに基づいて宛先ＰＳＡＰのためのルーティング情報を決定する。
[00280]図１９には示されていないが、ある実施形態では、フローは更に、ルーティング情報を備える第２のメッセージをＯＴＴサービスプロバイダに送信することを含むことがあり、このルーティング情報は、ＯＴＴサービスプロバイダが、宛先ＰＳＡＰに、又はそこに向かって緊急呼をルーティングすることを可能にする。その場合、ルーティング情報は、基準ＩＤ及びＰＳＡＰ又は中間の宛先のいずれかのアドレス若しくは識別情報であり得る。第２のメッセージはＳＩＰ ３００ Ｍｕｌｔｉｐｌｅ Ｃｈｏｉｃｅｓメッセージであり得る。
[00281]ある実施形態では、フローは更に、別のエンティティから基準ＩＤを備える第３のメッセージを受信することと、基準ＩＤに基づいてＵＥを識別することと、ＵＥの位置を取得することと、位置を備える第４のメッセージを他のエンティティに送信することとを含み得る。基準ＩＤは、ＥＳＲＫ、ＥＳＲＤとＭＳＩＳＤＮ、又は位置ＵＲＩであり得る。ＵＥの位置は、制御プレーン位置特定解決法又はユーザプレーン位置特定解決法を使用して取得され得る。ある態様では、他のエンティティは、ＰＳＡＰ、ＡＬＩ又はＥＳＩｎｅｔであり得る。
[00282]ある実施形態では、フローは更に、ルーティング情報に基づいて、ＰＳＡＰに、又はそこに向かって第２のメッセージを送信することを含むことがあり、第２のメッセージは緊急呼に対する要求を備える。この場合、ＩＭＳエンティティは緊急ＣＳＣＦであり得る。
[00283]図２０は、ＵＥ２００、３００、４００、５００、６００、７００、８００、９００、１００２及び１１００のいずれかなどのＵＥにおいて、緊急呼をサポートするための例示的なフローを示す。ある実施形態では、図２０に示されるフローは、測位モジュール１０５４によって実行されることがあり、又は測位モジュール１０５４によって実行されるようにさせられることがある。
[00284]２０１０において、ＵＥは、ＵＥのユーザから緊急呼に対する要求を受信する。
[00285]２０２０において、ＵＥは、８０２／８０４及び９０２／９０４におけるように、ＵＥのサービングＭＮＯのためのＭＮＯデータを取得する。
[00286]２０３０において、ＵＥは、８０６及び９０６におけるように、ＯＴＴ ＳＰ１５０などのＯＴＴサービスプロバイダに、緊急呼に対する要求を備える第１のメッセージを送信する。緊急呼に対する要求はＭＮＯデータを含む。ＭＮＯデータは、サービングＭＮＯのＩＭＳのアドレス、ＵＥの現在のサービングモビリティ管理エンティティ若しくはＳＧＳＮの識別情報、サービングＭＮＯにより割り当てられたＵＥのＩＰアドレス、ＵＥのグローバル識別情報若しくはローカル識別情報、又はこれらの何らかの組合せを含み得る。
[00287]ＯＴＴサービスプロバイダは、ＩＭＳのアドレスに基づいて第２のメッセージをＩＭＳに送信し、第２のメッセージは緊急呼に対する要求を備え、ＭＮＯデータを含む。ＩＭＳは、ＭＮＯデータに基づいて緊急呼のためのルーティング情報を決定する。この実施形態では、フローは更に、ユーザプレーン位置特定解決法又は制御プレーン位置特定解決法に従って、位置推定又は位置測定に対する要求を受信することを含み、位置推定又は位置測定は、ＩＭＳがＵＥの位置を取得することを可能にし、ＵＥの位置は、ＩＭＳが、ルーティング情報を決定すること、又は位置をＰＳＡＰに提供することを可能にする。
[00288]ＩＭＳは、ルーティング情報を備える第３のメッセージをＯＴＴサービスプロバイダに送信し得る。ＯＴＴサービスプロバイダは、宛先ＰＳＡＰに、又はそれに向かって、第４のメッセージを送信し、ＰＳＡＰはルーティング情報に基づいて決定される。この場合、ＩＭＳのアドレスはＬＲＦのアドレスである。
[00289]ＩＭＳは、宛先ＰＳＡＰに、又はそれに向かって第５のメッセージを送信することがあり、第５のメッセージは緊急呼に対する要求を備え、ＰＳＡＰはルーティング情報に基づいて決定される。ＩＭＳのアドレスはＥ−ＣＳＣＦのアドレスであり得る。
[00290]図２１は、一連の相互に関係する機能モジュールとして表される例示的なアクセスネットワークノード装置２１００を示す。本明細書で論じられるように、受信するためのモジュール２１１０は、少なくとも幾つかの態様では、例えば、図１０の通信機器１０１４などの通信機器、又は、任意選択で測位モジュール１０５６と連携する処理システム１０３４などの処理システムに、対応し得る。本明細書で論じられるように、決定するためのモジュール２１２０は、少なくとも幾つかの態様では、例えば、任意選択で測位モジュール１０５６と連携する処理システム１０３４などの処理システムに対応し得る。本明細書で論じられるように、送信するためのモジュール２１３０は、少なくとも幾つかの態様では、例えば、図１０の通信機器１０１４などの通信機器、又は、任意選択で測位モジュール１０５６と連携する処理システム１０３４などの処理システムに、対応し得る。
[00291]図２２は、一連の相互に関係する機能モジュールとして表される例示的な位置サーバ装置２２００を示す。本明細書で論じられるように、受信するためのモジュール２２１０は、少なくとも幾つかの態様では、例えば、図１０の通信機器１０２６などの通信機器、又は、任意選択で測位モジュール１０５８と連携する処理システム１０３６などの処理システムに、対応し得る。本明細書で論じられるように、送信するためのモジュール２２２０は、少なくとも幾つかの態様では、例えば、図１０の通信機器１０２６などの通信機器、又は、任意選択で測位モジュール１０５８と連携する処理システム１０３６などの処理システムに、対応し得る。本明細書で論じられるように、受信するためのモジュール２２３０は、少なくとも幾つかの態様では、例えば、図１０の通信機器１０２６などの通信機器又は任意選択で測位モジュール１０５８と連携する処理システム１０３６などの処理システムに、対応し得る。本明細書で論じられるように、決定するためのモジュール２２４０は、少なくとも幾つかの態様では、例えば、任意選択で測位モジュール１０５８と連携する処理システム１０３６などの処理システムに対応し得る。本明細書で論じられるように、送信するためのモジュール２２５０は、少なくとも幾つかの態様では、例えば、図１０の通信機器１０２６などの通信機器、又は、任意選択で測位モジュール１０５８と連携する処理システム１０３６などの処理システムに、対応し得る。
[00292]図２３は、一連の相互に関係する機能モジュールとして表される例示的な位置サーバ装置２３００を示す。本明細書で論じられるように、受信するためのモジュール２３１０は、少なくとも幾つかの態様では、例えば、図１０の通信機器１０２６などの通信機器又は任意選択で測位モジュール１０５８と連携する処理システム１０３６などの処理システムに、対応し得る。本明細書で論じられるように、認証するためのモジュール２３２０は、少なくとも幾つかの態様では、例えば、任意選択で測位モジュール１０５８と連携する処理システム１０３６などの処理システムに対応し得る。本明細書で論じられるように、決定するためのモジュール２３３０は、少なくとも幾つかの態様では、例えば、任意選択で測位モジュール１０５８と連携する処理システム１０３６などの処理システムに対応し得る。本明細書で論じられるように、送信するためのモジュール２３４０は、少なくとも幾つかの態様では、例えば、図１０の通信機器１０２６などの通信機器、又は、任意選択で測位モジュール１０５８と連携する処理システム１０３６などの処理システムに、対応し得る。
[00293]図２４は、一連の相互に関係する機能モジュールとして表される例示的なユーザ機器装置２４００を示す。本明細書で論じられるように、送信するためのモジュール２４１０は、少なくとも幾つかの態様では、例えば、図１０の通信機器１００８などの通信機器、又は、任意選択で測位モジュール１０５４と連携する処理システム１０３２などの処理システムに、対応し得る。本明細書で論じられるように、受信するためのモジュール２４２０は、少なくとも幾つかの態様では、例えば、図１０の通信機器１００８などの通信機器、又は、任意選択で測位モジュール１０５４と連携する処理システム１０３２などの処理システムに、対応し得る。本明細書で論じられるように、受信するためのモジュール２４３０は、少なくとも幾つかの態様では、例えば、図１０の通信機器１００８などの通信機器、又は、任意選択で測位モジュール１０５４と連携する処理システム１０３２などの処理システムに、対応し得る。本明細書で論じられるように、送信するためのモジュール２４４０は、少なくとも幾つかの態様では、例えば、図１０の通信機器１００８などの通信機器、又は、任意選択で測位モジュール１０５４と連携する処理システム１０３２などの処理システムに、対応し得る。
[00294]図２５は、一連の相互に関係する機能モジュールとして表される例示的なＯＴＴサービスプロバイダ装置２５００を示す。本明細書で論じられるように、受信するためのモジュール２５１０は、少なくとも幾つかの態様では、例えば、図１０の通信機器１０２６などの通信機器、又は、任意選択で測位モジュール１０５８と連携する処理システム１０３６などの処理システムに、対応し得る。本明細書で論じられるように、送信するためのモジュール２５２０は、少なくとも幾つかの態様では、例えば、図１０の通信機器１０２６などの通信機器、又は、任意選択で測位モジュール１０５８と連携する処理システム１０３６などの処理システムに、対応し得る。
[00295]図２６は、一連の相互に関係する機能モジュールとして表される例示的なＩＭＳエンティティ装置２６００を示す。本明細書で論じられるように、受信するためのモジュール２６１０は、少なくとも幾つかの態様では、例えば、図１０の通信機器１０２６などの通信機器、又は、任意選択で測位モジュール１０５８と連携する処理システム１０３６などの処理システムに、対応し得る。本明細書で論じられるように、決定するためのモジュール２６２０は、少なくとも幾つかの態様では、例えば、任意選択で測位モジュール１０５８と連携する処理システム１０３６などの処理システムに対応し得る。
[00296]図２７は、一連の相互に関係する機能モジュールとして表される例示的なユーザ機器装置２７００を示す。本明細書で論じられるように、受信するためのモジュール２７１０は、少なくとも幾つかの態様では、例えば、図１０の通信機器１００８などの通信機器、又は、任意選択で測位モジュール１０５４と連携する処理システム１０３２などの処理システムに、対応し得る。本明細書で論じられるように、取得するためのモジュール２７２０は、少なくとも幾つかの態様では、例えば、図１０の通信機器１００８などの通信機器、又は、任意選択で測位モジュール１０５４と連携する処理システム１０３２などの処理システムに、対応し得る。本明細書で論じられるように、送信するためのモジュール２７３０は、少なくとも幾つかの態様では、例えば、図１０の通信機器１００８などの通信機器又は任意選択で測位モジュール１０５４と連携する処理システム１０３２などの処理システムに、対応し得る。
[00297]図２１〜図２７のモジュールの機能は、本明細書の教示に一致する様々な方法で実装され得る。幾つかの設計では、これらのモジュールの機能は、１つ又は複数の電気的構成要素として実装され得る。幾つかの設計では、これらのブロックの機能は、１つ又は複数のプロセッサ構成要素を含む処理システムとして実装され得る。幾つかの設計では、これらのモジュールの機能は、例えば、１つ又は複数の集積回路（例えば、ＡＳＩＣ）の少なくとも一部分を使用して実装され得る。本明細書で説明されるように、集積回路は、プロセッサ、ソフトウェア、他の関係する構成要素又はそれらの何らかの組合せを含み得る。従って、異なるモジュールの機能は、例えば、集積回路の異なるサブセットとして、ソフトウェアモジュールのセットの異なるサブセットとして、又はそれらの組合せとして実装され得る。また、（例えば、集積回路の及び／又はソフトウェアモジュールのセットの）所与のサブセットは、機能の少なくとも一部分を２つ以上のモジュールに与え得ることが理解されるだろう。
[00298]更に、図２１〜図２７によって表される構成要素及び機能並びに本明細書で説明される他の構成要素及び機能は、任意の適切な手段を使用して実装され得る。そのような手段はまた、少なくとも部分的に、本明細書で教示される対応する構造を使用して実装され得る。例えば、図２１〜図２７の構成要素「のためのモジュール」に関連して上で説明された構成要素は、同様に指定された機能「のための手段」に対応することもある。従って、幾つかの態様では、そのような手段のうちの１つ又は複数は、本明細書で教示されるプロセッサ構成要素、集積回路、又は他の適切な構造のうちの１つ又は複数を使用して実装され得る。
[00299]情報及び信号は、多種多様な技術及び技法のいずれかを使用して表され得ることを当業者は理解するだろう。例えば、上記の説明全体にわたって言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、及びチップは、電圧、電流、電磁波、磁界又は磁性粒子、光場又は光学粒子、あるいはそれらの任意の組合せによって表され得る。
[00300]更に、本明細書で開示される実施形態に関連して説明される様々な例示的な論理ブロック、モジュール、回路、及びアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、又は両方の組合せとして実装され得ることを、当業者は理解するだろう。ハードウェアとソフトウェアのこの互換性を明確に示すために、様々な例示的な構成要素、ブロック、モジュール、回路及びステップについて、上では概してそれらの機能に関して説明された。そのような機能をハードウェアとして実装するか、ソフトウェアとして実装するかは、具体的な適用例及び全体的なシステムに課された設計制約に依存する。当業者は、説明された機能を、具体的な適用例ごとに様々な方法で実装し得るが、そのような実装の決定は、本開示の範囲からの逸脱を引き起こすと解釈されるべきではない。
[00301]本明細書で開示される実施形態に関して説明された様々な例示的な論理ブロック、モジュール、及び回路は、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）若しくは他のプログラマブル論理機器、個別のゲート若しくはトランジスタ論理、個別のハードウェア構成要素、又は本明細書で説明される機能を実行するように設計されたそれらの任意の組合せを用いて、実装又は実行され得る。汎用プロセッサはマイクロプロセッサであり得るが、代替として、プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、又は状態機械であり得る。プロセッサは、コンピュータ機器の組合せ、例えば、ＤＳＰとマイクロプロセッサとの組合せ、複数のマイクロプロセッサ、ＤＳＰコアと連携する１つ以上のマイクロプロセッサ、又は任意の他のそのような構成として実装されることもある。
[00302]本明細書で開示される実施形態に関して説明する方法、シーケンス及び／又はアルゴリズムは、ハードウェアで直接実装されるか、プロセッサによって実行されるソフトウェアモジュールで実装されるか、又はそれらの２つの組合せで実装され得る。ソフトウェアモジュールは、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、リムーバブルディスク、ＣＤ−ＲＯＭ、又は当技術分野で知られている任意の他の形態の記憶媒体中に存在することがある。例示的な記憶媒体は、プロセッサが記憶媒体から情報を読み取り、及び記憶媒体に情報を書き込むことができるように、プロセッサに結合される。代替として、記憶媒体はプロセッサに一体であり得る。プロセッサ及び記憶媒体は、ＡＳＩＣ中に存在し得る。ＡＳＩＣはユーザ端末（例えば、ＵＥ）中に存在し得る。代替形態では、プロセッサ及び記憶媒体は、ユーザ端末内の個別の構成要素として存在し得る。
[00303]１つ又は複数の例示的な実施形態では、説明された機能は、ハードウェア、ソフトウェア、ファームウェア、又はそれらの任意の組合せで実装され得る。ソフトウェアで実装される場合、機能は、１つ又は複数の命令又はコードとしてコンピュータ可読媒体上に記憶されるか、あるいはコンピュータ可読媒体を介して送信され得る。コンピュータ可読媒体は、コンピュータプログラムのある場所から別の場所への転送を容易にする任意の媒体を含む、コンピュータ記憶媒体と通信媒体の両方を含む。記憶媒体は、コンピュータによってアクセスされ得る任意の利用可能な媒体であり得る。限定ではなく例として、そのようなコンピュータ可読媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭ若しくは他の光ディスクストレージ、磁気ディスクストレージ若しくは他の磁気ストレージ機器、又は、命令若しくはデータ構造の形態の所望のプログラムコードを搬送若しくは記憶するために使用され、コンピュータによってアクセスされ得る任意の他の媒体を備え得る。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。例えば、同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者線（ＤＳＬ）、又は赤外線、無線、及びマイクロ波などのワイヤレス技術を使用して、ソフトウェアがウェブサイト、サーバ又は他のリモートソースから送信される場合、同軸ケーブル、光ファイバケーブル、ツイストペア、ＤＳＬ、又は赤外線、無線、及びマイクロ波などワイヤレス技術は、媒体の定義に含まれる。本明細書で使用されるディスク（disk）及びディスク（disc）は、コンパクトディスク（disc）（ＣＤ）、レーザーディスク（登録商標）（disc）、光ディスク（disc）、デジタル多用途ディスク（disc）（ＤＶＤ）、フロッピーディスク（disk）及びＢｌｕ−ｒａｙ（登録商標）ディスク（disc）を含み、ここで、ディスク（disk）は、通常、データを磁気的に再生し、ディスク（disc）は、データをレーザーで光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲に含まれるべきである。
[00304]上記の開示は本開示の例示的な実施形態を示すが、添付の特許請求の範囲によって規定される本開示の範囲から逸脱することなく、本明細書において様々な変更及び修正が行われ得ることに留意されたい。本明細書で説明された本開示の実施形態による方法クレームの機能、ステップ及び／又はアクションは、特定の順序で実行されなくてもよい。更に、本開示の要素は、単数形で説明又は請求されていることがあるが、単数形に限定することが明示的に述べられていない限り、複数形が企図される。
以下に本願の出願当初の特許請求の範囲に記載された発明を付記する。
［Ｃ１］
オーバーザトップ（ＯＴＴ）サービスプロバイダにおいて緊急呼をサポートする方法であって、
ユーザ機器（ＵＥ）から緊急呼要求を備える第１のメッセージを受信することと、ここにおいて、前記第１のメッセージが前記ＵＥのサービングモバイルネットワーク事業者（ＭＮＯ）を介して前記ＯＴＴサービスプロバイダに移送され、前記第１のメッセージが前記サービングＭＮＯのインターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）のアドレスを含む、
前記アドレスに基づいて第２のメッセージを前記ＩＭＳに送信することと、ここにおいて、前記第２のメッセージが緊急呼に対する要求を備える、を備える方法。
［Ｃ２］
前記第１のメッセージ、前記第２のメッセージ、又は両方のメッセージが、セッション開始プロトコル（ＳＩＰ） ＩＮＶＩＴＥメッセージを備える、Ｃ１に記載の方法。
［Ｃ３］
宛先緊急応答機関（ＰＳＡＰ）のためのルーティング情報を備える第３のメッセージを前記ＩＭＳから受信することと、
前記ルーティング情報に基づいて、前記ＰＳＡＰに、又は前記ＰＳＡＰに向かって第４のメッセージを送信することとを更に備え、前記第４のメッセージが緊急呼に対する要求を備える、Ｃ１に記載の方法。
［Ｃ４］
前記第３のメッセージが、セッション開始プロトコル（ＳＩＰ） ３００ Ｍｕｌｔｉｐｌｅ Ｃｈｏｉｃｅｓメッセージを備える、Ｃ３に記載の方法。
［Ｃ５］
前記ＩＭＳの前記アドレスが、位置検索機能（ＬＲＦ）のためのものである、Ｃ３に記載の方法。
［Ｃ６］
前記ルーティング情報が基準識別子（ＩＤ）を含み、前記方法が、
前記第４のメッセージに前記基準ＩＤを含めることを更に備え、前記基準ＩＤが、前記ＰＳＡＰが前記ＬＲＦから前記ＵＥの位置を取得することを可能にする、Ｃ５に記載の方法。
［Ｃ７］
前記ＩＭＳが、宛先ＰＳＡＰに、又は前記ＰＳＡＰに向かって第５のメッセージを送信し、前記第５のメッセージが前記ＵＥに対する緊急呼要求を備える、Ｃ１に記載の方法。
［Ｃ８］
前記ＩＭＳの前記アドレスが、緊急呼セッション制御機能（Ｅ−ＣＳＣＦ）のためのものである、Ｃ７に記載の方法。
［Ｃ９］
前記ＩＭＳが、前記第５のメッセージに基準識別子を含め、前記基準識別子が、前記ＰＳＡＰが前記ＩＭＳから前記ＵＥの位置を取得することを可能にする、Ｃ７に記載の方法。
［Ｃ１０］
サービングモバイルネットワーク事業者（ＭＮＯ）のためのＩＰマルチメディアサブシステム（ＩＭＳ）エンティティにおいて緊急呼をサポートする方法であって、
ユーザ機器（ＵＥ）に対する緊急呼要求を備える、オーバーザトップ（ＯＴＴ）サービスプロバイダによって送信される第１のメッセージを受信することと、ここにおいて、前記緊急呼要求が前記ＵＥのためのＭＮＯデータを含む、
前記ＭＮＯデータに基づいて、宛先緊急応答機関（ＰＳＡＰ）のためのルーティング情報を決定することとを備える、方法。
［Ｃ１１］
前記第１のメッセージが、セッション開始プロトコル（ＳＩＰ） ＩＮＶＩＴＥメッセージを備える、Ｃ１０に記載の方法。
［Ｃ１２］
前記ルーティング情報を備える第２のメッセージを前記ＯＴＴサービスプロバイダに送信することを更に備え、前記ルーティング情報が、前記ＯＴＴサービスプロバイダが、前記宛先ＰＳＡＰに、又は前記宛先ＰＳＡＰに向かって前記緊急呼をルーティングすることを可能にする、Ｃ１０に記載の方法。
［Ｃ１３］
前記第２のメッセージが、セッション開始プロトコル（ＳＩＰ） ３００ Ｍｕｌｔｉｐｌｅ Ｃｈｏｉｃｅｓメッセージを備える、Ｃ１２に記載の方法。
［Ｃ１４］
前記ＩＭＳエンティティが位置検索機能（ＬＲＦ）である、Ｃ１２に記載の方法。
［Ｃ１５］
前記ルーティング情報が、基準識別子（ＩＤ）と、前記ＰＳＡＰ又は中間の宛先のいずれかの前記アドレス若しくは識別情報とを備える、Ｃ１２に記載の方法。
［Ｃ１６］
別のエンティティから前記基準ＩＤを備える第３のメッセージを受信することと、
前記基準ＩＤに基づいて前記ＵＥを識別することと、
前記ＵＥの位置を取得することと、
前記位置を備える第４のメッセージを前記他のエンティティに送信することとを更に備える、Ｃ１５に記載の方法。
［Ｃ１７］
前記基準ＩＤが、緊急サービスルーティングキー（ＥＳＲＫ）、緊急サービスルーティングディジット（ＥＳＲＤ）と移動局国際加入者ディレクトリ番号（ＭＳＩＳＤＮ）又はロケーション統一資源識別子（ＵＲＩ）を備える、Ｃ１６に記載の方法。
［Ｃ１８］
前記ＵＥの前記位置が、制御プレーン位置特定解決法又はユーザプレーン位置特定解決法を使用して取得される、Ｃ１６に記載の方法。
［Ｃ１９］
前記他のエンティティが、前記ＰＳＡＰ、自動位置識別（ＡＬＩ）又は緊急サービスＩＰネットワーク（ＥＳＩｎｅｔ）である、Ｃ１６に記載の方法。
［Ｃ２０］
前記ルーティング情報に基づいて、前記ＰＳＡＰに、又は前記ＰＳＡＰに向かって第２のメッセージを送信することを更に備え、前記第２のメッセージが前記緊急呼に対する要求を備える、Ｃ１０に記載の方法。
［Ｃ２１］
前記ＩＭＳエンティティが、緊急呼セッション制御機能（ＣＳＣＦ）である、Ｃ２０に記載の方法。
［Ｃ２２］
ユーザ機器（ＵＥ）において緊急呼をサポートする方法であって、
前記ＵＥのユーザから緊急呼に対する要求を受信することと、
前記ＵＥのサービングモバイルネットワーク事業者（ＭＮＯ）のためのＭＮＯデータを取得することと、
前記緊急呼に対する要求を備える第１のメッセージをオーバーザトップ（ＯＴＴ）サービスプロバイダに送信することとを備え、前記緊急呼に対する前記要求が前記ＭＮＯデータを含む、方法。
［Ｃ２３］
前記ＭＮＯデータが、前記サービングＭＮＯのインターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）のアドレス、前記ＵＥの現在のサービングモビリティ管理エンティティ若しくはサービング汎用パケット無線サービスサポートノード（ＳＧＳＮ）の識別情報、サービングＭＮＯにより割り当てられた前記ＵＥのＩＰアドレス、前記ＵＥのグローバル識別情報又はローカル識別情報若しくはこれらの任意の組合せを備える、Ｃ２２に記載の方法。
［Ｃ２４］
前記ＯＴＴサービスプロバイダが、前記ＩＭＳの前記アドレスに基づいて第２のメッセージを前記ＩＭＳに送信し、前記第２のメッセージが前記緊急呼に対する要求を備え、前記ＭＮＯデータを含む、Ｃ２３に記載の方法。
［Ｃ２５］
前記ＩＭＳが、前記ＭＮＯデータに基づいて前記緊急呼のためのルーティング情報を決定する、Ｃ２４に記載の方法。
［Ｃ２６］
ユーザプレーン位置特定解決法又は制御プレーン位置特定解決法に従って、位置推定若しくは位置測定に対する要求を受信することを更に備え、前記位置推定若しくは位置測定が、前記ＩＭＳが前記ＵＥの位置を取得することを可能にし、前記ＵＥの前記位置が、前記ＩＭＳが、前記ルーティング情報を決定すること、又は前記ＵＥの前記位置を前記ＰＳＡＰに提供することを可能にする、Ｃ２５に記載の方法。
［Ｃ２７］
前記ＩＭＳが、前記ルーティング情報を備える第３のメッセージを前記ＯＴＴサービスプロバイダに送信し、前記ＯＴＴサービスプロバイダが、宛先緊急応答機関（ＰＳＡＰ）に、又は前記宛先ＰＳＡＰに向かって第４のメッセージを送信し、前記ＰＳＡＰが前記ルーティング情報に基づいて決定される、Ｃ２５に記載の方法。
［Ｃ２８］
前記ＩＭＳの前記アドレスが、位置検索機能（ＬＲＦ）のアドレスである、Ｃ２７に記載の方法。
［Ｃ２９］
前記ＩＭＳが、宛先ＰＳＡＰに、又は前記宛先ＰＳＡＰに向かって第５のメッセージを送信し、前記第５のメッセージが前記緊急呼に対する要求を備え、前記ＰＳＡＰが前記ルーティング情報に基づいて決定される、Ｃ２５に記載の方法。
［Ｃ３０］
オーバーザトップ（ＯＴＴ）サービスプロバイダにおいて緊急呼をサポートするための装置であって、
少なくとも１つのプロセッサと、
前記少なくとも１つのプロセッサに結合された送受信機とを備え、前記送受信機が、
ユーザ機器（ＵＥ）から緊急呼要求を備える第１のメッセージを受信することと、ここにおいて、前記第１のメッセージが前記ＵＥのサービングモバイルネットワーク事業者（ＭＮＯ）を介して前記ＯＴＴサービスプロバイダに移送され、前記第１のメッセージが前記サービングＭＮＯのインターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）のアドレスを含む、
前記アドレスに基づいて第２のメッセージを前記ＩＭＳに送信することと、ここにおいて、前記第２のメッセージが前記緊急呼に対する要求を備える、
を行うように構成される、装置。

Claims (22)

  1. オーバーザトップ（ＯＴＴ）サービスプロバイダにおいて緊急呼をサポートする方法であって、
    ユーザ機器（ＵＥ）から緊急呼要求を備える第１のメッセージを受信することと、ここにおいて、前記第１のメッセージが前記ＵＥのサービングモバイルネットワーク事業者（ＭＮＯ）を介して前記ＯＴＴサービスプロバイダに移送され、前記第１のメッセージが前記サービングＭＮＯのインターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）のアドレスを含む、
    前記ＯＴＴサービスプロバイダが前記アドレスによって示される前記ＩＭＳに、ＭＮＯデータを含む第２のメッセージを送信することと、ここにおいて、前記第２のメッセージが緊急呼に対する要求を備える、
    前記ＩＭＳが、前記ＭＮＯデータに基づいて宛先緊急応答機関（ＰＳＡＰ）に向かう前記ＯＴＴサービスプロバイダからの呼のルーティングを可能にするルーティング情報を決定することと、
    前記ＯＴＴサービスプロバイダが、前記ＩＭＳによって決定されたルーティング情報を受信することと、
    を備える方法。
  2. 前記第１のメッセージ、前記第２のメッセージ、又は両方のメッセージが、セッション開始プロトコル（ＳＩＰ） ＩＮＶＩＴＥメッセージを備える、請求項１に記載の方法。
  3. 前記宛先緊急応答機関（ＰＳＡＰ）のための前記ルーティング情報を備える第３のメッセージを前記ＩＭＳから受信することと、
    前記ルーティング情報に基づいて、前記ＰＳＡＰに、又は前記ＰＳＡＰに向かって第４のメッセージを送信することとを更に備え、前記第４のメッセージが緊急呼に対する要求を備える、請求項１に記載の方法。
  4. 前記第３のメッセージが、セッション開始プロトコル（ＳＩＰ） ３００ Ｍｕｌｔｉｐｌｅ Ｃｈｏｉｃｅｓメッセージを備える、請求項３に記載の方法。
  5. 前記ＩＭＳの前記アドレスが、位置検索機能（ＬＲＦ）のためのものである、請求項３に記載の方法。
  6. 前記ルーティング情報が基準識別子（ＩＤ）を含み、前記方法が、
    前記第４のメッセージに前記基準ＩＤを含めることを更に備え、前記基準ＩＤが、前記ＰＳＡＰが前記ＬＲＦから前記ＵＥの位置を取得することを可能にする、請求項５に記載の方法。
  7. 前記ＩＭＳが、前記宛先ＰＳＡＰに、又は前記宛先ＰＳＡＰに向かって第５のメッセージを送信し、前記第５のメッセージが前記ＵＥに対する緊急呼要求を備える、請求項１に記載の方法。
  8. 前記ＩＭＳの前記アドレスが、緊急呼セッション制御機能（Ｅ−ＣＳＣＦ）のためのものである、請求項７に記載の方法。
  9. 前記ＩＭＳが、前記第５のメッセージに基準識別子を含め、前記基準識別子が、前記ＰＳＡＰが前記ＩＭＳから前記ＵＥの位置を取得することを可能にする、請求項７に記載の方法。
  10. サービングモバイルネットワーク事業者（ＭＮＯ）のためのＩＰマルチメディアサブシステム（ＩＭＳ）エンティティにおいて緊急呼をサポートする方法であって、
    ユーザ機器（ＵＥ）に対する緊急呼要求を備える、オーバーザトップ（ＯＴＴ）サービスプロバイダによって送信される第１のメッセージを受信することと、ここにおいて、前記緊急呼要求が前記ＵＥのためのＭＮＯデータを含み、前記ＭＮＯデータは、（ｉ）ＩＭＳアドレス、（ｉｉ）制御プレーン位置特定が使用される場合、前記ＵＥの現在のサービングＭＭＥ又は現在のサービングＳＧＳＮの識別情報、（ｉｉｉ）ユーザプレーン位置特定が使用される場合、前記ＵＥのＭＮＯにより割り当てられたＩＰアドレス及び（ｉｖ）前記ＵＥのグローバル識別情報と、前記ＵＥの前記サービングＭＭＥ又はサービングＳＧＳＮによって割り当てられた前記ＵＥのローカル識別情報とのいずれか、のうちの少なくとも１つを含む、
    前記ＭＮＯデータに基づいて、宛先緊急応答機関（ＰＳＡＰ）のためのルーティング情報を決定することと
    を備える、方法。
  11. 前記第１のメッセージが、セッション開始プロトコル（ＳＩＰ） ＩＮＶＩＴＥメッセージを備える、請求項１０に記載の方法。
  12. 前記ルーティング情報を備える第２のメッセージを前記ＯＴＴサービスプロバイダに送信することを更に備え、前記ルーティング情報が、前記ＯＴＴサービスプロバイダが、前記宛先ＰＳＡＰに、又は前記宛先ＰＳＡＰに向かって前記緊急呼をルーティングすることを可能にする、請求項１０に記載の方法。
  13. 前記第２のメッセージが、セッション開始プロトコル（ＳＩＰ） ３００ Ｍｕｌｔｉｐｌｅ Ｃｈｏｉｃｅｓメッセージを備える、請求項１２に記載の方法。
  14. 前記ＩＭＳエンティティが位置検索機能（ＬＲＦ）である、請求項１２に記載の方法。
  15. 前記ルーティング情報が、基準識別子（ＩＤ）と、前記ＰＳＡＰ又は中間の宛先のいずれかの前記アドレス若しくは識別情報とを備える、請求項１２に記載の方法。
  16. 別のエンティティから前記基準ＩＤを備える第３のメッセージを受信することと、
    前記基準ＩＤに基づいて前記ＵＥを識別することと、
    前記ＵＥの位置を取得することと、
    前記位置を備える第４のメッセージを前記別のエンティティに送信することとを更に備える、請求項１５に記載の方法。
  17. 前記基準ＩＤが、緊急サービスルーティングキー（ＥＳＲＫ）、緊急サービスルーティングディジット（ＥＳＲＤ）と移動局国際加入者ディレクトリ番号（ＭＳＩＳＤＮ）又はロケーション統一資源識別子（ＵＲＩ）を備える、請求項１６に記載の方法。
  18. 前記ＵＥの前記位置が、制御プレーン位置特定解決法又はユーザプレーン位置特定解決法を使用して取得される、請求項１６に記載の方法。
  19. 前記別のエンティティが、前記ＰＳＡＰ、自動位置識別（ＡＬＩ）又は緊急サービスＩＰネットワーク（ＥＳＩｎｅｔ）である、請求項１６に記載の方法。
  20. 前記ルーティング情報に基づいて、前記ＰＳＡＰに、又は前記ＰＳＡＰに向かって第２のメッセージを送信することを更に備え、前記第２のメッセージが前記緊急呼に対する要求を備える、請求項１０に記載の方法。
  21. 前記ＩＭＳエンティティが、緊急呼セッション制御機能（ＣＳＣＦ）である、請求項２０に記載の方法。
  22. オーバーザトップ（ＯＴＴ）サービスプロバイダにおいて緊急呼をサポートするための装置であって、
    少なくとも１つのプロセッサと、
    前記少なくとも１つのプロセッサに結合された送受信機とを備え、前記送受信機が、
    ユーザ機器（ＵＥ）から緊急呼要求を備える第１のメッセージを受信することと、ここにおいて、前記第１のメッセージが前記ＵＥのサービングモバイルネットワーク事業者（ＭＮＯ）を介して前記ＯＴＴサービスプロバイダに移送され、前記第１のメッセージが前記サービングＭＮＯのインターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）のアドレスを含む、
    前記ＯＴＴサービスプロバイダが前記アドレスによって示される前記ＩＭＳに、ＭＮＯデータを含む第２のメッセージを送信することと、ここにおいて、前記第２のメッセージが前記緊急呼に対する要求を備える、
    前記ＩＭＳが、前記ＭＮＯデータに基づいて宛先緊急応答機関（ＰＳＡＰ）に向かう前記ＯＴＴサービスプロバイダからの呼のルーティングを可能にするルーティング情報を決定すること、
    前記ＯＴＴサービスプロバイダが、前記ＩＭＳによって決定されたルーティング情報を受信すること、
    を行うように構成される、装置。
JP2017527555A 2014-11-24 2015-11-10 オーバーザトップサービスプロバイダのために位置特定と緊急呼とをサポートする方法 Active JP6374110B2 (ja)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US201462083768P 2014-11-24 2014-11-24
US62/083,768 2014-11-24
US201562101974P 2015-01-09 2015-01-09
US62/101,974 2015-01-09
US14/863,751 2015-09-24
US14/863,751 US9756664B2 (en) 2014-11-24 2015-09-24 Methods of supporting location and emergency calls for an over-the-top service provider
PCT/US2015/059998 WO2016085647A1 (en) 2014-11-24 2015-11-10 Methods of supporting location and emergency calls for an over-the-top service provider

Publications (2)

Publication Number Publication Date
JP2017536768A JP2017536768A (ja) 2017-12-07
JP6374110B2 true JP6374110B2 (ja) 2018-08-15

Family

ID=56011640

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017527555A Active JP6374110B2 (ja) 2014-11-24 2015-11-10 オーバーザトップサービスプロバイダのために位置特定と緊急呼とをサポートする方法

Country Status (11)

Country Link
US (2) US9756664B2 (ja)
EP (1) EP3225042B1 (ja)
JP (1) JP6374110B2 (ja)
KR (1) KR101825898B1 (ja)
CN (1) CN107113566B (ja)
AU (1) AU2015354709B2 (ja)
BR (1) BR112017010777B1 (ja)
DK (1) DK3225042T3 (ja)
ES (1) ES2775501T3 (ja)
HU (1) HUE047306T2 (ja)
WO (1) WO2016085647A1 (ja)

Families Citing this family (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3198979A1 (en) * 2014-09-17 2017-08-02 Nokia Technologies OY Emergency call handling using over-the-top services
US10097979B2 (en) 2014-11-24 2018-10-09 Qualcomm Incorporated Location by reference for an over-the-top emergency call
US9756664B2 (en) 2014-11-24 2017-09-05 Qualcomm Incorporated Methods of supporting location and emergency calls for an over-the-top service provider
US10278100B1 (en) 2016-03-16 2019-04-30 Sprint Communications Company L.P. Long term evolution (LTE) mobility management entity (MME) management of an internet protocol multimedia subsystem (IMS) media session service level for a user equipment (UE)
US9706351B1 (en) * 2016-04-29 2017-07-11 Peerless Network, Inc. Emergency call over a data network
US20190159160A1 (en) * 2016-05-03 2019-05-23 Telefonaktiebolaget Lm Ericsson (Publ) Methods and network nodes for providing ue location for vowifi calls
CN109661853B (zh) * 2016-09-07 2020-12-08 华为技术有限公司 本地分组数据网络的动态创建方法、装置及系统
US11165833B2 (en) * 2016-11-02 2021-11-02 T-Mobile Usa, Inc. Network routing based on terminal's media path
WO2018157194A1 (en) 2017-03-03 2018-09-07 Mararlee Pty Ltd System and method for delivery and receipt of electronic communications
US10244574B2 (en) * 2017-03-09 2019-03-26 T-Mobile Usa, Inc. Call setup timer triggered and terminated by different protocols
US10694364B2 (en) * 2017-03-24 2020-06-23 Apple Inc. Providing a local address while roaming
US10111077B1 (en) * 2017-04-19 2018-10-23 Qualcomm Incorporated System and method for enabling mobile device location services during an emergency call
SG11202000353QA (en) * 2017-08-09 2020-02-27 Nokia Solutions & Networks Oy Emergency voice service support indications
GB2567980B (en) 2017-08-30 2020-01-01 Metaswitch Networks Ltd Establishing a telephony session
KR102422619B1 (ko) * 2018-02-14 2022-07-20 삼성전자 주식회사 위급한 상황에 처한 사용자의 위치 정보를 제공하는 전자 장치 및 방법
JP6992906B2 (ja) * 2018-03-28 2022-01-13 日本電気株式会社 ユーザ装置のための方法及びユーザ装置
US20190335040A1 (en) * 2018-04-26 2019-10-31 Microsoft Technology Licensing, Llc Prioritized routing during a regional event
US10999422B2 (en) * 2018-05-11 2021-05-04 Sony Corporation Confirming geolocation of a device
CN110677844B (zh) * 2018-07-03 2022-04-08 中国电信股份有限公司 呼叫方法、信息交互方法、通信设备和交互平台
CN111131997B (zh) * 2018-10-12 2021-08-06 大唐移动通信设备有限公司 一种上行到达时间差定位方法及其装置
US11792631B2 (en) 2019-01-31 2023-10-17 Huawei Technologies Co., Ltd. Emergency call method and user terminal
US11277450B2 (en) * 2019-02-04 2022-03-15 Verizon Patent And Licensing Inc. Over-the-top client with native calling quality of service
US11526826B2 (en) 2019-11-07 2022-12-13 Nokia Solutions And Networks Oy Remote definition of metrics
US11689367B2 (en) * 2020-09-24 2023-06-27 Huawei Technologies Co., Ltd. Authentication method and system
US11330103B1 (en) * 2021-01-05 2022-05-10 T-Mobile Usa, Inc. Call state notification for emergency call processing
WO2022177859A1 (en) * 2021-02-17 2022-08-25 Qualcomm Incorporated Systems and techniques to support cell identification for satellite wireless access
US11477632B2 (en) 2021-02-17 2022-10-18 Qualcomm Incorporated Systems and techniques to support cell identification for satellite wireless access
US11617059B1 (en) 2021-05-28 2023-03-28 T-Mobile Usa, Inc. Mobile device geographic location determination for emergency services
US11924514B2 (en) * 2022-03-17 2024-03-05 Charter Communications Operating, Llc Caller identification for a destination wireless user equipment

Family Cites Families (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1932330A4 (en) * 2005-04-12 2011-05-04 Telecomm Systems Inc TEMPORARY ENUM GATEWAY
US20070086382A1 (en) 2005-10-17 2007-04-19 Vidya Narayanan Methods of network access configuration in an IP network
US20070153986A1 (en) * 2006-01-03 2007-07-05 Sony Ericsson Mobile Communications Ab Method and Apparatus for Routing Emergency Calls in a VoIP System
US7463880B2 (en) * 2006-01-13 2008-12-09 Kyocera Wireless Corp. E911 behavior with GSRM in a wireless communication device
US8493267B2 (en) 2006-11-10 2013-07-23 Qualcomm Incorporated Method and apparatus for position determination with extended SPS orbit information
US9185216B2 (en) * 2007-06-15 2015-11-10 Blackberry Limited System and method for indicating emergency call back to user equipment
US7991382B1 (en) * 2007-11-08 2011-08-02 Sprint Spectrum L.P. Method for communicating indoor location to an emergency service system
US20090154397A1 (en) * 2007-12-17 2009-06-18 Nortel Networks Limited System and method for providing quality of service enablers for third party applications
US8254877B2 (en) 2008-01-04 2012-08-28 Qualcomm Incorporated Method and apparatus for extended call establishment for IMS emergency calls
US9208293B1 (en) 2008-01-28 2015-12-08 Sprint Communications Company L.P. Authentication for tag-based content delivery
US8369822B2 (en) * 2009-05-28 2013-02-05 At&T Intellectual Property I, Lp Systems and methods for providing emergency callback procedures
US8594015B2 (en) * 2009-07-29 2013-11-26 T-Mobile Usa, Inc. System and method for providing emergency service in an IP-based wireless network
US20110026687A1 (en) * 2009-07-31 2011-02-03 Vladimir Smelyansky Emergency 911 services with just-in-time provisioning for voip customers
US8270574B2 (en) * 2009-09-08 2012-09-18 Verizon Patent And Licensing Inc. Emergency calls in internet protocol multimedia subsystem (IMS) over evolved packet core (EPC) networks
CN102036204B (zh) 2009-09-24 2015-06-03 中兴通讯股份有限公司 一种实现紧急定位的方法及系统
US8315589B2 (en) * 2009-09-30 2012-11-20 Verizon Patent And Licensing Inc. Emergency calls for internet protocol multimedia subsystem (IMS) over packet switched code division multiple access (CDMA) networks
US9065908B2 (en) 2010-02-12 2015-06-23 Broadcom Corporation Method and system for ensuring user and/or device anonymity for location based services (LBS)
US8774836B2 (en) 2010-03-11 2014-07-08 Broadcom Corporation Method and system for optimized transfer of location database information
WO2012097127A1 (en) * 2011-01-14 2012-07-19 Interdigital Patent Holdings, Inc. Identifying public safety answering point (psap) callbacks in internet protocol (ip) multimedia subsystem (ims) emergency services
US8929855B2 (en) * 2011-12-02 2015-01-06 Maple Acquisition Llc Enabling location determination of user device originating emergency service call
EP2807857B1 (en) * 2012-01-27 2017-06-28 Telefonaktiebolaget LM Ericsson (publ) Handover of emergency calls from a circuit switched to a packet switched access network
US9467907B2 (en) 2012-03-12 2016-10-11 Telefonaktiebolaget Lm Ericsson (Publ) Handover of user-equipment (UE) undetected emergency calls
US9161196B2 (en) 2012-08-07 2015-10-13 Google Technology Holdings LLC Apparatus and method for secure private location information transfer
US9693366B2 (en) 2012-09-27 2017-06-27 Interdigital Patent Holdings, Inc. End-to-end architecture, API framework, discovery, and access in a virtualized network
US20140031003A1 (en) 2012-10-02 2014-01-30 Bandwidth.Com, Inc. Methods and systems for providing emergency calling
US9609497B2 (en) * 2012-11-16 2017-03-28 Verizon Patent And Licensing Inc. Intelligent emergency session handling
EP2932680A1 (en) 2012-12-12 2015-10-21 Interdigital Patent Holdings, Inc. Independent identity management systems
US9426833B2 (en) * 2013-03-01 2016-08-23 T-Mobile Usa, Inc. Systems and methods for emergency call route failover
US9516689B2 (en) 2014-02-21 2016-12-06 Apple Inc. Mitigating no-service delays for LTE capable wireless devices without LTE access permission
EP3198979A1 (en) * 2014-09-17 2017-08-02 Nokia Technologies OY Emergency call handling using over-the-top services
WO2016080880A1 (en) * 2014-11-20 2016-05-26 Telefonaktiebolaget L M Ericsson (Publ) Method and arrangement for retrieving geographic location
US9756664B2 (en) 2014-11-24 2017-09-05 Qualcomm Incorporated Methods of supporting location and emergency calls for an over-the-top service provider
US10097979B2 (en) 2014-11-24 2018-10-09 Qualcomm Incorporated Location by reference for an over-the-top emergency call

Also Published As

Publication number Publication date
WO2016085647A1 (en) 2016-06-02
US9756664B2 (en) 2017-09-05
CN107113566B (zh) 2018-11-02
AU2015354709A1 (en) 2017-05-04
US20180014338A1 (en) 2018-01-11
EP3225042B1 (en) 2020-01-01
KR101825898B1 (ko) 2018-02-05
BR112017010777A2 (pt) 2018-01-09
JP2017536768A (ja) 2017-12-07
EP3225042A1 (en) 2017-10-04
CN107113566A (zh) 2017-08-29
AU2015354709B2 (en) 2018-10-04
DK3225042T3 (da) 2020-02-10
US20160150574A1 (en) 2016-05-26
BR112017010777B1 (pt) 2023-10-17
US10165395B2 (en) 2018-12-25
HUE047306T2 (hu) 2020-04-28
KR20170091600A (ko) 2017-08-09
ES2775501T3 (es) 2020-07-27

Similar Documents

Publication Publication Date Title
JP6374110B2 (ja) オーバーザトップサービスプロバイダのために位置特定と緊急呼とをサポートする方法
US10085142B2 (en) Location by reference for an over-the-top emergency call
US9980086B2 (en) System and method for providing emergency service in an IP-based wireless network
JP6736582B2 (ja) 非補償気圧情報の転送
CN101273615B (zh) Voip紧急呼叫处理
US10560570B2 (en) Method, system and device for providing a setup of an enhanced call via a wireless local area network
US20200146080A1 (en) Method, System and Device for Providing a Setup of an Enhanced Call via a Wireless Local Area Network

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20171016

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20171016

A871 Explanation of circumstances concerning accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A871

Effective date: 20171016

A975 Report on accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A971005

Effective date: 20171106

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20171128

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180228

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20180403

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180518

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20180529

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20180619

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20180718

R150 Certificate of patent or registration of utility model

Ref document number: 6374110

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250