WO2024009365A1

WO2024009365A1 - 制御装置、測位演算方式決定方法、及びプログラム

Info

Publication number: WO2024009365A1
Application number: PCT/JP2022/026628
Authority: WO
Inventors: 孝太郎小野; 和宏徳永; 健桑原
Original assignee: 日本電信電話株式会社
Priority date: 2022-07-04
Filing date: 2022-07-04
Publication date: 2024-01-11

Abstract

測位対象に対して使用する測位演算方式を決定する制御装置であって、測位演算方式に要求される要件、及び、測位演算方式の優先度を入力する入力部と、実施可能であり、かつ、前記要件を満たす１又は複数の測位演算方式の中から、前記優先度に基づいて、前記測位対象に対して使用する測位演算方式を決定する決定部とを備える。

Description

制御装置、測位演算方式決定方法、及びプログラム

　本発明は、位置情報の取得技術に関連するものである。

　近年、ＧＮＳＳ（Global Navigation Satellite Systems：全地球航法衛星システム）による測位がスマートフォンを含む幅広いアプリケーションに活用されている。

　また、位置情報の測位演算方式が多角化／高度化している。具体的には、ＧＮＳＳ測位の高精度化に加えて、デッドレコニングや画像測位等のＧＮＳＳ信号を使用しない測位演算方式の実用化／高度化も進んでいる。

　また、既に多様な位置情報を活用するサービスがあり、今後もサービスの増加／多角化が進んでいくことが想定される。

吉田誠史, 桐原誉人, 坪井俊一, 豊野剛, 桑原健, "GNSSとネットワークの連携による高付加価値位置情報サービス", NTT技術ジャーナル, 2019.4 https://journal.ntt.co.jp/wp-content/uploads/2020/06/JN20190415.pdf

　上述した状況から、位置情報に関する要件も細分化／高度化している。そのため、環境や要求条件に合った位置情報の取得方法を用いることが求められている。

　しかし、従来技術では、端末等の状況に対応して、位置情報の取得方法（測位演算方式等）を適切に決定することができなかった。

　本発明は上記の点に鑑みてなされたものであり、端末等の状況に対応して、位置情報の取得方法を適切に決定することを可能とする技術を提供することを目的とする。

　開示の技術によれば、測位対象に対して使用する測位演算方式を決定する制御装置であって、
　測位演算方式に要求される要件、及び、測位演算方式の優先度を入力する入力部と、
　実施可能であり、かつ、前記要件を満たす１又は複数の測位演算方式の中から、前記優先度に基づいて、前記測位対象に対して使用する測位演算方式を決定する決定部と
　を備える制御装置が提供される。

　開示の技術によれば、端末等の状況に対応して、位置情報の取得方法を適切に決定することを可能とする技術が提供される。

測位を行う環境の特徴を示す図である。測位方式を変更するイメージを示す図である。システムの全体構成例を示す図である。測位演算方式の特性を示す図である。測位演算方式の特性を示す図である。測位演算方式の適性を示す図である。測位演算方式の適性を示す図である。制御装置１００の構成図である。測位演算方式判断部１１０の処理フローを示す図である。測位演算方式判断部１１０の処理フローを示す図である。実施可能な測位演算方式のパターンを示す図である。測位演算方式判断部１１０の処理フローを示す図である。使用する測位演算方式の遷移例を示す図である。使用する測位演算方式の遷移例を示す図である。使用する測位演算方式の遷移例を示す図である。測位演算方式判断部１１０の処理フローを示す図である。密集性に応じて測位演算方式を決定する方法を説明するための図である。測位演算方式判断部１１０の処理フローを示す図である。情報送受信時間差の通知を説明するための図である。システムの構成例を示す図である。装置のハードウェア構成例を示す図である。

　以下、図面を参照して本発明の実施の形態（本実施の形態）を説明する。以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。なお、以下の説明で用いる"／"は、「又は」を意味する。例えば「Ａ／Ｂ」は、「Ａ又はＢ」である。ただし、「Ａ／Ｂ」は、「ＡとＢのうちのどちらか１つのみ」を意味しているのではなく、「ＡとＢの両方」も「Ａ／Ｂ」の意味に含まれる。

　（実施の形態の概要）
　まず、本実施の形態の概要について説明する。なお、以下で説明する既存の測位演算方式自体は公知技術であるが、その特徴のまとめや、分析、課題の説明などは公知技術ではない。

　図１に、測位を行う場所（環境）として１～５の５つの例を挙げ、それぞれの特徴を示す。ここでは、特徴として、「ＧＮＳＳ信号受信環境」、「混雑／密集性」、「測位誤差の許容範囲」、その環境で主に利用することが想定される測位方式を挙げている。

　各測位演算方式には一長一短があるため、ある１つの測位演算方式を固定的に用いると周囲の環境の変化によっては必要な精度を満たせない。また、端末を含むＮＷ全体として位置情報を算出する負荷に無駄（非効率なリソース利用など）が生まれる。

　そのため、本実施の形態では、条件に応じて、図２に示すように、測位演算方式を変えることとしている。

　すなわち、本実施の形態では、後述する制御装置１００により、要件を満たしつつリソースの効率的な利用（コストを含む）を可能にするために、ＮＷ側で管理する情報を活用してプロアクティブに測位演算方式を変更（測位演算自体にＮＷ情報を考慮することを含む）する。これにより、より適切な状態を実現できる。

　測位演算方式を変える（決定する）際の基となる条件として、例えば、下記の条件（１）～（４）を挙げることができる。例えば、下記の複数の条件のうちのいずれか１つ又は複数を用いて、測位演算方式を決定することができる。

　（１）道路条件
　「道路条件」は、高速道路（自動車専用道路）と一般道の区別、車線数、車線の有無、歩道の有無、及び、自動運転車の専用道路か否かなど、走行する道路に関わる条件である。

　（２）地理条件
　「地理条件」は、測位対象（例：車両）が存在する場所が、都市部か否か、山間部か否か、あるいは、仮想的に線引きした地理的境界線（ジオフェンス）内か否かなど、道路の状況だけではなく周辺の環境も含んで設定する条件である。なお、ジオフェンスとして、自動運転車を走行させる範囲を事前に定めることで、規制の緩和やマッピング、インフラの整備など、自動運転を行いやすい環境を構築することができる。

　地理条件を用いることで、例えば、過疎道路から交差点進入時などの走行環境変化に対応して、測位演算方式を決定できる。

　（３）環境条件
　「環境条件」は、天候や日照状況（昼・夜の区別）などの周辺状況に関する条件である。環境条件は、例えば、豪雨時や降雪・積雪など、センサ（例：車載センサ）の精度に影響を及ぼす可能性がある場合などに使用する。

　環境条件を用いることで、例えば、可視衛星数やマルチパス環境の変化を含むＧＮＳＳ信号受信状況変化に対応して、測位演算方式を決定できる。

　（４）その他
　その他の条件として、速度制限や信号情報などのインフラ協調の有無、特定の経路のみに限定した運行の有無、保安要員の乗車要否、連続運行時間などの諸条件がある。これらの条件を用いることで、例えば、電磁誘導線や磁気マーカ等による自己位置特定のためのインフラ支援状況に対応して、測位演算方式を決定できる。

　本実施の形態に係る制御装置１００は、上記のような条件を考慮するとともに、例えば、下記の判断を行うことで、測位演算方式を決定（設定）する。

　・実現可能な測位演算機能（能力）を端末が持っているか否か
　・実現可能な測位演算機能（能力）をＮＷ（エッジ／クラウド）側が持っているか否か
　・測位演算に必要な情報を端末側やＮＷ（エッジ／クラウド）側からＮＷ経由等で取得可能な状態になっているかどうか
　・測位演算結果が要件を満たせるかどうか
　・ＮＷ測位と端末測位のどちらを優先するか
　・測位演算方式の優先順位はどうか
　上記のような判断を行うことで、端末が存在する場所の環境と測位演算方式の特徴に合わせて、様々な位置情報の取得方法（演算方法、演算場所）の間での切換を行うことができる。

　これにより、端末側の電力、及びＮＷ（エッジ／クラウド）側の電力を含むリソース利用効率の向上と、要件充足範囲（サービスカバレッジ）の拡大、及び、位置情報収集範囲の拡大を実現できる。

　（システム構成例）
　図３に、本実施の形態におけるシステム（ネットワーク）の全体構成例を示す。図３に示すように、基準局１、移動局（端末）２、エッジ／クラウドサーバ３、情報基盤４が存在し、それぞれネットワーク５に接続されている。

　また、図３の例では、移動局２が、端末側機能部８、及び端末側測位演算部９を備える。エッジ／クラウドサーバ３は、ＮＷ側測位演算部７を備える。ネットワーク５は、ＮＷ側機能部６を備える。

　情報基盤４は、例えば、「高度地理空間情報データベース」上に、多様なセンシングデータをリアルタイムに統合し、高速に分析処理を行う基盤（データベースを含む）である。

　端末側機能部８は、ＮＷ側機能部６の判断結果に基づく測位演算方式の切り替え、及びＮＷ側への送信情報の切り替えを行う。また、端末側機能部８は、端末側の状態監視及び情報送信を行う。

　ＮＷ側機能部６は、ＮＷ／サーバリソースの状態監視を行う。具体的には、基地局と移動局／ＮＷ側測位演算部との間、移動局とＮＷ側測位演算部との間、における、ＮＷ種別、品質、やり取りされるデータ量、及び、Ｅ２Ｅでの伝送遅延等を把握する。また、ＮＷ側機能部６は、測位演算機能（コード／ＲＴＫ測位、画像認識やＩＭＵ等による複合測位）の配置／利用状態（効率、コストを含む）を把握する。

　また、ＮＷ側機能部６は、端末識別子（ＥＩＤ等）と利用サービス／測位要件の関係性を保持する。また、ＮＷ側機能部６は、情報基盤４（データベース）との連携を行う。具体的には、地図上での端末位置（周囲の静的／動的物体との位置関係を含む）の把握を行う。また、デジタルツイン反映時に測位演算方式の情報を付加する。

　ＮＷ側機能部６は、上記の情報に基づいて、測位演算対象に適用する測位演算方式の決定を行う。

　なお、後述する制御装置１００は、ＮＷ側機能部６に含まれることを想定している。ただし、これは例であり、制御装置１００が端末側に備えられてもよい。

　本システムでは、ＮＷ側で端末の状況（及びＮＷ（エッジ／クラウド）側）を監視し、より良い測位演算方式を選択することで、より良い測位演算を実現する。「選択機能」（制御装置１００）はＮＷ（エッジ／クラウド）側に備えてもよいし、端末側に備えてもよいし、両方に分散配備して調停しながら運用してもよい。

　（測位演算方式の特徴）
　本実施の形態において選択の対象となる測位演算方式と、その特性を図４、図５に示す。図４は端末側測位を示し、図５は、ＮＷ側測位を示す。

　図４、図５において、複合演算方式における「ＧＮＳＳ＋α」におけるαは、デッドレコニングに使用される加速度センサ／ジャイロ／磁気センサ、あるいは画像認識等である。また、図５では、ＮＷ側でのコード測位を挙げている。これは技術的には可能だがＮＷ側で実施するメリットは小さい。

　（判断方法の概要）
　次に、本実施の形態において、制御装置１００が測位演算方式を選択する際の判断方法について説明する。

　＜判断ポリシー＞
　制御装置１００は、入力される要件及び優先度に基づいて、測位演算方式毎に、下記の要素を（１）→（２）→（３）→（４）の順番で考慮し、測位演算方式の絞り込みと決定を行う。下記のポリシーにより、要件を満たす測位演算方式の中で優先度の高いものを選択する。

　（１）測位演算機能の有無（ＮＷあるいは端末において、機能として実施可能な測位演算方式かどうか）
　（２）その時点での端末／ＮＷ側の環境／状況下で実施可能な測位演算方式かどうか
　（３）測位演算方式が要件を満たすかどうか
　（４）リソースの効率的な利用を考慮した測位演算方式の優先度
　また、制御装置１００は、測位演算方式の正確性（精度）／利便性（頻度、遅延）／完全性の重みづけを行って、判断を実行してもよい。

　＜要件＞
　判断ポリシーで用いられる要件は、測位演算方式選択の判断材料となる入力の１つである。要件の例は下記ａ、ｂである。

　（ａ）サービスや環境によって決定される測位演算結果に求められる正確性（精度）／利便性（頻度、遅延）／完全性
　上記の要件は、サービスによって固定的に決まる要件と、地図上の位置や端末の密集性によって変動する要件がある。

　（ｂ）利用するリソース（ＮＷ／サーバリソース）
　ＮＷ／サーバリソースに加えて、電力消費（特に端末の電池消耗）（および変動）も考慮する。

　＜優先度＞
　判断ポリシーで用いられる優先度は、測位演算方式選択の判断材料となる入力の１つである。優先度の例として、端末／ＮＷ側環境および状況変化に基づいて決定される優先度がある。

　基本的に端末リッチ（端末の機能及びリソースが豊富）の場合は端末側測位優先、それ以外はＮＷ側測位優先となる。また、端末／ＮＷ側の電力消費やリソース状況に応じて、要件を満たす範囲で優先度は適宜変更することとしてよい。

　本実施の形態の制御装置１００は、要件を満たす測位演算方式の中で、優先度の高いものを選択する。

　（測位演算方式の適性）
　図６、図７に、プロアクティブに測位演算方式を変更することを考慮した、各測位演算方式の適性をまとめた図を示す。

　例えば、図６において、端末側測位のデッドレコグニングは、ＧＮＳＳ信号が受信不可でも適用できるが、端末の電力消費は中から大であり、端末視点での混雑度が無から小である必要があることを示している。また、図７に示すように、端末側測位のデッドレコグニングは、ＮＷ／サーバリソースが逼迫していても適用できる。

　（装置構成）
　以降、本実施の形態における装置構成と装置の動作を詳細に説明する。図８に、本実施の形態における制御装置１００の構成例を示す。制御装置１００を制御システムと呼んでもよい。制御装置１００は、１つのコンピュータで構成してもよいし、複数のコンピュータで構成してもよい。

　図８に示す制御装置１００により、リアルタイムな情報取得に基づく変動要素を考慮したプロアクティブな測位演算方式の適用判断を行うことができるとともに、ＮＷ側へ送信する情報の切り替えを行うことができる。

　また、ＮＷ状況（例：基準局情報の伝送にかかるＥ２Ｅでの処理遅延）の測位演算方式自体への反映を行うことができる。

　図８に示すように、制御装置１００は、測位演算方式判断部１１０、記憶部１２０、情報取得部１３０、測位演算方式制御部１４０を有する。なお、測位演算方式判断部１１０を決定部と呼び、情報取得部１３０を入力部と呼んでもよい。

　情報取得部１３０は、ＮＷ、サーバ、他システム等から、各種の管理情報及び各種の取得情報を受信する。これら各種の情報の例として、例えば、下記の情報がある。

　・ＮＷ／サーバリソースの配備／利用状況（Ｅ２Ｅでの遅延等の品質を含む）
　・測位演算機能の配備／利用状態
　・端末識別子と利用サービス／測位要件との関係性
　・地図上での端末位置（周囲の静的／動的物体との位置関係を含む）
　・Ｇｅｏｆｅｎｃｉｎｇ関連情報
　・電力状況
　・端末保守期間関連情報
　・要件、優先度
　情報取得部１３０により取得された情報は、記憶部１２０に格納される。測位演算方式判断部１１０は、記憶部１２０から読み出した情報に基づいて、測位対象についての測位演算方式を判断する。測位演算方式判断部１１０は、測位演算方式判断結果を記憶部１２０に格納するとともに、測位演算方式制御部１４０に通知する。

　測位演算方式制御部１４０は、測位演算方式／送信情報の切り替えについての適用指示を測位演算機能部、情報送信機能部等に送信する。

　（測位演算方式判断部１１０の処理フロー）
　次に、測位演算方式判断部１１０の処理フローについて、図９、図１０を参照して説明する。図９における記号Ｂ～Ｃは下記を意味する。

　Ｂ：端末側で複合測位ができない（デッドレコニングとＲＴＫ測位はできる）
　Ｃ：端末側で複合測位とデッドレコニングのいずれもできない（ＲＴＫ測位はできる）
　Ｄ：端末側で複合測位とＲＴＫ測位のいずれもできない（デッドレコニングはできる）
　Ｅ：端末側で複合測位とＲＴＫ測位とデッドレコニングがいずれもできない
　Ｆ：端末側で測位演算できない
　Ｓ１０１において、測位演算方式判断部１１０は、端末側で測位演算可能か否かを判断する。Ｓ１０１の判断結果がＹｅｓであればＳ１０２に進み、Ｎｏであれば「Ｆ」であると判断する。

　Ｓ１０２において、測位演算方式判断部１１０は、端末側で複合測位が可能か否かを判断する。Ｓ１０２の判断結果がＹｅｓであれば「Ａ」に進み、ＮｏであればＳ１０３に進む。

　Ｓ１０３において、測位演算方式判断部１１０は、端末側でＲＴＫ測位可能か否かを判断する。Ｓ１０３の判断結果がＹｅｓであればＳ１０４に進み、ＮｏであればＳ１０５に進む。

　Ｓ１０４において、測位演算方式判断部１１０は、端末側でデッドレコニングが可能か否かを判断する。Ｓ１０４の判断結果がＹｅｓであれば「Ｂ」であると判断し、Ｎｏであれば「Ｃ」であると判断する。

　Ｓ１０５において、測位演算方式判断部１１０は、端末側でデッドレコニングが可能か否かを判断する。Ｓ１０５の判断結果がＹｅｓであれば「Ｄ」であると判断し、Ｎｏであれば「Ｅ」であると判断する。

　図１０でＡに進んだ場合における処理フロー（端末／ＮＷ側の環境／状況の確認）を図１０に示す。また、図１０に示すＡ－１～Ａ－１０は図１１に示されている。

　図１０に示すように、Ｓ２０１において、測位演算方式判断部１１０は、測位演算にクラウド環境が利用可能か否かを判断する。つまり、ＮＷ側での測位演算が利用可能か否かを判断する。Ｓ２０１の判断結果がＹｅｓであればＳ２０２に進み、ＮｏであればＳ２０７に進む。

　Ｓ２０２において、測位演算方式判断部１１０は、測位対象（例：車両等の端末（移動局））における複合測位向けセンサ情報は利用可能か否かを判断する。Ｓ２０２の判断結果がＹｅｓであればＳ２０３に進み、ＮｏであればＳ２０５に進む。

　Ｓ２０３において、測位演算方式判断部１１０は、測位対象におけるＧＮＳＳ信号受信環境は良好か否かを判断する。Ｓ２０３の判断結果がＹｅｓであれば「Ａ－１」であると判断し、ＮｏであればＳ２０４に進む。

　Ｓ２０４において、測位演算方式判断部１１０は、測位対象におけるＧＮＳＳ信号受信が可能か否かを判断する。Ｓ２０４の判断結果がＹｅｓであれば「Ａ－２」であると判断し、Ｎｏであれば「Ａ－３」であると判断する。

　Ｓ２０５において、測位演算方式判断部１１０は、測位対象におけるＧＮＳＳ信号環境が良好か否かを判断する。Ｓ２０５の判断結果がＹｅｓであれば「Ａ－４」であると判断し、ＮｏであればＳ２０６に進む。

　Ｓ２０６において、測位演算方式判断部１１０は、測位対象におけるＧＮＳＳ信号受信が可能か否かを判断する。Ｓ２０６の判断結果がＹｅｓであれば「Ａ－５」であると判断し、Ｎｏであれば「Ａ－３」であると判断する。

　Ｓ２０７において、測位演算方式判断部１１０は、測位対象において複合測位向けセンサ情報は利用可能か否かを判断する。Ｓ２０７の判断結果がＹｅｓであればＳ２０８に進み、ＮｏであればＳ２１０に進む。

　Ｓ２０８において、測位演算方式判断部１１０は、測位対象におけるＧＮＳＳ信号受信環境は良好か否かを判断する。Ｓ２０８の判断結果がＹｅｓであれば「Ａ－６」であると判断し、ＮｏであればＳ２０９に進む。

　Ｓ２０９において、測位演算方式判断部１１０は、測位対象におけるＧＮＳＳ信号受信が可能か否かを判断する。Ｓ２０９の判断結果がＹｅｓであれば「Ａ－７」であると判断し、Ｎｏであれば「Ａ－８」であると判断する。

　Ｓ２１０において、測位演算方式判断部１１０は、測位対象におけるＧＮＳＳ信号環境が良好か否かを判断する。Ｓ２１０の判断結果がＹｅｓであれば「Ａ－９」であると判断し、ＮｏであればＳ２１１に進む。

　Ｓ２１１において、測位演算方式判断部１１０は、測位対象におけるＧＮＳＳ信号受信が可能か否かを判断する。Ｓ２１１の判断結果がＹｅｓであれば「Ａ－１０」であると判断し、Ｎｏであれば「Ａ－８」であると判断する。

　前述のとおり、Ａ－１～Ａ－１０は図１１に示すとおりである。例えば、判断結果が「Ａ－３」になったときに、利用可能な測位演算方式は、端末側のデッドレコニング、及び、ＮＷ側のデッドレコニングである。

　（優先度の確認）
　続いて、測位演算方式判断部１１０は、図１２に示すフローにより、測位演算方式の優先度を判断することで、測位対象に対する測位演算方式を決定する。このフローにより、測位演算方式判断部１１０は、図１０、図１１のフローによる判断により残っている候補のうち、最も優先度の高い測位演算方式を選択する。

　なお、図１２のフローで測位不能となった場合、測位演算不可としても良いし、要件を充足していない参考の位置情報として、何がしかの測位演算方式（ＮＷ事業者都合の優先度で決めても、最も要件を満たせそうだったものを用いることでも構わない）で演算した結果を活用する（要求元に送信）運用を行っても構わない。

　上記のとおり、フローにおいては測位不能になる場合がある。一方、自動運転車の遠隔制御などのミッションクリティカル系全般では、方式の切替途中などにおいて位置情報が不連続になることは許容されない。

　そのため、位置情報が不連続になることが許容されないユースケースにおいては、要件を充足していないことなどによりフロー上で測位不能になる場合でも、測位演算機能により位置情報の取得を継続して、位置情報が不連続になることを回避する必要がある。

　そこで、要件を充足する測位演算不可がない状態において、制御装置１００は、例えば、ユーザポリシあるいはサービスポリシに従って、要件を充足していない参考の位置情報に基づいて、縮小対応しながら運用を続けるように、測位対象（ここでは例として自動運転車とする）を制御する。縮小対応とは、例えば、減速すること、自動運転制御に関わるサービス（提供範囲、性能など）を制限することなどである。

　また、自動運転車に対して減速を指示し、要件を充足するまで縮小対応し、要件を充足した後に、徐々に速度を増加させてもよい。また、自動運転車に対して減速を指示した後に、ある時間以内に要件を充足しない場合には、最終的に自動運転車の停止などサービス提供を停止することとしてもよい。

　図１２のＳ４０１において、測位演算方式判断部１１０は、要件を満たす測位演算方式があるか否かを判断する。一例として、車両の自動運転を行うために、正確な測位が必要であることが要件であるとすると、要件を満たす測位演算方式として、例えば、端末側又はＮＷ側の複合測位が選択される。このとき、既に行った判断により、端末側又はＮＷ側の複合測位が可能であれば、Ｓ４０１の判断はＹｅｓとなるが、端末側とＮＷ側のいずれも複合測位が不可能であれば、Ｓ４０１の判断はＮｏとなる。

　Ｓ４０１の判断がＹｅｓの場合は、Ｓ４０２に進み、Ｎｏの場合はＳ４０５において測位不能と判断する。

　Ｓ４０２において、測位演算方式判断部１１０は、優先度が、「端末側測位＜ＮＷ側測位」であるか否かを判断する。Ｓ４０２の判断がＹｅｓの場合は、Ｓ４０３に進み、Ｎｏの場合はＳ４０４に進む。

　Ｓ４０３において、測位演算方式判断部１１０は、優先度が、「ＲＴＫ測位＜複合測位」であるか否かを判断する。Ｓ４０３の判断がＹｅｓの場合は、下記の（１）～（８）の優先順位で、候補として残存している測位演算方式の中から使用する測位演算方式を決定する。候補として残存している測位演算方式とは、図１０、図１１のフローの判断で実施可能であり、かつ、要件を満たす測位演算方式である。

　（１）ＮＷ側測位（複合）
　（２）ＮＷ側測位（ＲＴＫ）
　（３）ＮＷ側測位（デッドレコニング）
　（４）端末側測位（複合）
　（５）端末側測位（コード）
　（６）端末側測位（ＲＴＫ）
　（７）端末側測位（デッドレコニング）
　（８）測位不能（時刻／位置情報利用システム停止など）
　Ｓ４０３の判断がＮｏの場合、下記の（１）～（８）の優先順位で、候補として残存している測位演算方式の中から使用する測位演算方式を決定する。

　（１）ＮＷ側測位（ＲＴＫ）
　（２）ＮＷ側測位（複合）
　（３）ＮＷ側測位（デッドレコニング）
　（４）端末側測位（コード）
　（５）端末側測位（ＲＴＫ）
　（６）端末側測位（複合）
　（７）端末側測位（デッドレコニング）
　（８）測位不能（時刻／位置情報利用システム停止など）
　Ｓ４０４において、測位演算方式判断部１１０は、優先度が、「ＲＴＫ測位＜複合測位」であるか否かを判断する。Ｓ４０４の判断がＹｅｓの場合は、下記の（１）～（８）の優先順位で、候補として残存している測位演算方式の中から使用する測位演算方式を決定する。

　（１）端末側測位（複合）
　（２）端末側測位（コード）
　（３）端末側測位（ＲＴＫ）
　（４）端末側測位（デッドレコニング）
　（５）ＮＷ側測位（複合）
　（６）ＮＷ側測位（ＲＴＫ）
　（７）ＮＷ側測位（デッドレコニング）
　（８）測位不能（時刻／位置情報利用システム停止など）
　Ｓ４０４の判断がＮｏの場合、下記の（１）～（８）の優先順位で、候補として残存している測位演算方式の中から使用する測位演算方式を決定する。

　（１）端末側測位（コード）
　（２）端末側測位（ＲＴＫ）
　（３）端末側測位（複合）
　（４）端末側測位（デッドレコニング）
　（５）ＮＷ側測位（ＲＴＫ）
　（６）ＮＷ側測位（複合）
　（７）ＮＷ側測位（デッドレコニング）
　（８）測位不能（時刻／位置情報利用システム停止など）
なお、上記の例では、いずれも８個の方式（測位不能含む）についての優先度を用いるが、８個のうちの全部ではなく、一部の複数の方式についての優先度を用いてもよい。つまり、８個のうちの一部の複数の方式を選択の候補としてもよい。

　（測位演算方式の判断の遷移例）
　次に、ＮＷ側の豊富なリソースを活用した高度測位の利用の例について、図１３を参照して説明する。ここでは、端末側の電源ＯＮからスタートし、端末が置かれている状況や、端末の機能有無に応じて、測位演算方式が遷移する。ここでの優先度は下記のとおりとする。

　・端末側測位＜ＮＷ側測位
　・端末側測位について
　デッドレコニング＜コード＜ＲＴＫ＜複合
　・ＮＷ側測位について
　デッドレコニング（＜コード）＜ＲＴＫ＜複合
　「デッドレコニング（＜コード）」は、ＮＷ側コード測位を行わなくてもよいことを示しており、ＮＷ側コード測位を行う場合には、「デッドレコニング＜コード」であることを示す。また、測位対象は「端末」である。

　電源ＯＮの後、Ｓ１において、端末側測位（コード）が行われる。端末がＲＴＫ測位可能なテバイス、かつ、ＧＮＳＳ信号受信環境が良好であれば、Ｓ２において、端末側測位（ＲＴＫ）が行われる。Ｓ２の状態において、基準局情報受信不可（ＮＷ環境悪化等）、あるいは、ＧＮＳＳ信号受信環境が悪化すればＳ１に進む。

　Ｓ１において、クラウド環境利用可能、かつＧＮＳＳ信号受信環境良好であれば、Ｓ３に進み、ＮＷ側測位（ＲＴＫ）が行われる。Ｓ３の状態において、クラウド環境利用不可、かつＧＮＳＳ信号受信環境が悪化すると、Ｓ１に進む。

　Ｓ１の状態で、端末がデッドレコニング可能なテバイスであり、かつＧＮＳＳ信号受信不可になったとすると、Ｓ５に進み、端末側測位（デッドレコニング）が行われる。Ｓ５の状態で、ＧＮＳＳ信号が受信可能になるとＳ１に進む。

　Ｓ１の状態において、端末が複合測位可能なデバイスであるとすると、Ｓ６に進み、端末側測位（複合）が行われる。Ｓ６の状態で、ＧＮＳＳ信号以外のセンサ情報利用不可、かつ基準局情報受信不可（ＮＷ環境悪化等）、あるいはＧＮＳＳ信号受信環境悪化になると、Ｓ１に進む。

　Ｓ５の状態で、クラウド環境利用可能な場合は、Ｓ４に進み、ＮＷ側測位（デッドレコニング）が行われる。Ｓ４の状態において、端末が、デッドレコニング可能なテパイスであり、かつクラウド環境利用不可であるとすると、Ｓ５に進む。

　Ｓ２の状態において、端末が、複合測位可能なテバイスである場合、Ｓ６に進み、端末側測位（複合）が行われる。Ｓ６の状態で、端末がＲＴＫ測位可能なデバイス、かつ、ＧＮＳＳ信号以外のセンサ情報利用が不可になると、Ｓ２に進む。

　Ｓ２の状態で、クラウド環境利用可能の場合は、Ｓ３に進み、ＮＷ側測位（ＲＴＫ）が行われる。Ｓ３の状態で、端末がＲＴＫ測位可能なデバイスで、クラウド環境利用不可、かつ、ＧＮＳＳ信号受信環境が良好な場合は、Ｓ２に進む。

　Ｓ３の状態で、複合測位向け各種センサ情報を利用可能な場合、Ｓ７に進み、ＮＷ側測位（複合）が行われる。Ｓ７の状態で、ＧＮＳＳ信号以外のセンサ情報が利用不可になると、Ｓ３に進む。

　Ｓ３の状態で、ＧＮＳＳ信号受信不可になると、Ｓ４に進む。Ｓ４の状態で、ＧＮＳＳ信号受信環境が良好になると、Ｓ３に進む。Ｓ６の状態において、クラウド環境が利用可能である場合、Ｓ７に進む。Ｓ６の状態において、ＧＮＳＳ信号受信が不可になると、Ｓ５に進む。

　Ｓ７の状態において、端末が複合測位可能なデパイスであり、かつクラウド環境利用不可である場合は、Ｓ６に進む。Ｓ７の状態で、ＧＮＳＳ信号受信不可の場合は、Ｓ４に進む。Ｓ４の状態で、ＧＮＳＳ信号受信可能になり、かつ複合測位向け各種センサ情報が利用可能な場合は、Ｓ７に進む。

　図１４を参照して、ＮＷ側での複合測位が不適な場合（ＮＷ帯域逼迫、遅延の増大）における状態遷移例を説明する。本例での優先度は、下記のとおりである。

　・端末側測位＜ＮＷ側測位
　・端末側測位について
　デッドレコニング＜コード＜ＲＴＫ＜複合
　・ＮＷ側測位について
　デッドレコニング＜複合＜ＲＴＫ
　以下では、図１３を参照して説明した遷移と異なる点を説明する。図１３において存在するが、図１４において存在しない矢印線の遷移は行われない。

　図１４の例では、Ｓ７のＮＷ側測位（複合）から開始する。Ｓ７の状態において、端末／ＮＷ側の環境及び状況変化に伴い、複合測位向けセンサ情報等が利用不可になる、あるいは、処理遅延等の要件が不満足になると、Ｓ３に進む。

　図１５を参照して、ＮＷ側での測位が不適な場合（遅延の増大、ＮＷ断、ＮＷ側リソース逼迫）における状態遷移例を説明する。本例での優先度は、下記のとおりである。

　・端末側測位＞ＮＷ側測位
　・端末側測位について
　デッドレコニング＜コード＜ＲＴＫ＜複合
　・ＮＷ側測位について
　デッドレコニング＜複合＜ＲＴＫ
　以下では、図１３を参照して説明した遷移と異なる点を説明する。図１３において存在するが、図１５において存在しない矢印線の遷移は行われない。図１５の例では、Ｓ７から開始する。Ｓ７からＳ３への遷移の条件、Ｓ３からＳ１への遷移の条件、Ｓ３からＳ２への遷移の条件、Ｓ４からＳ５への遷移の条件が図１３で説明した遷移と異なるので、これらについて、以下に示す。

　Ｓ７からＳ３への遷移の条件：
　端末／ＮＷ側の環境および状況変化に伴い複合測位向けセンサ情報等の利用が不可になる、あるいは、処遅遅延等の要件が不満足になる。

　Ｓ３からＳ１への遷移の条件：
　端末／ＮＷ側の環境および状況変化に伴い処運遅延等の要件が不満足になる、あるいは、非効率性が増大し、かつＧＮＳＳ信号受信環境が悪化する。

　Ｓ３からＳ２への遷移の条件：
　「端末／ＮＷ側の環境および状況変化に伴い処理遅延等の要件が不満足になる、あるいは、非効率性が増大する」、かつ、端末がＲＴＫ測位可能なテパイスであり、かつ、ＧＮＳＳ信号受信環境が良好である。

　Ｓ４からＳ５への遷移の条件：
　「端末／ＮＷ側の環境および状況変化に伴い処理遅延等の要件が不満足になる、あるいは、非効率性が増大する」、かつ、端末がデッドレコニング可能なテバイスであり、かつ、ＧＮＳＳ信号が受信不可である。

　（端末／ＮＷ側リソース状況に応じた判断例）
　次に、測位演算方式判断部１１０が、リソース状況に変化があった場合に測位演算する場所／方式を変更する処理フローの例を、図１６を参照して説明する。初期設定もこのフローの通り行われる。図１６のフローでは、リソース状況として電力状況Ｐ、Ｗ、Ｍを使用し、ＮＷ品質としてＴ、ｔを使用する。

　Ｓ５０１において、測位演算方式判断部１１０は、記憶部１２０に格納されているＮＷ品質（スループット：Ｔ、遅延：ｔ）、電力状況（端末側利用可能電力量：Ｐ、単位時間当たりの端末側電力消費量：Ｗ、次回端末保守までの時間：Ｍ）を参照する。なお、ＮＷ品質は、例えば、測位対象である端末と、測位演算機能を持つ制御装置１００との間のＮＷ品質である。

　Ｓ５０２において、測位演算方式判断部１１０は、「Ｗ≦Ｗ_ｔｈ」であるか否かを判断する。ここで、Ｗ_ｔｈは、端末保守（電池交換／寿命）を考慮して任意に設定する単位時間当たりの電力消費量の閾値である。Ｓ５０２の判断結果がＹｅｓであればＳ５０３に進み、ＮｏであればＳ５０７に進む。

　Ｓ５０３において、測位演算方式判断部１１０は、「Ｐ－Ｍ×Ｗ≧Ｐ_ｔｈ１」であるか否かを判断する。ここで、Ｐ_ｔｈ１は、端末保守（電池交換／寿命）を考慮して任意に設定する電力残量の閾値である。基本的にはＰ≦Ｐ_ｔｈ１の発生を回避するように運用する。Ｓ５０３の判断結果がＹｅｓであればＳ５０４に進み、ＮｏであればＳ５０７に進む。

　Ｓ５０４において、測位演算方式判断部１１０は、「Ｐ－Ｍ×Ｗ≧Ｐ_ｔｈ２」であるか否かを判断する。ここで、Ｐ_ｔｈ２は、端末保守（電池交換／寿命）を考慮して任意に設定する電力残量の閾値である。Ｐ≦Ｐ_ｔｈ２の発生時には運用者にアラートを上げて旱期対処を促す運用を行う。

　Ｓ５０４の判断結果がＹｅｓであればＳ５０５に進み、ＮｏであればＳ５０６に進む。Ｓ５０５において、測位演算方式判断部１１０は、既定の要件／優先度に基づき測位演算方式を決定する。つまり、これまでに説明した方法のとおりに測位演算方式を決定する。

　Ｓ５０６において、測位演算方式判断部１１０は、要件／優先度（Ａ）に基づき測位演算方式を決定する。「要件／優先度（Ａ）」は、電力消費増加発生回避のため既定の要件／優先度から、選択候補として端末側複合測位を除外したものを意味する。

　Ｓ５０７において、測位演算方式判断部１１０は、「Ｔ≧Ｔ_ｔｈかつｔ≦ｔ_ｔｈ」であるか否かを判断する。Ｔ_ｔｈ、ｔ_ｔｈはそれぞれ予め定めた閾値である。

　Ｓ５０７の判断結果がＹｅｓであればＳ５０８に進み、ＮｏであればＳ５０９に進む。Ｓ５０８において、測位演算方式判断部１１０は、要件／優先度（Ｂ）に基づき測位演算方式を決定する。「要件／優先度（Ｂ）」は、電力消費低減のため既定の要件／優先度から、ＮＷ側測位優先としたものである。

　Ｓ５０９において、測位演算方式判断部１１０は、要件／優先度（Ｃ）に基づき測位演算方式を決定する。「要件／優先度（Ｃ）」は、電力消費／ＮＷソース負担低減のため、既定の要件／優先度から、ＮＷ側ＲＴＫ測位優先としたものである。

　（端末位置や密集性に応じた判断例）
　次に、地図上での端末位置や密集性に応じて測位演算方式を決定する例を説明する。図１７に、測位演算方式判断部１１０が、密集性に変化があった場合に測位演算の場所／方式を変更する様子を示す。初期設定に関しても同様である。「自端末」は測位対象である。

　図１７の左側の部分において、自端末位置から半径ｒ（ｍ）圏内に存在する他端末数がｎ（台）である。自端末と第一近接（最も近い）端末との距離をｄ_１（ｍ）とし、自端末と第二近接（２番目に近い）端末との距離をｄ_２（ｍ）とする。これらの変数は、図１８のフローでも使用する。

　図１７の左側に示す部分において、測位演算方式判断部１１０は、ｎが増加する、又は、ｄ_１が減少することを検知すると、ＲＴＫ測位を複合測位に変更すると判断する。図１７の右側に示す混雑領域に自端末が入る場合、測位演算方式判断部１１０は、例えば、端末側ＲＴＫ測位からＮＷ側複合測位に変更する。つまり、測位演算方式判断部１１０は、境界跨ぎを検知して測位演算方式を変更する。なお、境界跨ぎを検知することには、過去の位置遷移や移動計画から未来時点での境界跨ぎが想定される場合を含む。

　測位演算方式判断部１１０が、密集性に変化があった場合に場所／方式を変更する処理フローを図１８に示す。初期設定もこのフローの通り行われる。図１８のフローでは、密集性ｄ（距離）、ｎ（台数）を判断して測位方式を決定する。また、要件／優先度（既定）は下記のとおりであるとする。

　・端末側測位＞ＮＷ側測位
　・靖末側測位について
　デッドレコニング＜コード＜複合＜ＲＴＫ
　・ＮＷ側測位について
　デッドレコニング（＜コード）＜複合＜ＲＴＫ
　Ｓ６０１において、測位演算方式判断部１１０は、記憶部１２０に格納されている地図上での自端末位置、Ｇｅｏｆｅｎｃｉｎｇ設定、ｎ、ｄ_１、ｄ_２を参照する。Ｓ６０２において、測位演算方式判断部１１０は、自端末の位置が、Ｇｅｏｆｅｎｃｅ内か否かを判断する。Ｓ６０２の判断結果がＹｅｓであればＳ６０３に進み、ＮｏであればＳ６０４に進む。

　Ｓ６０３において、測位演算方式判断部１１０は、Ｇｅｏｆｅｎｃｉｎｇ設定に規定されている要件／優先度に基づき測位演算方式を決定する。

　Ｇｅｏｆｅｎｃｉｎｇ設定について、例えば、地理的環境に応じた高精度測位実施のため下記の設定とする。

　・ＮＷ側測位のみ
　・ＮＷ側測位について
　ＲＴＫ＜複合
　Ｓ６０４において、測位演算方式判断部１１０は、「ｄ_１≦ｄ_ｔｈ１」が成立するか否かを判断する。ｄ_ｔｈ１及び後述するｄ_ｔｈ２はいずれも、端末の混雑／密集性を考慮して任意に設定する端末間距離の閾値である。後述するｎ_ｔｈは、端末の混雑／密集性を考慮して任意に設定する空間内の端末数の閾値である。Ｓ６０４の判断結果がＹｅｓであればＳ６０５に進み、ＮｏであればＳ６０８に進む。

　Ｓ６０５において、測位演算方式判断部１１０は、「ｄ_２≦ｄ_ｔｈ２」が成立するか否かを判断する。Ｓ６０５の判断結果がＹｅｓであればＳ６０６に進み、ＮｏであればＳ６０７に進む。

　Ｓ６０６において、測位演算方式判断部１１０は、ｄ_１≦ｄ_ｔｈ１かつｄ_２≦ｄ_ｔｈ２時に適用される要件／優先度に基づき測位演算方式を決定する。この場合、例えば、周囲環境（混雑／密集性）に応じた高精度測位実施のため下記に基づき決定する。

　・端末側測位＜ＮＷ側測位
　・端末側測位について
　ＲＴＫ＜複合
　・ＮＷ側測位について
　ＲＴＫ＜複合
　Ｓ６０７において、測位演算方式判断部１１０は、ｄ_１≦ｄ_ｔｈ１かつｄ_２＞ｄ_ｔｈ２時に適用される要件／優先度に基づき測位演算方式を決定する。この場合、例えば、周囲環境（混雑／密集性）に応じた高精度測位実施のため下記に基づき決定する。

　・端末側測位＜ＮＷ側測位
　・端末側測位について
　ＲＴＫ＜複合
　・ＮＷ側測位について
　デッドレコニング＜ＲＴＫ＜複合
　Ｓ６０８において、測位演算方式判断部１１０は、「ｎ≧ｎ_ｔｈ」が成立するか否かを判断する。Ｓ６０８の判断結果がＹｅｓであればＳ６０９に進み、ＮｏであればＳ６１０に進む。

　Ｓ６０９において、測位演算方式判断部１１０は、ｎ≧ｎ_ｔｈ時に適用される要件／優先度に基づき測位演算方式を決定する。この場合、例えば、周囲環境（混雑／密集性）に応じた高精度測位実施のため下記に基づき決定する。

　・端末側測位＜ＮＷ側測位
　・端末側測位について
　デッドレコニング＜コード＜複合＜ＲＴＫ
　・ＮＷ側測位について
　デッドレコニング（＜コード）＜複合＜ＲＴＫ
　Ｓ６１０において、測位演算方式判断部１１０は、既定の要件／優先度に基づき測位演算方式を決定する。

　（遅延時間算出と測位演算機能）
　遅延時間算出と測位演算機能について説明する。図１９に示すように、衛星ａ，ｂ、端末ｕ（測位対象である受信機）、基準局ｓがある状況を想定する。また、測位演算機能部Ｆ、ＮＷ側機能部６が存在する。なお、図１９に示す、衛星ａ、ｂ、端末ｕ、基準局ｓを有する構成、及び、以下で数式を用いて説明している搬送波位相観測値Φ、搬送波位相の二重位相差の計算方法は、「https://www.denshi.e.kaiyodai.ac.jp/kubo/isejima.pdf」に開示されている。

　ＧＮＳＳ信号（端末受信）に関するｕ－Ｆ間の情報送受信にかかる時間をｔ_１とし、ＧＮＳＳ信号（基準局受信）に関するｓ－Ｆ間の情報送受信にかかる時間をｔ_２とする。情報送受信時間差Δｔ＝ｔ_２－ｔ_１である。

　ＮＷ側機能部６において、ＮＷ／サーバリソースの状態監視で得られるΔｔをＦに通知して測位演算に活用する。つまり、ＮＷ情報を活用するシステムを実現する。

　搬送波位相観測値Φは下記のように表される。

　Φ＝ρ＋ｃ（ｄｔ－ｄＴ）－Ｉ＋Ｔ十λＮ＋ε
　各記号の意味は下記のとおりである。

　Φ：搬送波位相（ｍ）
　ρ：衛星と受信機間の幾何学距離（ｍ）
　ｃ：光速（ｍ／ｓ）
　ｄｔ：受信機時計誤差（ｓ）
　ｄＴ：衛星時計誤差（ｓ）
　Ｉ：電離層遅延量（ｍ）
　Ｔ：対流圏遅延量（ｍ）
　λ：波長（ｍ）
　Ｎ：搬送波位相バイアス（ｃｙｃｌｅ）
　ε：ノイズ（ｍ）
　搬送波位相の二重位相差は下記のように表される。

　衛星時計補正（ｔ_２＞ｔ_１の時）は、下記で算出される。

　本実施の形態では、Δｔの部分をリアルタイムに変動させていく。つまり、遅延した結果を測位演算機能部Ｆに反映させることができる。

　図１９における測位演算機能部Ｆは、端末側の機能であってもよいし、ＮＷ側機能であってもよい。また、ＮＷ側機能部６は、制御装置１００に相当する。制御装置１００に測位演算機能部Ｆが含まれていてもよい。また、Δｔの算出、及びΔｔのＦへの通知は、測位演算方式判断部１１０が行うこととしてもよい。

　（システムの構成例）
　本実施の形態で説明した制御装置１００は、図２０に示すような位置情報流通基盤で用いられてもよい。図２０におけるコントローラ１００が制御装置１００に相当する。また、図２０では、一例として、車両が送信する映像の制御を行う例を示している。なお、図２０に示す略称について、NWはNetworkの略であり、EIDはEndpoint Identifierｍの略であり、CPEはCustomer Premises Equipmentの略であり、NMEAは、NMEA0183の略であり、NMEA自体はNational Marine Electronics Associationの略である。

　（ハードウェア構成例）
　上述した制御装置１００は、例えば、コンピュータに、本実施の形態で説明する処理内容を記述したプログラムを実行させることにより実現可能である。このコンピュータは、物理的なコンピュータであってもよいし、クラウド上の仮想マシンであってもよい。

　すなわち、制御装置１００は、コンピュータに内蔵されるＣＰＵやメモリ等のハードウェア資源を用いて、当該装置で実施される処理に対応するプログラムを実行することによって実現することが可能である。上記プログラムは、コンピュータが読み取り可能な記録媒体（可搬メモリ等）に記録して、保存したり、配布したりすることが可能である。また、上記プログラムをインターネットや電子メール等、ネットワークを通して提供することも可能である。

　図２１は、上記コンピュータのハードウェア構成例を示す図である。図２１のコンピュータは、それぞれバスＢＳで相互に接続されているドライブ装置１０００、補助記憶装置１００２、メモリ装置１００３、ＣＰＵ１００４、インタフェース装置１００５、表示装置１００６、入力装置１００７、出力装置１００８等を有する。

　当該コンピュータでの処理を実現するプログラムは、例えば、ＣＤ－ＲＯＭ又はメモリカード等の記録媒体１００１によって提供される。プログラムを記憶した記録媒体１００１がドライブ装置１０００にセットされると、プログラムが記録媒体１００１からドライブ装置１０００を介して補助記憶装置１００２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１００１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１００２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

　メモリ装置１００３は、プログラムの起動指示があった場合に、補助記憶装置１００２からプログラムを読み出して格納する。ＣＰＵ１００４は、メモリ装置１００３に格納されたプログラムに従って、制御装置１００に係る機能を実現する。インタフェース装置１００５は、ネットワーク等に接続するためのインタフェースとして用いられる。表示装置１００６はプログラムによるＧＵＩ（Ｇｒａｐｈｉｃａｌ　Ｕｓｅｒ　Ｉｎｔｅｒｆａｃｅ）等を表示する。入力装置１００７はキーボード及びマウス、ボタン、又はタッチパネル等で構成され、様々な操作指示を入力させるために用いられる。出力装置１００８は演算結果を出力する。

　（実施の形態の効果）
　本実施の形態に係る技術により、ＮＷ側で管理する情報を活用してプロアクティブに測位演算方式を変更（測位演算自体にＮＷ情報を考慮することを含む）することができるので、要件を満たしつつリソースを効率的に利用することが可能となる。

　（付記）
　以上の実施形態に関し、更に以下の付記項を開示する。
（付記項１）
　測位対象に対して使用する測位演算方式を決定する制御装置であって、
　測位演算方式に要求される要件、及び、測位演算方式の優先度を入力する入力部と、
　実施可能であり、かつ、前記要件を満たす１又は複数の測位演算方式の中から、前記優先度に基づいて、前記測位対象に対して使用する測位演算方式を決定する決定部と
　を備える制御装置。
（付記項２）
　前記優先度は、ＮＷ側複合測位、ＮＷ側ＲＴＫ測位、ＮＷ側デッドレコニング測位、端末側複合測位、端末側コード測位、端末側ＲＴＫ測位、端末側デッドレコニング測位、及び、測位不能のうちのいずれか複数又はこれら全部についての優先度である
　付記項１に記載の制御装置。
（付記項３）
　前記決定部は、前記測位対象である端末におけるリソース状況、又は、ＮＷ品質に基づいて、前記測位対象に対して使用する測位演算方式を決定する
　付記項１又は２に記載の制御装置。
（付記項４）
　前記決定部は、前記測位対象が存在する場所の密集性に基づいて、前記測位対象に対して使用する測位演算方式を決定する
　付記項１ないし３のうちいずれか１項に記載の制御装置。
（付記項５）
　前記決定部は、基準局から測位演算機能部への情報送信にかかる時間と、ＧＮＳＳ信号を受信する端末から前記測位演算機能部への情報送信にかかる時間との差分を計算し、当該差分を前記測位演算機能部に通知する
　付記項１ないし４のうちいずれか１項に記載の制御装置。
（付記項６）
　測位対象に対して使用する測位演算方式を決定する制御装置が実行する測位演算方式決定方法であって、
　測位演算方式に要求される要件、及び、測位演算方式の優先度を入力する入力ステップと、
　実施可能であり、かつ、前記要件を満たす１又は複数の測位演算方式の中から、前記優先度に基づいて、前記測位対象に対して使用する測位演算方式を決定する決定ステップと
　を備える測位演算方式決定方法。
（付記項７）
　コンピュータを、付記項１ないし５のうちいずれか１項に記載の制御装置における各部として機能させるためのプログラムを記憶した非一時的記憶媒体。

　以上、本実施の形態について説明したが、本発明はかかる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

１　基準局
２　移動局（端末）
３　エッジ／クラウドサーバ
４　情報基盤
５　ネットワーク
６　ＮＷ側機能部
７　ＮＷ側測位演算部
８　端末側機能部
９　端末側測位演算部
１００　制御装置
１１０　測位演算方式判断部
１２０　記憶部
１３０　情報取得部
１４０　測位演算方式制御部
１０００　ドライブ装置
１００１　記録媒体
１００２　補助記憶装置
１００３　メモリ装置
１００４　ＣＰＵ
１００５　インタフェース装置
１００６　表示装置
１００７　入力装置
１００８　出力装置

Claims

　測位対象に対して使用する測位演算方式を決定する制御装置であって、
　測位演算方式に要求される要件、及び、測位演算方式の優先度を入力する入力部と、
　実施可能であり、かつ、前記要件を満たす１又は複数の測位演算方式の中から、前記優先度に基づいて、前記測位対象に対して使用する測位演算方式を決定する決定部と
　を備える制御装置。
　前記優先度は、ＮＷ側複合測位、ＮＷ側ＲＴＫ測位、ＮＷ側デッドレコニング測位、端末側複合測位、端末側コード測位、端末側ＲＴＫ測位、端末側デッドレコニング測位、及び、測位不能のうちのいずれか複数又はこれら全部についての優先度である
　請求項１に記載の制御装置。
　前記決定部は、前記測位対象である端末におけるリソース状況、又は、ＮＷ品質に基づいて、前記測位対象に対して使用する測位演算方式を決定する
　請求項１に記載の制御装置。
　前記決定部は、前記測位対象が存在する場所の密集性に基づいて、前記測位対象に対して使用する測位演算方式を決定する
　請求項１に記載の制御装置。
　前記決定部は、基準局から測位演算機能部への情報送信にかかる時間と、ＧＮＳＳ信号を受信する端末から前記測位演算機能部への情報送信にかかる時間との差分を計算し、当該差分を前記測位演算機能部に通知する
　請求項１に記載の制御装置。
　測位対象に対して使用する測位演算方式を決定する制御装置が実行する測位演算方式決定方法であって、
　測位演算方式に要求される要件、及び、測位演算方式の優先度を入力する入力ステップと、
　実施可能であり、かつ、前記要件を満たす１又は複数の測位演算方式の中から、前記優先度に基づいて、前記測位対象に対して使用する測位演算方式を決定する決定ステップと
　を備える測位演算方式決定方法。
　コンピュータを、請求項１ないし５のうちいずれか１項に記載の制御装置における各部として機能させるためのプログラム。