説明

無線アクセスネットワークにおける効率的な定期的位置報告

【課題】無線アクセスネットワークにおける効率的な定期的位置報告。
【解決手段】無線アクセスネットワーク(RAN)と通信するユーザ機器(UE)は、ネットワークエンティティに対し、クライアントエンティティへのUE位置の定期的報告のリクエストを送る。リクエストが承認された後、MSC/SGSNは、UEについての定期的位置報告を開始するために、RANにシグナリングを送る。RANは、ポジショニングセンタに対して、支援データをUEに送るように、リクエストすることができる。RANは定期的位置報告を調整しコントロールしてもよいし、あるいはポジショニングセンタにコントロールを渡してもよい。各位置報告について、UEは、位置情報をRANに送る。UEが測定値を送る場合は、SASは位置推定値を計算する。RANは、UEについての位置推定値をMSC/SGSNに送り、クライアントエンティティに向けて位置推定値を転送する。

【発明の詳細な説明】
【背景】
【0001】
(優先権の主張)
本願は、2005年6月21日に出願され、「短絡したメッセージフローを用いた位置サービスを提供する方法および装置(METHOD AND APPARATUS FOR PROVIDING LOCATION SERVICES WITH SHORT-CIRCUITED MESSAGE FLOWS)」と題された仮米国出願シリアル番号60/693と;2005年8月25日に出願され、「無線アクセスネットワークにおける効率的な定期的位置報告(EFFICIENT PERIODIC LOCATION REPORTING IN A RADIO ACCESS NETWORK)」と題された仮米国出願シリアル番号60/711,801と;2005年9月16日に出願され、「無線アクセスネットワークにおける効率的な定期的位置報告(EFFICIENT PERIODIC LOCATION REPORTING IN A RADIO ACCESS NETWORK)」と題された仮米国出願シリアル番号60/718,112と;2006年2月6日に出願され、「無線アクセスネットワークにおける効率的な定期的位置報告(EFFICIENT PERIODIC LOCATION REPORTING IN A RADIO ACCESS NETWORK)」と題された仮米国出願シリアル番号60/771,180と;2006年2月7日に出願され、「定期的位置プロシージャの解明および補正(CLARIFICATION AND CORRECTION OF PERIODIC LOCATION PROCEDURE)」と題された仮米国出願シリアル番号60/771,217と;2006年2月8日に出願され、「定期的位置プロシージャの追加(ADDITION OF PERIODIC LOCATION PROCEDURES)」と題された仮米国出願シリアル番号60/771,706と;の優先権を主張する、なお、これらはすべて、ここでの譲受人に譲渡されており、参照によりここに組み込まれる。
【0002】
(分野)
本開示は、一般に、通信に関し、より具体的には、位置サービス(location services)を提供するための技術に関連する。
【0003】
(背景)
ネットワークにおける無線デバイス(wireless device)の位置(location)を知ることは、多くの場合望ましく、また、時々必要である。例えば、無線ユーザは、ウェブサイトにザット目を通す(browse through a website)ために無線デバイスを利用するかもしれないし、また、ロケーションセンシティブコンテンツ(location sensitive content)をクリックするかもしれない。ウェブサーバ(web server)は、そのとき、無線デバイスの位置についてネットワークを検索する(query)ことができる。ネットワークは、無線デバイスの位置を確認するために、無線デバイスを用いて位置処理(location processing)を開始するだろう。ネットワークは、そのあと、無線デバイスについての位置推定値(location estimate)をウェブサーバに戻すであろう、ウェブサーバは、この位置推定値を、無線ユーザに適切なコンテンツを提供するために使用することができる。無線デバイスの位置についての知識が有用である、あるいは必要である、多くの他のシナリオがある。以下の説明においては、用語「位置(location)」と用語「ポジション(position)」とは、同義語(synonymous)であり、区別なく(interchangeably)使用される。
【0004】
メッセージフロー(message flow)(これはまた、コールフロー(call flow)あるいはプロシージャ(procedure)とも呼ばれてよい)は、典型的に、無線デバイスについての位置推定値を得て、そして、この位置推定値をクライアントエンティティ(client entity)(例、ウェブサーバ)に送るために実行される。様々なメッセージは、典型的に、メッセージフローについての、1つ以上のネットワークエンティティ、無線デバイス、およびクライアントエンティティの間で交換される。これらのメッセージは、無線デバイスについてのポジショニング(positioning)を実行するために、かつ/または、クライアントエンティティに位置推定値を伝えるために、各エンティティには関連情報が提供されている、あるいは、各エンティティはこの情報を別のエンティティから得ることができる、ということを確実にする。然しながら、これらのメッセージは、様々なネットワークエンティティの間のトラフィック(traffic)を増す。追加のトラフィックは、無線デバイスについての位置推定値をクライアントエンティティに定期的に(periodically)提供する定期的位置報告(periodic location reporting)の場合に、特に大きいかもしれない。メッセージはまた、クライアントエンティティに位置推定値を送るための応答時間を、もしかすると受け入れがたい量の分、延ばすかもしれない。
【0005】
従って、当技術分野においては、位置サービスを効率的に提供する技術について必要性がある。
【発明の概要】
【0006】
[概要]
無線アクセスネットワーク(radio access network)(RAN)の定期的LCS機能(periodic LCS capability)を使用する位置サービス(LCS)を効率的に提供する技術が、ここに説明される。これらの技術は、LCSクライアントに無線デバイスの位置を定期的に報告するRANベースの定期的位置報告(RAN-based periodic location reporting)を利用する。RANベースの定期的位置報告は、定期的位置報告についてのモバイルターミネートの位置リクエスト(mobile terminated location request)(MT−LR)プロシージャ(procedure)、ネットワーク誘導の位置リクエスト(network induced location request)(NI−LR)プロシージャ、また、モバイルオリジネートの位置リクエスト(mobile originated location request)(MO−LR)プロシージャのために使用されることができる。
【0007】
MO−LRの定期的位置報告の一実施形態においては、RANと通信する無線デバイスは、ネットワークエンティティに、(1)クライアントエンティティへのUE位置の定期的報告についてのリクエスト、および(2)定期的位置情報を送る。無線デバイスはまた、ユーザ機器(UE)と呼ばれ、ネットワークエンティティは、モバイルサービス交換局(MSC)、あるいは、サービングGPRSサポートノード(SGSN)であり得る、そして、クライアントエンティティはまた、LCSクライアントと呼ばれる。定期的位置情報は、報告エベント(reporting events)のスケジュール、及び/又は、位置報告をトリガする(trigger)1セットの予め決められたエベント(a set of predetermined events)を示すことができる。リクエストが承認された後、MSC/SGSNは、UEについての定期的位置報告を開始するために、RANにシグナリング(signaling)を送る。RANは、ポジショニングセンタ(これはスタンドアロンのサービングモバイル位置センタ(standalone serving mobile location center)(SAS)と呼ばれてもよい)に、支援データ(assistance data)をUEに送ることをリクエストすることができる。RANは、定期的位置報告を調整し(coordinate)コントロール(control)してもよいし、あるいは、SASにコントロールを渡して(pass)もよい。どんな場合も、定期的位置情報によって決定される位置報告については、UEは位置情報をRANに送る。この位置情報は、(1)基地局及び/又は衛星についてUEによって測定により得られた測定値(measurements made by)、あるいは、(2)UEについての位置推定値を含むことができる。衛星あるいはRANがUEから測定値を受け取る場合、そのときは、RANは測定値をSASに送ることができ、それは、UEについての位置推定値を計算し(compute)、位置推定値をRANに戻すことができる。RANは、そのあと、UEについての位置推定値をMSC/SGSNに送り、それは、位置推定値を、LCSクライアントに向けて転送する。RANベースの定期的位置報告は、定期的にUE位置推定値をLCSクライアントに送るシグナリングを減らし、そしてまた、より速い応答時間を提供する。
【0008】
RANベースの定期的位置報告についての様々なメッセージフローが以下に説明される。本発明の様々な態様および実施形態もまた、以下により詳細に説明される。
【図面の簡単な説明】
【0009】
【図1A】図1Aは3GPPベースのネットワークを示す。
【図1B】図1Bは、複数のネットワークを含んでいる3GPPベースの展開を示す。
【図2A】図2Aは、MT−LRの定期的位置報告のためのメッセージフローを示す。
【図2B】図2Bは、NI−LRの定期的位置報告のためのメッセージフローを示す。
【図3】図3は、MO−LRの定期的位置報告のためのメッセージフローを示す。
【図4】図4は、RANベースの定期的位置報告のためのメッセージフローを示す。
【図5】図5は、RNCセントリックモードにおけるRANベースの定期的位置報告のためのメッセージフローを示す。
【図6】図6は、SASセントリックモードにおけるRANベースの定期的位置報告のためのメッセージフローを示す。
【図7】図7は、通知付のRANベースの定期的位置報告のためのメッセージフローを示す。
【図8】図8は、RANベースのMO−LR定期的セルフロケーションのためのメッセージフローを示す。
【図9】図9は、パケットモードにおけるGERANのためのRANベースの定期的位置報告のためのメッセージフローを示す。
【図10】図10は、サーキットモードにおけるGERANのためのRANベースの定期的位置報告のためのメッセージフローを示す。
【図11】図11は別のネットワーク展開を示す。
【図12】図12は、図1における様々なネットワークエンティティのブロック図を示す。
【0010】
[詳細な説明]
本発明の特徴および本質は、同様な参照文字が全体をとおして同様に識別する図面と併せて以下に述べられる詳細な説明から、より明らかになるであろう。
【0011】
ここで使用されている用語「例示的な(exemplary)」は、「例(example)、インスタンス(instance)、または例証(illustration)として機能している」を意味するようにここでは使用される。「例示的な」としてここで説明されるどの実施形態あるいは設計も、他の実施形態あるいは設計よりも好ましいあるいは有利であるとして必ずしも解釈されるべきではない。
【0012】
ここに説明される定期的位置報告技術は、符号分割多元接続(CDMA)ネットワーク、時分割多元接続(TDMA)ネットワーク、周波数分割多元接続(FDMA)ネットワーク、直交周波数分割多元接続(OFDMA)ネットワーク、前述の技術の組合せをサポートするネットワーク、無線ローカルエリアネットワーク(WLAN)サービスエリアと同様に広域ネットワークサービスエリアを備えたネットワーク、などのような、様々な無線ネットワークに使用されることができる。CDMAネットワークは、1つ以上のCDMA無線技術、例えば、広帯域CDMA(W−CDMA)、cdma2000などを、インプリメント(implement)できる。cdma2000は、IS−2000、IS−856、およびIS−95標準規格をカバーする。TDMAネットワークは、1つ以上のTDMA無線技術、例えば、汎欧州デジタル移動電話方式(Global System for Mobile Communications)(GSM(登録商標))、デジタル先進移動電話方式(Digital Advanced Mobile Phone System)(D−AMPS)などを、インプリメントできる。D−AMPSは、IS−136およびIS−54をカバーする。これらの様々な無線技術および標準規格は、当技術においては知られている。W−CDMAおよびGSM(登録商標)は、「第三世代協力プロジェクト」(3GPP)と呼ばれる団体のドキュメントにおいて説明されている。cdma2000は、「第三世代協力プロジェクト2」(3GPP2)と呼ばれる団体のドキュメントにおいて説明されている。3GPPと3GPP2のドキュメントは公的に利用可能である。明確にするために、3GPPによって広められた1つ以上の無線技術および1つ以上のネットワーキングプロトコル(networking protocols)を利用する3GPPベースのネットワーク(3GPP-based network)について、本技術が以下に説明される。例えば、3GPPベースのネットワークは、無線通信(over-the-air communication)の無線技術(radio technology)としてW−CDMAを、また、コアネットワーク機能性(core network functionality)のためのネットワーキングプロトコルとしてモバイルアプリケーションパート(Mobile Application Part)を利用するユニバーサルモバイルテレコミュニケーションシステム(Universal Mobile Telecommunication System)(UMTS)ネットワークであってよい。
【0013】
図1Aは、以下の説明においてUEs(3GPP専門用語)と呼ばれる無線デバイスについての通信と位置のサービスを提供する3GPPベースのネットワーク100を示す。簡単にするために、1つのUE120のみが、図1Aにおいて示される。UE120は、固定されていてもよいし、あるいはモバイル(mobile)であってもよく、また、移動局、端末、あるいは加入者ユニットとも呼ばれることができ、あるいは他のなんらかの専門用語で呼ばれるかもしれない。UE120はまた、携帯電話(cellular phone)、ラップトップ、携帯情報端末(personal digital assistant)(PDA)、遠隔測定デバイス(telemetry device)、追跡装置(tracking device)などであってもよい。UE120はまた、無線アクセスネットワーク(RAN)130における1つ以上の基地局と通信するかもしれない。UE120はまた、全地球測位システム(Global Positioning System)(GPS)、欧州ガリレオシステム(European Galileo system)、あるいはロシアのGlonassシステム、の一部かもしれない1つ以上の衛星190から、信号を受け取るかもしれない。UE120はまた、RAN130における基地局からの信号、及び/又は、衛星190からの信号を測定する(measure)かもしれないし、また、これらの基地局および衛星についての疑似距離測定値(pseudo-range measurements)を得るかもしれない。これらの疑似距離測定値は、UEについての位置推定値(location estimate)を導き出すために使用されることができる。
【0014】
RAN130は、RANのサービスエリアの全体にわたって位置するUEsに無線通信を提供する。RAN130は、モバイルサービス交換局(MSC)及び/又はサービングGPRSサポートノード(SGSN)(MSC/SGSN)140と通信し、そしてまた、サービングモバイル位置センタ(SMLC)及び/又はスタンドアロンのSMLC(SAS)(SMLC/SAS)132と通信する。MSC140は、そのサービスエリア内のUEsのための回路交換コール(circuit-switched calls)のためのスイッチング関数(switching functions)(例えば、回路交換の音声およびデータのコールのセットアップ(setup)、ルーティング(routing)、起こり得るリリース(release))を実行する。SGSN140は、パケット交換コール(packet-switched calls)およびパケット交換接続(packet-switched connections)のためのスイッチングおよびルーティング関数(switching and routing functions)を実行する。SMLC/SAS132は、ポジショニングサービス(positioning services)を提供し、UEベースの(UE-based)、UE支援の(UE-assisted)、およびネットワーク−ベースの(network-based)、ポジショニングモードをサポートできる。ポジショニングは、ターゲットUE(target UE)の地理的位置(geographical location)を検出する、あるいは決定する機能(functionality)を指す。SASは、あるポジショニング方法、例えば、アップリンク到着時間差(Uplink Time Difference of Arrival)(U−TDOA)ポジショニング方法、を支援するいくつかの関連する位置測定ユニット(Location Measurement Units)(LMUs)(図1Aの中では示されていない)を有していてもよい。SMLCは、RANの物理的及び/又は論理的な部分であってもよいし、あるいは、それは、スタンドアロンの(standalone)SMLC(SAS)の場合には、物理的かつ論理的に分離されている可能性がある。いずれの場合も、以下の説明では
、SMLC/SAS132は、それが、RANの物理的及び/又は論理的な部分であろうとなかろうと、あるいはRANから分離されていようとなかろうと、異なったエンティティ(distinct entity)として扱われる。
【0015】
ゲートウェイモバイル位置センタ(gateway mobile location center)(GMLC)150は、位置サービスをサポートする様々な機能を実行し、外部LCSクライアントとインタフェースをとり、そして、サービス、例えば、加入者プライバシ(subscriber privacy)、許可(authorization)、認証(authentication)、ビリング(billing)など、を提供する。ホームロケーションレジスタ(home location register)(HLR)/ホーム加入者サーバ(HSS)160は、ネットワーク100の加入者であるUEs(例、UE120)のための登録情報(registration information)を保存する。LCSクライアント170は、LCSターゲットについての位置情報をリクエストし、かつ/または、受け取る機能あるいはエンティティである。LCSターゲットは、その位置が求められているUEである。一般に、LCSクライアントは、ネットワークエンティティあるいはUEの中に存在するかもしれないし、あるいは、ネットワークとUEの両方の外側にあるかもしれない。LCSクライアント170は、GLMC150と通信する。
【0016】
簡単にするために、図1Aは、位置サービスに関連するネットワークエンティティを示す。これらのネットワークエンティティは、「位置サービス(LCS)の機能的ステージ2説明(リリース6)(Functional stage 2 description of Location Services (LCS) (Release 6))」と題された3GPP TS 23.271の中で、「UTRANにおけるユーザ機器(UE)ポジショニングのステージ2機能仕様(リリース6)(Stage 2 functional specification of User Equipment (UE) positioning in UTRAN (Release 6))」と題された3GPP TS 25.305の中で、また、「GERANにおける位置サービス(LCS)の機能的ステージ2説明(リリース6)(Functional stage 2 description of Location Services (LCS) in GERAN (Release 6))」と題された3GPP TS 43.059の中で、説明されており、それらの全部が、公に利用可能である。
【0017】
図1Aは、UE120が、単一のネットワーク(例、ホームネットワーク)と通信するケースを示す。このネットワークにおけるネットワークエンティティのすべてが、コアネットワーク及び/又は他のデータネットワーク(図1Aにおいては示されていない)経由で、通信する。UE120は、ローミングし、異なる訪問先ネットワーク(visited networks)と通信することができる。
【0018】
図1Bは、訪問先/サービングネットワーク(visited/ serving network)102と、ホームネットワーク(home network)104と、リクエスティングネットワーク(requesting network)106とを含む、3GPPベースの展開(3GPP-based deployment)101を示す。訪問先ネットワーク102は、現在UE120にサービングを行っている(serving)ネットワークである。ホームネットワーク104は、UE120が加入をしているネットワークである。リクエスティングネットワーク106は、それを介してLCSクライアント170がUE120の位置(location)についてリクエストを出す(originate)ことができ、かつ/または、UE120の位置を受け取ることができる、ネットワークである。ホームネットワーク104は、訪問先ネットワーク102と同じであるかもしれないし、あるいは異なるかもしれない。リクエスティングネットワーク106もまた、訪問先ネットワーク102と同じであるかもしれないし、あるいは異なるかもしれない。各ネットワークは、パブリックランドモバイルネットワーク(public land mobile network)(PLMN)と呼ばれてもよい。
【0019】
図1Bにおいて示される実施形態の場合、訪問先ネットワーク102は、第二世代(2G)GSM(登録商標) EDGE無線アクセスネットワーク(GERAN)130aおよび第3世代(3G)ユニバーサルテレストリアル無線アクセスネットワーク(Universal Terrestrial Radio Access Network)(UTRAN)130bを含んでいる。GERAN130aは、2G−SGSN140a及び/又は2G−MSC140bと通信する。GERAN130aはまた、3G−SGSN140c及び/又は3G−MSC14Odと通信することができる。UTRAN130bは、3G−SGSN140c及び/又は3G−MSC14Odと通信する。各MSCは、訪問先MSC(VMSC)として動作でき、また、3G−MSC140dは、MSCサーバであってもよい。訪問先GMLC(V−GMLC)150aは、訪問先ネットワーク102についての位置サービス(location services)をサポートし、MSC140bおよび140d、および、SGSNで140aおよび140cと通信する。SMLC/SAS132は、ポジショニングサービス(positioning services)を提供し、GERAN130a、UTRAN130b、2G−MSC140aなどと通信することができる。
【0020】
ホームネットワーク104は、ホームGMLC(H−GMLC)150bおよびHLR/HSS160を含んでいる。H−GMLC150bは、ホームネットワーク104についての位置サービスをサポートする。HLR/HSS160は、ホームネットワーク104の加入者であるUEについての登録情報を保存する。リクエスティングネットワーク106は、リクエスティングネットワーク106についての位置サービスをサポートするリクエスティングGLMC(R−GLMC)150cを含んでいる。図1Bの中では示されていないが、R−GLMC150c及び/又はH−GLMC150bは、訪問先ネットワーク102の中のSGSN140a、MSC140b、SGSN140c、及び/又はMSC14Odと、適切なインタフェース経由で直接に通信してもよい。
【0021】
図1Aおよび1Bにおけるネットワークエンティティはまた、他のネットワークおよび他の位置アーキテクチャにおいて、他の名前によって参照されるかもしれない。例えば、オープンモバイルアライアンス(Open Mobile Alliance)(OMA)によって広められたセキュアユーザプレーンロケーション(Secure User Plane Location)(SUPL)アーキテクチャにおいては、LCSクライアントは、時にはSUPLエージェントと呼ばれることもあり、GLMCはSUPL位置センタ(SLC)と呼ばれ、SUPLをサポートするUEは、SUPL使用可能端末(SUPL enabled terminal)(SET)と呼ばれ、SLMCは、SUPLポジショニングセンタ(SPC)と呼ばれる。これらのSUPL名称のエンティティによって実行される機能およびシグナリングは、対応する3GPP名称エンティティによって実行されるそれらと正確に同じではないが、おおまかに言って類似しており、同等のサービスおよび機能(comparable services and capabilities)を可能にしている。GLMCもまた、位置センタ(location center)、LCSサーバ(LCS server)、位置サーバ(location server)、モバイルポジショニングセンタ(mobile positioning center)(MPC)などと呼ばれるかもしれない。SMLCもまた、ポジショニングエンティティ(positioning entity)、ポジショニングセンタ(positioning center)、位置決定エンティティ(position determination entity)(PDE)などと呼ばれるかもしれない。一般に、各ネットワークは、任意のサービス範囲を提供できるネットワークエンティティの任意のコレクションを、含むことができる。明確にするために、以下の説明の多くは、図1Aにおける3GPPベースのネットワーク100の場合である。
【0022】
UE120の位置は、(1)モバイルオリジネートの位置リクエスト(mobile originated location request)(MO−LR)をもたらす、UEで実行中のアプリケーション(Apps)、(2)モバイルターミネートの位置リクエスト(mobile terminated location request)(MT−LR)をもたらす、LCSクライアント170で実行中のアプリケーション、および(3)ネットワーク誘導の位置リクエスト(network induced location request)(NI−LR)をもたらす、ターゲットUE(例えば、図1Bにおける2G−SGSN140a、2G−MSC140b、3G−SGSN140cあるいは3G−MSC14Od)にサービングを行っているPLMNエンティティのうちのいずれかの内部で実行中のアプリケーションによって、リクエストされることができる。UE120の位置は、ワンショットあるいは即時位置報告(one-shot or immediate location reporting)をもたらす1回限りのリクエストがされてもよいし、定期的位置報告(periodic location reporting)をもたらすシングルリクエスト(single request)で複数回リクエストされてもよい。定期的位置報告は、定期的なMT−LRメッセージフロー、定期的なNI−LRメッセージフロー、あるいは定期的なMO−LRメッセージフローで達成されることができる。定期的位置報告は、UE位置をクライアントエンティティにいつ報告するのかを示す定期的位置情報に基づいて、ターゲットUEについての位置推定値をLCSクライアントに定期的に(periodically)提供する。定期的位置情報は、報告エベントのスケジュール及び/又は1セットのトリガエベント(triggering events)であってもよい。スケジュールは、例えば、開始時間(start time)、報告間隔(reporting interval)、及び、停止時間(stop time)、持続時間(duration)あるいは報告の特定の数のうちの1つなどの、様々なフォーマットで与えられることができる。トリガエベントは、例えば、利用可能になるUE、あらかじめ定義された地理的エリアに入る、あるいは、から離れるUE、あらかじめ定義された地理的エリア内にあるUE、あらかじめ定義された閾値を越えるUE速度あるいは加速度、あらかじめ定義された閾値によって変化するUE位置、速度あるいは加速度、などに、対応し得る。
【0023】
UE120についての位置推定値は、UEベース、UE支援、あるいはネットワークベースの、ポジショニングモードを使用して得られることができる。UEベースのモードの場合、UEの位置は、SMLC、GERANあるいはUTRANからの支援データを多分使用して、UEによって決定される。UE支援のモードの場合、UEの位置は、UEからの支援(例、測定)によりSMLCによって決定される。ネットワークベースのモードの場合、UEの位置は、UEからの何ら特別な支援無しに、ネットワークによって得られるかあるいは既にネットワークに知られている情報に基づいて決定される。ネットワークベースのモードの場合、UEの位置は、1つ以上のLMUあるいは基地局で測定して得られるアップリンク測定値(uplink measurements)によって決定されることができる。
【0024】
UEベースのモードとUE支援のモードは、様々なポジショニング方法、例えば、GPS、支援GPS(assisted GPS)(A−GPS)、ハイブリッド、高度順方向リンク三辺測量(advanced forward link trilateration)(A−FLT)、拡張観測時間差(enhanced observed time difference)(E−OTD)、到着の観測時間差(observed time difference of arrival)(OTDOA)など、を利用できる。ネットワークベースのモードは、様々なポジショニング方法、例えば、到着のアップリンク時間(uplink time of arrival)(U−TOA)、到着のアップリンク時間差(uplink time difference of arrival)(U−TDOA)、セルID(cell-ID)、拡張セルID(enhanced cell-ID)など、を利用できる。1つ以上のポジショニングモードについて複数のポジショニング方法もまた、組み合わせて使用されてもよい。GPSとA−GPSの方法は、衛星測定結果(satellite measurements)にもっぱら基づきUEについての位置推定値を導き出し、高い正確さ(accuracy)を有する。ハイブリッド方法は、衛星と基地局の両方の測定値に基づき位置推定値を導き出し、高い正確さと高い信頼性とを有する。A−FLT、E−OTD、およびOTDOAの方法は、UEによって測定された基地局タイミングの測定値に基づき位置推定値を導き出し、より中間の正確さを有する。U−TOAおよびU−TDOAの方法は、ネットワークによって測定されたUEタイミングの測定値に基づき位置推定値を導き出し、より中間の正確さを有する。セルIDおよび拡張セルIDの方法は、セルラーネットワークに基づいて位置推定値を導き出し、より粗い正確さを(coarser accuracy)有する。これらの様々なポジショニング方法は当技術分野において知られている。
【0025】
LCSクライアント170へのUE位置の定期的報告をサポートする様々なメッセージフローが、図1Aにおける3GPPベースのネットワーク100について、以下に説明される。これらのメッセージフローは、コアネットワーク(例、MSC/SGSN140)が、RANベースの定期的位置報告を効率的に提供するために、RAN130の定期的なLCS機能を呼び出し(invoke)そして利用することを、可能にする。RANベースの定期的位置報告は、MSC/SGSN、UE、あるいはGMLCとは対照的に、RANによって調整されコントロールされる(coordinated and controlled)定期的位置報告を指す。
【0026】
図2Aは、MT−L定期的位置報告についてのメッセージフロー200の一実施形態を示す。メッセージフロー200の場合、LCSクライアント170は、(1)LCSクライアント170へのターゲットUE120の定期的位置報告についてのリクエスト(すなわち、定期的位置リクエスト)および(2)定期的位置情報(「定期的loc info」)を含むLCSサービスリクエストメッセージ(LCS Service Request message)を、GMLC150に送る(ステップ1)。GMLC150は、LCSクライアント170の識別情報(identity)を確認する(verify)ことができ、LCSクライアントを認証する(authenticate)ことができ、また、LCSクライアントがリクエストされた位置サービスについて許可される(authorized)のかどうかを決定することができる。LCSクライアント170が許可される場合、そのときGMLC150は、(1)LCSクライアント170についての加入データ(subscription data)、UE120の加入者についての加入データ、及び/又はLCSクライアント170によって供給されるデータに基づき、UE120の識別子(identifier)およびLCSのサービスの質(quality of service)(QoS)を決定し、(2)UE加入者についてのプライバシプロファイル(privacy profile)に基づいたプライバシチェックを行ない、そして(3)その後の位置報告をオリジナルの定期的位置リクエストに関連付けるために使用される参照識別子(reference identifier)(ID)を割り当てる。プライバシチェックの場合、GMLC150は、LCSクライアント170あるいはこの種のLCSクライアントがUE120についての定期的位置報告をリクエストすることを承認されているのかどうかを、また、UEがこのリクエストについて通知され、リクエストを許可または拒否する(accept or reject)ことを承認される必要があるかもしれないかどうかを、確認する。
【0027】
GMLC150が、UE120のための現在のサービングMSCあるいはSGSNを知らない場合、そのときGMLC150は、UEについてのルーティング情報をリクエストするために、LCSのためのルーティング情報を送れのメッセージ(Send Routing Info for LCS message)をHLR/HSS160に送る(ステップ2)。HLR/HSS160は、そのあと、MSC/SGSN140のアドレスを含んでいる、LCSのためのルーティング情報を送れの肯定応答メッセージ(Send Routing Info for LCS Acknowledgment message)を返す(ステップ3)。ステップ2および3は、もしGMLC150がMSC/SGSN140のアドレスを既に知っている場合は、スキップされてもよい。GMLC150は、そのあと、MSC/SGSN140に、定期的位置リクエスト、UE識別子、定期的位置情報、及び/又は他の関連情報を含んでいる、加入者位置を提供せよメッセージ(Provide Subscriber Location message)を送る(ステップ4)。
【0028】
MSC/SGSN140は、定期的位置リクエストが承認されることを認証できる。(同様にステップ4)。定期的位置リクエストが承認される場合、そのときMSC/SGSN140は、例えば、UE120がアイドルモード(idle mode)にあったのであれば、UE120のページングおよび認証(paging and authentication)を行なうためにRAN130を呼びだすことができる(ステップ5)。もし通知(notification)あるいはプライバシ確認(privacy verification)が必要とされる場合、そのときは、MSC/SGSN140は、定期的位置リクエストを無線ユーザに通知し、許可を与えるか拒否するためにユーザを調べる(query)ためにUE120に通知する(同様にステップ5)。UE120は、例えば、UEベースの、及び/又は、UE支援のモードがUEによってサポートされていようとなかろうと、その機能(capability)を、RAN130及び/又はMSC/SGSN140に提供することができる(同様にステップ5)。MSC/SGSN140は、そのあと、UE120に、定期的位置リクエストについての関連情報(例、定期的位置情報、LCS QoS、参照IDなど)を含むLCS定期的位置呼び出しメッセージ(LCS Periodic Location Invoke message)を送る(ステップ6)。LCS定期的位置呼び出しメッセージはまた、(1)定期的位置報告が承認される(例えば、MO−LRリクエストが出される(originated)ことができる)PLMNsのリスト、および(2)PLMNがRANベースの定期的位置報告をサポートするかどうかに関しての各PLMNについての表示(indication)、を含むことができる。もしPLMNsのリストが含まれていない場合、そのときは、後に続くMO−LRリクエストは、現在のサービングPLMNに制限されてもよい。
【0029】
UE120はそのあと、定期的位置リクエストが受理され且つその後のMO−LRリクエストが積極的にサポートされることができるかどうかを示すLCS定期的位置呼び出し肯定応答メッセージ(LCS Periodic Location Invoke Acknowledgment message)を、MSC/SGSN140に送る。プライバシ確認の結果は、それが既にステップ5において含まれているので、このメッセージにおいては必要とされないであろう。もし定期的位置リクエストが受理されないが、ステップ5におけるプライバシ確認が通過すれば、そのときは、UE120は、定期的位置報告を承認する意向であること(willingness)を、しかし、後のMO−LRリクエストによってそれを積極的にサポートすることができない、あるいは不本意であること(inability or unwillingness)を、示しているであろう。その場合、以下に説明されるように、MSC/SGSN140は、RAN130を経由して定期的位置報告を依然として呼び出す(invoke)ことができる。そうでなければ、エラーレスポンス(error response)が、MSC/SGSN140によって出され(originated)、そしてGMLC150に戻される。いずれの場合も、MSC/SGSN140は、GMLC150に、定期的位置リクエストが受理されるかどうかを示す、加入者位置を提供せよ肯定応答メッセージ(Provide Subscriber Location Acknowledgment message)を送る(ステップ8)。このメッセージは、UE120に送られたPLMNのリストのような他の関連情報を含んでいてもよい。GMLC150は、そのあと、LCSクライアント170に、関連情報(例えば、定期的位置リクエストが受理されるかどうか)を含んでいるLCSサービスレスポンスメッセージを送る(ステップ9)。以下に説明されるように、LCSクライアント170へのUE位置の定期的報告が、RAN130の定期的LCS機能(periodic LCS capabilities)を使用して、そのあと実行される(ステップ10)。
【0030】
図2Bは、NI−LRの定期的位置報告のためのメッセージフロー210の一実施形態を示す。もしLCSクライアント170がMSC/SGSN140内に存在するか、あるいは同じPLMN内に存在し、MSC/SGSN140に直接的にリンクされる場合は、メッセージフロー210が使用される。メッセージフロー210のステップ1、5、6、7、9および10は、図2Aにおけるメッセージフロー200の、ステップ1、5、6、7、9および10にそれぞれ対応する。メッセージフロー210の場合、LCSクライアント170は、定期的位置リクエストおよび定期的位置情報を含んでいるLCSサービスリクエストメッセージ(LCS Service Request message)を、MSC/SGSN140に直接送信する(ステップ1)。MSC/SGSN140は、定期的位置リクエストが承認されるのを認証することができ、そしてリクエストが承認される場合は、UE120のページングおよび認証を行なうためにRAN130を呼びだしてもよい(ステップ5)。典型的には、通知あるいはプライバシ確認はステップ5においては行なわれない。メッセージフロー210のステップ6および7は、メッセージフロー200について上記に説明されたとおりである。MSC/SGSN140は、そのあと、LCSクライアント170に、定期的位置リクエストが受理されるかどうかを示すLCSサービスレスポンスメッセージ(LCS Service Response message)を直接送る(ステップ9)。以下に説明されるように、LCSクライアント170へのUE位置の定期的報告は、そのあと、RAN130の定期的LCS機能を使用して行なわれる(ステップ10)。
【0031】
図3は、MO−LRの定期的位置報告のためのメッセージフロー300の一実施形態を示す。もしUE120がアイドルモードである場合、そのときは、UEは、無線接続セットアップ(radio connection setup)をリクエストし、RAN130に、コールインデペンデント補足サービス(call independent supplementary service)についてのリクエストを示すコネクション管理(CM)サービスリクエストメッセージ(Connection Management (CM) Service Request message)を送る(ステップ1)。もしUE120が専用モード(dedicated mode)にある場合、そのときは、UEは、既に確立されている無線接続に関するCMサービスリクエストを送る(同様にステップ1)。RAN130は、CMサービスリクエストメッセージをMSC/SGSN140へ転送する(ステップ2)。MSC/SGSN140は、UE120がアイドルモードであれば、認証および暗号化(ciphering)を開始し(instigates)、あるいは、UE120が専用モードにあれば、直接転送CMサービス受理メッセージ(Direct Transfer CM Service Accept message)を返す(ステップ3)。UE120は、例えば、UEベースの、及び/又は、UE支援のモードがUEにサポートされていようとなかろうと、RAN130及び/又はMSC/SGSN140に、その機能を提供することができる(同様にステップ3)。明確にするために、図3における接続セットアップステップ1から3までは、回路交換(CS)ドメイン(circuit switched (CS) domain)を前提としており、また、シグナリングはMSCに送られる(SGSNではない)。パケット交換(PS)ドメイン(packet switched (PS) domain)のための接続セットアップステップは異なり、また、シグナリングは、RAN130経由でSGSNに送られる。CSおよびPSのドメインのための接続セットアップは、公的に利用可能である3GPP TS 23.271の中で説明されている。
【0032】
UE120は、そのあと、MSC/SGSN140に、(1)LCSクライアント170へのUE120の定期的位置報告のリクエスト(すなわち定期的位置リクエスト)および(2)定期的位置報告についての関連情報を含んでいるLCS MO−LR位置サービス呼び出しメッセージ(LCS MO-LR Location Services Invoke message)を送る(ステップ4)。関連情報は、次の任意の組合せを含むことができる:
1.位置報告のためのスケジュール(「定期的loc info」)、
2.LCSクライアント170への位置報告をトリガするために使用される特定のエベント(同様に「定期的loc info」)、
3.LCSクライアント170の識別情報(「lcs−クライアント−addr」)、
4.LCSクライアント170がアクセスされることができるGMLC150の識別情報、
5.LCS QoS、例えば、正確さと応答時間、
6.定期的位置報告のための好ましい方法、例えば、MT−LRあるいはMO−LR、
7.任意の位置推定値の最大許容エイジ(maximum allowed age)、
8.UE120は、UEの実際の識別情報あるいは実アドレスを使用し、あるいは匿名を使用して、LCSクライアント170に識別されるべきであるかどうか、
9.他の関連情報。
【0033】
MSC/SGSN140は、UEについての加入プロファイルに基づいて、リクエストされた位置サービスに対しUE120が許可されることを確認する(同様にステップ4)。定期的位置リクエストが許可される場合、そのときは、MSC/SGSN140は、GMLC150に、定期的位置リクエストおよび関連情報(例、定期的位置情報)を含んでいるMAP加入者位置報告メッセージ(MAP Subscriber Location Report message)を送る(ステップ5)。GMLC150は、そのあと、LCSクライアント170へ、定期的位置リクエストおよび関連情報を転送する(ステップ6)。LCSクライアント170は、GMLC150に、UEリクエストに対するレスポンスを送る(ステップ7)。一実施形態においては、MSC/SGSN140、GMLC150、およびLCSクライアント170の中のいずれのエンティティも、定期的位置リクエストを拒否あるいは受理することができる。もしリクエストが受理される(例えば、どのエンティティによっても拒否されない)場合、そのときGMLC150は、リクエストに対し参照IDを割り当てる。GMLC150は、そのあと、MSC/SGSN140に、MAP加入者位置報告肯定応答メッセージ(MAP Subscriber Location Report Acknowledgment message)を送る(ステップ8)。MSC/SGSN140は、次の情報の任意の組合せを受け取ることができる:
1.GMLC150によって割り当てられた参照ID、
2.位置報告のための修正されたスケジュール(「定期的loc info」)、
3.LCSクライアント170への位置報告をトリガするために使用される修正された特定エベント(同様に「定期的loc info」)、
4.GMLC150のアドレス、
5.他の関連情報。
【0034】
MSC/SGSN140は、UE120に、GMLC150から受け取られた情報を含んでいるLCS MO−LRリターン結果メッセージ(LCS MO-LR Return Result message)を送る(ステップ9)。LCS MO−LRリターン結果メッセージは更に、(1)定期的位置報告が承認されるPLMNsのリストと、(2)PLMNがRANベースの定期的位置報告をサポートするかどうかに関しての各PLMNについての表示と、を含んでいてもよい。これは、もしUE120がMO−LRリクエストをとおしての後の定期的位置報告において積極的な役割をする場合に、該当する。もしPLMNのリストが提供されない場合は、そのときは、どんな後のMO−LRリクエストも、現在のサービングPLMNに制限されてよい。以下に説明されるように、LCSクライアント170へのUE位置の定期的報告は、RAN130の定期的LCS機能を使用して、そのあと実行されることができる(ステップ10)。
【0035】
一般に、どんなエンティティ(例、UE120)も、LCSクライアント170へのUE位置のRANベースの定期的位置報告を呼び出すことができる。RAN130における定期的報告のUE120による呼び出しサポートするために、UE120は、各PLMNがRANにおいて定期的LCS機能を有しているかどうかを通知されることができる。この情報は、メッセージフロー200のステップ6あるいはメッセージフロー300のステップ9において、UE120に送られるPLMNsのリスト中に含まれることができる。この情報はまた、RANsによるブロードキャストであってもよい。
【0036】
定期的位置報告の場合、最初の位置報告(the first reporting)は、典型的には、定期的位置報告を開始するためにメッセージ交換を完了した直後である。位置報告は、次のエベントのうちの1つが発生するまで続くことができる:
1.報告持続時間が経過した、あるいは報告の総数が得られた、
2.定期的位置報告が、LCSクライアント170あるいはGMLC150によってキャンセルされる、
3. UE120が定期的位置報告を終了する。
【0037】
図4は、図2Aにおけるメッセージフロー200のステップ10、図2Bにおけるメッセージフロー210のステップ10、および図3におけるメッセージフロー300のステップ10のために使用されることができる、RANベースの定期的位置報告のためのメッセージフロー400の一実施形態を示す。メッセージフロー400のステップ1から3までは、メッセージフロー300のステップ1から3までと同じである。UE120は、そのあと、MSC/SGSN140に、定期的位置報告を呼び出すLCS MO−LR位置サービス呼び出しメッセージ(LCS MO-LR Location Services Invoke message)を送る(ステップ4)。メッセージフロー300のステップ4において送られるLCS MO−LR位置サービス呼び出しメッセージは、定期的位置報告について「リクエストする」が、これに対して、メッセージフロー400のステップ4において送られるLCS MO−LR位置サービス呼び出しメッセージは、定期的位置リクエストが許可された後に、定期的位置報告を「呼び出す」。メッセージフロー400において送られるLCS MO−LR位置サービス呼び出しメッセージは、関連情報、例えば、定期的位置情報、LCS QoS、LCSクライアント170の識別情報、定期的位置リクエストが許可されたという表示などを、含む。許可表示(authorization indication)は、例えば、GMLC150によって割り当てられた参照IDであってもよい。LCS MO−LR位置サービス呼び出しメッセージにおける許可表示の存在(図4において)あるいは不在(図3において)は、MSC/SGSN140に、メッセージフロー400あるいはメッセージフロー300をそれぞれ実行すべきかどうかを通知する。LCS MO−LR位置サービス呼び出しにおける定期的位置情報あるいは他の同等の情報(equivalent information)の存在は、MSC/SGSN140に、ワンショット位置報告(one shot location report)よりは寧ろLCSクライアント170へのRANベースの定期的位置報告がリクエストされていることを知らせる。ワンショット位置報告の場合には、UE120が、LCSクライアント170に送られるべき各スケジュールされた、あるいはトリガされた位置報告について、ステップ4におけるLCS MO−LR位置サービス呼び出しを再度発行すること(re-issuing)(例えば、ステップ1から4を繰り返すこと)に責任を負うであろう。RANベースの定期的位置報告のリクエストで、UEは、以下に説明されるように、RANによる位置報告のスケジューリング及び/又はトリガリングが完了するまで、別のLCS MO−LR位置サービス呼び出しを再度発行する必要がない。
【0038】
MSC/SGSN140は、リクエストされた位置サービスについてUE120が許可されることを確認し、そのあと、RAN130に、RANベースの定期的位置報告を開始する位置リクエストメッセージ(Location Request message)を送る(ステップ5)。このメッセージはまた、定期的位置情報、LCS QoS、などを含むことができる。RAN130は、位置リクエスト、必要とされる正確さ、およびUE機能に基づいて適切なポジショニング方法(positioning method)を選択する。
【0039】
RAN130は、そのあと、UE120についての最初の位置推定値を得てそして返すために適切なメッセージフローを開始する(ステップ6a)。このメッセージフローは、様々なファクタ(factors)、例えば、UE機能(例、UEベースの、あるいはUE支援の)、選択されたポジショニング方法(例、A−GPS、A−FLT、E−OTD、OTDOAなど)、UE120、RAN130、あるいはSAS132が位置推定値を計算するであろうかどうか、など、に依存し得る。ステップ6aについてのメッセージフローのいくつかの実施形態が以下に説明される。RAN130は、ステップ6aにおけるメッセージフローからUE120についての位置推定値を得て、MSC/SGSN140に、この位置推定値および他の関連情報(例、参照ID)を含んでいる位置報告メッセージを送る(ステップ7a)。MSC/SGSN140は、そのあと、位置推定値および関連情報を含んでいるMAP加入者位置報告メッセージ(MAP Subscriber Location Report message)を、GMLC150に送り(ステップ8a)、GMLC150はLCSクライアント170に位置推定値および関連情報を送る(ステップ9a)。LCSクライアント170は、位置情報肯定応答(location information acknowledgment)をGMLC150に送ることによって応答し(ステップ10a)、GMLC150は、MSC/SGSN140に、位置推定値がLCSクライアント170に成功裡に送られたかどうかを示すMAP加入者位置報告肯定応答メッセージを送る(ステップlla)。
【0040】
各その後の位置報告エベントi、但しi=b...n、について、定期的位置情報によって決定されるように、メッセージフローが、UE120についての位置推定値を得るために実行され(ステップ6i)、そして、位置推定値が、MSC/SGSN140に送られる(ステップ7i)。MSC/SGSN140は、そのあと、LCSクライアント170に位置推定値を転送する(ステップ8iから11iまで)。すべての位置報告エベントが完了した後、MSC/SGSN140は、UE120に、位置推定値がLCSクライアント170に送られたことを確認し、かつ定期的位置報告の終了を示すために、LCS MO−LRリターン結果メッセージ(LCS MO-LR Return Result message)を送る(ステップ12)。
【0041】
もしUEが以前にアイドルであったならば、MSC/SGSN140は、コネクション管理(CM)、移動管理(MM)あるいはGPRS移動管理(GMM)、および無線リソース管理(RR/RRC)の接続のUE120へのリリース(release)を開始(instigate)してもよい(ステップ13)。もしUE120が、例えば、他の進行中のサービスをサポートするために、RAN130と通信する専用モードに残る必要がある場合は、ステップ13は省略されてもよい。
【0042】
UMTS(例、W − CDMA)の場合におけるRANベースの定期的位置報告は、RNCセントリックモード(RNC-centric mode)およびSASセントリックモード(SAS -centric mode)で達成されることができる。RNCセントリックモードの場合、サービングRAN内のサービング無線ネットワークコントローラ(SRNC)は、UEについての定期的位置報告を調整しコントロールする。SASセントリックモードの場合、SRNCは、コントロールをSASへ渡し、それが、定期的位置報告を調整しコントロールする。RNCセントリックとSASセントリックの両方のモードの場合、SRNCは、定期的位置報告のためのUE、SAS、およびMSC/SGSNとの通信を容易にするために、状態情報(state information)を保存する。UEは、RNCセントリックあるいはSASセントリックのモードが定期的位置報告のために使用されているかどうかに気づいている必要はない。RNCセントリックおよびSASセントリックのモードは、UE支援の、UEベースの、およびネットワークベースのモードに使用されることができる。
【0043】
図5は、RNCセントリックモードにおけるRANベースの定期的位置報告のためのメッセージフロー500の一実施形態を示す。メッセージフロー500は、図4におけるメッセージフロー400の一実施形態であり、図2A、2Bおよび3におけるメッセージフロー200、210および300のステップ10のためにそれぞれ使用されることができる。
【0044】
メッセージフロー(それは図4におけるメッセージフロー400のステップ1から4までを含んでもよい)が、LCSクライアント170への定期的位置報告を開始するために最初に実行される(ステップ1)。MSC/SGSN140は、そのあと、RAN130内のSRNC(あるいは簡略に、RAN/SRNC130)に、定期的位置報告を開始する無線アクセスネットワークアプリケーションパート(RANAP)位置報告コントロールメッセージ(Radio Access Network Application Part (RANAP) Location Reporting Control message)を送る(ステップ2)。このメッセージはまた、定期的位置情報、LCS QoSなどを含んでいてもよい。一実施形態においては、RANAP位置報告コントロールメッセージは、次のフィールド(fields)を有する定期的報告基準情報エレメント(IE)(Periodical Reporting Criteria information element (IE))を含んでいる:
1.報告の量(Amount of Reports) − 1、2、4、8、16、32、64、無限、
2.報告間隔(Reporting Interval) − 250、500、1000、2000、3000、4000、6000、8000、12000、16000、20000、24000、28000、32000、64000ミリセカンド(ms)。
この実施形態の場合、各フィールドは、上記に与えられた1セットの可能な値(a set of possible value)に関連している。一般に、定期的報告基準IEは、任意のフィールドを含むことができ、また、各フィールドは、任意のセットの可能な値含むことができる。
【0045】
定期的報告基準IEのためのフィールドは、メッセージフロー500のステップ5においてRAN/SRNC130によってUE120に送られるべきRRC測定コントロールメッセージ(RRC Measurement Control message)中のRRC定期的報告基準IEのためのフィールドと同じであるように定義されることができる。更に、同じセットの値が、定期的報告基準IEとRRC定期的報告基準IEとにおける対応するフィールドのために使用されてもよい。これは、そのとき、RAN/SRNC130が、MSC/SGSN140から定期的報告基準IEにおける値を簡単に取り出す(simply extract)ことを、また、これらの値を、UE120に送られるRRC定期的報告基準IE上に直接マッピングする(map)ことを、可能にするであろう。MSC/SGSN140は、定期的位置情報(例えば、開始時間、停止時間および報告間隔)を、定期的報告基準IEにおける報告の量と報告間隔のフィールド(the Amount of Reports and the Reporting Interval fields)のための最適値(the best fitting values)に変換するであろう。MSC/SGSN140は、報告の量のフィールドのデフォルト値(default value)として「無限(infinite)」を使用してもよく、また、これ以上の位置報告が必要とされない時には、RAN/SRNC130に、「報告停止(stop reporting)」コマンド(command)を送ることができる。RAN/SRNC130は、そのあと、停止コマンドをUE120に送るだろう。一般に、もし様々なメッセージ中の関連するフィールドが同じでない場合は、そのとき、MSC/SGSN140は、UE120から受け取られた(あるいは、例えばMSC/SGSN140またはLCSクライアント170のようなPLMNにおける任意の他のエンティティから受け取られた)定期的位置情報を、ステップ2におけるRANAP位置報告コントロールメッセージのための最適値へと変換し(必要であれば)、また、RAN/SRNC130は、これらの値を、ステップ5におけるRRC測定コントロールメッセージのための最適値へと変換する(必要であれば)。
【0046】
別の実施形態においては、RANAP位置報告コントロールメッセージにおける定期的報告基準IEは、報告間隔のための任意の値(例えば、任意の整数倍数の秒)を、あるいは、報告の数のための任意の値を含むことができる。RAN/SRNC130あるいはSAS132は、この情報を、RRC定期的報告を呼び出すべきかどうかを決定するために、あるいは、単一のリクエストのために使用されるようなRRC測定コントロール/測定報告メッセージシーケンスを定期的に(periodically)繰り返すべきであるかどうかを決定するために、使用することができる。例えば、受け取られたRANAP位置報告コントロールにおける定期的報告基準IEのための値がRRC定期的報告基準IEにおける対応する値と互換性がある(compatible)ときは、RRC定期的報告は呼び出されることができる。
【0047】
RAN/SRNC130は、位置リクエスト、要求される正確さ(required accuracy)、およびUE機能に基づき、適切なポジショニング方法を選択する(同様にステップ2)。もしSAS132が利用可能であり、かつ選択されたポジショニング方法がA−GPSであるのであれば、そのときRAN/SRNC130は、SAS132へ、GPS支援データをリクエストするためにポジショニング計算アプリケーションパート(PCAP)情報交換開始リクエストメッセージ(Positioning Calculation Application Part (PCAP) Information Exchange Initiation Request message)を送ることができる(ステップ3)。SAS132は、そのあと、RAN/SRNC130に、リクエストされたGPS支援データを含んでいるPCAP情報交換開始レスポンスメッセージ(PCAP Information Exchange Initiation Response message)を返す(ステップ4)。ステップ3および4は、他のポジショニング方法の場合、あるいはもしGPS支援データが必要でない場合、あるいはもしRAN/SRNCがGPS支援データを(例えば、SAS132への以前のリクエストから)既に所有する場合は、省略されてもよい。RAN/SRNC130は、そのあと、UE120に、定期的位置情報(例えば、RRC定期的報告基準IE)およびGPS支援データを含んでいるRRC測定コントロールメッセージを送る(ステップ5)。ステップ3、4および5は、最初の位置報告エベント用のポジショニング1のためのメッセージの一部である。
【0048】
各位置報告エベントi、但しi=a...n、について、定期的位置情報によって決定されるように、UE120は、RAN/SRNC130に、位置情報を含んでいるRRC測定報告メッセージ(RRC Measurement Report message)を送る(ステップ6i)。この位置情報は、UEによって観測可能な基地局及び/又は衛星についてのUE120によって測定される測定値(UE支援のモードの場合)、UE120についての位置推定値(UEベースのモードの場合)、あるいは、測定値あるいは位置推定値が利用可能でないならばエラー表示、を備えることができる。測定値は、例えば、A−GPSについての疑似距離、OTDOAについてのシステムフレームナンバ−システムフレームナンバ(system frame number-system frame number)(SFN−SFN)観測時間差(observed time differences)、あるいは何らかの他のタイプの測定値であってよい。もし報告間隔が短く(例えば2秒)そして選択されたポジショニング方法がA−GPSである場合、そのときは、UE120でのGPS受信機が衛星を捉え(acquired)かつトラッキングモード(tracking mode)の中にあるまで、最初のわずかのRRC測定報告メッセージは、エラーメッセージを含んでいるかもしれない。そのあと、RRC測定報告メッセージは、該報告間隔で良い測定値及び/又は位置推定値を提供するはずである。
【0049】
もしRAN/SRNC130がUE120から測定値を受け取り(UE支援のモードの場合)かつSAS132が利用可能である場合は、そのときは、RAN/SRNC130はSAS132に、例えば更なるネットワークベースのポジショニングについてのUE測定値とたぶん他の情報とを含むPCAPポジション計算リクエスト(PCAP Position Calculation Request message)を送る(ステップ7i)。ステップ7iで送られたPCAPポジション計算リクエストメッセージはまた、定期的位置情報、例えば、全体の定期的位置プロシージャについての未解決のリクエストの数および報告間隔を含んでいるかもしれない。定期的位置情報は、SAS132が個々のPCAPポジション計算リクエストの間での状態情報(state information)を将来のそのようなリクエストをよりよく満たすために維持することを、可能にする。SAS132は、測定値およびその他の情報に基づきUE120についての位置推定値を計算し、RAN/SRNC130に、位置推定値を含んでいるPCAPポジション計算レスポンスメッセージを送る(ステップ8i)。もしRAN/SRNC130が、UE120から位置推定値を受け取るならば(UEベースのモードの場合)、そのときは、ステップ7iおよび8iはスキップされてもよい。もしRAN/SRNC130がネットワークベースのポジショニング(例、拡張セルBD、U−TDOA)のみを使用することを決定する場合、そのときは、ステップ3、4、5および6i(但しi=a...n)はスキップされ、そして、RAN/SRNC130は、ステップ7iにおいてSAS132に、選ばれたネットワークベースのポジション方法についての情報を含んでいるPCAPポジション計算リクエストメッセージ(PCAP Position Calculation Request message)を送る。SAS132は、そのあと、ステップ8iにおいて、SAS132によるネットワークベースの方法のアプリケーションから生じる位置推定値を含んでいるPCAPポジション計算レスポンスメッセージ(PCAP Position Calculation Response message)を返す。いずれの場合も、RAN/SRNC130は、位置推定値を含んでいるRANAP位置報告メッセージ(RANAP Location Report message)をMSC/SGSN140に送り(ステップ9i)、それはLCSクライアント170に位置推定値を転送する(ステップ10i)。ステップ10iは、図4におけるメッセージフロー400の8iから11iまでを含んでいてもよい。
【0050】
図5において示されるように、各位置報告エベントは、ポジショニング、RAN/SRNC130からMSC/SGSN140への位置推定値の転送(ステップ9i)、およびMSC/SGSN140からLCSクライアント170への位置推定値の転送(ステップ10i)についてのメッセージを含んでいる。最初の位置報告エベントのためのポジショニング1についてのメッセージは、3から8aまでを含んでおり、また、各その後の位置報告エベントのためのポジショニングiについてのメッセージは、ステップ6iから8iまでを含んでいる。最初の位置報告エベントのためのポジショニング1についてのメッセージは、SAS132からのGPS支援をリクエストし次いで得るために(ステップ3および4)、そして位置情報を定期的に送るためにUE120を呼び出すためこの支援データをUE120に転送するために(ステップ5)、更なるステップ3、4および5を含んでもよい。UE120はまた、RAN/SRNC130に位置測定値を送る代わりに、あるいは送ることに加えて、ステップ6iにおいて新しい支援データをリクエストすることができる。これは、例えば、最初にリクエストされた(例、ステップ5において)報告の数が多く、かつリクエストされたポジショニング方法がA−GPSである場合のケースであり得る。もしUE120が新しい支援データをリクエストする場合は、そのとき、ステップ3、4および5は繰り返され、そして、新しいあるいは更新された支援データが、他の関連情報と共に、測定コントロールメッセージの中で、あるいは支援データ配信メッセージ(Assistance Data Delivery message)の中で、UE120に送られる。ステップ6iにおける新しい支援データのリクエスト、およびステップ3、4および5の反復をとおしてのその提供(provision)が、メッセージフロー500において一度よりも多く生じるかもしれない。位置報告エベントのすべてが完了した後、メッセージフロー(それは図4におけるメッセージフロー400のステップ12および13を含んでいるかもしれない)は、LCSクライアント170への定期的位置報告を終了するために実行される(ステップ11)。
【0051】
RAN/SRNC130は、例えば、RRC測定コントロールメッセージからのRRC定期的報告基準IEを省略するために、あるいは、報告の数について1つの値(a value of one)と共にこのIEを含めるために、定期的UE報告をリクエストしないことをステップ5において決定してもよい。上記に言及されるように、これは、RANAP位置報告コントロールメッセージにおいて受け取られる定期的位置情報が、RRC測定コントロールメッセージ中の対応する利用可能な値の範囲に適合しない(not compatible)場合のケースであり得る。RAN/SRNC130は、そのあと、望まれる定期的報告間隔で、ステップ5を送ることを繰り返してよい。各位置報告エベントについてポジショニングiのためのメッセージは、そのとき、ステップ6iから8iまでに加えて、ステップ5を含むであろう。
【0052】
図6は、SASセントリックモードにおいてのRANベースの定期的位置報告のためのメッセージフロー600の一実施形態を示す。メッセージフロー600は、図4におけるメッセージフロー400の別の実施形態であり、そしてまた、図2A、2Bおよび3の中のメッセージフロー200、210および300のステップ10のために、それぞれ使用されてもよい。
【0053】
メッセージフロー600のステップ1および2は、図5におけるメッセージフロー500のステップ1および2に似ている(例えば、同じ)。RAN/SRNC130は、MSC/SGSN140から、定期的位置情報、LCS QoSなどを含んでいるRANAP位置報告コントロールメッセージ(RANAP Location Reporting Control message)を受け取る(ステップ2)。RAN/SRNC130は、そのあと、SAS132へ、MSC/SGSN140から受け取られた情報および多分他の情報、例えば、セルIDおよびUEポジショニング機能(例、ターゲットUE120がサポートするポジショニング方法、あるいは複数のポジショニング方法に関する情報)などを含んでいるPCAPポジション開始リクエストメッセージ(PCAP Position Initiation Request message)を送る(ステップ3)。このメッセージはまた、定期的位置報告のコントロール(control)をSAS132に転送する。SAS132は、要求される正確さおよびUE機能に基づいて適切なポジショニング方法を選択し、UE120に送るために適切な支援データ(もしあれば)を決定する。SAS132は、そのあと、RAN/SRNC130に、定期的位置情報(例、定期的報告基準IE)および支援データを含んでいるPCAPポジションアクチベーションリクエストメッセージ(PCAP Position Activation Request message)を送る(ステップ4)。SAS132は、必要とされる場合は、ステップ4で、ステップ3におけるRAN/SRNC130から受け取られた定期的位置情報を、PCAPポジションアクチベーションリクエストメッセージに対しての最適値へ、変換されることができる。RAN/SRNC130は、そのあと、UE120に、定期的位置情報および支援データを含んでいるRRC測定コントロールメッセージを送る(ステップ5)。ステップ3、4および5は、最初の位置報告エベントについてのポジショニング1のためのメッセージの一部である。
【0054】
各位置報告エベントi、但しi=a...n、について、定期的位置情報によって決定されるように、UE120は、RAN/SRNC130に、位置情報を含んでいるRRC測定報告メッセージを送る(ステップ6i)。この位置情報は、基地局及び/又は衛星についてUE120によって測定される測定値(UE支援のモードの場合)、UE120についての位置推定値(UEベースのモードの場合)、あるいは、測定値あるいは位置推定値が利用可能でない場合はエラー表示、を含むことができる。RAN/SRNC130は、SAS132に、UE120から受け取られる位置情報を含んでいるPCAPポジション定期的リクエストメッセージを送る(ステップ7i)。UE支援のモードの場合、SAS132は、UE120から測定値を受け取り、そして、測定値およびたぶん他の情報(例えば、ネットワークベースのポジショニングから得られた情報)に基づいてUEについての位置推定値を計算する。UEベースのモードの場合は、SAS132は、UE120から位置推定値を受け取り、そして、(例えば、ネットワークベースのポジショニングから得られた情報に基づいて)位置推定値を確認、かつ/またはそれを修正できる。UEベースとUE支援の両方のモードの場合、SAS132は、RAN/SRNC130に、UE120についての位置推定値を含んでいるPCAPポジション定期的レスポンスメッセージを送る(ステップ8i)。RAN/SRNC130は、そのあと、位置推定値を含んでいるRANAP位置報告メッセージを、MSC/SGSN140に送り(ステップ9i)、それは位置推定値をLCSクライアント170に転送する(ステップ10i)。ステップ10iは、図4におけるメッセージフロー400の8iから11iまでを含むことができる。
【0055】
UE120からの最終のRRC測定報告メッセージの受取り(ステップ6n)に続いて、RAN/SRNC130は、ステップ7nにおいて、SAS132に、前のステップ7i(但しi=a...n−1)におけるPCAPポジション定期的リクエストメッセージと同じタイプの情報(例えば、測定値あるいは位置推定値)を搬送するPCAPポジションアクチベーションレスポンスメッセージを送ることができる。SAS132は、そのあと、ステップ8nにおいて、前のステップ8i(但しi=a...n−1)におけるPCAPポジション定期的レスポンスメッセージと同じタイプの情報(例えば、計算された位置推定値)を搬送するPCAPポジション開始レスポンスメッセージを返すことができる。この区別は、RNCからSASにまたはSASからRNCに送られるどんなPCAPリクエストメッセージもせいぜい1つの異なるPCAPレスポンスメッセージによって答えられるという(3GPP TS 25.453に定義された)3GPPについての現行の規則(existing conventions)の遵守(compliance)を支援することができる。この場合、ステップ8nにおいて送られるPCAPポジション開始レスポンスメッセージは、ステップ3において送られるPCAPポジション開始リクエストメッセージに対するレスポンスであり;ステップ7nにおいて送られるPCAPポジションアクチベーションレスポンスメッセージは、ステップ4において送られるPCAPポジションアクチベーションリクエストメッセージに対するレスポンスであり;また、ステップ8i(但しi=a...n−1)において送られるPCAPポジション定期的レスポンスメッセージは、ステップ7iにおいて送られるPCAPポジション定期的リクエストメッセージに対するレスポンスである。これらのペアリング(paring)は、特に、3GPP TS 25.453におけるクラス1基本プロシージャに準拠する。更に、最初の2つのペアリング(ステップ3と8n、および、ステップ4と7n)は、シングルショット位置リクエスト(各ペアリングが一度だけ生じる故)に適用可能であり、シングルショット位置リクエストと定期的位置リクエストとの間のより大きなコンパティビリティ(compatibility)と、両方のタイプの位置リクエストをサポートするRAN/SRNC130およびSAS132においてのたぶんより容易なインプリメンテーションとを可能にする。RNCセントリックのオペレーションとのより大きなコンパティビリティを可能にするために、ステップ7iと8iにおけるPCAPポジション定期的リクエストとレスポンスのメッセージは、RNCセントリックモードにおいて使用され、かつ図5において示されるPCAPポジション計算リクエスト/レスポンスのメッセージと取り替えられてもよい。その場合、PCAPポジション計算リクエスト/レスポンスのメッセージはまた、UEから受け取られた位置推定値のSASへの配信(delivery)を可能にするためにわずかに修正されるかもしれないが、新しいプロシージャは必要とされない。
【0056】
メッセージフロー600の代替の実施形態においては、ステップ6nにおけるUE120からの最終のRRC測定報告メッセージの受取りに続いて、RAN/SRNCは、ステップ7nにおいてPCAPポジション定期的リクエストメッセージをSAS132に送ることができ、そしてSAS132は、ちょうど前のステップ7iおよび8iにおけるのと同じように、ステップ8nにおいて、PCAPポジション定期的レスポンスメッセージを返すことができる。この場合、ステップ8nに続いて、なお図6においては示されていないが、RAN/SRNC130は、SAS132aに、いずれの測定値あるいは位置推定値も含んでいないPCAPポジションアクチベーションレスポンスメッセージを送ることができ、そしてSAS132は、ステップ3および4における初期のメッセージに応答し、かつSAS132およびRAN/SRNC130においてそれらに関連したトランザクション(transactions)を終了するために、位置推定値を含んでいないPCAPポジション開始レスポンスメッセージを返すことができる。
【0057】
メッセージフロー600の別の代替実施形態においては、ステップ7iおよび8iにおけるPCAPポジション定期的リクエストとレスポンスのメッセージを備えるPCAPクラス1基本プロシージャは、3GPP TS 25.453に定義されているPCAPクラス2基本プロシージャによって取り替えられることができる。クラス2基本プロシージャは、レスポンスメッセージのないプロシージャである。この実施形態においては、メッセージフロー600のステップ7でのPCAPポジションアクチベーションレスポンスメッセージは、ステップ4でのPCAPポジションアクチベーションリクエストメッセージの直後か、あるいは、最初のRRC測定報告メッセージが受け取られた後、なおそれはステップ6aの後である、に、送られることができる。前者の場合においては、PCAPポジションアクチベーションレスポンスメッセージは、リクエストされたアクションの確認を含むであろう。後者の場合においては、PCAPポジションアクチベーションレスポンスメッセージは、さらに最初の測定報告情報を含むであろう。PCAPポジションアクチベーションリクエストメッセージは、ある推奨されるポジショニングインストラクション(positioning instruction)を含むことができ、RAN/SRNC130はそれを、UE120に、ステップ5でのRRC測定コントロールメッセージの中で転送することができる。もしRAN/SRNC130が、あるポジショニングインストラクションについてのリクエストに応じることができない場合、そのときRAN/SRNC130は、ステップ5においてUE120に送られるRRC測定コントロールメッセージにおいて代わりに使用されるポジショニングインストラクションに関してPCAPポジションアクチベーションレスポンスメッセージの中でSAS132に通知することができる。そのようなポジショニングインストラクションの一例は、どのRRC状態においてリクエストされた測定値が有効であるかについての情報であってもよい。RAN/SRNC130でUE120から受け取られるその後の測定報告情報(measurement report information)は、そのあと、クラス2 PCAPポジション定期的報告メッセージ(class 2 PCAP Position Periodic Report messages)においてSAS132に伝達されるであろう、それは、メッセージフロー600において示されるPCAPポジション定期的リクエストメッセージの代わりにステップ7iにおいて送られるであろう。SAS132は、次に、クラス2 PCAPポジション定期的結果メッセージ(class 2 PCAP Position Periodic Result messages)において位置推定値をRAN/SRNC132に報告するであろう、それは、メッセージフロー600において示されるPCAPポジション定期的レスポンスメッセージの代わりにステップ8iにおいて送られるであろう。もしSAS132が進行中のRRC定期的プロシージャ(ongoing RRC periodic procedure)をキャンセルすることを決定すれば、そのとき、SAS132は、RAN/SRNC132に、定期的プロシージャの終了のリクエストを含んでいるPCAPポジション定期的結果メッセージを送ることができる。あるいは、SAS132は、進行中の定期的プロシージャをキャンセルするためにクラス2 PCAPポジション定期的終了メッセージ(class 2 PCAP Position Periodic Termination message)をRAN/SRNC130に送ってもよい。このメッセージフローは、RRCシグナリング、例えば、セルIDあるいはU−TDOAネットワークベースのポジショニング、を要求しない定期的位置プロシージャと、よりコンパティブルであり得る。
【0058】
上記に説明されたクラス2実施形態は、(例えば、ステップ3でのPCAPポジション開始リクエストメッセージにおいてSAS132で受け取られた定期的報告情報が、RRC定期的報告基準IEにおける利用可能な値の範囲とコンパティブルでない場合において)定期的RRC測定報告を呼び出すべきかどうか、あるいは、シングルリクエスト定期的に繰り返すべきかどうかを、SAS132が決定することを可能にする。SAS132は、そのあと、リクエストされた定期的報告間隔で、RAN/SRNC132に、PCAPポジションアクチベーションリクエストメッセージを送ることを繰り返すことができる。RAN/SRNC130は、RRC測定コントロール/報告メッセージのペアを繰り返すであろう、また、PCAPポジションアクチベーションレスポンスメッセージにおけるSAS132への測定情報を伝達する。SAS132は、そのあと、個々の位置推定値を、PCAPポジション定期的結果メッセージにおいてRAN/SRNC130に送ることができる。
【0059】
クラス2実施形態は、例えば、定期的なセルIDベースのポジショニングをサポートするために使用されることができる。この場合、SAS132は、RAN/SRNC130にPCAPポジションアクチベーションリクエストメッセージを定期的に送ることができる(図6において示されていない)。RAN/SRNC130は、そのあと、RAN/SRNC130によって得られるUE120についてのセル関連の測定値を含んでいるPCAPポジションアクチベーションレスポンスメッセージを返すことができる。SAS132は、そのあと、RAN/SRNC130に、これらの測定から得られた位置推定値を含んでいるPCAPポジション定期的結果メッセージを送ることができる。
【0060】
クラス2実施形態はまた、定期的なU−TDOAベースのポジショニングをサポートするために使用されることができる。この場合、RAN/SRNC130は、SAS132に、図6の中のステップ3におけるPCAPポジションアクチベーションリクエストメッセージを受け取った後に、UE120についてのチャネル関連情報を含んでいるPCAPポジションアクチベーションレスポンスメッセージを返すことができる。SAS132は、そのあと、UE120についての定期的U−TDOA測定値を得るためにLMUsを構成(configure)してもよいし、また、一連のPCAPポジション定期的結果メッセージにおいてRAN/SRNC130に定期的位置推定値結果(periodic location estimate results)を返してもよい。U−TDOAの場合のこの実施形態においては、RAN/SRNC130がSAS132にさらにメッセージを送ることは必要でないかもしれず、それによって、伝送と処理のリソースを節約し、遅れを減らす。
【0061】
クラス2実施形態は、定期的A−GPS及び/又は定期的OTDOAポジショニングと同時に(in parallel with)定期的U−TDOAベースのポジショニングをサポートするように拡張されることができる。この場合、定期的U−TDOAポジショニングは上記に説明されたように開始される(instigated)ことができる。定期的A−GPSあるいはOTDOAポジショニングは、そのあと、上記に同様に説明されたクラス2基本PCAPプロシージャの実施形態を使用して開始されることができる。SAS132は、LMUによって得られた定期的U−TDOA測定値、および、定期的PCAPポジション定期的報告メッセージにおいてSAS132に提供される定期的GPS測定値を使用して、UE120についての定期的位置推定値を得ることができる。SAS132は、そのあと、PCAPポジション定期的結果メッセージにおいて、RAN/SRNC130に各位置推定値を返すことができる。
【0062】
図6において示されるように、各位置報告エベント(location reporting event)は、ポジショニング、RAN/SRNC130からMSC/SGSN140への位置推定値の転送(ステップ9i)、およびMSC/SGSN140からLCSクライアント170への位置推定値の転送(ステップ10i)のためのメッセージを含んでいる。最初の位置報告エベントについてのポジショニング1のためのメッセージは、ステップ3から8aまでを含み、そして、各その後の位置報告エベントについてのポジショニングiのためのメッセージは、ステップ6iから8iまでを含んでいる。位置報告エベントのすべてが完了した後、メッセージフロー(それは図4におけるメッセージフロー400のステップ12および13を含んでいるかもしれない)は、LCSクライアント170への定期的位置報告を終了するために実行される(ステップ11)。
【0063】
UE120は、ある時点で、RAN/SRNC130に位置測定値を送る代わりに、あるいは送ることに加えて、ステップ6iにおいて新しいあるいは更新された支援データをリクエストすることができる。これは、例えば、もし(例えばステップ5において)最初にリクエストされた報告の数が大きく、かつ、リクエストされたポジショニング方法がA−GPSであった場合のケースであり得る。一実施形態においては、追加の支援データのリクエストは、RAN/SRNC130から、ステップ7iにおいて送られたPCAPポジション定期的リクエストメッセージまたはPCAPポジション定期的報告メッセージ(図6中では示されていない)のいずれかの中でSAS132に転送されることができ、また、リクエストされた支援データは、SAS132によって、ステップ8iにおいて送られたPCAPポジション定期的レスポンスメッセージまたはPCAPポジション定期的結果メッセージ(図6の中では示されていない)のいずれかにおいて、RAN/SRNC130に返されることができる。RAN/SRNC130は、そのあと、支援データを、RRC測定コントロールメッセージまたはRRC支援データ配信メッセージ(図6の中では示されていない)のいずれかにおいてUE120に転送することができる。この実施形態は、SAS132およびRAN/SRNC130がA−GPSポジショニングサポートをリスタート(re-start)する必要を避ける。別の実施形態においては、ステップ6iにおいて追加支援データのリクエストを受け取った後、RAN/SRNC130は、このリクエストをPCAPポジションアクチベーションレスポンスメッセージにおいてSAS132に転送することができる(図6においては示されていない)。SAS132は、そのあと、リクエストされた新しい支援データを準備し、これをおそらく新しいPCAPポジションアクチベーションリクエストメッセージにおける新しい定期的位置情報と共にRAN/SRNC130に送り(図6においては示されていない)、それは新しいトランザクションを開始する。RAN/SRNC130は、そのあと、新しいRRC測定コントロールメッセージをUE120に送り、前に開始された測定(ステップ5において)は、新しい支援データ(およびたぶん新しい報告インストラクション)で現在修正されていることを示す。この実施形態は、SAS132およびRAN/SRNC130において、また、たぶんUE120における定期的報告インストラクションを変更することにおいて、A−GPSポジショニングサポートをリスタートする効果を有する。
【0064】
別の実施形態においては、RAN/SRNC130は、SAS132からの支援データをリクエストするために3GPP TS 25.453に定義されるようなPCAP情報交換プロシージャを呼び出すことができるが、それは現在、RNCセントリックモードのためのみに使用されている。この実施形態においては、RAN/SRNC130は、図5におけるステップ3、4および5をコピーすることによって、SAS132からの支援データをリクエストすることができる(図6においては示されていない)。このプロシージャをSASセントリックモードにおいても同様に使用するとき、SAS132は、すべてのPCAPメッセージを同じポジショニングエベントに関連づけるセッションIDパラメータ(session ID parameter)を使用することにより、あるいはUE120のこの特定のポジショニングエベントに割り付けられた既存のシグナリング接続を使用することにより、このプロシージャがUE120についてのポジショニングエベントに属することに気付いている。
【0065】
いずれの場合も、支援データを受け取った後に、UE120は、RRC測定報告メッセージにおいて測定値をRAN/SRNC130に報告することを続け、それは次に、PCAPポジション定期的リクエストおよびPCAPポジション定期的レスポンスのメッセージペアを、あるいは代わりに、上記に説明されるように、PCAPポジション定期的報告およびPCAPポジション定期的結果のメッセージを続ける。ステップ6iにおけるUE120による新しい支援データのリクエスト、および上記に説明された実施形態のうちの1つをとおしてのその準備もまた、メッセージフロー600において一度よりも多く発生するかもしれない。
【0066】
ある種の例外状態(certain exception conditions)が図6におけるメッセージフロー600の間に時々発生することがあり、それは、ある追加のアクション(some additional action)を必要とする。もしUE120がサービングセルを変更するがしかしRAN/SRNC130のサービスエリア内に残る場合は、RAN/SRNC130は、SAS132に、新しいセルの識別情報を含んでいるPCAPポジションパラメータ修正メッセージ(PCAP Position Parameter Modification message)を送ることにより、新しいセルをSAS132に通知することができる。このメッセージは、SASセントリックモードにおけるシングルショットポジショニングでのRNC内セル変更の場合、(例えば、3GPP TS 25.305において)現在許可されているものと同じであるかもしれない。もし進行中のRRC測定プロシージャ(RRC measurement procedure)中にRRC状態変更(RRC state change)がある場合、RAN/SRNC130はまた、SAS132に、PCAPポジションパラメータ修正メッセージを送ることができる。別のRNCへのハードなハンドオーバ(hard handover)のような、ある種の他の例外状態(certain other exception conditions)のような場合には、UE120及び/又はRAN/SRNC130は、定期的位置プロシージャを途中停止する(abort)することができ、また、MSC/SGSN140は、(例えば、新しいRAN/SRNCへのシグナリングによって)プロシージャをリスタートすることができる。
【0067】
例えば、もしUE120あるいはMSC/SGSN140が、図4、5および6が現在示すあるいは前提とするMO−LRリクエストを介して定期的位置プロシージャをサポートすることができないか、あるいは、サポートすることに合意しない場合は、図4、5および6におけるRANベースの定期的位置報告メッセージが、以下に説明されるいくつかの小さな変更により、定期的位置報告についてのMT−LR(図2A)および定期的位置報告についてのNI−LR(図2B)のために使用されることができる。通知およびプライバシ確認が図2Aのステップ5において使用される場合は、もしUE加入者がMT−LRの場合において位置リクエストを拒否しなければ、RANベースの定期的位置報告が使用されることができる。図4、5および6におけるメッセージフローへの変更は、以下のとおりである。
【0068】
図4において、ステップ1から4までが取り除かれる。代わりに、もしUE120がアイドルモードに戻ってしまっている場合、(例えば、図2Aにおけるステップ5の場合に説明されているように)MSC/SGSN140はページングおよび認証を行なう。然しながら、(図2Aの中のステップ5で示される)通知およびプライバシ確認はないに違いない、というのは、それは図2Aにおけるメッセージフロー200あるいは(必要ならば)図2Bにおけるメッセージフロー210の部分として先に行われてしまっているであろうという理由による。もしUE120がアイドルモードにない場合、そのときは、ページングおよび認証は必要とされない。ステップ12もまた取り除かれるが、ステップ13は有効なままである。
【0069】
図5および6においては、もしUE120がアイドルモードにある場合、図4への変更について上記に説明されるように、ステップ1は、今、単に(just)ページングおよび認証を含んでいるべきである。ステップ11は、今、図4におけるちょうどステップ13(そしてステップ12および13の両方ではない)に対応する。
【0070】
図4において示されるメッセージフロー400の場合、比較的長いMO−LRトランザクションがステップ4からステップ12まで生じるかもしれない。この時間の間、UE120は、各位置転送の成功か失敗かの知識を持たないかもしれない、そして、報告の完了後に定期的位置報告の結果が通知される。然しながら、オープンMO−LRトランザクション(open MO-LR transaction)は、UE120へのCMおよびMM/GMM接続を維持するのに、また、UE120がアイドルモードに戻るのを防ぐために、有用であり得る。LCS更新サービス(update services)を使用して、定期的位置報告の進行状況(progress)をUE120が通知されるのを維持することは望ましいかもしれない。
【0071】
図7は、通知付きのRANベースの定期的位置報告(RAN-based periodic location reporting with notification)のためのメッセージフロー700の一実施形態を示す。メッセージフロー700もまた、図2A、2Bおよび3におけるメッセージフロー200、210および300のステップ10のためにそれぞれ使用されてもよい。メッセージフロー700のステップ1から4までは、図4におけるメッセージフロー400のステップ1から4までと同じである。UE120は、MSC/SGSN140に、定期的位置(periodic location)を呼び出すために、LCS MO−LR位置サービス呼び出しメッセージ(LCS MO-LR Location Services Invoke message)を送る(ステップ4)。MSC/SGSN140は、呼び出しを確認するために、UE120に、LCS MO−LRリターン結果メッセージを送り(ステップ5)、そうすることによって、MO−LRリクエストがサポートされるであろうという即時のフィードバックをUE120に提供する。MSC/SGSN140はまた、RAN130に、定期的位置情報およびLCS QoSを含んでいる位置リクエストメッセージを送る(ステップ6)。
【0072】
メッセージフローは、そのあと、UE120についての最初の位置推定値を得るために、また、LCSクライアント170に位置推定値を転送するために、実行される(ステップ7a)。ステップ7aは、図4におけるメッセージフロー400のステップ6aから11aまで、図5におけるメッセージフロー500のステップ3から10aまで、あるいは、図6におけるメッセージフロー600のステップ3から10aまでを含んでいてもよい。MSC/SGSN140は、そのあと、最初の位置推定値がLCSクライアント170に成功裡に転送されたことを示すために、UE120に、LCS位置アップデート呼び出しメッセージ(LCS Location Update Invoke message)を送る(ステップ8a)。このメッセージはまた、例えば、次の定期的間隔に続く、次の位置報告エベントで、第2の位置推定値が転送されるであろうと、UE120に通知するように機能する(serve)ことができる。UE120は、通知の受取を確認するために、MSC/SGSN140にLCS位置アップデートリターン結果メッセージを送る(ステップ9a)。このメッセージは、もしUE120が定期的位置プロシージャをこの時点でキャンセルすることを望む場合は、次の位置報告の拒否を含むことができる。
【0073】
各々の後に続く位置報告エベントi、但しi=b...n、について、メッセージフローが、LCSクライアント170へのUE120についての位置推定値を取得し転送するために実行され(ステップ7i)、LCS位置アップデート呼び出しメッセージが、位置転送の結果をUE120に通知するためにMSC/SGSN140よって送られ(ステップ8i)、そして、LCS位置アップデートリターン結果メッセージが、通知を確認するためにUE120によって送られる(ステップ9i)。位置報告エベントのすべてが完了した後に、MSC/SGSN140は、CM、MMあるいはGMM、およびRR/RRCのUE120への接続のリリースを開始してもよい(ステップ10)。
【0074】
別の実施形態においては、LCS MO−LRリターン結果メッセージは、図7中のステップ5においては送られずに、図4中のメッセージフロー400と似たように、代わりにステップ9nの後に送られる。この場合、図7中のステップ8a...8nにおけるLCS位置アップデート呼び出しメッセージのMSC/SGSN140からUE120への送信は、UE120に、UE120への各位置転送の結果と同様にMO−LRリクエストがサポートされるであろうというUE120へのフィードバックを提供する。
【0075】
代替実施形態においては、各ステップ8iにおけるLCS位置アップデート呼び出しメッセージと各ステップ9iにおけるLCS位置アップデートリターン結果メッセージは、それぞれ、LCS通知呼び出しメッセージとLCS通知リターン結果に取り替えられ、それらは、3GPP TS 24.080において定義される現行の3GPPメッセージである。現行の3GPPメッセージの使用は、MSC/SGSN140およびUE120へのインプリメンテーションインパクト(implementation impacts)を軽減することができる。
【0076】
さらに別の実施形態においては、LCS位置アップデート呼び出しメッセージおよびLCS位置アップデートリターン結果メッセージのペアかまたはLCS通知呼び出しメッセージおよびLCS通知リターン結果メッセージのペアは、エベントの後(図7において示されるような)に代えて、各位置報告エベントに先立って交換される(図7においては示されていない)。この実施形態の場合、LCS位置アップデート呼び出しメッセージあるいはLCS通知呼び出しメッセージは、位置推定値は次の位置報告エベントにおいて取得されLCSクライアント170に転送されることをUE120に通知する。UEユーザは、そのとき、転送を拒否する、あるいは定期的位置報告をキャンセルする機会を与えられてもよい。メッセージはまた、UE120に、以前の転送の結果(例えば、もし位置推定値が得られなかった場合は、転送が成功したのか不成功であったのかどうか)を通知してもよい。さらに別の実施形態においては、LCS位置アップデート呼び出しメッセージおよびLCS位置アップデートリターン結果メッセージのペアかまたはLCS通知呼び出しメッセージおよびLCS通知リターン結果メッセージのペアは、各位置報告エベントに先立って送られ、そして、これらのメッセージの最終のペアは、最後の位置報告エベントの後に送られる。各位置報告エベントより先のメッセージペアは、UE120に前の位置転送(previous location transfer)の結果(もしあれば)を伝え、UE120が転送を拒否するあるいはプロシージャをキャンセルすることを可能にし、そして、UE120に次の転送を通知する。最後の位置報告エベントの後のメッセージペアは、UE120に定期的位置報告の終了および位置転送の結果を通知する。
【0077】
UE120が、それ自身の使用のために、あるいは、UE120が通信している(例えば、インターネットによってアクセスされる)ある外部アプリケーションのために、それ自身の位置を定期的に決定するために、定期的セルフロケーション(periodic self location)を実行することが望ましいかもしれない。もしUE120がUEベースのモードをサポートする場合、そのときは、UE120は、たぶんRAN130とのどんなシグナリングもなしに、必要なときはいつでも、それ自身で位置推定値を導き出すことができる。然しながら、もしUE120が、UE支援のモードをサポートするのみかポジショニング機能を有さない場合は、そのときは、セルフロケーションのための各MO−LRリクエストについてRAN130における各位置トランザクションを定期的にセットアップしかつ解体する(set up and tear down)ために、もし各々のそのようなリクエストがシングルショット位置リクエスト(single shot location request)のみを開始するのであれば、オーバーヘッド(overhead)が背負いこまれる(incurred)であろう。このオーバヘッドは、定期的セルフロケーションについてRAN130の定期的LCS機能を使用することによって軽減あるいは回避されることができる。
【0078】
図8は、RANベースのMO −LR定期的セルフロケーション−のためのメッセージフロー800の一実施形態を示す。定期的セルフロケーションは、定期的位置報告の特別なケースとして見られることができ、ここでは、LCSクライアントは、外部のLCSクライアント170の代わりにUE120である。
【0079】
メッセージフロー800のステップ1から3までは、図4におけるメッセージフロー400のステップ1から3までと同じである。UE120は、そのとき、MSC/SGSN140に、定期的セルフロケーションをリクエストするためにLCS MO−LR位置サービス呼び出しメッセージを送る(ステップ4)。このメッセージは、関連情報、例えば、定期的位置情報(例、開始時間、報告間隔、及び、停止時間、報告持続時間あるいは報告の設定回数のうちの1つ)、LCS QoSなど、を含んでいる。メッセージはまた、定期的位置推定値がUE120に送られるべきであることを示す。MSC/SGSN140は、UE120が、UEについての加入プロファイルに基づいて、リクエストされた位置サービスに対し許可されることを、確認する(同様にステップ4)。もし位置リクエストが許可されるのであれば、そのときは、MSC/SGSN140は、定期的セルフロケーションリクエストの受理を示すために、UE120にLCS MO−LRリターン結果メッセージを送る(ステップ5)。MSC/SGSN140はまた、RAN130に、定期的セルフロケーションリクエスト、定期的位置情報、UE機能、およびLCS QoSを含んでいる位置リクエストメッセージを送る(ステップ6)。
【0080】
メッセージフローはそのあと、UE120についての最初の位置推定値を得るために実行される(ステップ7a)。ステップ7aは、図5におけるメッセージフロー500のステップ3から8aまで、あるいは図6におけるメッセージフロー600のステップ3から8aまで、を含むことができる。RAN130は、ステップ7aにおけるメッセージフローからUE120についての位置推定値を受け取り、そして、MSC/SGSN140に、この位置推定値および他の関連情報を含んでいる位置報告メッセージを送る(ステップ8a)。MSC/SGSN140は、そのあと、UE120に、最初の位置推定値および関連情報を含んでいるLCS位置アップデートメッセージを送る(ステップ9a)。UE120は、最初の位置推定値の受取りを確認するLCS位置アップデート肯定応答メッセージを返す(ステップ10a)。このメッセージはまた、定期的セルフロケーションをキャンセルする表示(indication)を、もしそのようなことがUE120により望まれるのであれば、含むことができる。各々のその後のセルフロケーションエベントi、但しi=b...n、について、メッセージフローは、UE120についての位置推定値を得るために(ステップ7i)、そして位置推定値をMSC/SGSN140に送るために、実行される(ステップ8i)。MSC/SGSN140はそのあと、位置推定値をUE120に返す(ステップ9iおよび10i)。位置報告エベントのすべてが完了した後、MSC/SGSN140は、CM、MMあるいはGMM、およびRR/RRCのUE120への接続のリリースを開始することができる。
【0081】
別の実施形態においては、図4におけるメッセージフロー400に似たように、LCS MO−LRリターン結果メッセージは、図8の中のステップ5においては送られず、代わりにステップ10nの後に送られる。別の実施形態においては、各ステップ9iにおけるLCS位置アップデートメッセージおよび各ステップ10iにおけるLCS位置アップデート肯定応答は、それぞれ、現行の3GPPメッセージであるLCS通知呼び出しメッセージおよびLCS通知リターン結果メッセージと取り替えられる。この場合もやはり、現行の3GPPメッセージの使用は、MSC/SGSN140およびUE120へのインプリメンテーションインパクトを軽減することができる。
【0082】
RANベースの定期的位置報告はまた、GERANと通信する移動局(MS)について使用されてもよい。パケットモード定期的位置報告プロシージャ(packet mode periodic location reporting procedure)は、図1Bにおいて2G−SGSN140aによって受け取られる定期的位置リクエストの場合に使用されることができる。
【0083】
サーキットモード定期的位置報告プロシージャ(circuit mode periodic location reporting procedure)は、2G−MSC140bによって受け取られる定期的位置リクエストの場合に使用されることができる。サーキットモードにおけるGERAN定期的位置報告の場合、GSM(登録商標)における基地局サブシステム(BSS)は定期的位置の間隔(intervals of periodic location)の間に、専用のシグナリングチャネルを動的にリリースし、後で再割り当てするための機能を有していないので、MSが、定期的位置報告の全持続期間の間、専用モードで動作することができ、シグナリングチャネル(signaling channel)(例、SDCCH)を割り当てられることができる。パケットモードにけるGERAN定期的位置報告の場合、MSは、MSとBSSとの間でメッセージを転送することが必要なときに、シグナリングチャネルを動的に割り当てられることができる。以下の説明では、UE120(UMTS専門用語)は、MS120(GSM(登録商標)専門用語)と呼ばれる。MS120は、GERAN130aにおいてBSSと通信する。
【0084】
図9は、パケットモードにおけるGERANのためのRANベースの定期的位置報告のためのメッセージフロー900の実施形態を示す。LCSクライアント170あるいはMS120は、定期的にLCSクライアント170にMS120についての位置推定値を送るリクエストを開始することができる(ステップ1)。例えば、図2A、2Bあるいは3の場合にそれぞれ上記に説明されるように、定期的位置(periodic location)は、MT−LR、NI−LRあるいはMO−LRによって、開始されることができる。定期的位置リクエストは、SGSN140aに、LCSクライアント170によって出されたMT−LRのための1つまたは複数のGMLCsを経由して、あるいはMS120によって出されたMO−LRのためのBSSを経由して、転送されることができる。リクエストは、位置推定値を送るためのスケジュールあるいは条件(例、エベント)を識別する定期的位置情報を含むことができる。リクエストは、関与するエンティティ(participating entities)、例えば、GMLCs150、SGSN140a、MS120、およびLCSクライアント170によって承認されることができる。定期的位置配信は、そのあと、MS120からのMO−LRによってか、またはSGSN140aによって、スターとされることができ、それは、MS120がアイドルモードに戻っている(has reverted)場合は、ページングおよび認証(paging and authentication)を実行することができる。
【0085】
SGSN140aは、BSSGP実行位置リクエストメッセージ(BSSGP Perform Location Request message)を、MS120に現在サービングを行っているBSSに送る(ステップ2)。このメッセージは、定期的位置リクエストを含み、そして更に、定期的位置情報、QoS、及び/又は他の関連情報を含んでいる。BSSは、メッセージを受け取り、そして、リクエストがシングルショット位置(single shot location)よりは寧ろ定期的位置(periodic location)についてであることを認識する。BSSは、そのあと、BSSMAP−LE実行位置リクエストメッセージ(BSSMAP-LE Perform Location Request message)において定期的位置リクエストおよび定期的位置情報をSMLC132に送る(ステップ3)。
【0086】
SMLC132は、BSSからメッセージを受け取り、定期的位置リクエストを評価し(evaluate)、ポジショニング方法(positioning method)を選択する。もしA−GPS及び/又はE−OTDが選択される場合は、そのときSMLC132は、BSSに、BSSMAP−LEコネクション型情報メッセージ(BSSMAP-LE Connection Oriented Information message)を送るが、これはBSSLAP MSポジションコマンドメッセージ(BSSLAP MS Position Command message)を含んでおり、更にそれはRRLP測定ポジションリクエストメッセージ(RRLP Measure Position Request message)(ステップ4)。BSSLAP MSポジションコマンドメッセージは、定期的位置(periodic location)がリクエストされているという指示(indication)を伝えることができ、また、BSSはこの情報を記録することができる。RRLP測定ポジションリクエストメッセージは、定期的位置情報、この情報のサブセット(subset)、あるいはこの情報の変換されたセットあるいはサブセットを含むことができる。RRLP測定ポジションリクエストメッセージはまた、MS120がA―GPS及び/又はE−OTD測定を実行するのを支援するための、そして、もしMSベースのポジショニングが選択されるのであれば、MS120が位置推定値を計算するのを支援するための、支援データを含むことがでる。もし支援データが1つのRRLP測定ポジションリクエストメッセージに適合しない場合、そのときSMLC132は、RRLP測定ポジションリクエストメッセージを送る前に、1つまたは複数のRRLP支援データメッセージにおいて、MS132に、定期的位置情報を含む支援データおよび他の情報のうちのいくつかあるいはすべてを送ることができる(図9においては示されていない)。MS120は、そのあと、RRLP支援データ肯定応答メッセージで各RRLP支援データメッセージを確認するであろう。
【0087】
BSSは、SGSN140aに、SMLC132から受け取られたRRLP測定ポジションリクエストメッセージを含んでいるBSSGPポジションコマンドメッセージ(BSSGP Position Command message)を送る(ステップ5)。SGSN140aは、そのあと、MS120に、SMLC132から受け取られたRRLP測定ポジションリクエストメッセージを伝えるTOMメッセージ(TOM message)を含んでいる論理リンク制御(LLC)未確認情報(UI)フレームメッセージ(Logical Link Control (LLC) Unconfirmed Information (UI) Frame message)を送る(ステップ6)。MS120は、SGSN140aからメッセージを受け取り、そして、RRLP測定ポジションリクエストメッセージにおいて(あるいは前のRRLP支援データメッセージにおいて)含まれた定期的位置情報に基づいた定期的位置リクエストを認識する。もしA−GPSが選択される場合、そのときは、MS120は、RRLP測定ポジションリクエストメッセージあるいは前の支援データメッセージを受け取ると支援データ(もしあれば)を使用して、GPS衛星からの信号を取得し、測定することができる。もしE−OTDが選択される場合、そのときは、MS120は、近くの基地局からの信号を取得して測定することを始めることができる。MS120はまた、もしE−OTDとA−GPSとが両方とも選択される場合は、GPS衛星と基地局との両方からの信号を取得して測定することができる。
【0088】
最初のスケジュールされた位置推定が期限になったとき、あるいは、位置推定が必要とされる最初のセットの条件(例、エベント)が発生するとき、MS120は、A−GPS及び/又はE−OTDの測定を実行する。もしMSベースのポジショニングが選択された場合、そのときは、MS120はさらに、測定値から位置推定値を得る。MS120は、そのあと、SGSN140aに、RRLP測定ポジションレスポンスメッセージにおいて測定値か位置推定値を送る(ステップ7a)。RRLP測定ポジションレスポンスメッセージは、TOMメッセージにおいて搬送され、それは、今度はLLC UIフレームメッセージにおいて搬送される。TOMメッセージヘッダー(TOM message header)は、RRLP測定ポジションレスポンスメッセージは最後のものではないことを示しているフラグ(flag)を含んでいる。RRLP測定ポジションレスポンスメッセージはまた、もっと多くの定期的位置推定値が後で提供されるだろうという表示を搬送することができる。MS120は、もし測定値あるいは位置推定値が単一のメッセージに適合しない場合は、1つより多くのRRLP測定ポジションレスポンスメッセージを送ってもよい(図9においては示されていない)。
【0089】
SGSN140aは、MS120からLLC UIフレームメッセージを受け取り、そして、BSSGPポジションレスポンスメッセージにおいてRRLP測定ポジションレスポンスメッセージをBSSに転送する(ステップ8a)。BSSGPポジションレスポンスメッセージヘッダーは、これが最後のRRLP測定ポジションレスポンスメッセージではないことを示しているフラグを含んでいる。BSSは、SGSN140aからBSSGPポジションレスポンスメッセージを受け取り、そして、BSSMAP−LEコネクション型情報メッセージにおいて搬送されるBSSLAP MSポジションレスポンスメッセージの中でRRLP測定ポジションレスポンスメッセージを、SMLC132に転送する(ステップ9a)。BSSLAP MSポジションレスポンスメッセージヘッダーは、これが最後のRRLP測定ポジションレスポンスメッセージではないことを示しているフラグを含んでいる。BSSは、(ステップ2からの、そしてたぶんステップ4からの)そしてまたフラグ設定からの定期的位置リクエストに気付いている。BSSはこのようにして、MS120からの更なるRRLP測定ポジションレスポンスメッセージを予期し、そして、すべての測定値あるいは位置推定値(RRLP測定ポジションレスポンスメッセージ内部の)がMS120から転送されてしまう前は、定期的位置(periodic location)を途中停止しない。
【0090】
SMLC132は、MS120によって提供される測定値から位置推定値を計算する、あるいは、MSによって提供されるどんな位置推定値も確認する(verifies)。SMLC132はそのあと、BSSMAP−LE実行位置報告メッセージ(BSSMAP-LE Perform Location Report message)において計算されたあるいは確認された位置推定値をBSSに送る(ステップ10a)。このメッセージは、BSSに、定期的位置(periodic location)が未だ終えられていないことを、また、更なる位置推定値がSMLC132によって後で提供されるであろうことを、通知する。BSSは、SMLC132から位置推定値を受け取り、そして、BSSGP実行位置報告メッセージ(BSSGP Perform Location Report message)においてこの位置推定値をSGSN140aに送る(ステップ11a)。このメッセージは、SGSN140aに、定期的位置(periodic location)が終えられていないことを、また、更なる位置推定値が後で提供されるであろうことを、通知する。SGSN140aはそのあと、位置推定値を、例えば、図4においてステップ8aからllaまでを使用してGMLC経由で、あるいは、BSS経由で、LCSクライアント170に転送する。
【0091】
ステップ7aからllaまでは1つの位置報告エベントのためのものである。これらのステップは、スケジュールされあるいはトリガされる各追加の位置推定値の場合に繰り返されることができる。もし、利用可能な支援データがもはや有効ではないためにMS120が測定値あるいは位置推定値を得ることができない場合、そのときMS120は、後のステップ7で送られるRRLP測定ポジションレスポンスメッセージの中でより多くの支援データのリクエストを含めることができる。このデータリクエストは、測定値あるいは位置推定値の代わりに、あるいはその測定値に加えて送られるかもしれない。ステップ9においてこのリクエストを受取り次第、SMLC132は、1つあるいは複数のRRLP支援データメッセージを使用して、リクエストされた支援データをMS120に送るだろう。一実施形態においては、SMLC132およびMS120の両方は、支援データの転送を、(例えば、ステップ4、5および6において始められた)定期的位置(periodic location)についてのペンディングのRRLPトランザクションと平行して生じる追加のRRLPトランザクションとして扱う。MS120は、ステップ7aから11aまでを繰り返すことによって、SMLC132に定期的な測定値あるいは位置推定値を送り続ける。別の実施形態においては、より多くの支援データについてのリクエストを送るとき、MS120は、SMLC132への定期的な測定値あるいは位置推定値の転送を終了することができる。例えば、MS120は、より多くの支援データのリクエストを搬送するRRLP測定ポジションレスポンスメッセージにおいてエラー表示を含めることにより、定期的位置報告の終了を示すことができる。その場合、後のステップ7において送られるTOMメッセージヘッダーは、これが最後のRRLP測定ポジションレスポンスメッセージであることを示しているフラグを含むことができる。BSSがその後のステップ8においてSGSN140aからこのフラグを受け取るとき、BSSは、この最後のRRLP測定ポジションレスポンスメッセージを、SMLC132に送り、そして、MS120からのこれ以上のRRLP測定ポジションレスポンスメッセージを期待しない。SMLC132は、ステップ4から11までを繰り返すことによって、MS120からの定期的測定あるいは位置推定値の転送をリスタートすることができる。SMLC132は、リクエストされた支援データを、RRLP測定ポジションリクエストメッセージ及び/又は1つあるいは複数のRRLP支援データメッセージにおいて、MS120に送ることができる。
【0092】
MS120は、定期的位置(periodic location)についての最終の測定値あるいは位置推定値をSGSN140aに送る(ステップ7n)。測定値あるいは位置推定値は、RRLP測定ポジションレスポンスメッセージにおいて送られ、RRLP測定ポジションレスポンスメッセージはTOMメッセージの中で搬送され、TOMメッセージはさらにLLC UIフレームメッセージの中で搬送される。これらのメッセージは、これが最終のRRLP測定ポジションレスポンスメッセージであることを示すフラグをTOMメッセージヘッダーが含んでいる以外は、ステップ7aにおいて使用されるものと同じである。RRLP測定ポジションレスポンスメッセージは、これが最後の定期的測定値あるいは位置推定値であることを示すパラメータを含むことができる。ステップ8nから11nまでは、ステップ8aから11aまでに似ている。然しながら、最終のRRLP測定ポジションレスポンスメッセージが送られていることを示しているフラグは、ステップ8nにおいてSGSN140aによって送られるBSSGPポジションレスポンスメッセージにおいて、また、ステップ9nにおいてBSSによって送られるBSSLAP MSポジションレスポンスメッセージにおいて、含まれることができる。SMLC132は、定期的位置プロシージャが終了したことをBSSに通知するために、ステップ10aにおけるBSSMAP−LE実行位置報告メッセージの代わりに、ステップ10nにおいてBSSMAP−LE実行位置レスポンスメッセージを送ることができる。BSSは、定期的位置プロシージャが終了したことをSGSN140aに通知するために、ステップ11aにおけるBSSGP実行位置報告メッセージの代わりに、ステップ11nにおいてBSSGP実行位置レスポンスメッセージを送ることができる。新しいポジショニングプロシージャがSMLC132によって開始されなければ、BSSは、MS120からのこれ以上のRRLP測定ポジションレスポンスメッセージを期待しなし。SMLC132は、ステップ4から9nまでを繰り返すことによって、さらに定期的位置(periodic location)を開始することができる。SGSN140aは、ステップ2から11nまでを繰り返すことによって、定期的位置報告を続けることができる。そうでなければ、SGSN140aは、定期的位置報告が今完了することを、LCSクライアント170に示すことができる。
【0093】
図9におけるメッセージフロー900の間に、更なるアクションを必要とするある種の例外状態が発生するかもしれない。もしMS120がサービングセルを変更するが同じBSSのサービスエリア内に残る場合、そのときは、BSSは、新しいセルの識別情報を含んでいるBSSMAP−LE実行位置情報メッセージをSMLCに送ることによって、新しいセルをSMLC132に通知することができる。他のいくつかの例外状態、例えば、新しいBSSへのセル変更、SGSN内のPRSルーティングエリアアップデート(intra-SGSN GPRS routing area update)、あるいはTMSI再割り当てなど、については、MS120及び/又はBSSは、定期的位置プロシージャを途中停止することができ、また、SGSN140aは、例えば、新しいBSSへのシグナリングによりプロシージャをリスタートすることができる。
【0094】
図10は、サーキットモードにおけるGERANの場合のRANベースの定期的位置報告のためのメッセージフロー1000の一実施形態を示す。サーキットモードのためのメッセージフロー1000は、パケットモードのためのメッセージフロー900に似ている。相違は、SGSN140aが2G−MSC140bと取り替えられること、SGSN140aとBSSとの間のBSSGPメッセージが、対応するBSSMAPメッセージと取り替えられること、そして、BSSとMS120との間のRRLPメッセージの転送がより直接であること、である。
【0095】
LCSクライアント170あるいはMS120は、MS120についての位置推定値を定期的にLCSクライアント170に送るようにリクエストを開始することができる(ステップ1)。リクエストは、1つ以上のGMLCsを経由してあるいはBSSを経由して、2G−MSC140bに転送されることができる。リクエストは、定期的位置情報を含むことができ、また、関与するエンティティ、例えば、GMLCs150、2G−MSC140b、MS120、およびLCSクライアント170によって承認されることができる。定期的位置配信はそのあと、MS120からのMO−LRによるかまたは、もしMS120がアイドルモードに戻っているならばページングおよび認証を行なうことができる2G−MSC140bによって、始められることができ。
【0096】
2G−MSC140bは、BSSMAP実行位置リクエストメッセージ(BSSMAP Perform Location Request message)を、MS120に現在サービングを行っているBSSに送る(ステップ2)。このメッセージは定期的位置リクエストを含んでおり、定期的位置情報、QoS、および他の関連情報をさらに含んでいる。BSSは、BSSMAP−LE実行位置リクエストメッセージにおける定期的位置リクエストをSMLC132に送る(ステップ3)。SMLC132は、メッセージを受け取り、定期的位置リクエストを評価し、そして、ポジショニング方法を選択する。もしA−GPS及び/又はE−OTDが選択される場合、そのときは、SMLC132は、BSSに、BSSLAP MSポジションコマンドメッセージ(BSSLAP MS Position Command message)を含んでいるBSSMAP−LEコネクション型情報メッセージ(BSSMAP-LE Connection Oriented Information message)を送る、なお、BSSLAP MSポジションコマンドメッセージは更にRRLP測定ポジションリクエストメッセージ(RRLP Measure Position Request message)を含んでいる(ステップ4)。
【0097】
BSSは、MS120に、SMLC132から受け取られたRRLP測定ポジションリクエストメッセージを含んでいるRRアプリケーション情報メッセージ(RR Application Information message)を送る(ステップ5)。MS120は、BSSからメッセージを受け取り、RRLP測定ポジションリクエストメッセージにおいて(あるいは前のRRLP支援データメッセージにおいて)含まれる定期的位置情報に基づいた定期的位置リクエストを認識する。MS120は、(A−GPSのための)GPS衛星からの、かつ/または(E−OTDのための)基地局の近くの、信号を取得しそして測定することができる。
【0098】
最初のスケジュールされた位置推定値が期限になったとき、あるいは、位置推定値が必要とされる最初のセットの条件(例、エベント)が発生するとき、MS120は、A−GPS及び/又はE−OTDの測定を実行し、そして、もしMSベースのポジショニングが選択されたならば、更に位置推定値を得る。MS120は、そのあと、BSSに、RRアプリケーション情報メッセージの中で搬送されるRRLP測定ポジションレスポンスメッセージにおいて測定値あるいは位置推定値を送る(ステップ6a)。RRアプリケーション情報メッセージヘッダーは、これが最後のRRLP測定ポジションレスポンスメッセージではないことを示しているフラグを含む。RRLP測定ポジションレスポンスメッセージはまた、もっと定期的位置推定値が後で提供されるであろうという表示を伝えることができる。
【0099】
BSSは、MS120からRRアプリケーション情報メッセージを受け取り、そして、BSSMAP−LEコネクション型情報メッセージの中で搬送されるBSSLAP MSポジションレスポンスメッセージにおいて、RRLP測定ポジションレスポンスメッセージをSMLC132に転送する(ステップ7a)。BSSLAP MSポジションレスポンスメッセージヘッダーは、これが最後のRRLP測定ポジションレスポンスメッセージではないことを示しているフラグを含む。SMLC132は、MS120によって提供される測定値からの位置推定値を計算する、あるいは、MSによって提供されるどんな位置推定値も確認する。SMLC132はそのあと、BSSMAP―LE実行位置報告メッセージにおいて、計算されたあるいは確認された位置推定値をBSSに送る(ステップ8a)。BSSは、SMLC132から位置推定値を受け取り、そして、BSSMAP実行位置報告メッセージにおいて、この位置推定値を2G−MSC140bに送る(ステップ9a)。2G−MSC140bはそのあと、位置推定値を、例えば、GMLCまたはBSSを経由して、LCSクライアント170に転送する。
【0100】
ステップ6aから9aまでは1つの位置報告エベントのためのものである。これらのステップは、スケジュールされているかあるいはトリガされている各追加の位置推定のために繰り返されることができる。MS120は、後のステップ6においてRRLP測定ポジションレスポンスメッセージの中でリクエストを送ることにより、より多くの支援データを得ることができる。SMLC132およびMS120は、支援データの転送を、定期的位置(periodic location)についてのペンディングのRRLPトランザクションと平行して生じる追加のRRLPトランザクションとして扱う。あるいは、MS120は、例えば、これが最後のRRLP測定ポジションレスポンスメッセージであることを示すために、RRアプリケーション情報メッセージヘッダーの中にフラグを含めることによって、定期的測定値あるいは位置推定値の転送を終了することができる。SMLC132は、そのあと、ステップ4から9までを繰り返すことによって、MS120からの定期的測定値あるいは位置推定値の転送をリスタートすることができる。
【0101】
MS120は、BSSに定期的位置(periodic location)についての最終的な測定値あるいは位置推定値を送る(ステップ6n)。測定値あるいは位置推定値はRRLP測定ポジションレスポンスメッセージにおいて送られ、それはRRアプリケーション情報メッセージにおいて搬送される。これらのメッセージは、RRアプリケーション情報メッセージヘッダーが、これが最終のRRLP測定ポジションレスポンスメッセージであることを示しているフラグを含んでいること以外は、ステップ6aにおいて使用されるものと同じである。RRLP測定ポジションレスポンスメッセージは、これが最後の定期的測定値あるいは位置推定値であることを示しているパラメータを含むことができる。ステップ7nから9nまでは、ステップ7aから9aまでに似ている。然しながら、ステップ7nにおいてBSSによって送られたBSSLAP MSポジションレスポンスメッセージは、最終のRRLP測定ポジションレスポンスメッセージが送られていることを示しているフラグを含んでいる。SMLC132は、ステップ8nにおいてBSSMAP−LE実行位置レスポンスメッセージ(BSSMAP-LE Perform Location Response message)を送ることができ、そして、BSSは、定期的位置プロシージャが終了したことを示すためにステップ9nにおいてBSSMAP実行位置レスポンスメッセージ(BSSMAP Perform Location Response message)を送ることができる。SMLC132は、ステップを4から7nまでを繰り返すことにより、もっと定期的位置報告を開始することができる。2G−MSC140bは、ステップを2から9nまでを繰り返すことにより、定期的位置報告を続けることができる。そうでなければ、2G−MSC140bは、定期的位置報告が今完了することをLCSクライアント170に示すことができる。
【0102】
図10におけるメッセージフロー1000の間に、更なるアクションを必要とするある種の例外状態が発生するかもしれない。もしMS120がサービングセルを変更するが同じBSSのサービスエリア内に残る場合、あるいは、もしある他のRR管理プロシージャがBSSとMS120との間で行われ、それがBSSとMS120との間にサーキットモード無線シグナリングリンク(circuit mode radio signaling link)を依然と残す場合、そのときは、BSSは、ポジショニングを途中停止することができ、また、SMLC132は、シングルショットかあるいは定期的ポジショニングのためにMS120においてポジショニングをリスタートすることができる。あるいは、BSSは、SMLC132に、任意のセル変更を(例えば、BSSMAP−LE実行位置情報メッセージを送ることによって)通知することができ、また、MS120、BSSおよびSMLC132は、定期的ポジショニングを続けることができる。新しいBSSへのハンドオーバのような、いくつかの他の例外状態については、MS120及び/又はBSSは定期的位置プロシージャを途中停止することができ、また、2G−MSC140bは、例えば、新しいBSSへのシグナリングによりプロシージャをリスタートすることができる。
【0103】
図9および10における多くのメッセージは、3GPP TS 43.059において説明されており、そして、MSのワンショット位置(one shot location)のために使用される。これらのメッセージは、定期的位置のインプリメンテーションを単純化するために可能な場合はいつも、定期的位置のために使用されることができる。他のメッセージもまた、図9および10の場合に使用されてもよい。
【0104】
図4から10までは、RANベースの定期的位置報告のために使用されることができる例示的なメッセージフローを示す。図の4から7まで、9、および10、におけるメッセージフローは、定期的位置リクエストが許可されたあとに、図2Aおよび3において示されるMT−LRおよびMO−LRの定期的プロシージャの一部として、それぞれ使用されることができる。これらのメッセージフローはまた、スタンドアロンのプロシージャとして使用されることもでき、従って、MT−LRおよびMO−LRの定期的プロシージャの一部であることに制限されない。RANベースの定期的位置報告のための他のメッセージフローはまた、MT−LRおよびMO−LRの定期的プロシージャと共に使用されるために実施される(implemented)こともできる。
【0105】
UE120は最初に、定期的LCS機能を有さずそして図4から10までにおいてメッセージフローをサポートしないRAN(例、GERAN)と通信するかもしれない。定期的位置報告は、そのあと、他の方法で、例えば、UE120、あるいは、LCSクライアント170へのUE120についての単一の位置推定値を取得しそして転送するために定期的にメッセージフローを開始するネットワークエンティティ(例、GMLC150)を用いて、達成されることができる。もしUE120が続いて、定期的LCS機能を有するRAN(例、UTRAN)のサービスエリア内で移動する場合、そのときUE120は、新しいRANに切り換えることができ、また、この新しいRANの定期的LCS機能は、効率的に定期的位置報告を提供するために利用されることができる。
【0106】
簡単にするために、RANベースの定期的位置報告についての上記説明は、1つのGMLC(例えば、図IAにおいて示されるような)を備えた展開(deployment)および各位置推定のために実行されるポジショニングを前提としている。RANベースの定期的位置報告はまた、複数のGMLCs(例えば、図IBにおいて示されるような)を備えた展開について使用されることができる。改良された効率は、(1)複数のGMLCsを備えた展開についてGLMCショートサーキット、および(2)1つまたは複数のGMLCsを備えた展開についてMO−LRショートサーキット、を使用することにより達成されることができる。GLMCショートサーキットは、図1BにおいてR−GMLC150cとMSC/SGSN140との間での直接のメッセージの交換を指し、それによって、V−GMLC150aおよびH−GMLC150bをバイパス(bypassing)し、あるいは短絡化(short-circuiting)する。MO−LRショートサーキットは、たとえ、適切な位置推定値がUE120に利用可能であって、MO−LRショートサーキットの使用が認められる場合であっても、各位置報告エベントについてのポジショニングのバイパスを指す。GMLCショートサーキット、MO−LRショートサーキット、あるいは両方のタイプのショートサーキットは、システムリソースを節約するために、また、LCSクライアント170への位置転送についてより速いレスポンスを供給するために使用されることができる。MO−LRショートサーキットかあるいはRANベースの定期的報告は、UEベースのポジショニングのために使用されることができる。然しながら、もし、UEが、MO−LRショートサーキットあるいはLCSクライアントをサポートしない場合、あるいは、関係しているPLMNのうちのいずれかが、MO−LRショートサーキットの使用を否定する場合、そのときは、RANベースの定期的ポジショニングのみが、UEベースのポジショニングに適することができる。反対に、もしRAN(例、GERAN)がRANベースの定期的報告をサポートしない場合、そのときは、MO−LRショートサーキットのみが適することができる(もし許可され、かつサポートされる場合)。UE支援のポジショニングあるいはネットワークベースのポジショニングの場合(例、UE支援のポジショニングを唯一サポートするUEの場合)、MO−LRショートサーキットは使用されず、RANベースのポジショニングのみが適することができる。従って、MO−LRショートサーキットおよびRANベースの定期的報告は、異なる状況の下で適用可能であり得る。
【0107】
MO−LRショートサーキットの使用は、例えば、ビリングと加入の点などについて、UEの正確さ及び信頼性、あるいはUEの完全性(integrity)における信頼の欠如(例、スプーフィング(spoofing))に対処するためのような、様々な理由のために、コントロールされることができる。例えば、もしUE120が、RAN130による確認なしにMSC/SGSN140に位置推定値を直接に提供することを信頼される場合は、MO−LRショートサーキットの使用は認められることができる。GLMCショートサーキットの使用もまた、ビリング、加入などに関連する理由のためにコントロールされることができる。
【0108】
一実施形態においては、1つのエンティティ(例、UE120、MSC/SGSN140、あるいはR−GMLC150c)は、後の位置報告エベントのために、GMLCショートサーキット及び/又はMO−LRショートサーキットを使用する許可をリクエストすることができる。任意の他のエンティティ(例、MSC/SGSN140、V−GMLC150a、H−GMLC150b、R−GMLC150c、UE120およびLCSクライアント170)は、各タイプのショートサーキットのリクエストを受理あるいは拒否することができる。別の実施形態においては、1つのエンティティ(例、UE120、MSC/SGSN140、あるいはR−GMLC150c)は、GMLCショートサーキット及び/又はMO−LRショートサーキットを、これらのショートサーキットを使用することを特にリクエストすること無しに、サポートするための意向(willingness)あるいは機能を示すことができる。V−GMLC150a、H−GMLC150b、R−GMLC150c、UE120およびLCSクライアント170の中の任意のエンティティは、そのあと、各タイプのショートサーキットをサポートする意向あるいは機能を、受理あるいは拒否することができる。あるエンティティ(例、H−GMLC152)は、もしすべてのエンティティがそのショートサーキットについて意向および機能を示す場合、各タイプのショートサーキットを使用するべきかどうかを決定することができる。すべての実施形態の場合、GMLCショートサーキットを使用するリクエストおよびMO−LRショートサーキットを使用するリクエストは、独立したリクエストとして扱われることができる。更に、GMLCショートサーキット及び/又はMO−LRショートサーキットを使用することについてのどんな合意も、UE120にMSC/SGSN140によって送られたリスト中のPLMNsのすべてに適用可能であり得る。
【0109】
さらに実施形態においては、UE120、MSC/SGSN140、V―GMLC150a、H−GMLC150b、およびR−GMLC150cの中のどのエンティティも、GLMCショートサーキットを使用するべきかどうかを、また、MO−LRショートサーキットを使用するべきかどうかを、自主的に決定することができる。
【0110】
図2AにおけるMT−LRメッセージフロー200の場合、R−GMLC150cは、LCSサービスリクエストメッセージをH−GMLC150bに送ることができ、それは、LCSサービスリクエストメッセージをV−GMLC150aに送ることができ、それは、定期的位置報告についてリクエストするために、加入者位置提供せよメッセージ(Provide Subscriber Location message)を、MSC/SGSN140に送ることができる。各エンティティによって送られるメッセージは、(1)もしGMLCショートサーキットが好まれる場合は、R−GMLC150cのアドレス、および(2)MO−LRショートサーキットが認められるのかあるいは好まれるのかどうかについての表示、を含むことができる。一実施形態においては、R−GMLC150c、H−GMLC150b、V−GMLC150a、およびMSC/SGSN140は、各々、GMLCショートサーキットを受理あるいは拒否することができ、また、各々、MO−LRショートサーキットを受理あるいは拒否することができる。
【0111】
図3におけるMO−LRメッセージフロー300の場合、UE120は、メッセージフロー300のステップ4においてMSC/SGSN140に送られるLCS MO−LR位置サービス呼び出しメッセージの中に、(1)GMLCショートサーキット使用のリクエスト、及び/又は(2)MO−LRショートサーキット使用のリクエスト(例えば、UE120がUEベースのモードをサポートする場合)を含むことができる。別の実施形態においては、MSC/SGSN140は、UE120からの表示なしに、1つあるいは両方のリクエストをそれ自体決定することができる。いずれの場合も、ショートサーキットリクエスト(1つあるいは両方)は、V−GMLC150aに、次にH−GMLC150bに、次にR−GMLC150cに、そして次にLCSクライアント170に、送られることができる。LCSクライアント170は、UEリクエスト(単数または複数)についてのレスポンスを、R−GMLC150cに送り、それはそのレスポンスを、H−GMLC150bに送り、それはそのレスポンスを、V−GMLC150aに送り、それはそのレスポンスをMSC/SGSN140に送る。各エンティティによって送られるレスポンスは、前のエンティティから受け取られるレスポンスを組み込み(もしあれば)、そして、定期的位置リクエストの受理あるいは拒否、および、各ショートサーキットリクエストの受理あるいは拒否を示すことができる(もし送られれば)。
【0112】
MT−LRメッセージフロー200とMO−LRメッセージフロー300の両方の場合、MSC/SGSN140は、(上記にリストされた情報に加えて)次の情報を受け取ることができる:
1.UE120が、RAN130においての確認無しに、MSC/SGSN140に位置推定値を直接に提供することを承認されるかどうか、あるいは予想されるかどうか、を示すMO−LRショートサーキット表示、
2.位置推定値がR−GMLC150cに、直接に送られることができるかどうか、あるいは直接に送られるであろうかどうか、を示すGMLCショートサーキット表示、
3.例えば、もしGMLCショートサーキットがリクエストされていないかあるいは拒否される場合、H−GMLC150bに位置情報を送るために使用されるべきH−GMLC150bのアドレス、
4.例えば、もしGMLCショートサーキットが受理される場合、MSC/SGSN140からR−GMLC150cに直接に位置情報を送るために使用されるべきR−GMLC150cのアドレス。
【0113】
もしMO−LRショートサーキットが許可される場合、そのときUE120は、MSC/SGSN140に送られるLCS MO−LR位置サービス呼び出しメッセージにおいて、UEで利用可能な位置推定値を含むことができる。RAN130あるいはSAS132は、UE120についての位置推定値を計算する必要がないであろう。
【0114】
もしGMLCショートサーキットが受理される場合、そのときMSC/SGSN140は、R−GMLC150cのアドレスを保存することができる、あるいは、UE120は、各位置報告エベントにおいてR−GMLCアドレスを送ることができる。MSC/SGSN140は、そのあと、各位置推定値を、R−GMLCアドレスを使用してR−GMLC150c直接に送ることができ、また、V−GMLC150aおよびH−GMLC150bをバイパスすることができる。
【0115】
明確にするために、図2から10までの中のメッセージフローの各々は、特定のシーケンスのステップを示す。各メッセージフローは、そのメッセージフローのために示されたステップに追加のステップ、示されたステップよりも少ないステップ、あるいは、示されたステップとは異なるステップ、を含んでいてもよい。各メッセージフローのステップは、そのメッセージフローにおいて示された順序で、あるいは異なる順序で、実行されることができる。各メッセージフローの各ステップは、一般に、任意の数のメッセージ交換、任意のエンティティでの任意のタイプの処理、などを、含むことができる。
【0116】
同様に明確にするために、3GPPによって使用される(あるいは、3GPPに適用可能な)特定のメッセージが、図2から10までの中のメッセージフローのために示されている。他のネットワークおよび他の位置アーキテクチャは、典型的に、上記に説明されたメッセージとは異なるメッセージを使用する。一般に、任意のシグナリングが、位置報告のために上記に説明された機能性を達成するために様々なエンティティの間で関連情報を交換するために使用されることができる。シグナリングは、他のある形式で送信されるメッセージ、パケット、表示、フラグあるいはデータを備えることができる。
【0117】
明確にするために、位置サービスをサポートするコントロールプレーン(control plane)を利用する、3GPPベースのネットワークのための技術が、特に上記に説明されている。技術はまた、他のネットワークおよび他の位置アーキテクチャ、例えば、オープンモバイルアライアンス(Open Mobile Alliance)(OMA)によって広められたプリSUPLアーキテクチャ(pre-SUPL architecture)およびSUPLアーキテクチャおよび、IS−881および3GPP2 X.S0002において記述された3GPP2コントロールプレーンアーキテクチャ、X.S0024において記述された3GPP2ユーザプレーンアーキテクチャ、などのために使用されることができる。コントロールプレーン(それはまた一般にシグナリングプレーン(signaling plane)と呼ばれる)は、上位層のアプリケーションのためのシグナリングを搬送するためのメカニズムであり、ネットワークに特有のプロトコルおよびシグナリングメッセージを用いて実施されることができる。ユーザプレーン(user plane)は、上位層のアプリケーションのためのデータを搬送するためのメカニズムであり、ユーザプレーンベアラ(user-plane bearer)を使用し、それは、当技術分野においてよく知られているユーザデータグラムプロトコル(UDP)、転送制御プロトコル(TCP)、およびインターネットプロトコル(IP)、のようなプロトコルを用いて典型的に実施される。位置サービスおよびポジショニングをサポートするメッセージは、コントロールプレーンアーキテクチャにおけるシグナリングの一部として、また、ユーザプレーンアーキテクチャにおけるデータの一部として搬送される。然しながら、メッセージのコンテンツは、両方のアーキテクチャにおいて似ているかもしれないし、あるいは、同一でさえあるかもしれない。メッセージが異なるかもしれないが、ショートサーキット技術はまた、回路交換(CS)ベースのモードおよびパケット交換(PS)ベースのモードのために使用されることができる。
【0118】
図11は、訪問先/サービングネットワーク(visited/serving network)1102、ホームネットワーク(home network)1104、およびリクエストティングネットワーク(requesting network)1106を含んでいるSUPL展開1100(SUPL deployment)を示す。訪問先ネットワーク1102は、無線ネットワーク1130およびビジティングSUPL位置プラットフォーム(visiting SUPL location platform)(V−SLP)1150aを含んでいる。無線ネットワーク1130は、無線ネットワークのサービスエリア内に位置する無線デバイスに無線通信を提供する。無線デバイスはまた、SUPL使用可能端末(SUPL enabled terminal)(SET))と呼ばれる。V−SLP1150aは、SUPL位置センタ(SUPL location center)(SLC)1180を含んでおり、また、SUPLポジショニングセンタ(SUPL positioning center)(SPC)1182を含むことができる。SLC1180は、V−GMLC150aに似ており、そして、位置サービスのための様々な機能を実行する。SPC1182は、SMLC/SAS132に似ており、無線デバイスについてのポジショニングをサポートする。ホームネットワーク1104は、ホームネットワーク1104についてのポジショニングおよび位置サービスをサポートするホームSLP(H−SLP)1150bを含んでいる。リクエスティングネットワーク1106は、LCSクライアントについてのポジショニングおよび位置サービスをサポートするリクエスティングSLP(R−SLP)1150cを含んでいる。
【0119】
ここに説明された技術は、SUPL展開1100において使用されることができる。RANベースの定期的位置報告の場合、V−SLP1150aあるいはH−SLP1150bは、例えば、上記に説明されるように、無線デバイス1120についての定期的位置報告を調整し、そしてコントロールすることができる。この場合、RANは、特には関与しないであろう、そして、RANの役割は、V−SLP1150a及び/又はH−SLP1150bによって、かつ/または、これらのいずれかの中のSPCによって(例えば、SPC1182によって)、引き受けられるであろう。UE1120とV−SLP1150aあるいはH−SLP1150bとの間のメッセージインタラクション(message interaction)(例、RRC測定コントロールメッセージおよびRRC測定報告メッセージの転送)は、このとき、例えば、3GPPコントロールプレーンシグナリングを使用する代わりにOMAによって定義されるSUPLポジショニングプロトコルおよびTCP/IPを使用してメッセージ(例、RRCメッセージ)が異なって転送される、ということを除いて、図5および6におっけるUE120とRAN/SRNC130との間のこれらのメッセージの交換に似ているであろう。非プロキシーモードにおけるGMLCショートサーキットの場合、無線デバイス1120あるいはV−SLP1150aは、位置推定値を直接にR−SLP1150cに送ることができ、それはそのあと、位置推定値をLCSクライアント1170に送り、H−SLP1150bをそして恐らくV−SLP1150aをバイパスする。プロキシーモードにおけるサーキットの場合、無線デバイス1120は、位置推定値をH−SLP1150bに送ることができ、それはそのあと、位置推定値をR−SLP1150cに送り、それは更に、位置推定値をLCSクライアント1170に送り、V−SLP1150aとのインタラクションをバイパスする。
【0120】
図12は、図1における3GPPベースのネットワーク100の中の様々なネットワークエンティティおよびUE120のブロック図を示す。RAN130は、無線通信をネットワーク100に提供し、典型的には、少なくとも1つのRNCおよび複数の基地局あるいはノードBsを含んでいる。簡単にするために、1つのプロセッサ1230、1つのメモリユニット1232、1つのトランシーバ1234、および1つの通信ユニット1236のみが、RAN130について示されている。各RNCおよび各基地局は、典型的には、1つまたは複数のプロセッサ、メモリユニット、通信ユニットなどを含んでおり、また、各基地局は、典型的には、トランシーバ1234を含んでいる。同様に簡単にするために、1つのプロセッサ1220、1つのメモリユニット1222、および1つのトランシーバ1224のみが、UE120について示されている。UE120は、無線通信をサポートすることができ、そして、1つまたは複数の受信機、1つまたは複数のアンテナ、1つまたは複数のプロセッサなどを用いてGPS信号を処理することができる。
【0121】
ダウンリンク上で、RAN130の中の基地局は、トラフィックデータ、シグナリング、およびパイロットを、それらのサービスエリア内のUEsに送信する。これらの様々なタイプのデータは、アンテナを経由して送信されるダウンリンク信号を生成するために、プロセッサ1230によって処理され、またトランシーバ1234によって条件付けられる(conditioned)。UE120で、1つまたは複数の基地局からのダウンリンク信号が、アンテナを経由して受け取られ、トランシーバ1224によって条件付けられ、そして、位置サービスについて様々なタイプの情報を得るためにプロセッサ1220によって処理される。例えば、プロセッサ1220は、受信信号(これらはポジショニングのために使用されることができる)の到着の時間、上記に説明されたメッセージフローのために使用されるデコードされたメッセージ、などを得ることができる。メモリユニット1222および1232は、UE120およびRAN130で、プロセッサ1220および1230のためのプログラムコードおよびデータをそれぞれ保存する。アップリンク上で、UE120は、トラフィックデータ、シグナリング、およびパイロットを、RAN130の中の1つまたは複数の基地局に送信することができる。これらの様々なタイプのデータは、UEアンテナを経由して送信されるアップリンク信号を生成するために、プロセッサ1220によって処理され、またトランシーバ1224によって条件付けられる。RAN130で、UE120からのアップリンク信号および他のUEsは、トランシーバ1234によって受け取られ、また条件付けられ、そして、様々なタイプの情報(例、データ、シグナリング、報告など)を得るために、プロセッサ1230によってさらに処理される。通信(Comm)ユニット1236は、RAN130がSMLC/SAS132およびMSC/SGSN140と通信することを可能にする。
【0122】
MSC/SGSN140は、MSC/SGSN140のための処理を実行するプロセッサ1240、プロセッサ1240のためのプログラムコードおよびデータを保存するメモリユニット1242、および、MSC/SGSN140がRAN130、SMLC/SAS132、および他のネットワークエンティティとデータ/コアネットワーク1202を経由して通信することを可能にする通信ユニット1244、を含んでいる。SMLC/SAS132は、SMLC/SAS132のための処理を実行するプロセッサ1250、プロセッサ1250のためのプログラムコードおよびデータを保存するメモリユニット1252、およびSMLC/SAS132が、RAN130およびMSC/SGSN140と通信することを可能にする通信ユニット1254、を含んでいる。一般に、各ネットワークエンティティは、1つまたは複数のプロセッサ、メモリユニット、通信ユニット、コントローラなどを含むことができる。データ/コアネットワーク1202は、コアネットワーク、及び/又は、他のプライベート(private)/パブリック(public)のデータネットワーク含んでもよい。
【0123】
ここに説明された技術は、様々な手段によって実施されることができる。例えば、本技術は、ハードウェア、ファームウェア、ソフトウェア、あるいはそれの組合せにおいて実施されることができる。ハードウェアインプリメンテーションの場合、各エンティティで処理を実行するために使用されるユニットは、1つまたは複数の特定用途向け集積回路(ASICs)、デジタル信号プロセッサ(DSPs)、デジタル信号処理デバイス(DSPDs)、プログラマブル論理デバイス(PLDs)、フィールドプログラマブルゲートアレイ(FPGAs)、プロセッサ、コントローラ、マイクロコントローラ、マイクロプロセッサ、電子デバイス、ここに説明された機能(function)を実行するように設計された他の電子ユニット、あるいはそれらの組合せの中で、インプリメントされることができる。
【0124】
ソフトウェアインプリメンテーションの場合、本技術は、ここに説明された機能を実行するモジュール(例、プロシージャ、関数、など)を用いてインプリメントされてもよい。ソフトウェアコードは、メモリユニット(例、図12の中のメモリユニット1222、1232、1242、あるいは1252)の中に保存され、プロセッサ(例、プロセッサ1220、1230、1240、あるいは1250)によって実行されることができる。メモリユニットは、プロセッサ内で、あるいはプロセッサの外部でインプリメントされることができる。
【0125】
開示された実施形態の以上の説明は、当業者の誰もが本発明を作りまたは使用するのを可能とするように提供されている。これらの実施形態の様々の修正は、当業者には容易に明らかであろう、そして、ここに定義された包括的な原理は本発明の精神或いは範囲を逸脱することなく他の実施形態に適用されることができる。従って、本発明は、ここに示された実施形態に限定されるように意図されてはおらず、ここに開示された原理及び新規な特徴と整合する最も広い範囲が与えられるべきものである。

【特許請求の範囲】
【請求項1】
クライアントエンティティへのユーザ機器(UE)の位置の定期的報告を開始するように、無線アクセスネットワーク(RAN)にシグナリングを送ることと、なおここでは、前記RANに送られる前記シグナリングは、前記UEについての位置推定値をいつ前記クライアントエンティティに送るのかを示す定期的位置情報を含んでおり、また、ここでは、前記RANは、前記クライアントエンティティへのUE位置の前記定期的報告を調整しコントロールする;
前記定期的位置情報によって示される各位置報告について、
前記RANから、前記UEについての位置推定値を受け取ることと、
前記UEについての前記位置推定値を前記クライアントエンティティへ向けて送ることと;
を備える、位置サービスを提供する方法。
【請求項2】
前記クライアントエンティティへの前記UE位置の定期的報告のために、前記クライアントエンティティによって送られたリクエストを受け取ることと;
前記リクエストを前記UEに転送することと;
を更に備える、請求項1記載の方法。
【請求項3】
前記クライアントエンティティへの前記UE位置の定期的報告のために、前記クライアントエンティティからリクエストを直接に受け取ることと;
前記リクエストを前記UEに転送することと:
を更に備える、請求項1記載の方法。
【請求項4】
前記クライアントエンティティへの前記UE位置の定期的報告のリクエストをUEから受け取ること;
前記リクエストを前記クライアントエンティティに向けて転送することと:
を更に備える、請求項1記載の方法。
【請求項5】
前記RANは第1の位置センタに関連付けられており、また、前記UEについての前記位置推定値を前記クライアントエンティティに向けて前記送ることは、前記UEについての前記位置推定値を第2の位置センタに直接に送ることと、前記第1の位置センタをバイパスすることと、を備えており、また、前記第2の位置センタは前記クライアントエンティティに関連付けられており、また、前記第1および第2の位置センタは、異なるネットワークに関連付けられている、請求項1記載の方法。
【請求項6】
前記UEについての前記位置推定値を前記第2の位置センタに直接に前記送ることは、前記UEについての前記位置推定値を前記第2の位置センタに直接に送ることと、前記第1の位置センタと第3の位置センタとをバイパスすることと、を備えており、前記第3の位置センタは、前記UEのホームネットワークに関連付けられている、請求項5記載の方法。
【請求項7】
前記第2の位置センタのアドレスを保存することを、更に備える、請求項5記載の方法。
【請求項8】
各位置報告の後に、前記UEに対して、前の位置報告の結果を伝えるように、前記定期的報告のキャンセルを可能とするように、あるいはそれらの組合せのために、シグナリングを送ること、
を更に備える、請求項1記載の方法。
【請求項9】
各位置報告に先立って、前記UEに対して、前の位置報告の結果を伝えるように、前記UEに現在の位置報告を知らせるように、前記定期的報告のキャンセルを可能とするように、あるいはそれらの組合せのために、シグナリングを送ること、
を更に備える、請求項1記載の方法。
【請求項10】
前記定期的報告の完了後に、前記UEに対して、前記定期的報告の完了を示すように、前記定期的報告の結果を伝えるように、あるいはそれらの組合せのために、シグナリングを送ること、
を更に備える、請求項1記載の方法。
【請求項11】
前記UEについての前記位置推定値を前記クライアントエンティティに向けて前記送ることは、前記UEについての前記位置推定値を前記クライアントエンティティに関連する位置センタに送ることを備えており、前記クライアントエンティティは前記UEの外側にある、請求項1記載の方法。
【請求項12】
前記UEについての前記位置推定値を前記クライアントエンティティに向けて前記送ることは、前記UEについての前記位置推定値を前記UEに送ることを備えており、前記クライアントエンティティは前記UEにある、請求項1記載の方法。
【請求項13】
ネットワークエンティティと無線アクセスネットワーク(RAN)との間で、および、前記ネットワークエンティティと位置センタとの間で、シグナリングの交換を容易にするように動作する通信ユニットと;
クライアントエンティティへのユーザ機器(UE)の位置の定期的報告を開始するように前記RANに、シグナリングを送るように、そして、各位置報告について、前記UEについての位置推定値を前記RANから受け取るように、また、前記UEについての前記位置推定値を前記位置センタに送るように、動作するプロセッサと、なおここでは、前記RANに送られる前記シグナリングは、前記UEについての位置推定値をいつ前記クライアントエンティティに送るのかを示す定期的位置情報を含んでおり、また、ここでは、前記RANは、前記クライアントエンティティへのUE位置の前記定期的報告を調整しコントロールする;
を備える装置。
【請求項14】
前記位置センタは前記クライアントエンティティに関連付けられており、前記RANは別の位置センタに関連付けられており、前記プロセッサは、前記UEについての前記位置推定値を前記クライエントエンティティに関連する前記位置センタに直接に送るように、また、前記RANに関連する前記位置センタをバイパスするように、動作する、請求項13記載の装置。
【請求項15】
前記プロセッサは、各位置報告に先立ってあるいは各位置報告の後に、前記UEに対して、前の位置報告の結果を伝えるように、前記UEに現在のあるいは次の位置報告を知らせるように、前記現在のあるいは次の位置報告の拒否を可能とするように、前記定期的報告のキャンセルを可能とするように、あるいはそれらの組合せのために、シグナリングを送るよう動作する、請求項13記載の装置。
【請求項16】
前記プロセッサは、前記定期的報告の完了後に、前記UEに対して、前記定期的報告の完了を示すように、前記定期的報告の結果を伝えるように、あるいはそれらの組合せのために、シグナリングを送るよう動作する、請求項13記載の装置。
【請求項17】
クライアントエンティティへのユーザ機器(UE)の位置の定期的報告を開始するように、無線アクセスネットワーク(RAN)にシグナリングを送るための手段と、なおここでは、前記RANに送られる前記シグナリングは、前記UEについての位置推定値をいつ前記クライアントエンティティに送るのかを示す定期的位置情報を含んでおり、また、ここでは、前記RANは、前記クライアントエンティティへのUE位置の前記定期的報告を調整しコントロールする;
前記RANから、前記UEについての位置推定値を受け取るための手段と、
前記UEについての前記位置推定値を前記クライアントエンティティに向けて送るための手段と、
を備える、前記定期的位置情報によって示される各位置報告を処理するための手段と;
を備える装置。
【請求項18】
前記RANは第1の位置センタに関連付けられており、また、前記UEについての前記位置推定値を前記クライアントエンティティに向けて送るための前記手段は、前記UEについての前記位置推定値を第2の位置センタに直接に送り、そして前記第1の位置センタをバイパスするための、手段を備えており、また、前記第2の位置センタは前記クライアントエンティティに関連付けられており、また、前記第1および第2の位置センタは、異なるネットワークに関連付けられている、請求項17記載の装置。
【請求項19】
各位置報告に先立ってあるいは各位置報告の後に、前記UEに対して、前の位置報告の結果を伝えるように、前記UEに現在のあるいは次の位置報告を知らせるように、前記現在のあるいは次の位置報告の拒否を可能とするように、前記定期的報告のキャンセルを可能とするように、あるいはそれらの組合せのために、シグナリングを送るための手段を、
更に備える、請求項17記載の装置。
【請求項20】
前記定期的報告の完了後に、前記UEに対して、前記定期的報告の完了を示すように、前記定期的報告の結果を伝えるように、あるいはそれらの組合せのために、シグナリングを送るための手段を、
更に備える、請求項17記載の装置。
【請求項21】
クライアントエンティティへのユーザ機器(UE)の位置の定期的報告を開始するように、ネットワークエンティティによって送られるシグナリングを、無線アクセスネットワーク(RAN)で受け取ることと、なおここでは、前記ネットワークエンティティから受け取られる前記シグナリングは、前記UEについての位置推定値をいつ前記クライアントエンティティに送るのかを示す定期的位置情報を含んでいる;
前記クライアントエンティティへのUE位置の前記定期的報告を調整しコントロールすることと;
前記定期的位置情報によって示される各位置報告について、
前記UEからのあるいは前記UEに関しての位置情報を受け取ることと、
必要であれば、前記UEについての位置推定値を得るために前記位置情報に基づいてポジショニングを実行することと、
前記UEについての前記位置推定値を前記ネットワークエンティティに送ることと;
を備える、位置サービスを提供する方法。
【請求項22】
前記定期的位置情報は、位置報告の設定回数と、連続する位置報告間の時間間隔とを示す、請求項21記載の方法。
【請求項23】
前記UEに前記定期的位置情報を送ること、
を更に備える請求項21記載の方法。
【請求項24】
前記位置情報は、前記UE、または前記RAN、または前記UEと前記RANの両方によって得られる測定値を備えており、また、前記の、必要であれば、前記UEについての位置推定値を得るために前記位置情報に基づいてポジショニングを実行することは、
ポジショニングエンティティに前記測定値を送ることと、
前記ポジショニングエンティティから前記UEについての前記位置推定値を受け取ることと;
を備えている、
請求項21記載の方法。
【請求項25】
前記定期的報告の調整およびコントロールを前記ポジショニングエンティティに渡すために、シグナリングをポジショニングエンティティと交換すること、
を更に備える請求項21記載の方法。
【請求項26】
前記の、必要であれば、前記UEについての前記位置推定値を得るために前記位置情報に基づいてポジショニングを実行することは、
前記位置情報を前記ポジショニングエンティティに転送することと、
前記ポジショニングエンティティから、前記UEについての前記位置推定値を受け取ることと、
を備える、請求項25記載の方法。
【請求項27】
前記UEについての前記位置推定値を導き出すために使用される測定値を測定して得るために、ポジショニングエンティティから支援データを受け取ることと;
前記支援データを前記UEに送ることと;
を更に備える請求項21記載の方法。
【請求項28】
無線アクセスネットワーク(RAN)とネットワークエンティティとの間でのシグナリングの交換を容易にするように動作する通信ユニットと;
前記RANとユーザ機器(UE)との間の通信を容易にするように動作するトランシーバと;
クライアントエンティティへの前記UEの位置の定期的報告を開始するために、前記ネットワークエンティティによって送られるシグナリングを受け取るように、前記クライアントエンティティへのUE位置の前記定期的報告を調整しコントロールするように、各位置報告について、前記UEからのあるいは前記UEに関しての位置情報を受け取るように、必要ならば、前記UEについての位置推定値を得るために前記位置情報に基づいてポジショニングを実行するように、また、前記UEについての前記位置推定値を前記ネットワークエンティティに送るように、動作するプロセッサと、なおここでは、前記ネットワークエンティティから受け取られる前記シグナリングは、前記クライアントエンティティに前記UEについての位置推定値をいつ送るのかを示す定期的位置情報を含んでいる;
装置。
【請求項29】
前記位置情報は、前記UE、または前記RAN、または前記UEと前記RANの両方によって得られる測定値を備えており、また、前記プロセッサは、ポジショニングエンティティに前記測定値を送るように、また、前記ポジショニングエンティティから前記UEについての前記位置推定値を受け取るように、動作する、請求項28記載の装置。
【請求項30】
前記定期的報告の調整およびコントロールを前記ポジショニングエンティティに渡すために、シグナリングをポジショニングエンティティと交換するように動作する、請求項28記載の装置。
【請求項31】
前記RANはユニバーサル地上無線アクセスネットワーク(UTRAN)であり、前記ネットワークエンティティは、モバイルサービス交換局(MSC)またはサービングGPRSサポートノード(SGSN)である、請求項28記載の装置。
【請求項32】
前記RANはGSM EDGE無線アクセスネットワーク(GERAN)であり、前記ネットワークエンティティは、モバイルサービス交換局(MSC)またはサービングGPRSサポートノード(SGSN)である、請求項28記載の装置。
【請求項33】
クライアントエンティティへのユーザ機器(UE)の位置の定期的報告を開始するように、ネットワークエンティティによって送られるシグナリングを、無線アクセスネットワーク(RAN)で受け取るための手段と、なおここでは、前記ネットワークエンティティから受け取られる前記シグナリングは、前記クライアントエンティティへの前記UEについての位置推定値をいつ送るのかを示す定期的位置情報を含んでいる;
前記クライアントエンティティへのUE位置の前記定期的報告を調整しコントロールするための手段と;
前記UEからのあるいは前記UEに関しての位置情報を受け取るための手段と、
必要であれば、前記UEについての位置推定値を得るために前記位置情報に基づいてポジショニングを実行するための手段と、
前記UEについての前記位置推定値を前記ネットワークエンティティに送るための手段と、
を備える、前記定期的位置情報によって示される各位置情報を処理するための手段と;
を備える装置。
【請求項34】
前記位置情報は、前記UE、または前記RAN、または前記UEと前記RANの両方によって得られる測定値を備えており、また、必要であれば、前記UEについての前記位置推定値を得るために前記位置情報に基づいてポジショニングを実行するための前記手段は、 ポジショニングエンティティに前記測定値を送るための手段と、
前記ポジショニングエンティティから前記UEについての前記位置推定値を受け取るための手段と、
を備えている、
請求項33記載の装置。
【請求項35】
前記定期的報告の調整およびコントロールを前記ポジショニングエンティティに渡すために、シグナリングをポジショニングエンティティと交換するための手段、
を更に備える請求項33記載の装置。
【請求項36】
クライアントエンティティへのユーザ機器(UE)の位置の定期的報告を開始するように、無線アクセスネットワーク(RAN)によって送られるシグナリングを、ポジショニングエンティティで受け取ることと、なおここでは、前記RANから受け取られる前記シグナリングは、前記UEについての位置推定値をいつ前記クライアントエンティティに送るのかを示す定期的位置情報を含んでいる;
前記クライアントエンティティへのUE位置の前記定期的報告を調整しコントロールすることと;
前記定期的位置情報によって示される各位置報告について、
前記UEによって送られるあるいは前記UEに関する位置情報を前記RANから受け取ることと、
必要であれば、前記UEについての位置推定値を得るためにポジショニングを実行することと、
前記UEについての前記位置推定値を前記RANに送ることと;
を備える、位置サービスを提供する方法。
【請求項37】
前記UEについての前記位置推定値を導き出すために使用される測定値を測定して得るために、前記RANに支援データを送ること、
を更に備える請求項36記載の方法。
【請求項38】
ポジショニングエンティティと無線アクセスネットワーク(RAN)との間でのシグナリングの交換を容易にするように動作する通信ユニットと;
クライアントエンティティへのユーザ機器(UE)の位置の定期的報告を開始するために、前記RANによって送られるシグナリングを受け取るように、前記クライアントエンティティへのUE位置の前記定期的報告を調整しコントロールするように、各位置報告について、前記UEによって送られるあるいは前記UEに関する位置情報を前記RANから受け取るように、必要ならば、前記UEについての位置推定値を得るためにポジショニングを実行するように、また、前記UEについての前記位置推定値を前記RANに送るように、動作するプロセッサと、なおここでは、前記RANから受け取られる前記シグナリングは、前記クライアントエンティティに前記UEについての位置推定値をいつ送るのかを示す定期的位置情報を含んでいる;
装置。
【請求項39】
前記UEについての前記位置推定値を導き出すために使用される測定値を前記UEにより測定して得るために、前記RANに支援データを送るように動作する、請求項38記載の装置。
【請求項40】
クライアントエンティティへのユーザ機器(UE)の位置の定期的報告を開始するように、無線アクセスネットワーク(RAN)によって送られるシグナリングを、ポジショニングエンティティで受け取るための手段と、なおここでは、前記RANから受け取られる前記シグナリングは、前記UEについての位置推定値をいつ前記クライアントエンティティに送るのかを示す定期的位置情報を含んでいる;
前記クライアントエンティティへのUE位置の前記定期的報告を調整しコントロールするための手段と;
前記UEによって送られるあるいは前記UEに関する位置情報を前記RANから受け取るための手段と、
必要であれば、前記UEについての位置推定値を得るためにポジショニングを実行するための手段と、
前記UEについての前記位置推定値を前記RANに送るための手段と、
を備える、前記定期的位置情報によって示される各位置情報を処理するための手段と; を備える装置。
【請求項41】
前記UEについての前記位置推定値を導き出すために使用される測定値を前記UEにより測定して得るために、前記RANに支援データを送るための手段、
を更に備える請求項40記載の装置。
【請求項42】
クライアントエンティティへのユーザ機器(UE)の位置の定期的報告を開始するように、無線アクセスネットワーク(RAN)によって送られるシグナリングを、前記UEで受け取ることと、なおここでは、前記RANから受け取られる前記シグナリングは、前記UEについての位置推定値をいつ前記クライアントエンティティに送るのかを示す定期的位置情報を含んでいる、またここでは、前記RANは、前記クライアントエンティティへのUE位置の前記定期的報告を調整しコントロールする;
前記定期的位置情報によって示される各位置報告について、位置情報を前記RANに送ることと、なおここでは、前記位置情報は、前記UEについての位置推定値、あるいは、前記UEについての前記位置推定値を導き出すために使用される測定値を備える;
を備える、位置サービスを得る方法。
【請求項43】
前記定期的位置情報は、位置報告の設定回数と、連続する位置報告間の時間間隔とを示す、請求項42記載の方法。
【請求項44】
前記定期的位置情報は、位置情報の報告をトリガする少なくとも1つの条件を示す、請求項42記載の方法。
【請求項45】
前記クライアントエンティティへの前記UE位置の定期的報告についての前記クライアントエンティティによって送られたリクエストを前記RAN経由で受け取ることと、
前記リクエストの許可または拒否を送ることと、
を更に備える請求項42記載の方法。
【請求項46】
前記クライアントエンティティへの前記UE位置の定期的報告についての前記クライアントエンティティによって送られたリクエストを前記RAN経由で受け取ること、を更に備え、
前記クライアントエンティティは、位置サービスをサポートするネットワークエンティティ内に存在するか、あるいは前記ネットワークエンティティに直接に結合されている、
請求項42記載の方法。
【請求項47】
前記クライアントエンティティへの前記UE位置の定期的報告のリクエストを送ることと、
前記リクエストに対する許可を受け取ることと、
を更に備える請求項42記載の方法。
【請求項48】
前記測定値を測定して得るために、支援データを前記RAN経由で受け取ることと、
各位置報告について前記測定値を測定して得るために前記支援データを使用することと、
を更に備える請求項42記載の方法。
【請求項49】
各位置報告について少なくとも1つの送信機のために測定値を測定して得ることと、なおここでは、各送信機は基地局または衛星である;
前記位置情報として前記測定値を提供することと;
を更に備える請求項42記載の方法。
【請求項50】
各位置報告について少なくとも1つの送信機のために測定値を測定して得ることと、なおここでは、各送信機は基地局または衛星である;
前記測定値に基づいて前記UEについての前記位置推定値を導き出すことと;
前記位置情報として前記位置推定値を提供することと;
を更に備える請求項42記載の方法。
【請求項51】
前記位置情報は、前記UEについての前記位置推定値を導き出すために使用される測定値を備えており、前記方法は、
各位置報告について前記UEについての前記位置推定値を前記RAN経由で受け取ること、
を更に備える、
請求項42記載の方法。
【請求項52】
ユーザ機器(UE)と無線アクセスネットワーク(RAN)との間の通信を容易にするように動作するトランシーバと;
クライアントエンティティへの前記UEの位置の定期的報告を開始するように、前記RANによって送られるシグナリングを受け取るように、前記RANから受け取られた前記シグナリング中に含まれる定期的位置情報に基づいて、前記UEについての位置推定値をいつ前記クライアントエンティティに送るのかを決定するように、前記UEについての位置推定値、あるいは、位置情報として前記位置推定値を導き出すために使用される測定値を提供するように、また、前記RANに前記位置情報を送るように、動作するプロセッサと、なおここでは、前記RANは、前記クライアントエンティティへのUE位置の前記定期的報告を調整しコントロールする;
を備える装置。
【請求項53】
前記プロセッサは、各位置報告について、少なくとも1つの送信機のための測定値を得るように、かつ、前記位置情報として前記測定値を提供するように、動作し、またここでは、各送信機は、基地局かまたは衛星である、請求項52記載の装置。
【請求項54】
前記プロセッサは、各位置報告について、少なくとも1つの送信機のための測定値を得るように、前記測定値に基づいて前記UEについての前記位置推定値を導き出すように、また、前記位置情報として前記位置測定値を提供するように、動作し、またここでは、各送信機は、基地局かまたは衛星である、請求項52記載の装置。
【請求項55】
前記シグナリングは、モバイルサービス交換局(MSC)またはサービングGPRSサポートノード(SGSN)によって出される、請求項52記載の装置。
【請求項56】
クライアントエンティティへのユーザ機器(UE)の位置の定期的報告を開始するように、無線アクセスネットワーク(RAN)によって送られるシグナリングを、前記UEで受け取るための手段と、なおここでは、前記RANから受け取られる前記シグナリングは、前記UEについての位置推定値をいつ前記クライアントエンティティに送るのかを示す定期的位置情報を含んでいる、またここでは、前記RANは、前記クライアントエンティティへのUE位置の前記定期的報告を調整しコントロールする;
前記定期的位置情報によって示される各位置報告について、位置情報を前記RANに送るための手段と、なおここでは、前記位置情報は、前記UEについての位置推定値、あるいは、前記UEについての前記位置推定値を導き出すために使用される測定値を備える;
を備える装置。
【請求項57】
各位置報告について少なくとも1つの送信機のために測定値を測定して得るための手段と、なおここでは、各送信機は基地局または衛星である;
前記位置情報として前記測定値を提供するための手段と;
を更に備える請求項56記載の装置。
【請求項58】
各位置報告について少なくとも1つの送信機のために測定値を測定して得るための手段と、なおここでは、各送信機は基地局または衛星である;
前記測定値に基づいて前記UEについての前記位置推定値を導き出すための手段と; 前記位置情報として前記位置推定値を提供するための手段と;
を更に備える請求項56記載の装置。

【図1A】
image rotate

【図1B】
image rotate

【図2A】
image rotate

【図2B】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate

【図10】
image rotate

【図11】
image rotate

【図12】
image rotate


【公開番号】特開2011−250429(P2011−250429A)
【公開日】平成23年12月8日(2011.12.8)
【国際特許分類】
【外国語出願】
【出願番号】特願2011−138291(P2011−138291)
【出願日】平成23年6月22日(2011.6.22)
【分割の表示】特願2008−518393(P2008−518393)の分割
【原出願日】平成18年6月21日(2006.6.21)
【出願人】(595020643)クゥアルコム・インコーポレイテッド (7,166)
【氏名又は名称原語表記】QUALCOMM INCORPORATED
【Fターム(参考)】