(57)【要約】【課題】無線アクセスネットワークにおける効率的な定期的位置報告。【解決手段】無線アクセスネットワーク（ＲＡＮ）と通信するユーザ機器（ＵＥ）は、ネットワークエンティティ（例、ＭＳＣ／ＳＧＳＮ）に対し、クライアントエンティティへのＵＥ位置の定期的報告のリクエストを送る。リクエストが承認された後、ＭＳＣ／ＳＧＳＮは、ＵＥについての定期的位置報告を開始するために、ＲＡＮにシグナリングを送る。ＲＡＮは、ポジショニングセンタ（例、ＳＡＳ）に対して、支援データをＵＥに送るように、リクエストすることができる。ＲＡＮは定期的位置報告を調整しコントロールしてもよいし、あるいはポジショニングセンタにコントロールを渡してもよい。各位置報告について、ＵＥは、位置情報（例えば、ＵＥによって測定された測定値、あるいは、ＵＥによって計算された位置推定値）をＲＡＮに送る。ＵＥが測定値を送る場合は、ＳＡＳは位置推定値を計算する。ＲＡＮは、そのあと、ＵＥについての位置推定値をＭＳＣ／ＳＧＳＮに送り、それは、クライアントエンティティに向けて位置推定値を転送する。【選択図】      図２Ａ
2009513036.tif 000002
【特許請求の範囲】
【請求項１】
クライアントエンティティへのユーザ機器（ＵＥ）の位置の定期的報告を開始するように、無線アクセスネットワーク（ＲＡＮ）にシグナリングを送ることと、なおここでは、前記ＲＡＮに送られる前記シグナリングは、前記クライアントエンティティへの前記ＵＥについての位置推定値をいつ送るのかを示す定期的位置情報を含んでおり、また、ここでは、前記ＲＡＮは、前記クライアントエンティティへのＵＥ位置の前記定期的報告を調整しコントロールする；
前記定期的位置情報によって示される各位置報告について、
前記ＲＡＮから、前記ＵＥについての位置推定値を受け取ることと、
前記ＵＥについての前記位置推定値を前記クライアントエンティティへ向けて送ることと；
を備える、位置サービスを提供する方法。
【請求項２】
前記クライアントエンティティへの前記ＵＥ位置の定期的報告のために、前記クライアントエンティティによって送られたリクエストを受け取ることと；
前記リクエストを前記ＵＥに転送することと；
を更に備える、請求項１記載の方法。
【請求項３】
前記クライアントエンティティへの前記ＵＥ位置の定期的報告のために、前記クライアントエンティティからリクエストを直接に受け取ることと；
前記リクエストを前記ＵＥに転送することと：
を更に備える、請求項１記載の方法。
【請求項４】
前記ライアントエンティティへの前記ＵＥ位置の定期的報告のリクエストをＵＥから受け取ること；
前記リクエストを前記クライアントエンティティに向けて転送することと：
を更に備える、請求項１記載の方法。
【請求項５】
前記ＲＡＮは第１の位置センタに関連付けられており、また、前記の、前記ＵＥについての前記位置推定値を前記クライアントエンティティに向けて送ることは、前記ＵＥについての前記位置推定値を第２の位置センタに直接に送ることと、前記第１の位置センタをバイパスすることと、を備えており、また、前記第２の位置センタは前記クライアントエンティティに関連付けられており、また、前記第１および第２の位置センタは、異なるネットワークに関連付けられている、請求項１記載の方法。
【請求項６】
前記の、前記ＵＥについての前記位置推定値を前記第２の位置センタに直接に送ることは、前記ＵＥについての前記位置推定値を前記第２の位置センタに直接に送ることと、前記第１の位置センタと第３の位置センタとをバイパスすることと、を備えており、前記第３の位置センタは、前記ＵＥのホームネットワークに関連付けられている、請求項５記載の方法。
【請求項７】
前記第２の位置センタのアドレスを保存することを、更に備える、請求項５記載の方法。
【請求項８】
各位置報告の後に、前記ＵＥに対して、前の位置報告の結果を伝えるように、前記定期的報告のキャンセルを可能とするように、あるいはそれらの組合せのために、シグナリングを送ること、
を更に備える、請求項１記載の方法。
【請求項９】
各位置報告に先立って、前記ＵＥに対して、前の位置報告の結果を伝えるように、前記ＵＥに現在の位置報告を知らせるように、前記定期的報告のキャンセルを可能とするように、あるいはそれらの組合せのために、シグナリングを送ること、
を更に備える、請求項１記載の方法。
【請求項１０】
前記定期的報告の完了後に、前記ＵＥに対して、前記定期的報告の完了を示すように、前記定期的報告の結果を伝えるように、あるいはそれらの組合せのために、シグナリングを送ること、
を更に備える、請求項１記載の方法。
【請求項１１】
前記の、前記ＵＥについての前記位置推定値を前記クライアントエンティティに向けて送ることは、前記ＵＥについての前記位置推定値を前記クライアントエンティティに関連する位置センタに送ることを備えており、前記クライアントエンティティは前記ＵＥの外側にある、請求項１記載の方法。
【請求項１２】
前記の、前記ＵＥについての前記位置推定値を前記クライアントエンティティに向けて送ることは、前記ＵＥについての前記位置推定値を前記ＵＥに送ることを備えており、前記クライアントエンティティは前記ＵＥにある、請求項１記載の方法。
【請求項１３】
ネットワークエンティティと無線アクセスネットワーク（ＲＡＮ）との間で、および、前記ネットワークエンティティと位置センタとの間で、シグナリングの交換を容易にするように動作する通信ユニットと；
クライアントエンティティへのユーザ機器（ＵＥ）の位置の定期的報告を開始するように前記ＲＡＮに、シグナリングを送るように、そして、各位置報告について、前記ＵＥについての位置推定値を前記ＲＡＮから受け取るように、また、前記ＵＥについての前記位置推定値を前記位置センタに送るように、動作するプロセッサと、なおここでは、前記ＲＡＮに送られる前記シグナリングは、前記クライアントエンティティへの前記ＵＥについての位置推定値をいつ送るのかを示す定期的位置情報を含んでおり、また、ここでは、前記ＲＡＮは、前記クライアントエンティティへのＵＥ位置の前記定期的報告を調整しコントロールする；
を備える装置。
【請求項１４】
前記位置センタは前記クライアントエンティティに関連付けられており、前記ＲＡＮは別の位置センタに関連付けられており、前記プロセッサは、前記ＵＥについての前記位置推定値を前記クライエントエンティティに関連する前記位置センタに直接に送るように、また、前記ＲＡＮに関連する前記位置センタをバイパスするように、動作する、請求項１３記載の装置。
【請求項１５】
前記プロセッサは、各位置報告に先立ってあるいは各位置報告の後に、前記ＵＥに対して、前の位置報告の結果を伝えるように、前記ＵＥに現在のあるいは次の位置報告を知らせるように、前記現在のあるいは次の位置報告の拒否を可能とするように、前記定期的報告のキャンセルを可能とするように、あるいはそれらの組合せのために、シグナリングを送るよう動作する、請求項１３記載の装置。
【請求項１６】
前記プロセッサは、前記定期的報告の完了後に、前記ＵＥに対して、前記定期的報告の完了を示すように、前記定期的報告の結果を伝えるように、あるいはそれらの組合せのために、シグナリングを送るよう動作する、請求項１３記載の装置。
【請求項１７】
クライアントエンティティへのユーザ機器（ＵＥ）の位置の定期的報告を開始するように、無線アクセスネットワーク（ＲＡＮ）にシグナリングを送るための手段と、なおここでは、前記ＲＡＮに送られる前記シグナリングは、前記クライアントエンティティへの前記ＵＥについての位置推定値をいつ送るのかを示す定期的位置情報を含んでおり、また、ここでは、前記ＲＡＮは、前記クライアントエンティティへのＵＥ位置の前記定期的報告を調整しコントロールする；
前記ＲＡＮから、前記ＵＥについての位置推定値を受け取るための手段と、
前記ＵＥについての前記位置推定値を前記クライアントエンティティに向けて送るための手段と、
を備える、前記定期的位置情報によって示される各位置報告を処理するための手段と；
を備える装置。
【請求項１８】
前記ＲＡＮは第１の位置センタに関連付けられており、また、前記ＵＥについての前記位置推定値を前記クライアントエンティティに向けて送るための前記手段は、前記ＵＥについての前記位置推定値を第２の位置センタに直接に送り、そして前記第１の位置センタをバイパスするための、手段を備えており、また、前記第２の位置センタは前記クライアントエンティティに関連付けられており、また、前記第１および第２の位置センタは、異なるネットワークに関連付けられている、請求項１７記載の装置。
【請求項１９】
各位置報告に先立ってあるいは各位置報告の後に、前記ＵＥに対して、前の位置報告の結果を伝えるように、前記ＵＥに現在のあるいは次の位置報告を知らせるように、前記現在のあるいは次の位置報告の拒否を可能とするように、前記定期的報告のキャンセルを可能とするように、あるいはそれらの組合せのために、シグナリングを送るための手段を、
更に備える、請求項１７記載の装置。
【請求項２０】
前記定期的報告の完了後に、前記ＵＥに対して、前記定期的報告の完了を示すように、前記定期的報告の結果を伝えるように、あるいはそれらの組合せのために、シグナリングを送るための手段を、
更に備える、請求項１７記載の装置。
【請求項２１】
クライアントエンティティへのユーザ機器（ＵＥ）の位置の定期的報告を開始するように、ネットワークエンティティによって送られるシグナリングを、無線アクセスネットワーク（ＲＡＮ）で受け取ることと、なおここでは、前記ネットワークエンティティから受け取られる前記シグナリングは、前記クライアントエンティティへの前記ＵＥについての位置推定値をいつ送るのかを示す定期的位置情報を含んでいる；
前記クライアントエンティティへのＵＥ位置の前記定期的報告を調整しコントロールすることと；
前記定期的位置情報によって示される各位置報告について、
前記ＵＥからのあるいは前記ＵＥに関しての位置情報を受け取ることと、
必要であれば、前記ＵＥについての位置推定値を得るために前記位置情報に基づいてポジショニングを実行することと、
前記ＵＥについての前記位置推定値を前記ネットワークエンティティに送ることと；
を備える、位置サービスを提供する方法。
【請求項２２】
前記定期的位置情報は、位置報告の設定回数と、連続する位置報告間の時間間隔とを示す、請求項２１記載の方法。
【請求項２３】
前記ＵＥに前記定期的位置情報を送ること、
を更に備える請求項２１記載の方法。
【請求項２４】
前記位置情報は、前記ＵＥ、または前記ＲＡＮ、または前記ＵＥと前記ＲＡＮの両方によって得られる測定値を備えており、また、前記の、必要であれば、前記ＵＥについての位置推定値を得るために前記位置情報に基づいてポジショニングを実行することは、
ポジショニングエンティティに前記測定値を送ることと、
前記ポジショニングエンティティから前記ＵＥについての前記位置推定値を受け取ることと；
を備えている、
請求項２１記載の方法。
【請求項２５】
前記定期的報告の調整およびコントロールを前記ポジショニングエンティティに渡すために、シグナリングをポジショニングエンティティと交換すること、
を更に備える請求項２１記載の方法。
【請求項２６】
前記の、必要であれば、前記ＵＥについての前記位置推定値を得るために前記位置情報に基づいてポジショニングを実行することは、
前記位置情報を前記ポジショニングエンティティに転送することと、
前記ポジショニングエンティティから、前記ＵＥについての前記位置推定値を受け取ることと、
を備える、請求項２５記載の方法。
【請求項２７】
前記ＵＥについての前記位置推定値を導き出すために使用される測定値を測定して得るために、ポジショニングエンティティから支援データを受け取ることと；
前記支援データを前記ＵＥに送ることと；
を更に備える請求項２１記載の方法。
【請求項２８】
無線アクセスネットワーク（ＲＡＮ）とネットワークエンティティとの間でのシグナリングの交換を容易にするように動作する通信ユニットと；
前記ＲＡＮとユーザ機器（ＵＥ）との間の通信を容易にするように動作するトランシーバと；
クライアントエンティティへの前記ＵＥの位置の定期的報告を開始するために、前記ネットワークエンティティによって送られるシグナリングを受け取るように、前記クライアントエンティティへのＵＥ位置の前記定期的報告を調整しコントロールするように、各位置報告について、前記ＵＥからのあるいは前記ＵＥに関しての位置情報を受け取るように、必要ならば、前記ＵＥについての位置推定値を得るために前記位置情報に基づいてポジショニングを実行するように、また、前記ＵＥについての前記位置推定値を前記ネットワークエンティティに送るように、動作するプロセッサと、なおここでは、前記ネットワークエンティティから受け取られる前記シグナリングは、前記クライアントエンティティに前記ＵＥについての位置推定値をいつ送るのかを示す定期的位置情報を含んでいる；
装置。
【請求項２９】
前記位置情報は、前記ＵＥ、または前記ＲＡＮ、または前記ＵＥと前記ＲＡＮの両方によって得られる測定値を備えており、また、前記プロセッサは、ポジショニングエンティティに前記測定値を送るように、また、前記ポジショニングエンティティから前記ＵＥについての前記位置推定値を受け取るように、動作する、請求項２８記載の装置。
【請求項３０】
前記定期的報告の調整およびコントロールを前記ポジショニングエンティティに渡すために、シグナリングをポジショニングエンティティと交換するように動作する、請求項２８記載の装置。
【請求項３１】
前記ＲＡＮはユニバーサル地上無線アクセスネットワーク（ＵＴＲＡＮ）であり、前記ネットワークエンティティは、モバイルサービス交換局（ＭＳＣ）またはサービングＧＰＲＳサポートノード（ＳＧＳＮ）である、請求項２８記載の装置。
【請求項３２】
前記ＲＡＮはＧＳＭ  ＥＤＧＥ無線アクセスネットワーク（ＧＥＲＡＮ）であり、前記ネットワークエンティティは、モバイルサービス交換局（ＭＳＣ）またはサービングＧＰＲＳサポートノード（ＳＧＳＮ）である、請求項２８記載の装置。
【請求項３３】
クライアントエンティティへのユーザ機器（ＵＥ）の位置の定期的報告を開始するように、ネットワークエンティティによって送られるシグナリングを、無線アクセスネットワーク（ＲＡＮ）で受け取るための手段と、なおここでは、前記ネットワークエンティティから受け取られる前記シグナリングは、前記クライアントエンティティへの前記ＵＥについての位置推定値をいつ送るのかを示す定期的位置情報を含んでいる；
前記クライアントエンティティへのＵＥ位置の前記定期的報告を調整しコントロールするための手段と；
前記ＵＥからのあるいは前記ＵＥに関しての位置情報を受け取るための手段と、
必要であれば、前記ＵＥについての位置推定値を得るために前記位置情報に基づいてポジショニングを実行するための手段と、
前記ＵＥについての前記位置推定値を前記ネットワークエンティティに送るための手段と、
を備える、前記定期的位置情報によって示される各位置情報を処理するための手段と；
を備える装置。
【請求項３４】
前記位置情報は、前記ＵＥ、または前記ＲＡＮ、または前記ＵＥと前記ＲＡＮの両方によって得られる測定値を備えており、また、必要であれば、前記ＵＥについての前記位置推定値を得るために前記位置情報に基づいてポジショニングを実行するための前記手段は、
ポジショニングエンティティに前記測定値を送るための手段と、
前記ポジショニングエンティティから前記ＵＥについての前記位置推定値を受け取るための手段と、
を備えている、
請求項３３記載の装置。
【請求項３５】
前記定期的報告の調整およびコントロールを前記ポジショニングエンティティに渡すために、シグナリングをポジショニングエンティティと交換するための手段、
を更に備える請求項３３記載の装置。
【請求項３６】
クライアントエンティティへのユーザ機器（ＵＥ）の位置の定期的報告を開始するように、無線アクセスネットワーク（ＲＡＮ）によって送られるシグナリングを、ポジショニングエンティティで受け取ることと、なおここでは、前記ＲＡＮから受け取られる前記シグナリングは、前記クライアントエンティティへの前記ＵＥについての位置推定値をいつ送るのかを示す定期的位置情報を含んでいる；
前記クライアントエンティティへのＵＥ位置の前記定期的報告を調整しコントロールすることと；
前記定期的位置情報によって示される各位置報告について、
前記ＵＥによって送られるあるいは前記ＵＥに関する位置情報を前記ＲＡＮから受け取ることと、
必要であれば、前記ＵＥについての位置推定値を得るためにポジショニングを実行することと、
前記ＵＥについての前記位置推定値を前記ＲＡＮに送ることと；
を備える、位置サービスを提供する方法。
【請求項３７】
前記ＵＥについての前記位置推定値を導き出すために使用される測定値を測定して得るために、前記ＲＡＮに支援データを送ること、
を更に備える請求項３６記載の方法。
【請求項３８】
ポジショニングエンティティと無線アクセスネットワーク（ＲＡＮ）との間でのシグナリングの交換を容易にするように動作する通信ユニットと；
クライアントエンティティへのユーザ機器（ＵＥ）の位置の定期的報告を開始するために、前記ＲＡＮによって送られるシグナリングを受け取るように、前記クライアントエンティティへのＵＥ位置の前記定期的報告を調整しコントロールするように、各位置報告について、前記ＵＥによって送られるあるいは前記ＵＥに関する位置情報を前記ＲＡＮから受け取るように、必要ならば、前記ＵＥについての位置推定値を得るためにポジショニングを実行するように、また、前記ＵＥについての前記位置推定値を前記ＲＡＮに送るように、動作するプロセッサと、なおここでは、前記ＲＡＮから受け取られる前記シグナリングは、前記クライアントエンティティに前記ＵＥについての位置推定値をいつ送るのかを示す定期的位置情報を含んでいる；
装置。
【請求項３９】
前記ＵＥについての前記位置推定値を導き出すために使用される測定値を前記ＵＥにより測定して得るために、前記ＲＡＮに支援データを送るように動作する、請求項３８記載の装置。
【請求項４０】
クライアントエンティティへのユーザ機器（ＵＥ）の位置の定期的報告を開始するように、無線アクセスネットワーク（ＲＡＮ）によって送られるシグナリングを、ポジショニングエンティティで受け取るための手段と、なおここでは、前記ＲＡＮから受け取られる前記シグナリングは、前記クライアントエンティティへの前記ＵＥについての位置推定値をいつ送るのかを示す定期的位置情報を含んでいる；
前記クライアントエンティティへのＵＥ位置の前記定期的報告を調整しコントロールするための手段と；
前記ＵＥによって送られるあるいは前記ＵＥに関する位置情報を前記ＲＡＮから受け取るための手段と、
必要であれば、前記ＵＥについての位置推定値を得るためにポジショニングを実行するための手段と、
前記ＵＥについての前記位置推定値を前記ＲＡＮに送るための手段と、
を備える、前記定期的位置情報によって示される各位置情報を処理するための手段と；
を備える装置。
【請求項４１】
前記ＵＥについての前記位置推定値を導き出すために使用される測定値を前記ＵＥにより測定して得るために、前記ＲＡＮに支援データを送るための手段、
を更に備える請求項４０記載の装置。
【請求項４２】
クライアントエンティティへのユーザ機器（ＵＥ）の位置の定期的報告を開始するように、無線アクセスネットワーク（ＲＡＮ）によって送られるシグナリングを、前記ＵＥで受け取ることと、なおここでは、前記ＲＡＮから受け取られる前記シグナリングは、前記クライアントエンティティへの前記ＵＥについての位置推定値をいつ送るのかを示す定期的位置情報を含んでいる、またここでは、前記ＲＡＮは、前記クライアントエンティティへのＵＥ位置の前記定期的報告を調整しコントロールする；
前記定期的位置情報によって示される各位置報告について、位置情報を前記ＲＡＮに送ることと、なおここでは、前記位置情報は、前記ＵＥについての位置推定値、あるいは、前記ＵＥについての前記位置推定値を導き出すために使用される測定値を備える；
を備える、位置サービスを得る方法。
【請求項４３】
前記定期的位置情報は、位置報告の設定回数と、連続する位置報告間の時間間隔とを示す、請求項４２記載の方法。
【請求項４４】
前記定期的位置情報は、位置情報の報告をトリガする少なくとも１つの条件を示す、請求項４２記載の方法。
【請求項４５】
前記クライアントエンティティへの前記ＵＥ位置の定期的報告についての前記クライアントエンティティによって送られたリクエストを前記ＲＡＮ経由で受け取ることと、
前記リクエストの許可または拒否を送ることと、
を更に備える請求項４２記載の方法。
【請求項４６】
前記クライアントエンティティへの前記ＵＥ位置の定期的報告についての前記クライアントエンティティによって送られたリクエストを前記ＲＡＮ経由で受け取ること、を更に備え、
前記クライアントエンティティは、位置サービスをサポートするネットワークエンティティ内に存在するか、あるいは前記ネットワークエンティティに直接に結合されている、
請求項４２記載の方法。
【請求項４７】
前記クライアントエンティティへの前記ＵＥ位置の定期的報告のリクエストを送ることと、
前記リクエストに対する許可を受け取ることと、
を更に備える請求項４２記載の方法。
【請求項４８】
前記測定値を測定して得るために、支援データを前記ＲＡＮ経由で受け取ることと、
各位置報告について前記測定値を測定して得るために前記支援データを使用することと、
を更に備える請求項４２記載の方法。
【請求項４９】
各位置報告について少なくとも１つの送信機のために測定値を測定して得ることと、なおここでは、各送信機は基地局または衛星である；
前記位置情報として前記測定値を提供することと；
を更に備える請求項４２記載の方法。
【請求項５０】
各位置報告について少なくとも１つの送信機のために測定値を測定して得ることと、なおここでは、各送信機は基地局または衛星である；
前記測定値に基づいて前記ＵＥについての前記位置推定値を導き出すことと；
前記位置情報として前記位置推定値を提供することと；
を更に備える請求項４２記載の方法。
【請求項５１】
前記位置情報は、前記ＵＥについての前記位置推定値を導き出すために使用される測定値を備えており、前記方法は、
各位置報告について前記ＵＥについての前記位置推定値を前記ＲＡＮ経由で受け取ること、
を更に備える、
請求項４２記載の方法。
【請求項５２】
ユーザ機器（ＵＥ）と無線アクセスネットワーク（ＲＡＮ）との間の通信を容易にするように動作するトランシーバと；
クライアントエンティティへの前記ＵＥの位置の定期的報告を開始するように、前記ＲＡＮによって送られるシグナリングを受け取るように、前記ＲＡＮから受け取られた前記シグナリング中に含まれる定期的位置情報に基づいて、前記クライアントエンティティへの前記ＵＥについての位置推定値をいつ送るのかを決定するように、前記ＵＥについての位置推定値、あるいは、位置情報として前記位置推定値を導き出すために使用される測定値を提供するように、また、前記ＲＡＮに前記位置情報を送るように、動作するプロセッサと、なおここでは、前記ＲＡＮは、前記クライアントエンティティへのＵＥ位置の前記定期的報告を調整しコントロールする；
を備える装置。
【請求項５３】
前記プロセッサは、各位置報告について、少なくとも１つの送信機のための測定値を得るように、かつ、前記位置情報として前記測定値を提供するように、動作し、またここでは、各送信機は、基地局かまたは衛星である、請求項５２記載の装置。
【請求項５４】
前記プロセッサは、各位置報告について、少なくとも１つの送信機のための測定値を得るように、前記測定値に基づいて前記ＵＥについての前記位置推定値を導き出すように、また、前記位置情報として前記位置測定値を提供するように、動作し、またここでは、各送信機は、基地局かまたは衛星である、請求項５２記載の装置。
【請求項５５】
前記シグナリングは、モバイルサービス交換局（ＭＳＣ）またはサービングＧＰＲＳサポートノード（ＳＧＳＮ）によって出される、請求項５２記載の装置。
【請求項５６】
クライアントエンティティへのユーザ機器（ＵＥ）の位置の定期的報告を開始するように、無線アクセスネットワーク（ＲＡＮ）によって送られるシグナリングを、前記ＵＥで受け取るための手段と、なおここでは、前記ＲＡＮから受け取られる前記シグナリングは、前記クライアントエンティティへの前記ＵＥについての位置推定値をいつ送るのかを示す定期的位置情報を含んでいる、またここでは、前記ＲＡＮは、前記クライアントエンティティへのＵＥ位置の前記定期的報告を調整しコントロールする；
前記定期的位置情報によって示される各位置報告について、位置情報を前記ＲＡＮに送るための手段と、なおここでは、前記位置情報は、前記ＵＥについての位置推定値、あるいは、前記ＵＥについての前記位置推定値を導き出すために使用される測定値を備える；
を備える装置。
【請求項５７】
各位置報告について少なくとも１つの送信機のために測定値を測定して得るための手段と、なおここでは、各送信機は基地局または衛星である；
前記位置情報として前記測定値を提供するための手段と；
を更に備える請求項５６記載の装置。
【請求項５８】
各位置報告について少なくとも１つの送信機のために測定値を測定して得るための手段と、なおここでは、各送信機は基地局または衛星である；
前記測定値に基づいて前記ＵＥについての前記位置推定値を導き出すための手段と；
前記位置情報として前記位置推定値を提供するための手段と；
を更に備える請求項５６記載の装置。
【発明の詳細な説明】
【背景】
【０００１】
（優先権の主張）
本願は、２００５年６月２１日に出願され、「短絡したメッセージフローを用いた位置サービスを提供する方法および装置(METHOD AND APPARATUS FOR PROVIDING LOCATION SERVICES WITH SHORT-CIRCUITED MESSAGE FLOWS)」と題された仮米国出願シリアル番号６０／６９３と；２００５年８月２５日に出願され、「無線アクセスネットワークにおける効率的な定期的位置報告(EFFICIENT PERIODIC LOCATION REPORTING IN A RADIO ACCESS NETWORK)」と題された仮米国出願シリアル番号６０／７１１，８０１と；２００５年９月１６日に出願され、「無線アクセスネットワークにおける効率的な定期的位置報告(EFFICIENT PERIODIC LOCATION REPORTING IN A RADIO ACCESS NETWORK)」と題された仮米国出願シリアル番号６０／７１８，１１２と；２００６年２月６日に出願され、「無線アクセスネットワークにおける効率的な定期的位置報告(EFFICIENT PERIODIC LOCATION REPORTING IN A RADIO ACCESS NETWORK)」と題された仮米国出願シリアル番号６０／７７１，１８０と；２００６年２月７日に出願され、「定期的位置プロシージャの解明および補正(CLARIFICATION AND CORRECTION OF PERIODIC LOCATION PROCEDURE)」と題された仮米国出願シリアル番号６０／７７１，２１７と；２００６年２月８日に出願され、「定期的位置プロシージャの追加(ADDITION OF PERIODIC LOCATION PROCEDURES)」と題された仮米国出願シリアル番号６０／７７１，７０６と；の優先権を主張する、なお、これらはすべて、ここでの譲受人に譲渡されており、参照によりここに組み込まれる。
【０００２】
（分野）
本開示は、一般に、通信に関し、より具体的には、位置サービス(location services)を提供するための技術に関連する。
【０００３】
（背景）
ネットワークにおける無線デバイス(wireless device)の位置(location)を知ることは、多くの場合望ましく、また、時々必要である。例えば、無線ユーザは、ウェブサイトにザット目を通す(browse through a website)ために無線デバイスを利用するかもしれないし、また、ロケーションセンシティブコンテンツ(location sensitive content)をクリックするかもしれない。ウェブサーバ(web server)は、そのとき、無線デバイスの位置についてネットワークを検索する(query)ことができる。ネットワークは、無線デバイスの位置を確認するために、無線デバイスを用いて位置処理(location processing)を開始するだろう。ネットワークは、そのあと、無線デバイスについての位置推定値(location estimate)をウェブサーバに戻すであろう、ウェブサーバは、この位置推定値を、無線ユーザに適切なコンテンツを提供するために使用することができる。無線デバイスの位置についての知識が有用である、あるいは必要である、多くの他のシナリオがある。以下の説明においては、用語「位置(location)」と用語「ポジション(position)」とは、同義語(synonymous)であり、区別なく(interchangeably)使用される。
【０００４】
メッセージフロー(message flow)（これはまた、コールフロー(call flow)あるいはプロシージャ(procedure)とも呼ばれてよい）は、典型的に、無線デバイスについての位置推定値を得て、そして、この位置推定値をクライアントエンティティ(client entity)（例、ウェブサーバ）に送るために実行される。様々なメッセージは、典型的に、メッセージフローについての、１つ以上のネットワークエンティティ、無線デバイス、およびクライアントエンティティの間で交換される。これらのメッセージは、無線デバイスについてのポジショニング(positioning)を実行するために、かつ／または、クライアントエンティティに位置推定値を伝えるために、各エンティティには関連情報が提供されている、あるいは、各エンティティはこの情報を別のエンティティから得ることができる、ということを確実にする。然しながら、これらのメッセージは、様々なネットワークエンティティの間のトラフィック(traffic)を増す。追加のトラフィックは、無線デバイスについての位置推定値をクライアントエンティティに定期的に(periodically)提供する定期的位置報告(periodic location reporting)の場合に、特に大きいかもしれない。メッセージはまた、クライアントエンティティに位置推定値を送るための応答時間を、もしかすると受け入れがたい量の分、延ばすかもしれない。
【０００５】
従って、当技術分野においては、位置サービスを効率的に提供する技術について必要性がある。
【発明の開示】
【０００６】
［概要］
無線アクセスネットワーク(radio access network)（ＲＡＮ）の定期的ＬＣＳ機能(periodic LCS capability)を使用する位置サービス(ＬＣＳ)を効率的に提供する技術が、ここに説明される。これらの技術は、ＬＣＳクライアントに無線デバイスの位置を定期的に報告するＲＡＮベースの定期的位置報告(RAN-based periodic location reporting)を利用する。ＲＡＮベースの定期的位置報告は、定期的位置報告についてのモバイルターミネートの位置リクエスト(mobile terminated location request)（ＭＴ−ＬＲ）プロシージャ(procedure)、ネットワーク誘導の位置リクエスト(network induced location request)（ＮＩ−ＬＲ）プロシージャ、また、モバイルオリジネートの位置リクエスト(mobile originated location request)（ＭＯ−ＬＲ）プロシージャのために使用されることができる。
【０００７】
ＭＯ−ＬＲの定期的位置報告の一実施形態においては、ＲＡＮと通信する無線デバイスは、ネットワークエンティティに、（１）クライアントエンティティへのＵＥ位置の定期的報告についてのリクエスト、および（２）定期的位置情報を送る。無線デバイスはまた、ユーザ機器（ＵＥ）と呼ばれ、ネットワークエンティティは、モバイルサービス交換局（ＭＳＣ）、あるいは、サービングＧＰＲＳサポートノード（ＳＧＳＮ）であり得る、そして、クライアントエンティティはまた、ＬＣＳクライアントと呼ばれる。定期的位置情報は、報告エベント(reporting events)のスケジュール、及び／又は、位置報告をトリガする(trigger)１セットの予め決められたエベント(a set of predetermined events)を示すことができる。リクエストが承認された後、ＭＳＣ／ＳＧＳＮは、ＵＥについての定期的位置報告を開始するために、ＲＡＮにシグナリング(signaling)を送る。ＲＡＮは、ポジショニングセンタ（これはスタンドアロンのサービングモバイル位置センタ(standalone serving mobile location center)（ＳＡＳ）と呼ばれてもよい）に、支援データ(assistance data)をＵＥに送ることをリクエストすることができる。ＲＡＮは、定期的位置報告を調整し(coordinate)コントロール(control)してもよいし、あるいは、ＳＡＳにコントロールを渡して(pass)もよい。どんな場合も、定期的位置情報によって決定される位置報告については、ＵＥは位置情報をＲＡＮに送る。この位置情報は、（１）基地局及び／又は衛星についてＵＥによって測定により得られた測定値(measurements made by)、あるいは、（２）ＵＥについての位置推定値を含むことができる。衛星あるいはＲＡＮがＵＥから測定値を受け取る場合、そのときは、ＲＡＮは測定値をＳＡＳに送ることができ、それは、ＵＥについての位置推定値を計算し(compute)、位置推定値をＲＡＮに戻すことができる。ＲＡＮは、そのあと、ＵＥについての位置推定値をＭＳＣ／ＳＧＳＮに送り、それは、位置推定値を、ＬＣＳクライアントに向けて転送する。ＲＡＮベースの定期的位置報告は、定期的にＵＥ位置推定値をＬＣＳクライアントに送るシグナリングを減らし、そしてまた、より速い応答時間を提供する。
【０００８】
ＲＡＮベースの定期的位置報告についての様々なメッセージフローが以下に説明される。本発明の様々な態様および実施形態もまた、以下により詳細に説明される。
【０００９】
［詳細な説明］
【００１０】
本発明の特徴および本質は、同様な参照文字が全体をとおして同様に識別する図面と併せて以下に述べられる詳細な説明から、より明らかになるであろう。
【００１１】
ここで使用されている用語「例示的な(exemplary)」は、「例(example)、インスタンス(instance)、または例証(illustration)として機能している」を意味するようにここでは使用される。「例示的な」としてここで説明されるどの実施形態あるいは設計も、他の実施形態あるいは設計よりも好ましいあるいは有利であるとして必ずしも解釈されるべきではない。
【００１２】
ここに説明される定期的位置報告技術は、符号分割多元接続（ＣＤＭＡ）ネットワーク、時分割多元接続（ＴＤＭＡ）ネットワーク、周波数分割多元接続（ＦＤＭＡ）ネットワーク、直交周波数分割多元接続（ＯＦＤＭＡ）ネットワーク、前述の技術の組合せをサポートするネットワーク、無線ローカルエリアネットワーク（ＷＬＡＮ）サービスエリアと同様に広域ネットワークサービスエリアを備えたネットワーク、などのような、様々な無線ネットワークに使用されることができる。ＣＤＭＡネットワークは、１つ以上のＣＤＭＡ無線技術、例えば、広帯域ＣＤＭＡ（Ｗ−ＣＤＭＡ）、ｃｄｍａ２０００などを、インプリメント(implement)できる。ｃｄｍａ２０００は、ＩＳ−２０００、ＩＳ−８５６、およびＩＳ−９５標準規格をカバーする。ＴＤＭＡネットワークは、１つ以上のＴＤＭＡ無線技術、例えば、汎欧州デジタル移動電話方式(Global System for Mobile Communications)（ＧＳＭ）、デジタル先進移動電話方式(Digital Advanced Mobile Phone System)（Ｄ−ＡＭＰＳ）などを、インプリメントできる。Ｄ−ＡＭＰＳは、ＩＳ−１３６およびＩＳ−５４をカバーする。これらの様々な無線技術および標準規格は、当技術においては知られている。Ｗ−ＣＤＭＡおよびＧＳＭは、「第三世代協力プロジェクト」（３ＧＰＰ）と呼ばれる団体のドキュメントにおいて説明されている。ｃｄｍａ２０００は、「第三世代協力プロジェクト２」（３ＧＰＰ２）と呼ばれる団体のドキュメントにおいて説明されている。３ＧＰＰと３ＧＰＰ２のドキュメントは公的に利用可能である。明確にするために、３ＧＰＰによって広められた１つ以上の無線技術および１つ以上のネットワーキングプロトコル(networking protocols)を利用する３ＧＰＰベースのネットワーク(3GPP-based network)について、本技術が以下に説明される。例えば、３ＧＰＰベースのネットワークは、無線通信(over-the-air communication)の無線技術(radio technology)としてＷ−ＣＤＭＡを、また、コアネットワーク機能性(core network functionality)のためのネットワーキングプロトコルとしてモバイルアプリケーションパート(Mobile Application Part)を利用するユニバーサルモバイルテレコミュニケーションシステム(Universal Mobile Telecommunication System)（ＵＭＴＳ）ネットワークであってよい。
【００１３】
図１Ａは、以下の説明においてＵＥｓ（３ＧＰＰ専門用語）と呼ばれる無線デバイスについての通信と位置のサービスを提供する３ＧＰＰベースのネットワーク１００を示す。簡単にするために、１つのＵＥ１２０のみが、図１Ａにおいて示される。ＵＥ１２０は、固定されていてもよいし、あるいはモバイル(mobile)であってもよく、また、移動局、端末、あるいは加入者ユニットとも呼ばれることができ、あるいは他のなんらかの専門用語で呼ばれるかもしれない。ＵＥ１２０はまた、携帯電話(cellular phone)、ラップトップ、携帯情報端末(personal digital assistant)（ＰＤＡ）、遠隔測定デバイス(telemetry device)、追跡装置(tracking device)などであってもよい。ＵＥ１２０はまた、無線アクセスネットワーク（ＲＡＮ）１３０における１つ以上の基地局と通信するかもしれない。ＵＥ１２０はまた、全地球測位システム(Global Positioning System)（ＧＰＳ）、欧州ガリレオシステム(European Galileo system)、あるいはロシアのＧｌｏｎａｓｓシステム、の一部かもしれない１つ以上の衛星１９０から、信号を受け取るかもしれない。ＵＥ１２０はまた、ＲＡＮ１３０における基地局からの信号、及び／又は、衛星１９０からの信号を測定する(measure)かもしれないし、また、これらの基地局および衛星についての疑似距離測定値(pseudo-range measurements)を得るかもしれない。これらの疑似距離測定値は、ＵＥについての位置推定値(location estimate)を導き出すために使用されることができる。
【００１４】
ＲＡＮ１３０は、ＲＡＮのサービスエリアの全体にわたって位置するＵＥｓに無線通信を提供する。ＲＡＮ１３０は、モバイルサービス交換局（ＭＳＣ）及び／又はサービングＧＰＲＳサポートノード（ＳＧＳＮ）（ＭＳＣ／ＳＧＳＮ）１４０と通信し、そしてまた、サービングモバイル位置センタ（ＳＭＬＣ）及び／又はスタンドアロンのＳＭＬＣ（ＳＡＳ）（ＳＭＬＣ／ＳＡＳ）１３２と通信する。ＭＳＣ１４０は、そのサービスエリア内のＵＥｓのための回路交換コール(circuit-switched calls)のためのスイッチング関数(switching functions)（例えば、回路交換の音声およびデータのコールのセットアップ(setup)、ルーティング(routing)、起こり得るリリース(release)）を実行する。ＳＧＳＮ１４０は、パケット交換コール(packet-switched calls)およびパケット交換接続(packet-switched connections)のためのスイッチングおよびルーティング関数(switching and routing functions)を実行する。ＳＭＬＣ／ＳＡＳ１３２は、ポジショニングサービス(positioning services)を提供し、ＵＥベースの(UE-based)、ＵＥ支援の(UE-assisted)、およびネットワーク−ベースの(network-based)、ポジショニングモードをサポートできる。ポジショニングは、ターゲットＵＥ(target UE)の地理的位置(geographical location)を検出する、あるいは決定する機能(functionality)を指す。ＳＡＳは、あるポジショニング方法、例えば、アップリンク到着時間差(Uplink Time Difference of Arrival)（Ｕ−ＴＤＯＡ）ポジショニング方法、を支援するいくつかの関連する位置測定ユニット(Location Measurement Units)（ＬＭＵｓ）（図１Ａの中では示されていない）を有していてもよい。ＳＭＬＣは、ＲＡＮの物理的及び／又は論理的な部分であってもよいし、あるいは、それは、スタンドアロンの(standalone)ＳＭＬＣ（ＳＡＳ）の場合には、物理的かつ論理的に分離されている可能性がある。いずれの場合も、以下の説明では
、ＳＭＬＣ／ＳＡＳ１３２は、それが、ＲＡＮの物理的及び／又は論理的な部分であろうとなかろうと、あるいはＲＡＮから分離されていようとなかろうと、異なったエンティティ(distinct entity)として扱われる。
【００１５】
ゲートウェイモバイル位置センタ(gateway mobile location center)（ＧＭＬＣ）１５０は、位置サービスをサポートする様々な機能を実行し、外部ＬＣＳクライアントとインタフェースをとり、そして、サービス、例えば、加入者プライバシ(subscriber privacy)、許可(authorization)、認証(authentication)、ビリング(billing)など、を提供する。ホームロケーションレジスタ(home location register)（ＨＬＲ）／ホーム加入者サーバ（ＨＳＳ）１６０は、ネットワーク１００の加入者であるＵＥｓ（例、ＵＥ１２０）のための登録情報(registration information)を保存する。ＬＣＳクライアント１７０は、ＬＣＳターゲットについての位置情報をリクエストし、かつ／または、受け取る機能あるいはエンティティである。ＬＣＳターゲットは、その位置が求められているＵＥである。一般に、ＬＣＳクライアントは、ネットワークエンティティあるいはＵＥの中に存在するかもしれないし、あるいは、ネットワークとＵＥの両方の外側にあるかもしれない。ＬＣＳクライアント１７０は、ＧＬＭＣ１５０と通信する。
【００１６】
簡単にするために、図１Ａは、位置サービスに関連するネットワークエンティティを示す。これらのネットワークエンティティは、「位置サービス（ＬＣＳ）の機能的ステージ２説明（リリース６）(Functional stage 2 description of Location Services (LCS) (Release 6))」と題された３ＧＰＰ  ＴＳ  ２３．２７１の中で、「ＵＴＲＡＮにおけるユーザ機器（ＵＥ）ポジショニングのステージ２機能仕様（リリース６）(Stage 2 functional specification of User Equipment (UE) positioning in UTRAN (Release 6))」と題された３ＧＰＰ  ＴＳ  ２５．３０５の中で、また、「ＧＥＲＡＮにおける位置サービス（ＬＣＳ）の機能的ステージ２説明（リリース６）(Functional stage 2 description of Location Services (LCS) in GERAN (Release 6))」と題された３ＧＰＰ  ＴＳ  ４３．０５９の中で、説明されており、それらの全部が、公に利用可能である。
【００１７】
図１Ａは、ＵＥ１２０が、単一のネットワーク（例、ホームネットワーク）と通信するケースを示す。このネットワークにおけるネットワークエンティティのすべてが、コアネットワーク及び／又は他のデータネットワーク（図１Ａにおいては示されていない）経由で、通信する。ＵＥ１２０は、ローミングし、異なる訪問先ネットワーク(visited networks)と通信することができる。
【００１８】
図１Ｂは、訪問先／サービングネットワーク(visited/ serving network)１０２と、ホームネットワーク(home network)１０４と、リクエスティングネットワーク(requesting network)１０６とを含む、３ＧＰＰベースの展開(3GPP-based deployment)１０１を示す。訪問先ネットワーク１０２は、現在ＵＥ１２０にサービングを行っている(serving)ネットワークである。ホームネットワーク１０４は、ＵＥ１２０が加入をしているネットワークである。リクエスティングネットワーク１０６は、それを介してＬＣＳクライアント１７０がＵＥ１２０の位置(location)についてリクエストを出す(originate)ことができ、かつ／または、ＵＥ１２０の位置を受け取ることができる、ネットワークである。ホームネットワーク１０４は、訪問先ネットワーク１０２と同じであるかもしれないし、あるいは異なるかもしれない。リクエスティングネットワーク１０６もまた、訪問先ネットワーク１０２と同じであるかもしれないし、あるいは異なるかもしれない。各ネットワークは、パブリックランドモバイルネットワーク(public land mobile network)（ＰＬＭＮ）と呼ばれてもよい。
【００１９】
図１Ｂにおいて示される実施形態の場合、訪問先ネットワーク１０２は、第二世代（２Ｇ）ＧＳＭ  ＥＤＧＥ無線アクセスネットワーク（ＧＥＲＡＮ）１３０ａおよび第３世代（３Ｇ）ユニバーサルテレストリアル無線アクセスネットワーク(Universal Terrestrial Radio Access Network)（ＵＴＲＡＮ）１３０ｂを含んでいる。ＧＥＲＡＮ１３０ａは、２Ｇ−ＳＧＳＮ１４０ａ及び／又は２Ｇ−ＭＳＣ１４０ｂと通信する。ＧＥＲＡＮ１３０ａはまた、３Ｇ−ＳＧＳＮ１４０ｃ及び／又は３Ｇ−ＭＳＣ１４Ｏｄと通信することができる。ＵＴＲＡＮ１３０ｂは、３Ｇ−ＳＧＳＮ１４０ｃ及び／又は３Ｇ−ＭＳＣ１４Ｏｄと通信する。各ＭＳＣは、訪問先ＭＳＣ（ＶＭＳＣ）として動作でき、また、３Ｇ−ＭＳＣ１４０ｄは、ＭＳＣサーバであってもよい。訪問先ＧＭＬＣ（Ｖ−ＧＭＬＣ）１５０ａは、訪問先ネットワーク１０２についての位置サービス(location services)をサポートし、ＭＳＣ１４０ｂおよび１４０ｄ、および、ＳＧＳＮで１４０ａおよび１４０ｃと通信する。ＳＭＬＣ／ＳＡＳ１３２は、ポジショニングサービス(positioning services)を提供し、ＧＥＲＡＮ１３０ａ、ＵＴＲＡＮ１３０ｂ、２Ｇ−ＭＳＣ１４０ａなどと通信することができる。
【００２０】
ホームネットワーク１０４は、ホームＧＭＬＣ（Ｈ−ＧＭＬＣ）１５０ｂおよびＨＬＲ／ＨＳＳ１６０を含んでいる。Ｈ−ＧＭＬＣ１５０ｂは、ホームネットワーク１０４についての位置サービスをサポートする。ＨＬＲ／ＨＳＳ１６０は、ホームネットワーク１０４の加入者であるＵＥについての登録情報を保存する。リクエスティングネットワーク１０６は、リクエスティングネットワーク１０６についての位置サービスをサポートするリクエスティングＧＬＭＣ（Ｒ−ＧＬＭＣ）１５０ｃを含んでいる。図１Ｂの中では示されていないが、Ｒ−ＧＬＭＣ１５０ｃ及び／又はＨ−ＧＬＭＣ１５０ｂは、訪問先ネットワーク１０２の中のＳＧＳＮ１４０ａ、ＭＳＣ１４０ｂ、ＳＧＳＮ１４０ｃ、及び／又はＭＳＣ１４Ｏｄと、適切なインタフェース経由で直接に通信してもよい。
【００２１】
図１Ａおよび１Ｂにおけるネットワークエンティティはまた、他のネットワークおよび他の位置アーキテクチャにおいて、他の名前によって参照されるかもしれない。例えば、オープンモバイルアライアンス(Open Mobile Alliance)（ＯＭＡ）によって広められたセキュアユーザプレーンロケーション(Secure User Plane Location)（ＳＵＰＬ）アーキテクチャにおいては、ＬＣＳクライアントは、時にはＳＵＰＬエージェントと呼ばれることもあり、ＧＬＭＣはＳＵＰＬ位置センタ（ＳＬＣ）と呼ばれ、ＳＵＰＬをサポートするＵＥは、ＳＵＰＬ使用可能端末(SUPL enabled terminal)（ＳＥＴ）と呼ばれ、ＳＬＭＣは、ＳＵＰＬポジショニングセンタ（ＳＰＣ）と呼ばれる。これらのＳＵＰＬ名称のエンティティによって実行される機能およびシグナリングは、対応する３ＧＰＰ名称エンティティによって実行されるそれらと正確に同じではないが、おおまかに言って類似しており、同等のサービスおよび機能(comparable services and capabilities)を可能にしている。ＧＬＭＣもまた、位置センタ(location center)、ＬＣＳサーバ(LCS server)、位置サーバ(location server)、モバイルポジショニングセンタ(mobile positioning center)（ＭＰＣ）などと呼ばれるかもしれない。ＳＭＬＣもまた、ポジショニングエンティティ(positioning entity)、ポジショニングセンタ(positioning center)、位置決定エンティティ(position determination entity)（ＰＤＥ）などと呼ばれるかもしれない。一般に、各ネットワークは、任意のサービス範囲を提供できるネットワークエンティティの任意のコレクションを、含むことができる。明確にするために、以下の説明の多くは、図１Ａにおける３ＧＰＰベースのネットワーク１００の場合である。
【００２２】
ＵＥ１２０の位置は、（１）モバイルオリジネートの位置リクエスト(mobile originated location request)（ＭＯ−ＬＲ）をもたらす、ＵＥで実行中のアプリケーション（Ａｐｐｓ）、（２）モバイルターミネートの位置リクエスト(mobile terminated location request)（ＭＴ−ＬＲ）をもたらす、ＬＣＳクライアント１７０で実行中のアプリケーション、および（３）ネットワーク誘導の位置リクエスト(network induced location request)（ＮＩ−ＬＲ）をもたらす、ターゲットＵＥ（例えば、図１Ｂにおける２Ｇ−ＳＧＳＮ１４０ａ、２Ｇ−ＭＳＣ１４０ｂ、３Ｇ−ＳＧＳＮ１４０ｃあるいは３Ｇ−ＭＳＣ１４Ｏｄ）にサービングを行っているＰＬＭＮエンティティのうちのいずれかの内部で実行中のアプリケーションによって、リクエストされることができる。ＵＥ１２０の位置は、ワンショットあるいは即時位置報告(one-shot or immediate location reporting)をもたらす１回限りのリクエストがされてもよいし、定期的位置報告(periodic location reporting)をもたらすシングルリクエスト(single request)で複数回リクエストされてもよい。定期的位置報告は、定期的なＭＴ−ＬＲメッセージフロー、定期的なＮＩ−ＬＲメッセージフロー、あるいは定期的なＭＯ−ＬＲメッセージフローで達成されることができる。定期的位置報告は、ＵＥ位置をクライアントエンティティにいつ報告するのかを示す定期的位置情報に基づいて、ターゲットＵＥについての位置推定値をＬＣＳクライアントに定期的に(periodically)提供する。定期的位置情報は、報告エベントのスケジュール及び／又は１セットのトリガエベント(triggering events)であってもよい。スケジュールは、例えば、開始時間(start time)、報告間隔(reporting interval)、及び、停止時間(stop time)、持続時間(duration)あるいは報告の特定の数のうちの１つなどの、様々なフォーマットで与えられることができる。トリガエベントは、例えば、利用可能になるＵＥ、あらかじめ定義された地理的エリアに入る、あるいは、から離れるＵＥ、あらかじめ定義された地理的エリア内にあるＵＥ、あらかじめ定義された閾値を越えるＵＥ速度あるいは加速度、あらかじめ定義された閾値によって変化するＵＥ位置、速度あるいは加速度、などに、対応し得る。
【００２３】
ＵＥ１２０についての位置推定値は、ＵＥベース、ＵＥ支援、あるいはネットワークベースの、ポジショニングモードを使用して得られることができる。ＵＥベースのモードの場合、ＵＥの位置は、ＳＭＬＣ、ＧＥＲＡＮあるいはＵＴＲＡＮからの支援データを多分使用して、ＵＥによって決定される。ＵＥ支援のモードの場合、ＵＥの位置は、ＵＥからの支援（例、測定）によりＳＭＬＣによって決定される。ネットワークベースのモードの場合、ＵＥの位置は、ＵＥからの何ら特別な支援無しに、ネットワークによって得られるかあるいは既にネットワークに知られている情報に基づいて決定される。ネットワークベースのモードの場合、ＵＥの位置は、１つ以上のＬＭＵあるいは基地局で測定して得られるアップリンク測定値(uplink measurements)によって決定されることができる。
【００２４】
ＵＥベースのモードとＵＥ支援のモードは、様々なポジショニング方法、例えば、ＧＰＳ、支援ＧＰＳ(assisted GPS)（Ａ−ＧＰＳ）、ハイブリッド、高度順方向リンク三辺測量(advanced forward link trilateration)（Ａ−ＦＬＴ）、拡張観測時間差(enhanced observed time difference)（Ｅ−ＯＴＤ）、到着の観測時間差(observed time difference of arrival)（ＯＴＤＯＡ）など、を利用できる。ネットワークベースのモードは、様々なポジショニング方法、例えば、到着のアップリンク時間(uplink time of arrival)（Ｕ−ＴＯＡ）、到着のアップリンク時間差(uplink time difference of arrival)（Ｕ−ＴＤＯＡ）、セルＩＤ(cell-ID)、拡張セルＩＤ(enhanced cell-ID)など、を利用できる。１つ以上のポジショニングモードについて複数のポジショニング方法もまた、組み合わせて使用されてもよい。ＧＰＳとＡ−ＧＰＳの方法は、衛星測定結果(satellite measurements)にもっぱら基づきＵＥについての位置推定値を導き出し、高い正確さ(accuracy)を有する。ハイブリッド方法は、衛星と基地局の両方の測定値に基づき位置推定値を導き出し、高い正確さと高い信頼性とを有する。Ａ−ＦＬＴ、Ｅ−ＯＴＤ、およびＯＴＤＯＡの方法は、ＵＥによって測定された基地局タイミングの測定値に基づき位置推定値を導き出し、より中間の正確さを有する。Ｕ−ＴＯＡおよびＵ−ＴＤＯＡの方法は、ネットワークによって測定されたＵＥタイミングの測定値に基づき位置推定値を導き出し、より中間の正確さを有する。セルＩＤおよび拡張セルＩＤの方法は、セルラーネットワークに基づいて位置推定値を導き出し、より粗い正確さを(coarser accuracy)有する。これらの様々なポジショニング方法は当技術分野において知られている。
【００２５】
ＬＣＳクライアント１７０へのＵＥ位置の定期的報告をサポートする様々なメッセージフローが、図１Ａにおける３ＧＰＰベースのネットワーク１００について、以下に説明される。これらのメッセージフローは、コアネットワーク（例、ＭＳＣ／ＳＧＳＮ１４０）が、ＲＡＮベースの定期的位置報告を効率的に提供するために、ＲＡＮ１３０の定期的なＬＣＳ機能を呼び出し(invoke)そして利用することを、可能にする。ＲＡＮベースの定期的位置報告は、ＭＳＣ／ＳＧＳＮ、ＵＥ、あるいはＧＭＬＣとは対照的に、ＲＡＮによって調整されコントロールされる(coordinated and controlled)定期的位置報告を指す。
【００２６】
図２Ａは、ＭＴ−Ｌ定期的位置報告についてのメッセージフロー２００の一実施形態を示す。メッセージフロー２００の場合、ＬＣＳクライアント１７０は、（１）ＬＣＳクライアント１７０へのターゲットＵＥ１２０の定期的位置報告についてのリクエスト（すなわち、定期的位置リクエスト）および（２）定期的位置情報（「定期的ｌｏｃ  ｉｎｆｏ」）を含むＬＣＳサービスリクエストメッセージ(LCS Service Request message)を、ＧＭＬＣ１５０に送る（ステップ１）。ＧＭＬＣ１５０は、ＬＣＳクライアント１７０の識別情報(identity)を確認する(verify)ことができ、ＬＣＳクライアントを認証する(authenticate)ことができ、また、ＬＣＳクライアントがリクエストされた位置サービスについて許可される(authorized)のかどうかを決定することができる。ＬＣＳクライアント１７０が許可される場合、そのときＧＭＬＣ１５０は、（１）ＬＣＳクライアント１７０についての加入データ(subscription data)、ＵＥ１２０の加入者についての加入データ、及び／又はＬＣＳクライアント１７０によって供給されるデータに基づき、ＵＥ１２０の識別子(identifier)およびＬＣＳのサービスの質(quality of service)（ＱｏＳ）を決定し、（２）ＵＥ加入者についてのプライバシプロファイル(privacy profile)に基づいたプライバシチェックを行ない、そして（３）その後の位置報告をオリジナルの定期的位置リクエストに関連付けるために使用される参照識別子(reference identifier)（ＩＤ）を割り当てる。プライバシチェックの場合、ＧＭＬＣ１５０は、ＬＣＳクライアント１７０あるいはこの種のＬＣＳクライアントがＵＥ１２０についての定期的位置報告をリクエストすることを承認されているのかどうかを、また、ＵＥがこのリクエストについて通知され、リクエストを許可または拒否する(accept or reject)ことを承認される必要があるかもしれないかどうかを、確認する。
【００２７】
ＧＭＬＣ１５０が、ＵＥ１２０のための現在のサービングＭＳＣあるいはＳＧＳＮを知らない場合、そのときＧＭＬＣ１５０は、ＵＥについてのルーティング情報をリクエストするために、ＬＣＳのためのルーティング情報を送れのメッセージ(Send Routing Info for LCS message)をＨＬＲ／ＨＳＳ１６０に送る（ステップ２）。ＨＬＲ／ＨＳＳ１６０は、そのあと、ＭＳＣ／ＳＧＳＮ１４０のアドレスを含んでいる、ＬＣＳのためのルーティング情報を送れの肯定応答メッセージ(Send Routing Info for LCS Acknowledgment message)を返す（ステップ３）。ステップ２および３は、もしＧＭＬＣ１５０がＭＳＣ／ＳＧＳＮ１４０のアドレスを既に知っている場合は、スキップされてもよい。ＧＭＬＣ１５０は、そのあと、ＭＳＣ／ＳＧＳＮ１４０に、定期的位置リクエスト、ＵＥ識別子、定期的位置情報、及び／又は他の関連情報を含んでいる、加入者位置を提供せよメッセージ(Provide Subscriber Location message)を送る（ステップ４）。
【００２８】
ＭＳＣ／ＳＧＳＮ１４０は、定期的位置リクエストが承認されることを認証できる。（同様にステップ４）。定期的位置リクエストが承認される場合、そのときＭＳＣ／ＳＧＳＮ１４０は、例えば、ＵＥ１２０がアイドルモード(idle mode)にあったのであれば、ＵＥ１２０のページングおよび認証(paging and authentication)を行なうためにＲＡＮ１３０を呼びだすことができる（ステップ５）。もし通知(notification)あるいはプライバシ確認(privacy verification)が必要とされる場合、そのときは、ＭＳＣ／ＳＧＳＮ１４０は、定期的位置リクエストを無線ユーザに通知し、許可を与えるか拒否するためにユーザを調べる(query)ためにＵＥ１２０に通知する（同様にステップ５）。ＵＥ１２０は、例えば、ＵＥベースの、及び／又は、ＵＥ支援のモードがＵＥによってサポートされていようとなかろうと、その機能(capability)を、ＲＡＮ１３０及び／又はＭＳＣ／ＳＧＳＮ１４０に提供することができる（同様にステップ５）。ＭＳＣ／ＳＧＳＮ１４０は、そのあと、ＵＥ１２０に、定期的位置リクエストについての関連情報（例、定期的位置情報、ＬＣＳ  ＱｏＳ、参照ＩＤなど）を含むＬＣＳ定期的位置呼び出しメッセージ(LCS Periodic Location Invoke message)を送る（ステップ６）。ＬＣＳ定期的位置呼び出しメッセージはまた、（１）定期的位置報告が承認される（例えば、ＭＯ−ＬＲリクエストが出される(originated)ことができる）ＰＬＭＮｓのリスト、および（２）ＰＬＭＮがＲＡＮベースの定期的位置報告をサポートするかどうかに関しての各ＰＬＭＮについての表示(indication)、を含むことができる。もしＰＬＭＮｓのリストが含まれていない場合、そのときは、後に続くＭＯ−ＬＲリクエストは、現在のサービングＰＬＭＮに制限されてもよい。
【００２９】
ＵＥ１２０はそのあと、定期的位置リクエストが受理され且つその後のＭＯ−ＬＲリクエストが積極的にサポートされることができるかどうかを示すＬＣＳ定期的位置呼び出し肯定応答メッセージ(LCS Periodic Location Invoke Acknowledgment message)を、ＭＳＣ／ＳＧＳＮ１４０に送る。プライバシ確認の結果は、それが既にステップ５において含まれているので、このメッセージにおいては必要とされないであろう。もし定期的位置リクエストが受理されないが、ステップ５におけるプライバシ確認が通過すれば、そのときは、ＵＥ１２０は、定期的位置報告を承認する意向であること(willingness)を、しかし、後のＭＯ−ＬＲリクエストによってそれを積極的にサポートすることができない、あるいは不本意であること(inability or unwillingness)を、示しているであろう。その場合、以下に説明されるように、ＭＳＣ／ＳＧＳＮ１４０は、ＲＡＮ１３０を経由して定期的位置報告を依然として呼び出す(invoke)ことができる。そうでなければ、エラーレスポンス(error response)が、ＭＳＣ／ＳＧＳＮ１４０によって出され(originated)、そしてＧＭＬＣ１５０に戻される。いずれの場合も、ＭＳＣ／ＳＧＳＮ１４０は、ＧＭＬＣ１５０に、定期的位置リクエストが受理されるかどうかを示す、加入者位置を提供せよ肯定応答メッセージ(Provide Subscriber Location Acknowledgment message)を送る（ステップ８）。このメッセージは、ＵＥ１２０に送られたＰＬＭＮのリストのような他の関連情報を含んでいてもよい。ＧＭＬＣ１５０は、そのあと、ＬＣＳクライアント１７０に、関連情報（例えば、定期的位置リクエストが受理されるかどうか）を含んでいるＬＣＳサービスレスポンスメッセージを送る（ステップ９）。以下に説明されるように、ＬＣＳクライアント１７０へのＵＥ位置の定期的報告が、ＲＡＮ１３０の定期的ＬＣＳ機能(periodic LCS capabilities)を使用して、そのあと実行される（ステップ１０）。
【００３０】
図２Ｂは、ＮＩ−ＬＲの定期的位置報告のためのメッセージフロー２１０の一実施形態を示す。もしＬＣＳクライアント１７０がＭＳＣ／ＳＧＳＮ１４０内に存在するか、あるいは同じＰＬＭＮ内に存在し、ＭＳＣ／ＳＧＳＮ１４０に直接的にリンクされる場合は、メッセージフロー２１０が使用される。メッセージフロー２１０のステップ１、５、６、７、９および１０は、図２Ａにおけるメッセージフロー２００の、ステップ１、５、６、７、９および１０にそれぞれ対応する。メッセージフロー２１０の場合、ＬＣＳクライアント１７０は、定期的位置リクエストおよび定期的位置情報を含んでいるＬＣＳサービスリクエストメッセージ(LCS Service Request message)を、ＭＳＣ／ＳＧＳＮ１４０に直接送信する（ステップ１）。ＭＳＣ／ＳＧＳＮ１４０は、定期的位置リクエストが承認されるのを認証することができ、そしてリクエストが承認される場合は、ＵＥ１２０のページングおよび認証を行なうためにＲＡＮ１３０を呼びだしてもよい（ステップ５）。典型的には、通知あるいはプライバシ確認はステップ５においては行なわれない。メッセージフロー２１０のステップ６および７は、メッセージフロー２００について上記に説明されたとおりである。ＭＳＣ／ＳＧＳＮ１４０は、そのあと、ＬＣＳクライアント１７０に、定期的位置リクエストが受理されるかどうかを示すＬＣＳサービスレスポンスメッセージ(LCS Service Response message)を直接送る（ステップ９）。以下に説明されるように、ＬＣＳクライアント１７０へのＵＥ位置の定期的報告は、そのあと、ＲＡＮ１３０の定期的ＬＣＳ機能を使用して行なわれる（ステップ１０）。
【００３１】
図３は、ＭＯ−ＬＲの定期的位置報告のためのメッセージフロー３００の一実施形態を示す。もしＵＥ１２０がアイドルモードである場合、そのときは、ＵＥは、無線接続セットアップ(radio connection setup)をリクエストし、ＲＡＮ１３０に、コールインデペンデント補足サービス(call independent supplementary service)についてのリクエストを示すコネクション管理（ＣＭ）サービスリクエストメッセージ(Connection Management (CM) Service Request message)を送る（ステップ１）。もしＵＥ１２０が専用モード(dedicated mode)にある場合、そのときは、ＵＥは、既に確立されている無線接続に関するＣＭサービスリクエストを送る（同様にステップ１）。ＲＡＮ１３０は、ＣＭサービスリクエストメッセージをＭＳＣ／ＳＧＳＮ１４０へ転送する（ステップ２）。ＭＳＣ／ＳＧＳＮ１４０は、ＵＥ１２０がアイドルモードであれば、認証および暗号化(ciphering)を開始し(instigates)、あるいは、ＵＥ１２０が専用モードにあれば、直接転送ＣＭサービス受理メッセージ(Direct Transfer CM Service Accept message)を返す（ステップ３）。ＵＥ１２０は、例えば、ＵＥベースの、及び／又は、ＵＥ支援のモードがＵＥにサポートされていようとなかろうと、ＲＡＮ１３０及び／又はＭＳＣ／ＳＧＳＮ１４０に、その機能を提供することができる（同様にステップ３）。明確にするために、図３における接続セットアップステップ１から３までは、回路交換（ＣＳ）ドメイン(circuit switched (CS) domain)を前提としており、また、シグナリングはＭＳＣに送られる（ＳＧＳＮではない）。パケット交換（ＰＳ）ドメイン(packet switched (PS) domain)のための接続セットアップステップは異なり、また、シグナリングは、ＲＡＮ１３０経由でＳＧＳＮに送られる。ＣＳおよびＰＳのドメインのための接続セットアップは、公的に利用可能である３ＧＰＰ  ＴＳ  ２３．２７１の中で説明されている。
【００３２】
ＵＥ１２０は、そのあと、ＭＳＣ／ＳＧＳＮ１４０に、（１）ＬＣＳクライアント１７０へのＵＥ１２０の定期的位置報告のリクエスト（すなわち定期的位置リクエスト）および（２）定期的位置報告についての関連情報を含んでいるＬＣＳ  ＭＯ−ＬＲ位置サービス呼び出しメッセージ(LCS MO-LR Location Services Invoke message)を送る（ステップ４）。関連情報は、次の任意の組合せを含むことができる：
１．位置報告のためのスケジュール（「定期的ｌｏｃ  ｉｎｆｏ」）、
２．ＬＣＳクライアント１７０への位置報告をトリガするために使用される特定のエベント（同様に「定期的ｌｏｃ  ｉｎｆｏ」）、
３．ＬＣＳクライアント１７０の識別情報（「ｌｃｓ−クライアント−ａｄｄｒ」）、
４．ＬＣＳクライアント１７０がアクセスされることができるＧＭＬＣ１５０の識別情報、
５．ＬＣＳ  ＱｏＳ、例えば、正確さと応答時間、
６．定期的位置報告のための好ましい方法、例えば、ＭＴ−ＬＲあるいはＭＯ−ＬＲ、
７．任意の位置推定値の最大許容エイジ(maximum allowed age)、
８．ＵＥ１２０は、ＵＥの実際の識別情報あるいは実アドレスを使用し、あるいは匿名を使用して、ＬＣＳクライアント１７０に識別されるべきであるかどうか、
９．他の関連情報。
【００３３】
ＭＳＣ／ＳＧＳＮ１４０は、ＵＥについての加入プロファイルに基づいて、リクエストされた位置サービスに対しＵＥ１２０が許可されることを確認する（同様にステップ４）。定期的位置リクエストが許可される場合、そのときは、ＭＳＣ／ＳＧＳＮ１４０は、ＧＭＬＣ１５０に、定期的位置リクエストおよび関連情報（例、定期的位置情報）を含んでいるＭＡＰ加入者位置報告メッセージ(MAP Subscriber Location Report message)を送る（ステップ５）。ＧＭＬＣ１５０は、そのあと、ＬＣＳクライアント１７０へ、定期的位置リクエストおよび関連情報を転送する（ステップ６）。ＬＣＳクライアント１７０は、ＧＭＬＣ１５０に、ＵＥリクエストに対するレスポンスを送る（ステップ７）。一実施形態においては、ＭＳＣ／ＳＧＳＮ１４０、ＧＭＬＣ１５０、およびＬＣＳクライアント１７０の中のいずれのエンティティも、定期的位置リクエストを拒否あるいは受理することができる。もしリクエストが受理される（例えば、どのエンティティによっても拒否されない）場合、そのときＧＭＬＣ１５０は、リクエストに対し参照ＩＤを割り当てる。ＧＭＬＣ１５０は、そのあと、ＭＳＣ／ＳＧＳＮ１４０に、ＭＡＰ加入者位置報告肯定応答メッセージ(MAP Subscriber Location Report Acknowledgment message)を送る（ステップ８）。ＭＳＣ／ＳＧＳＮ１４０は、次の情報の任意の組合せを受け取ることができる：
１．ＧＭＬＣ１５０によって割り当てられた参照ＩＤ、
２．位置報告のための修正されたスケジュール（「定期的ｌｏｃ  ｉｎｆo」）、
３．ＬＣＳクライアント１７０への位置報告をトリガするために使用される修正された特定エベント（同様に「定期的ｌｏｃ  ｉｎｆo」）、
４．ＧＭＬＣ１５０のアドレス、
５．他の関連情報。
【００３４】
ＭＳＣ／ＳＧＳＮ１４０は、ＵＥ１２０に、ＧＭＬＣ１５０から受け取られた情報を含んでいるＬＣＳ  ＭＯ−ＬＲリターン結果メッセージ(LCS MO-LR Return Result message)を送る（ステップ９）。ＬＣＳ  ＭＯ−ＬＲリターン結果メッセージは更に、（１）定期的位置報告が承認されるＰＬＭＮｓのリストと、（２）ＰＬＭＮがＲＡＮベースの定期的位置報告をサポートするかどうかに関しての各ＰＬＭＮについての表示と、を含んでいてもよい。これは、もしＵＥ１２０がＭＯ−ＬＲリクエストをとおしての後の定期的位置報告において積極的な役割をする場合に、該当する。もしＰＬＭＮのリストが提供されない場合は、そのときは、どんな後のＭＯ−ＬＲリクエストも、現在のサービングＰＬＭＮに制限されてよい。以下に説明されるように、ＬＣＳクライアント１７０へのＵＥ位置の定期的報告は、ＲＡＮ１３０の定期的ＬＣＳ機能を使用して、そのあと実行されることができる（ステップ１０）。
【００３５】
一般に、どんなエンティティ（例、ＵＥ１２０）も、ＬＣＳクライアント１７０へのＵＥ位置のＲＡＮベースの定期的位置報告を呼び出すことができる。ＲＡＮ１３０における定期的報告のＵＥ１２０による呼び出しサポートするために、ＵＥ１２０は、各ＰＬＭＮがＲＡＮにおいて定期的ＬＣＳ機能を有しているかどうかを通知されることができる。この情報は、メッセージフロー２００のステップ６あるいはメッセージフロー３００のステップ９において、ＵＥ１２０に送られるＰＬＭＮｓのリスト中に含まれることができる。この情報はまた、ＲＡＮｓによるブロードキャストであってもよい。
【００３６】
定期的位置報告の場合、最初の位置報告(the first reporting)は、典型的には、定期的位置報告を開始するためにメッセージ交換を完了した直後である。位置報告は、次のエベントのうちの１つが発生するまで続くことができる：
１．報告持続時間が経過した、あるいは報告の総数が得られた、
２．定期的位置報告が、ＬＣＳクライアント１７０あるいはＧＭＬＣ１５０によってキャンセルされる、
３．  ＵＥ１２０が定期的位置報告を終了する。
【００３７】
図４は、図２Ａにおけるメッセージフロー２００のステップ１０、図２Ｂにおけるメッセージフロー２１０のステップ１０、および図３におけるメッセージフロー３００のステップ１０のために使用されることができる、ＲＡＮベースの定期的位置報告のためのメッセージフロー４００の一実施形態を示す。メッセージフロー４００のステップ１から３までは、メッセージフロー３００のステップ１から３までと同じである。ＵＥ１２０は、そのあと、ＭＳＣ／ＳＧＳＮ１４０に、定期的位置報告を呼び出すＬＣＳ  ＭＯ−ＬＲ位置サービス呼び出しメッセージ(LCS MO-LR Location Services Invoke message)を送る（ステップ４）。メッセージフロー３００のステップ４において送られるＬＣＳ  ＭＯ−ＬＲ位置サービス呼び出しメッセージは、定期的位置報告について「リクエストする」が、これに対して、メッセージフロー４００のステップ４において送られるＬＣＳ  ＭＯ−ＬＲ位置サービス呼び出しメッセージは、定期的位置リクエストが許可された後に、定期的位置報告を「呼び出す」。メッセージフロー４００において送られるＬＣＳ  ＭＯ−ＬＲ位置サービス呼び出しメッセージは、関連情報、例えば、定期的位置情報、ＬＣＳ  ＱｏＳ、ＬＣＳクライアント１７０の識別情報、定期的位置リクエストが許可されたという表示などを、含む。許可表示(authorization indication)は、例えば、ＧＭＬＣ１５０によって割り当てられた参照ＩＤであってもよい。ＬＣＳ  ＭＯ−ＬＲ位置サービス呼び出しメッセージにおける許可表示の存在（図４において）あるいは不在（図３において）は、ＭＳＣ／ＳＧＳＮ１４０に、メッセージフロー４００あるいはメッセージフロー３００をそれぞれ実行すべきかどうかを通知する。ＬＣＳ  ＭＯ−ＬＲ位置サービス呼び出しにおける定期的位置情報あるいは他の同等の情報(equivalent information)の存在は、ＭＳＣ／ＳＧＳＮ１４０に、ワンショット位置報告(one shot location report)よりは寧ろＬＣＳクライアント１７０へのＲＡＮベースの定期的位置報告がリクエストされていることを知らせる。ワンショット位置報告の場合には、ＵＥ１２０が、ＬＣＳクライアント１７０に送られるべき各スケジュールされた、あるいはトリガされた位置報告について、ステップ４におけるＬＣＳ  ＭＯ−ＬＲ位置サービス呼び出しを再度発行すること(re-issuing)（例えば、ステップ１から４を繰り返すこと）に責任を負うであろう。ＲＡＮベースの定期的位置報告のリクエストで、ＵＥは、以下に説明されるように、ＲＡＮによる位置報告のスケジューリング及び／又はトリガリングが完了するまで、別のＬＣＳ  ＭＯ−ＬＲ位置サービス呼び出しを再度発行する必要がない。
【００３８】
ＭＳＣ／ＳＧＳＮ１４０は、リクエストされた位置サービスについてＵＥ１２０が許可されることを確認し、そのあと、ＲＡＮ１３０に、ＲＡＮベースの定期的位置報告を開始する位置リクエストメッセージ(Location Request message)を送る（ステップ５）。このメッセージはまた、定期的位置情報、ＬＣＳ  ＱｏＳ、などを含むことができる。ＲＡＮ１３０は、位置リクエスト、必要とされる正確さ、およびＵＥ機能に基づいて適切なポジショニング方法(positioning method)を選択する。
【００３９】
ＲＡＮ１３０は、そのあと、ＵＥ１２０についての最初の位置推定値を得てそして返すために適切なメッセージフローを開始する（ステップ６ａ）。このメッセージフローは、様々なファクタ(factors)、例えば、ＵＥ機能（例、ＵＥベースの、あるいはＵＥ支援の）、選択されたポジショニング方法（例、Ａ−ＧＰＳ、Ａ−ＦＬＴ、Ｅ−ＯＴＤ、ＯＴＤＯＡなど）、ＵＥ１２０、ＲＡＮ１３０、あるいはＳＡＳ１３２が位置推定値を計算するであろうかどうか、など、に依存し得る。ステップ６ａについてのメッセージフローのいくつかの実施形態が以下に説明される。ＲＡＮ１３０は、ステップ６ａにおけるメッセージフローからＵＥ１２０についての位置推定値を得て、ＭＳＣ／ＳＧＳＮ１４０に、この位置推定値および他の関連情報（例、参照ＩＤ）を含んでいる位置報告メッセージを送る（ステップ７ａ）。ＭＳＣ／ＳＧＳＮ１４０は、そのあと、位置推定値および関連情報を含んでいるＭＡＰ加入者位置報告メッセージ(MAP Subscriber Location Report message)を、ＧＭＬＣ１５０に送り（ステップ８ａ）、ＧＭＬＣ１５０はＬＣＳクライアント１７０に位置推定値および関連情報を送る（ステップ９ａ）。ＬＣＳクライアント１７０は、位置情報肯定応答(location information acknowledgment)をＧＭＬＣ１５０に送ることによって応答し（ステップ１０ａ）、ＧＭＬＣ１５０は、ＭＳＣ／ＳＧＳＮ１４０に、位置推定値がＬＣＳクライアント１７０に成功裡に送られたかどうかを示すＭＡＰ加入者位置報告肯定応答メッセージを送る（ステップｌｌａ）。
【００４０】
各その後の位置報告エベントｉ、但しｉ＝ｂ．．．ｎ、について、定期的位置情報によって決定されるように、メッセージフローが、ＵＥ１２０についての位置推定値を得るために実行され（ステップ６ｉ）、そして、位置推定値が、ＭＳＣ／ＳＧＳＮ１４０に送られる（ステップ７ｉ）。ＭＳＣ／ＳＧＳＮ１４０は、そのあと、ＬＣＳクライアント１７０に位置推定値を転送する（ステップ８ｉから１１ｉまで）。すべての位置報告エベントが完了した後、ＭＳＣ／ＳＧＳＮ１４０は、ＵＥ１２０に、位置推定値がＬＣＳクライアント１７０に送られたことを確認し、かつ定期的位置報告の終了を示すために、ＬＣＳ  ＭＯ−ＬＲリターン結果メッセージ(LCS MO-LR Return Result message)を送る（ステップ１２）。
【００４１】
もしＵＥが以前にアイドルであったならば、ＭＳＣ／ＳＧＳＮ１４０は、コネクション管理（ＣＭ）、移動管理（ＭＭ）あるいはＧＰＲＳ移動管理（ＧＭＭ）、および無線リソース管理（ＲＲ／ＲＲＣ）の接続のＵＥ１２０へのリリース(release)を開始(instigate)してもよい（ステップ１３）。もしＵＥ１２０が、例えば、他の進行中のサービスをサポートするために、ＲＡＮ１３０と通信する専用モードに残る必要がある場合は、ステップ１３は省略されてもよい。
【００４２】
ＵＭＴＳ（例、Ｗ  −    ＣＤＭＡ）の場合におけるＲＡＮベースの定期的位置報告は、ＲＮＣセントリックモード(RNC-centric mode)およびＳＡＳセントリックモード(SAS -centric mode)で達成されることができる。ＲＮＣセントリックモードの場合、サービングＲＡＮ内のサービング無線ネットワークコントローラ（ＳＲＮＣ）は、ＵＥについての定期的位置報告を調整しコントロールする。ＳＡＳセントリックモードの場合、ＳＲＮＣは、コントロールをＳＡＳへ渡し、それが、定期的位置報告を調整しコントロールする。ＲＮＣセントリックとＳＡＳセントリックの両方のモードの場合、ＳＲＮＣは、定期的位置報告のためのＵＥ、ＳＡＳ、およびＭＳＣ／ＳＧＳＮとの通信を容易にするために、状態情報(state information)を保存する。ＵＥは、ＲＮＣセントリックあるいはＳＡＳセントリックのモードが定期的位置報告のために使用されているかどうかに気づいている必要はない。ＲＮＣセントリックおよびＳＡＳセントリックのモードは、ＵＥ支援の、ＵＥベースの、およびネットワークベースのモードに使用されることができる。
【００４３】
図５は、ＲＮＣセントリックモードにおけるＲＡＮベースの定期的位置報告のためのメッセージフロー５００の一実施形態を示す。メッセージフロー５００は、図４におけるメッセージフロー４００の一実施形態であり、図２Ａ、２Ｂおよび３におけるメッセージフロー２００、２１０および３００のステップ１０のためにそれぞれ使用されることができる。
【００４４】
メッセージフロー（それは図４におけるメッセージフロー４００のステップ１から４までを含んでもよい）が、ＬＣＳクライアント１７０への定期的位置報告を開始するために最初に実行される（ステップ１）。ＭＳＣ／ＳＧＳＮ１４０は、そのあと、ＲＡＮ１３０内のＳＲＮＣ（あるいは簡略に、ＲＡＮ／ＳＲＮＣ１３０）に、定期的位置報告を開始する無線アクセスネットワークアプリケーションパート（ＲＡＮＡＰ）位置報告コントロールメッセージ(Radio Access Network Application Part (RANAP) Location Reporting Control message)を送る（ステップ２）。このメッセージはまた、定期的位置情報、ＬＣＳ  ＱｏＳなどを含んでいてもよい。一実施形態においては、ＲＡＮＡＰ位置報告コントロールメッセージは、次のフィールド(fields)を有する定期的報告基準情報エレメント（ＩＥ）(Periodical Reporting Criteria information element (IE))を含んでいる：
１．報告の量(Amount of Reports)  −  １、２、４、８、１６、３２、６４、無限、
２．報告間隔(Reporting Interval)  −  ２５０、５００、１０００、２０００、３０００、４０００、６０００、８０００、１２０００、１６０００、２００００、２４０００、２８０００、３２０００、６４０００ミリセカンド（ｍｓ）。  
この実施形態の場合、各フィールドは、上記に与えられた１セットの可能な値(a set of possible value)に関連している。一般に、定期的報告基準ＩＥは、任意のフィールドを含むことができ、また、各フィールドは、任意のセットの可能な値含むことができる。
【００４５】
定期的報告基準ＩＥのためのフィールドは、メッセージフロー５００のステップ５においてＲＡＮ／ＳＲＮＣ１３０によってＵＥ１２０に送られるべきＲＲＣ測定コントロールメッセージ(RRC Measurement Control message)中のＲＲＣ定期的報告基準ＩＥのためのフィールドと同じであるように定義されることができる。更に、同じセットの値が、定期的報告基準ＩＥとＲＲＣ定期的報告基準ＩＥとにおける対応するフィールドのために使用されてもよい。これは、そのとき、ＲＡＮ／ＳＲＮＣ１３０が、ＭＳＣ／ＳＧＳＮ１４０から定期的報告基準ＩＥにおける値を簡単に取り出す(simply extract)ことを、また、これらの値を、ＵＥ１２０に送られるＲＲＣ定期的報告基準ＩＥ上に直接マッピングする(map)ことを、可能にするであろう。ＭＳＣ／ＳＧＳＮ１４０は、定期的位置情報（例えば、開始時間、停止時間および報告間隔）を、定期的報告基準ＩＥにおける報告の量と報告間隔のフィールド(the Amount of Reports and the Reporting Interval fields)のための最適値(the best fitting values)に変換するであろう。ＭＳＣ／ＳＧＳＮ１４０は、報告の量のフィールドのデフォルト値(default value)として「無限(infinite)」を使用してもよく、また、これ以上の位置報告が必要とされない時には、ＲＡＮ／ＳＲＮＣ１３０に、「報告停止(stop reporting)」コマンド(command)を送ることができる。ＲＡＮ／ＳＲＮＣ１３０は、そのあと、停止コマンドをＵＥ１２０に送るだろう。一般に、もし様々なメッセージ中の関連するフィールドが同じでない場合は、そのとき、ＭＳＣ／ＳＧＳＮ１４０は、ＵＥ１２０から受け取られた（あるいは、例えばＭＳＣ／ＳＧＳＮ１４０またはＬＣＳクライアント１７０のようなＰＬＭＮにおける任意の他のエンティティから受け取られた）定期的位置情報を、ステップ２におけるＲＡＮＡＰ位置報告コントロールメッセージのための最適値へと変換し（必要であれば）、また、ＲＡＮ／ＳＲＮＣ１３０は、これらの値を、ステップ５におけるＲＲＣ測定コントロールメッセージのための最適値へと変換する（必要であれば）。
【００４６】
別の実施形態においては、ＲＡＮＡＰ位置報告コントロールメッセージにおける定期的報告基準ＩＥは、報告間隔のための任意の値（例えば、任意の整数倍数の秒）を、あるいは、報告の数のための任意の値を含むことができる。ＲＡＮ／ＳＲＮＣ１３０あるいはＳＡＳ１３２は、この情報を、ＲＲＣ定期的報告を呼び出すべきかどうかを決定するために、あるいは、単一のリクエストのために使用されるようなＲＲＣ測定コントロール／測定報告メッセージシーケンスを定期的に(periodically)繰り返すべきであるかどうかを決定するために、使用することができる。例えば、受け取られたＲＡＮＡＰ位置報告コントロールにおける定期的報告基準ＩＥのための値がＲＲＣ定期的報告基準ＩＥにおける対応する値と互換性がある(compatible)ときは、ＲＲＣ定期的報告は呼び出されることができる。
【００４７】
ＲＡＮ／ＳＲＮＣ１３０は、位置リクエスト、要求される正確さ(required accuracy)、およびＵＥ機能に基づき、適切なポジショニング方法を選択する（同様にステップ２）。もしＳＡＳ１３２が利用可能であり、かつ選択されたポジショニング方法がＡ−ＧＰＳであるのであれば、そのときＲＡＮ／ＳＲＮＣ１３０は、ＳＡＳ１３２へ、ＧＰＳ支援データをリクエストするためにポジショニング計算アプリケーションパート（ＰＣＡＰ）情報交換開始リクエストメッセージ(Positioning Calculation Application Part (PCAP) Information Exchange Initiation Request message)を送ることができる（ステップ３）。ＳＡＳ１３２は、そのあと、ＲＡＮ／ＳＲＮＣ１３０に、リクエストされたＧＰＳ支援データを含んでいるＰＣＡＰ情報交換開始レスポンスメッセージ(PCAP Information Exchange Initiation Response message)を返す（ステップ４）。ステップ３および４は、他のポジショニング方法の場合、あるいはもしＧＰＳ支援データが必要でない場合、あるいはもしＲＡＮ／ＳＲＮＣがＧＰＳ支援データを（例えば、ＳＡＳ１３２への以前のリクエストから）既に所有する場合は、省略されてもよい。ＲＡＮ／ＳＲＮＣ１３０は、そのあと、ＵＥ１２０に、定期的位置情報（例えば、ＲＲＣ定期的報告基準ＩＥ）およびＧＰＳ支援データを含んでいるＲＲＣ測定コントロールメッセージを送る（ステップ５）。ステップ３、４および５は、最初の位置報告エベント用のポジショニング１のためのメッセージの一部である。
【００４８】
各位置報告エベントｉ、但しｉ＝ａ．．．ｎ、について、定期的位置情報によって決定されるように、ＵＥ１２０は、ＲＡＮ／ＳＲＮＣ１３０に、位置情報を含んでいるＲＲＣ測定報告メッセージ(RRC Measurement Report message)を送る（ステップ６ｉ）。この位置情報は、ＵＥによって観測可能な基地局及び／又は衛星についてのＵＥ１２０によって測定される測定値（ＵＥ支援のモードの場合）、ＵＥ１２０についての位置推定値（ＵＥベースのモードの場合）、あるいは、測定値あるいは位置推定値が利用可能でないならばエラー表示、を備えることができる。測定値は、例えば、Ａ−ＧＰＳについての疑似距離、ＯＴＤＯＡについてのシステムフレームナンバ−システムフレームナンバ(system frame number-system frame number)（ＳＦＮ−ＳＦＮ）観測時間差(observed time differences)、あるいは何らかの他のタイプの測定値であってよい。もし報告間隔が短く（例えば２秒）そして選択されたポジショニング方法がＡ−ＧＰＳである場合、そのときは、ＵＥ１２０でのＧＰＳ受信機が衛星を捉え(acquired)かつトラッキングモード(tracking mode)の中にあるまで、最初のわずかのＲＲＣ測定報告メッセージは、エラーメッセージを含んでいるかもしれない。そのあと、ＲＲＣ測定報告メッセージは、該報告間隔で良い測定値及び／又は位置推定値を提供するはずである。
【００４９】
もしＲＡＮ／ＳＲＮＣ１３０がＵＥ１２０から測定値を受け取り（ＵＥ支援のモードの場合）かつＳＡＳ１３２が利用可能である場合は、そのときは、ＲＡＮ／ＳＲＮＣ１３０はＳＡＳ１３２に、例えば更なるネットワークベースのポジショニングについてのＵＥ測定値とたぶん他の情報とを含むＰＣＡＰポジション計算リクエスト(PCAP Position Calculation Request message)を送る（ステップ７ｉ）。ステップ７ｉで送られたＰＣＡＰポジション計算リクエストメッセージはまた、定期的位置情報、例えば、全体の定期的位置プロシージャについての未解決のリクエストの数および報告間隔を含んでいるかもしれない。定期的位置情報は、ＳＡＳ１３２が個々のＰＣＡＰポジション計算リクエストの間での状態情報(state information)を将来のそのようなリクエストをよりよく満たすために維持することを、可能にする。ＳＡＳ１３２は、測定値およびその他の情報に基づきＵＥ１２０についての位置推定値を計算し、ＲＡＮ／ＳＲＮＣ１３０に、位置推定値を含んでいるＰＣＡＰポジション計算レスポンスメッセージを送る（ステップ８ｉ）。もしＲＡＮ／ＳＲＮＣ１３０が、ＵＥ１２０から位置推定値を受け取るならば（ＵＥベースのモードの場合）、そのときは、ステップ７ｉおよび８ｉはスキップされてもよい。もしＲＡＮ／ＳＲＮＣ１３０がネットワークベースのポジショニング（例、拡張セルＢＤ、Ｕ−ＴＤＯＡ）のみを使用することを決定する場合、そのときは、ステップ３、４、５および６ｉ（但しｉ＝ａ．．．ｎ）はスキップされ、そして、ＲＡＮ／ＳＲＮＣ１３０は、ステップ７ｉにおいてＳＡＳ１３２に、選ばれたネットワークベースのポジション方法についての情報を含んでいるＰＣＡＰポジション計算リクエストメッセージ(PCAP Position Calculation Request message)を送る。ＳＡＳ１３２は、そのあと、ステップ８ｉにおいて、ＳＡＳ１３２によるネットワークベースの方法のアプリケーションから生じる位置推定値を含んでいるＰＣＡＰポジション計算レスポンスメッセージ(PCAP Position Calculation Response message)を返す。いずれの場合も、ＲＡＮ／ＳＲＮＣ１３０は、位置推定値を含んでいるＲＡＮＡＰ位置報告メッセージ(RANAP Location Report message)をＭＳＣ／ＳＧＳＮ１４０に送り（ステップ９ｉ）、それはＬＣＳクライアント１７０に位置推定値を転送する（ステップ１０ｉ）。ステップ１０ｉは、図４におけるメッセージフロー４００の８ｉから１１ｉまでを含んでいてもよい。
【００５０】
図５において示されるように、各位置報告エベントは、ポジショニング、ＲＡＮ／ＳＲＮＣ１３０からＭＳＣ／ＳＧＳＮ１４０への位置推定値の転送（ステップ９ｉ）、およびＭＳＣ／ＳＧＳＮ１４０からＬＣＳクライアント１７０への位置推定値の転送（ステップ１０ｉ）についてのメッセージを含んでいる。最初の位置報告エベントのためのポジショニング１についてのメッセージは、３から８ａまでを含んでおり、また、各その後の位置報告エベントのためのポジショニングｉについてのメッセージは、ステップ６ｉから８ｉまでを含んでいる。最初の位置報告エベントのためのポジショニング１についてのメッセージは、ＳＡＳ１３２からのＧＰＳ支援をリクエストし次いで得るために（ステップ３および４）、そして位置情報を定期的に送るためにＵＥ１２０を呼び出すためこの支援データをＵＥ１２０に転送するために（ステップ５）、更なるステップ３、４および５を含んでもよい。ＵＥ１２０はまた、ＲＡＮ／ＳＲＮＣ１３０に位置測定値を送る代わりに、あるいは送ることに加えて、ステップ６ｉにおいて新しい支援データをリクエストすることができる。これは、例えば、最初にリクエストされた（例、ステップ５において）報告の数が多く、かつリクエストされたポジショニング方法がＡ−ＧＰＳである場合のケースであり得る。もしＵＥ１２０が新しい支援データをリクエストする場合は、そのとき、ステップ３、４および５は繰り返され、そして、新しいあるいは更新された支援データが、他の関連情報と共に、測定コントロールメッセージの中で、あるいは支援データ配信メッセージ(Assistance Data Delivery message)の中で、ＵＥ１２０に送られる。ステップ６ｉにおける新しい支援データのリクエスト、およびステップ３、４および５の反復をとおしてのその提供(provision)が、メッセージフロー５００において一度よりも多く生じるかもしれない。位置報告エベントのすべてが完了した後、メッセージフロー（それは図４におけるメッセージフロー４００のステップ１２および１３を含んでいるかもしれない）は、ＬＣＳクライアント１７０への定期的位置報告を終了するために実行される（ステップ１１）。
【００５１】
ＲＡＮ／ＳＲＮＣ１３０は、例えば、ＲＲＣ測定コントロールメッセージからのＲＲＣ定期的報告基準ＩＥを省略するために、あるいは、報告の数について１つの値(a value of one)と共にこのＩＥを含めるために、定期的ＵＥ報告をリクエストしないことをステップ５において決定してもよい。上記に言及されるように、これは、ＲＡＮＡＰ位置報告コントロールメッセージにおいて受け取られる定期的位置情報が、ＲＲＣ測定コントロールメッセージ中の対応する利用可能な値の範囲に適合しない(not compatible)場合のケースであり得る。ＲＡＮ／ＳＲＮＣ１３０は、そのあと、望まれる定期的報告間隔で、ステップ５を送ることを繰り返してよい。各位置報告エベントについてポジショニングｉのためのメッセージは、そのとき、ステップ６ｉから８ｉまでに加えて、ステップ５を含むであろう。
【００５２】
図６は、ＳＡＳセントリックモードにおいてのＲＡＮベースの定期的位置報告のためのメッセージフロー６００の一実施形態を示す。メッセージフロー６００は、図４におけるメッセージフロー４００の別の実施形態であり、そしてまた、図２Ａ、２Ｂおよび３の中のメッセージフロー２００、２１０および３００のステップ１０のために、それぞれ使用されてもよい。
【００５３】
メッセージフロー６００のステップ１および２は、図５におけるメッセージフロー５００のステップ１および２に似ている（例えば、同じ）。ＲＡＮ／ＳＲＮＣ１３０は、ＭＳＣ／ＳＧＳＮ１４０から、定期的位置情報、ＬＣＳ  ＱｏＳなどを含んでいるＲＡＮＡＰ位置報告コントロールメッセージ(RANAP Location Reporting Control message)を受け取る（ステップ２）。ＲＡＮ／ＳＲＮＣ１３０は、そのあと、ＳＡＳ１３２へ、ＭＳＣ／ＳＧＳＮ１４０から受け取られた情報および多分他の情報、例えば、セルＩＤおよびＵＥポジショニング機能（例、ターゲットＵＥ１２０がサポートするポジショニング方法、あるいは複数のポジショニング方法に関する情報）などを含んでいるＰＣＡＰポジション開始リクエストメッセージ(PCAP Position Initiation Request message)を送る（ステップ３）。このメッセージはまた、定期的位置報告のコントロール(control)をＳＡＳ１３２に転送する。ＳＡＳ１３２は、要求される正確さおよびＵＥ機能に基づいて適切なポジショニング方法を選択し、ＵＥ１２０に送るために適切な支援データ（もしあれば）を決定する。ＳＡＳ１３２は、そのあと、ＲＡＮ／ＳＲＮＣ１３０に、定期的位置情報（例、定期的報告基準ＩＥ）および支援データを含んでいるＰＣＡＰポジションアクチベーションリクエストメッセージ(PCAP Position Activation Request message)を送る（ステップ４）。ＳＡＳ１３２は、必要とされる場合は、ステップ４で、ステップ３におけるＲＡＮ／ＳＲＮＣ１３０から受け取られた定期的位置情報を、ＰＣＡＰポジションアクチベーションリクエストメッセージに対しての最適値へ、変換されることができる。ＲＡＮ／ＳＲＮＣ１３０は、そのあと、ＵＥ１２０に、定期的位置情報および支援データを含んでいるＲＲＣ測定コントロールメッセージを送る（ステップ５）。ステップ３、４および５は、最初の位置報告エベントについてのポジショニング１のためのメッセージの一部である。
【００５４】
各位置報告エベントｉ、但しｉ＝ａ．．．ｎ、について、定期的位置情報によって決定されるように、ＵＥ１２０は、ＲＡＮ／ＳＲＮＣ１３０に、位置情報を含んでいるＲＲＣ測定報告メッセージを送る（ステップ６ｉ）。この位置情報は、基地局及び／又は衛星についてＵＥ１２０によって測定される測定値（ＵＥ支援のモードの場合）、ＵＥ１２０についての位置推定値（ＵＥベースのモードの場合）、あるいは、測定値あるいは位置推定値が利用可能でない場合はエラー表示、を含むことができる。ＲＡＮ／ＳＲＮＣ１３０は、ＳＡＳ１３２に、ＵＥ１２０から受け取られる位置情報を含んでいるＰＣＡＰポジション定期的リクエストメッセージを送る（ステップ７ｉ）。ＵＥ支援のモードの場合、ＳＡＳ１３２は、ＵＥ１２０から測定値を受け取り、そして、測定値およびたぶん他の情報（例えば、ネットワークベースのポジショニングから得られた情報）に基づいてＵＥについての位置推定値を計算する。ＵＥベースのモードの場合は、ＳＡＳ１３２は、ＵＥ１２０から位置推定値を受け取り、そして、（例えば、ネットワークベースのポジショニングから得られた情報に基づいて）位置推定値を確認、かつ／またはそれを修正できる。ＵＥベースとＵＥ支援の両方のモードの場合、ＳＡＳ１３２は、ＲＡＮ／ＳＲＮＣ１３０に、ＵＥ１２０についての位置推定値を含んでいるＰＣＡＰポジション定期的レスポンスメッセージを送る（ステップ８ｉ）。ＲＡＮ／ＳＲＮＣ１３０は、そのあと、位置推定値を含んでいるＲＡＮＡＰ位置報告メッセージを、ＭＳＣ／ＳＧＳＮ１４０に送り（ステップ９ｉ）、それは位置推定値をＬＣＳクライアント１７０に転送する（ステップ１０ｉ）。ステップ１０ｉは、図４におけるメッセージフロー４００の８ｉから11ｉまでを含むことができる。
【００５５】
ＵＥ１２０からの最終のＲＲＣ測定報告メッセージの受取り（ステップ６ｎ）に続いて、ＲＡＮ／ＳＲＮＣ１３０は、ステップ７ｎにおいて、ＳＡＳ１３２に、前のステップ７ｉ（但しｉ＝ａ．．．ｎ−１）におけるＰＣＡＰポジション定期的リクエストメッセージと同じタイプの情報（例えば、測定値あるいは位置推定値）を搬送するＰＣＡＰポジションアクチベーションレスポンスメッセージを送ることができる。ＳＡＳ１３２は、そのあと、ステップ８ｎにおいて、前のステップ８ｉ（但しｉ＝ａ．．．ｎ−１）におけるＰＣＡＰポジション定期的レスポンスメッセージと同じタイプの情報（例えば、計算された位置推定値）を搬送するＰＣＡＰポジション開始レスポンスメッセージを返すことができる。この区別は、ＲＮＣからＳＡＳにまたはＳＡＳからＲＮＣに送られるどんなＰＣＡＰリクエストメッセージもせいぜい1つの異なるＰＣＡＰレスポンスメッセージによって答えられるという（３ＧＰＰ  ＴＳ  ２５．４５３に定義された）３ＧＰＰについての現行の規則(existing conventions)の遵守(compliance)を支援することができる。この場合、ステップ８ｎにおいて送られるＰＣＡＰポジション開始レスポンスメッセージは、ステップ３において送られるＰＣＡＰポジション開始リクエストメッセージに対するレスポンスであり；ステップ７ｎにおいて送られるＰＣＡＰポジションアクチベーションレスポンスメッセージは、ステップ４において送られるＰＣＡＰポジションアクチベーションリクエストメッセージに対するレスポンスであり；また、ステップ８ｉ（但しｉ＝ａ．．．ｎ−１）において送られるＰＣＡＰポジション定期的レスポンスメッセージは、ステップ７ｉにおいて送られるＰＣＡＰポジション定期的リクエストメッセージに対するレスポンスである。これらのペアリング(paring)は、特に、３ＧＰＰ  ＴＳ  ２５．４５３におけるクラス１基本プロシージャに準拠する。更に、最初の２つのペアリング（ステップ３と８ｎ、および、ステップ４と７ｎ）は、シングルショット位置リクエスト（各ペアリングが一度だけ生じる故）に適用可能であり、シングルショット位置リクエストと定期的位置リクエストとの間のより大きなコンパティビリティ(compatibility)と、両方のタイプの位置リクエストをサポートするＲＡＮ／ＳＲＮＣ１３０およびＳＡＳ１３２においてのたぶんより容易なインプリメンテーションとを可能にする。ＲＮＣセントリックのオペレーションとのより大きなコンパティビリティを可能にするために、ステップ７ｉと８ｉにおけるＰＣＡＰポジション定期的リクエストとレスポンスのメッセージは、ＲＮＣセントリックモードにおいて使用され、かつ図５において示されるＰＣＡＰポジション計算リクエスト／レスポンスのメッセージと取り替えられてもよい。その場合、ＰＣＡＰポジション計算リクエスト／レスポンスのメッセージはまた、ＵＥから受け取られた位置推定値のＳＡＳへの配信(delivery)を可能にするためにわずかに修正されるかもしれないが、新しいプロシージャは必要とされない。
【００５６】
メッセージフロー６００の代替の実施形態においては、ステップ６ｎにおけるＵＥ１２０からの最終のＲＲＣ測定報告メッセージの受取りに続いて、ＲＡＮ／ＳＲＮＣは、ステップ７ｎにおいてＰＣＡＰポジション定期的リクエストメッセージをＳＡＳ１３２に送ることができ、そしてＳＡＳ１３２は、ちょうど前のステップ７ｉおよび８ｉにおけるのと同じように、ステップ８ｎにおいて、ＰＣＡＰポジション定期的レスポンスメッセージを返すことができる。この場合、ステップ８ｎに続いて、なお図６においては示されていないが、ＲＡＮ／ＳＲＮＣ１３０は、ＳＡＳ１３２ａに、いずれの測定値あるいは位置推定値も含んでいないＰＣＡＰポジションアクチベーションレスポンスメッセージを送ることができ、そしてＳＡＳ１３２は、ステップ３および４における初期のメッセージに応答し、かつＳＡＳ１３２およびＲＡＮ／ＳＲＮＣ１３０においてそれらに関連したトランザクション(transactions)を終了するために、位置推定値を含んでいないＰＣＡＰポジション開始レスポンスメッセージを返すことができる。
【００５７】
メッセージフロー６００の別の代替実施形態においては、ステップ７ｉおよび８ｉにおけるＰＣＡＰポジション定期的リクエストとレスポンスのメッセージを備えるＰＣＡＰクラス１基本プロシージャは、３ＧＰＰ  ＴＳ  ２５．４５３に定義されているＰＣＡＰクラス２基本プロシージャによって取り替えられることができる。クラス２基本プロシージャは、レスポンスメッセージのないプロシージャである。この実施形態においては、メッセージフロー６００のステップ７でのＰＣＡＰポジションアクチベーションレスポンスメッセージは、ステップ４でのＰＣＡＰポジションアクチベーションリクエストメッセージの直後か、あるいは、最初のＲＲＣ測定報告メッセージが受け取られた後、なおそれはステップ６ａの後である、に、送られることができる。前者の場合においては、ＰＣＡＰポジションアクチベーションレスポンスメッセージは、リクエストされたアクションの確認を含むであろう。後者の場合においては、ＰＣＡＰポジションアクチベーションレスポンスメッセージは、さらに最初の測定報告情報を含むであろう。ＰＣＡＰポジションアクチベーションリクエストメッセージは、ある推奨されるポジショニングインストラクション(positioning instruction)を含むことができ、ＲＡＮ／ＳＲＮＣ１３０はそれを、ＵＥ１２０に、ステップ５でのＲＲＣ測定コントロールメッセージの中で転送することができる。もしＲＡＮ／ＳＲＮＣ１３０が、あるポジショニングインストラクションについてのリクエストに応じることができない場合、そのときＲＡＮ／ＳＲＮＣ１３０は、ステップ５においてＵＥ１２０に送られるＲＲＣ測定コントロールメッセージにおいて代わりに使用されるポジショニングインストラクションに関してＰＣＡＰポジションアクチベーションレスポンスメッセージの中でＳＡＳ１３２に通知することができる。そのようなポジショニングインストラクションの一例は、どのＲＲＣ状態においてリクエストされた測定値が有効であるかについての情報であってもよい。ＲＡＮ／ＳＲＮＣ１３０でＵＥ１２０から受け取られるその後の測定報告情報(measurement report information)は、そのあと、クラス２  ＰＣＡＰポジション定期的報告メッセージ(class 2 PCAP Position Periodic Report messages)においてＳＡＳ１３２に伝達されるであろう、それは、メッセージフロー６００において示されるＰＣＡＰポジション定期的リクエストメッセージの代わりにステップ７ｉにおいて送られるであろう。ＳＡＳ１３２は、次に、クラス２  ＰＣＡＰポジション定期的結果メッセージ(class 2 PCAP Position Periodic Result messages)において位置推定値をＲＡＮ／ＳＲＮＣ１３２に報告するであろう、それは、メッセージフロー６００において示されるＰＣＡＰポジション定期的レスポンスメッセージの代わりにステップ８ｉにおいて送られるであろう。もしＳＡＳ１３２が進行中のＲＲＣ定期的プロシージャ(ongoing RRC periodic procedure)をキャンセルすることを決定すれば、そのとき、ＳＡＳ１３２は、ＲＡＮ／ＳＲＮＣ１３２に、定期的プロシージャの終了のリクエストを含んでいるＰＣＡＰポジション定期的結果メッセージを送ることができる。あるいは、ＳＡＳ１３２は、進行中の定期的プロシージャをキャンセルするためにクラス２  ＰＣＡＰポジション定期的終了メッセージ(class 2 PCAP Position Periodic Termination message)をＲＡＮ／ＳＲＮＣ１３０に送ってもよい。このメッセージフローは、ＲＲＣシグナリング、例えば、セルＩＤあるいはＵ−ＴＤＯＡネットワークベースのポジショニング、を要求しない定期的位置プロシージャと、よりコンパティブルであり得る。
【００５８】
上記に説明されたクラス２実施形態は、（例えば、ステップ３でのＰＣＡＰポジション開始リクエストメッセージにおいてＳＡＳ１３２で受け取られた定期的報告情報が、ＲＲＣ定期的報告基準ＩＥにおける利用可能な値の範囲とコンパティブルでない場合において）定期的ＲＲＣ測定報告を呼び出すべきかどうか、あるいは、シングルリクエスト定期的に繰り返すべきかどうかを、ＳＡＳ１３２が決定することを可能にする。ＳＡＳ１３２は、そのあと、リクエストされた定期的報告間隔で、ＲＡＮ／ＳＲＮＣ１３２に、ＰＣＡＰポジションアクチベーションリクエストメッセージを送ることを繰り返すことができる。ＲＡＮ／ＳＲＮＣ１３０は、ＲＲＣ測定コントロール／報告メッセージのペアを繰り返すであろう、また、ＰＣＡＰポジションアクチベーションレスポンスメッセージにおけるＳＡＳ１３２への測定情報を伝達する。ＳＡＳ１３２は、そのあと、個々の位置推定値を、ＰＣＡＰポジション定期的結果メッセージにおいてＲＡＮ／ＳＲＮＣ１３０に送ることができる。
【００５９】
クラス２実施形態は、例えば、定期的なセルＩＤベースのポジショニングをサポートするために使用されることができる。この場合、ＳＡＳ１３２は、ＲＡＮ／ＳＲＮＣ１３０にＰＣＡＰポジションアクチベーションリクエストメッセージを定期的に送ることができる（図６において示されていない）。ＲＡＮ／ＳＲＮＣ１３０は、そのあと、ＲＡＮ／ＳＲＮＣ１３０によって得られるＵＥ１２０についてのセル関連の測定値を含んでいるＰＣＡＰポジションアクチベーションレスポンスメッセージを返すことができる。ＳＡＳ１３２は、そのあと、ＲＡＮ／ＳＲＮＣ１３０に、これらの測定から得られた位置推定値を含んでいるＰＣＡＰポジション定期的結果メッセージを送ることができる。
【００６０】
クラス２実施形態はまた、定期的なＵ−ＴＤＯＡベースのポジショニングをサポートするために使用されることができる。この場合、ＲＡＮ／ＳＲＮＣ１３０は、ＳＡＳ１３２に、図６の中のステップ３におけるＰＣＡＰポジションアクチベーションリクエストメッセージを受け取った後に、ＵＥ１２０についてのチャネル関連情報を含んでいるＰＣＡＰポジションアクチベーションレスポンスメッセージを返すことができる。ＳＡＳ１３２は、そのあと、ＵＥ１２０についての定期的Ｕ−ＴＤＯＡ測定値を得るためにＬＭＵｓを構成(configure)してもよいし、また、一連のＰＣＡＰポジション定期的結果メッセージにおいてＲＡＮ／ＳＲＮＣ１３０に定期的位置推定値結果(periodic location estimate results)を返してもよい。Ｕ−ＴＤＯＡの場合のこの実施形態においては、ＲＡＮ／ＳＲＮＣ１３０がＳＡＳ１３２にさらにメッセージを送ることは必要でないかもしれず、それによって、伝送と処理のリソースを節約し、遅れを減らす。
【００６１】
クラス２実施形態は、定期的Ａ−ＧＰＳ及び／又は定期的ＯＴＤＯＡポジショニングと同時に(in parallel with)定期的Ｕ−ＴＤＯＡベースのポジショニングをサポートするように拡張されることができる。この場合、定期的Ｕ−ＴＤＯＡポジショニングは上記に説明されたように開始される(instigated)ことができる。定期的Ａ−ＧＰＳあるいはＯＴＤＯＡポジショニングは、そのあと、上記に同様に説明されたクラス２基本ＰＣＡＰプロシージャの実施形態を使用して開始されることができる。ＳＡＳ１３２は、ＬＭＵによって得られた定期的Ｕ−ＴＤＯＡ測定値、および、定期的ＰＣＡＰポジション定期的報告メッセージにおいてＳＡＳ１３２に提供される定期的ＧＰＳ測定値を使用して、ＵＥ１２０についての定期的位置推定値を得ることができる。ＳＡＳ１３２は、そのあと、ＰＣＡＰポジション定期的結果メッセージにおいて、ＲＡＮ／ＳＲＮＣ１３０に各位置推定値を返すことができる。
【００６２】
図６において示されるように、各位置報告エベント(location reporting event)は、ポジショニング、ＲＡＮ／ＳＲＮＣ１３０からＭＳＣ／ＳＧＳＮ１４０への位置推定値の転送（ステップ９ｉ）、およびＭＳＣ／ＳＧＳＮ１４０からＬＣＳクライアント１７０への位置推定値の転送（ステップ１０ｉ）のためのメッセージを含んでいる。最初の位置報告エベントについてのポジショニング１のためのメッセージは、ステップ３から８ａまでを含み、そして、各その後の位置報告エベントについてのポジショニングｉのためのメッセージは、ステップ６ｉから８ｉまでを含んでいる。位置報告エベントのすべてが完了した後、メッセージフロー（それは図４におけるメッセージフロー４００のステップ１２および１３を含んでいるかもしれない）は、ＬＣＳクライアント１７０への定期的位置報告を終了するために実行される（ステップ１１）。
【００６３】
ＵＥ１２０は、ある時点で、ＲＡＮ／ＳＲＮＣ１３０に位置測定値を送る代わりに、あるいは送ることに加えて、ステップ６ｉにおいて新しいあるいは更新された支援データをリクエストすることができる。これは、例えば、もし（例えばステップ５において）最初にリクエストされた報告の数が大きく、かつ、リクエストされたポジショニング方法がＡ−ＧＰＳであった場合のケースであり得る。一実施形態においては、追加の支援データのリクエストは、ＲＡＮ／ＳＲＮＣ１３０から、ステップ７ｉにおいて送られたＰＣＡＰポジション定期的リクエストメッセージまたはＰＣＡＰポジション定期的報告メッセージ（図６中では示されていない）のいずれかの中でＳＡＳ１３２に転送されることができ、また、リクエストされた支援データは、ＳＡＳ１３２によって、ステップ８ｉにおいて送られたＰＣＡＰポジション定期的レスポンスメッセージまたはＰＣＡＰポジション定期的結果メッセージ（図６の中では示されていない）のいずれかにおいて、ＲＡＮ／ＳＲＮＣ１３０に返されることができる。ＲＡＮ／ＳＲＮＣ１３０は、そのあと、支援データを、ＲＲＣ測定コントロールメッセージまたはＲＲＣ支援データ配信メッセージ（図６の中では示されていない）のいずれかにおいてＵＥ１２０に転送することができる。この実施形態は、ＳＡＳ１３２およびＲＡＮ／ＳＲＮＣ１３０がＡ−ＧＰＳポジショニングサポートをリスタート(re-start)する必要を避ける。別の実施形態においては、ステップ６ｉにおいて追加支援データのリクエストを受け取った後、ＲＡＮ／ＳＲＮＣ１３０は、このリクエストをＰＣＡＰポジションアクチベーションレスポンスメッセージにおいてＳＡＳ１３２に転送することができる（図６においては示されていない）。ＳＡＳ１３２は、そのあと、リクエストされた新しい支援データを準備し、これをおそらく新しいＰＣＡＰポジションアクチベーションリクエストメッセージにおける新しい定期的位置情報と共にＲＡＮ／ＳＲＮＣ１３０に送り（図６においては示されていない）、それは新しいトランザクションを開始する。ＲＡＮ／ＳＲＮＣ１３０は、そのあと、新しいＲＲＣ測定コントロールメッセージをＵＥ１２０に送り、前に開始された測定（ステップ５において）は、新しい支援データ（およびたぶん新しい報告インストラクション）で現在修正されていることを示す。この実施形態は、ＳＡＳ１３２およびＲＡＮ／ＳＲＮＣ１３０において、また、たぶんＵＥ１２０における定期的報告インストラクションを変更することにおいて、Ａ−ＧＰＳポジショニングサポートをリスタートする効果を有する。
【００６４】
別の実施形態においては、ＲＡＮ／ＳＲＮＣ１３０は、ＳＡＳ１３２からの支援データをリクエストするために３ＧＰＰ  ＴＳ  ２５．４５３に定義されるようなＰＣＡＰ情報交換プロシージャを呼び出すことができるが、それは現在、ＲＮＣセントリックモードのためのみに使用されている。この実施形態においては、ＲＡＮ／ＳＲＮＣ１３０は、図５におけるステップ３、４および５をコピーすることによって、ＳＡＳ１３２からの支援データをリクエストすることができる（図６においては示されていない）。このプロシージャをＳＡＳセントリックモードにおいても同様に使用するとき、ＳＡＳ１３２は、すべてのＰＣＡＰメッセージを同じポジショニングエベントに関連づけるセッションＩＤパラメータ(session ID parameter)を使用することにより、あるいはＵＥ１２０のこの特定のポジショニングエベントに割り付けられた既存のシグナリング接続を使用することにより、このプロシージャがＵＥ１２０についてのポジショニングエベントに属することに気付いている。
【００６５】
いずれの場合も、支援データを受け取った後に、ＵＥ１２０は、ＲＲＣ測定報告メッセージにおいて測定値をＲＡＮ／ＳＲＮＣ１３０に報告することを続け、それは次に、ＰＣＡＰポジション定期的リクエストおよびＰＣＡＰポジション定期的レスポンスのメッセージペアを、あるいは代わりに、上記に説明されるように、ＰＣＡＰポジション定期的報告およびＰＣＡＰポジション定期的結果のメッセージを続ける。ステップ６ｉにおけるＵＥ１２０による新しい支援データのリクエスト、および上記に説明された実施形態のうちの１つをとおしてのその準備もまた、メッセージフロー６００において一度よりも多く発生するかもしれない。
【００６６】
ある種の例外状態(certain exception conditions)が図６におけるメッセージフロー６００の間に時々発生することがあり、それは、ある追加のアクション(some additional action)を必要とする。もしＵＥ１２０がサービングセルを変更するがしかしＲＡＮ／ＳＲＮＣ１３０のサービスエリア内に残る場合は、ＲＡＮ／ＳＲＮＣ１３０は、ＳＡＳ１３２に、新しいセルの識別情報を含んでいるＰＣＡＰポジションパラメータ修正メッセージ(PCAP Position Parameter Modification message)を送ることにより、新しいセルをＳＡＳ１３２に通知することができる。このメッセージは、ＳＡＳセントリックモードにおけるシングルショットポジショニングでのＲＮＣ内セル変更の場合、（例えば、３ＧＰＰ  ＴＳ  ２５．３０５において）現在許可されているものと同じであるかもしれない。もし進行中のＲＲＣ測定プロシージャ(RRC measurement procedure)中にＲＲＣ状態変更(RRC state change)がある場合、ＲＡＮ／ＳＲＮＣ１３０はまた、ＳＡＳ１３２に、ＰＣＡＰポジションパラメータ修正メッセージを送ることができる。別のＲＮＣへのハードなハンドオーバ(hard handover)のような、ある種の他の例外状態(certain other exception conditions)のような場合には、ＵＥ１２０及び／又はＲＡＮ／ＳＲＮＣ１３０は、定期的位置プロシージャを途中停止する(abort)することができ、また、ＭＳＣ／ＳＧＳＮ１４０は、（例えば、新しいＲＡＮ／ＳＲＮＣへのシグナリングによって）プロシージャをリスタートすることができる。
【００６７】
例えば、もしＵＥ１２０あるいはＭＳＣ／ＳＧＳＮ１４０が、図４、５および６が現在示すあるいは前提とするＭＯ−ＬＲリクエストを介して定期的位置プロシージャをサポートすることができないか、あるいは、サポートすることに合意しない場合は、図４、５および６におけるＲＡＮベースの定期的位置報告メッセージが、以下に説明されるいくつかの小さな変更により、定期的位置報告についてのＭＴ−ＬＲ（図２Ａ）および定期的位置報告についてのＮＩ−ＬＲ（図２Ｂ）のために使用されることができる。通知およびプライバシ確認が図２Ａのステップ５において使用される場合は、もしＵＥ加入者がＭＴ−ＬＲの場合において位置リクエストを拒否しなければ、ＲＡＮベースの定期的位置報告が使用されることができる。図４、５および６におけるメッセージフローへの変更は、以下のとおりである。
【００６８】
図４において、ステップ１から４までが取り除かれる。代わりに、もしＵＥ１２０がアイドルモードに戻ってしまっている場合、（例えば、図２Ａにおけるステップ５の場合に説明されているように）ＭＳＣ／ＳＧＳＮ１４０はページングおよび認証を行なう。然しながら、（図２Ａの中のステップ５で示される）通知およびプライバシ確認はないに違いない、というのは、それは図２Ａにおけるメッセージフロー２００あるいは(必要ならば)図２Ｂにおけるメッセージフロー２１０の部分として先に行われてしまっているであろうという理由による。もしＵＥ１２０がアイドルモードにない場合、そのときは、ページングおよび認証は必要とされない。ステップ１２もまた取り除かれるが、ステップ１３は有効なままである。
【００６９】
図５および６においては、もしＵＥ１２０がアイドルモードにある場合、図４への変更について上記に説明されるように、ステップ１は、今、単に(just)ページングおよび認証を含んでいるべきである。ステップ１１は、今、図４におけるちょうどステップ１３（そしてステップ１２および１３の両方ではない）に対応する。
【００７０】
図４において示されるメッセージフロー４００の場合、比較的長いＭＯ−ＬＲトランザクションがステップ４からステップ１２まで生じるかもしれない。この時間の間、ＵＥ１２０は、各位置転送の成功か失敗かの知識を持たないかもしれない、そして、報告の完了後に定期的位置報告の結果が通知される。然しながら、オープンＭＯ−ＬＲトランザクション(open MO-LR transaction)は、ＵＥ１２０へのＣＭおよびＭＭ／ＧＭＭ接続を維持するのに、また、ＵＥ１２０がアイドルモードに戻るのを防ぐために、有用であり得る。ＬＣＳ更新サービス(update services)を使用して、定期的位置報告の進行状況(progress)をＵＥ１２０が通知されるのを維持することは望ましいかもしれない。
【００７１】
図７は、通知付きのＲＡＮベースの定期的位置報告(RAN-based periodic location reporting with notification)のためのメッセージフロー７００の一実施形態を示す。メッセージフロー７００もまた、図２Ａ、２Ｂおよび３におけるメッセージフロー２００、２１０および３００のステップ１０のためにそれぞれ使用されてもよい。メッセージフロー７００のステップ１から４までは、図４におけるメッセージフロー４００のステップ１から４までと同じである。ＵＥ１２０は、ＭＳＣ／ＳＧＳＮ１４０に、定期的位置(periodic location)を呼び出すために、ＬＣＳ  ＭＯ−ＬＲ位置サービス呼び出しメッセージ(LCS MO-LR Location Services Invoke message)を送る（ステップ４）。ＭＳＣ／ＳＧＳＮ１４０は、呼び出しを確認するために、ＵＥ１２０に、ＬＣＳ  ＭＯ−ＬＲリターン結果メッセージを送り（ステップ５）、そうすることによって、ＭＯ−ＬＲリクエストがサポートされるであろうという即時のフィードバックをＵＥ１２０に提供する。ＭＳＣ／ＳＧＳＮ１４０はまた、ＲＡＮ１３０に、定期的位置情報およびＬＣＳ  ＱｏＳを含んでいる位置リクエストメッセージを送る（ステップ６）。
【００７２】
メッセージフローは、そのあと、ＵＥ１２０についての最初の位置推定値を得るために、また、ＬＣＳクライアント１７０に位置推定値を転送するために、実行される（ステップ７ａ）。ステップ７ａは、図４におけるメッセージフロー４００のステップ６ａから１１ａまで、図５におけるメッセージフロー５００のステップ３から１０ａまで、あるいは、図６におけるメッセージフロー６００のステップ３から１０ａまでを含んでいてもよい。ＭＳＣ／ＳＧＳＮ１４０は、そのあと、最初の位置推定値がＬＣＳクライアント１７０に成功裡に転送されたことを示すために、ＵＥ１２０に、ＬＣＳ位置アップデート呼び出しメッセージ(LCS Location Update Invoke message)を送る（ステップ８ａ）。このメッセージはまた、例えば、次の定期的間隔に続く、次の位置報告エベントで、第２の位置推定値が転送されるであろうと、ＵＥ１２０に通知するように機能する(serve)ことができる。ＵＥ１２０は、通知の受取を確認するために、ＭＳＣ／ＳＧＳＮ１４０にＬＣＳ位置アップデートリターン結果メッセージを送る（ステップ９ａ）。このメッセージは、もしＵＥ１２０が定期的位置プロシージャをこの時点でキャンセルすることを望む場合は、次の位置報告の拒否を含むことができる。
【００７３】
各々の後に続く位置報告エベントｉ、但しｉ＝ｂ．．．ｎ、について、メッセージフローが、ＬＣＳクライアント１７０へのＵＥ１２０についての位置推定値を取得し転送するために実行され（ステップ７ｉ）、ＬＣＳ位置アップデート呼び出しメッセージが、位置転送の結果をＵＥ１２０に通知するためにＭＳＣ／ＳＧＳＮ１４０よって送られ（ステップ８ｉ）、そして、ＬＣＳ位置アップデートリターン結果メッセージが、通知を確認するためにＵＥ１２０によって送られる（ステップ９ｉ）。位置報告エベントのすべてが完了した後に、ＭＳＣ／ＳＧＳＮ１４０は、ＣＭ、ＭＭあるいはＧＭＭ、およびＲＲ／ＲＲＣのＵＥ１２０への接続のリリースを開始してもよい（ステップ１０）。
【００７４】
別の実施形態においては、ＬＣＳ  ＭＯ−ＬＲリターン結果メッセージは、図７中のステップ５においては送られずに、図４中のメッセージフロー４００と似たように、代わりにステップ９ｎの後に送られる。この場合、図７中のステップ８ａ．．．８ｎにおけるＬＣＳ位置アップデート呼び出しメッセージのＭＳＣ／ＳＧＳＮ１４０からＵＥ１２０への送信は、ＵＥ１２０に、ＵＥ１２０への各位置転送の結果と同様にＭＯ−ＬＲリクエストがサポートされるであろうというＵＥ１２０へのフィードバックを提供する。
【００７５】
代替実施形態においては、各ステップ８ｉにおけるＬＣＳ位置アップデート呼び出しメッセージと各ステップ９ｉにおけるＬＣＳ位置アップデートリターン結果メッセージは、それぞれ、ＬＣＳ通知呼び出しメッセージとＬＣＳ通知リターン結果に取り替えられ、それらは、３ＧＰＰ  ＴＳ  ２４．０８０において定義される現行の３ＧＰＰメッセージである。現行の３ＧＰＰメッセージの使用は、ＭＳＣ／ＳＧＳＮ１４０およびＵＥ１２０へのインプリメンテーションインパクト(implementation impacts)を軽減することができる。
【００７６】
さらに別の実施形態においては、ＬＣＳ位置アップデート呼び出しメッセージおよびＬＣＳ位置アップデートリターン結果メッセージのペアかまたはＬＣＳ通知呼び出しメッセージおよびＬＣＳ通知リターン結果メッセージのペアは、エベントの後（図７において示されるような）に代えて、各位置報告エベントに先立って交換される（図７においては示されていない）。この実施形態の場合、ＬＣＳ位置アップデート呼び出しメッセージあるいはＬＣＳ通知呼び出しメッセージは、位置推定値は次の位置報告エベントにおいて取得されＬＣＳクライアント１７０に転送されることをＵＥ１２０に通知する。ＵＥユーザは、そのとき、転送を拒否する、あるいは定期的位置報告をキャンセルする機会を与えられてもよい。メッセージはまた、ＵＥ１２０に、以前の転送の結果（例えば、もし位置推定値が得られなかった場合は、転送が成功したのか不成功であったのかどうか）を通知してもよい。さらに別の実施形態においては、ＬＣＳ位置アップデート呼び出しメッセージおよびＬＣＳ位置アップデートリターン結果メッセージのペアかまたはＬＣＳ通知呼び出しメッセージおよびＬＣＳ通知リターン結果メッセージのペアは、各位置報告エベントに先立って送られ、そして、これらのメッセージの最終のペアは、最後の位置報告エベントの後に送られる。各位置報告エベントより先のメッセージペアは、ＵＥ１２０に前の位置転送(previous location transfer)の結果（もしあれば）を伝え、ＵＥ１２０が転送を拒否するあるいはプロシージャをキャンセルすることを可能にし、そして、ＵＥ１２０に次の転送を通知する。最後の位置報告エベントの後のメッセージペアは、ＵＥ１２０に定期的位置報告の終了および位置転送の結果を通知する。
【００７７】
ＵＥ１２０が、それ自身の使用のために、あるいは、ＵＥ１２０が通信している（例えば、インターネットによってアクセスされる）ある外部アプリケーションのために、それ自身の位置を定期的に決定するために、定期的セルフロケーション(periodic self location)を実行することが望ましいかもしれない。もしＵＥ１２０がＵＥベースのモードをサポートする場合、そのときは、ＵＥ１２０は、たぶんＲＡＮ１３０とのどんなシグナリングもなしに、必要なときはいつでも、それ自身で位置推定値を導き出すことができる。然しながら、もしＵＥ１２０が、ＵＥ支援のモードをサポートするのみかポジショニング機能を有さない場合は、そのときは、セルフロケーションのための各ＭＯ−ＬＲリクエストについてＲＡＮ１３０における各位置トランザクションを定期的にセットアップしかつ解体する(set up and tear down)ために、もし各々のそのようなリクエストがシングルショット位置リクエスト(single shot location request)のみを開始するのであれば、オーバーヘッド(overhead)が背負いこまれる(incurred)であろう。このオーバヘッドは、定期的セルフロケーションについてＲＡＮ１３０の定期的ＬＣＳ機能を使用することによって軽減あるいは回避されることができる。
【００７８】
図８は、ＲＡＮベースのＭＯ  −ＬＲ定期的セルフロケーション−のためのメッセージフロー８００の一実施形態を示す。定期的セルフロケーションは、定期的位置報告の特別なケースとして見られることができ、ここでは、ＬＣＳクライアントは、外部のＬＣＳクライアント１７０の代わりにＵＥ１２０である。
【００７９】
メッセージフロー８００のステップ１から３までは、図４におけるメッセージフロー４００のステップ１から３までと同じである。ＵＥ１２０は、そのとき、ＭＳＣ／ＳＧＳＮ１４０に、定期的セルフロケーションをリクエストするためにＬＣＳ  ＭＯ−ＬＲ位置サービス呼び出しメッセージを送る（ステップ４）。このメッセージは、関連情報、例えば、定期的位置情報（例、開始時間、報告間隔、及び、停止時間、報告持続時間あるいは報告の設定回数のうちの１つ）、ＬＣＳ  ＱｏＳなど、を含んでいる。メッセージはまた、定期的位置推定値がＵＥ１２０に送られるべきであることを示す。ＭＳＣ／ＳＧＳＮ１４０は、ＵＥ１２０が、ＵＥについての加入プロファイルに基づいて、リクエストされた位置サービスに対し許可されることを、確認する（同様にステップ４）。もし位置リクエストが許可されるのであれば、そのときは、ＭＳＣ／ＳＧＳＮ１４０は、定期的セルフロケーションリクエストの受理を示すために、ＵＥ１２０にＬＣＳ  ＭＯ−ＬＲリターン結果メッセージを送る（ステップ５）。ＭＳＣ／ＳＧＳＮ１４０はまた、ＲＡＮ１３０に、定期的セルフロケーションリクエスト、定期的位置情報、ＵＥ機能、およびＬＣＳ  ＱｏＳを含んでいる位置リクエストメッセージを送る（ステップ６）。
【００８０】
メッセージフローはそのあと、ＵＥ１２０についての最初の位置推定値を得るために実行される（ステップ７ａ）。ステップ７ａは、図５におけるメッセージフロー５００のステップ３から８ａまで、あるいは図６におけるメッセージフロー６００のステップ３から８ａまで、を含むことができる。ＲＡＮ１３０は、ステップ７ａにおけるメッセージフローからＵＥ１２０についての位置推定値を受け取り、そして、ＭＳＣ／ＳＧＳＮ１４０に、この位置推定値および他の関連情報を含んでいる位置報告メッセージを送る（ステップ８ａ）。ＭＳＣ／ＳＧＳＮ１４０は、そのあと、ＵＥ１２０に、最初の位置推定値および関連情報を含んでいるＬＣＳ位置アップデートメッセージを送る（ステップ９ａ）。ＵＥ１２０は、最初の位置推定値の受取りを確認するＬＣＳ位置アップデート肯定応答メッセージを返す（ステップ１０ａ）。このメッセージはまた、定期的セルフロケーションをキャンセルする表示(indication)を、もしそのようなことがＵＥ１２０により望まれるのであれば、含むことができる。各々のその後のセルフロケーションエベントｉ、但しｉ＝ｂ．．．ｎ、について、メッセージフローは、ＵＥ１２０についての位置推定値を得るために（ステップ７ｉ）、そして位置推定値をＭＳＣ／ＳＧＳＮ１４０に送るために、実行される（ステップ８ｉ）。ＭＳＣ／ＳＧＳＮ１４０はそのあと、位置推定値をＵＥ１２０に返す（ステップ９ｉおよび１０ｉ）。位置報告エベントのすべてが完了した後、ＭＳＣ／ＳＧＳＮ１４０は、ＣＭ、ＭＭあるいはＧＭＭ、およびＲＲ／ＲＲＣのＵＥ１２０への接続のリリースを開始することができる。
【００８１】
別の実施形態においては、図４におけるメッセージフロー４００に似たように、ＬＣＳ  ＭＯ−ＬＲリターン結果メッセージは、図８の中のステップ５においては送られず、代わりにステップ１０ｎの後に送られる。別の実施形態においては、各ステップ９ｉにおけるＬＣＳ位置アップデートメッセージおよび各ステップ１０ｉにおけるＬＣＳ位置アップデート肯定応答は、それぞれ、現行の３ＧＰＰメッセージであるＬＣＳ通知呼び出しメッセージおよびＬＣＳ通知リターン結果メッセージと取り替えられる。この場合もやはり、現行の３ＧＰＰメッセージの使用は、ＭＳＣ／ＳＧＳＮ１４０およびＵＥ１２０へのインプリメンテーションインパクトを軽減することができる。
【００８２】
ＲＡＮベースの定期的位置報告はまた、ＧＥＲＡＮと通信する移動局（ＭＳ）について使用されてもよい。パケットモード定期的位置報告プロシージャ(packet mode periodic location reporting procedure)は、図１Ｂにおいて２Ｇ−ＳＧＳＮ１４０ａによって受け取られる定期的位置リクエストの場合に使用されることができる。
【００８３】
サーキットモード定期的位置報告プロシージャ(circuit mode periodic location reporting procedure)は、２Ｇ−ＭＳＣ１４０ｂによって受け取られる定期的位置リクエストの場合に使用されることができる。サーキットモードにおけるＧＥＲＡＮ定期的位置報告の場合、ＧＳＭにおける基地局サブシステム（ＢＳＳ）は定期的位置の間隔(intervals of periodic location)の間に、専用のシグナリングチャネルを動的にリリースし、後で再割り当てするための機能を有していないので、ＭＳが、定期的位置報告の全持続期間の間、専用モードで動作することができ、シグナリングチャネル(signaling channel)（例、ＳＤＣＣＨ）を割り当てられることができる。パケットモードにけるＧＥＲＡＮ定期的位置報告の場合、ＭＳは、ＭＳとＢＳＳとの間でメッセージを転送することが必要なときに、シグナリングチャネルを動的に割り当てられることができる。以下の説明では、ＵＥ１２０（ＵＭＴＳ専門用語）は、ＭＳ１２０（ＧＳＭ専門用語）と呼ばれる。ＭＳ１２０は、ＧＥＲＡＮ１３０ａにおいてＢＳＳと通信する。
【００８４】
図９は、パケットモードにおけるＧＥＲＡＮのためのＲＡＮベースの定期的位置報告のためのメッセージフロー９００の実施形態を示す。ＬＣＳクライアント１７０あるいはＭＳ１２０は、定期的にＬＣＳクライアント１７０にＭＳ１２０についての位置推定値を送るリクエストを開始することができる（ステップ１）。例えば、図２Ａ、２Ｂあるいは３の場合にそれぞれ上記に説明されるように、定期的位置(periodic location)は、ＭＴ−ＬＲ、ＮＩ−ＬＲあるいはＭＯ−ＬＲによって、開始されることができる。定期的位置リクエストは、ＳＧＳＮ１４０ａに、ＬＣＳクライアント１７０によって出されたＭＴ−ＬＲのための１つまたは複数のＧＭＬＣｓを経由して、あるいはＭＳ１２０によって出されたＭＯ−ＬＲのためのＢＳＳを経由して、転送されることができる。リクエストは、位置推定値を送るためのスケジュールあるいは条件（例、エベント）を識別する定期的位置情報を含むことができる。リクエストは、関与するエンティティ(participating entities)、例えば、GMLCｓ１５０、ＳＧＳＮ１４０ａ、ＭＳ１２０、およびＬＣＳクライアント１７０によって承認されることができる。定期的位置配信は、そのあと、ＭＳ１２０からのＭＯ−ＬＲによってか、またはＳＧＳＮ１４０ａによって、スターとされることができ、それは、ＭＳ１２０がアイドルモードに戻っている(has reverted)場合は、ページングおよび認証(paging and authentication)を実行することができる。
【００８５】
ＳＧＳＮ１４０ａは、ＢＳＳＧＰ実行位置リクエストメッセージ(BSSGP Perform Location Request message)を、ＭＳ１２０に現在サービングを行っているＢＳＳに送る（ステップ２）。このメッセージは、定期的位置リクエストを含み、そして更に、定期的位置情報、ＱｏＳ、及び／又は他の関連情報を含んでいる。ＢＳＳは、メッセージを受け取り、そして、リクエストがシングルショット位置(single shot location)よりは寧ろ定期的位置(periodic location)についてであることを認識する。ＢＳＳは、そのあと、ＢＳＳＭＡＰ−ＬＥ実行位置リクエストメッセージ(BSSMAP-LE Perform Location Request message)において定期的位置リクエストおよび定期的位置情報をＳＭＬＣ１３２に送る（ステップ３）。
【００８６】
ＳＭＬＣ１３２は、ＢＳＳからメッセージを受け取り、定期的位置リクエストを評価し(evaluate)、ポジショニング方法(positioning method)を選択する。もしＡ−ＧＰＳ及び／又はＥ−ＯＴＤが選択される場合は、そのときＳＭＬＣ１３２は、ＢＳＳに、ＢＳＳＭＡＰ−ＬＥコネクション型情報メッセージ(BSSMAP-LE Connection Oriented Information message)を送るが、これはＢＳＳＬＡＰ  ＭＳポジションコマンドメッセージ(BSSLAP MS Position Command message)を含んでおり、更にそれはＲＲＬＰ測定ポジションリクエストメッセージ(RRLP Measure Position Request message)（ステップ４）。ＢＳＳＬＡＰ  ＭＳポジションコマンドメッセージは、定期的位置(periodic location)がリクエストされているという指示(indication)を伝えることができ、また、ＢＳＳはこの情報を記録することができる。ＲＲＬＰ測定ポジションリクエストメッセージは、定期的位置情報、この情報のサブセット(subset)、あるいはこの情報の変換されたセットあるいはサブセットを含むことができる。ＲＲＬＰ測定ポジションリクエストメッセージはまた、ＭＳ１２０がＡ―ＧＰＳ及び／又はＥ−ＯＴＤ測定を実行するのを支援するための、そして、もしＭＳベースのポジショニングが選択されるのであれば、ＭＳ１２０が位置推定値を計算するのを支援するための、支援データを含むことがでる。もし支援データが１つのＲＲＬＰ測定ポジションリクエストメッセージに適合しない場合、そのときＳＭＬＣ１３２は、ＲＲＬＰ測定ポジションリクエストメッセージを送る前に、１つまたは複数のＲＲＬＰ支援データメッセージにおいて、ＭＳ１３２に、定期的位置情報を含む支援データおよび他の情報のうちのいくつかあるいはすべてを送ることができる（図９においては示されていない）。ＭＳ１２０は、そのあと、ＲＲＬＰ支援データ肯定応答メッセージで各ＲＲＬＰ支援データメッセージを確認するであろう。
【００８７】
ＢＳＳは、ＳＧＳＮ１４０ａに、ＳＭＬＣ１３２から受け取られたＲＲＬＰ測定ポジションリクエストメッセージを含んでいるＢＳＳＧＰポジションコマンドメッセージ(BSSGP Position Command message)を送る（ステップ５）。ＳＧＳＮ１４０ａは、そのあと、ＭＳ１２０に、ＳＭＬＣ１３２から受け取られたＲＲＬＰ測定ポジションリクエストメッセージを伝えるＴＯＭメッセージ(TOM message)を含んでいる論理リンク制御（ＬＬＣ）未確認情報（ＵＩ）フレームメッセージ(Logical Link Control (LLC) Unconfirmed Information (UI) Frame message)を送る（ステップ６）。ＭＳ１２０は、ＳＧＳＮ１４０ａからメッセージを受け取り、そして、ＲＲＬＰ測定ポジションリクエストメッセージにおいて（あるいは前のＲＲＬＰ支援データメッセージにおいて）含まれた定期的位置情報に基づいた定期的位置リクエストを認識する。もしＡ−ＧＰＳが選択される場合、そのときは、ＭＳ１２０は、ＲＲＬＰ測定ポジションリクエストメッセージあるいは前の支援データメッセージを受け取ると支援データ（もしあれば）を使用して、ＧＰＳ衛星からの信号を取得し、測定することができる。もしＥ−ＯＴＤが選択される場合、そのときは、ＭＳ１２０は、近くの基地局からの信号を取得して測定することを始めることができる。ＭＳ１２０はまた、もしＥ−ＯＴＤとＡ−ＧＰＳとが両方とも選択される場合は、ＧＰＳ衛星と基地局との両方からの信号を取得して測定することができる。
【００８８】
最初のスケジュールされた位置推定が期限になったとき、あるいは、位置推定が必要とされる最初のセットの条件（例、エベント）が発生するとき、ＭＳ１２０は、Ａ−ＧＰＳ及び／又はＥ−ＯＴＤの測定を実行する。もしＭＳベースのポジショニングが選択された場合、そのときは、ＭＳ１２０はさらに、測定値から位置推定値を得る。ＭＳ１２０は、そのあと、ＳＧＳＮ１４０ａに、ＲＲＬＰ測定ポジションレスポンスメッセージにおいて測定値か位置推定値を送る（ステップ７ａ）。ＲＲＬＰ測定ポジションレスポンスメッセージは、ＴＯＭメッセージにおいて搬送され、それは、今度はＬＬＣ  ＵＩフレームメッセージにおいて搬送される。ＴＯＭメッセージヘッダー(TOM message header)は、ＲＲＬＰ測定ポジションレスポンスメッセージは最後のものではないことを示しているフラグ(flag)を含んでいる。ＲＲＬＰ測定ポジションレスポンスメッセージはまた、もっと多くの定期的位置推定値が後で提供されるだろうという表示を搬送することができる。ＭＳ１２０は、もし測定値あるいは位置推定値が単一のメッセージに適合しない場合は、１つより多くのＲＲＬＰ測定ポジションレスポンスメッセージを送ってもよい（図９においては示されていない）。
【００８９】
ＳＧＳＮ１４０ａは、ＭＳ１２０からＬＬＣ  ＵＩフレームメッセージを受け取り、そして、ＢＳＳＧＰポジションレスポンスメッセージにおいてＲＲＬＰ測定ポジションレスポンスメッセージをＢＳＳに転送する（ステップ８ａ）。ＢＳＳＧＰポジションレスポンスメッセージヘッダーは、これが最後のＲＲＬＰ測定ポジションレスポンスメッセージではないことを示しているフラグを含んでいる。ＢＳＳは、ＳＧＳＮ１４０ａからＢＳＳＧＰポジションレスポンスメッセージを受け取り、そして、ＢＳＳＭＡＰ−ＬＥコネクション型情報メッセージにおいて搬送されるＢＳＳＬＡＰ  ＭＳポジションレスポンスメッセージの中でＲＲＬＰ測定ポジションレスポンスメッセージを、ＳＭＬＣ１３２に転送する（ステップ９ａ）。ＢＳＳＬＡＰ  ＭＳポジションレスポンスメッセージヘッダーは、これが最後のＲＲＬＰ測定ポジションレスポンスメッセージではないことを示しているフラグを含んでいる。ＢＳＳは、（ステップ２からの、そしてたぶんステップ４からの）そしてまたフラグ設定からの定期的位置リクエストに気付いている。ＢＳＳはこのようにして、ＭＳ１２０からの更なるＲＲＬＰ測定ポジションレスポンスメッセージを予期し、そして、すべての測定値あるいは位置推定値（ＲＲＬＰ測定ポジションレスポンスメッセージ内部の）がＭＳ１２０から転送されてしまう前は、定期的位置(periodic location)を途中停止しない。
【００９０】
ＳＭＬＣ１３２は、ＭＳ１２０によって提供される測定値から位置推定値を計算する、あるいは、ＭＳによって提供されるどんな位置推定値も確認する(verifies)。ＳＭＬＣ１３２はそのあと、ＢＳＳＭＡＰ−ＬＥ実行位置報告メッセージ(BSSMAP-LE Perform Location Report message)において計算されたあるいは確認された位置推定値をＢＳＳに送る（ステップ１０ａ）。このメッセージは、ＢＳＳに、定期的位置(periodic location)が未だ終えられていないことを、また、更なる位置推定値がＳＭＬＣ１３２によって後で提供されるであろうことを、通知する。ＢＳＳは、ＳＭＬＣ１３２から位置推定値を受け取り、そして、ＢＳＳＧＰ実行位置報告メッセージ(BSSGP Perform Location Report message)においてこの位置推定値をＳＧＳＮ１４０ａに送る（ステップ１１ａ）。このメッセージは、ＳＧＳＮ１４０ａに、定期的位置(periodic location)が終えられていないことを、また、更なる位置推定値が後で提供されるであろうことを、通知する。ＳＧＳＮ１４０ａはそのあと、位置推定値を、例えば、図４においてステップ８ａからｌｌａまでを使用してGMLC経由で、あるいは、ＢＳＳ経由で、ＬＣＳクライアント１７０に転送する。
【００９１】
ステップ７ａからｌｌａまでは１つの位置報告エベントのためのものである。これらのステップは、スケジュールされあるいはトリガされる各追加の位置推定値の場合に繰り返されることができる。もし、利用可能な支援データがもはや有効ではないためにＭＳ１２０が測定値あるいは位置推定値を得ることができない場合、そのときＭＳ１２０は、後のステップ７で送られるＲＲＬＰ測定ポジションレスポンスメッセージの中でより多くの支援データのリクエストを含めることができる。このデータリクエストは、測定値あるいは位置推定値の代わりに、あるいはその測定値に加えて送られるかもしれない。ステップ９においてこのリクエストを受取り次第、ＳＭＬＣ１３２は、１つあるいは複数のＲＲＬＰ支援データメッセージを使用して、リクエストされた支援データをＭＳ１２０に送るだろう。一実施形態においては、ＳＭＬＣ１３２およびＭＳ１２０の両方は、支援データの転送を、（例えば、ステップ４、５および６において始められた）定期的位置(periodic location)についてのペンディングのＲＲＬＰトランザクションと平行して生じる追加のＲＲＬＰトランザクションとして扱う。ＭＳ１２０は、ステップ７ａから１１ａまでを繰り返すことによって、ＳＭＬＣ１３２に定期的な測定値あるいは位置推定値を送り続ける。別の実施形態においては、より多くの支援データについてのリクエストを送るとき、ＭＳ１２０は、ＳＭＬＣ１３２への定期的な測定値あるいは位置推定値の転送を終了することができる。例えば、ＭＳ１２０は、より多くの支援データのリクエストを搬送するＲＲＬＰ測定ポジションレスポンスメッセージにおいてエラー表示を含めることにより、定期的位置報告の終了を示すことができる。その場合、後のステップ７において送られるＴＯＭメッセージヘッダーは、これが最後のＲＲＬＰ測定ポジションレスポンスメッセージであることを示しているフラグを含むことができる。ＢＳＳがその後のステップ８においてＳＧＳＮ１４０ａからこのフラグを受け取るとき、ＢＳＳは、この最後のＲＲＬＰ測定ポジションレスポンスメッセージを、ＳＭＬＣ１３２に送り、そして、ＭＳ１２０からのこれ以上のＲＲＬＰ測定ポジションレスポンスメッセージを期待しない。ＳＭＬＣ１３２は、ステップ４から１１までを繰り返すことによって、ＭＳ１２０からの定期的測定あるいは位置推定値の転送をリスタートすることができる。ＳＭＬＣ１３２は、リクエストされた支援データを、ＲＲＬＰ測定ポジションリクエストメッセージ及び／又は１つあるいは複数のＲＲＬＰ支援データメッセージにおいて、ＭＳ１２０に送ることができる。
【００９２】
ＭＳ１２０は、定期的位置(periodic location)についての最終の測定値あるいは位置推定値をＳＧＳＮ１４０ａに送る（ステップ７ｎ）。測定値あるいは位置推定値は、ＲＲＬＰ測定ポジションレスポンスメッセージにおいて送られ、ＲＲＬＰ測定ポジションレスポンスメッセージはＴＯＭメッセージの中で搬送され、ＴＯＭメッセージはさらにＬＬＣ  ＵＩフレームメッセージの中で搬送される。これらのメッセージは、これが最終のＲＲＬＰ測定ポジションレスポンスメッセージであることを示すフラグをＴＯＭメッセージヘッダーが含んでいる以外は、ステップ７ａにおいて使用されるものと同じである。ＲＲＬＰ測定ポジションレスポンスメッセージは、これが最後の定期的測定値あるいは位置推定値であることを示すパラメータを含むことができる。ステップ８ｎから１１ｎまでは、ステップ８ａから１１ａまでに似ている。然しながら、最終のＲＲＬＰ測定ポジションレスポンスメッセージが送られていることを示しているフラグは、ステップ８ｎにおいてＳＧＳＮ１４０ａによって送られるＢＳＳＧＰポジションレスポンスメッセージにおいて、また、ステップ９ｎにおいてＢＳＳによって送られるＢＳＳＬＡＰ  ＭＳポジションレスポンスメッセージにおいて、含まれることができる。ＳＭＬＣ１３２は、定期的位置プロシージャが終了したことをＢＳＳに通知するために、ステップ１０ａにおけるＢＳＳＭＡＰ−ＬＥ実行位置報告メッセージの代わりに、ステップ１０ｎにおいてＢＳＳＭＡＰ−ＬＥ実行位置レスポンスメッセージを送ることができる。ＢＳＳは、定期的位置プロシージャが終了したことをＳＧＳＮ１４０ａに通知するために、ステップ１１ａにおけるＢＳＳＧＰ実行位置報告メッセージの代わりに、ステップ１１ｎにおいてＢＳＳＧＰ実行位置レスポンスメッセージを送ることができる。新しいポジショニングプロシージャがＳＭＬＣ１３２によって開始されなければ、ＢＳＳは、ＭＳ１２０からのこれ以上のＲＲＬＰ測定ポジションレスポンスメッセージを期待しなし。ＳＭＬＣ１３２は、ステップ４から９ｎまでを繰り返すことによって、さらに定期的位置(periodic location)を開始することができる。ＳＧＳＮ１４０ａは、ステップ２から１１ｎまでを繰り返すことによって、定期的位置報告を続けることができる。そうでなければ、ＳＧＳＮ１４０ａは、定期的位置報告が今完了することを、ＬＣＳクライアント１７０に示すことができる。
【００９３】
図９におけるメッセージフロー９００の間に、更なるアクションを必要とするある種の例外状態が発生するかもしれない。もしＭＳ１２０がサービングセルを変更するが同じＢＳＳのサービスエリア内に残る場合、そのときは、ＢＳＳは、新しいセルの識別情報を含んでいるＢＳＳＭＡＰ−ＬＥ実行位置情報メッセージをＳＭＬＣに送ることによって、新しいセルをＳＭＬＣ１３２に通知することができる。他のいくつかの例外状態、例えば、新しいＢＳＳへのセル変更、ＳＧＳＮ内のＰＲＳルーティングエリアアップデート(intra-SGSN GPRS routing area update)、あるいはＴＭＳＩ再割り当てなど、については、ＭＳ１２０及び／又はＢＳＳは、定期的位置プロシージャを途中停止することができ、また、ＳＧＳＮ１４０ａは、例えば、新しいＢＳＳへのシグナリングによりプロシージャをリスタートすることができる。
【００９４】
図１０は、サーキットモードにおけるＧＥＲＡＮの場合のＲＡＮベースの定期的位置報告のためのメッセージフロー１０００の一実施形態を示す。サーキットモードのためのメッセージフロー１０００は、パケットモードのためのメッセージフロー９００に似ている。相違は、ＳＧＳＮ１４０ａが２Ｇ−ＭＳＣ１４０ｂと取り替えられること、ＳＧＳＮ１４０ａとＢＳＳとの間のＢＳＳＧＰメッセージが、対応するＢＳＳＭＡＰメッセージと取り替えられること、そして、ＢＳＳとＭＳ１２０との間のＲＲＬＰメッセージの転送がより直接であること、である。
【００９５】
ＬＣＳクライアント１７０あるいはＭＳ１２０は、ＭＳ１２０についての位置推定値を定期的にＬＣＳクライアント１７０に送るようにリクエストを開始することができる（ステップ１）。リクエストは、１つ以上のGMLCｓを経由してあるいはＢＳＳを経由して、２Ｇ−ＭＳＣ１４０ｂに転送されることができる。リクエストは、定期的位置情報を含むことができ、また、関与するエンティティ、例えば、ＧＭＬＣｓ１５０、２Ｇ−ＭＳＣ１４０ｂ、ＭＳ１２０、およびＬＣＳクライアント１７０によって承認されることができる。定期的位置配信はそのあと、ＭＳ１２０からのＭＯ−ＬＲによるかまたは、もしＭＳ１２０がアイドルモードに戻っているならばページングおよび認証を行なうことができる２Ｇ−ＭＳＣ１４０ｂによって、始められることができ。
【００９６】
２Ｇ−ＭＳＣ１４０ｂは、ＢＳＳＭＡＰ実行位置リクエストメッセージ(BSSMAP Perform Location Request message)を、ＭＳ１２０に現在サービングを行っているＢＳＳに送る（ステップ２）。このメッセージは定期的位置リクエストを含んでおり、定期的位置情報、ＱｏＳ、および他の関連情報をさらに含んでいる。ＢＳＳは、ＢＳＳＭＡＰ−ＬＥ実行位置リクエストメッセージにおける定期的位置リクエストをＳＭＬＣ１３２に送る（ステップ３）。ＳＭＬＣ１３２は、メッセージを受け取り、定期的位置リクエストを評価し、そして、ポジショニング方法を選択する。もしＡ−ＧＰＳ及び／又はＥ−ＯＴＤが選択される場合、そのときは、ＳＭＬＣ１３２は、ＢＳＳに、ＢＳＳＬＡＰ  ＭＳポジションコマンドメッセージ(BSSLAP MS Position Command message)を含んでいるＢＳＳＭＡＰ−ＬＥコネクション型情報メッセージ(BSSMAP-LE Connection Oriented Information message)を送る、なお、ＢＳＳＬＡＰ  ＭＳポジションコマンドメッセージは更にＲＲＬＰ測定ポジションリクエストメッセージ(RRLP Measure Position Request message)を含んでいる（ステップ４）。
【００９７】
ＢＳＳは、ＭＳ１２０に、ＳＭＬＣ１３２から受け取られたＲＲＬＰ測定ポジションリクエストメッセージを含んでいるＲＲアプリケーション情報メッセージ(RR Application Information message)を送る（ステップ５）。ＭＳ１２０は、ＢＳＳからメッセージを受け取り、ＲＲＬＰ測定ポジションリクエストメッセージにおいて（あるいは前のＲＲＬＰ支援データメッセージにおいて）含まれる定期的位置情報に基づいた定期的位置リクエストを認識する。ＭＳ１２０は、（Ａ−ＧＰＳのための）ＧＰＳ衛星からの、かつ／または（Ｅ−ＯＴＤのための）基地局の近くの、信号を取得しそして測定することができる。
【００９８】
最初のスケジュールされた位置推定値が期限になったとき、あるいは、位置推定値が必要とされる最初のセットの条件（例、エベント）が発生するとき、ＭＳ１２０は、Ａ−ＧＰＳ及び／又はＥ−ＯＴＤの測定を実行し、そして、もしＭＳベースのポジショニングが選択されたならば、更に位置推定値を得る。ＭＳ１２０は、そのあと、ＢＳＳに、ＲＲアプリケーション情報メッセージの中で搬送されるＲＲＬＰ測定ポジションレスポンスメッセージにおいて測定値あるいは位置推定値を送る（ステップ６ａ）。ＲＲアプリケーション情報メッセージヘッダーは、これが最後のＲＲＬＰ測定ポジションレスポンスメッセージではないことを示しているフラグを含む。ＲＲＬＰ測定ポジションレスポンスメッセージはまた、もっと定期的位置推定値が後で提供されるであろうという表示を伝えることができる。
【００９９】
ＢＳＳは、ＭＳ１２０からＲＲアプリケーション情報メッセージを受け取り、そして、ＢＳＳＭＡＰ−ＬＥコネクション型情報メッセージの中で搬送されるＢＳＳＬＡＰ  ＭＳポジションレスポンスメッセージにおいて、ＲＲＬＰ測定ポジションレスポンスメッセージをＳＭＬＣ１３２に転送する（ステップ７ａ）。ＢＳＳＬＡＰ  ＭＳポジションレスポンスメッセージヘッダーは、これが最後のＲＲＬＰ測定ポジションレスポンスメッセージではないことを示しているフラグを含む。ＳＭＬＣ１３２は、ＭＳ１２０によって提供される測定値からの位置推定値を計算する、あるいは、ＭＳによって提供されるどんな位置推定値も確認する。ＳＭＬＣ１３２はそのあと、ＢＳＳＭＡＰ―ＬＥ実行位置報告メッセージにおいて、計算されたあるいは確認された位置推定値をＢＳＳに送る（ステップ８ａ）。ＢＳＳは、ＳＭＬＣ１３２から位置推定値を受け取り、そして、ＢＳＳＭＡＰ実行位置報告メッセージにおいて、この位置推定値を２Ｇ−ＭＳＣ１４０ｂに送る（ステップ９ａ）。２Ｇ−ＭＳＣ１４０ｂはそのあと、位置推定値を、例えば、ＧＭＬＣまたはＢＳＳを経由して、ＬＣＳクライアント１７０に転送する。
【０１００】
ステップ６ａから９ａまでは１つの位置報告エベントのためのものである。これらのステップは、スケジュールされているかあるいはトリガされている各追加の位置推定のために繰り返されることができる。ＭＳ１２０は、後のステップ６においてＲＲＬＰ測定ポジションレスポンスメッセージの中でリクエストを送ることにより、より多くの支援データを得ることができる。ＳＭＬＣ１３２およびＭＳ１２０は、支援データの転送を、定期的位置(periodic location)についてのペンディングのＲＲＬＰトランザクションと平行して生じる追加のＲＲＬＰトランザクションとして扱う。あるいは、ＭＳ１２０は、例えば、これが最後のＲＲＬＰ測定ポジションレスポンスメッセージであることを示すために、ＲＲアプリケーション情報メッセージヘッダーの中にフラグを含めることによって、定期的測定値あるいは位置推定値の転送を終了することができる。ＳＭＬＣ１３２は、そのあと、ステップ４から９までを繰り返すことによって、ＭＳ１２０からの定期的測定値あるいは位置推定値の転送をリスタートすることができる。
【０１０１】
ＭＳ１２０は、ＢＳＳに定期的位置(periodic location)についての最終的な測定値あるいは位置推定値を送る（ステップ６ｎ）。測定値あるいは位置推定値はＲＲＬＰ測定ポジションレスポンスメッセージにおいて送られ、それはＲＲアプリケーション情報メッセージにおいて搬送される。これらのメッセージは、ＲＲアプリケーション情報メッセージヘッダーが、これが最終のＲＲＬＰ測定ポジションレスポンスメッセージであることを示しているフラグを含んでいること以外は、ステップ６ａにおいて使用されるものと同じである。ＲＲＬＰ測定ポジションレスポンスメッセージは、これが最後の定期的測定値あるいは位置推定値であることを示しているパラメータを含むことができる。ステップ７ｎから９ｎまでは、ステップ７ａから９ａまでに似ている。然しながら、ステップ７ｎにおいてＢＳＳによって送られたＢＳＳＬＡＰ  ＭＳポジションレスポンスメッセージは、最終のＲＲＬＰ測定ポジションレスポンスメッセージが送られていることを示しているフラグを含んでいる。ＳＭＬＣ１３２は、ステップ８ｎにおいてＢＳＳＭＡＰ−ＬＥ実行位置レスポンスメッセージ(BSSMAP-LE Perform Location Response message)を送ることができ、そして、ＢＳＳは、定期的位置プロシージャが終了したことを示すためにステップ９ｎにおいてＢＳＳＭＡＰ実行位置レスポンスメッセージ(BSSMAP Perform Location Response message)を送ることができる。ＳＭＬＣ１３２は、ステップを４から７ｎまでを繰り返すことにより、もっと定期的位置報告を開始することができる。２Ｇ−ＭＳＣ１４０ｂは、ステップを２から９ｎまでを繰り返すことにより、定期的位置報告を続けることができる。そうでなければ、２Ｇ−ＭＳＣ１４０ｂは、定期的位置報告が今完了することをＬＣＳクライアント１７０に示すことができる。
【０１０２】
図１０におけるメッセージフロー１０００の間に、更なるアクションを必要とするある種の例外状態が発生するかもしれない。もしＭＳ１２０がサービングセルを変更するが同じＢＳＳのサービスエリア内に残る場合、あるいは、もしある他のＲＲ管理プロシージャがＢＳＳとＭＳ１２０との間で行われ、それがＢＳＳとＭＳ１２０との間にサーキットモード無線シグナリングリンク(circuit mode radio signaling link)を依然と残す場合、そのときは、ＢＳＳは、ポジショニングを途中停止することができ、また、ＳＭＬＣ１３２は、シングルショットかあるいは定期的ポジショニングのためにＭＳ１２０においてポジショニングをリスタートすることができる。あるいは、ＢＳＳは、ＳＭＬＣ１３２に、任意のセル変更を（例えば、ＢＳＳＭＡＰ−ＬＥ実行位置情報メッセージを送ることによって）通知することができ、また、ＭＳ１２０、ＢＳＳおよびＳＭＬＣ１３２は、定期的ポジショニングを続けることができる。新しいＢＳＳへのハンドオーバのような、いくつかの他の例外状態については、ＭＳ１２０及び／又はＢＳＳは定期的位置プロシージャを途中停止することができ、また、２Ｇ−ＭＳＣ１４０ｂは、例えば、新しいＢＳＳへのシグナリングによりプロシージャをリスタートすることができる。
【０１０３】
図９および１０における多くのメッセージは、３ＧＰＰ  ＴＳ  ４３．０５９において説明されており、そして、ＭＳのワンショット位置(one shot location)のために使用される。これらのメッセージは、定期的位置のインプリメンテーションを単純化するために可能な場合はいつも、定期的位置のために使用されることができる。他のメッセージもまた、図９および１０の場合に使用されてもよい。
【０１０４】
図４から１０までは、ＲＡＮベースの定期的位置報告のために使用されることができる例示的なメッセージフローを示す。図の４から７まで、９、および１０、におけるメッセージフローは、定期的位置リクエストが許可されたあとに、図２Ａおよび３において示されるＭＴ−ＬＲおよびＭＯ−ＬＲの定期的プロシージャの一部として、それぞれ使用されることができる。これらのメッセージフローはまた、スタンドアロンのプロシージャとして使用されることもでき、従って、ＭＴ−ＬＲおよびＭＯ−ＬＲの定期的プロシージャの一部であることに制限されない。ＲＡＮベースの定期的位置報告のための他のメッセージフローはまた、ＭＴ−ＬＲおよびＭＯ−ＬＲの定期的プロシージャと共に使用されるために実施される(implemented)こともできる。
【０１０５】
ＵＥ１２０は最初に、定期的ＬＣＳ機能を有さずそして図４から１０までにおいてメッセージフローをサポートしないＲＡＮ（例、ＧＥＲＡＮ）と通信するかもしれない。定期的位置報告は、そのあと、他の方法で、例えば、ＵＥ１２０、あるいは、ＬＣＳクライアント１７０へのＵＥ１２０についての単一の位置推定値を取得しそして転送するために定期的にメッセージフローを開始するネットワークエンティティ（例、ＧＭＬＣ１５０）を用いて、達成されることができる。もしＵＥ１２０が続いて、定期的ＬＣＳ機能を有するＲＡＮ（例、ＵＴＲＡＮ）のサービスエリア内で移動する場合、そのときＵＥ１２０は、新しいＲＡＮに切り換えることができ、また、この新しいＲＡＮの定期的ＬＣＳ機能は、効率的に定期的位置報告を提供するために利用されることができる。
【０１０６】
簡単にするために、ＲＡＮベースの定期的位置報告についての上記説明は、１つのＧＭＬＣ（例えば、図ＩＡにおいて示されるような）を備えた展開(deployment)および各位置推定のために実行されるポジショニングを前提としている。ＲＡＮベースの定期的位置報告はまた、複数のＧＭＬＣｓ（例えば、図ＩＢにおいて示されるような）を備えた展開について使用されることができる。改良された効率は、（１）複数のＧＭＬＣｓを備えた展開についてＧＬＭＣショートサーキット、および（２）１つまたは複数のＧＭＬＣｓを備えた展開についてＭＯ−ＬＲショートサーキット、を使用することにより達成されることができる。ＧＬＭＣショートサーキットは、図１ＢにおいてＲ−ＧＭＬＣ１５０ｃとＭＳＣ／ＳＧＳＮ１４０との間での直接のメッセージの交換を指し、それによって、Ｖ−ＧＭＬＣ１５０ａおよびＨ−ＧＭＬＣ１５０ｂをバイパス(bypassing)し、あるいは短絡化(short-circuiting)する。ＭＯ−ＬＲショートサーキットは、たとえ、適切な位置推定値がＵＥ１２０に利用可能であって、ＭＯ−ＬＲショートサーキットの使用が認められる場合であっても、各位置報告エベントについてのポジショニングのバイパスを指す。ＧＭＬＣショートサーキット、ＭＯ−ＬＲショートサーキット、あるいは両方のタイプのショートサーキットは、システムリソースを節約するために、また、ＬＣＳクライアント１７０への位置転送についてより速いレスポンスを供給するために使用されることができる。ＭＯ−ＬＲショートサーキットかあるいはＲＡＮベースの定期的報告は、ＵＥベースのポジショニングのために使用されることができる。然しながら、もし、ＵＥが、ＭＯ−ＬＲショートサーキットあるいはＬＣＳクライアントをサポートしない場合、あるいは、関係しているＰＬＭＮのうちのいずれかが、ＭＯ−ＬＲショートサーキットの使用を否定する場合、そのときは、ＲＡＮベースの定期的ポジショニングのみが、ＵＥベースのポジショニングに適することができる。反対に、もしＲＡＮ（例、ＧＥＲＡＮ）がＲＡＮベースの定期的報告をサポートしない場合、そのときは、ＭＯ−ＬＲショートサーキットのみが適することができる（もし許可され、かつサポートされる場合）。ＵＥ支援のポジショニングあるいはネットワークベースのポジショニングの場合（例、ＵＥ支援のポジショニングを唯一サポートするＵＥの場合）、ＭＯ−ＬＲショートサーキットは使用されず、ＲＡＮベースのポジショニングのみが適することができる。従って、ＭＯ−ＬＲショートサーキットおよびＲＡＮベースの定期的報告は、異なる状況の下で適用可能であり得る。
【０１０７】
ＭＯ−ＬＲショートサーキットの使用は、例えば、ビリングと加入の点などについて、ＵＥの正確さ及び信頼性、あるいはＵＥの完全性(integrity)における信頼の欠如（例、スプーフィング(spoofing)）に対処するためのような、様々な理由のために、コントロールされることができる。例えば、もしＵＥ１２０が、ＲＡＮ１３０による確認なしにＭＳＣ／ＳＧＳＮ１４０に位置推定値を直接に提供することを信頼される場合は、ＭＯ−ＬＲショートサーキットの使用は認められることができる。ＧＬＭＣショートサーキットの使用もまた、ビリング、加入などに関連する理由のためにコントロールされることができる。
【０１０８】
一実施形態においては、１つのエンティティ（例、ＵＥ１２０、ＭＳＣ／ＳＧＳＮ１４０、あるいはＲ−ＧＭＬＣ１５０ｃ）は、後の位置報告エベントのために、ＧＭＬＣショートサーキット及び／又はＭＯ−ＬＲショートサーキットを使用する許可をリクエストすることができる。任意の他のエンティティ（例、ＭＳＣ／ＳＧＳＮ１４０、Ｖ−ＧＭＬＣ１５０ａ、Ｈ−ＧＭＬＣ１５０ｂ、Ｒ−ＧＭＬＣ１５０ｃ、ＵＥ１２０およびＬＣＳクライアント１７０）は、各タイプのショートサーキットのリクエストを受理あるいは拒否することができる。別の実施形態においては、１つのエンティティ（例、ＵＥ１２０、ＭＳＣ／ＳＧＳＮ１４０、あるいはＲ−ＧＭＬＣ１５０ｃ）は、ＧＭＬＣショートサーキット及び／又はＭＯ−ＬＲショートサーキットを、これらのショートサーキットを使用することを特にリクエストすること無しに、サポートするための意向(willingness)あるいは機能を示すことができる。Ｖ−ＧＭＬＣ１５０ａ、Ｈ−ＧＭＬＣ１５０ｂ、Ｒ−ＧＭＬＣ１５０ｃ、ＵＥ１２０およびＬＣＳクライアント１７０の中の任意のエンティティは、そのあと、各タイプのショートサーキットをサポートする意向あるいは機能を、受理あるいは拒否することができる。あるエンティティ（例、Ｈ−ＧＭＬＣ１５２）は、もしすべてのエンティティがそのショートサーキットについて意向および機能を示す場合、各タイプのショートサーキットを使用するべきかどうかを決定することができる。すべての実施形態の場合、ＧＭＬＣショートサーキットを使用するリクエストおよびＭＯ−ＬＲショートサーキットを使用するリクエストは、独立したリクエストとして扱われることができる。更に、ＧＭＬＣショートサーキット及び／又はＭＯ−ＬＲショートサーキットを使用することについてのどんな合意も、ＵＥ１２０にＭＳＣ／ＳＧＳＮ１４０によって送られたリスト中のＰＬＭＮｓのすべてに適用可能であり得る。
【０１０９】
さらに実施形態においては、ＵＥ１２０、ＭＳＣ／ＳＧＳＮ１４０、Ｖ―ＧＭＬＣ１５０ａ、Ｈ−ＧＭＬＣ１５０ｂ、およびＲ−ＧＭＬＣ１５０ｃの中のどのエンティティも、ＧＬＭＣショートサーキットを使用するべきかどうかを、また、ＭＯ−ＬＲショートサーキットを使用するべきかどうかを、自主的に決定することができる。
【０１１０】
図２ＡにおけるＭＴ−ＬＲメッセージフロー２００の場合、Ｒ−ＧＭＬＣ１５０ｃは、ＬＣＳサービスリクエストメッセージをＨ−ＧＭＬＣ１５０ｂに送ることができ、それは、ＬＣＳサービスリクエストメッセージをＶ−ＧＭＬＣ１５０ａに送ることができ、それは、定期的位置報告についてリクエストするために、加入者位置提供せよメッセージ(Provide Subscriber Location message)を、ＭＳＣ／ＳＧＳＮ１４０に送ることができる。各エンティティによって送られるメッセージは、（１）もしＧＭＬＣショートサーキットが好まれる場合は、Ｒ−ＧＭＬＣ１５０ｃのアドレス、および（２）ＭＯ−ＬＲショートサーキットが認められるのかあるいは好まれるのかどうかについての表示、を含むことができる。一実施形態においては、Ｒ−ＧＭＬＣ１５０ｃ、Ｈ−ＧＭＬＣ１５０ｂ、Ｖ−ＧＭＬＣ１５０ａ、およびＭＳＣ／ＳＧＳＮ１４０は、各々、ＧＭＬＣショートサーキットを受理あるいは拒否することができ、また、各々、ＭＯ−ＬＲショートサーキットを受理あるいは拒否することができる。
【０１１１】
図３におけるＭＯ−ＬＲメッセージフロー３００の場合、ＵＥ１２０は、メッセージフロー３００のステップ４においてＭＳＣ／ＳＧＳＮ１４０に送られるＬＣＳ  ＭＯ−ＬＲ位置サービス呼び出しメッセージの中に、（１）ＧＭＬＣショートサーキット使用のリクエスト、及び／又は（２）ＭＯ−ＬＲショートサーキット使用のリクエスト（例えば、ＵＥ１２０がＵＥベースのモードをサポートする場合）を含むことができる。別の実施形態においては、ＭＳＣ／ＳＧＳＮ１４０は、ＵＥ１２０からの表示なしに、１つあるいは両方のリクエストをそれ自体決定することができる。いずれの場合も、ショートサーキットリクエスト（１つあるいは両方）は、Ｖ−ＧＭＬＣ１５０ａに、次にＨ−ＧＭＬＣ１５０ｂに、次にＲ−ＧＭＬＣ１５０ｃに、そして次にＬＣＳクライアント１７０に、送られることができる。ＬＣＳクライアント１７０は、ＵＥリクエスト（単数または複数）についてのレスポンスを、Ｒ−ＧＭＬＣ１５０ｃに送り、それはそのレスポンスを、Ｈ−ＧＭＬＣ１５０ｂに送り、それはそのレスポンスを、Ｖ−ＧＭＬＣ１５０ａに送り、それはそのレスポンスをＭＳＣ／ＳＧＳＮ１４０に送る。各エンティティによって送られるレスポンスは、前のエンティティから受け取られるレスポンスを組み込み（もしあれば）、そして、定期的位置リクエストの受理あるいは拒否、および、各ショートサーキットリクエストの受理あるいは拒否を示すことができる（もし送られれば）。
【０１１２】
ＭＴ−ＬＲメッセージフロー２００とＭＯ−ＬＲメッセージフロー３００の両方の場合、ＭＳＣ／ＳＧＳＮ１４０は、（上記にリストされた情報に加えて）次の情報を受け取ることができる：
１．ＵＥ１２０が、ＲＡＮ１３０においての確認無しに、ＭＳＣ／ＳＧＳＮ１４０に位置推定値を直接に提供することを承認されるかどうか、あるいは予想されるかどうか、を示すＭＯ−ＬＲショートサーキット表示、  
２．位置推定値がＲ−ＧＭＬＣ１５０ｃに、直接に送られることができるかどうか、あるいは直接に送られるであろうかどうか、を示すＧＭＬＣショートサーキット表示、  
３．例えば、もしＧＭＬＣショートサーキットがリクエストされていないかあるいは拒否される場合、Ｈ−ＧＭＬＣ１５０ｂに位置情報を送るために使用されるべきＨ−ＧＭＬＣ１５０ｂのアドレス、  
４．例えば、もしＧＭＬＣショートサーキットが受理される場合、ＭＳＣ／ＳＧＳＮ１４０からＲ−ＧＭＬＣ１５０ｃに直接に位置情報を送るために使用されるべきＲ−ＧＭＬＣ１５０ｃのアドレス。
【０１１３】
もしＭＯ−ＬＲショートサーキットが許可される場合、そのときＵＥ１２０は、ＭＳＣ／ＳＧＳＮ１４０に送られるＬＣＳ  ＭＯ−ＬＲ位置サービス呼び出しメッセージにおいて、ＵＥで利用可能な位置推定値を含むことができる。ＲＡＮ１３０あるいはＳＡＳ１３２は、ＵＥ１２０についての位置推定値を計算する必要がないであろう。
【０１１４】
もしＧＭＬＣショートサーキットが受理される場合、そのときＭＳＣ／ＳＧＳＮ１４０は、Ｒ−ＧＭＬＣ１５０ｃのアドレスを保存することができる、あるいは、ＵＥ１２０は、各位置報告エベントにおいてＲ−ＧＭＬＣアドレスを送ることができる。ＭＳＣ／ＳＧＳＮ１４０は、そのあと、各位置推定値を、Ｒ−ＧＭＬＣアドレスを使用してＲ−ＧＭＬＣ１５０ｃ直接に送ることができ、また、Ｖ−ＧＭＬＣ１５０ａおよびＨ−ＧＭＬＣ１５０ｂをバイパスすることができる。
【０１１５】
明確にするために、図２から１０までの中のメッセージフローの各々は、特定のシーケンスのステップを示す。各メッセージフローは、そのメッセージフローのために示されたステップに追加のステップ、示されたステップよりも少ないステップ、あるいは、示されたステップとは異なるステップ、を含んでいてもよい。各メッセージフローのステップは、そのメッセージフローにおいて示された順序で、あるいは異なる順序で、実行されることができる。各メッセージフローの各ステップは、一般に、任意の数のメッセージ交換、任意のエンティティでの任意のタイプの処理、などを、含むことができる。
【０１１６】
同様に明確にするために、３ＧＰＰによって使用される（あるいは、３ＧＰＰに適用可能な）特定のメッセージが、図２から１０までの中のメッセージフローのために示されている。他のネットワークおよび他の位置アーキテクチャは、典型的に、上記に説明されたメッセージとは異なるメッセージを使用する。一般に、任意のシグナリングが、位置報告のために上記に説明された機能性を達成するために様々なエンティティの間で関連情報を交換するために使用されることができる。シグナリングは、他のある形式で送信されるメッセージ、パケット、表示、フラグあるいはデータを備えることができる。
【０１１７】
明確にするために、位置サービスをサポートするコントロールプレーン(control plane)を利用する、３ＧＰＰベースのネットワークのための技術が、特に上記に説明されている。技術はまた、他のネットワークおよび他の位置アーキテクチャ、例えば、オープンモバイルアライアンス(Open Mobile Alliance)（ＯＭＡ）によって広められたプリＳＵＰＬアーキテクチャ(pre-SUPL architecture)およびＳＵＰＬアーキテクチャおよび、ＩＳ−８８１および３ＧＰＰ２  Ｘ．Ｓ０００２において記述された３ＧＰＰ２コントロールプレーンアーキテクチャ、Ｘ．Ｓ００２４において記述された３ＧＰＰ２ユーザプレーンアーキテクチャ、などのために使用されることができる。コントロールプレーン（それはまた一般にシグナリングプレーン(signaling plane)と呼ばれる）は、上位層のアプリケーションのためのシグナリングを搬送するためのメカニズムであり、ネットワークに特有のプロトコルおよびシグナリングメッセージを用いて実施されることができる。ユーザプレーン(user plane)は、上位層のアプリケーションのためのデータを搬送するためのメカニズムであり、ユーザプレーンベアラ(user-plane bearer)を使用し、それは、当技術分野においてよく知られているユーザデータグラムプロトコル（ＵＤＰ）、転送制御プロトコル（ＴＣＰ）、およびインターネットプロトコル（ＩＰ）、のようなプロトコルを用いて典型的に実施される。位置サービスおよびポジショニングをサポートするメッセージは、コントロールプレーンアーキテクチャにおけるシグナリングの一部として、また、ユーザプレーンアーキテクチャにおけるデータの一部として搬送される。然しながら、メッセージのコンテンツは、両方のアーキテクチャにおいて似ているかもしれないし、あるいは、同一でさえあるかもしれない。メッセージが異なるかもしれないが、ショートサーキット技術はまた、回路交換（ＣＳ）ベースのモードおよびパケット交換（ＰＳ）ベースのモードのために使用されることができる。
【０１１８】
図１１は、訪問先／サービングネットワーク(visited/serving network)１１０２、ホームネットワーク(home network)１１０４、およびリクエストティングネットワーク(requesting network)１１０６を含んでいるＳＵＰＬ展開１１００(SUPL deployment)を示す。訪問先ネットワーク１１０２は、無線ネットワーク１１３０およびビジティングＳＵＰＬ位置プラットフォーム(visiting SUPL location platform)（Ｖ−ＳＬＰ）１１５０ａを含んでいる。無線ネットワーク１１３０は、無線ネットワークのサービスエリア内に位置する無線デバイスに無線通信を提供する。無線デバイスはまた、ＳＵＰＬ使用可能端末(SUPL enabled terminal)（ＳＥＴ））と呼ばれる。Ｖ−ＳＬＰ１１５０ａは、ＳＵＰＬ位置センタ(SUPL location center)（ＳＬＣ）１１８０を含んでおり、また、ＳＵＰＬポジショニングセンタ(SUPL positioning center)（ＳＰＣ）１１８２を含むことができる。ＳＬＣ１１８０は、Ｖ−ＧＭＬＣ１５０ａに似ており、そして、位置サービスのための様々な機能を実行する。ＳＰＣ１１８２は、ＳＭＬＣ／ＳＡＳ１３２に似ており、無線デバイスについてのポジショニングをサポートする。ホームネットワーク１１０４は、ホームネットワーク１１０４についてのポジショニングおよび位置サービスをサポートするホームＳＬＰ（Ｈ−ＳＬＰ）１１５０ｂを含んでいる。リクエスティングネットワーク１１０６は、ＬＣＳクライアントについてのポジショニングおよび位置サービスをサポートするリクエスティングＳＬＰ（Ｒ−ＳＬＰ）１１５０ｃを含んでいる。
【０１１９】
ここに説明された技術は、ＳＵＰＬ展開１１００において使用されることができる。ＲＡＮベースの定期的位置報告の場合、Ｖ−ＳＬＰ１１５０ａあるいはＨ−ＳＬＰ１１５０ｂは、例えば、上記に説明されるように、無線デバイス１１２０についての定期的位置報告を調整し、そしてコントロールすることができる。この場合、ＲＡＮは、特には関与しないであろう、そして、ＲＡＮの役割は、Ｖ−ＳＬＰ１１５０ａ及び／又はＨ−ＳＬＰ１１５０ｂによって、かつ／または、これらのいずれかの中のＳＰＣによって（例えば、ＳＰＣ１１８２によって）、引き受けられるであろう。ＵＥ１１２０とＶ−ＳＬＰ１１５０ａあるいはＨ−ＳＬＰ１１５０ｂとの間のメッセージインタラクション(message interaction)（例、ＲＲＣ測定コントロールメッセージおよびＲＲＣ測定報告メッセージの転送）は、このとき、例えば、３ＧＰＰコントロールプレーンシグナリングを使用する代わりにＯＭＡによって定義されるＳＵＰＬポジショニングプロトコルおよびＴＣＰ／ＩＰを使用してメッセージ（例、ＲＲＣメッセージ）が異なって転送される、ということを除いて、図５および６におっけるＵＥ１２０とＲＡＮ／ＳＲＮＣ１３０との間のこれらのメッセージの交換に似ているであろう。非プロキシーモードにおけるＧＭＬＣショートサーキットの場合、無線デバイス１１２０あるいはＶ−ＳＬＰ１１５０ａは、位置推定値を直接にＲ−ＳＬＰ１１５０ｃに送ることができ、それはそのあと、位置推定値をＬＣＳクライアント１１７０に送り、Ｈ−ＳＬＰ１１５０ｂをそして恐らくＶ−ＳＬＰ１１５０ａをバイパスする。プロキシーモードにおけるサーキットの場合、無線デバイス１１２０は、位置推定値をＨ−ＳＬＰ１１５０ｂに送ることができ、それはそのあと、位置推定値をＲ−ＳＬＰ１１５０ｃに送り、それは更に、位置推定値をＬＣＳクライアント１１７０に送り、Ｖ−ＳＬＰ１１５０ａとのインタラクションをバイパスする。
【０１２０】
図１２は、図１における３ＧＰＰベースのネットワーク１００の中の様々なネットワークエンティティおよびＵＥ１２０のブロック図を示す。ＲＡＮ１３０は、無線通信をネットワーク１００に提供し、典型的には、少なくとも１つのＲＮＣおよび複数の基地局あるいはノードＢｓを含んでいる。簡単にするために、１つのプロセッサ１２３０、１つのメモリユニット１２３２、１つのトランシーバ１２３４、および１つの通信ユニット１２３６のみが、ＲＡＮ１３０について示されている。各ＲＮＣおよび各基地局は、典型的には、１つまたは複数のプロセッサ、メモリユニット、通信ユニットなどを含んでおり、また、各基地局は、典型的には、トランシーバ１２３４を含んでいる。同様に簡単にするために、１つのプロセッサ１２２０、１つのメモリユニット１２２２、および１つのトランシーバ１２２４のみが、ＵＥ１２０について示されている。ＵＥ１２０は、無線通信をサポートすることができ、そして、１つまたは複数の受信機、１つまたは複数のアンテナ、１つまたは複数のプロセッサなどを用いてＧＰＳ信号を処理することができる。
【０１２１】
ダウンリンク上で、ＲＡＮ１３０の中の基地局は、トラフィックデータ、シグナリング、およびパイロットを、それらのサービスエリア内のＵＥｓに送信する。これらの様々なタイプのデータは、アンテナを経由して送信されるダウンリンク信号を生成するために、プロセッサ１２３０によって処理され、またトランシーバ１２３４によって条件付けられる(conditioned)。ＵＥ１２０で、１つまたは複数の基地局からのダウンリンク信号が、アンテナを経由して受け取られ、トランシーバ１２２４によって条件付けられ、そして、位置サービスについて様々なタイプの情報を得るためにプロセッサ１２２０によって処理される。例えば、プロセッサ１２２０は、受信信号（これらはポジショニングのために使用されることができる）の到着の時間、上記に説明されたメッセージフローのために使用されるデコードされたメッセージ、などを得ることができる。メモリユニット１２２２および１２３２は、ＵＥ１２０およびＲＡＮ１３０で、プロセッサ１２２０および１２３０のためのプログラムコードおよびデータをそれぞれ保存する。アップリンク上で、ＵＥ１２０は、トラフィックデータ、シグナリング、およびパイロットを、ＲＡＮ１３０の中の１つまたは複数の基地局に送信することができる。これらの様々なタイプのデータは、ＵＥアンテナを経由して送信されるアップリンク信号を生成するために、プロセッサ１２２０によって処理され、またトランシーバ１２２４によって条件付けられる。ＲＡＮ１３０で、ＵＥ１２０からのアップリンク信号および他のＵＥｓは、トランシーバ１２３４によって受け取られ、また条件付けられ、そして、様々なタイプの情報（例、データ、シグナリング、報告など）を得るために、プロセッサ１２３０によってさらに処理される。通信（Ｃｏｍｍ）ユニット１２３６は、ＲＡＮ１３０がＳＭＬＣ／ＳＡＳ１３２およびＭＳＣ／ＳＧＳＮ１４０と通信することを可能にする。
【０１２２】
ＭＳＣ／ＳＧＳＮ１４０は、ＭＳＣ／ＳＧＳＮ１４０のための処理を実行するプロセッサ１２４０、プロセッサ１２４０のためのプログラムコードおよびデータを保存するメモリユニット１２４２、および、ＭＳＣ／ＳＧＳＮ１４０がＲＡＮ１３０、ＳＭＬＣ／ＳＡＳ１３２、および他のネットワークエンティティとデータ／コアネットワーク１２０２を経由して通信することを可能にする通信ユニット１２４４、を含んでいる。ＳＭＬＣ／ＳＡＳ１３２は、ＳＭＬＣ／ＳＡＳ１３２のための処理を実行するプロセッサ１２５０、プロセッサ１２５０のためのプログラムコードおよびデータを保存するメモリユニット１２５２、およびＳＭＬＣ／ＳＡＳ１３２が、ＲＡＮ１３０およびＭＳＣ／ＳＧＳＮ１４０と通信することを可能にする通信ユニット１２５４、を含んでいる。一般に、各ネットワークエンティティは、１つまたは複数のプロセッサ、メモリユニット、通信ユニット、コントローラなどを含むことができる。データ／コアネットワーク１２０２は、コアネットワーク、及び／又は、他のプライベート(private)／パブリック(public)のデータネットワーク含んでもよい。
【０１２３】
ここに説明された技術は、様々な手段によって実施されることができる。例えば、本技術は、ハードウェア、ファームウェア、ソフトウェア、あるいはそれの組合せにおいて実施されることができる。ハードウェアインプリメンテーションの場合、各エンティティで処理を実行するために使用されるユニットは、１つまたは複数の特定用途向け集積回路（ＡＳＩＣｓ）、デジタル信号プロセッサ（ＤＳＰｓ）、デジタル信号処理デバイス（ＤＳＰＤｓ）、プログラマブル論理デバイス（ＰＬＤｓ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡｓ）、プロセッサ、コントローラ、マイクロコントローラ、マイクロプロセッサ、電子デバイス、ここに説明された機能(function)を実行するように設計された他の電子ユニット、あるいはそれらの組合せの中で、インプリメントされることができる。
【０１２４】
ソフトウェアインプリメンテーションの場合、本技術は、ここに説明された機能を実行するモジュール（例、プロシージャ、関数、など）を用いてインプリメントされてもよい。ソフトウェアコードは、メモリユニット（例、図１２の中のメモリユニット１２２２、１２３２、１２４２、あるいは１２５２）の中に保存され、プロセッサ（例、プロセッサ１２２０、１２３０、１２４０、あるいは１２５０）によって実行されることができる。メモリユニットは、プロセッサ内で、あるいはプロセッサの外部でインプリメントされることができる。
【０１２５】
開示された実施形態の以上の説明は、当業者の誰もが本発明を作りまたは使用するのを可能とするように提供されている。これらの実施形態の様々の修正は、当業者には容易に明らかであろう、そして、ここに定義された包括的な原理は本発明の精神或いは範囲を逸脱することなく他の実施形態に適用されることができる。従って、本発明は、ここに示された実施形態に限定されるように意図されてはおらず、ここに開示された原理及び新規な特徴と整合する最も広い範囲が与えられるべきものである。
【図面の簡単な説明】
【０１２６】
【図１Ａ】図１Ａは３ＧＰＰベースのネットワークを示す。
【図１Ｂ】図１Ｂは、複数のネットワークを含んでいる３ＧＰＰベースの展開を示す。
【図２Ａ】図２Ａは、ＭＴ−ＬＲの定期的位置報告のためのメッセージフローを示す。
【図２Ｂ】図２Ｂは、ＮＩ−ＬＲの定期的位置報告のためのメッセージフローを示す。
【図３】図３は、ＭＯ−ＬＲの定期的位置報告のためのメッセージフローを示す。
【図４】図４は、ＲＡＮベースの定期的位置報告のためのメッセージフローを示す。
【図５】図５は、ＲＮＣセントリックモードにおけるＲＡＮベースの定期的位置報告のためのメッセージフローを示す。
【図６】図６は、ＳＡＳセントリックモードにおけるＲＡＮベースの定期的位置報告のためのメッセージフローを示す。
【図７】図７は、通知付のＲＡＮベースの定期的位置報告のためのメッセージフローを示す。
【図８】図８は、ＲＡＮベースのＭＯ−ＬＲ定期的セルフロケーションのためのメッセージフローを示す。
【図９】図９は、パケットモードにおけるＧＥＲＡＮのためのＲＡＮベースの定期的位置報告のためのメッセージフローを示す。
【図１０】図１０は、サーキットモードにおけるＧＥＲＡＮのためのＲＡＮベースの定期的位置報告のためのメッセージフローを示す。
【図１１】図１１は別のネットワーク展開を示す。
【図１２】図１２は、図１における様々なネットワークエンティティのブロック図を示す。
【図１Ａ】
2009513036.tif 000003
【図１Ｂ】
2009513036.tif 000004
【図２Ａ】
2009513036.tif 000005
【図２Ｂ】
2009513036.tif 000006
【図３】
2009513036.tif 000007
【図４】
2009513036.tif 000008
【図５】
2009513036.tif 000009
【図６】
2009513036.tif 000010
【図７】
2009513036.tif 000011
【図８】
2009513036.tif 000012
【図９】
2009513036.tif 000013
【図１０】
2009513036.tif 000014
【図１１】
2009513036.tif 000015
【図１２】
2009513036.tif 000016
【国際調査報告】
2009513036.tif 000017
2009513036.tif 000018
2009513036.tif 000019