(57)【特許請求の範囲】
【請求項１】
位置決定サービスをサポートする方法であって、
ネットワークエンティティによって、ユーザ装置(UE)のための位置決定サービスの要求を受信するステップと、
前記ネットワークエンティティによって、ユーザプレーンの位置決定法を介して位置決定サーバと通信し、前記UEのための前記位置決定サービスをサポートするステップと、
前記ネットワークエンティティによって、制御プレーンの位置決定法を介して前記UEと通信し、前記UEのための前記位置決定サービスをサポートするステップと、
前記ネットワークエンティティによって、前記ユーザプレーンの位置決定法と前記制御プレーンの位置決定法で、切替動作するステップと
を含む、方法。
【請求項２】
前記UEのための位置推定を、前記位置決定サーバまたは前記UEから取得するステップと、
前記要求に応答して、前記UEのための前記位置推定を返すステップと
をさらに含む、請求項1に記載の方法。
【請求項３】
前記位置決定サーバと通信する前記ステップが、前記位置決定サーバから、前記ユーザプレーンの位置決定法のための第1のメッセージを受信するステップを含み、前記UEと通信する前記ステップが、前記制御プレーンの位置決定法のための第2のメッセージを前記UEに送信するステップを含み、前記切替動作するステップが、前記第1のメッセージの中の情報の少なくとも一部を、前記第2のメッセージに移送するステップを含む、請求項1に記載の方法。
【請求項４】
前記UEと通信する前記ステップが、前記UEから、前記制御プレーンの位置決定法のための第3のメッセージを受信するステップを含み、前記位置決定サーバと通信する前記ステップが、前記ユーザプレーンの位置決定法のための第4のメッセージを前記位置決定サーバに送信するステップを含み、前記切替動作するステップが、前記第3のメッセージの中の情報の少なくとも一部を、前記第4のメッセージに移送するステップを含む、請求項3に記載の方法。
【請求項５】
前記第1のメッセージが、Radio Resourece Location Services(LCS) Protocol(RRLP)測位プロトコルのためのものであり、前記第2のメッセージが、Radio Resource Control(RRC)測位プロトコルのためのものである、請求項3に記載の方法。
【請求項６】
前記ユーザプレーンの位置決定法が、Secure User Plane Location(SUPL)を含み、前記制御プレーンの位置決定法が、3GPPの制御プレーンの位置決定法を含む、請求項1に記載の方法。
【請求項７】
前記ネットワークエンティティが、前記位置決定サーバと通信するための前記UEとして動作し、前記UEの測位能力を前記位置決定サーバに提供し、前記位置決定サーバが、前記UEの前記測位能力に基づいて支援を提供する、請求項1に記載の方法。
【請求項８】
前記位置決定サービスが、前記UEの位置、前記UEへの支援データの送達、または、前記UEの位置と前記UEへの支援データの送達の両方を決定するための、測位を含む、請求項1に記載の方法。
【請求項９】
前記位置決定サービスが、前記UEの位置を求めるための、アシスト型全地球的航法衛星システム(A-GNSS)を含む、請求項1に記載の方法。
【請求項１０】
前記ネットワークエンティティが、Home Node B(HNB)またはラジオネットワークコントローラ(RNC)を含む、請求項1に記載の方法。
【請求項１１】
ワイヤレス通信のための装置であって、
ネットワークエンティティによって、ユーザ装置(UE)のための位置決定サービスの要求を受信するための手段と、
前記ネットワークエンティティによって、ユーザプレーンの位置決定法を介して位置決定サーバと通信し、前記UEのための前記位置決定サービスをサポートするための手段と、
前記ネットワークエンティティによって、制御プレーンの位置決定法を介して前記UEと通信し、前記UEのための前記位置決定サービスをサポートするための手段と、
前記ネットワークエンティティによって、前記ユーザプレーンの位置決定法と前記制御プレーンの位置決定法で、切替動作するための手段と
を含む、装置。
【請求項１２】
前記位置決定サーバと通信するための前記手段が、前記位置決定サーバから、前記ユーザプレーンの位置決定法のための第1のメッセージを受信するための手段を含み、前記UEと通信するための前記手段が、前記制御プレーンの位置決定法のための第2のメッセージを前記UEに送信するための手段を含み、前記切替動作するための手段が、前記第1のメッセージの中の情報の少なくとも一部を、前記第2のメッセージに移送するための手段を含む、請求項11に記載の装置。
【請求項１３】
前記ネットワークエンティティが、前記位置決定サーバと通信するための前記UEとして動作し、前記UEの測位能力を前記位置決定サーバに提供し、前記位置決定サーバが、前記UEの前記測位能力に基づいて支援を提供する、請求項11に記載の装置。
【請求項１４】
ワイヤレス通信のための装置であって、
ネットワークエンティティによって、ユーザ装置(UE)のための位置決定サービスの要求を受信し、前記ネットワークエンティティによって、ユーザプレーンの位置決定法を介して位置決定サーバと通信して、前記UEのための前記位置決定サービスをサポートし、前記ネットワークエンティティによって、制御プレーンの位置決定法を介して前記UEと通信して、前記UEのための前記位置決定サービスをサポートし、前記ネットワークエンティティによって、前記ユーザプレーンの位置決定法と前記制御プレーンの位置決定法で切替動作するように構成される、少なくとも1つのプロセッサ
を含む、装置。
【請求項１５】
前記少なくとも1つのプロセッサが、前記位置決定サーバから、前記ユーザプレーンの位置決定法のための第1のメッセージを受信し、前記制御プレーンの位置決定法のための第2のメッセージを前記UEに送信し、前記第1のメッセージの中の情報の少なくとも一部を、前記第2のメッセージに移送するように構成される、請求項14に記載の装置。
【請求項１６】
前記ネットワークエンティティが、前記位置決定サーバと通信するための前記UEとして動作し、前記UEの測位能力を前記位置決定サーバに提供し、前記位置決定サーバが、前記UEの前記測位能力に基づいて支援を提供する、請求項14に記載の装置。
【請求項１７】
少なくとも1つのコンピュータに、ネットワークエンティティによって、ユーザ装置(UE)のための位置決定サービスの要求を受信させるためのコードと、
前記少なくとも1つのコンピュータに、前記ネットワークエンティティによって、ユーザプレーンの位置決定法を介して位置決定サーバと通信させ、前記UEのための前記位置決定サービスをサポートさせるためのコードと、
前記少なくとも1つのコンピュータに、前記ネットワークエンティティによって、制御プレーンの位置決定法を介して前記UEと通信させ、前記UEのための前記位置決定サービスをサポートさせるためのコードと、
前記少なくとも1つのコンピュータに、前記ネットワークエンティティによって、前記ユーザプレーンの位置決定法と前記制御プレーンの位置決定法で、切替動作させるためコードと
を含むコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、2010年4月14日に出願された、「HNB Location」という表題の米国特許仮出願第61/324156号の優先権を主張し、上記の仮出願は本出願の譲受人に譲渡され、全体が参照により本明細書に組み込まれる。
【０００２】
本開示は全般に通信に関し、より具体的には、ワイヤレスネットワークにおいてHome Node B(HNB)を介した位置決定サービスをサポートするための技法に関する。
【背景技術】
【０００３】
HNBは、ますます普及が進みつつあり、家庭、オフィス、店舗、集合住宅などのような様々な位置において、より広範囲に配備されるようになっている、家庭用の基地局である(フェムトセルまたはフェムト基地局と呼ばれることがある)。これらのHNBは、通常、ワイヤレスネットワーク事業者(普通は認可された無線周波数を使用する)のための基地局として動作し、無線カバレッジの改善、スループットの向上、ならびに/または、ネットワーク事業者および/もしくはユーザに対する他の利益の実現のために、用いられ得る。特定の位置に注意深く配備されネットワーク事業者により管理されるマクロ基地局とは異なり、HNBは、あらゆる位置において、ユーザにより自由にかつ無計画に配備され得る。
【０００４】
HNBは、カバレッジの中の1つまたは複数のユーザ装置(UE)のための、通信をサポートすることができる。HNBまたはHNBと通信するUEの位置を知ることが、望ましいことがある。たとえば、HNBが現在の位置において動作することが許可されている(たとえば、HNBによりサポートされる無線周波数を使用するための免許を関連するネットワーク事業者が有する、地理的な領域内にHNBがある)ことを確認するために、HNBの位置を知ることが必要になり得る。別の例として、UEのユーザは、UEを用いて緊急通報を行うことがある。そして、UEの位置が求められ、その位置はユーザに緊急の援助を送るために用いられ得る。UEまたはHNBの位置を知ることが有用または必要である状況が、他にも多くある。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
デバイス(たとえば、HNBまたはUE)は、ネットワークからの支援が全くなくても、自身の位置を自動的に求める能力を有し得る。たとえば、デバイスは、単体の全地球的航法衛星システム(GNSS)をサポートすることができ、GNSSの中の衛星から受信された信号に基づいて、位置を求めることができ得る。単体のGNSSにより得られる位置推定は、高い正確性を有し得る。しかし、単体のGNSSは、初期位置算出時間(TTFF)が比較的長いこと、非常に低い信号強度では衛星を検出できないことなどのような、いくつかの欠点を有し得る。したがって、HNBおよびUEのための、単体のGNSSよりも性能を向上できる技法が、極めて望まれ得る。
【課題を解決するための手段】
【０００６】
HNBおよびHNBと通信するUEのための、位置決定サービスをサポートするための技法が、本明細書で説明される。位置決定サービスは、アシスト型GNSS(A-GNSS)を含んでもよく、A-GNSSは、単体のGNSSに対していくつかの利点を有し得る。
【０００７】
ある態様では、HNBと通信するUEのための位置決定サービスは、ユーザプレーンの位置決定法と制御プレーンの位置決定法との間で、HNBを切替動作（inter-work）させることによって、サポートされ得る。一設計では、HNBは、UEのための位置決定サービスの要求を受信することができる。HNBは、ユーザプレーンの位置決定法を介して位置決定サーバと通信し、UEのための位置決定サービスをサポートすることができる。HNBは、制御プレーンの位置決定法を介してUEと通信し、UEのための位置決定サービスをサポートすることもできる。以下で説明されるように、HNBは、ユーザプレーンの位置決定法と制御プレーンの位置決定法との間で、切替動作することができる。この方式はまた、UEのための位置決定サービスをサポートするために、他のネットワークエンティティ(HNB以外)により実行されてもよい。
【０００８】
別の態様では、位置決定サーバは、HNBおよびUEのための、位置決定サービスおよびA-GNSSをサポートするために用いられ得る。位置決定サーバは、HNBゲートウェイ(HNB GW)に結合されてよく、HNB GWは、位置決定サーバによりラジオネットワークコントローラ(RNC)と見なされ得る。一設計では、HNBは、UEのための位置決定サービスの要求を受信することができる。HNBは、UEのための位置決定サービスをサポートするために、HNG GWを介して、位置決定サーバとPositioning Calculation Application Part(PCAP)メッセージを交換することができる。PCAPメッセージは、(i)HNBとHNB GWとの間では第1のプロトコルのメッセージで、(ii)HNB GWと位置決定サーバとの間では第2のプロトコルのメッセージで移送され得る。HNBは、UEのための位置決定サービスをサポートするために、UEとRadio Resource Control(RRC)メッセージを交換することができる。
【０００９】
本開示の様々な態様および特徴が、以下でさらに詳細に説明される。
【図面の簡単な説明】
【００１０】
【図１】例示的なワイヤレスネットワークを示す図である。
【図２】ユーザプレーンの位置決定法と制御プレーンの位置決定法との間で、HNBによる切替動作によって、UEのための位置決定サービスをサポートするためのメッセージフローを示す図である。
【図２Ａ】図2の続きで、ユーザプレーンの位置決定法と制御プレーンの位置決定法との間で、HNBによる切替動作によって、UEのための位置決定サービスをサポートするためのメッセージフローを示す図である。
【図３】別の例示的なワイヤレスネットワークを示す図である。
【図４】図3の様々なネットワークエンティティにおける、例示的なプロトコルスタックを示す図である。
【図５】UEのためのA-GNSSをサポートするためのメッセージフローを示す図である。
【図５Ａ】図５に続きで、UEのためのA-GNSSをサポートするためのメッセージフローを示す図である。
【図６】HNB GW内のハンドオーバーの間に、UEの位置決定手順を継続するための、メッセージフローを示す図である。
【図６Ａ】図６の続きで、HNB GW内のハンドオーバーの間に、UEの位置決定手順を継続するための、メッセージフローを示す図である。
【図７】HNBのためのA-GNSSをサポートするためのメッセージフローを示す図である。
【図８】UEのための位置決定サービスをサポートするための処理を示す図である。
【図９】UEのための位置決定サービスをサポートするための処理を示す図である。
【図１０】UEのための位置決定サービスをサポートするための処理を示す図である。
【図１１】HNBのための位置決定サービスをサポートするための処理を示す図である。
【図１２】UEおよび様々なネットワークエンティティのブロック図である。
【発明を実施するための形態】
【００１１】
デバイス(たとえば、HNBおよびUE)のための位置決定サービスをサポートするための、本明細書で説明される技法は、「第3世代パートナーシッププロジェクト」(3GPP)および「第3世代パートナーシッププロジェクト2」(3GPP2)という名称の組織により定義されるものを含む、様々なワイヤレスネットワークおよび無線技術に対して用いられ得る。たとえば、技術は、3GPPにより定義されるUniversal Terrestrial Radio Access(UTRA)を実装する広帯域符号分割多重接続(WCDMA)ネットワーク、3GPPにより定義されるEvolved Universal Terrestrial Radio Access(E-UTRA)を実装するLong Term Evolution(LTE)ネットワークなどに対して用いることができる。WCDMAは、Universal Mobile Telecommunication System(UMTS)の一部である。LTEは、3GPP Evolved Packet System(EPS)の一部である。WCDMA、LTE、UTRA、E-UTRA、UMTSおよびEPSは、3GPPからの文書で説明される。技術は、他のワイヤレスネットワーク(たとえば、3GPPおよび3GPP2ネットワーク)および他の無線技術に対しても、用いられ得る。
【００１２】
本明細書で説明される技法は、位置決定サービスをサポートできる、様々なユーザプレーンおよび制御プレーンの位置決定法/アーキテクチャに対しても、用いられ得る。位置決定サーバは、位置情報に基づく、または位置情報に関連する任意のサービスを指す。位置情報は、たとえば位置推定、測定結果などの、デバイスの位置に関連する任意の情報を含み得る。位置決定サービスは測位を含んでもよく、測位とは、ターゲットデバイスの地理的な位置を求める機能を指す。位置決定サービスは、UEが位置関連の測定を行い自身の位置を求めるのを支援するための、支援データのUEへの移送のような、測位を支援する動作も含み得る。
【００１３】
ユーザプレーンの位置決定法は、ユーザプレーンを介して位置決定サービスのためのメッセージを送る、位置決定法またはシステムである。ユーザプレーンは、高次層のアプリケーションのためのシグナリングおよびデータを搬送し、ユーザプレーンのベアラを利用するための機構であり、ユーザプレーンのベアラは通常、ユーザデータグラムプロトコル(UDP)、送信制御プロトコル(TCP)、およびインターネットプロトコル(IP)のような標準的なプロトコルにより実装される。制御プレーンの位置決定法は、制御プレーンを介して位置決定サービスのためのメッセージを送る、位置決定法である。制御プレーンは、高次層のアプリケーションのためのシグナリングを搬送するための機構であり、通常、ネットワーク特有の、プロトコル、インターフェース、およびシグナリングメッセージにより実装される。位置決定サービスをサポートするメッセージは、制御プレーンの位置解決法においてはシグナリングの一部として、ユーザプレーンの位置解決法においてはトラフィックデータの一部(ネットワークの観点から)として搬送される。しかし、メッセージの内容は、ユーザプレーンの位置決定法と制御プレーンの位置決定法の両方において、同一または同様であってよい。ユーザプレーンの位置決定法の例は、Open Mobile Alliance(OMA)によるSecure User Plane Location(SUPL)を含む。制御プレーンの位置決定法のいくつかの例には、(i)3GPP TS23.271、TS43.059、TS25.305およびTS36.305に記載される、3GPPの制御プレーンの位置決定法、ならびに、(ii)IS-881およびX.S0002に記載される、3GPP2の制御プレーンの位置決定法がある。
【００１４】
本明細書で説明される技法は、(i)3GPPにより定義される、LTE Positioning Protocol(LPP)、Radio Resource LCS Protocol(RRLP)、およびRadio Resource Control(RRC)、(ii)3GPP2により定義されるC.S0022(IS-801としても知られる)、ならびに(iii)OMAにより定義されるLPP Extensions(LPPe)のような、様々な測位プロトコルに対しても、用いられ得る。測位プロトコルは、デバイスの測位を調整して制御するために用いられ得る。測位プロトコルは、(i)位置決定サーバおよび測位されているデバイスにより実行され得る手順、ならびに(ii)デバイスと位置決定サーバとの間の通信またはシグナリングを、定義することができる。
【００１５】
図1は、通信および位置決定サービスをサポートするワイヤレスネットワーク100を示す。HNB120は、HNB120のカバレッジの中で、UEのための無線通信をサポートするために、ユーザにより任意の位置(たとえば家庭)に配備され得る。HNBは、ホーム基地局、フェムトアクセスポイント(FAP)、Home evolved Node B(HeNB)などとも呼ばれ得る。HNB120は、WCDMAまたは何らかの他の無線技術を用いて、無線アクセスをサポートすることができる。
【００１６】
ホームマネジメントシステム(HMS)124は、たとえば、HNB120が登録されているネットワーク事業者により定められるように、動作のためにHNB120および他のHNBを構成することができる。HNBゲートウェイ(GW)130は、HNB120および他のHNBに結合されてよく、HNBと他のネットワークエンティティとの切替動作をサポートすることができる。基幹ネットワーク150は、ワイヤレスネットワーク100のための様々な機能およびサービスをサポートする、様々なネットワークエンティティを含み得る。たとえば、基幹ネットワーク150は、Mobile Switching Center(MSC)、Serving GPRS Support Node(SGSN)、および/または他のネットワークエンティティを含み得る。MSCは、回線交換(CS)型の呼のための交換機能を実行することができ、ショートメッセージサービス(SMS)メッセージをルーティングすることもできる。SGSNは、UEのパケット交換(PS)型の接続およびセッションのための、シグナリング機能、交換機能およびルーティング機能を実行することができる。基幹ネットワーク150は、他のネットワーク、たとえば、他のワイヤレスネットワークおよび/またはインターネットへのアクセスを有し得る。
【００１７】
Home SUPL Location Platform(H-SLP)140は、測位サービスおよび位置決定サービスをサポートすることができる。H-SLP140は、SUPL Location Center(SLC)を含んでもよく、場合によってはSUPL Positioning Center(SPC)を含んでもよい。SLCは、位置決定サービスのための様々な機能を実行することができ、SUPLの動作を調整することができ、SUPL対応端末(SET)と対話することができる。SPCは、SETの測位およびSETへの支援データの送達をサポートすることができ、位置計算のために用いられるメッセージおよび手順に応答するものであってよい。位置決定サービス(LCS)クライアント160は、位置情報を所望し、基幹ネットワーク150の中のネットワークエンティティと通信して位置情報を取得することができる、エンティティであってよい。LCSクライアント160は、(図1に示されるように)UEの外部にあり基幹ネットワーク150と通信していてもよく、UEに存在していてもよく、またはUEと通信していてもよい。
【００１８】
簡単にするために、図1は、ワイヤレスネットワーク100に存在し得る一部のネットワークエンティティのみを示す。ワイヤレスネットワーク100は、他のネットワークエンティティを含み得る。たとえば、セキュリティゲートウェイ(SeGW)は、HNB120とHNB GW130との間に結合されてよく、HNB120を介したアクセスに関するセキュリティ(たとえば、ネットワークの他の部分に対するセキュリティ)を提供することができる。ワイヤレスネットワーク100は、ラジオネットワークコントローラ(RNC)、基地局コントローラ(BSC)、基地局、Mobility Management Entity(MME)なども含んでよく、これらは、3GPPおよび3GPP2からの公開の文書で説明される機能を実行することができる。
【００１９】
UE110は、ワイヤレスネットワーク100によりサポートされる多くのUEの1つであってよい。UE110は、固定式であっても移動式であってもよく、基地局、端末、アクセス端末、加入者ユニット、局、SETなどとも呼ばれ得る。UE110は、携帯電話、携帯情報端末(PDA)、ワイヤレスデバイス、ワイヤレスモデム、ラップトップコンピュータ、スマートフォン、ネットブック、スマートブック、タブレット、テレメトリデバイス、追跡デバイスなどであってよい。UE110は、HNBおよびマクロ基地局と通信し、通信サービスを得ることができてもよい。UE110はまた、A-GNSS、Observed Time Difference of Arrival(OTDOA)、Uplink Time DIfference of Arrival(U-TDOA)、Enhanced Cell Identity(E-CID)などのような、1つまたは複数の測位方法をサポートすることができる。これらの測位方法のいずれも、UE110の位置を求めるために用いることができる
【００２０】
UE110および/またはHNB120は、1つまたは複数の衛星190からの信号を受信して測定することができ、衛星のための擬似距離測定結果を得ることができる。衛星190は、GNSSの一部であってよく、GNSSは、米国の全地球測位システム(GPS)、欧州のGalileoシステム、ロシアのGLONASSシステム、または何らかの他のGNSSであってよい。本明細書での説明において、用語「GNSS」は全般に、GPS、Galileo、GLONASSなどのような、測位をサポートする任意の衛星システムまたは衛星システムの任意の組合せを指す。UE110および/またはHNB120は、マクロ基地局および/またはHNB(図1には示されない)からの信号を測定し、タイミングの測定結果、信号強度の測定結果、信号品質の測定結果、ならびに/または、基地局および/もしくはHNBの識別情報を得ることもできる。衛星、基地局、および/またはHNBの測定結果、ならびに場合によっては、基地局および/またはHNBの識別情報を用いて、UE110またはHNB120の位置推定を導出することができる。位置推定は、場所推定、場所決定などとも呼ばれ得る。
【００２１】
HNB120は、単体のGNSSをサポートすることができ、単体のGNSSの能力に基づいて、自身の位置を求めることができてよい。UE110も、単体のGNSSをサポートすることができ、単体のGNSSの能力に基づいて、自身の位置を求めることができてよい。あるいは、UE110が単体のGNSSをサポートしない場合、UE110の位置は、HNB120の位置に基づいて推定されてもよい。いずれの場合でも、単体のGNSSは、正確な位置推定を提供でき得るが、いくつかの欠点があり得る。たとえば、単体のGNSSは、ナビゲーションデータを復調するために、最良の衛星の信号強度が、約-145dBmまたはそれよりも大きいことが必要であり得る。さらに、単体のGNSSの初期位置算出時間(TTFF)は、信号強度が小さい場合には、数分以上のオーダーになり得る。
【００２２】
アシスト型GNSS(A-GNSS)は、単体のGNSSよりも良好な性能を実現することができ、かつ/または、単体のGNSSの欠点の一部を改善することができる。A-GNSSでは、デバイスは、ネットワークから衛星のための支援データを得ることができ、支援データを用いて、衛星を探して捕捉することができる。支援データは、デバイスが、より迅速に衛星を検出すること、受信信号レベルの低い衛星を検出すること、衛星ナビゲーションデータを復調する必要をなくすことなどを、可能にし得る。たとえば、A-GNSSは、最良の衛星の信号強度が約-155dBmである場合でも動作することができ、これは、単体のGNSSよりも約10dB有利であり得る。TTFFは、A-GNSSでは、単体のGNSSの場合の数分ではなく、数十秒のオーダーであり得る。A-GNSSにおける感度の向上と最小信号強度の低下は、屋内に配備されることが多いHNBでは特に、望ましい可能性がある。TTFFが短くなることで、より良好なユーザ体験を提供することができる。
【００２３】
ある態様では、HNBと通信するUEのための位置決定サービスは、ユーザプレーンの位置決定法と制御プレーンの位置決定法との間で、HNBを切替動作させることによって、サポートされ得る。HNBは、SUPLのようなユーザプレーンの位置決定法をサポートすることができる。UEは、制御プレーンの位置決定法と、3GPPからのRRC測位プロトコルとをサポートすることができる。HNBは、切替動作して、UEが、SUPLを介した測位サービスおよび位置決定サービスのためのネットワーク支援を得られるようにすることができる。
【００２４】
図2は、ユーザプレーンの位置決定法と制御プレーンの位置決定法のHNB120による切替動作によって、UE110向けの位置決定サービスおよびA-GNSSをサポートするための、メッセージフロー200の設計を示し、HNB120はWCDMA無線接続をサポートすることができる。UE110は、HNB120とのシグナリング接続を確立することができ(たとえば、位置を取得する目的でHNB120により連絡された後に)、HNB120に測位能力を提供することができる(ステップ1)。たとえば、UE110は、3GPP TS25.331で定義されるように、HNB 120へのシグナリング接続が確立されると、RRC Connection Setup Completeメッセージの中のUE Radio Access Capability Information Element(IE)に含まれる、UE Positioning Capability IEにおいて、HNB120に測位能力を提供することができる。UEの測位能力は、(i)UE110によりサポートされる測位方法(たとえば、UEに支援されるA-GNSS、UEに基づくA-GNSS、UEに支援されるOTDOA、UEに基づくOTDOAなど)、および、(ii)A-GNSSがサポートされる場合には、UE110によりサポートされる特定のGNSSシステムおよびGNSS信号を含み得る。
【００２５】
LCSクライアント160は、UE110の位置を取得することを望むことがあり、基幹ネットワーク150の中のネットワークエンティティに要求を送信し得る。要求は、要求されるQuality of Service(QoS)またはQuality of Positioning(QoP)を含み得る。そして、基幹ネットワーク150は、Radio Access Network Application Part(RANAP) Location Reporting Controlメッセージを送り、UE 110の位置についての情報を要求することができる(ステップ2)。RANAPは、基幹ネットワーク150とHNB GW130との間のIuインターフェースのために用いられるプロトコルである。RANAP Location Reporting Controlメッセージは、要求されるQoPまたはQoSを含むことができ、基幹ネットワーク150からHNB GW130への移送のために、Signaling Connection Control Part(SCCP) Data Form1(DT1)で搬送され得る。HNB GW130は、基幹ネットワーク150からSCCP DT1メッセージを受信することができ、HNB120へのRANAP User Adaptation(RUA) Direct Transferメッセージの中で、RANAP Location Reporting Controlメッセージを転送することができる(ステップ3)。RUAは、HNB120とHNB GW130の間のIuhインターフェースのために用いられるプロトコルであり、3GPP TS25.468で定義される。HNB120は、RUA Direct Transferメッセージを受信し、RANAP Location Reporting Controlメッセージを展開し、UE110の位置についての情報が要求されていると判定することができる。
【００２６】
HNB120は、SUPLをサポートすることができ、測位サービスおよび位置決定サービスのために、H-SLP140と通信できてもよい。HNB120とH-SLP140との間の通信は、直接のシグナリングリンクを介したものであってよく、または、1つもしくは複数のネットワークおよび/もしくはネットワークエンティティ、たとえばHNB GW130、基幹ネットワーク150、インターネットなどを介したものであってよい。HNB120はまた、RRCを介してUE110と通信し、制御プレーンの位置決定法、たとえば、3GPP TS25.305で定義される位置決定法に従って、UE110のための測位サービスおよび位置決定サービスをサポートすることができてもよい。一設計では、HNB120は、SUPLと3GPPの制御プレーンの位置決定法で切替動作し、UE110のための測位サービスおよび位置決定サービスをサポートすることができる。切替動作では、HNB120は、HNB120がUE110であるかのように、H-SLP140と通信することができる。あるいは、HNB120は、H-SLP140の登録SETとしてH-SLP140と通信できるが、HNB120の測位能力ではなく、UE110の測位能力をH-SLP140に示し得る。HNB120は、H-SLP140から受信された関連情報をUE110に移送することもでき、UE110から受信された関連情報をH-SLP140に移送することができる。
【００２７】
HNB120は、H-SLP140へのセキュアなIP接続を確立することができる(ステップ4)。HNB120は、固有のセキュリティ情報および識別情報を用いて、このセキュアなIP接続を確立でき、たとえば、HNB120は、H-SLP140には、H-SLP140によるSUPLサービスに参加するSUPL SETであるように見え得る。そして、HNB120は、SUPL STARTメッセージを送信して、H-SLP140による位置決定セッションを開始することができる(ステップ5)。SUPL STARTメッセージは、セッションID、セルID、測位能力、所望のQoPなどを含み得る。セッションIDは、位置決定セッションを識別するために用いられ得る。セルIDは、HNB120のセル識別子(ID)、近くのマクロセルのセルID、またはこれらの両方であってよい。測位能力は、ステップ1においてHNB120に報告された、UE110によりサポートされる測位方法の一部または全てを含み得る。測位能力はまた、(i)UE110ではなくHNB120により、または(ii)HNB120ではなくUE110により、または(iii)HNB120とUE110の両方によりサポートされる、測位プロトコルを示し得る。WCDMA接続および制御プレーンの位置決定では、UE110は通常、RRC測位プロトコルのみをサポートする。場合(i)に対する測位プロトコルは、RRLPまたはLPPを含んでもよく、場合(ii)および場合(iii)に対する測位プロトコルは、RRCを含んでもよい。所望のQoPは、ステップ3においてHNB120により受信されたものと同一であってよい。SUPL STARTメッセージの送信者は通常、送信者の測位能力および送信者により所望されるQoPを含む。しかし、HNB120は、UE110およびLCSクライアント160の測位を支援するためのプロキシとして動作することができ、したがって、(HNB120の測位能力ではなく)UE110の測位能力およびLCSクライアント160により所望されるQoPを、SUPL STARTメッセージの中に含めることができる。HNB120はまた、HNB120がサポートする1つまたは複数の測位プロトコルのサポートを示すことができるが、(上記の場合(i)では)UE110がサポートしないこと、または(上記の場合(ii)および(iii)では)UE110がサポートする1つまたは複数の測位プロトコルのサポートをUE110が示し得ることを、HNB120は示すこともできる。H-SLP140は、SUPL STARTメッセージを受信し、サポートされる測位方法の1つを選択し、セッションID、選択された測位方法などを含み得るSUPL RESPONSEメッセージを返すことができる(ステップ6)。
【００２８】
HNB120は、セッションID、A-GNSSのための支援データの要求、ステップ5におけるような測位能力、HNBセルIDおよび/または近くのマクロセルID、ならびに場合によっては、H-SLP140への他の情報を含み得る、SUPL POS INITメッセージを送信することができる(ステップ7)。そして、H-SLP140は、セッションID、要求される支援データを含む測位メッセージ、および場合によっては測定の要求などを含み得る、SUPL POSメッセージを返すことができる(ステップ8)。測位メッセージは、ステップ5および/またはステップ7で送信された、測位能力に含まれる測位プロトコルの1つに準拠し得る。たとえば、RRLPが測位能力に含まれる場合、測位メッセージは、図2に示されるようなRRLP Measure Position Requestメッセージであってよい。あるいは、測位メッセージは、RRLPのための何らかの他のメッセージ(たとえば、Assistance Dataメッセージ)、または、何らかの他の測位プロトコルのためのメッセージ(図2には示されない)であってよい。H-SLP140が、ステップ8において特定の測位プロトコルを使用し始めると、通常、同一の測位プロトコルが、このSUPL測位セッションのためにHNB120とH-SLP140との間で移送される他の測位メッセージを符号化するために、(たとえばステップ12において)用いられる。
【００２９】
HNB120は、SUPL POSメッセージに含まれる測位メッセージから支援データを得ることができ、RRC Measurement Controlメッセージの中で、UE110に支援データを送信することができる(ステップ9)。測位メッセージが、RRC測位プロトコルに準拠しなかった(たとえば、図2に示されたようなRRLP Measure Position Requestメッセージであった)場合、HNB120は、測位メッセージを復号し、支援データを展開し、RRC Measurement Controlメッセージで支援データを送信することができる。逆に、測位メッセージがすでにRRC Measurement Controlメッセージであった場合、HNB120は、変換または修正をほとんどまたは全く行わずに、このメッセージで送信することができる。
【００３０】
UE110は、支援データに基づいて、GNSS測定結果(すなわち、衛星の測定結果)を得ることができる(ステップ10)。UE110は、GNSS測定結果に基づいて、位置推定を求めることができてもできなくてもよい。UE110は、UE110により得られたGNSS測定結果または位置推定を含み得る、RRC Measurement ReportメッセージをHNB120に送信することができる(ステップ11)。そして、HNB120は、RRLP Measure Position Responseメッセージの中で、GNSS測定結果または位置推定を転送することができ、RRLP Measure Position Responseメッセージは、H-SPL140に送信されるSUPL POSメッセージで搬送され得る(ステップ12)。ステップ12では、HNB120が、UE110から受信されるRRC Measurement Reportメッセージを復号し、GNSS測定結果または位置推定を展開し、GNSS測定結果または位置推定を、RRLP Measure Position Responseメッセージの中で送信することができる。しかし、HNB110が、ステップ8において、RRCのためのサポートを示し、H-SLP140からRRC Measurement Controlメッセージをすでに受信していた場合、HNB120は、ステップ11でUEから受信されたRRC Measurement Reportメッセージを、変換または修正をほとんどまたは全く行わずに、ステップ12でH-SLP140に移送することができる。GNSS測定結果がH-SLP140に送信されると、H-SLP140は、GNSS測定結果に基づいて、UE110の位置推定を計算することができる。そして、H-SLP140は、H-SLP140により計算される位置推定を含み得る、SUPL ENDメッセージを送信することができる(ステップ13)。位置推定がH-SLP140に送信されると、H-SLP140は単純に、SUPL ENDメッセージを返すことができる。
【００３１】
HNB120は、ステップ11のUE110とステップ13のH-SLP140のいずれかから、UE110の位置推定を受信することができる。HNB120は、RANAP Location Reportメッセージの中で、UE110の位置推定を送信することができ、RANAP Location Reportメッセージは、HNB GW130に送信されるRUA Direct Transferメッセージの中で搬送され得る(ステップ14)。HNB GW130は、基幹ネットワーク150へのSCCP DT1メッセージの中で、RANAP Location Reportメッセージを転送することができる(ステップ15)。そして、基幹ネットワーク150は、位置推定をLCSクライアント160に移送することができる。
【００３２】
簡単にするために、図2は、ステップ8および9における、H-SLP140からUE110へのA-GNSSの支援データの移送を示す。UE110は、ステップ10において、UE110が新たな支援データを必要とすると判定することがある。この場合、UE110は、HNB120に新たな支援データの要求を送信することができ、HNB120は、H-SLP140へのSUPL POSメッセージの中で、要求を転送することができる。その後、HNB120は、H-SLP140から新たな支援データを含むSUPL POSメッセージを受信することができ、たとえば、図2のステップ8および9と同様の方式で、新たな支援データをUE110に転送することができる。
【００３３】
図2に示されるように、ネットワーク事業者は、制御プレーンの位置決定法とユーザプレーンの位置決定法の両方をサポートすることができる。HNB120は、UE110の位置決定をサポートするために、SUPLと3GPPの制御プレーンの位置決定法で切替動作することができる。さらに、HNB120は、SUPLにより用いられるRRLP測位プロトコルと、UE110により用いられるRRC測位プロトコルで、切替動作することができる。H-SLP140が、RRLPの代わりにRRCを用いる場合(これは、HNB120が、ステップ5および7において測位能力の一部としてRRCのサポートを含める場合に起こり得る)、RRLPとRRCの切替動作は必要なく、HNB120は、UE110とH-SLP140との間で、RRC測位メッセージを、変換または修正をほとんどまたは全く行わずに、移送することができる。いずれの場合でも、HNB120による切替動作により、UEの位置としてHNBの位置を用いる必要なく、UEの位置を明示的に(たとえば、A-GNSSにより)得られるようになり得る。
【００３４】
HNB120が、UEの位置決定のために、ネットワークエンティティ(たとえばMSCまたはSGSN)から制御プレーンの位置決定要求を受信すると、HNB120は、HNB120の固有のネットワークのH-SLP140(または場合によっては別のネットワークのSLP)によるSUPL位置決定セッションを、引き起こすことができる。HNB120は、UE110がサポートするのと同じ測位方法(たとえばA-GNSS)をHNB120がサポートすることを、H-SLP140に示すことができ、A-GNSSのための支援データを要求することができる。HNB120は、H-SLP140から受信された支援データを、UE110に移送することができる。UE110が、(たとえばRRCを用いて)より多くの支援データを要求する場合、HNB120は、RRLPを用いて要求をH-SLP140に送信することができ、H-SLP140から受信された新たな支援データを、UE110に移送することができる。同様に、HNB120が、より多くの位置に関連する測定結果またはUE110からの別の位置推定のための別の要求を、SUPL POSメッセージの中で搬送される測位メッセージでH-SLP140から受信すると、HNB120は、(H-SLP140により用いられる測位プロトコルがRRCではない場合、要求をRRCメッセージに変換することによって、または、RRCが用いられる場合、要求を転送することによって)この要求をUE110に移送することができる。HNB120は、ステップ8から12におけるような、得られた位置に関連する測定結果または位置推定を、H-SLP140に返すことができる。
【００３５】
HNB120が位置に関連する測定結果または位置推定をUE110から受信すると、HNB120は、あらゆる位置推定を保持し、あらゆる位置に関連する測定結果を、RRLP(図2に示されるような)、または何らかの他の測位プロトコル(図2には示されない)およびSUPLを用いて、H-SLP140に移送することができる。H-SLP140は、(与えられる場合には)位置に関連する測定結果に基づいて、UE110の位置推定を計算することができ、SUPL ENDメッセージの中で、位置推定をHNB120に返すことができる。HNB120は、UE110またはH-SLP140から受信された位置推定を、要求するネットワークエンティティ(たとえばMSCまたはSGSN)に送信することができる。
【００３６】
図2は、A-GNSSを用いたUE110の測位を示す。図2に示される例示的な手順はまた、(i)ステップ7から9で他の測位方法のための支援データを要求し返すことによって、かつ、(ii)ステップ8から12で他の測位方法のための測定結果または位置推定を要求し返すことによって、A-GNSSに加えて、またはその代わりに、そうした他の測位方法(たとえば、OTDOAまたはE-CID)を用いてUE110を測位するのに、用いられ得る。さらに、図2は、HNB120とH-SLP140との間の、SUPL1.0またはSUPL2.0の使用を示し得る。ステップ5、6、7、8、12および13の1つまたは複数において、他のSUPLメッセージおよびパラメータを用いることで、他のバージョンのSUPL(たとえばSUPL3.0)を用いることができる。HNB120およびHNB GW130、ならびにこれらの間のリンクを単一のRNCで置き換え、ステップ3および14を除くことによって、HNB120ではなくRNCにおいて、SUPLと制御プレーンの位置決定で切替動作することによる、マクロセルにおけるUEの測位のための手順を得ることができる。ユーザプレーンの位置決定と制御プレーンの位置決定で切替動作するという原理は、制御プレーンの位置決定のためのアンカーポイントとして動作する、たとえば、MSC、SGSN、またはMMEとして用いられ得る、他のエンティティにおいても利用され得る。
【００３７】
図2は、UE110のためにA-GNSSをサポートする設計を示す。A-GNSSは、様々な方式でHNB120のためにサポートされ得る。一設計では、HNB120は、SUPLを用いて自身の位置を取得するために、H-SLP140にクエリを行うことができる。HNB120は、H-SLP140によるSUPL測位セッションを引き起こすことができ、SUPLを用いてH-SLP140と対話する際、SETとして振舞うことができる。別の設計では、HMS124は、たとえば、プロプライエタリなシグナリング方法を用いて、A-GNSSのための支援データをHNB120に与えることができ、それにより、HNB120が、HNB120により行われるGNSS測定から、自身の位置を取得できるようになる。さらに別の設計では、プロプライエタリなサーバ(たとえば、HNB120の製造業者またはその製造業者のOEMにより提供されるサーバ)が、最初に、または後で、支援データをHNB120に提供してもよい。HNB120は、他の方式で支援データを取得することもできる。HNB120は、任意の適切な機構を介して取得された支援データを用いて、測位を実行することができる。
【００３８】
別の態様では、Standalone Serving Mobile Location Center(SAS)または何らかの他の位置決定サーバが、HNBおよびUEのための、位置決定サービスおよびA-GNSSをサポートするために用いられ得る。SASは通常、3GPPネットワークにおいて用いられてよく、Iupcインターフェースを介してRNCに結合されてよく、3GPPネットワークと通信するUEのための測位をサポートすることができる。しかし、HNBおよびUEの測位をサポートするために、SASがHNB GWに結合されてよく、HNB GWはSASによりRNCとして見なされ得る。
【００３９】
図3は、通信および位置決定サービスをサポートするワイヤレスネットワーク300を示す。HNB320および322は、これらのHNBのカバレッジの中で、UEの無線通信をサポートするために、1人または複数のユーザにより様々な位置(たとえば、建物の2階)に配備され得る。HMS324は、動作のためにHNB320および322を構成することができる。HNB GW330は、HNB320および322に結合されてよく、HNBと他のネットワークエンティティとの切替動作をサポートすることができる。SAS340は、ネットワーク300と通信するUEのための、位置決定サービスおよび測位をサポートすることができる。基幹ネットワーク350は、MSC/SGSN352およびGateway Mobile Location Center(GMLC)354を含み得る。GMLC354は、位置決定サービスをサポートするための様々な機能を実行し、LCSクライアント360とのインターフェースをとり、加入者のプライバシー、許可、認証、課金などのようなサービスを提供することができる。簡単にするために、図3は、ワイヤレスネットワーク300に存在し得る、一部のネットワークエンティティのみを示す。ワイヤレスネットワーク300は、他のネットワークエンティティを含み得る。UE310は、ワイヤレスネットワーク300によりサポートされる多くのUEの1つであってよい。
【００４０】
図4は、HNB320、HNB GW330、およびSAS340における例示的なプロトコルスタックを示す。HNB320およびSAS340は、Positioning Calculation Application Part(PCAP)を介して、端末間で通信することができ、PCAPは、HNB320およびSAS340のためのプロトコルスタックの最上位に存在し得る。PCAPは、WCDMA接続のための3GPP制御プレーンによる測位をサポートするのに用いられるプロトコルであり、RNCとSASとの間で用いられ得る。PCAPは、公開されている3GPP TS25.453において定義される。Iuhインターフェースを介した、HNB320およびHNB GW330のためのプロトコルスタックは、RUAまたはPCAP User Adaptation(PUA)プロトコル、Stream Control Transmission Protocol(SCTP)、IP、データリンク層、および物理層を含み得る。Iupcインターフェースを介した、HNB GW330およびSAS340のためのプロトコルスタックは、SCCP、MTP3-User Adaptation(M3UA)、SCTP、IP、データリンク層、および物理層を含み得る。
【００４１】
図4に示されるように、PCAPは制御プレーンに追加されてよく、PCAPメッセージは、Iuhインターフェース上ではPUA/RUA、およびIupcインターフェース上ではSCCPを用いて、HNB GW330を介して移送され得る。HNB GW330は、SAS340のためのPCAPの下層でIupcプロトコルを終了してよく、HNB320のためのPCAPの下層でIuhプロトコルを終了してもよい。図4には示されないが、HNB GW330はまた、MSC/SGSN352からのRANAPの下層でIuプロトコルを終了してもよい。
【００４２】
HNB320が最初にネットワーク300にアクセスするとき、位置に関連する情報が、HNB320で検証され構成され得る。HNB320は、測位能力をHMS324に報告することができる。HMS324は、どの測位能力を用いることができるか、たとえば、A-GNSS、E-CID、ブロードキャスト、RNCセントリックモード対SASセントリックモードなどを用いることができるかを、構成することができる。HMS324は、SAS340、および/またはHNB GW330からアクセス可能であり得る他のSASの、識別情報および能力も、HNB320に提供することができる。HNB320は、SAS340を利用して、自身の位置をより正確に求め、HMS324においてこの位置を報告または更新することができる。あるいは、HNB320は、上で説明された機能を実行できる、HNB GW330に登録してもよい。
【００４３】
一設計では、SAS340は、SAS340によりサーブされ得るHNBのための、HNB情報のデータベースを記憶することができる。HNB320のためにSAS340により記憶されるHNB情報は、HNB320、HNB320の位置座標、HNB320の近くの近傍セルのセルIDおよび場合によっては信号強度、HNB320の測位能力などを一意に識別できる、セルグローバルID(CGI)を含み得る。HNB320は、HNB320が最初に初期化されたとき、またはHNB320がHNB GW330に登録したとき、またはHNB320が位置を変えたときなどに、または周期的に、SAS340にHNB情報を送信することができる。一設計では、HNB320は、SAS340への新たなコネクションレスPCAPメッセージの中で、HNB情報を送信することができる。別の設計では、HNB320は、SAS340への既存のPCAPメッセージ(たとえば、PCAP Position Initiation Requestメッセージ)の中で、HNB情報を送信して、SASからの位置決定のサポートを得ることができる。HNB320は、SAS340に送信されている情報(たとえば、PCAP Position Initiation Requestメッセージの中の)が、メッセージ中に識別パラメータを含めることでHNB320と関連付けられると、特定することができる。識別パラメータは、International Mobile Subscriber Identity(IMSI)またはInternational Mobile Equipment Identity(IMEI)を含んでもよく、HNBを識別するためにネットワーク300の管理者により用意されるような文字列のセットに属する、数字の列を格納し得る。この数字の列のセット(たとえば、ある範囲の値により定義される)が、SAS340で事前に構成されている場合、SAS340は、識別パラメータを認識することができるので、PCAPメッセージの中の情報を、HNBに関連するものと推測することができる。このことは、既存のPCAPメッセージおよびパラメータを、HNB320からSAS340にHNB情報を運ぶのに使用できるようにすることができ、新たなPCAPメッセージおよびパラメータを、標準化して実装する必要をなくすことができる。HNB320はまた、他の方式でSAS340にHNB情報を送信することもできる。SAS340は、半永続的な情報または半静的な情報として、HNB情報を記憶してもよい。
【００４４】
図5は、SAS340を用いて、UE310のための位置決定サービスおよびA-GNSSをサポートするための、メッセージフロー500の設計を示す。UE310は、HNB320と関連付けることができ(たとえば、場合によっては位置を取得する目的でネットワーク300により連絡された後に、HNB320とのシグナリング接続を確立することができ)、HNB320に測位能力を提供することができる(ステップ1)。LCSクライアント360は、UE310の位置を取得することを望むことがあり、基幹ネットワーク350の中のGMLC354に要求を送信し得る。基幹ネットワーク350は、SCCP DT1メッセージの中で、RANAP Location Reporting Controlメッセージを送り、UE310の位置についての情報を要求することができる(ステップ2)。HNB GW330は、基幹ネットワーク350からSCCP DT1メッセージを受信することができ、HNB320へのRUA Direct Transferメッセージの中で、RANAP Location Reporting Controlメッセージを転送することができる(ステップ3)。
【００４５】
HNB320は、RUA Direct Transferメッセージを受信し、RANAP Location Reporting Controlメッセージを展開し、UE310の位置についての情報が要求されていると判定することができる。そして、HNB320は、HNB GW330へのPUA Connectメッセージの中で、PCAP Position Initiation Requestメッセージを送り、SAS340による位置決定セッションを開始することができる(ステップ4)。PUA Connectメッセージはまた、SAS(たとえばSAS340)の識別情報を含み得る。PCAP Position Initiation Requestメッセージは、セルID(たとえば、HNB320またはHNB320に見える近くのマクロセルのセルID)、UEの測位能力(たとえばA-GNSS)などを含み得る。HNB GW330は、HNB320からPUA Connectメッセージを受信することができ、SAS340へのSCCP Connection Request(CR)メッセージの中で、PCAP Position Initiation Requestメッセージを転送することができる(ステップ5)。HNB GW330は、PUA Connectメッセージに含まれる任意のSASの識別情報から、または他の方法で(たとえば、デフォルトでは1つのSASのみがHNB GW330に接続される)、SAS340を決定することができる。
【００４６】
SAS340は、PCAP Position Initiation Requestメッセージを受信することができ、SCCP Connection Confirm(CC)メッセージの中で、PCAP Position Activation Requestメッセージを送信することによって、A-GNSS測位手順を開始することができる(ステップ6)。PCAP Position Activation Requestメッセージは、A-GNSS測位、A-GNSSのための支援データなどに対する、要求を含み得る。HNB GW330は、SAS340からSCCP CCメッセージを受信することができ、HNB120へのPUA Direct Transferメッセージの中で、PCAP Position Activation Requestメッセージを転送することができる(ステップ7)。
【００４７】
HNB320は、PCAP Position Activation Requestメッセージから情報を得ることができ、UE310へのRRC Measurement Controlメッセージの中で、A-GNSS測位要求および支援データを送信することができる(ステップ8)。UE310は、支援データに基づいて、GNSS測定結果を得ることができる(ステップ9)。UE310は、GNSS測定結果に基づいて、位置推定を求めることができてもできなくてもよい。UE310は、UE310により得られたGNSS測定結果または位置推定を含み得る、RRC Measurement ReportメッセージをHNB320に送信することができる(ステップ10)。そして、HNB320は、PCAP Position Activation Responseメッセージの中で、GNSS測定結果または位置推定を転送することができ、PCAP Position Activation Responseメッセージは、HNB GW330に送信されるPUA Direct Transferメッセージで搬送され得る(ステップ11)。HNB GW330は、HNB320からPUA Direct Transferメッセージを受信することができ、SAS340へのSCCP DT1メッセージの中で、PCAP Position Activation Responseメッセージを、転送することができる(ステップ12)。
【００４８】
SAS340は、PCAP Position Activation Responseメッセージから、GNSS測定結果または位置推定を受信することができる。SAS340は、GNSS測定結果に基づいて、UE310のための位置推定を計算することができ、かつ/または、UE310のための位置推定を検証することができる。そして、SAS340は、PCAP Position Initiation Responseメッセージの中で、SAS340により計算されかつ/または検証される位置推定を送信することができ、PCAP Position Initiation Responseメッセージは、HNB330に送信されるSCCP DT1メッセージの中で、搬送され得る(ステップ14)。HNB GW330は、SAS340からSCCP DT1メッセージを受信することができ、HNB320へのPUA Direct Transferメッセージの中で、PCAP Position Initiation Responseメッセージを転送することができる(ステップ15)。
【００４９】
HNB320は、ステップ10においてUE310から、またはステップ15においてSAS340から、UE310の位置推定を受信することができる。HNB320は、PUA DisconnectメッセージをHNB GW330に送信することによって、SAS340による位置決定セッションを終了することができ(ステップ16)、HNB GW330は、SCCP Released(RLSD)メッセージを、SAS340に送信することができる(ステップ17)。SAS340は、SCCP Release Complete(RLC)メッセージを返すことができる(ステップ18)。
【００５０】
HNB320は、RANAP Location Reportメッセージの中で、UE310の位置推定を送信することができ、RANAP Location Reportメッセージは、HNB GW330に送信されるRUA Direct Transferメッセージの中で搬送され得る(ステップ19)。HNB GW330は、基幹ネットワーク350へのSCCP DT1メッセージの中で、RANAP Location Reportメッセージを転送することができる(ステップ20)。
【００５１】
図5において、SAS340は、ステップ6から8において、A-GNSSのための支援データをUE310に送信することができる。UE310は、UE310がステップ9において新たな支援データを必要とすると、判定することができる。この場合、UE310は、HNB320を介して、支援データの要求をSAS340に送信することができる。そして、ステップ6から12が実行され、新たな支援データをUE310に提供することができる。同様に、SAS340は、ステップ13において、SAS340がより多くの位置に関連する測定結果または別の位置推定を必要としていると、判定することができる。そして、SAS340は、ステップ6から12を再び実行して、(i)HNB320を介して、位置測定または位置推定のためのより多くの支援データおよび別の要求をUE310に送信し、(ii)位置に関連する測定結果または位置推定を、HNB320を介してUE310から受信することができる。ステップ5において、(たとえば、ステップ4においてPCAP Position Initiation Requestの中に、HNB320のためのIMSIまたはIMEIを含めたことにより)SAS340が、HNB320から来るものとして要求を認識でき、SAS340がHNB320の正確な位置をすでに有している場合、SAS340は、ステップ6から13を飛ばし、ステップ14および15において、HNB320の位置をHNB320に返すことができる。任意のHNBのカバレッジエリアは狭いため、UE310は通常HNB320の近くにあることを考えると、HNBの位置は、UE310の位置に対する良好に概算になり得る。あるいは、SAS340が、ステップ11および12でSAS340に提供されるあらゆる測定結果または位置推定から、十分正確にUE310の位置を得られない場合、SAS340は、ステップ6から13を実行した後で、ステップ14および15において、UE310の位置の概算として、HNB320の位置をHNB320に返してもよい。このことは、UE310が正確な位置測定結果を得られない場合(たとえば、UE310が建物の中にある場合)、有用であり得る。
【００５２】
上で説明されたように、図4および5における設計は、UE310のための位置決定サービスおよびA-GNSSをサポートすることができる。これらの設計は、OTDOAおよびE-CIDなどのような、他のUEにより支援される測位方法およびUEに基づく測位方法もサポートすることができる。これらの設計はまた、A-GNSS、E-CID、および他のネットワークにより支援される測位方法をサポートして、HNB320の位置を求めることもできる。これらの設計は、SASセントリックモード(図5に示される)またはRNCセントリックモードで用いられ得る。RNCセントリックモードでは、HNB320は、SAS340ではなく位置決定手順を制御し、図5のRRCメッセージ(ステップ8および10)は同じままであってよいが、異なるPCAPメッセージが、図5のPCAPメッセージの代わりに、HNB320とSAS340との間で交換され得る(ステップ4、5、6、7、12および14)。
【００５３】
図4および5に示される設計では、HNB320は、PCAPメッセージとRRCメッセージで切替動作することができる。HNB320は、SAS340からPCAPメッセージを受信することができ、UE110へのRRC測位メッセージの中で関連情報を転送することができる。HNB320はまた、UE110からRRC測位メッセージを受信することができ、SAS340へのPCAPメッセージの中で関連情報を転送することができる。
【００５４】
図4および5に示される設計では、HNB GW330は、たとえば図4および5に示されるようなPUAを用いて、HNB320とSAS340との間での、PCAPメッセージの移送をサポートすることができる。HNB GW330は、SAS340によりSCCPメッセージで送信されるPCAPメッセージを受信することができ、HNB320へのPUAメッセージ(図5に示されるような)および/またはRUAメッセージの中で、これらのPCAPメッセージを転送することができる。HNB GW330はまた、HNB320によりPUAメッセージ(図5に示されるような)の中で送信されるPCAPメッセージを受信することができ、SAS340へのSCCPメッセージの中でこれらのPCAPメッセージを転送することができる。
【００５５】
一設計では、RUAは、PCAPメッセージを移送するために拡張され得る。別の設計では、PUAは、(たとえば図5に示されるように)HNB320とHNB GW330との間でPCAPメッセージを移送するために、定義され得る。この設計は、RANAPのサポートに影響が及ぶのを避けることができるので、単純に実装することができる。PUAは、RUAとは異なり得るある特性を有し得る。たとえば、PUAは、以下の特性の1つまたは複数を有し得る。
・RANAPメッセージの代わりにPCAPメッセージを搬送する
・特定のUEに対する参照を含まない
・コネクションレスPCAPメッセージのトランザクションIDをサポートする
・複数のSASをサポートする
【００５６】
一設計では、HNB GWはUEの関連付けを認識している必要はないので、PUAメッセージは、特定のUEとは明示的に関連付けられなくてもよい。さらに、HNBは、PUAメッセージを用いて、HNBの位置を求めるためにPCAPメッセージをSASに移送することができる。その場合、位置決定すべきUEはないので、UEと関連付けられるPUAメッセージは不可能である。
【００５７】
一設計では、HNB320により送信される、コネクションレスで、場合によってはコネクション型のPCAPメッセージが、固有のPCAPトランザクションIDを格納し得る。PCAP応答メッセージおよびPCAP要求メッセージが、コネクションレスSCCPおよび場合によってはコネクション型のSCCPを用いて、HNB GW330とSAS340との間で移送される場合、PCAPトランザクションIDは、PCAP応答メッセージをPCAP要求メッセージと関連付けるために、PCAPレベルで用いられ得る。HNB320が、特定のSASの固有のトランザクションIDのために、PUA要求をHNB GW330に送信する場合、PCAPトランザクションIDは、HNB GW330により管理されて割り当てられ、PUAを用いてHNB320に与えられ得る。SAS340は、RNCとしてHNB GW330を見なすことができ、HNB GW330の背後のHNB320のような、様々なHNBは認識できない。したがって、SAS340は、HNB GW330に関するトランザクションIDの単一のセットをサポートすることができる。エラーを引き起こし得るため、HNB320およびHNB322のような異なるHNBは、同一のPCAPトランザクションIDを用いるべきではない。たとえば、HNB320に宛てられたSAS340からのコネクションレスPCAP応答メッセージが、HNB GW330により誤ってHNB322にルーティングされることがある。HNB320は、HNB GW330から固有のPCAPトランザクションIDを得ることができ、一定の時間の後、PUAメッセージをHNB GW330に送信してトランザクションIDを解放することができ、これにより、HNB GW330が後で別のHNB(たとえばHNB322)にそのPCAPトランザクションIDを割り当てることが可能になる。コネクションレスPCAPメッセージのために、固有のPCAPトランザクションIDをHNB320に送信することで、HNB GW 330は、PCAPトランザクションIDが一意であることを検証するために、HNB320からSAS340にHNB GW330を通って移送されるコネクションレスPCAPメッセージを、検査する必要がなくなる。このことにより、HNB GW330において、PCAPプロトコルの一部をサポートする必要がなくなる。しかし、HNB GW330は、SAS340によりHNB320に送信される任意のコネクションレスPCAP応答メッセージを検査して、PCAPメッセージを、HNB322のような何らかの他のHNBではなくHNB320にルーティングするために、PCAPトランザクションIDを得てもよい。
【００５８】
コネクション型のPCAPメッセージでは、SCCP接続が、これらのメッセージを移送するために、HNB GW330とSAS340との間で確立され得る。SCCP接続は、(i)SAS340からHNB320に送信されたPCAP応答メッセージと、HNB320からSAS340に送信された前のPCAP要求メッセージとを関連付けるのを助け、(ii)PCAP応答メッセージを正しいHNBにルーティングするために、用いられ得る。したがって、HNB GW330は、SAS340により送信されるコネクション型のPCAPメッセージを正しいHNBにルーティングするために、そのようなメッセージを検査する必要がなくてもよい。しかし、コネクション型のPCAPメッセージのトランザクションIDが、各SCCP接続のみに対して一意になることを、SAS340が可能しない限り、HNB GW330から固有のPCAPトランザクションIDをHNB320が要求するための機構が、依然として利用され得る。この後者の場合、HNB320は、HNB GW330の支援なしで、PCAPトランザクションID自体を割り当てることができる。
【００５９】
ある代替的な設計では、HNB GW330は、HNB320により割り当てられたPCAPトランザクションIDと、SAS340により見られるPCAPトランザクションIDとを互いに変換することができる。この設計では、HNB320は、固有のPCAPトランザクションIDを管理し、適切なトランザクションID Xを、HNB GW330を介してSAS340に送信される任意のPCAP要求メッセージに挿入することができる。そして、HNB GW330は、トランザクションID Xを、HNB GW330とSAS340との間のインターフェースに固有の別のトランザクションID Yと置き換えることができ、次いで、PCAP要求メッセージをSAS340に転送することができる。後で、SAS340は、同一のトランザクションID Yを搬送するこのPCAP要求のためのPCAP応答メッセージを、送信し返すことができる。次いで、HNB GWが、PCAP応答を検査し、トランザクションID YをトランザクションID Xにより置き換え、PCAP応答メッセージをHNB320にルーティングし戻すことができる。この代替的な設計により、HNB GW330は、PCAPプロトコルをより多くサポートできるが、HNB320およびHNB GW330によるPUAサポートの範囲は狭くなり得る(たとえば、HNB320はHNB GW330からPCAPトランザクションIDを要求できなくなり得る)。
【００６０】
SAS340により開始されるHNB320へのPCAPトランザクションでは、PCAPトランザクションIDは、HNB GW330により変換または変更されることなく、SAS340とHNB320との間で移送され得る。それは、SAS340が、各種類のPCAP手順に対して、トランザクションIDが一意であることを、確実にできるためである。
【００６１】
一設計では、PUAは、以下の機能の1つまたは複数を有し得る。
・コネクション型のPCAPメッセージの移送のためのIupcインターフェースを通じた、SCCP接続のセットアップを制御または報告し、かつSCCP接続を解放する
・コネクション型PCAPメッセージを移送する
・PUAメッセージの中でローカルな識別子を用いて、Iupcインターフェース上の特定のHNBと関連付けられたSCCP接続を識別する
・コネクションレスPCAPメッセージを移送し、PCAPトランザクションIDの割り当てを管理する
・複数のSASがHNB GWに接続する場合にSASを識別する(たとえば、HNBが、新たなPCAP手順のために特定のSASを選択できるようにする)
【００６２】
一設計では、PUAメッセージのセットがサポートされてよく、以下のPUAメッセージの1つまたは複数を含み得る。
・PUA Connectメッセージ-HNBからの、またはHNBへのコネクション型PCAPメッセージの移送のために、HNB GWとSASとの間のSCCP接続をセットアップするために、またはセットアップを報告するために用いられる
・Direct Transferメッセージ-HNB GWとHNBとの間で、コネクション型PCAPメッセージを移送するために用いられる
・Disconnectメッセージ-HNB GWとSASとの間のSCCP接続を解放するために、またはSCCP接続の解放を報告するために用いられる
・Request Transaction IDメッセージ-コネクションレスPCAPメッセージのための固有のPCAPトランザクションIDを得るために、HNBによりHNB GWに送信される
・Return Transaction IDメッセージ-HNB GWにより管理されるPCAPトランザクションIDの共通の保管場所に、PCAPトランザクションIDを返すために、HNBによりHNB GWに送信される
・Connectionless Transferメッセージ-HNBとHNB GWとの間で、コネクションレスPCAPメッセージを移送するために用いられる
・HNB Transferメッセージ-UE位置決定手順がハンドオーバーのためにソースHNBにより開始された後に開始する、HNB内のGWハンドオーバーの後の、継続するUEの位置決定をサポートするために用いられる
【００６３】
各PUAメッセージは、任意の適切なフォーマットの、任意の数のパラメータを含み得る。一設計では、PUA Connectメッセージは、PCAPメッセージ、HNB GWとSASとの間のSCCP接続へのローカルのPUAの参照、複数のSASがある場合のSAS IDなどを含み得る。HNB GWは、HNB GWとHNBとの間で用いられるローカルのPUA接続の参照と、HNB GWとSASとの間のSCCP接続との、関連付けを管理することができる。PUA Direct Transferメッセージは、コネクション型のPCAPメッセージおよびローカルのPUA接続の参照を含み得る。複数のSASがある場合には、PUA Connectionless Transferメッセージは、コネクションレスPCAPメッセージおよびSAS IDを含み得る。
【００６４】
別の設計では、上で開示される様々な能力、メッセージおよびパラメータは、HNB320とSAS340との間でPCAPを用いてUE310またはHNB320の位置決定をサポートするために、RUAに含まれ得る。この設計では、PCAPメッセージは、PUAの代わりにRUAを用いて、HNB320とHNB GW330との間で移送される。
【００６５】
UE310は、たとえば図5に示されるように、HNB320により位置決定手順を実行することができる。UE310は移動式であってよく、位置決定手順の間、ソースHNB320からターゲットHNB322にハンドオーバーされ得る。HNB320および322は、ともに同一のHNB GW330に結合されてよく、HNB GW内でのハンドオーバーがUE310のために実行され得る。一設計では、ソースHNB320は、(i)あらゆる進行中のSASセントリック位置決定セッションのために、PCAP AbortメッセージをSAS340に送信して、(ii)エラーの原因を伴うRANAP Location ReportメッセージをMSC/SGSN352に送信することによって、UE310のための位置決定手順を終了することができる。そして、UE310がターゲットHNB322にハンドオーバーされた後、新たな位置決定手順が開始され得る。
【００６６】
別の設計では、ソースHNB320を介した、UE310のための進行中の位置決定手順は、HNB322を介して継続され得る。一設計では、HNB GW330は、UE310のハンドオーバーがHNB GWの内部で行われるものかどうかを、ソースHNB320に示すことができる。そして、ソースHNB320は、位置決定手順を中止すべきか、またはターゲットHNB322を介して位置決定手順を継続すべきかを、決定することができる。一設計では、位置決定手順の継続が決定されると、ソースHNB320は、UE310のための位置状態情報を、HNB GW330を介してターゲットHNB322に移送することができる。任意のSASセントリック位置決定セッションは、ターゲットHNB322を介して継続することができ、ターゲットHNB322は、HNB322の新たなセルIDによりSAS340を更新することができる。UE310のハンドオーバーが何らかの理由により失敗した場合、ソースHNB320はUE310のための位置決定手順を継続することができる。
【００６７】
図6は、HNB GW内のハンドオーバーで、UE310の位置決定手順を継続するための、メッセージフロー600の設計を示す。UE310は、最初にHNB320と通信してよく、HNB320は、UE310のためのSAS340による進行中の位置決定手順を有し得る(ステップ1)。HNB320は、HNB322へのUE310のハンドオーバーのために再配置を実行すると決定することができる(ステップ2)。そして、HNB320は、HNB GW330へのRUA Direct Transferメッセージの中で、RANAP Relocation Requiredメッセージを送信することができる(ステップ3)。HNB GW330は、ターゲットHNB322におけるUE310の登録を引き起こすことができる(ステップ4)。HNB GW330は、RANAP Relocation Commandメッセージを返すことができ、RANAP Relocation Commandメッセージは、HNB320へのRUA Direct Transferメッセージの中に、HNB GW内でのハンドオーバーを示すものを含めることができる(ステップ5)。
【００６８】
HNB320は、UE310のための位置決定手順を継続すると、決定することができる(ステップ6)。そして、HNB320は、位置決定手順のための位置状態情報を含むPUA HNB Transferメッセージを、HNB GW330に送信することができる(ステップ7)。HNB GW330は、PUA HNB Transferメッセージを、HNB322に転送することができる(ステップ8)。
【００６９】
ステップ5における再配置を実行するという決定の後の任意の時に、HNB320は、Physical Channel ReconfigurationメッセージをUE310に送信することができる(ステップ9)。このメッセージは、HNB322へのUE310のハンドオーバーを示すことができる。そして、UE310は、HNB322に対するアップリンク同期を実行することができる(ステップ10)。
【００７０】
ステップ10におけるアップリンク同期を受信した後、HNB322は、HNB GW330へのRUA Direct Transferメッセージの中で、RANAP Relocation Completeメッセージを送信することができる(ステップ11)。そして、HNB GW330は、HNB320へのRUA Direct Transferメッセージの中で、RANAP Iu Release Commandメッセージを送信することができる(ステップ12)。HNB320は、HNB GW330へのRUA Disconnectメッセージの中で、RANAP Iu Release Completeメッセージを返すことができる(ステップ13)。
【００７１】
UE310のための位置決定手順を継続するために、HNB322は、PCAP Position Parameter Modificationメッセージを送信することができ、PCAP Position Parameter Modificationメッセージは、HNB GW330へのPUA Direct Transferメッセージの中の、HNB322の新たなセルIDを含み得る(ステップ14)。HNB GW330は、最初のUEの位置決定のためにHNB320に前に割り当てられたものと同じSCCP接続を用いて、SAS340へのSCCP DT1メッセージの中で、PCAP Position Parameter Modificationメッセージを転送することができる。そして、位置決定手順は、HNB GW330を介して、HNB322とSAS340との間で継続することができる(ステップ16)。HNB GW330は、HNB322に移送された、位置決定手順のサポートのためのSAS340とのIupcインターフェースのためにHNB320と事前に関連付けられた任意の状態情報(たとえばSCCP接続情報)を、使用し続けることができる。
【００７２】
一般に、ソースHNB320によりターゲットHNB322に転送された位置状態情報は、UE310のための位置決定手順を継続するのに有用または必要であり得る、任意の情報を含み得る。一設計では、位置状態情報は、要求されるQoS、要求される優先度、速度の要求、HNB320における位置決定手順のこれまでの全体の長さ、任意の定期的な要求に当てはまる詳細事項(たとえば、これまでに完了した定期的な位置報告の数)などのような、基幹ネットワーク350からの元の位置要求において前にHNB320に提供された情報を、含み得る。一設計では、SASセントリックモードが用いられる場合、位置状態情報は、HNB320により用いられるPCAPトランザクションID、および、PCAP Position Initiation RequestメッセージのためにHNB320とHNB GW330との間で用いられるローカルの接続の参照を、含み得る。
【００７３】
一設計では、位置状態情報は、UE310のためにHNB320においてSAS340により実行される、各々の進行中のSASセントリック測位方法について、以下の1つまたは複数を含み得る。
・測位方法の種類(たとえば、UEにより支援されるA-GNSSまたはOTDOA)
・PCAP Position Activation Requestメッセージの中でSAS340により用いられるPCAPトランザクションID
・要求される応答時間および測位方法の現在の経過時間
・測位方法(たとえばODTOA)についてこれまでに得られた情報(たとえばUE310からの測定結果)
【００７４】
ソースHNB320が、OTDOA測定のための参照セルである場合、UE310はハンドオーバーの後にHNB320のためのOTDOA測定を取得できないことがあるため、OTDOAのための位置決定セッションは中止され得る。したがって、ターゲット側のHNB322でOTDOAを常に中止し、ソースHNB320からの詳細な情報を移送しないことが、よりシンプルであり得る。位置決定手順は、ターゲットHNB322から新たなセルIDが受信されるとSAS340において終了し得るので、U-TDOAのための情報が、位置状態情報(たとえば、当てはまる場合には、CELL_FACH状態のための情報)に含まれる必要はない。
【００７５】
一設計では、ソースHNB320が、A-GNSSまたはOTDOAのような任意の進行中のUEに支援されたまたはUEに基づく測位方法のために、RRC Measurement ControlメッセージをUE310に送信したという、仮定が行われ得る。この場合、ターゲットHNB322は、RRC Measurement Controlメッセージを、UE310に送信する必要はない。ソースHNB320がRRC Measurement Controlメッセージを送信していない場合、ソースHNB320またはターゲットHNB322は、PCAP Position Activation FailureメッセージをSAS340に送信することができる。
【００７６】
図5は、UE310のための、位置決定サービスおよびA-GNSSならびに/または他の測位方法をサポートする、設計を示す。HNB320のためのA-GNSSおよび/または他の測位方法は、HNB320の位置を求められるようにするように、同様の方式でサポートされ得る。HNB320は、上で説明されたように、PCAPおよびPUAを使用し続けることができる。しかし、A-GNSSのための支援データを提供して、GNSS測定結果または位置推定を得るために、UE310と対話する代わりに、HNB320は、UEの役割を引き受けてよく、場合によってはSAS340から受信された支援データの助けにより、GNSSおよび/または他の(たとえばOTDOA)測定を行い、かつ/または位置推定を得てもよい。この場合、HNB320は、PCAPとRRCで切替動作する必要はないが、代わりにPCAPを測位プロトコルとして用いることができる。HNB GW330およびSAS340の観点からは、HNB320の測位は、UE310の測位と同じに、またはほとんど同じに見え得るので、追加のサポートをほとんどまたは全く必要としない。
【００７７】
図7は、SAS340を用いて、HNB320のための位置決定サービスおよびA-GNSSをサポートするための、メッセージフロー700の設計を示す。HNB320またはHMS324は、HNB320の位置が必要であると判定することができる(ステップ1)。HNB320は、HNB GW330へのPUA Connectメッセージの中で、PCAP Position Initiation Requestメッセージを送り、SAS340による位置決定セッションを開始することができる(ステップ2)。PUA Connectメッセージはまた、SAS(たとえばSAS340)の識別情報を含み得る。PCAP Position Initiation Requestメッセージは、セルID(たとえば、HNB320において見える近くのマクロセルのセルID)、HNB320の測位能力(たとえばA-GNSS)などを含み得る。HNB GW330は、SAS340へのSCCP CRメッセージの中で、PCAP Position Initiation Requestメッセージを転送することができる(ステップ3)。HNB GW330は、PUA Connectメッセージに含まれる任意のSASの識別情報から、または他の方法で(たとえば、デフォルトでは1つのSASのみがHNB GW330に接続される)、SAS340を決定することができる。SAS340は、PCAP Position Initiation Requestメッセージを受信することができ、HNB GW330に送信されるSCCP CCメッセージの中で、A-GNSSのための支援データを含み得るPCAP Position Activation Requestメッセージを送信することによって、A-GNSS測位手順を開始することができる(ステップ4)。HNB GW330は、HNB320へのPUA Direct Transferメッセージの中で、PCAP Position Activation Requestメッセージを、転送することができる(ステップ5)。
【００７８】
HNB320は、PCAP Position Activation Requestメッセージを受信することができ、たとえば、SAS340から受信された支援データに基づいて、GNSS測定結果を得ることができる(ステップ6)。HNB320は、GNSS測定結果およびステップ5で受信された支援データに基づいて、位置推定を求めることができてもできなくてもよい。HNB320は、PCAP Position Activation Responseメッセージを送信することができ、PCAP Position Activation Responseメッセージは、HNB GW330に送信されるPUA Direct Transferメッセージの中の、GNSS測定結果および/または位置推定を含み得る(ステップ7)。HNB GW330は、SAS340へのSCCP DT1メッセージの中で、PCAP Position Activation Requestメッセージを、転送することができる(ステップ8)。
【００７９】
SAS340は、PCAP Position Activation Responseメッセージから、GNSS測定結果および/または位置推定を受信することができる。SAS340は、(与えられる場合には)GNSS測定結果に基づいて、HNB320の位置推定を計算することができ、かつ/または、HNB320の位置推定を検証することができる(ステップ9)。そして、SAS340は、PCAP Position Initiation Responseメッセージの中で、SAS340により計算されかつ/または検証される位置推定を送信することができ、PCAP Position Initiation Responseメッセージは、HNB330へのSCCP DT1メッセージの中で搬送され得る(ステップ10)。HNB GW330は、HNB320へのPUA Direct Transferメッセージの中で、PCAP Position Initiation Responseメッセージを、転送することができる(ステップ11)。
【００８０】
HNB320は、PUA DisconnectメッセージをHNB GW330に送信することによって、SAS340による位置決定セッションを終了することができ(ステップ12)、HNB GW330は、SCCP Releasedメッセージを、SAS340に送信することができる(ステップ13)。SAS340は、SCCP Release Complete(RLC)メッセージを返すことができる(ステップ14)。HNB320は、自身の位置推定を記憶することができ、かつ/またはHMS324に位置推定を提供することができる。
【００８１】
図7において、SAS340は、ステップ4および5において、A-GNSSのための支援データをHNB320に送信することができる。HNB320は、ステップ6において、HNB320が新たな支援データを必要とすると判定することができる。この場合、HNB320は、支援データの要求をSAS340に送信することができる。そして、ステップ4から8が実行され、新たな支援データをHNB320に提供することができる。同様に図7において、SAS340は、ステップ9において、SAS340がさらなる測定結果または別の位置推定を必要とすると判定することができ、HNB320からの測定結果または位置推定を得るために、ステップ4から8を繰り返すことができる。
【００８２】
図7はA-GNSSの使用を示すが、SAS340は、ステップ4から8において、1つまたは複数の追加のまたは代替的な測位方法を呼び出してもよい。たとえば、SAS340はOTDOAを呼び出してよく、ステップ4および5で送信されるPCAP Position Activationメッセージの中に、OTDOAのための支援データを含めてもよい。そして、HNB320は、ステップ6において、OTDOA測定結果またはOTDOA測定結果に基づく位置推定を得ることができ、ステップ7および8において、PCAP Position Activation Responseメッセージの中で、SAS340にOTDOA測定結果または位置推定を返すことができる。HNB320はまた、ステップ2および3においてSAS340に送信されるPCAP Position Initiation Requestメッセージの中に、HNB320自体の識別情報(たとえばIMSIまたはIMEI)も含めてよい。この識別情報は、SAS340における、ネットワーク300の管理者によるHNB320の識別情報(たとえば、HNBのセットの広範な識別情報)の事前構成により、いくつかのHNBのいずれかに、または特にHNB320に属するものとして、SAS340により認識され得る。SAS340は、この既知の識別情報を用いて、測位方法を呼び出し、UE(たとえばUE310)の位置決定を行うのよりもHNB(たとえばHNB320)の位置決定を行うのにより適切な支援データを、ステップ4および5においてHNB320に提供することができる。SAS340はまた、新たな位置決定セッションを支援するために、HNB320のために事前に取得され記憶された他の情報(たとえば、HNB320の前の位置推定)、またはHNB320のために構成された他の情報(たとえば、測位能力)を、取り出すことができる。
【００８３】
一設計では、メッセージフロー700は、PCAPへの何らかの変化、ならびに、HNB320およびSAS340における測位への何らかの関連する変化により援助され得る。HNBを示すものおよび/または何らかの他のHNBの識別情報(たとえば、IMSIまたはIMEIではない)が、PCAPメッセージの中に含まれ得る。SAS340は、既知のHNB特性および/または前に得られたHNB情報(たとえば、HNB320がHNB GW330に登録した後でHNB320により提供された情報)を用いて、位置決定のサポートを改善することができる。SAS340はまた、HNB320について得られる任意の新たな位置により、HNB320についてのSAS340の情報を更新することができる。PCAP Position Initiation Requestメッセージの中のセルID IEは、信号強度が良好である場合には、近くのマクロセルのためのものであってよい。あるいは、HNB320の概略的な位置推定は、そのようなマクロセルがない場合には、PCAPメッセージ(たとえば、ステップ2および3のPCAP Position Initiation Requestメッセージ)の中で提供されてもよい。OTDOAでは、マクロ参照セル(たとえば、HNB320により提供される任意のマクロセル)が、OTDOA測定に好適であり得る。E-CIDでは、UEのために定義される測定結果のみが、SAS340に提供されてよいが、これらの測定結果は、HNB320がUEであるかのように、HNB320によりSAS340に提供され得る。A-GNSSでは、SAS340からの任意のfine time assistance(FTA)が、HNB320に見える近くのマクロセルに対して提供され得る。
【００８４】
別の設計では、メッセージフロー700は、PCAPおよびSAS340への影響を避けるために、HNB320によりサーブされHNB320と同じ場所に配置される(たとえば、往復時間(RTT)が0である)UEの位置を、HNB320にエミュレートさせることによって、援助され得る。
【００８５】
一設計では、HNB320は、HNB320によりサーブされる、またはHNB320の近くに位置するUEの位置決定を支援するために、A-GNSS、OTDOA、および/または他の測位方法のための情報(たとえば、支援データ)を、SAS340から要求することができる。その要求および要求された情報は、PCAPメッセージの中で送信されてよく、PCAPメッセージは、PUAおよびSCCPを用いて、HNB GW330により転送され得る。たとえば、要求は、PCAP Information Exchange Initiation Requestメッセージの中で、送信され得る。要求された情報は、PCAP Information Exchange Initiation Responseメッセージの中で、またはPCAP Information Reportメッセージの中で定期的に、送信され得る。HNB320は、SAS340から受信される情報を、UE(たとえばUE310)が測位で用いるためにUEにブロードキャストすることができる。ブロードキャストをサポートするかどうかについての決定が、たとえば、HNB320がHMS324に登録するときに、行われ得る。
【００８６】
図8はUEのための位置決定サービスをサポートするための、処理800の設計を示す。処理800は、HNB、MSC、SGSN、RNC、MME、BSCなどであり得る、ネットワークエンティティによって実行され得る。たとえば、ネットワークエンティティは、図2のメッセージフロー200におけるHNB120であってよい。
【００８７】
ネットワークエンティティは、UEのための位置決定サービスの要求を受信することができる(ブロック812)。ネットワークエンティティは、ユーザプレーンの位置決定法(たとえばSUPL)を介して位置決定サーバ(たとえばH-SLP)と通信し、UEのための位置決定サービスをサポートすることができる(ブロック814)。ネットワークエンティティは、制御プレーンの位置決定法(たとえば3GPPの制御プレーンの位置決定法)を介してUEと通信し、UEのための位置決定サービスをサポートすることができる(ブロック816)。ネットワークエンティティは、ユーザプレーンの位置決定法と制御プレーンの位置決定法との間で、切替動作することができる(ブロック818)。
【００８８】
位置決定サービスは、UEの位置を求めるための測位(たとえば、A-GNSSまたは何らかの他のネットワークにより支援される測位方法による)、UEへの支援データの送達などを含み得る。ネットワークエンティティは、位置決定サーバまたはUEから、UEのための位置推定を得ることができる(ブロック820)。ネットワークエンティティは、要求に応答して、UEのための位置推定を返すことができる(ブロック822)。
【００８９】
一設計では、ネットワークエンティティは、ユーザプレーンの位置決定法のための第1のメッセージを位置決定サーバから受信することができ、制御プレーンの位置決定法のための第2のメッセージをUEに送信することができる。ネットワークエンティティは、第1のメッセージの中の情報の少なくとも一部を、第2のメッセージに移すことができる。ネットワークエンティティは、制御プレーンの位置決定法のための第3のメッセージをUEから受信することができ、ユーザプレーンの位置決定法のための第4のメッセージを位置決定サーバに送信することができる。ネットワークエンティティは、第3のメッセージの中の情報の少なくとも一部を、第4のメッセージに移すことができる。一設計では、第1のメッセージおよび第4のメッセージは、RRLP測位プロトコルのためのものであってよく、第2のメッセージおよび第3のメッセージは、RRC測位プロトコルのためのものであってよい。
【００９０】
一設計では、ネットワークエンティティは、位置決定サーバと通信するためのUEとして動作することができ、UEの能力を位置決定サーバに提供することができる。位置決定サーバは、UEの測位能力に基づいて、支援(たとえば、支援データの送達、位置推定の計算または検証など)を提供することができる。
【００９１】
図9はUEのための位置決定サービスをサポートするための、処理900の設計を示す。処理900は、HNB(以下で説明されるような)または何らかの他のエンティティにより実行され得る。たとえば、HNBは、図5のメッセージフロー500におけるHNB320であってよい。
【００９２】
HNBは、UEのための位置決定サービスの要求を受信することができる(ブロック912)。HNBは、HNB GWを介して、位置決定サーバ(たとえばSAS)とPCAPメッセージを交換し、UEのための位置決定サービスをサポートすることができる(ブロック914)。PCAPメッセージは、(i)HNBとHNB GWとの間では第1のプロトコル(たとえばPUAまたはRUA)のメッセージで、(ii)HNB GWと位置決定サーバとの間では第2のプロトコル(たとえばSCCP)のメッセージで移送され得る。HNBは、UEのための位置決定サービスをサポートするために、UEとRRCメッセージを交換することができる(ブロック916)。
【００９３】
位置決定サービスは、UEの位置を求めるための測位(たとえば、A-GNSSまたは何らかの他のネットワークにより支援される測位方法による)、UEへの支援データの送達などを含み得る。HNBは、位置決定サーバまたはUEから、UEのための位置推定を得ることができる(ブロック918)。HNBは、要求に応答して、UEのための位置推定を返すことができる(ブロック920)。
【００９４】
一設計では、HNBは、位置決定サーバから第1のPCAPメッセージを受信することができ、第1のRRCメッセージをUEに送信することができる。第1のRRCメッセージは、測位要求および/または支援データを含んでもよく、これらは第1のPCAPメッセージから得ることができる。一設計では、HNBは、UEから第2のRRCメッセージを受信することができ、第2のPCAPメッセージを位置決定サーバに送信することができる。PCAPメッセージは、UEにより生成された測定結果および/またはUEのための位置推定を含んでもよく、これらはRRCメッセージから得ることができる。
【００９５】
一設計では、PCAPメッセージは、HNBとHNB GWとの間で、PUAメッセージの中で移送され得る。一設計では、PCAPメッセージはトランザクション型のメッセージであってよく、PUAメッセージは、SCCPを介したコネクション型またはコネクションレスの移送と関連付けられ得る。PUAメッセージは、位置決定サーバ(たとえばSAS)、トランザクション識別子、ローカルの接続の参照、PCAPメッセージ、またはこれらの組合せを含み得る。
【００９６】
一設計では、HNBは、HNB自体の情報を位置決定サーバに送信することができる。この情報は、HNBのセルグローバル識別子、HNBの位置、少なくとも1つの近隣セルの少なくとも1つのセルID、HNBの測位能力などを含み得る。
【００９７】
図10は、UEのための位置決定サービスをサポートするための、処理1000の設計を示す。処理1000は、第1のHNB(以下で説明されるような)または何らかの他のエンティティにより実行され得る。たとえば、第1のHNBは、図6のメッセージフロー600におけるソースHNB320であってよい。
【００９８】
第1のHNBは、位置決定サーバにより位置測定手順を実行し、第1のHNBと通信するUEのための位置決定サービスをサポートすることができる(ブロック1012)。位置決定サービスは、UEの位置を求めるための測位(たとえば、A-GNSSまたは何らかの他のネットワークにより支援される測位方法による)、UEへの支援データの送達などを含み得る。第1のHNBは、第1のHNBから第2のHNBへ、UEをハンドオーバーするための指示を得ることができる(ブロック1014)。第1のHNBおよび第2のHNBは、ともに同じHNB GWとインターフェースをとることができ、HNB GWを介して位置決定サーバと通信することができる。第1のHNBは、第2のHNBに位置状態情報を移送することができる(ブロック1016)。位置状態情報は、位置決定手順で用いられる少なくとも1つの測位方法、各測位方法のために取得される情報、位置の報告に関連する情報、および/または他の情報を含み得る。位置決定手順は、第1のHNBにより提供される位置状態情報に基づいて、第2のHNBおよび位置決定サーバにより継続され得る。
【００９９】
第1のHNBは、第2のHNBへのUEのハンドオーバーの後に、位置決定手順を中止すべきか位置決定手順を継続すべきかを、決定することができる。第1のHNBは、位置決定手順を継続するという決定に応答して、位置状態情報を第2のHNBに移送することができる。第1のHNBは、第1のHNBから第2のHNBへのUEのハンドオーバーが失敗したと、判定することがある。その場合、第1のHNBは、UEのハンドオーバーが失敗したと判定されると、位置決定サーバによる位置決定手順を継続することができる。
【０１００】
図11はHNBのための位置決定サービスをサポートするための、処理1100の設計を示す。処理1100は、HNB(以下で説明されるような)または何らかの他のエンティティにより実行され得る。たとえば、HNBは、図7のメッセージフロー700におけるHNB320であってよい。HNBは、HNBの測位のために、(たとえばHNB GWを介して)位置決定サーバとPCAPメッセージを交換することができる(ブロック1112)。PCAPメッセージは、(i)HNBとHNB GWとの間では第1のプロトコル(たとえばPUA)のメッセージで、(ii)HNB GWと位置決定サーバとの間では第2のプロトコル(たとえばSCCP)のメッセージで移送され得る。HNBは、PCAPメッセージに基づいて自身の位置を求めることができる(ブロック1114)。
【０１０１】
図12は、UE1210、HNB/ホーム基地局1220、HNB GW1230、および位置決定サーバ1240の設計のブロック図を示す。UE1210は、図1のUE110または図3のUE310であってよい。HNB1220は、図1のHNB120または図3のHNB320であってよい。HNB GW1230は、図1のHNB GW130または図3のHNB GW330であってよい。位置決定サーバ1240は、図1のH-SLP140または図3のSAS340であってよい。簡単にするために、図12は、(i)UE1210に対して、1つのコントローラ/プロセッサ1212、1つのメモリ1214、および1つの送信機/受信機(TMTR/RCVR)1216を、(ii)HNB1220に対して、1つのコントローラ/プロセッサ1222、1つのメモリ(Mem)1224、1つの送信機/受信機1226、および1つの通信(Comm)ユニット1228を、(iii)HNB GW1230に対して、1つのコントローラ/プロセッサ1232、1つのメモリ1234、および1つの通信ユニット1236を、ならびに(iv)位置決定サーバ1240に対して、1つのコントローラ/プロセッサ1242、1つのメモリ1244、および1つの通信ユニット1246を、示す。一般に、各エンティティは、任意の数のコントローラ、プロセッサ、メモリ、送受信機、通信ユニットなどを含んでもよい。
【０１０２】
ダウンリンクでは、HNB1220は、トラフィックデータ、シグナリング、ブロードキャスト情報、およびパイロット信号を、HNB1220のカバレッジの中のUEに送信することができる。これらの様々な種類のデータは、プロセッサ1222により処理され、送信機1226により調整され、ダウンリンクで送信され得る。UE1210において、HNB1220および/または他の基地局からのダウンリンク信号は、アンテナを介して受信され、受信機1216により調整され、プロセッサ1212により処理されて、HNB1220および/または他の基地局により送信される様々な種類の情報を回復することができる。プロセッサ1212は、図2、5、および6のメッセージフローにおいて、UEのための処理を実行することができる。メモリ1214および1224は、それぞれUE1210およびHNB1220のための、プログラムコードおよびデータを記憶することができる。アップリンクでは、UE1210は、トラフィックデータ、シグナリング、およびパイロット信号を、HNB1220および/または基地局に送信することができる。これらの様々な種類のデータは、プロセッサ1212により処理され、送信機1216により調整され、アップリンクで送信され得る。HNB1220において、UE1210および他のUEからのアップリンク信号は、受信機1226により受信および調整され、プロセッサ1222によりさらに処理されて、UE1210および他のUEにより送信される様々な種類の情報を回復することができる。プロセッサ1222は、図8の処理800、図9の処理900、図10の処理1000、図11の処理1100、および/または本明細書で説明される技法のための他の処理を、実行または指示することができる。プロセッサ1222は、図2、5、6、および7のメッセージフローにおいて、HNB120または320のための処理を実行することもできる。HNB1220は、通信ユニット1228を介して、他のネットワークエンティティと通信することができる。
【０１０３】
HNB GW1230の中で、プロセッサ1232は、制御の及ぶ範囲でHNBのための通信をサポートし、HNB1220と位置決定サーバ1240との間のメッセージの移送をサポートし、HNB GWにより通常実行される他の機能を実行することができる。プロセッサ1232は、図2、5、6、および7のメッセージフローにおいて、HNB GW130または330のための処理を実行することもできる。メモリ1234は、HNB GW1230のためのプログラムコードまたはデータを記憶することができる。通信ユニット1236は、HNB GW1230が、他のエンティティと通信できるようにし得る。
【０１０４】
位置決定サーバ1240の中で、プロセッサ1242は、UEのための測位を実行し、UEに支援データを提供し、UEおよび他のLCSクライアントのための位置決定サービスをサポートすることなどができる。プロセッサ1242はまた、図2のメッセージフローにおいてはH-SLP140のための、図5、6および7のメッセージフローにおいてはSAS340のための処理を、実行することもできる。メモリ1244は、位置決定サーバ1240のためのプログラムコードおよびデータを記憶することができる。通信ユニット1246は、位置決定サーバ1240が、他のエンティティと通信できるようにし得る。
【０１０５】
情報および信号は、多種多様な技術および技法のいずれかを使用して表され得ることを当業者であれば理解されよう。たとえば、上記の説明の全体にわたって言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、およびチップは、電圧、電流、電磁波、磁界もしくは粒子、光場もしくは粒子、またはその任意の組み合わせによって表され得る。
【０１０６】
さらに、本明細書の開示に関して説明した様々な例示的な論理ブロック、モジュール、回路、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、または両方の組合せとして実装され得ることを、当業者は理解されよう。ハードウェアとソフトウェアのこの互換性を明確に示すために、様々な例示的な構成要素、ブロック、モジュール、回路、およびステップを、上記では概してそれらの機能に関して説明した。そのような機能をハードウェアとして実装するか、ソフトウェアとして実装するかは、具体的な適用例および全体的なシステムに課される設計制約に依存する。当業者は、説明した機能を具体的な適用例ごとに様々な方法で実装し得るが、そのような実装の決定は、本開示の範囲からの逸脱を生じるものと解釈すべきではない。
【０１０７】
本明細書の開示に関して説明する様々な例示的な論理ブロック、モジュール、および回路は、汎用プロセッサ、デジタルシグナルプロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)または他のプログラマブル論理デバイス、個別ゲートまたはトランジスタ論理、個別ハードウェア構成要素、または本明細書で説明する機能を実行するように設計されたそれらの任意の組合せで実装または実行することができる。汎用プロセッサはマイクロプロセッサであり得るが、代替として、汎用プロセッサは任意の従来のプロセッサ、コントローラ、マイクロコントローラ、または状態機械であり得る。プロセッサはまた、コンピューティングデバイスの組合せ、たとえば、DSPとマイクロプロセッサとの組合せ、複数のマイクロプロセッサ、DSPコアと連携する1つもしくは複数のマイクロプロセッサ、または任意の他のそのような構成として実装され得る。
【０１０８】
本明細書の開示に関して説明する方法またはアルゴリズムのステップは、直接ハードウェアで実施されるか、プロセッサによって実行されるソフトウェアモジュールで実施されるか、またはその2つの組合せで実施され得る。ソフトウェアモジュールは、RAMメモリ、フラッシュメモリ、ROMメモリ、EPROMメモリ、EEPROMメモリ、レジスタ、ハードディスク、リムーバブルディスク、CD-ROM、または当技術分野で知られている任意の他の形態の記憶媒体中に存在し得る。例示的な記憶媒体は、プロセッサが記憶媒体から情報を読み取り、記憶媒体に情報を書き込むことができるように、プロセッサに結合される。代替として、記憶媒体はプロセッサと一体であり得る。プロセッサおよび記憶媒体はASIC中に存在し得る。ASICはユーザ端末中に存在し得る。代替として、プロセッサおよび記憶媒体は、ユーザ端末中に個別構成要素として存在し得る。
【０１０９】
1つまたは複数の例示的な設計では、説明した機能はハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装する場合、機能は、1つまたは複数の命令またはコードとしてコンピュータ可読媒体上に記憶され得る。コンピュータ可読媒体は、過渡的な伝搬信号を指さない。記憶媒体は、汎用または専用コンピュータによってアクセスされ得る任意の利用可能な媒体であり得る。限定ではなく例として、そのようなコンピュータ可読媒体は、RAM、ROM、EEPROM、CD-ROM、または他の光ディスクストレージ、磁気ディスクストレージまたは他の磁気ストレージデバイス、または命令もしくはデータ構造の形態の所望のプログラムコード手段を記憶するために使用されて、汎用もしくは専用コンピュータまたは汎用もしくは専用プロセッサによってアクセスされ得る、任意の他の媒体を含むことができる。本明細書で使用する場合、ディスク(disk)およびディスク(disc)は、コンパクトディスク(CD)、レーザーディスク（登録商標）、光ディスク、デジタル多用途ディスク(DVD)、フロッピー（登録商標）ディスク、およびブルーレイディスクを含み、ディスク(disk)は、通常、磁気的にデータを再生し、ディスク(disc)は、レーザーで光学的にデータを再生する。上記の組合せもコンピュータ可読媒体の範囲内に含まれるものとする。
【０１１０】
本開示の上記の説明は、当業者が本開示を作成または使用できるようにするために提供される。本開示への様々な修正が当業者には容易に明らかとなり、本明細書で定義した一般原理は、本開示の趣旨および範囲を逸脱することなく他の変形形態に適用され得る。したがって、本開示は、本明細書で説明される例および設計に限定されるものではなく、本明細書で開示する原理および新規の特徴に一致する最大の範囲を与えられるものである。
【符号の説明】
【０１１１】
100  ワイヤレスネットワーク
110  ユーザ装置
120  HNB
130  HNBゲートウェイ
140  H-SLP
150  基幹ネットワーク
300  ワイヤレスネットワーク
310  ユーザ装置
320  HNB
322  HNB
324  HMS
330  HNBゲートウェイ
340  SAS
350  基幹ネットワーク
352  MSC/SGSN
354  GMLC
360  LCSクライアント
1210  ユーザ装置
1220  HNB
1230  HNBゲートウェイ
1240  位置サーバ
【図２】
0005548816.tif 000002
【図２Ａ】
0005548816.tif 000003
【図４】
0005548816.tif 000004
【図５】
0005548816.tif 000005
【図５Ａ】
0005548816.tif 000006
【図６】
0005548816.tif 000007
【図６Ａ】
0005548816.tif 000008
【図７】
0005548816.tif 000009
【図８】
0005548816.tif 000010
【図９】
0005548816.tif 000011
【図１０】
0005548816.tif 000012
【図１１】
0005548816.tif 000013
【図１２】
0005548816.tif 000014
【図１】
0005548816.tif 000015
【図３】
0005548816.tif 000016