(57)【要約】モバイルまたは無線装置が異なるキャリア・ネットワーク間をローミングしたときでさえ、途切れのないユーザ・プレーン位置情報サービスを可能にする、改善されたユーザ・プレーン位置情報サービス（ＬＢＳ）アーキテクチャおよびメッセージ・フロー。本発明は、セキュア・ユーザ・プレーン位置特定サービス仕様で定義された、現在のローミング・サポート用プロトコルに固有の制約を克服する。位置特定システムは自動的にメッセージ・トンネリング・メカニズムにフォールバックすることが可能となり、位置特定サービス・システムと対象無線装置との間の通信パスのセキュリティを保証し、無線装置が移動してもその通信パスが途切れないようにすることができる。
2007513580.tif 000002
【特許請求の範囲】
【請求項１】
ローミングする無線装置にユーザ・プレーン位置情報サービスを提供する方法であって、
契約先の無線キャリア・ネットワークの契約先ＬＣＳマネージャと目下在圏する無線キャリア・ネットワークの在圏先ＬＣＳマネージャとの間でローミング・インターフェースを確立するステップと、
前記契約先の無線キャリア・ネットワークのファイアウォールおよび前記在圏先の無線キャリア・ネットワークのファイアウォールを通過して送信される機能を有するＩＰ接続をインターネットを介して導くステップと、
位置特定サービス・システムと位置特定の対象となる無線装置との間に途切れのない通信パスを提供するためのメッセージ・トンネリング・メカニズムを提供するステップとを含む方法。
【請求項２】
前記ローミングする無線装置が携帯電話を含む、請求項１に記載のローミングする無線装置にユーザ・プレーン位置情報サービスを提供する方法。
【請求項３】
前記ローミングする無線装置が携帯情報端末（ＰＤＡ）装置を含む、請求項１に記載のローミングする無線装置にユーザ・プレーン位置情報サービスを提供する方法。
【請求項４】
前記ローミングする無線装置が無線電子メール装置を含む、請求項１に記載のローミングする無線装置にユーザ・プレーン位置情報サービスを提供する方法。
【請求項５】
前記ローミングする無線装置がカメラ付無線装置を含む、請求項１に記載のローミングする無線装置にユーザ・プレーン位置情報サービスを提供する方法。
【請求項６】
ローミングする無線装置にユーザ・プレーン位置情報サービスを提供する装置であって、
契約先の無線キャリア・ネットワークの契約先ＬＣＳマネージャと目下在圏する無線キャリア・ネットワークの在圏先ＬＣＳマネージャとの間でローミング・インターフェースを確立する手段と、
前記契約先の無線キャリア・ネットワークのファイアウォールおよび前記在圏先の無線キャリア・ネットワークのファイアウォールを通過して送信される機能を有するＩＰ接続をインターネットを介して導く手段と、
位置特定サービス・システムと位置特定の対象となる無線装置との間に途切れのない通信パスを提供するためのメッセージ・トンネリング・メカニズムを提供する手段とを含む装置。
【請求項７】
前記ローミングする無線装置が携帯電話を含む、請求項６に記載のローミングする無線装置にユーザ・プレーン位置情報サービスを提供する装置。
【請求項８】
前記ローミングする無線装置が携帯情報端末（ＰＤＡ）装置を含む、請求項６に記載のローミングする無線装置にユーザ・プレーン位置情報サービスを提供する装置。
【請求項９】
前記ローミングする無線装置が無線電子メール装置を含む、請求項６に記載のローミングする無線装置にユーザ・プレーン位置情報サービスを提供する装置。
【請求項１０】
前記ローミングする無線装置がカメラ付無線装置を含む、請求項６に記載のローミングする無線装置にユーザ・プレーン位置情報サービスを提供する装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般に、無線および長距離キャリア、インターネット・サービス・プロバイダ（ＩＳＰ）、ならびに情報コンテンツ配信サービス／プロバイダおよび長距離キャリアに関する。より詳細には、本発明は無線通信事業の位置特定サービス（ｌｏｃａｔｉｏｎ  ｓｅｒｖｉｃｅｓ）に関する。
【背景技術】
【０００２】
無線ネットワーク内にある無線装置（例えば無線電話）の物理的な位置を正確に特定することが望まれる。位置情報サービス（ｌｏｃａｔｉｏｎ  ｂａｓｅｄ  ｓｅｒｖｉｃｅ）（ＬＳＢ）を達成するために、現在、異なる２つのタイプのアーキテクチャが開発されている。すなわち、制御プレーン位置情報サービス（Ｃｏｎｔｒｏｌ  Ｐｌａｎｅ  ｌｏｃａｔｉｏｎ  ｂａｓｅｄ  ｓｅｒｖｉｃｅｓ）と、より最近のユーザ・プレーン位置情報サービス（Ｕｓｅｒ  Ｐｌａｎｅ  ｌｏｃａｔｉｏｎ  ｂａｓｅｄ  ｓｅｒｖｉｃｅｓ）である。
【０００３】
より古い位置情報サービスは、制御プレーン位置情報サービスと現在呼ばれているものを利用する。ある制御プレーン位置情報サービスは、管理システムを利用して処理の自動化、構築を行い、在庫管理を実施する。ある制御プレーン位置情報サービスは、制御メッセージまたはシグナリング・メッセージを利用して、個々の無線装置の位置を判定する。
【０００４】
これら２つの技術の決定的な違いは、制御プレーン・ソリューションが制御チャネルを用いて無線装置と通信するのに対して、ユーザ・プレーン・ソリューションは加入者のトラフィック・チャネル自体（例えばＩＰベアラ（ＩＰ  ｂｅａｒｅｒ）あるいはＳＭＳ）を用いて無線装置と通信することである。制御プレーン・ソリューションは、既存のほぼすべてのネットワーク構成要素および無線装置に対するソフトウェア更新を必要とするが、ユーザ・プレーン・ソリューションは、キャリアが位置情報サービスを提供する上で、より実現可能なソリューションと見なされている。
【０００５】
ユーザ・プレーン位置情報サービスとして知られる概念では、ユーザのベアラ・チャネルそれ自体、例えばＩＰベアラあるいはＳＭＳを利用して、測位手順（ｐｏｓｉｔｉｏｎｉｎｇ  ｐｒｏｃｅｄｕｒｅ）を開始するのに必要となる通信を確立する。ユーザ・プレーン位置情報サービスは、３ＧＰＰなどの標準化団体で定義された、代替位置特定サービス・アーキテクチャとして導入されてきた。
【０００６】
したがってユーザ・プレーン位置情報サービスは、通信コンテンツそれ自体を利用して無線装置の位置を特定する。ユーザ・プレーン位置情報サービスは携帯電話など無線装置のＴＣＰ／ＩＰ機能に焦点を合わせて、一般にはキャリアのインフラストラクチャは回避し、その代わりに、例えばインターネットを利用する。ユーザ・プレーン位置情報サービスの配備には、制御プレーン位置情報サービスのそれよりも容易で合理的なアーキテクチャを含めて、大きな利点がある。このようにしてコストが高くつく更新は回避され、他の点では従来型のシステム構成要素を使った、迅速で比較的安価な配備が可能である。
【０００７】
ユーザ・プレーン位置情報サービスでは、対象（ｔａｒｇｅｔ）移動端末（ｍｏｂｉｌｅ）がローミングし、ＩＰベアラが使われている（ＩＰベアラは、ユーザ・プレーン位置特定サービス・ソリューションでのデフォルトのベアラである）とき、位置特定サービス手順に関して問題のあることに本発明者らは気付いた。ローミングとは、異なる無線キャリアがカバーする領域間を無線装置が物理的に移動することをいう。
【０００８】
具体的には、従来のユーザ・プレーン位置特定サービス・アーキテクチャによれば、位置特定の対象となる無線装置または移動端末は、その無線装置が在圏するセルでサービスを実行している測位サーバ（Ｐｏｓｉｔｉｏｎｉｎｇ  Ｓｅｒｖｅｒ）（３ＧＰＰではＧＭＬＣ、３ＧＰＰ２ではＭＰＣとして知られる）と通信しなければならない。この手順では、ＰＤＰコンテキスト（ＰＤＰ  Ｃｏｎｔｅｘｔ）が、無線装置とその無線装置の契約先公衆陸上移動体ネットワーク（Ｈｏｍｅ  Ｐｕｂｌｉｃ  Ｌａｎｄ  Ｍｏｂｉｌｅ  Ｎｅｔｗｏｒｋ）（Ｈ−ＰＬＭＮ）内のＧＧＳＮとの間で確立される。ＰＤＰコンテキストは、対象無線装置がＩＰネットワークにアクセスするために確立される、Ｈ−ＬＣＳマネージャ（Ｈ−ＬＣＳ  Ｍａｎａｇｅｒ）（３ＧＰＰではＨ−ＧＭＬＣ、３ＧＰＰ２ではＨ−ＭＰＣとして知られる）、在圏先ＬＣＳマネージャ（Ｖｉｓｉｔｅｄ−ＬＣＳ  Ｍａｎａｇｅｒ）（３ＧＰＰでは在圏先ＧＭＬＣ、３ＧＰＰ２では在圏先ＭＰＣとして知られる）、および／または測位サーバ（３ＧＰＰではＳＭＬＣ、３ＧＰＰ２ではＰＤＥとして知られる）を含む通信チャネルである。
【０００９】
しかし、本発明者らは、異なるＰＬＭＮのＩＰネットワークが、セキュリティ上の理由から、保護用のＩＰファイアウォールで隔てられていることに気付く。さらにＰＬＭＮの内部では、ＩＰネットワークは通常、プライベートＩＰアドレスを使用するプライベート・ネットワークとして構成される。インターネットへのＩＰ接続は、ＮＡＴ機能を提供するゲートウェイ・ルータを通過する。それにもかかわらず、現在定義されているユーザ・プレーン位置情報サービスでは、対象無線装置は、在圏先ＬＣＳマネージャの提供する測位サーバのプライベートＩＰアドレスを用いて、契約先ＰＬＭＮ内のＧＧＳＮを介して在圏先ＰＬＭＮ内の測位サーバと通信しなければならない。しかし、あるローミング・シナリオでは、さまざまなファイアウォールのせいで無線装置が適切な測位サーバと直接通信することが現在のところ不可能であることに気付かされる。
【００１０】
ユーザ・プレーン位置ベース・ソリューションが開発され、多くのネットワークに配備されているが、サポートは、特にベアラとしてＧＰＲＳ  ＩＰベアラが使われるときは、万全といえない。本発明は、ユーザ・プレーン位置情報サービス・ソリューションのローミング・シナリオに関する重要な問題を解決する方法を導入する。
【００１１】
従来の３ＧＰＰネットワーク・アーキテクチャでは、移動端末がＰＤＰコンテキストと呼ばれるパケット・データ・サービス・セッション（ｐａｃｋｅｔ  ｄａｔａ  ｓｅｒｖｉｃｅ  ｓｅｓｓｉｏｎ）を開始すると、位置特定ＳＧＳＮが、移動端末の提供するアクセス・ポイント名（Ａｃｃｅｓｓ  Ｐｏｉｎｔ  Ｎａｍｅ）（ＡＰＮ）の示すＧＧＳＮへの接続を確立する。ＡＰＮにより識別されるＧＧＳＮは通常、移動端末の契約先公衆陸上移動体ネットワーク（Ｈ−ＰＬＭＮ）に置かれている。そこでこのローミング・シナリオでは、ＭＳと契約先ＰＬＭＮ内のＧＧＳＮとの間でＩＰベアラが確立される。したがって移動端末とのＩＰトラフィックはすべて、契約先ＰＬＭＮにトンネル接続される。
【００１２】
３ＧＰＰ規格のリリース６アーキテクチャでは、位置情報ゲートウェイ（Ｇａｔｅｗａｙ  Ｍｏｂｉｌｅ  Ｌｏｃａｔｉｏｎ  Ｃｅｎｔｅｒ）（ＧＭＬＣ）は、Ｌｒインターフェースを使って異なるＰＬＭＮ内に置かれた他のＧＭＬＣと通信することができる。したがってＬｒインターフェースは、ローミング・シナリオにおいて適切なサービスを提供しようと試みて、ＰＬＭＮのファイアウォールを通過することが許される。あるローミング・シナリオにおける典型的な移動体着信（Ｍｏｂｉｌｅ  Ｔｅｒｍｉｎａｔｉｎｇ）（ＭＴ）位置特定サービスでは、移動端末または無線装置は、位置情報（ｌｏｃａｔｉｏｎ  ｉｎｆｏｒｍａｔｉｏｎ）を交換し、使用されている具体的な測位方法に応じた補助情報（ａｓｓｉｓｔａｎｃｅ）および測位計算（ｐｏｓｉｔｉｏｎｉｎｇ  ｃａｌｃｕｌａｔｉｏｎ）を要求するために、ユーザ・プレーン位置情報サービスのローカルの測位サーバ（３ＧＰＰ規格技術を用いる「ＳＭＬＣ」と呼ばれることもある）と通信しなければならない。
【００１３】
しかし、従来のユーザ・プレーン位置情報サービスでは、ＭＴ位置特定サービス手順中に、無線装置にローカルの測位サーバのＩＰアドレスが与えられる。本発明者らが理解したように、通常、このＩＰアドレスはプライベートＩＰアドレスである。したがって理論的には完全なローミング・サポートが可能となるようにみえるが、実際には、プライベート・ネットワーク（Ｈ−ＰＬＭＮ）がファイアウォールで保護されているので、無線装置は必ずしもそのプライベート・ネットワーク（Ｈ−ＰＬＭＮ）からこのＩＰホストに到達できるわけではないことを本発明者らは理解した。
【００１４】
既存のＧＰＲＳネットワーク・アーキテクチャにおいて、ユーザ・プレーン位置情報サービスを利用する実世界にいる加入者（ｒｅａｌ−ｗｏｒｌｄ  ｓｕｂｓｃｒｉｂｅｒ）にローミング・サポートを提供する必要がある。
【発明の開示】
【発明が解決しようとする課題】
【００１５】
本発明の原理によれば、メッセージ・トンネリング・メカニズム（ｍｅｓｓａｇｅ  ｔｕｎｎｅｌｉｎｇ  ｍｅｃｈａｎｉｓｍ）により、対象加入者が異なるネットワークをローミングするときでさえ、位置情報サービスを途切れなくサポートするユーザ・プレーン位置特定サービスが可能になる。
【課題を解決するための手段】
【００１６】
本発明の一態様では、ローミングする無線装置にユーザ・プレーン位置情報サービスを提供する方法は、契約先の無線キャリア・ネットワークの契約先ＬＣＳマネージャと目下在圏する無線キャリア・ネットワークの在圏先ＬＣＳマネージャとの間でローミング・インターフェースを確立するステップを含む。契約先の無線キャリア・ネットワークのファイアウォールおよび在圏先の無線キャリア・ネットワークのファイアウォールを通過して送信される機能を有するＩＰ接続がインターネットを介して導かれる。位置特定サービス・システムと位置特定の対象となる無線装置との間に途切れのない通信パスを提供するためのメッセージ・トンネリング・メカニズムが提供される。
【００１７】
本発明の特徴および利点は、図面を参照しながら以下の説明を読めば当業者には明らかとなるであろう。
【発明を実施するための最良の形態】
【００１８】
本発明は、移動端末または無線装置が異なるキャリア・ネットワーク間をローミングするときでさえ、途切れのないユーザ・プレーン位置情報サービスを可能にする改善されたユーザ・プレーン位置情報サービス（ＬＢＳ）アーキテクチャおよびメッセージ・フローを提供することに関する。
【００１９】
本発明は、セキュア・ユーザ・プレーン位置特定サービス（Ｓｅｃｕｒｅ  Ｕｓｅｒ  Ｐｌａｎｅ  Ｌｏｃａｔｉｏｎ  Ｓｅｒｖｉｃｅ）仕様で定義された、現在のローミング・サポート用プロトコルに固有の制約を克服する。
【００２０】
本発明のソリューションにより、位置特定システムは自動的にメッセージ・トンネリング・メカニズムにフォールバックすることが可能となり、位置特定サービス・システムと対象無線装置との間の通信パスのセキュリティを保証し、無線装置が移動してもその通信パスが途切れないようにすることができる。
【００２１】
図１には、本発明の一態様による例示的なユーザ・プレーン位置特定サービス・アーキテクチャが示してある。
【００２２】
具体的には、図１に示すように、ファイアウォールを通過しインターネットを介してＩＰ接続を導くことのできるローミング・インターフェース（Ｌｒ）が、ＬＣＳマネージャ（３ＧＰＰではＧＭＬＣ、３ＧＰＰ２ではＭＰＣとして知られる）間で確立される。本発明のソリューションでは、契約先ＬＣＳマネージャおよび／または在圏先ＬＣＳマネージャを介して端末間のプロトコル接続を提供するメッセージ・トンネリング・メカニズムを実装する。
【００２３】
本発明により導入される重要な概念は、複数のＧＭＬＣを介する、Ｌｒインターフェースを使ったメッセージング・レベル・トンネリング（ｍｅｓｓａｇｉｎｇ  ｌｅｖｅｌ  ｔｕｎｎｅｌｉｎｇ）の使用である。この方法を使うと、無線装置は、複数のＰＬＭＮを横切ってローカルの測位サーバと通信して、要求されたユーザ・プレーン測位手順を完了することができる。
【００２４】
図２には、図１に示したユーザ・プレーン位置特定サービス取決めに基づく、例示的な既存のユーザ・プレーン位置特定サービスのシグナリングが示してある。
【００２５】
具体的には、図２に示すように、ローミングするＵＥが在圏先ＰＬＭＮに置かれたＶ−測位サーバと通信する必要があるとき、ユーザ・プレーンＬＣＳで定義された手順によれば、どちらも物理的に同じネットワーク内にあるにもかかわらず、ＵＥはそのＶ−測位サーバとＴＣＰ接続を確立することさえできない。したがって現在のユーザ・プレーン・アーキテクチャは、プライベートＩＰアドレス割当てを使用する移動体ネットワーク（ｍｏｂｉｌｅ  ｎｅｔｗｏｒｋｓ）のローミング・シナリオをサポートできない（これは、ＩＰアドレスが限られた資源であるので、この業界では極めてありふれたことである）。
【００２６】
図３には、図１に示したユーザ・プレーン位置特定サービス取決めに基づく、メッセージ・トンネリング・メカニズムを用いた例示的な機能強化されたユーザ・プレーン位置特定サービスのシグナリングが示してある。
【００２７】
具体的には、図３はローミング・シナリオにおけるユーザ・プレーンＬＣＳサービス用のメッセージ・トンネリングの概念を示す。この場合、ＵＥはＶ−測位サーバに送るべきユーザ・プレーン・メッセージを、代わりに契約先ＬＣＳマネージャに送る。契約先ＬＣＳマネージャは、受け取ったメッセージを汎用メッセージ（ｇｅｎｅｒｉｃ  ｍｅｓｓａｇｅ）に封入し、それをＶ−ＬＣＳマネージャに送る。既存の３ＧＰＰリリース６アーキテクチャでは、ＬＣＳマネージャ（３ＧＰＰではＧＭＬＣとして知られる）は、Ｌｒインターフェースを使って異なるＰＬＭＮに置かれた別のＬＣＳマネージャ（またはＧＭＬＣ）と通信することができる。すなわちＬｒインターフェースはＰＬＭＮのファイアウォールを通過することが可能である。Ｖ−ＬＣＳマネージャはまた、メッセージ・トンネリング・メカニズムを使って、ローカルのＩＰネットワーク接続を介してＶ−測位サーバにＵＥからのメッセージを渡す。
【００２８】
図４には、本発明の原理による、ユーザ・プレーン位置情報サービスにおいてメッセージ・トンネリングによりローミングをサポートするための例示的なメッセージ・フローが示してある。
【００２９】
ステップＡ
図４のステップＡに示すように、ＬＣＳエージェント３０２は、位置特定サービス対応アプリケーションから位置特定要求（ｌｏｃａｔｉｏｎ  ｒｅｑｕｅｓｔ）を受け取るとすぐに、そのアプリケーションの認証を行うことができる。認証が成功した場合、ＬＣＳエージェント３０２は、ＬＣＳエージェントが関連付けられている要求元ＬＣＳマネージャ（Ｒｅｑｕｅｓｔｉｎｇ−ＬＣＳ  Ｍａｎａｇｅｒ）（Ｒ−ＬＣＳ  Ｍａｎａｇｅｒ）３０４に、即時位置決定（ｉｍｍｅｄｉａｔｅ  ｌｏｃａｔｉｏｎ  ｆｉｘ）を求めるＭＬＰ位置特定要求を発行する。
【００３０】
ステップＢ
要求元ＬＣＳマネージャ３０４は、ＬＣＳエージェント３０２を認証し、受け取ったＩｃｓ−ｃｌｉｅｎｔ−ｉｄに基づいて、ＬＣＳエージェント３０２にそれが要求するサービスについての権限が与えられていることを確認する。
【００３１】
受け取った対象加入者のｍｓｉｄを検査することによって、Ｒ−ＬＣＳマネージャ３０４は、例えばローミング契約をもとに、あるいはＩＥＴＦ  ＲＦＣ  ２９１６と同様のドメイン・ネーム・サービス（ＤＮＳ）検索メカニズムを用いて、関連する契約先ＬＣＳマネージャ３０６を識別することができる。この関連する契約先ＬＣＳマネージャ３０６を識別するのに用いられるメカニズムは、当業者には公知である。
【００３２】
次いでＲ−ＬＣＳマネージャ３０４は、Ｌｒインターフェースを使って、対象加入者の契約先ＬＣＳマネージャ３０６に位置特定要求を送る。
【００３３】
ステップＣ
位置特定要求を受け取るとすぐに、契約先ＬＣＳマネージャ３０６は、加入者のプライバシー（Ｐｒｉｖａｃｙ）をその要求で受け取ったＩｃｓ−ｃｌｉｅｎｔ−ｉｄ、ｒｅｑｕｅｓｔｏｒ−ｉｄ、ｑｏｓなどに対して適用する。このユースケースでは、プライバシー・チェックは成功したものと仮定する。ＬＣＳマネージャ３０６がその適用を承認していない場合は、ステップＮに適用ＭＬＰ戻りコード（ａｐｐｌｉｃａｂｌｅ  ＭＬＰ  ｒｅｔｕｒｎ  ｃｏｄｅ）が返される。
【００３４】
次いでＨ−ＬＣＳマネージャ３０６は、適切なＬＣＳ  ＩＮＩＴメッセージ、例えば無線アプリケーション・プロトコル（ＷＡＰ）のＰＵＳＨ、あるいはショート・メッセージ・システム（ＳＭＳ）のＴｒｉｇｇｅｒを用いて、ユーザ端末（ｕｓｅｒ  ｅｑｕｉｐｍｅｎｔ）（ＵＥ）３１２の位置特定処理を開始し、タイマＴ１を始動する。
【００３５】
Ｈ−ＬＣＳマネージャ３０６がＵＥの概略位置を知っている場合、Ｈ−ＬＣＳマネージャ３０６は、任意選択で、この時点でＵＥにＵＥ概略位置情報（ＵＥ  ｃｏａｒｓｅ  ｐｏｓｉｔｉｏｎ  ｉｎｆｏｒｍａｔｉｏｎ）を提供することができる。
【００３６】
ステップＢでのプライバシー・チェックの結果が対象加入者に対する通知または確認が必要であると示す場合、Ｈ−ＬＣＳマネージャ３０６はまた、ＬＣＳ  ＩＮＩＴメッセージに通知要素（ｎｏｔｉｆｉｃａｔｉｏｎ  ｅｌｅｍｅｎｔ）を含めることもできる。
【００３７】
ステップＤ
通知／確認（Ｎｏｔｉｆｉｃａｔｉｏｎ／Ｖｅｒｉｆｉｃａｔｉｏｎ）が必要とされる場合、ＵＥのポップアップ・テキストを使って、加入者に、誰が加入者の位置情報（ｌｏｃａｔｉｏｎ  ｉｎｆｏ）、例えばＩｃｓ−ｃｌｉｅｎｔ−ｉｄ、ｒｅｑｕｅｓｔｏｒ−ｉｄ、ｒｅｑｕｅｓｔ−ｔｙｐｅなどを要求しているかを通知することができる。任意選択で、加入者がその位置特定要求を承諾することも、あるいはその位置特定要求を拒否することもできるようにすることもできる。
【００３８】
対象加入者が位置特定要求を承諾した場合、ＵＥ  ３１２は、現在サービスを実行しているセル情報（ｃｅｌｌ  ｉｎｆｏｒｍａｔｉｏｎ）、ＴＡ、ＮＭＲおよび移動体装置の諸機能を取得することによって測位手順を開始する。次いでＵＥ  ３１２は、セル情報（ｃｅｌｌ  ｉｎｆｏ）と、ＵＥが補助データを取得する必要があり、かつ／またはＴＡおよびＮＭＲが利用可能である場合には任意選択のＡＤ、ＴＡおよびＮＭＲとを含む、位置特定開始要求（Ｓｔａｒｔ  Ｌｏｃａｔｉｏｎ  Ｒｅｑｕｅｓｔ）（ＳＬＲＥＱ）を使って、Ｈ−ＬＣＳマネージャ３０６と位置特定セッションを開始する。任意選択で、ＵＥ  ３１２はまた、ＬＣＳ  ＩＮＩＴメッセージで確認が必要とされている場合、対象加入者がアクセスを認められているかどうかを示す。
【００３９】
対象加入者が位置特定要求を拒否した場合、ＵＥ  ３１２は、Ｈ−ＬＣＳマネージャ３０６に対して、拒否の表示を含む位置特定応答（ｌｏｃａｔｉｏｎ  ｒｅｓｐｏｎｓｅ）を開始する。
【００４０】
Ｈ−ＬＣＳマネージャ３０６は、対象加入者から未解決トランザクションについてのＳＬＲＥＱメッセージを受け取ると、タイマＴ１を止める。
【００４１】
ステップＥ
ステップＤで対象加入者が位置特定要求を拒否している場合、ステップＬに適用ＭＬＰ戻りコードが返される。この場合、ステップＥからＫは省略される。そうでない場合、Ｈ−ＬＣＳマネージャ３０６は、対象ＵＥ  ３１２から（または別のメカニズムを介して）のセル情報を使って、対象ＵＥ  ３１２がローミングしていると判定することができる。関連するローミング契約に基づいて、あるいはＩＥＴＦ  ＲＦＣ  ２９１６と同様のＤＮＳ検索メカニズムを用いて、Ｈ−ＬＣＳマネージャ３０６は在圏先ＬＣＳマネージャ３０８を識別することができ、在圏先ＬＣＳマネージャ３０８に対して、メッセージ・トンネリング・メカニズムがこの遷移に使用されることを表すインジケータを含むＬｒ要求を開始する。
【００４２】
ステップＦ
Ｌｒ要求を受け取ると、在圏先ＬＣＳマネージャ３０８は、対象ＵＥ  ３１２が現在置かれているエリアでサービスを実行している測位サーバ３１０に対して、任意選択のセル情報、ＮＭＲ、ｄｅｖｉｃｅ  ｃａｐなどを含む、位置要求（Ｐｏｓｉｔｉｏｎ  Ｒｅｑｕｅｓｔ）（ＰＲＥＱ）を開始する。
【００４３】
ステップＧ
測位サーバ３１０は、Ｖ−ＬＣＳマネージャ３０８に位置応答（Ｐｏｓｉｔｉｏｎ  Ｒｅｓｐｏｎｓｅ）（ＰＲＥＳＰ）を戻し、測位サーバ３１０がｓｅｓｓｉｏｎｉｄによって識別された位置特定要求を処理する準備ができていることを確認する。
【００４４】
ステップＨ
位置応答メッセージを受け取るとすぐに、Ｖ−ＬＣＳマネージャ３０８は、Ｈ−ＬＣＳマネージャ３０６にＬｒ応答メッセージを送る。Ｌｒ応答メッセージは、例えば測位サーバ３１０のＩＰアドレス（ＵＲＬ）を含むことができる。
【００４５】
ステップＩ
サービスを実行している測位サーバ３１０からＰＲＥＳＰメッセージの確認を受け取るとすぐに、Ｈ−ＬＣＳマネージャ３０６は、対象ＵＥ  ３１２に、サービスを実行している測位サーバ３１０と対象ＵＥ  ３１２の間での直接通信が必要とされる場合には非ローミング・シナリオ用に、Ｖ−測位サーバではなくＨＬＣＳマネージャ３０６のアドレスを、また任意選択のｐｏｓｍｏｄｅを含む、位置特定開始応答（Ｓｔａｒｔ  Ｌｏｃａｔｉｏｎ  Ｒｅｓｐｏｎｓｅ）（ＳＬＲＥＳＰ）メッセージを送る。
【００４６】
重要なことには、与えられるサービスを実行している測位サーバ３１０のアドレスが、このローミング・シナリオではプライベートＩＰアドレスであり得ることに留意されたい。
【００４７】
ステップＪ
関連するＵＥ  ３１２のローミングが検出されるとすぐに、対象ＵＥ  ３１２はＨ−ＬＣＳマネージャ３０６に対して、位置決定（ｐｏｓｉｔｉｏｎ  ｄｅｔｅｒｍｉｎａｔｉｏｎ）、例えば位置決定開始（Ｐｏｓｉｔｉｏｎ  Ｄｅｔｅｒｍｉｎａｔｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ）（ＰＤＩＮＩＴ）およびｓｅｓｓｉｏｎｉｄを開始する。ＰＤＩＮＩＴメッセージは、任意選択で追加情報、例えばｃｅｌｌ  ｉｄ、ａｄ、および／またはＩＳ−８０１  ＰＤＵを含む。
【００４８】
ステップＫ
このメッセージを受け取ると、Ｈ−ＬＣＳマネージャ３０６は、関連するＬｒ接続を介してＶ−ＬＣＳマネージャ３０８に、位置データ（Ｐｏｓｉｔｉｏｎ  Ｄａｔａ）・メッセージに入れて、ｓｅｓｓｉｏｎｉｄに対応するＰＤＩＮＩＴメッセージを送る。
【００４９】
ステップＬ
Ｖ−ＬＣＳマネージャ３０８は、サービスを実行している測位サーバ３１０に、受け取った位置データ・メッセージを送る。
【００５０】
ステップＭ
測位サーバ３１０および対象ＵＥ  ３１２は、ステップＪ、ＫおよびＬで示した位置データに封入して位置決定メッセージング（Ｐｏｓｉｔｉｏｎ  Ｄｅｔｅｒｍｉｎａｔｉｏｎ  Ｍｅｓｓａｇｉｎｇ）（ＰＤＭＥＳＳ）メッセージをＨ−ＬＣＳマネージャ３０６およびＶ−ＬＣＳマネージャ３０８を介して交換することによって、正確な測位手順を開始する。
【００５１】
重要なことには、測位手順それ自体は、例えばＲＲＬＰ、ＩＳ−８０１、あるいはＲＲＣベースのトランザクションであり得る。しかし、測位手順（例えばＲＲＬＰ、ＩＳ−８０１、あるいはＲＲＣ）プロトコルはＰＤＭＥＳＳメッセージでトンネル化され、ＰＤＭＥＳＳメッセージは汎用位置データ・メッセージでトンネル化され、この汎用データ・メッセージがＨ−ＬＣＳマネージャとＶ−ＬＣＳマネージャの間で送信される。
【００５２】
ステップＮ
測位サーバ３１０は、Ｒ／Ｈ／Ｖ−ＬＣＳマネージャ３０４、３０６、３０８に、対象ＵＥ  ３１２からの決定された位置情報を含む、位置報告（Ｐｏｓｉｔｉｏｎ  Ｒｅｐｏｒｔ）（ＰＲＰＴ）を送ることができる。
【００５３】
ステップＯ、Ｐ
位置報告（ＰＲＰＴ）から必要とされる位置推定値（ｐｏｓｉｔｉｏｎ  ｅｓｔｉｍａｔｅｓ）を受け取るとすぐに、在圏先ＬＣＳマネージャ３０８は、Ｌｒ応答メッセージを使って、契約先ＬＣＳマネージャ３０６にその位置推定値を送る。
【００５４】
ステップＱ
位置推定値が対象加入者のプライバシー設定により認められている場合、契約先ＬＣＳマネージャ３０６は要求元ＬＣＳマネージャ３０４にその位置推定値を送る。
【００５５】
ステップＲ
最後に、要求元ＬＣＳマネージャ３０４が、ＬＣＳエージェント３０２に、位置推定値を含むＭＬＰ  ＳＬＩＡメッセージを戻す。
【００５６】
図５には、本発明の原理による、ユーザ・プレーン位置情報サービスにおいてメッセージ・トンネリングによりローミングをサポートするための例示的なメッセージ・フローが示してあり、ここでは、在圏先ＬＣＳマネージャおよび在圏先測位サーバが１つのデバイスに統合されている。
【００５７】
ステップＡ
図４のステップＡに示すように、ＬＣＳエージェント３０２は、位置特定サービス対応アプリケーションから位置特定要求を受け取るとすぐに、そのアプリケーションの認証を行うことができる。認証が成功した場合、ＬＣＳエージェント３０２は、ＬＣＳエージェントが関連付けられている要求元ＬＣＳマネージャ３０４に、即時位置決定を求めるＭＬＰ位置特定要求を発行する。
【００５８】
ステップＢ
要求元ＬＣＳマネージャ３０４は、ＬＣＳエージェント３０２を認証し、受け取ったＩｃｓ−ｃｌｉｅｎｔ−ｉｄに基づいて、ＬＣＳエージェント３０２にそれが要求するサービスについての権限が与えられていることを確認する。
【００５９】
受け取った対象加入者のｍｓｉｄを検査することによって、Ｒ−ＬＣＳマネージャ３０４は、例えばローミング契約をもとに、あるいはＩＥＴＦ  ＲＦＣ  ２９１６と同様のドメイン・ネーム・サービス（ＤＮＳ）検索メカニズムを用いて、関連する契約先ＬＣＳマネージャ３０６を識別することができる。この関連する契約先ＬＣＳマネージャ３０６を識別するのに用いられるメカニズムは、当業者には公知である。
【００６０】
次いでＲ−ＬＣＳマネージャ３０４は、Ｌｒインターフェースを使って、対象加入者の契約先ＬＣＳマネージャ３０６に位置特定要求を送る。
【００６１】
ステップＣ
位置特定要求を受け取るとすぐに、契約先ＬＣＳマネージャ３０６は、加入者のプライバシーをその要求で受け取ったＩｃｓ−ｃｌｉｅｎｔ−ｉｄ、ｒｅｑｕｅｓｔｏｒ−ｉｄ、ｑｏｓなどに対して適用する。このユースケースでは、プライバシー・チェックは成功したものと仮定する。ＬＣＳマネージャ３０４がその適用を承認していない場合は、ステップＮに適用ＭＬＰ戻りコードが返される。
【００６２】
次いでＨ−ＬＣＳマネージャ３０６は、適切なＬＣＳ  ＩＮＩＴメッセージ、例えば無線アプリケーション・プロトコル（ＷＡＰ）のＰＵＳＨ、あるいはショート・メッセージ・システム（ＳＭＳ）のＴｒｉｇｇｅｒを用いて、ユーザ端末（ＵＥ）３１２の位置特定処理を開始し、タイマＴ１を始動する。
【００６３】
Ｈ−ＬＣＳマネージャ３０６がＵＥの概略位置を知っている場合、Ｈ−ＬＣＳマネージャ３０６は、任意選択で、この時点でＵＥにＵＥ概略位置情報を提供することができる。
【００６４】
ステップＢでのプライバシー・チェックの結果が対象加入者に対する通知または確認が必要であると示す場合、Ｈ−ＬＣＳマネージャ３０６はまた、ＬＣＳ  ＩＮＩＴメッセージに通知要素を含めることもできる。
【００６５】
ステップＤ
通知／確認が必要とされる場合、ＵＥのポップアップ・テキストを使って、加入者に、誰が加入者の位置情報、例えばＩｃｓ−ｃｌｉｅｎｔ−ｉｄ、ｒｅｑｕｅｓｔｏｒ−ｉｄ、ｒｅｑｕｅｓｔ−ｔｙｐｅなどを要求しているかを通知することができる。任意選択で、加入者がその位置特定要求を承諾することも、あるいはその位置特定要求を拒否することもできるようにすることもできる。
【００６６】
対象加入者が位置特定要求を承諾した場合、ＵＥ  ３１２は、現在サービスを実行しているセル情報、ＴＡ、ＮＭＲおよび移動体装置の諸機能を取得することによって測位手順を開始する。次いでＵＥ  ３１２は、セル情報と、ＵＥが補助データを取得する必要があり、かつ／またはＴＡおよびＮＭＲが利用可能である場合には任意選択のＡＤ、ＴＡおよびＮＭＲとを含む、位置特定開始要求（ＳＬＲＥＱ）を使って、Ｈ−ＬＣＳマネージャ３０６と位置特定セッションを開始する。任意選択で、ＵＥ  ３１２はまた、ＬＣＳ  ＩＮＩＴメッセージで確認が必要とされている場合、対象加入者がアクセスを認められているかどうかを示す。
【００６７】
対象加入者が位置特定要求を拒否した場合、ＵＥ  ３１２は、Ｈ−ＬＣＳマネージャ３０６に対して、拒否の表示を含む位置特定応答を開始する。
【００６８】
Ｈ−ＬＣＳマネージャ３０６は、対象加入者から未解決トランザクションについてのＳＬＲＥＱメッセージを受け取ると、タイマＴ１を止める。
【００６９】
ステップＥ
ステップＤで対象加入者が位置特定要求を拒否している場合、ステップＬに適用ＭＬＰ戻りコードが返される。この場合、ステップＥからＫは省略される。そうでない場合、Ｈ−ＬＣＳマネージャ３０６は、対象ＵＥ  ３１２から（または別のメカニズムを介して）のセル情報を使って、対象ＵＥ  ３１２がローミングしていると判定することができる。関連するローミング契約に基づいて、あるいはＩＥＴＦ  ＲＦＣ  ２９１６と同様のＤＮＳ検索メカニズムを用いて、Ｈ−ＬＣＳマネージャ３０６は在圏先ＬＣＳマネージャ３０８を識別することができ、在圏先ＬＣＳマネージャ３０８に対して、メッセージ・トンネリング・メカニズムがこの遷移に使用されることを表すインジケータを含むＬｒ要求を開始する。
【００７０】
ステップＦ
測位サーバ３１０および対象ＵＥ  ３１２は、位置データ・メッセージに封入した位置決定メッセージング（ＰＤＭＥＳＳ）メッセージをＨ−ＬＣＳマネージャ３０６およびＶ−ＬＣＳマネージャ３０８を介して交換することによって、正確な測位手順を開始する。
【００７１】
重要なことには、測位手順それ自体は、例えばＲＲＬＰ、ＩＳ−８０１、あるいはＲＲＣベースのトランザクションであり得る。しかし、測位手順（例えばＲＲＬＰ、ＩＳ−８０１、あるいはＲＲＣ）プロトコルはＰＤＭＥＳＳメッセージでトンネル化され、ＰＤＭＥＳＳメッセージは汎用位置データ・メッセージでトンネル化され、この汎用位置データがＨ−ＬＣＳマネージャとＶ−ＬＣＳマネージャの間で送信される。
【００７２】
ステップＧ
ステップＦで、要求された位置推定値を受け取るとすぐに、在圏先ＬＣＳマネージャ３０８は、Ｌｒ応答メッセージを使って、契約先ＬＣＳマネージャ３０６にその位置推定値を送る。
【００７３】
ステップＨ
位置推定値が対象加入者のプライバシー設定により認められている場合、契約先ＬＣＳマネージャ３０６は要求元ＬＣＳマネージャ３０４にその位置推定値を送る。
【００７４】
ステップＩ
最後に、要求元ＬＣＳマネージャ３０４が、ＬＣＳエージェント３０２に、位置推定値を含むＭＬＰ  ＳＬＩＡメッセージを戻す。
【００７５】
以上、本発明をその例示的な実施形態に則して説明してきたが、本発明の真の趣旨と範囲から逸脱することなく、当業者は本発明の上記で説明した実施形態にさまざまな変更を行うことができよう。
【図面の簡単な説明】
【００７６】
【図１】本発明の一実施形態による、例示的なユーザ・プレーン位置特定サービス・アーキテクチャを示す図である。
【図２】図１で示したユーザ・プレーン位置特定サービス取決めに基づく、例示的なユーザ・プレーン位置特定サービスのシグナリングを示す図である。
【図３】図１で示したユーザ・プレーン位置特定サービス取決めに基づく、メッセージ・トンネリング・メカニズムを使用する例示的な機能強化されたユーザ・プレーン位置特定サービスのシグナリングを示す図である。
【図４】本発明の原理による、ユーザ・プレーン位置情報サービスにおいてメッセージ・トンネリングによりローミングをサポートするための例示的なメッセージ・フローを示す図である。
【図５】本発明の原理による、在圏先ＬＣＳマネージャおよび在圏先測位サーバが１つのデバイスに統合されている、ユーザ・プレーン位置情報サービスにおいてメッセージ・トンネリングによりローミングをサポートするための例示的なメッセージ・フローを示す図である。
【図１】
2007513580.tif 000003
【図２】
2007513580.tif 000004
【図３】
2007513580.tif 000005
【図４】
2007513580.tif 000006
【図５】
2007513580.tif 000007
【国際調査報告】
2007513580.tif 000008