IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ スカイフック・ワイヤレス・インコーポレイテッドの特許一覧

特表2023-536054クラウドソーシングされるRTTに基づく測位
<>
  • 特表-クラウドソーシングされるRTTに基づく測位 図1
  • 特表-クラウドソーシングされるRTTに基づく測位 図2
  • 特表-クラウドソーシングされるRTTに基づく測位 図3
  • 特表-クラウドソーシングされるRTTに基づく測位 図4
  • 特表-クラウドソーシングされるRTTに基づく測位 図5
  • 特表-クラウドソーシングされるRTTに基づく測位 図6
  • 特表-クラウドソーシングされるRTTに基づく測位 図7
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2023-08-23
(54)【発明の名称】クラウドソーシングされるRTTに基づく測位
(51)【国際特許分類】
   G01S 5/14 20060101AFI20230816BHJP
【FI】
G01S5/14
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023502762
(86)(22)【出願日】2021-03-30
(85)【翻訳文提出日】2023-01-12
(86)【国際出願番号】 US2021024874
(87)【国際公開番号】W WO2022019965
(87)【国際公開日】2022-01-27
(31)【優先権主張番号】16/937,329
(32)【優先日】2020-07-23
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.BLUETOOTH
(71)【出願人】
【識別番号】523013570
【氏名又は名称】スカイフック・ワイヤレス・インコーポレイテッド
(74)【代理人】
【識別番号】100108453
【弁理士】
【氏名又は名称】村山 靖彦
(74)【代理人】
【識別番号】100163522
【弁理士】
【氏名又は名称】黒田 晋平
(72)【発明者】
【氏名】サイモン・イサコフ
(72)【発明者】
【氏名】ラリー・ヴイ・ドッズ
(72)【発明者】
【氏名】ロバート・ジェイ・アンダーソン
【テーマコード(参考)】
5J062
【Fターム(参考)】
5J062AA09
5J062CC07
5J062CC15
5J062FF01
(57)【要約】
様々な実施形態では、UEのRTTに基づく測位を可能にするために、クラウドソーシング技法が提供される。どのビーコン(たとえば、Wi-Fi AP、セルラー基地局、BLE送信機など)が(たとえば、IEEE 802.11mc、3GPP(登録商標)リリース16などによる)RTTの測定をサポートしているかを発見する問題に対処するために、ビーコンRTT能力が、UEからクラウドソーシングされ、クラウドベースのロケーションプラットフォームによってビーコンデータベース(またはより具体的には、それのRTTデータベース部分)において維持され得る。物理的アンテナ位置を決定するという問題に対処するために、RTT測定は、RTT対応であるそれらのビーコンに対してUEからクラウドソーシングされ、三辺測量アルゴリズム(たとえば、WLSマルチラテレーションアルゴリズム)によって使用されて、物理的アンテナ位置を決定してもよく、物理的アンテナ位置もまた、ビーコンデータベースに維持されてもよい。三辺測量の精度は、UEから生のGNSS測定値(たとえば、疑似距離)を取得し、UEに対してクラウドベースのRTK GNSS位置フィックスを行うことによって高められてもよい。
【特許請求の範囲】
【請求項1】
ラウンドトリップ時間(RTT)に基づく測位を可能にする方法であって、
ユーザ機器(UE)のワイヤレスネットワークインターフェースによって、前記UEの範囲内のビーコンをスキャンするステップと、
前記UEの範囲内の各ビーコンについてRTT能力が知られているかどうかを決定するために、クラウドベースのロケーションプラットフォームによって維持されるビーコンデータベースからの情報にアクセスするステップと、
未知のRTT能力を有する1つまたは複数のビーコンに対して、前記ビーコンにRTTを測定させようと試みるための範囲要求を送り、それに基づいて、前記ビーコンのRTT能力を示すRTT測定ステータスを前記ビーコンに割り当てるステップと、
前記ビーコンデータベースを更新するために、少なくとも前記RTT測定ステータスを前記クラウドベースのロケーションプラットフォームにアップロードするステップと
を含み、
前記UEが前記ビーコンデータベースからのビーコンのRTT能力に関する情報を消費することと、前記ビーコンデータベースにビーコンのRTT能力に関する情報を与えることの両方を行うようにする、方法。
【請求項2】
前記ビーコンがWi-Fiアクセスポイント(AP)であり、前記RTT能力が、米国電気電子技術者協会(IEEE)802.11mc規格に従ったファインタイミング測定(FTM)プロトコルへのサポートを含む、請求項1に記載の方法。
【請求項3】
前記ビーコンが、セルラー基地局であり、前記RTT能力が、第3世代パートナーシッププロジェクト(3GPP(登録商標))リリース16へのサポートを含み、前記RTTがマルチRTTである、請求項1に記載の方法。
【請求項4】
前記スキャンするステップが、前記UEの位置の決定を求める現在の要求に応じて行われる、請求項1に記載の方法。
【請求項5】
前記スキャンするステップが、前記UEの位置の決定を求める任意の現在の要求と無関係にバックグラウンドプロセスとして行われる、請求項1に記載の方法。
【請求項6】
前記UEの現在の位置を含む地理的エリアをカバーする前記ビーコンデータベースの一部分のローカルコピーをダウンロードするステップであって、前記ビーコンデータベースがビーコンをRTT対応、RTT非対応、または未知のRTT能力を有するとして識別する、ダウンロードするステップ
をさらに含み、
前記アクセスするステップが、前記UEの範囲内の各ビーコンを前記ローカルコピーに照らしてチェックするステップをさらに含む、請求項1に記載の方法。
【請求項7】
RTT対応である、または未知のRTT能力を有する前記UEの範囲内の各ビーコンを範囲リストに追加するステップをさらに含み、前記送るステップが、前記範囲リスト上の各ビーコンでRTTを測定しようと試みるための範囲要求を送る、請求項5に記載の方法。
【請求項8】
RTTに基づく測位を使用して、前記UEの位置を決定するステップ
をさらに含む、請求項1に記載の方法。
【請求項9】
前記RTT測定ステータスをローカルキャッシュに追加するステップ
をさらに含み、
前記アップロードするステップが、前記ビーコンデータベースに対する更新に含めるために、前記ローカルキャッシュのコンテンツを前記クラウドベースのロケーションプラットフォームに定期的に送るステップをさらに含む、請求項1に記載の方法。
【請求項10】
ラウンドトリップ時間(RTT)に基づく測位を可能にする方法であって、
クラウドベースのロケーションプラットフォームによって複数のユーザ機器(UE)に、ビーコンデータベースからのビーコンのRTT能力に関する情報を提供するステップであって、前記ビーコンの少なくとも1つが最初に未知のRTT能力を有する、提供するステップと、
前記クラウドベースのロケーションプラットフォームによって、最初に未知のRTT能力を有する前記ビーコンのうちのあるビーコンでRTTを測定しようと試みた前記複数のUEのうちの1つまたは複数からの少なくともRTT測定ステータスを含むRTT情報を受信するステップと、
前記受信したRTT測定ステータスに基づいて前記ビーコンのRTT能力を決定するステップと、
前記ビーコンの前記RTT能力を示す情報を含めるために前記ビーコンデータベースを更新するステップと
を含み、
前記クラウドベースのロケーションプラットフォームが、前記1つまたは複数のUEによって消費される前記ビーコンデータベースからのビーコンのRTT能力に関する情報を提供することと、前記1つまたは複数のUEからの前記ビーコンデータベースに与えられるビーコンのRTT能力に関する情報を受信することの両方を行うようにする、方法。
【請求項11】
前記ビーコンがWi-Fiアクセスポイント(AP)であり、前記RTT能力が、米国電気電子技術者協会(IEEE)802.11mc規格に従ったファインタイミング測定(FTM)プロトコルへのサポートを含む、請求項10に記載の方法。
【請求項12】
前記ビーコンが、セルラー基地局であり、前記RTT能力が、第3世代パートナーシッププロジェクト(3GPP(登録商標))リリース16へのサポートを含み、前記RTTがマルチRTTである、請求項10に記載の方法。
【請求項13】
前記決定するステップが、
前記1つまたは複数のUEのうちの少なくとも1つからの前記RTT測定ステータスが、前記UEが前記ビーコンにRTTを測定させることができたことを示す場合、前記ビーコンはRTT対応であるとし、前記1つまたは複数のUEのすべてからの前記RTT測定ステータスが、前記UEが前記ビーコンにRTTを測定させることができなかったことを示す場合、前記ビーコンをRTT非対応とし、前記1つまたは複数のUEのうちの少なくとも1つからの前記RTT測定ステータスが、前記UEがRTTを測定する範囲外であることを示し、前記1つまたは複数のUEのうちの他のすべてからの前記RTT測定ステータスが、前記UEが前記ビーコンにRTTを測定させることができなかったことを示す場合、前記ビーコンを未知のRTT能力を有するものとするステップ
を含む、請求項10に記載の方法。
【請求項14】
前記ビーコンがRTT対応であることを示す前記ビーコンの前記RTT能力に応じて、前記ビーコンによるRTT測定における予想される誤差を測定する前記ビーコンについてのRTTバイアスを推定するステップ
をさらに含み、
前記更新するステップが、前記ビーコンについての前記RTTバイアスを示す情報を、前記ビーコンデータベースに追加するステップを含む、請求項10に記載の方法。
【請求項15】
前記推定するステップが、
RTTに基づいて計算されたUEと前記ビーコンとの間の距離、ならびに前記UEの位置の決定された位置および前記ビーコンの推定される位置に基づいて計算された前記UEと前記ビーコンとの間の距離についてデルタを計算し、前記デルタに基づいて前記ビーコンの前記RTTバイアスを決定するステップ
を含む、請求項14に記載の方法。
【請求項16】
前記推定するステップが、
前記ビーコンと共通の組織識別子を共有する1つまたは複数の他のビーコンを決定するステップと、
前記1つまたは複数の他のビーコンのRTTバイアスに基づいて前記ビーコンの前記RTTバイアスを決定するステップと
を含む、請求項14に記載の方法。
【請求項17】
前記ビーコンがRTT対応であることを示す前記ビーコンの前記RTT能力に応じて、RTTに基づいて計算されたUEと前記ビーコンとの間の距離が、前記UEの決定された位置と一致しているかどうかを決定し、前記距離が一致していない場合、前記RTT能力を更新するステップ
をさらに含む、請求項10に記載の方法。
【請求項18】
前記複数のUEからのRTT測定値を使用する三辺測量アルゴリズムによって、前記ビーコンの物理的アンテナ位置を決定するステップ
をさらに含み、
前記更新するステップが、前記ビーコンの前記物理的アンテナ位置を前記ビーコンデータベースに追加するステップを含む、請求項10に記載の方法。
【請求項19】
RTT能力を決定し、前記ビーコンデータベースを更新する前記ステップが、バッチ期間に従って定期的に行われる、請求項10に記載の方法。
【請求項20】
ラウンドトリップ時間(RTT)に基づく測位を可能にする方法であって、
ビーコンデータベースを維持するクラウドベースのロケーションプラットフォームによって、ビーコンを観測した複数のユーザ機器(UE)からの観測を受信するステップであって、前記観測が、前記UEの少なくとも決定された位置および前記ビーコンによる前記UEについてのRTT測定値を含む、受信するステップと、
前記複数のUEの各々の前記決定された位置および前記RTT測定値に基づいて、前記ビーコンの物理的アンテナ位置を決定するために、前記クラウドベースのロケーションプラットフォームによって、三辺測量アルゴリズムを使用するステップと、
前記ビーコンの前記決定された物理的アンテナ位置を含めるために前記ビーコンデータベースを更新するステップと

前記クラウドベースのロケーションプラットフォームによって、前記ビーコンの前記物理的アンテナ位置を、前記複数のUEのうちの1つまたは複数に提供するステップと
を含み、
前記1つまたは複数のUEが、前記ビーコンデータベースを構築するために、前記ビーコンの物理的アンテナ位置を決定するために使用される情報を与えることと、前記ビーコンデータベースからの前記ビーコンの物理的アンテナ位置を消費することの両方を行うようにする、方法。
【請求項21】
前記ビーコンがWi-Fiアクセスポイント(AP)であり、RTT能力が、米国電気電子技術者協会(IEEE)802.11mc規格に従ったファインタイミング測定(FTM)プロトコルへのサポートを含む、請求項20に記載の方法。
【請求項22】
前記ビーコンが、セルラー基地局であり、RTT能力が、第3世代パートナーシッププロジェクト(3GPP(登録商標))リリース16へのサポートを含み、前記RTTがマルチRTTである、請求項20に記載の方法。
【請求項23】
前記UEの前記決定された位置が、前記決定された位置の位置信頼度を含み、前記方法が、
前記UEの前記決定された位置の前記位置信頼度のしきい値との比較に基づいて観測をフィルタリングするステップ
をさらに含む、請求項20に記載の方法。
【請求項24】
前記三辺測量アルゴリズムによる前記決定が、決定された位置の前記位置信頼度にさらに基づく、請求項23に記載の方法。
【請求項25】
前記複数のUEからのRTT情報が、RTT測定不確実性、RTT測定と関連する信号強度、およびRTT測定と関連する帯域幅を含み、前記三辺測量アルゴリズムによる前記決定が、前記複数のUEについての前記RTT測定不確実性、前記信号強度、および前記帯域幅にさらに基づく、請求項20に記載の方法。
【請求項26】
前記三辺測量アルゴリズムが、加重最小二乗(WLS)マルチラテレーションアルゴリズムである、請求項20に記載の方法。
【請求項27】
前記UEの位置を記述する前記情報が、前記UEについての生の全地球航法衛星システム(GNSS)測定値を含み、前記方法が、
前記クラウドベースのロケーションプラットフォームによってリアルタイムキネマティック(RTK)補正サービスから、各UEの前記生のGNSS測定値についてのRTK補正情報を取得するステップと、
前記クラウドベースのロケーションプラットフォームによって、前記生のGNSS測定値および前記RTK補正情報を使用して、各UEに対して補正されたGNSS位置フィックスを決定するステップと
をさらに含み、
前記三辺測量アルゴリズムによって使用される前記位置および前記RTTを記述する前記情報が、各UEに対しての前記補正されたGNSS位置フィックスを含む、請求項20に記載の方法。
【請求項28】
前記複数のUEに対して前記補正されたGNSS位置フィックスの水平測位誤差(HPE)を決定するステップ
をさらに含み、
前記三辺測量アルゴリズムによる前記決定が、前記複数のUEに対しての前記補正されたGNSS位置フィックスの前記HPEにさらに基づく、請求項27に記載の方法。
【請求項29】
ソフトウェアがその上に記憶された非一時的電子デバイス可読媒体であって、前記ソフトウェアが、1つまたは複数の電子デバイスの1つまたは複数のプロセッサ上で実行されると、
最初に未知のRTT能力を有するビーコンでRTTを測定しようと試みた複数のユーザ機器(UE)からラウンドドリップ時間(RTT)測定値を受信することと、
前記ビーコンがRTT対応であること、および前記複数のUEからの前記RTT測定値に基づく前記ビーコンの位置を決定することと、
前記ビーコンがRTT対応であること、および前記ビーコンの前記決定された位置を示す情報を含めるためにビーコンデータベースを更新することと、
前記ビーコンがRTT対応であるという表示、および前記ビーコンの前記決定された位置を含む情報を少なくとも1つのUEに、前記UEの位置を推定するために使用可能な地理的エリアについてのビーコン情報のセットの一部として提供することと
を行うように動作可能である、非一時的電子デバイス可読媒体。
【請求項30】
前記ビーコンがWi-Fiアクセスポイント(AP)であり、ビーコンが、米国電気電子技術者協会(IEEE)802.11mc規格に従ったファインタイミング測定(FTM)プロトコルをサポートしているとき、RTT対応である、請求項29に記載の非一時的電子デバイス可読媒体。
【請求項31】
前記ビーコンが、セルラー基地局であり、前記RTT能力が、第3世代パートナーシッププロジェクト(3GPP(登録商標))リリース16へのサポートを含み、前記RTTがマルチRTTである、請求項29に記載の非一時的電子デバイス可読媒体。
【請求項32】
前記ビーコンが、前記複数のUEのうちの少なくとも1つが前記ビーコンにRTTを測定させることができたことに応じて、RTT対応であると決定される、請求項29に記載の非一時的電子デバイス可読媒体。
【請求項33】
前記ソフトウェアが、
前記ビーコンによるRTT測定における予想される誤差を測定する前記ビーコンについてRTTバイアスを推定することと、
前記ビーコンについての前記RTTバイアスを示す情報を前記ビーコンデータベースに追加することと
を行うようにさらに動作可能である、請求項29に記載の非一時的電子デバイス可読媒体。
【請求項34】
前記ソフトウェアが、
RTTに基づいて計算された各UEと前記ビーコンとの間の距離が、前記UEの決定された位置と一致していると決定する
ようにさらに動作可能である、請求項29に記載の非一時的電子デバイス可読媒体。
【請求項35】
前記ソフトウェアが、
前記複数のUEからのRTT測定値を使用する三辺測量アルゴリズムによって、前記ビーコンの物理的アンテナ位置を決定することと、
前記ビーコンの前記物理的アンテナ位置を前記ビーコンデータベースに追加することと
を行うようにさらに動作可能である、請求項29に記載の非一時的電子デバイス可読媒体。
【請求項36】
ソフトウェアがその上に記憶された非一時的電子デバイス可読媒体であって、前記ソフトウェアが、1つまたは複数の電子デバイスの1つまたは複数のプロセッサ上で実行されると、
ビーコンを観測した複数のユーザ機器(UE)から、少なくとも前記UEについての生の全地球航法衛星システム(GNSS)測定値および前記ビーコンによる前記UEについてのRTT測定値を含む、情報を受信することと、
リアルタイムキネマティック(RTK)補正サービスから、各UEの前記生のGNSS測定値についてのRTK補正情報を取得することと、
前記生のGNSS測定値および前記RTK補正情報を使用して、各UEに対して補正されたGNSS位置フィックスを決定することと、
前記補正されたGNSS位置フィックスおよび前記複数のUEの各々の前記RTT測定値に基づいて、前記ビーコンの位置を決定することと、
前記ビーコンの前記決定された物理的アンテナ位置を含めるためにビーコンデータベースを更新することと、
前記ビーコンの前記物理的アンテナ位置を、前記複数のUEのうちの1つまたは複数に提供することと
を行うように動作可能である、非一時的電子デバイス可読媒体。
【請求項37】
前記ビーコンがWi-Fiアクセスポイント(AP)であり、ビーコンが、米国電気電子技術者協会(IEEE)802.11mc規格に従ったファインタイミング測定(FTM)プロトコルをサポートしているとき、RTT対応である、請求項36に記載の非一時的電子デバイス可読媒体。
【請求項38】
前記ビーコンが、セルラー基地局であり、RTT能力が、第3世代パートナーシッププロジェクト(3GPP(登録商標))リリース16へのサポートを含み、前記RTTがマルチRTTである、請求項36に記載の非一時的電子デバイス可読媒体。
【請求項39】
前記ソフトウェアが、実行されると、
前記複数のUEに対して前記補正されたGNSS位置フィックスの水平測位誤差(HPE)を決定するようにさらに動作可能であり、
前記ビーコンの位置決定が、前記複数のUEに対する前記補正されたGNSS位置フィックスの前記HPEに少なくとも部分的に基づいている三辺測量アルゴリズムを使用する、請求項36に記載の非一時的電子デバイス可読媒体。
【請求項40】
三辺測量アルゴリズムが、加重最小二乗(WLS)マルチラテレーションアルゴリズムである、請求項36に記載の非一時的電子デバイス可読媒体。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、一般にユーザ機器(UE)測位に関し、より詳細にはUEのラウンドトリップ時間(RTT)に基づく測位を可能にするクラウドソーシング技法に関する。
【背景技術】
【0002】
UE位置の決定は、ユーザの追跡、プロファイルの管理、ロケーションベースサービスの提供、および他のタスクのためにますます重要になっている。UE位置を決定するためのいくつかの技法は、受信信号強度(RSS)測定を含んでいる。たとえば、複数のビーコン(たとえば、Wi-Fiアクセスポイント(AP)、セルラー基地局、Bluetooth低エネルギー(BLE)送信機など)からUEで受信される信号のRSS測定の三角測量が行われる場合がある。しかしながら、RSSに基づく技法は、高精度のUE位置の決定に困難を伴う場合がある。
【0003】
UE位置の決定にRTT測定を利用することによって、精度の改善が可能である場合がある。一般に、RTTは、開始信号の送信と、対応する応答信号の受信との間に経過する時間である。RTTからターンアラウンド時間を引き、結果を2で割ることによって、飛行時間(Time-of-flight:ToF)を取得することができる。ToFから、UEとビーコンとの間の距離(範囲)が、容易に決定され得る。複数のビーコンまでの距離に基づいて、UEの位置は、たとえば三辺測量により決定され得る。
【0004】
米国電気電子技術者協会(IEEE)802.11mc規格で導入されたファインタイミング測定(FTM)プロトコルなどの様々な新しいプロトコル、ならびに第3世代パートナーシッププロジェクト(3GPP(登録商標))リリース16技術仕様(TS)シリーズ37および38で導入されたプロトコルが、RTTの高精度の測定を可能にする。FTMプロトコルをサポートしているWi-Fi APを用いて、FTMフレームおよびそれらのそれぞれの確認応答の出発および到着時に捕捉されるタイムスタンプからRTTが測定され得る。3GPP(登録商標)リリース16をサポートしているセルラー基地局を用いて、マルチRTTと呼ばれるRTTの特定のサブタイプが測定され得る。
【0005】
UEは、どのビーコンがRTTの測定をサポートしているかを発見するために様々な機構を使用し得る。たとえば、FTMプロトコルは、どのWi-Fi APがRTT測定をサポートしているかを発見するための2つの機構、すなわち広告フレームおよび範囲要求を提供する。広告フレームを用いて、Wi-Fi APが、それのRTT能力をUEに広告するためのフレームを定期的にブロードキャストする。範囲要求を用いて、UEは、Wi-Fi APへのピアリンクを確立し、それを用いてWi-Fi APにRTTを測定させようと試み、要求フレームを送信し、応答フレームのバーストを受信するのを待ち、これに確認応答で応答する。広告フレームまたは範囲要求のいずれかで、拡張能力要素(たとえば、広告フレームまたは初期応答フレームに含まれる)が、バースト継続時間、バーストあたりのFTMフレーム、帯域幅、連続するFTMフレーム間の最小時間などの、FTMセッションのスケジューリングおよび動作詳細に関する情報を提供し得る。同様に、3GPP(登録商標)リリース16は、どのセルラー基地局がRTTをサポートしているかを発見するためのそれ独自の機構を提供する。
【0006】
RTTを使用すると、UE位置決定の精度を向上させる可能性があるが、いくつかの障害が、RTTに基づく測位の広範囲の展開を妨げている。第1に、どのビーコンがRTTの測定をサポートしているかを決定することは、しばしばエラーを起こしやすく、運用上(時間、プロセッササイクル、メモリ空間、ネットワーク帯域幅、および電力の観点から)費用がかかる。いくつかのビーコンは、単にRTTの測定をサポートしている機能がない場合がある(たとえば、それらのビーコンはより古いプロトコルおよび規格しかサポートしていない)。他のビーコンは、機能を含む場合がある(たとえば、それらのチップセットは適用可能なプロトコルおよび規格をサポートしている)が、それらのビーコンは様々な理由でそれらのRTT能力を広告しない。たとえば、FTMプロトコルでは、展開されているWi-Fi APのほんの少数が、現在、IEEE 802.11mc規格およびFTMプロトコルをサポートしている。その少数のうち、いくつかのWi-Fi APは、FTMプロトコルをサポートしているそれらの能力を広告しない。どのWi-Fi APがFTMプロトコルをサポートしているかを知ることに関心があるUEは、一般に2つの最適ではないオプションを有し、すなわち、UEは広告を頼りにし、したがってそれらの能力を広告しないWi-Fi APを見逃す可能性があるか、またはUEは、各近隣のWi-Fi APに対してピアリンクを確立し、要求フレームを送り、したがって著しい時間、プロッササイクル、メモリ空間、ネットワーク帯域幅、および電力を消費する可能性がある。密な市街地では、数十、さらには数百の近隣のWi-Fi APがある場合があり、すべてのUEにすべての近隣のWi-Fi APに対してピアリンクを確立させ、要求フレームを送らせると、単純に運用上費用がかかりすぎて実用的ではない。
【0007】
第2に、RTTに基づく測位のための恩恵を十分に実感できる精度のレベルまで物理的アンテナ位置を決定することは困難である場合がある。RTTに基づく測位は、一般に、それの十分な恩恵を実感するには高度に正確な物理的アンテナ位置(たとえば、1メートル以内)を必要とする。そのような物理的アンテナ位置を取得する1つの方法は、専用の測量によるものである。たとえば、高精度のハードウェアを含むWi-Fi測量システムまたは車両が、場所を横断し、Wi-Fi APの物理的アンテナ位置の地図を作成し得る。そのような手法によって決定された物理的アンテナ位置は正確であり得るが、それは極めて時間がかかり、費用を要するものである。代替手法は、他の測位技法からすでに知られている場合があるビーコンのカバレージエリアに基づいて、物理的アンテナ位置を概算することである。たとえば、Wi-Fi APの物理的アンテナ位置は、Wi-Fi APのカバレージの図心として概算され得る。しかしながら、そのような手法は、一般にあまり正確ではない。カバレージの図心は、信号伝搬バイアス、観測バイアス、および他の要因により、しばしば物理的アンテナ位置からそれる。
【発明の概要】
【発明が解決しようとする課題】
【0008】
したがって、UEのRTTに基づく測位の広範囲の展開を妨げているこれらのおよび/または他の問題に対処することができる改善された技法が必要とされる。
【課題を解決するための手段】
【0009】
様々な実施形態では、UEのRTTに基づく測位を可能にするために、クラウドソーシング技法が提供される。どのビーコン(たとえば、Wi-Fi AP、セルラー基地局、BLE送信機など)が(たとえば、IEEE 802.11mc、3GPP(登録商標)リリース16などによる)RTTの測定をサポートしているかを発見する問題に対処するために、ビーコンRTT能力が、UEからクラウドソーシングされ、クラウドベースのロケーションプラットフォームによってビーコンデータベース(またはより具体的には、それのRTTデータベース部分)に維持され得る。物理的アンテナ位置を決定するという問題に対処するために、RTT測定は、RTT対応であるビーコンに対してUEからクラウドソーシングされ、三辺測量アルゴリズム(たとえば、加重最小二乗(WLS)マルチラテレーションアルゴリズム)によって使用されて、物理的アンテナ位置を決定してもよく、物理的アンテナ位置もまた、ビーコンデータベースに維持されてもよい。三辺測量の精度は、生の全地球航法衛星システム(GNSS)測定値(たとえば、疑似距離)をUEから取得し、UEに対してクラウドベースのリアルタイムキネマティック(RTK)GNSS位置フィックスを行うことによって高められ得る。
【0010】
一実施形態では、ビーコンRTT能力をクラウドソーシングするために、UE上の測位クライアントが使用される。UEは、UEの範囲内のビーコンをスキャンするために、ワイヤレスネットワークインターフェースを使用する。UEは、クラウドベースのロケーションプラットフォームによって維持されているビーコンデータベースからの情報にアクセスして、範囲内の各ビーコンについてRTT能力が知られているかどうかを決定する。未知のRTT能力を有する1つまたは複数のビーコンに対して、UEは、ビーコンにRTTを測定させようと試みるための範囲要求を送り、それに基づいて、ビーコンのRTT能力を示すRTT測定ステータスをビーコンに割り当てる。UEは次いで、少なくともRTT測定ステータスをクラウドベースのロケーションプラットフォームにアップロードして、ビーコンデータベースを更新する。そのような実施形態では、UEは、ビーコンデータベースからのビーコンのRTT能力に関する情報を消費することと、ビーコンデータベースにビーコンのRTT能力に関する情報を与えることの両方を行う。
【0011】
別の実施形態では、ビーコンRTT能力をクラウドソーシングするために、クラウドベースのロケーションプラットフォームが使用される。クラウドベースのロケーションプラットフォームは、複数のUEに、ビーコンデータベースからビーコンのRTT能力に関する情報を提供する。ビーコンの少なくとも1つが、最初は未知のRTT能力を有する。クラウドベースのロケーションプラットフォームは後に、最初に未知のRTT能力を有するビーコンでRTTを測定しようと試みた複数のUEのうちの1つまたは複数から、少なくともRTT測定ステータスを含むRTT情報を受信する。ビーコンのRTT能力は、受信したRTT測定ステータスに基づいて決定され、ビーコンデータベースは、ビーコンのRTT能力を示す情報を含めるために更新される。そのような実施形態では、この動作は、UEがビーコンデータベースからのビーコンのRTT能力に関する情報を消費することと、ビーコンデータベースにビーコンのRTT能力に関する情報を与えることの両方を行うことを可能にする。
【0012】
また別の実施形態では、クラウドベースのロケーションプラットフォームが、ビーコン位置、またはより具体的にはビーコンの物理的アンテナ位置を、クラウドソーシングされたデータに基づいて決定する。クラウドベースのロケーションプラットフォームは、ビーコンを観測した複数のUEからの観測を受信し、観測は、少なくともUEの決定された位置、およびビーコンによるUEについてのRTT測定値を含む。クラウドベースのロケーションプラットフォームは、複数のUEの各々について決定された位置およびRTT測定に基づいて、ビーコンの物理的アンテナ位置を決定するために、三辺測量アルゴリズムを使用する。クラウドベースのロケーションプラットフォームは、ビーコンの決定された物理的アンテナ位置を含めるためにビーコンデータベースを更新し、複数のUEのうちの1つまたは複数にビーコンの物理的アンテナ位置を提供する。そのような実施形態では、この動作は、UEがビーコンデータベースを構築するために、ビーコンの物理的アンテナ位置を決定するために使用される情報を与えることと、ビーコンデータベースからのビーコンの物理的アンテナ位置を消費することの両方を行うことを可能にする。
【0013】
さらに別の実施形態では、クラウドベースのロケーションプラットフォームが、ビーコン位置、またはより具体的にはビーコンの物理的アンテナ位置を、クラウドソーシングされたデータに基づいて決定し、そのような決定の精度は、UE位置に対してクラウドベースのRTK GNSS位置フィックスを使用して改善される。クラウドベースのロケーションプラットフォームは、少なくともUEについての生のGNSS測定値およびUEについてのRTT測定値を含む、ビーコンを観測した複数のUEからの情報を受信する。クラウドベースのロケーションプラットフォームはまた、生のGSNN測定値について補正サービスからRTK補正情報を取得する。クラウドベースのロケーションプラットフォームは、生のGNSS測定値およびRTK補正情報を使用して、各UEに対して補正されたGNSS位置フィックスを決定する。したがって、クラウドベースのロケーションプラットフォームは、補正されたGNSS位置フィックスおよびRTT測定値に基づいてビーコンの位置を決定するために、三辺測量アルゴリズムを使用し、ビーコンの決定された物理的アンテナ位置を含めるためにビーコンデータベースを更新する。クラウドベースのロケーションプラットフォームは次いで、ビーコンの物理的アンテナ位置を複数のUEのうちの1つまたは複数に提供する。
【0014】
本発明の概要で説明する実施形態は、以下で説明する他の特徴、およびそれらの変形を含む、様々な他の特徴を含む場合があることを理解されたい。さらに、様々な他の実施形態は、本明細書および以下で説明する特徴、ならびにそれらの変形の様々な組合せを含んで利用され得る。本発明の概要は、単に読者への短い導入となることを目的とし、本明細書で言及する特定の特徴が本発明のすべての特徴である、または本発明の本質的な特徴であるという意味を含まない。
【0015】
以下の説明は、添付の図面を参照する。
【図面の簡単な説明】
【0016】
図1】UEのRTTに基づく測位を可能にする技法が展開され得る例示的なアーキテクチャのブロック図である。
図2】ビーコンRTT能力をクラウドソーシングするためにUE上で測位クライアントの管理下で行われる例示的な動作を詳述する流れ図である。
図3】ビーコンRTT能力をクラウドソーシングするためにクラウドベースのロケーションプラットフォームによって行われる例示的な動作を詳述する流れ図である。
図4】UEからクラウドソーシングされたRTT測定値を使用して、ビーコン位置またはより具体的にはビーコンの物理的アンテナ位置を決定するためにクラウドベースのロケーションプラットフォームによって行われる例示的な動作を詳述する流れ図である。
図5】HPEおよび位置決定の精度の印としてのHPEの使用を示すUEの例示的な配置の図である。
図6】クラウドベースのRTK GNSS位置フィックスを使用して、ビーコン位置またはより具体的にはビーコンの物理的アンテナ位置を決定するために「オフボード」実装においてクラウドベースのロケーションプラットフォームによって行われる例示的な動作を詳述する流れ図である。
図7】UE位置を決定するためにハイブリッドRTTに基づく測位アルゴリズムを実装するようにUE上で測位クライアントによって行われる例示的な動作を詳述する流れ図である。
【発明を実施するための形態】
【0017】
図1は、UEのRTTに基づく測位を可能にする技法が展開され得る例示的なアーキテクチャ100のブロック図である。本明細書で使用する「ユーザ機器」または「UE」という用語は、エンドユーザによって操作されるモバイルデバイス、マシンツーマシン(M2M)デバイス、またはモノのインターネット(IoT)デバイスを指す。UE 110の例には、特に、エンドユーザによって操作されるスマートフォン、スマートウォッチ、コンピュータ、カメラ、およびセンサーが含まれる。同様に、本明細書で使用する「ビーコン」という用語は、UEの位置を決定するために使用され得る信号を交換する固定位置を有するデバイスを指す。ビーコン140の例には、デバイスの中でもWi-Fi AP、セルラー基地局、BLE送信機が含まれる。さらに、本明細書で使用する「RTT能力」という用語は、一般にRTT(またはマルチRTTなど、それのサブタイプ)を測定し、測定されたRTTを他のデバイスに提供するビーコンの能力を指す。RTT能力は、IEEE 802.11mc規格のFTMプロトコル、3GPP(登録商標)リリース16 TSシリーズ37および38、または他のプロトコルおよび規格に従ってもよい。またさらに、本明細書で使用する「RTT測定ステータス」という用語は、特定の測定RTT測定を行うためのビーコンの能力を指す。RTT測定ステータスは、IEEE 802.11mc規格のFTMプロトコル、3GPP(登録商標)リリース16 TSシリーズ37および38、または他のプロトコルおよび規格に従ってもよい。
【0018】
UE 110は一般に、いくつかの他の構成要素のうち、中央処理装置(CPU)115と、測位クライアント122を含むアプリケーションソフトウェアを維持するストレージ120(たとえば、揮発性および不揮発性メモリ)と、1つまたは複数のワイヤレスネットワークインターフェース125(たとえば、IEEE 802.11規格に従って動作するWi-Fiインターフェース、3GPP(登録商標)リリース16 TSシリーズ37および38に従って動作するセルラー無線、ならびに/または別のタイプのワイヤレスインターフェース)と、衛星信号を受信するGNSS受信機130とを含む。
【0019】
測位クライアント122は一般に、UE 110の範囲内のビーコン140(たとえば、Wi-Fi AP、セルラー基地局、BLE送信機など)をスキャンし、それの特性を決定するために、ワイヤレスネットワークインターフェースを利用する。これらの特性は、UE 110の位置を決定するために、ビーコン情報のローカルコピーと併せて使用され得る。同様に、測位クライアント122は、衛星からの生のGNSS測定値(たとえば、疑似距離)を捕捉するために、GNSS受信機130を利用し得る。生のGNSS測定値は、UEの位置を決定するためにも使用され得る(すなわち、GNSS位置フィックス)。
【0020】
UE 110は、インターネット150およびクラウドベースのロケーションプラットフォーム160までのWi-Fiまたはセルラーデータ通信路を介して通信し得る。機能の中でも、ロケーションプラットフォーム160は、一般にビーコンデータベース170を維持する。ビーコンデータベース170の一部分が、RTTデータベース175として設計され、ビーコンの識別子(たとえば、メディアアクセス制御(MAC)アドレス、セル識別子(ID)など)を、ビーコンのRTT能力(たとえば、RTT対応、RTT非対応、または未知のRTT能力を有する)、RTTバイアス、ビーコンの物理的アンテナ位置、位置不確実性などの、様々なRTTに関係する情報に関係付けてもよい。特定の地理的エリア(たとえば、タイル)をカバーする(RTTデータベース175を含む)ビーコンデータベースの部分が、ローカルコピーとして使用するために、測位クライアント122によってUE 110にダウンロードされてもよい。さらに、UE 110によって行われたスキャンから導出された情報(たとえば、UEの決定された位置、ビーコン識別情報、RTT測定ステータス、RTT測定値など)が、(RTTデータベース175を含む)ビーコンデータベース170の更新に情報を使用するクラウドベースのロケーションプラットフォーム160に定期的にアップロードされてもよい。
【0021】
図2は、ビーコンRTT能力をクラウドソーシングするためにUE 110上で測位クライアント122の指示下で行われる例示的な動作200を詳述する流れ図である。ステップ210において、測位クライアント122は、UEの範囲内のビーコン140を発見するためのスキャンを行うために、UE 110のワイヤレスネットワークインターフェース125を使用する。スキャンは、(たとえば、UE 110上で実行中のアプリケーションのためにUE位置を計算することを求める現在の要求に応答する)アクティブスキャンであってもよく、またはバックグラウンドスキャン(たとえば、UEの位置を決定することを求める現在の要求がないバックグラウンド動作)であってもよい。ステップ215において、地理的エリア(たとえば、タイル)をカバーするビーコンデータベース170の一部分のローカルコピーを利用する実装形態のために、測位クライアント122は、UE 110が、UE 110の現在の位置を含む地理的エリアをカバーするビーコンデータベース170の一部分(たとえば、タイル)のローカルコピーを記憶しているかどうかをチェックする。そうでない場合、ステップ220において、測位クライアント122は、クラウドベースのロケーションプラットフォーム160からローカルコピー(たとえば、タイル)をダウンロードする。これは、UEが新しい地理的エリアに入るたびに、または以前にダウンロードされたローカルコピー(たとえば、タイル)が古くなったとき、行われ得る。いくつかの実装形態は、ローカルコピー(たとえば、タイル)を使用しないことがあり、そのような場合、ステップ215~ステップ220は省略され得ることを理解されたい。
【0022】
ステップ225において、測位クライアント122は、UE 110の範囲内の各ビーコン140を通してループし、ステップ230において、RTT能力がすでに知られているかどうかを決定するためにチェックする。ローカルコピー(たとえば、タイル)を使用する一実施形態では、これは、ローカルコピー(たとえば、タイル)内のビーコンの識別情報をチェックすることを含んでもよい。代替的にこれは、クラウドベースのロケーションプラットフォーム160に照会することを含んでもよい。RTT能力は、RTT対応(すなわち、いくつかの他のUEが過去にビーコンにRTTを測定させることができたことを示す状態)、RTT非対応(すなわち、他のUEが過去にビーコンにRTTを測定させようとしたがいずれもできなかったことを示す状態)、または未知のRTT能力を有すること(すなわち、過去にRTTを測定しようとしたUEがないことを示す状態)を含む、いくつかの状態を有し得る。ステップ235において、RTT対応であるまたは未知のRTT能力を有すると示されたUE 110の範囲内の各ビーコン140について、測位クライアント122は、範囲要求を受信するように示された範囲リスト(すなわち、識別子(たとえば、MACアドレス、セルIDなど)のリスト)にビーコンを追加する。
【0023】
ステップ240において、測位クライアント122は、範囲リスト上の各ビーコン140を通してループし、ステップ245において、ワイヤレスネットワークインターフェース125に範囲要求(たとえば、IEEE 802.11mc規格に従ったFTMプロトコル範囲要求、または別の規格に従った要求)を送らせて、それとともにビーコン140にRTTを測定させるように試みる。ステップ250において、測位クライアント122は、ビーコン140にビーコンのRTT能力を示すRTT測定ステータスを割り当てる。割り当てられたRTT測定ステータスは、ビーコンが、RTT対応(すなわち、ビーコンはRTTを測定し、返すことができた)、RTT非対応(すなわち、ビーコンはRTTを測定し、返すことができなかった)、またはRTT範囲外である(すなわち、ビーコンはRTTを測定することができなかったが、ビーコンは範囲外の表示を返し、範囲がより小さい場合、ビーコンはRTTを測定し、返すことができる可能性がある)ことを示し得る。
【0024】
ステップ255において、測位クライアント122は、UE 110の位置を決定する。決定は、GNSSに基づいてもよく、決定された位置は、GNSS位置フィックスであるようにする。代替または追加として、決定は、RTTに基づく測位を利用してもよい。そのようなRTTに基づく測位は、以下でより詳細に説明するように、RTTに基づくWLS測位アルゴリズムと拡張カルマン測位アルゴリズム(Extended Kalman positioning algorithm)を組み合わせたハイブリッド測位アルゴリズムを利用してもよい。UE 110の決定された位置について、位置信頼度(たとえば、推定水平位置誤差(HPE))が計算されてもよい。
【0025】
ステップ260において、キャッシングを利用する実装形態では、測位クライアント122は、範囲内のビーコンについてのRTT情報を、UE 110上の測位クライアント122のローカルキャッシュに追加する。RTT情報は、UEの決定された位置(および、場合によっては位置信頼度)、ならびに各ビーコンについて、ビーコンの識別子(たとえば、MACアドレス、セルIDなど)、RTT測定ステータス(たとえば、RTT対応、RTT非対応、またはRTT範囲外)、および利用可能な場合は、RTT測定値を含み得る。ステップ265において、測位クライアント122は、キャッシュアップロードトリガに到達したかどうかを決定する。トリガは、ローカルキャッシュがいっぱいになること、ある量の時間が満了すること、または定期的に満たされる何らかの他の基準であってもよい。トリガに到達する場合、ステップ270において、測位クライアント122は、ビーコンデータベース170(またはより具体的には、それのRTTデータベース175)の更新に含めるために、ローカルキャッシュのコンテンツをクラウドベースのロケーションプラットフォーム160にアップロードする。いくつかの実装形態は、キャッシングを使用しないことがあり、その場合、ステップ260~ステップ265は省略されてもよく、ステップ270のアップロードは、ビーコンについての新しいRTT情報があると直ちに開始されることを理解されたい。最後に、任意選択のステップ275において、測位クライアント122は、(たとえば、最初のスキャンがアクティブスキャンであった場合)UEの決定された位置を他のアプリケーションソフトウェアに報告する。
【0026】
図3は、ビーコンRTT能力をクラウドソーシングするためにクラウドベースのロケーションプラットフォーム160によって行われる例示的な動作300を詳述する流れ図である。この動作は、ビーコンデータベース170(およびそれのRTTデータベース175)を構築するために多数のUE 110によって発見された情報を集約し得る。ステップ310において、クラウドベースのロケーションプラットフォーム160は、UE 110からの受信したRTT情報をバッチ処理する。
【0027】
上記で説明したように、RTT情報は、UEの決定された位置、およびUEの範囲内の各ビーコン140について、ビーコンの識別子(たとえば、MACアドレス、セルIDなど)、RTT測定ステータス(たとえば、RTT対応、RTT非対応、またはRTT範囲外)、および利用可能な場合は、RTT測定値を含み得る。
【0028】
ステップ320において、バッチが更新する実装形態では、クラウドベースのロケーションプラットフォーム160は、バッチ期間に到達したと決定する。バッチ期間は、ビーコンデータベース170におけるビーコン140のRTT能力が更新される時間期間(たとえば、1カ月に1回)、または非時間ベースのトリガであってもよい。いくつかの実装形態は、バッチ処理を使用しないことがあり、その場合ステップ320は省略されてもよく、動作がリアルタイムで開始されることを理解されたい。
【0029】
ステップ330において、クラウドベースのロケーションプラットフォーム160は、バッチ中の各ビーコン140を通してループし、識別子(たとえば、MACアドレス、セルIDなど)を通して反復適用され、ビーコンについてのRTT情報の集約を調べる。ステップ340において、クラウドベースのロケーションプラットフォーム160は、ビーコンについてのRTT情報内のRTT測定ステータスに基づいてビーコン140のRTT能力を決定する。少なくとも1つのUE 110からのRTT測定ステータスが、それはRTT対応であると示す場合、ビーコン140は、RTT対応とマークされ得る。UE 110のすべてからのRTT測定ステータスが、それはRTT非対応であると示す場合、ビーコン140は、RTT非対応とマークされ得る。少なくとも1つのUE 110からのRTT測定ステータスが、ビーコンはRTT範囲外であることを示す(ただしUE 110のRTT測定ステータスは、UEがRTT対応であることを示す)場合、ビーコン140は、未知のRTT能力を有するとマークされ得る。
【0030】
ステップ350において、クラウドベースのロケーションプラットフォーム160は、ビーコン140のRTT能力がそれはRTT対応であると示すかどうかを決定する。そうでない場合、実行はループして、次のビーコンを調べる。そうである場合、実行はステップ360に進み、クラウドベースのロケーションプラットフォーム160は、ビーコンによるRTT測定における予想されるオフセット/誤差を測定する、ビーコン140についてのRTTバイアスを推定する。RTTバイアスは、様々な技法を使用して推定され得る。たとえば、UE 110とビーコン140との間のRTTが決定した距離と、UEとビーコンとの間の位置フィックスが決定した距離との間のデルタが計算され得る。ビーコン140を観測したいくつかの(たとえば、すべての)UE 110にわたってデルタが実質的に同じである場合、デルタは、ビーコンのRTTバイアスとして使用されてもよい。また、クラウドベースのロケーションプラットフォーム160は、共通の組織識別子(たとえば、組織固有識別子(OUI))をビーコンと共有する他のビーコン140を決定してもよい。いくつかのこれらの他のビーコンが実質的に同じRTTバイアスを共有する場合、このRTTバイアスは、現在のビーコンに仮定され得る。これは、デルタ計算が可能ではない状況においてRTTバイアスの推定を可能にし得る。
【0031】
ステップ370において、クラウドベースのロケーションプラットフォーム160は、RTTに基づいて計算されたUE 110とビーコン140との間の距離(範囲)が妥当であるかどうかを決定する。たとえば、距離が、他の技法(たとえば、GNSS位置フィックス)を使用するUE 110の位置と、ビーコンデータベース170内のビーコン位置との間の距離と一致しているかどうかが決定され得る。RTTに基づく距離が妥当ではない場合、ビーコン140のRTT能力は(たとえば、ビーコンをRTT非対応とマークするために)更新される。
【0032】
ステップ380において、クラウドベースのロケーションプラットフォーム160は、ビーコン140の物理的アンテナ位置を決定する。決定は、複数のUEからのRTT測定を行う三辺測量アルゴリズム(たとえば、WLSマルチラテレーションアルゴリズム)を使用する。物理的アンテナ位置を決定するための例示的な動作の詳細について、以下で説明する。
【0033】
ステップ390において、ビーコンの各々を通してループする実行が行われるとき、クラウドベースのロケーションプラットフォーム160は、新しいRTT能力を含めるためにビーコンデータベース170(またはより具体的にはそれのRTTデータベース175)を更新する。その後、ローカルコピー(たとえば、タイル)を利用する実装形態において、更新されたビーコンデータベース170の部分は、もとのUE 110に提供されて、UE 110にビーコンのRTT能力を知らせてもよく、したがってUE 110はRTTに基づく測位を行うことができる。
【0034】
図4は、UE 110からクラウドソーシングされたRTT測定値を使用して、ビーコン位置またはより具体的にはビーコンの物理的アンテナ位置を決定するためにクラウドベースのロケーションプラットフォーム160によって行われる例示的な動作400を詳述する流れ図である。ステップ410において、クラウドベースのロケーションプラットフォーム160は、RTT対応のビーコン140のUE 110からの観測を受信する。観測は、UEの決定された位置(たとえば、GNSS位置フィックス)、決定された位置の位置信頼度(たとえば、GNSS位置フィックスのHPE)、ビーコンの識別子(たとえば、MACアドレス、セルIDなど)、およびRTT情報を含んでもよい。RTT情報は、RTT測定値、RTT測定不確実性、RTT測定に関連する信号強度、RTT測定に関連する帯域幅、ならびに他のRTTに関係するデータを含んでもよい。ステップ420において、クラウドベースのロケーションプラットフォーム160は、所与のビーコン140の観測を集約する。ステップ430において、クラウドベースのロケーションプラットフォーム160は、UEの決定された位置の位置信頼度(たとえば、GNSS位置フィックスのHPE)としきい値の比較に基づいて観測をフィルタリングする。好ましくは、しきい値は、非常に乏しい位置信頼度を有する観測(たとえば、非常に大きいHPEを有する観測)のみを削除するように設定される。その後の動作での重み付けによって、適度に信頼できる観測に対応してもよい。
【0035】
ステップ440において、クラウドベースのロケーションプラットフォームは、UE 110からの集約された観測に基づいて、ビーコン位置、またはより具体的にはビーコンの物理的アンテナ位置を決定するために三辺測量アルゴリズムを使用する。三辺測量アルゴリズムは、WLSマルチラテレーションアルゴリズムであってもよく、その中で重みは、UEの決定された位置の信頼度(たとえば、GNSS位置フィックスのHPE)、RTT測定不確実性、RTTが決定した範囲(たとえば、より長い範囲からの測定は信頼性が低いと考えられる)、RTT測定に関連する信号強度、RTT測定の数、およびRTT測定に関連する帯域幅(たとえば、高帯域ほど誤差が小さいと考えられる)の関数である。場合によっては、WLSマルチラテレーションアルゴリズムは、他の情報(たとえば、RSS、到来角(AoA)など)を考慮する場合もあり、不確実性に基づいてそれらに重みを適用する(たとえば、RSSはRTTよりも高い不確実性を有する可能性があるので、RSS測定に対してより高い重みを適用する)。ステップ450において、クラウドベースのロケーションプラットフォームは、ビーコン140の決定された位置、またはより具体的にはビーコンの決定された物理的アンテナ位置を含めるために、ビーコンデータベースを更新する。その後、更新されたビーコンデータベース170の部分(たとえば、タイル)は、もとのUE 110に提供されてもよく、ビーコンの決定された物理的アンテナ位置が、UEのRTTに基づく測位において使用できるようにする。
【0036】
三辺測量の精度は、非常に優れた位置信頼度を有するUEの決定された位置を使用することによってしばしば改善され得る。決定された位置がGNSS位置フィックスである場合、非常に優れた位置信頼度は、非常に低いHPEとして測定され得る。図5は、HPEおよび位置決定の精度の印としてのHPEの使用を示すUE 110の例示的な配置500の図である。ビーコン510の位置は、UE 520~540のGNSS位置フィクスを使用する三辺測量によって決定されてもよく、UE 520~540は各々、所与の半径を有する円によって表されるHPEを有する。具体的には、UE 540のHPEはやや大きく、この位置では信頼度が低いことを示す。UE 540の位置は、非常に不正確である可能性があり、三辺測量の精度に影響を及ぼし得る。UE 540の位置の精度が改善され得る場合、三辺測量の精度もまたおそらく改善され得る。
【0037】
UE 110についての位置決定の精度を向上させる1つの技法は、RTK補正サービスを含む。従来の実装形態、RTK補正の「オンボード」実装形態では、UE 110内のGNSS受信機130は、RTK対応であり、UEにおいて適用されるリアルタイムの補正を提供するRTK基地局の独立したネットワークと対話する。しかしながら、RTK対応のGNSS受信機は、一般的に極めて高価であり、低コストのUE(たとえば、スマートフォン、スマートウォッチなど)には通常配置されない。したがって、動作が「オンボード」であるように制限される場合、多くのUE 110は、RTK補正の恩恵を得ることができない。
【0038】
この限界は、UE 110からの生のGNSS測定値(たとえば、疑似距離)が、RTK GNSS位置フィックスを行うクラウドベースのロケーションプラットフォーム160に提供される「オフボード」実装形態によって対処され得る。図6は、クラウドベースのRTK GNSS位置フィックスを使用して、ビーコン位置またはより具体的にはビーコンの物理的アンテナ位置を決定するために「オフボード」実装形態でクラウドベースのロケーションプラットフォーム160によって行われる例示的な動作600を詳述する流れ図である。ステップ610において、クラウドベースのロケーションプラットフォーム160は、RTT対応のビーコンのUE 110からの観測を受信する。観測は、UE 110のGNSS受信機130からの生のGNSS測定値(たとえば、疑似距離)、ビーコンの識別子(たとえば、MACアドレス、セルIDなど)、およびRTT情報のうちの1つまたは複数のセットを含んでもよい。RTT情報は、RTT測定値、RTT測定不確実性、RTT測定に関連する信号強度、RTT測定に関連する帯域幅、ならびに他のRTTに関係するデータを含んでもよい。ステップ620において、クラウドベースのロケーションプラットフォーム160は、インターネット150を介してRTK補正サービスに接続し、RTK補正情報を取得する。ステップ630において、生のGNSS測定値の各セットに対して、クラウドベースのロケーションプラットフォーム160は、生のGNSS測定値およびRTK補正情報を使用して、UE 110に対して補正されたGNSS位置フィックスを決定する。ステップ640において、クラウドベースのロケーションプラットフォーム160は、UE 110の各々に対して、結果として得られた補正されたGNSS位置フィックスのHPEを決定する。この補正GNSS位置フィックスは、一般に、UE自体によって生成されたGNSS位置フィックスよりもはるかに小さいHPEを有することになる。
【0039】
ステップ650において、クラウドベースのロケーションプラットフォーム160は、所与のビーコンについて、UEのクラウドベースのRTK GNSS位置フィックスを含む、観測を集約する。ステップ660において、クラウドベースのロケーションプラットフォーム160は、GNSS位置フィックスのHPEのしきい値との比較に基づいて観測をフィルタリングする。ステップ670において、クラウドベースのロケーションプラットフォーム160は、UE 110からの集約された観測に基づいて、ビーコン位置、またはより具体的にはビーコンの物理的アンテナ位置を決定するために三辺測量アルゴリズムを使用する。三辺測量アルゴリズムは、UE 110からのHPEの代わりに補正されたGNSS位置フィックスのHPEが使用されることを除いて、上記で説明したように重みを有するWLSマルチラテレーションアルゴリズムであってもよい。ステップ680において、クラウドベースのロケーションプラットフォーム160は、ビーコン140の決定された位置、またはより具体的にはビーコンの決定された物理的アンテナ位置を含めるために、ビーコンデータベース170を更新する。その後、更新されたビーコンデータベース170の部分(たとえば、タイル)は、もとのUEに提供され得る。
【0040】
更新されたビーコンデータベース170の部分(たとえば、タイル)は、ローカルにキャッシュされ、RTTに基づく測位を行うためにUE 110によって使用されてもよい。位置決定を単にRTT測定に基づかせる、または他の情報(たとえば、RSS、AoAなど)と組み合わせてRTTを使用する、いくつかの異なるRTTに基づく測位アルゴリズムが使用され得る。一実施形態では、WLS測位アルゴリズムおよび拡張カルマンフィルタ測位アルゴリズムを混成させるハイブリッドRTTに基づく測位アルゴリズムが利用される。
【0041】
図7は、UE位置を決定するためにハイブリッドRTTに基づく測位アルゴリズムを実装するようにUE 110上で測位クライアント122によって行われる例示的な動作700を詳述する流れ図である。ステップ710において、測位クライアント122は、ある時間期間(たとえば、1秒の期間)にわたるUE 110の範囲内のRTT対応のビーコンによるRTT測定値を集約する。ステップ720において、測位クライアント122は、それに対する情報(たとえば、ビーコン位置)がUE 110によってローカルにキャッシュされたビーコンデータベース170の部分(たとえば、タイル)において利用可能である、集約の中のいくつかの固有のビーコン140を決定する。ステップ730において、測位クライアント122は、固有のビーコンの数がしきい値(たとえば、1つのビーコン)よりも大きいかどうかを決定する。固有のビーコンの数がしきい値よりも大きい場合、実行はステップ740へ進み、WLS測位アルゴリズムによってUE位置が決定される。WLS測位アルゴリズムで使用される重みは、RTT測定値の数、ビーコンの決定された位置の信頼度(たとえば、HPE)、RTT測定不確実性、および/または他の因子に基づいてもよい。WLS測位不確実性(たとえば、WLS位置HPE)が、ステップ740の一部として生成されてもよい。ステップ745において、測位クライアント122は、決定されたWLS位置に等しくなるようにカルマンフィルタ状態をリセットし、初期化する。次いで、ステップ750において、測位クライアント122は、決定されたWLS位置をUE 110の位置として(たとえば、UE上で実行しているアプリケーションに)報告する。
【0042】
固有のビーコンの数がしきい値よりも大きくない場合、実行はステップ760へ進み、カルマンフィルタ測位アルゴリズムによってUE位置が決定される。カルマンフィルタ状態が、ステップ745の一部として決定されたWLS位置に等しくなるようにすでに初期化されていた場合、そのような初期化が使用される。そうでない場合、カルマンフィルタ状態が、固有のビーコンの中央値(median)ビーコンロケーションに初期化され得る。ステップ770において、測位クライアント122は、カルマンフィルタ測位アルゴリズムが成功であったかどうかを決定し、そうである場合、ステップ750において、測位クライアント122は決定されたカルマン位置をUE 110の位置として報告する。カルマンフィルタ測位アルゴリズムが成功しなかった場合、ステップ775において測位クライアント122は、フレッシュネス区間(たとえば、2秒)内に返された前のカルマン位置があったかどうかを決定し、そうであった場合、ステップ750において測位クライアント122は、前のカルマン位置をUE 110の位置として(たとえば、UE上で実行しているアプリケーションに)報告する。フレッシュネス区間内に返された前のカルマン位置がなかった場合、ステップ780において測位クライアント122は、フレッシュネス区間内に返された前のWLS位置があったかどうかを決定する。そうであった場合、ステップ750において、測位クライアント122は、ステップ790において前のWLS位置に等しくなるようにカルマンフィルタ状態をリセットし、初期化し、前のWPS位置をUE 110の位置として、ステップ750において、報告する。フレッシュネス区間内に返された前のWLS位置がなかった場合、ステップ795において測位クライアント122は、UE 110に対して位置結果を報告しない。
【0043】
位置決定を単にRTT測定に基づかせることに加えて、測位アルゴリズムは、位置を決定するために他の情報(たとえば、RSS、AoAなど)と組み合わせてRTTを使用してもよいことを理解されたい。いくつかの場合には、RTT測定は、主として別の形態のビーコンデータ(たとえば、RSS)を利用する技法の精度を向上させるために使用されてもよい。たとえば、測位アルゴリズムが、UE位置を推定するために重み付き三辺測量においてビーコンに対して複数のRSS測定を使用してもよい。RTT測定は、RSS測定を調整する、潜在的に誤りのあるRSS測定をフィルタリングする、重み付き三辺測量においてビーコンに割り当てられる重みを調整するために、かつ/または他の方法においてRSS測位の精度を上げるために、使用されてもよい。
【0044】
上記の説明は、UE 110のRTTに基づく測位を可能にする様々なクラウドソーシング技法を詳述する。技法およびそれらの一部は、実装形態に応じて一緒に、個々に、または他の技法と組み合わせて利用され得ることを理解されたい。さらに、技法の態様は、実装形態に応じて修正され、追加され、削除され、または場合によっては変更され得ることを理解されたい。さらに、特定の例示的なハードウェアおよびソフトウェアについて上記で説明しているが、技法は様々な異なるタイプのハードウェア、ソフトウェア、およびそれらの組合せを使用して実装され得ることを理解されたい。そのようなハードウェアは、様々なタイプのプロセッサ、メモリチップ、プログラマブル論理回路、特定用途向け集積回路、および/またはソフトウェアの実行をサポートする他のタイプのハードウェア構成要素を含み得る。そのようなソフトウェアは、揮発性もしくは永続性メモリデバイス、ハードディスク、または他のデータストアなどの、非一時的電子デバイス可読媒体に記憶されたアプリケーションを実装する実行可能な命令を含み得る。ソフトウェアおよびハードウェアの組合せが、異なる環境および用途に適合するように構成されてもよい。とりわけ、上記の説明は単に例として受け取られるよう意図されていることを理解されたい。
【符号の説明】
【0045】
100 例示的なアーキテクチャ
110 UE
115 中央処理装置(CPU)
120 ストレージ
122 測位クライアント
125 ワイヤレスネットワークインターフェース
130 GNSS受信機
140 ビーコン
150 インターネット
160 クラウドベースのロケーションプラットフォーム
170 ビーコンデータベース
175 RTTデータベース
図1
図2
図3
図4
図5
図6
図7
【国際調査報告】