JP2021100222A - 端末装置、アプリケーションサーバ、受信方法及び送信方法 - Google Patents

Abstract

【課題】スタジアムなどの大規模施設の観客席から５Ｇを利用したＡＲサービスを視聴する場合のCapturing及びImage Recognitionの精度向上に寄与する。【解決手段】端末装置は、トランシーバと、カメラと、ディスプレイと、プロセッサと、を有する。プロセッサは、ビームフォーミングされて基地局から送信された複数の同期信号の中から無線品質が所定の閾値を満たす第１の同期信号を決定し、基地局に報告する。プロセッサは、補正情報により補正された仮想オブジェクトを、カメラの撮像画像に重畳させてディスプレイに表示する。補正情報は、第１の同期信号がカバーするエリアの実オブジェクトに対する位置を示すための情報である。補正情報は、エリアにおいてディスプレイに表示させる仮想オブジェクトの向きおよび実オブジェクトからエリアまでの距離に関する情報を含む。【選択図】図１

Description

本開示は、端末装置、アプリケーションサーバ、受信方法及び送信方法に関する。

Augmented Reality（ＡＲ）及びVirtual Reality（ＶＲ）を用いたサービスが第５世代移動体通信システム（５Ｇ ＮＲ）のキラーコンテンツとして期待されている。例えば、ＡＲ技術であれば、実空間の画像に撮像された実オブジェクトに対して、テキスト、アイコン、またはアニメーション等の様々な態様の仮想的なコンテンツ（以降では、「仮想オブジェクト」とも称する）を重畳してユーザに提示することが可能となる。非特許文献１や非特許文献２は、ＡＲ及びＶＲを用いたサービス（e.g., ＡＲ／ＶＲゲーム）のユースケース及び（潜在的な）要求条件を開示する。

実オブジェクトに仮想オブジェクトを重畳する技術に関し、非特許文献３及び特許文献１は、Marker-based recognitionとMaker-less recognitionの２つの方法を開示する。Marker-based recognitionの場合、マーカの向きや模様に応じて当該マーカに対するカメラ（撮像部）の相対的な方向を推定できる。また、マーカのサイズが既知の場合は、マーカとカメラ（撮像部）との間の距離も推定できる。Maker-less recognition（自然特徴トラッキング）の場合、対象物体上の顕著な点特徴（特徴点（interest point）又はkey point）に応じて、対象物体との相対的な位置や方向を推定できる。Maker-less recognitionの技術の例として、ＳＬＡＭ（simultaneous localization and mapping）がある。ＳＬＡＭは、カメラ等の撮像部、各種センサ、エンコーダ等を利用することにより、自己位置推定と環境地図の作成とを並行して行う技術である。より具体的には、撮像部により撮像された動画像に基づき、撮像された被写体の３次元形状を逐次的に復元する。そして、その復元結果を、撮像部の位置及び姿勢の検出結果と関連付けることで、周囲の環境の地図の作成と、当該環境における撮像部の位置及び姿勢の推定（認識）とが行われる。

さらに、非特許文献３及び特許文献１は、カメラでの撮像に、各種センサ（e.g., Global Positioning System（ＧＰＳ）、 Ｗｉ−Ｆｉ、Bluetooth（登録商標）、モバイルネットワークなどのワイヤレスネットワーキング、磁力計（電子コンパス）、ジャイロスコープ、リニア加速度計、）などを組み合わせて、Capturing、Image Recognitionの精度を向上させる技術も開示している。

3GPP TR 22.842, V17.1.0 (2019-09) 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Study on Network Controlled Interactive Services (Release 17) 3GPP TS 22.261 v17.0.1 (2019-10) 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects ; Service requirements for next generation new services and markets (Release 17) Dieter Schmalstieg他、「ARの教科書」、株式会社マイナビ出版、2018年7月30日発行

国際公開第２０１７／１８３３４６号

ＡＲ／ＶＲを用いたサービスは、スタジアム、コンサートホールのような大規模施設での提供が検討されている。例えば、ＡＲスポーツ、ＡＲゲームの大会などのＡＲイベントがそのスタジアムで開催され、観客はそのＡＲイベントをＡＲデバイス（スマートフォン、AR Head-Mounted Display（ＡＲＨＭＤ）など）を介して視聴（観戦）するかもしれない。

スタジアムのような大規模施設では、観客の一体感醸成によるユーザエクスペリエンス向上を目的として、全ての観客が同一対象をリアルタイムで視聴（観戦）するなど、観客の体験が共通化されることが望ましい。

このようなケースでは、観客は異なる位置（座席）から同一対象（実オブジェクトと仮想オブジェクト）を視聴（観戦）することになる。各観客は互いに異なる位置（座席）にいるため、同一対象（実オブジェクトと仮想オブジェクト）を視聴（観戦）していても、各観客が視認できる対象（実オブジェクトと仮想オブジェクト）の向き（視聴方向）はそれぞれ異なる。したがって、異なる位置の観客に適切なＡＲ画像を提供するために、実世界の物体（実オブジェクト）に仮想物体（仮想オブジェクト）を適切に重畳させる技術が必要となる。この技術は、Capturing、Image Recognition、Rendering and Output/Emittingを含む。このうち、Capturing、Image Recognitionは、例えば位置合わせ、キャリブレーション、トラッキングの処理を含んでもよい。

しかしながら、ＡＲを用いたサービスの提供場所として想定される大規模施設（e.g., スタジアム、コンサートホール）においては、上述の先行技術を用いたCapturing及びImage Recognitionでは不十分かもしれない。

例えば、スタジアムのような広い環境では、観客席から位置合わせの基準となる対象物体（e.g., マーカや特徴点）までの距離が遠いことが想定される。さらに、観客の装着負荷軽減の観点から端末（ＡＲデバイス）は軽量且つ小型であることが望ましい。その場合、ＡＲデバイスに搭載できるカメラの性能（e.g., レンズサイズやセンササイズ）やデバイス上での許容処理負荷（e.g., プロセッサの処理能力やバッテリーの許容量）が制限されるかもしれない。したがって、カメラの性能や許容処理負荷が制限されたＡＲデバイスでは、観客席から距離が遠い位置に配置された位置合わせの基準物（Capturing及びImage Recognitionのための基準となる対象物体。例えばマーカや特徴点）を使ったCapturing及びImage Recognitionを適切に行えないかもしれない。

そこで、本開示では、スタジアムなどの大規模施設の観客席から５Ｇを利用したＡＲサービスを視聴する場合のCapturing及びImage Recognitionの精度向上に寄与する端末装置、アプリケーションサーバ、受信方法及び送信方法を提供する。

なお、上記課題又は目的は、本明細書に開示される複数の実施形態が解決し得、又は達成し得る複数の課題又は目的の１つに過ぎない。

本開示によれば、端末装置が提供される。端末装置は、トランシーバと、実オブジェクトを撮像するためのカメラと、前記カメラが撮像した前記実オブジェクトに仮想オブジェクトを重畳させる拡張現実画像を表示するためのディスプレイと、プロセッサと、を有する。

前記プロセッサは、互いに異なる方向にビームフォーミングされて基地局から送信された複数の同期信号の少なくとも１つを、前記トランシーバを介して受信するように構成される。前記プロセッサは、受信した少なくとも１つの前記同期信号の中から、無線品質が所定の閾値を満たす第１の同期信号を決定するように構成される。前記プロセッサは、前記第１の同期信号を前記基地局へ報告するために、前記第１の同期信号に対応するランダムアクセスオケージョンを用いてランダムアクセスプリアンブルを送信するように構成される。前記プロセッサは、前記ランダムアクセスプリアンブルの送信を含むランダムアクセス処理手順の完了後に、アプリケーションサーバから前記拡張現実画像に関する情報を受信するように構成される。

前記拡張現実画像に関する前記情報は、前記拡張現実画像の表示に用いる補正情報、または、前記補正情報に基づいて前記実オブジェクトに対する前記仮想オブジェクトの位置合わせが行われた拡張現実画像データである。前記拡張現実画像に関する前記情報が前記補正情報である場合、前記プロセッサは、前記補正情報を使用して前記実オブジェクトに対する前記仮想オブジェクトの位置合わせを行って前記拡張現実画像を生成して前記ディスプレイに出力する。前記拡張現実画像に関する前記情報が前記補正情報に基づいて前記実オブジェクトに対する前記仮想オブジェクトの位置合わせが行われた前記拡張現実画像データである場合、前記プロセッサは、受信した前記拡張現実画像データに基づき拡張現実画像を前記ディスプレイに出力する。

前記補正情報は、前記ビームフォーミングされて送信された前記第１の同期信号がカバーするエリアの前記実オブジェクトに対する位置を示すための情報である。前記補正情報は、前記エリアにおいて前記ディスプレイに表示させる前記仮想オブジェクトの向きおよび前記実オブジェクトから前記エリアまでの距離に関する情報を含む。

本開示の第１の実施形態に係る情報処理の一例を説明するための図である。 従来のＳＳＢの伝送パターンを示す図である。 レンダリングに関するレンダリングサーバとＡＲ／ＶＲクライアントのイメージ図である。 本開示の第１の実施形態に係る通信システムの論理的構成例を示す図である。 本開示の第１の実施形態に係る端末装置の構成の一例を示すブロック図である。 本開示の第１の実施形態に係る基地局の構成の一例を示すブロック図である。 本開示の第１の実施形態に係るアプリケーションサーバの構成の一例を示すブロック図である。 本開示の第１の実施形態に係る通信システムの動作例を示すシーケンス図である。 本開示の第１の実施形態に係るビームと座席グループとの関連付けを説明するための図である。 本開示の第１の実施形態に係るビームと座席グループとの関連付けを説明するための図である。 本開示の第１の実施形態に係る補正情報を説明するための図である。 本開示の第１の実施形態の変形例１に係る通信システムの動作例を示すシーケンス図である。 本開示の第１の実施形態の変形例２に係る通信システムの動作例を示すシーケンス図である。 Point Cloudの構成を説明するための図である。 本開示の第２の実施形態に係る空間分割の方法、および、空間位置情報について説明するための図である。 アプリケーションサーバ（MPDファイルサーバ）が、部分G-PCCストリームが格納されたファイルを生成する生成処理を説明するフローチャートである。 端末装置（MPEG-DASHクライアント）が、部分G-PCCストリームが格納されたファイルを再生する再生処理を説明するフローチャートである。 Edge Computingが適用されたアプリケーションアーキテクチャの一例を示す図である。 本開示の第３の実施形態に係る通信システムの処理手順の一例を示すシーケンス図である。 本開示の第３の実施形態に係る通信システムの処理手順の一例を示すシーケンス図である。 手順E-CID Measurement Initiationを示すシーケンス図である。 手順E-CID Measurement Reportを示すシーケンス図である。 手順OTDOA Information Exchangeを示すシーケンス図である。

以下に添付図面を参照しながら、本開示の例示的な実施の形態について詳細に説明する。なお、本明細書および図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。

また、本明細書及び図面において、実質的に同一の機能構成を有する要素を、同一の符号の後に異なるアルファベットまたは数字を付して区別する場合もある。例えば、実質的に同一の機能構成を有する複数の要素を、必要に応じてＵＥ１０Ａ、１０Ｂのように区別する。ただし、実質的に同一の機能構成を有する複数の要素の各々を特に区別する必要がない場合、同一符号のみを付する。例えば、ＵＥ１０Ａ、１０Ｂを特に区別する必要が無い場合には、単にＵＥ１０と称する。

以下に説明される複数の実施形態（実施例を含む）は、各々が独立に実施されることが可能である。一方で、以下に説明される複数の実施形態は少なくとも一部が他の実施形態の少なくとも一部と適宜組み合わせて実施されてもよい。これら複数の実施形態は、互いに異なる新規な特徴を含み得る。したがって、これら複数の実施形態は、互いに異なる目的又は課題を解決することに寄与し得、互いに異なる効果を奏し得る。

以下に説明される複数の例示的な実施形態のいくつかは、５Ｇ ＮＲを主な対象として説明される。しかしながら、これらの実施形態は、５Ｇ ＮＲに限定されるものではなく、他のモバイル通信ネットワーク又はシステム、例えば３ＧＰＰ ＬＴＥ（Long Term Evolution）（LTE-Advanced及びLTE-Advanced Proを含む）、３ＧＰＰ ＵＭＴＳ（Universal Mobile Telecommunications System）等に適用されてもよい。

ＮＲは、ＬＴＥの次の世代（第５世代）の無線アクセス技術（ＲＡＴ：Radio Access Technology）である。ＮＲは、ｅＭＢＢ（Enhanced Mobile Broadband）、ｍＩｏＴ（Massive Internet of Things）（又はｍＭＴＣ（Massive Machine Type Communications））及びＵＲＬＬＣ（Ultra-Reliable and Low Latency Communications）を含む様々なユースケースに対応できる無線アクセス技術である。ＮＲは、これらのユースケースにおける利用シナリオ、要求条件、及び配置シナリオなどに対応する技術フレームワークを目指して検討されている。ＮＲには、ＮＲＡＴ（New Radio Access Technology）及びＦＥＵＴＲＡ（Further EUTRA）が含まれるものとする。

なお、説明は以下の順序で行うものとする。
１．第１の実施形態
１．１．本開示の第１の実施形態に係る情報処理の概要
１．２．基地局とＵＥとの間の無線通信の概要
１．３．通信システムの構成例
１．３．１．通信システムの全体構成例
１．３．２．端末装置の構成例
１．３．３．基地局の構成例
１．３．４．アプリケーションサーバの構成例
１．４．通信システムの動作
１．５．変形例
１．５．１．変形例１
１．５．２．変形例２
２．第２の実施形態
３．第３の実施形態
４．第４の実施形態
５．その他の実施形態
６．補足

＜１．第１の実施形態＞
＜１．１．本開示の第１の実施形態に係る情報処理の概要＞
図１は、本開示の第１の実施形態に係る情報処理の一例を説明するための図である。第１の実施形態に係る情報処理は、例えばスタジアムＳＴのように大規模施設の観客席のユーザが所持するＵＥ１０と、ＵＥ１０と通信を行う基地局２０と、ユーザに提示するＡＲ（拡張現実）画像データを生成するアプリケーションサーバ３０（不図示）と、を含む通信システムで行われるが、これには限られない。

第１の実施形態に係る情報処理では、アプリケーションサーバ３０が生成した拡張現実画像データを基地局２０がＵＥ１０に送信し、ＵＥ１０のディスプレイに表示する処理が行われる。以下、拡張現実画像をＡＲ画像という場合がある。ＵＥ１０は、例えばＡＲＨＭＤの一種であるＡＲグラスであり、スタジアムＳＴの観客席でＡＲグラスを装着したユーザにＡＲ画像を提示する。ＡＲ画像には、スタジアムＳＴのグラウンドにある実オブジェクトＲ１に、仮想オブジェクトＶ１（ＡＲ画像データ）が重畳されている。ユーザは、ＡＲ画像を視聴することで、ＡＲスポーツやＡＲゲームの大会など、スタジアムＳＴで開催されているＡＲイベントを観戦したりＡＲイベントに参加したりすることができる。実オブジェクトＲ１は、グラウンド上のボール、人物といった移動体、あるいはグラウンドに設けられたマーカ等で有り得る。

ここで、スタジアムＳＴは、大規模施設であり、複数のユーザは、グラウンドを取り囲む観客席から同じ仮想オブジェクトＶ１を視聴することになる。そのため、各ユーザは、異なる位置から同一対象（実オブジェクトＲ１及び仮想オブジェクトＶ１）を視聴することになるが、対象を視聴する向き（視聴方向）は、ユーザごとに異なる。例えば、図１の例では、ＵＥ１０Ａを所持するユーザは、仮想オブジェクトＶ１を正面左側から視聴する。すなわち、ＵＥ１０Ａを所持するユーザの視聴方向Ｌ１は、仮想オブジェクトＶ１の正面左側から仮想オブジェクトＶ１に向かう方向である。一方、ＵＥ１０Ｂを所持するユーザは、仮想オブジェクトＶ１を正面右側から視聴する。すなわち、ＵＥ１０Ｂを所持するユーザの視聴方向Ｌ２は、仮想オブジェクトＶ１の正面右側から仮想オブジェクトＶ１に向かう方向である。

アプリケーションサーバ３０が、各ＵＥ１０に対して同じＡＲ画像データを生成すると、ＵＥ１０Ａ、１０Ｂは、視聴方向Ｌ１、Ｌ２が異なるのに、同じ方向から見た仮想オブジェクトＶ１（ＡＲ画像データ）を含むＡＲ画像をユーザに提示することになり、ユーザに違和感を与えてしまう恐れがある。

そのため、ユーザに違和感を与えないように、ユーザの視聴方向Ｌ１、Ｌ２に応じたＡＲ画像データを生成するためには、ユーザごと、すなわちＵＥ１０ごとに視聴方向に基づいて仮想オブジェクト（ＡＲ画像データ）を補正して実空間に重畳する必要がある。

ここで、例えばMarker-based recognitionやMarker-less recognitionなどの従来の手法では、ＡＲグラス（本実施形態のＵＥ１０に相当）に搭載されたカメラによってマーカや特徴点を検出することでユーザの視聴方向を検出する。しかしながら、スタジアムＳＴのような大規模施設では、マーカや特徴点のサイズが小さくなる可能性があり、ＡＲグラスでの検出が困難になる恐れがある。さらに、ユーザによるＡＲ画像データの長時間の視聴を考慮すると、ＡＲグラス（本実施形態のＵＥ１０に相当）の軽量性は重要なファクタの１つとなり得、高画質な撮像を可能にするカメラの搭載は難しいかもしれない。

そこで、本実施形態に係る情報処理では、基地局２０が形成する複数のビームの各々が届けられる位置と、当該位置からＡＲ画像データを視聴した場合に生成するＡＲ画像データを適切に重畳するためのＵＥ１０ごとに生成するための補正情報とを予め対応づけておく。これにより、ＵＥ１０の位置に応じて補正したＡＲ画像データ（以降では、補正ＡＲ画像データとも称する）をユーザに提示する。

具体的に、ステップＳ１で、基地局２０Ａは、ビームをスウィーピングさせながらＵＥ１０に対して同期信号を送信する。例えば図１では、基地局２０Ａは、複数のビームＢ１〜Ｂ３をそれぞれ異なる方向に向けて送信する。なお、基地局２０Ａが送信するビームの数は３つに限られず、２つであってもよく、４つ以上であってもよい。

ステップＳ２で、ＵＥ１０Ａは、基地局２０Ａから受信した同期信号の中から、無線品質（例えば受信レベル）が所定の閾値を満たす同期信号を決定し、決定した同期信号を送信してきたビームをベストビームに決定する。ＵＥ１０Ａは、決定したベストビームに関する情報を、基地局２０Ａに報告する。報告したベストビームに関する情報は、基地局２０Ａ等を介してアプリケーションサーバ３０まで提供される。

アプリケーションサーバ３０は、ＵＥ１０Ａが決定したベストビームに対応する補正ＡＲ画像データを生成する。当該補正ＡＲ画像データは、視聴方向Ｌ１からユーザがＡＲ画像データを視聴した場合に、適切な向きで仮想オブジェクトＶ１が実オブジェクトＲ１に重畳されるよう、予め関連付けられている。例えば、アプリケーションサーバ３０は、ベストビームに対応する補正情報に基づいてＡＲ画像データを補正することで補正ＡＲ画像データを生成し、基地局２０Ａを介してＵＥ１０Ａに送信する。

ステップＳ３で、ＵＥ１０Ａは、例えば自装置に搭載されたカメラの撮像画像（実オブジェクト）に補正ＡＲ画像データを重畳することで、ベストビームに対応するユーザの視線方向に基づいたＡＲ画像Ｍ１を生成する。図１の例では、ＵＥ１０Ａは、ＡＲ画像Ｍ１として、視聴方向Ｌ１から仮想オブジェクトＶ１を見た画像をディスプレイに表示する。

また、ＵＥ１０Ｂは、同様にして基地局２０Ｂが送信する複数のビームの中からベストビームを決定し、アプリケーションサーバ３０は、ベストビームに対応する補正情報に基づき、補正ＡＲ画像データを生成する。ＵＥ１０Ｂは、実オブジェクトに補正ＡＲ画像データの仮想オブジェクトＶ１を重畳することで、図１に示すように、ＡＲ画像Ｍ２（視聴方向Ｌ２から仮想オブジェクトＶ１をみた画像）をディスプレイに表示する。

このように、基地局２０が送信するビームと補正情報とを対応づけておくことで、ＵＥ１０の位置に応じた補正ＡＲ画像データを提供することができる。そのため、スタジアムＳＴなどの大規模施設の観客席からＡＲサービスを視聴する場合のCapturing及びImage Recognitionの精度向上に寄与することができる。

以下、上記の情報処理を実行する通信システムの詳細について、図を用いて説明する。

＜１．２．基地局とＵＥとの間の無線通信の概要＞
上述したＵＥ１０及び基地局２０は、例えば５Ｇ ＮＲに基づく無線通信を行う。以下、５Ｇ ＮＲ、特に基地局２０が行うビームフォーミングについて説明する。

５Ｇ ＮＲは、第４世代セルラ通信システムのＬＴＥに比べ、高周波数帯域（例えば、６ＧＨｚ帯以上）での通信を許容する。高周波数帯域では電波の特性（直進性、減衰性）をカバーするため（i.e., 伝搬損失を補うため）に、ビームフォーミングを使用する。これにより、伝搬損失をそのbeam利得で補うことができる。しかし、ビームフォーミングを使用すると、高周波数帯域であっても遠くまで電波を飛ばすことができる一方、ビームが細くなり、１つのビームでカバーできる物理的な範囲が狭くなる。そこで、３ＧＰＰ ５Ｇ ＮＲは、ビームスイーピングを導入する。ビームスイーピングは、異なる方向にビームフォーミングされた複数の同期信号を基地局２０から順々に報知する技術である（図４参照）。これにより、低周波数帯域においてビームフォーミングなしに（i.e., 無指向性のビームで）カバー可能であったエリアを高周波数帯域においてもカバーすることが可能となる。このビームスイーピングされる信号は、下り方向では同期信号（SS/PBCH block）及びＣＳＩ−ＲＳが少なくとも規定されている。

同期信号（SS/PBCH block）のビームスイーピングについてより具体的に説明する。3GPP Rel．15において、端末装置（ＵＥ）１０がnetworkと下り同期するための同期信号は、ＳＳＢ（SS/PBCH block）と呼ばれる。同期信号（Synchronization Signal（ＳＳ））はPrimary Synchronization Signal（ＰＳＳ）とSecondary Synchronization Signal（ＳＳＳ）とからなる。ＰＢＣＨ（Physical Broadcast Channel）はMaster Information Blockを運ぶ。１つのＳＳＢには、ＰＳＳ、ＳＳＳ及びＰＢＣＨが含まれる。ＳＳＢは、複数のＳＳＢからなるSSB burst（SS burst）として周期的に基地局２０（ＲＡＮ）からセル内へ送信される。１つのSSB burst内の複数のＳＳＢには、識別子SSB indexがそれぞれ付加されている。3GPP Rel.15において、１つのSSB burst内のＳＳＢの数は、Frequency Rangeに応じて４、８又は６４のいずれかになる。ＳＳＢは、それぞれ異なる方向にビームフォーミングされて送信される。端末装置１０は、どの方向のビームの受信品質が良好であったかをSSB indexに関連付けられたRACH occasionで、基地局２０へ報告する。

周波数バンドと単位時間(e.g., 1SS burst又は1SSB burst)当たりのビーム数（ＳＳＢの数）とは、互いに紐づいて定義されている。３ＧＰＰでは、単位時間(e.g., 1SS burst又は1SSB burst)当たりのビーム数（ＳＳＢの数）の最大値はＬｍａｘとして定義されている。例えば、キャリア周波数が６ＧＨｚ以下のバンドは、ＦＲ（Frequency Range）１という周波数範囲が対応する。キャリア周波数が６ＧＨｚ以上のバンドは、ＦＲ２という周波数範囲が対応する。

図２は、従来のＳＳＢの伝送パターンを示す図である。従来のＳＳＢの伝送パターンには、CASE A-Eがある。ＦＲ１の場合（i.e., Case A-Cの場合）、送信されるＳＳＢの数は、単位時間（half frame: 5ms又は１つのSSB burst）あたり４又は８である。ＦＲ２の場合（i.e., Case D,Fの場合）、送信されるＳＳＢの数は、単位時間（half frame: 5 ms又は１つのSSB burst）あたり６４である。言い換えると、ＦＲ２は、周波数帯が24250MHz−52600MHzのFrequency rangeであるため、Ｌｍａｘ＝６４は、この周波数帯であっても対応できるＳＳＢの数として規定されている。

つまり、ＦＲ２（６ＧＨｚ帯以上）の場合、ビームフォーミングされたＳＳＢは、最大６４個（６４種類）必要であり、ＦＲ１の場合に比べ多い。言い換えると、ＦＲ１の場合（Case A-C）、単位時間（half frame: 5 ms）あたりに送信されるＳＳＢの最大数は、４又は８である。このため、ＦＲ１の場合、最大４又は８通りのBeam（Beamformed SSB）でBeam sweepingすれば十分である。しかし、ＦＲ２の場合（Case D,F）、単位時間（half frame: 5ms）あたりに送信されるＳＳＢの最大数は、６４である。このため、ＦＲ２の場合、最大６４通りのBeam（Beamformed SSB）でBeam sweepingする必要がある。なぜなら、高い周波数帯（例えば、６ＧＨｚ帯以上）では、低い周波数帯に比べプロパゲーションロスが大きくなり、beamを絞る必要があるためである。

なお、将来、拡張されて、52600MHzより高い周波数帯（例えば、100GHz帯）及びFrequency range（例えば、ＦＲ３）が新たに規定されるかもしれない。その場合、より一層ビームを絞る必要性があるため、同一地理的エリアをカバーするためには１つのSSB burst内のＳＳＢのｍａｘ数（Ｌｍａｘ）が６４では足りないかもしれない。例えば100GHz帯では、Ｌｍａｘ＝６４では足りず、Ｌｍａｘが、例えば１２８や２５６など６４よりも大きくなるかもしれない。本実施形態を含むいくつかの実施形態では、将来規定されるかもしれない周波数レンジ（e.g., ＦＲ３）及び６４以上のＬｍａｘにも適用可能である。

上述した５Ｇ ＮＲにおける同期信号（ＳＳＢ）の特性からも理解されるように、端末装置（ＵＥ）１０にとって好ましい（i.e.,無線品質が所定の閾値以上の）ＳＳＢ（i.e.,ビーム）はその端末装置（ＵＥ）１０の位置に応じて異なる。そして、どのＳＳＢ（i.e.,ビーム）が端末装置（ＵＥ）１０にとって好ましいかは、5ms＋数ms（e.g., 1SS burst＋端末内の処理時間）で判定が可能である。そこで、本実施形態では、ＡＲ／ＶＲ画像内の仮想オブジェクトに適用される補正情報（向きと距離）にＳＳＢのインデックスを関連付ける。

前述の通り、3GPP TR 22.842 v17.1.0及びTS 22.261 v17.0.1は、ＡＲ／ＶＲを用いたクラウドゲームについて、ゲーム画像のレンダリングに関する要求条件を規定している。より具体的には、これらの技術仕様書、報告書は、ゲーム画像のレンダリングにおいて、ＡＲ／ＶＲユーザが映像の動きに違和感のないレベルの許容遅延として、motion-to-photon遅延とmotion-to-sound遅延ついて次のように記載している。

・motion-to-photon遅延：要求されるデータレート（１Ｇｂｐｓ）を維持しつつ、motion-to-photon遅延は7-15msの範囲、
・motion-to-sound遅延：20ms未満。

なお、motion-to-photon遅延は、ユーザの頭の物理的な動きとAR/VR headset (e.g., Head Mount Display)内の更新された画像との間の遅延として定義され得る。また、motion-to-sound遅延は、ユーザの頭の物理的な動きとユーザの耳に届くヘッドマウントスピーカーからの内の更新された音波との間の遅延として定義され得る。ここでのAR/VR headset（ヘッドマウントディスプレイ）やヘッドマウントスピーカーは本実施形態における端末装置１０であってもよい。

これら遅延に関する条件を満たすために、5G systemとしてはレンダリングに関して次の２つの要求条件を満たすよう、上述の技術仕様書、報告書は規定している。

・Max Allowed End-to-end latency：5ms (すなわち、（e.g., 本実施形態における端末装置（ＵＥ）１０）とデータネットワーク（e.g., ＵＥから見てコアネットワークの先に配置されるネットワーク。クラウドネットワークやエッジネットワークを含む）へのインタフェースとの間の上りリンク及び下りリンクの合計の許容遅延が5ms)、
・Service bit rate: user-experienced data rate： 0.1 Gbps （100Mbps）（すなわち、ＡＲ／ＶＲコンテンツをサポートできるスループット）。

なお、ここでのレンダリングは、Ｃｌｏｕｄレンダリング、Ｅｄｇｅレンダリング又はＳｐｌｉｔレンダリングを含む。Ｃｌｏｕｄレンダリングは、ネットワークのクラウド上（ユーザの位置を考慮しないコアネットワーク（ＵＰＦを含む）配置とデータネットワーク（アプリケーションサーバやＡＦを含む）配置に基づく、とあるエンティティ上）においてＡＲ／ＶＲデータがレンダリングされる。Ｅｄｇｅレンダリングは、ネットワークのエッジ上（ユーザの位置に近いコアネットワーク（ＵＰＦを含む）配置とデータネットワーク（アプリケーションサーバやＡＦを含む）配置に基づく、とあるエンティティ（e.g.Edge Computing Server （Edge Computing のためのネットワーク配置におけるデータネットワーク内のアプリケーションサーバ３０））上において、ＡＲ／ＶＲデータがレンダリングされる。Ｓｐｌｉｔレンダリングは、レンダリングの一部がクラウド上で行われ、他の一部がエッジ上で行われるレンダリングを意味する。

図３は、レンダリングに関するレンダリングサーバとＡＲ／ＶＲクライアントのイメージ図である。なお、レンダリングサーバ及びＡＲ／ＶＲクライアントは上述の技術報告書に記載されている。ここで、ＡＲ／ＶＲクライアントは、本実施形態における端末装置（ＵＥ）１０に対応してもよい。また、Cloud Render Serverは、クラウド上に配置されたアプリケーションサーバであってもよいし、エッジコンピューティングのためにエッジに配置されたアプリケーションサーバ（e.g., Edge Computing Server）であってもよい。また、Cloud Render Serverは、Edge Render Serverという名称であってもよいし、Split Render Serverという名称であってもよい。レンダリングサーバは、本実施形態におけるアプリケーションサーバ３０に対応してもよい。

＜１．３．通信システムの構成例＞
＜１．３．１．通信システムの全体構成例＞
図４は、本開示の第１の実施形態に係る通信システムの論理的構成例を示す図である。図４の通信システムは、端末装置（ＵＥ）１０、基地局（ｇＮＢ）２０、コアネットワークノード（e.g., ＵＰＦ）４０、アプリケーションサーバ（e.g., (Edge) Application Server）３０を含む。

（端末装置）
端末装置１０はＵｕインタフェースを介して基地局２０に接続され得る。より具体的には、端末装置（ＵＥ）１０は、セルサーチ・セル選択手順を実行し、Suitable cellとしてあるセルにcamp onした後、任意のタイミングでランダムアクセス手順を実行する。ランダムアクセス手順は、端末観点で言えば、ランダムアクセスプリアンブルの送信、ランダムアクセスレスポンスの受信、及びその後のＭｓｇ３（メッセージ３）の受信を含む。ランダムアクセス手順が成功したのち、基地局（ｇＮＢ）２０との間でRRC Setup手順を実行し、RRC Setupメッセージの受信に応じて、端末装置１０は、RRC_Connectedへ入る。そして、端末装置１０は、RRC Setup手順を実行した現在のセル（Serving cell）をPrimary Cell（PCell）と認識（consider）する。

（基地局）
基地局２０は、前述の通り、Ｕｕインタフェースを介して端末装置１０と通信を行う。なお、単一の基地局２０は複数のセル又は複数のＢＷＰを管理してもよい。１又は複数の基地局２０は、無線アクセスネットワーク（ＲＡＮ）を構成する。ここで、無線アクセスネットワークは、Ｅ−ＵＴＲＡＮ（Evolved Universal Terrestrial Radio Access Network）やＮＧ−ＲＡＮ（Next Generation Radio Access Network）であってもよい。また、基地局２０はｇＮＢ ＣＵ（Central Unit）とｇＮＢ ＤＵ（Distributed Unit）との組み合わせ又はこれらのいずれかと称されてもよい。本実施形態において基地局２０は、他の基地局と無線通信可能に構成されていてもよい。例えば、複数の基地局２０がｅＮＢ同士又はｅＮＢとｇＮＢとの組み合わせである場合、当該装置間はＸ２インタフェースで接続されてもよい。また、複数の基地局２０がｅＮＢ同士又はｅＮＢとｇＮＢとの組み合わせである場合、当該装置間はＸｎインタフェースで接続されてもよい。また、複数の基地局２０がｇＮＢ ＣＵとｇＮＢ ＤＵとの組み合わせである場合、当該装置間はＦ１インタフェースで接続されてもよい。後述されるメッセージ・情報の全て又は少なくとも一部は複数の基地局２０間で（例えばＸ２、Ｘｎ、Ｆ１インタフェースを介して）通信されてもよい。

さらに、基地局２０は、複数の物理的又は論理的装置の集合で構成されていてもよい。例えば、本実施形態において基地局２０は、ＢＢＵ（Baseband Unit）及びＲＵ（Radio Unit）の複数の装置に区別され、これら複数の装置の集合体として解釈されてもよい。さらに又はこれに代えて、本開示の実施形態において基地局２０は、ＢＢＵ及びＲＵのうちいずれか又は両方であってもよい。ＢＢＵとＲＵとは所定のインタフェース（例えば、ｅＣＰＲＩ）で接続されていてもよい。さらに又はこれに代えて、ＲＵはＲＲＵ（Remote Radio Unit）又はＲＤ（Radio DoT）と称されていてもよい。さらに又はこれに代えて、ＲＵは前述又は後述のｇＮＢ ＤＵに対応していてもよい。さらに又はこれに代えてＢＢＵは、前述又は後述のｇＮＢ ＣＵに対応していてもよい。さらに又はこれに代えて、ＲＵはアンテナと一体的に形成された装置であってもよい。基地局２０が有するアンテナ（例えば、ＲＵと一体的に形成されたアンテナ）はAdvanced Antenna Systemを採用し、ＭＩＭＯ（例えば、ＦＤ−ＭＩＭＯ）やビームフォーミングをサポートしていてもよい。アドバンスドアンテナシステム（Advanced Antenna System）では、基地局２０が有するアンテナ（例えば、ＲＵと一体的に形成されたアンテナ）は、例えば、６４個の送信用アンテナポート及び６４個の受信用アンテナポートを備えていてもよい。基地局２０がビームフォーミングをサポートする場合、図４に示すように、基地局２０は、例えばビームをセルの円周方向や半径方向にビームスウィーピングさせて信号を送信する。なお、ビームスイーピングの方向は、水平方向のみ限られず、垂直方向又は水平方向と垂直方向との組み合わせによる任意の方向であってもよい。すなわち、ビームフォーミングを行うアンテナの複数アンテナ素子がアンテナ面に対して水平方向及び垂直方向に配列された場合、後述するアンテナに関する設定（e.g., アンテナチルト角、アンテナ素子（エレメント）間の距離・波長や位相オフセット、基準送信電力）を調整することにより水平方向及び垂直方向でビームを指向制御することができる。

（コアネットワークノード）
コアネットワークノード４０は、ネットワークインタフェースを介して基地局２０と接続される。複数のコアネットワークノード４０によりコアネットワークが形成される。コアネットワークは５ＧＣであってもよい。すなわちコアネットワークノード４０は、ＡＭＦ、ＵＰＦ、ＳＭＦ、ＮＥＦ、ＡＦ等のうちいずれかであってもよい。図４では、１つのコアネットワークノード４０のみが図示されているが、これには限られず、基地局２０(e.g., ｇＮＢ)と通信可能な（i.e., 基地局（ｇＮＢ）２０との間にreference pointを持ちうる）コアネットワークノード４０は複数であってもよい。同様に、アプリケーションサーバ３０と通信可能な（i.e., アプリケーションサーバ３０との間にreference pointを持ちうる）コアネットワークノード４０は複数であってもよい。例えば、図４に示すように、コアネットワークノード４０がＵＰＦの場合、ＵＰＦは基地局ｇＮＢとＮＧ−Ｕインタフェースを介して接続される。ＮＧ−Ｕインタフェースにおいては、NG-Application Protocol（NG-AP）メッセージが通信され得る。後述されるメッセージ・情報の全て又は少なくとも一部は基地局２０とコアネットワークノード４０との間で（例えばＮＧ−Ｃインタフェース又はＮＧ−Ｕインタフェースを介して）通信されてもよい。また、コントールプレーンの観点では、コアネットワークノード（e.g., ＡＭＦ）４０は、端末装置１０とNAS signalingを行うことができる。すなわち、後述されるメッセージ・情報の全て又は少なくとも一部は、端末装置１０とコアネットワークノード４０との間でNAS signalingにより通信されてもよい。後述するように、本実施形態におけるアプリケーションサーバ３０が、Edge Data Network内のEdge Application Serverである場合、当該コアネットワークノード４０は、Local UPFであってもよい。

（アプリケーションサーバ）
アプリケーションサーバ（(Edge) Application Server）３０は、端末装置１０に提供するアプリケーションおよびそのデータをホストし、端末装置１０の要求に応じてアプリケーションデータ（e.g., ＡＲ画像データ）を提供する。アプリケーションデータの端末装置１０への提供は、コアネットワーク及び基地局２０を介して行われる。

上述の、コアネットワークノード４０がユーザプレーン機能を担当するノード（e.g., ＵＰＦ）である場合、アプリケーションサーバ３０は、コアネットワークノード４０と直接又は間接的に接続する。より具体的には、ＵＰＦはData Networkに対するゲートウェイとして動作し、Data Network内のサーバ（e.g., アプリケーションサーバ３０）と通信が可能となる。また、コアネットワークノード４０がコントロールプレーン機能を担当するノード（e.g., ＡＭＦ、ＳＭＦ）である場合、アプリケーションサーバ３０は、コアネットワークノード４０と直接又は間接的に接続する。より具体的には、アプリケーションサーバ（e.g., サーバ内のApplication Function ）３０は、５ＧＣのＣ−Ｐｌａｎノードと、直接的に又はＮＥＦ（Network Exposure Function）を介して間接的に、通信（e.g., ＡＰＩなどを用いて情報のやり取り）が可能となる。

なお、本実施形態にEdge Computingが適用されてもよい。Edge Computingにより、オペレータとサードパーティのサービスをＵＥ１０のアクセスポイントの近くでホストできる。そのため、end-to-endの遅延とトランスポートネットワークの負荷が軽減され、効率的なサービス配信が実現され得る。すなわち、Data Networkは、Edge Data Networkであってもよい。アプリケーションサーバ３０はEdge Data Network内の、Edge Application Serverであってもよい。なお、ここでのEdge Computingは、Multi-access Edge Computing（ＭＥＣ）又はMobile Edge Computing（ＭＥＣ）と称されてもよい。本実施形態のEdge Computingへの適用例の詳細は、第３の実施形態にて後述する。

＜１．３．２．端末装置の構成例＞
次に、図５を参照して、本開示の第１の実施形態に係る端末装置１０の構成の一例を説明する。図５は、本開示の第１の実施形態に係る端末装置１０の構成の一例を示すブロック図である。

例えば、端末装置１０は、頭部装着型（例えば眼鏡型やゴーグル型など）のデバイス、すなわちＨＭＤであり得る。例えば、端末装置１０は、グラス型、ヘルメット型等、種々の構造が採用され得る。ＡＲ画像を表示する端末装置１０は、ビデオシースルー型のＨＭＤ（Ｈｅａｄ Ｍｏｕｎｔｅｄ Ｄｉｓｐｌａｙ）、または、光学シースルー型のＨＭＤに分類される。また、端末装置１０は、コンタクトレンズ型ディスプレイであってもよい。ＨＭＤとコンタクトレンズ型ディスプレイは総称してニアアイディスプレイ（near eye display）と呼ばれる場合がある。なお、端末装置１０は、ＶＲに対応した遮蔽型のＨＭＤであってもよいがこれらには限られない。例えば端末装置１０は、網膜投射型ＨＭＤであってもよい。あるいは、端末装置１０は、スマートフォンであってもよく、撮像部（e.g., カメラ）と表示部（e.g., ディスプレイ）を備えたスマートフォン以外の情報処理装置であってもよい。

図５に示すように、端末装置１０は、アンテナ部１００と、通信部（トランシーバ）１１０と、記憶部（メモリ）１２０と、表示部（ディスプレイ）１３０と、撮像部（カメラ）１４０と、制御部（プロセッサ）１５０と、を含む。なお、図５に示した構成は機能的な構成であり、ハードウェア構成はこれとは異なっていてもよい。また、端末装置１０の機能は、複数の物理的に分離された構成に分散して実装されてもよい。

アンテナ部１００は、通信部１１０により出力される信号を電波として空間に放射する。また、アンテナ部１００は、空間の電波を信号に変換し、当該信号を通信部１１０へ出力する。

通信部１１０は、信号を送受信する。例えば、通信部１１０は、基地局２０からのダウンリンク信号を受信し、基地局２０へのアップリンク信号を送信する。

記憶部１２０は、ＤＲＡＭ、ＳＲＡＭ、フラッシュメモリ、ハードディスク等のデータ読み書き可能な記憶装置である。記憶部１２０は、端末装置１０の記憶手段として機能する。

表示部１３０は、アプリケーションサーバ３０から送信されるＡＲ画像データを表示するディスプレイである。表示部１３０は、光学シースルーディスプレイであってもよく、非透過型（遮蔽型）のディスプレイ、すなわちビデオシースルーディスプレイであってもよい。表示部１３０が光学シースルーディスプレイの場合、表示部１３０は、光学透過性を有し、制御部１５０の制御に基づいてＡＲ画像データに含まれる仮想オブジェクトをディスプレイに表示する。表示部１３０がビデオシースルーディスプレイの場合、表示部１３０は、制御部１５０の制御に基づき、撮像部１４０が撮像した実画像にＡＲ画像データに含まれる仮想オブジェクトを重畳して表示する。

撮像部１４０は、ユーザの視線方向を撮像するカメラである。撮像部１４０は、ユーザの前方の映像を撮像する。上述したように、表示部１３０がビデオシースルーディスプレイの場合、撮像部１４０により撮影される、ユーザの前方の映像が表示部１３０に逐次表示されてもよい。

制御部１５０は、端末装置１０の各部を制御するコントローラである。制御部１５０は、例えば、ＣＰＵ、ＭＰＵ等のプロセッサ（ハードウェアプロセッサ）により実現される。例えば、制御部１５０は、端末装置１０内部の記憶装置に記憶されている各種プログラムを、プロセッサがＲＡＭ等を作業領域として実行することにより実現される。なお、制御部１５０は、ＡＳＩＣやＦＰＧＡ等の集積回路により実現されてもよい。ＣＰＵ、ＭＰＵ、ＡＳＩＣ、及びＦＰＧＡは何れもコントローラとみなすことができる。

なお、端末装置１０は、上述した構成以外にも、例えば入出力部やスピーカ等の音声出力部等の構成を有していてもよい。

＜１．３．３．基地局の構成例＞
次に、図６を参照して、本開示の第１の実施形態に係る基地局２０の構成の一例を説明する。図６は、本開示の第１の実施形態に係る基地局２０の構成の一例を示すブロック図である。

図６に示すように、基地局２０は、アンテナ部２００と、通信部（トランシーバ）２１０と、ネットワーク通信部（NW interface）２２０と、記憶部（メモリ）２３０と、制御部（プロセッサ）２４０と、を含む。なお、図６に示した構成は機能的な構成であり、ハードウェア構成はこれとは異なっていてもよい。また、基地局２０の機能は、複数の物理的に分離された構成に分散して実装されてもよい。

アンテナ部２００は、通信部２１０により出力される信号を電波として空間に放射する。また、アンテナ部２００は、空間の電波を信号に変換し、当該信号を通信部２１０へ出力する。

通信部２１０は、信号を送受信する。例えば、通信部２１０は、端末装置１０からのアップリンク信号を受信し、端末装置１０へのダウンリンク信号を送信する。

ネットワーク通信部２２０は、ネットワーク上で上位に位置するノード（例えば、コアネットワークノード４０、図４参照）と通信するための通信インタフェースである。例えば、ネットワーク通信部２２０は、ＮＩＣ等のＬＡＮインタフェースである。ネットワーク通信部２２０は、有線インタフェースであってもよいし、無線インタフェースであってもよい。ネットワーク通信部２２０は、基地局２０のネットワーク通信手段として機能する。

記憶部２３０は、ＤＲＡＭ、ＳＲＡＭ、フラッシュメモリ、ハードディスク等のデータ読み書き可能な記憶装置である。記憶部２３０は、基地局２０の記憶手段として機能する。

制御部２４０は、基地局２０の各部を制御するコントローラ（controller）である。制御部２４０は、例えば、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）等のプロセッサ（ハードウェアプロセッサ）により実現される。例えば、制御部２４０は、基地局２０内部の記憶装置に記憶されている各種プログラムを、プロセッサがＲＡＭ（Random Access Memory）等を作業領域として実行することにより実現される。なお、制御部２４０は、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現されてもよい。ＣＰＵ、ＭＰＵ、ＡＳＩＣ、及びＦＰＧＡは何れもコントローラとみなすことができる。

＜１．３．４．アプリケーションサーバの構成例＞
次に、図７を参照して、本開示の第１の実施形態に係るアプリケーションサーバ３０の構成の一例を説明する。図７は、本開示の第１の実施形態に係るアプリケーションサーバ３０の構成の一例を示すブロック図である。

図７に示すように、アプリケーションサーバ３０は、ネットワーク通信部（NW interface）３１０と、記憶部（メモリ）３２０と、制御部（プロセッサ）３３０と、を含む。なお、図７に示した構成は機能的な構成であり、ハードウェア構成はこれとは異なっていてもよい。また、アプリケーションサーバ３０の機能は、複数の物理的に分離された構成に分散して実装されてもよい。

ネットワーク通信部３１０は、ネットワーク上に位置するノード（例えば、コアネットワークノード４０、図４参照）と通信するための通信インタフェースである。例えば、ネットワーク通信部３１０は、ＮＩＣ等のＬＡＮインタフェースである。ネットワーク通信部３１０は、有線インタフェースであってもよいし、無線インタフェースであってもよい。ネットワーク通信部３１０は、アプリケーションサーバ３０のネットワーク通信手段として機能する。

記憶部２３０は、ＤＲＡＭ、ＳＲＡＭ、フラッシュメモリ、ハードディスク等のデータ読み書き可能な記憶装置である。記憶部２３０は、例えば基地局２０が送信するビーム（例えばＳＳＢのインデックス）と、ＡＲ画像データの補正情報と、を関連付けて記憶する。記憶部２３０は、アプリケーションサーバ３０の記憶手段として機能する。

制御部２４０は、アプリケーションサーバ３０の各部を制御するコントローラ（controller）である。制御部２４０は、例えば、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）等のプロセッサ（ハードウェアプロセッサ）により実現される。例えば、制御部２４０は、アプリケーションサーバ３０内部の記憶装置に記憶されている各種プログラムを、プロセッサがＲＡＭ（Random Access Memory）等を作業領域として実行することにより実現される。なお、制御部２４０は、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現されてもよい。ＣＰＵ、ＭＰＵ、ＡＳＩＣ、及びＦＰＧＡは何れもコントローラとみなすことができる。

＜１．４．通信システムの動作＞
図８は、本開示の第１の実施形態に係る通信システムの動作例を示すシーケンス図である。本動作例は、事前準備ステップであるステップＳ１０１、Ｓ１０２と、その後のステップＳ１０３〜Ｓ１０８とに動作するシーン（シチュエーション）が区別され得る。すなわち、本動作例は、例えばＡＲ／ＶＲイベント開催前までに実行される事前準備ステップ（ステップＳ１０１、Ｓ１０２）と、ＡＲ／ＶＲイベント中に繰り返し実行されるステップＳ１０３〜Ｓ１０８とを含む。

ステップＳ１０１では、事前準備として、基地局２０（ｇＮＢ）から送信される各ビームの送信方向の調整を行う。例えば所定のエリアを複数のビームでカバーできるように、基地局２０（ｇＮＢ）のアンテナに関する設定（e.g., アンテナチルト角、アンテナ素子（エレメント）間の距離・波長や位相オフセット、基準送信電力）を調整する。

例えば、二次元方向において、ビームの任意の角度θへの方向付けは、次の式から求められる。

ここで、ｄは複数のアンテナ素子間の距離、λは信号の波長、Δφは位相オフセットを示す。例えば（式１）を利用（応用）して、所定のエリアを複数のビームでカバーできるように、アンテナに関する設定を調整する。本実施形態が適用されるユースケースが、スタジアムＳＴ等の大規模施設でのＡＲ／ＶＲイベントである場合、１つのビームがカバーできるエリアは、１つの以上の座席を含む座席グループに関連付けられていてもよい。図９、図１０に、スタジアムＳＴ等の大規模施設において、複数のビーム（ＳＳＢ）と１つの以上の座席を含む座席グループとを関連付けた場合の例を示す。図９及び図１０は、本開示の第１の実施形態に係るビームと座席グループとの関連付けを説明するための図である。

例えば、前述の通り、ＦＲ２（６ＧＨｚ帯以上）の場合、単位時間（half frame:5ms）あたりに送信されるＳＳＢの最大数は、６４である。言い換えると、６４通りの異なる方向にビームが形成され、単位時間（1SS burst）の間に６４方向のビームが順々に基地局２０（ｇＮＢ）から送信（報知）される。したがって、１つの以上の座席を含む座席グループに１つのビームが対応するよう基地局２０（ｇＮＢ）のアンテナの設定を調整する。言い換えると、１つの以上の座席を含む座席グループに端末装置１０がいる場合に、所定のビーム（ＳＳＢ）が端末装置１０にとって一番良いビームとなるように（無線品質が一番良いビームとなるように）アンテナ設定を調整する。これにより、観客席を６４通りの異なる方向にビームに（i.e., ６４個のSSB Indexに）対応付けることができる。

次に、ステップＳ１０２では、１つのビームがカバーできるエリアの、ＡＲ画像表示のための基準点に対する相対的位置の情報（補正情報）と、対応するビームとを、複数のビーム毎に関連付ける。

より具体的には仮想オブジェクトを重畳させる基準点（実オブジェクト）の位置（e.g., 緯度・経度）を予め設定しておく。そして、あるビーム（ＳＳＢ）がカバーできるエリアから当該基準点にユーザがカメラ（e.g., 端末装置１０に備え付けられたカメラ１４０、図５参照）を向けた場合に、仮想オブジェクトが適切な向きと距離で当該基準点に重畳されるように補正情報（１つのビームがカバーできるエリアの当該基準点からの向きと距離）を設定し、当該補正情報と対応するビーム（ＳＳＢ）とを関連付ける。当該基準点は、端末装置１０が備えるカメラ１４０でその存在が認識できる程度に簡素なものでよい。例えば、Marker-based recognitionに必要な、マーカの向きや模様を識別できるほどの複雑（高精度）なものでなくてもよい。同様に、Marker-less recognitionに必要な対象物体上の顕著な点特徴（特徴点（interest point）又はkey point）がなくても（i.e., 認識できるほど高精度なカメラでなくても）よい。補正情報（１つのビームがカバーできるエリアの当該基準点からの向きと距離）により、基準点に対する向きと距離を識別することが可能なためである。

補正情報の具体例について説明する。図１１は、本開示の第１の実施形態に係る補正情報を説明するための図である。図１１では、スタジアムＳＴ等の大規模施設において所定の観客席からＡＲ画像を観覧した場合を想定する。かかる場合に、仮想オブジェクトが適切な向きと距離で当該基準点に重畳されるように補正情報（１つのビームがカバーできるエリアの当該基準点からの向きと距離）を設定する場合について説明する。

図１１は大規模施設（例えばスタジアムＳＴ）を真上（地球上の地面に対する垂直方向）から俯瞰した場合のx-y平面と、当該x-y平面に対する垂直方向の平面z-(x-y)平面を含んでいる。図１１のx-y平面では、SSB index #23で識別されるビームがカバーするエリア（端末装置１０が同期信号の測定をした場合に、SSB index #23で識別されるビームの無線品質が当該端末装置１０にとって一番良いビームとなるエリア）の中心部と、基準点（e.g., ＡＲ画像データ（仮想オブジェクト）を重畳させる基準となるポイント。例えば大規模施設の中心地点）との間の距離をＬで表し、x-y平面のx軸方向（e.g., x-y平面における任意の方向）からの角度をαとする。

さらに、図１１のz-(x-y)平面では、SSB index #23で識別されるビームがカバーするエリアの中心部と、基準点との間の距離をＬ’で表し、z-(x-y)平面におけるＬとＬ’との間の角度をβとする。なお、z-(x-y)平面において、基準点は、地面から高さｈを有する地点に設けられているが、高さｈはゼロであってもよい。ここで、基準点のx,y,z座標を（0, 0, 0）とした場合の、SSB index #23で識別されるビームがカバーするエリアの中心部のx,y,z座標を（X _{SSB_23}, Y _{SSB_23}, Z _{SSB_23}）とすると、式２が成り立つ。

したがって、式２を変形した式３から得られた（L', α, β）が、SSB index #23のビームの無線品質が一番良いビームであった端末装置１０のディスプレイ１３０に表示すべきＡＲ画像の位置合わせに用いる補正情報として、対応するビーム（i.e.,SSB Index）と関連付けられる。

これらの関連付けが、端末装置１０へのサービス提供の前に行われ得る。例えば、アプリケーションサーバ３０は、コアネットワーク（e.g., コアネットワークノード４０）を介して、基地局２０（ｇＮＢ）から、ビームに関する情報（e.g., ＳＳＢのIndex及びそれに対応するアンテナの設定情報のリスト）を取得してもよい。例えば、アプリケーションサーバ３０は、基地局２０（ｇＮＢ）又はコアネットワークが提供するＡＰＩを介してビームに関する情報を取得してもよい。本実施形態が、Edge Computingに適用される場合、当該ＡＰＩは、3GPP Network（基地局２０（ｇＮＢ）とコアネットワークを含む）とEdge Application Serverとの間のReference Point "EDGE-7"を介してアプリケーションサーバ３０へ提供されてもよい。例えば、Edge Application Serverは、（NEFによって開示されるAPIを介して）3GPPネットワーク機能及びAPIにアクセスすることができる。さらに又はこれに代えて、当該ＡＰＩは、3GPP Network（基地局２０（ｇＮＢ）とコアネットワークを含む）とEdge Enabler Serverとの間のReference Point "EDGE-2"及び、Edge Enabler ServerとEdge Application Serverとの間のReference Point "EDGE-3"を介してアプリケーションサーバ３０へ提供されてもよい。さらに又はこれに代えて、当該ＡＰＩは、3GPP Network（基地局２０（ｇＮＢ）とコアネットワークを含む）とEdge Data Network Configuration Serverとの間のReference Point "EDGE-8"、Edge Data Network Configuration ServerとEdge Enabler Serverとの間のReference Point "EDGE-6"及び、Edge Enabler ServerとEdge Application Serverとの間のReference Point "EDGE-3"を介してアプリケーションサーバ３０へ提供されてもよい。これらの詳細は後述される。

図８の説明に戻る。ステップＳ１０３において、基地局２０（ｇＮＢ）は、同期信号（e.g., ＳＳＢ）をセル内に報知する。より具体的には、複数の同期信号が異なる方向にビームフォーミングされて順々に送信されるビームスイーピングを行って、複数の同期信号をそれぞれ異なる方向に報知する。本ステップにおいて送信される各同期信号は、ステップＳ１０１におけるアンテナに関する設定で角度・基準送信電力が予め調整されている。例えば本実施形態では、６４通りの異なる方向にビームが形成され、単位時間（1SS burst）の間に６４方向のビームが順々に基地局２０（ｇＮＢ）から送信（報知）される。

ステップＳ１０４において、端末装置１０は、ビームスイーピングにより送信された少なくとも１つの同期信号（e.g., ＳＳＢ）を受信（検出）し、各同期信号の無線品質を測定する。ここでの無線品質は、ＲＳＲＰ、ＲＳＲＱ、ＳＩＮＲ、ＲＳＳＩ、ＣＳＩのうちいずれか又はその組み合わせであってもよいが、これには限られない。ここでのＲＳＲＰは、Secondary synchronization signal reference signal received power (ＳＳ−ＲＳＲＰ)であってもよい。ここでのＲＳＲＱは、Secondary synchronization signal reference signal received quality (ＳＳ−ＲＳＲＱ)であってもよい。ここでのＳＩＮＲは、Secondary synchronization signal interference to noise ratio (ＳＳ−ＳＩＮＲ)であってもよい。すなわち、同期信号（e.g., ＳＳＢ）の測定対象は、Secondary synchronization signalに限定されてもよい。そして、測定した同期信号の無線品質が所定の閾値よりも高い場合、当該同期信号を端末装置１０にとってベストなビームの同期信号として決定する。端末装置１０にとってベストなビーム（図８では、Beam A）は、同期信号のインデックス（e.g., SSB Index）を用いてネットワークへ報告される。所定の閾値よりも高い同期信号が複数ある場合、端末装置１０は、最も無線品質が高いビームのみをネットワークへ報告してもよいし、所定の閾値を満たすビームを複数又は全てネットワークへ報告してもよい。当該報告はステップＳ１０５で行われる。

ステップＳ１０５では、端末装置１０は、基地局２０（ｇＮＢ）との間でランダムアクセス手順を実行する。前述の通り、ランダムアクセス手順は、ランダムアクセスプリアンブルの送信、ランダムアクセスレスポンスの受信、及びその後のＭｓｇ３（メッセージ３）の受信を含む。すなわち、端末装置１０は、ランダムアクセスプリアンブルを基地局２０（ｇＮＢ）に対して送信する。

例えば、3GPP TS38.211によれば、端末装置１０が送信するプリアンブルに関しては、６４個の異なるプリアンブルが各RACH occasionに対して割り当てられる。従って、複数の端末装置１０が同じRACH occasionでプリアンブルを送信した場合に、異なるプリアンブルを用いていれば、基地局２０側で分離して判別することが可能になる。RACH occasionを含むRACH-Configは、基地局２０から提供されるシステムインフォメーション（e.g., ＳＩＢ１）で通知される。あるビームに対応するSSB Indexと、RACH occasionとは、１対１の関係で関連付けることができる。したがって、端末装置１０がどのRACH occasionでプリアンブルを送信してきたかを確認することで、基地局２０は端末装置１０にとってベストなSSB Indexつまりビームを識別することができる。

基地局２０（ｇＮＢ）は、ランダムアクセスプリアンブルの受信に応答して、ランダムアクセスレスポンスを送信する。ランダムアクセスプリアンブルが送信されるRACH occasionは端末装置１０にとってベストなSSB Indexつまりビームに関連づいているため、基地局２０は、端末装置１０にとってベストなビームを、RACH occasionに関連付けられたSSB Indexから認識できる。そして基地局２０から送信されるランダムアクセスレスポンスは、当該SSB Indexに対応するビームと同じ方向にビームフォーミングして送信される。以後の通信（e.g., Ｍｓｇ３の送信、RRC Setup手順）には、ビームが切り替えられない限り、同じ方向を向くビームが使用される。

任意のタイミングにおいて、アプリケーションサーバ３０は、端末装置１０へアプリケーション（e.g., ＡＲ画像データ）を提供することを決定する。この決定は、端末装置１０からの明示的又は暗示的案要求に基づいて行われてもよい。ここでの明示的な要求は、要求メッセージの端末装置１０からアプリケーションサーバ３０への送信によって行われてもよいし、暗示的な要求は、端末装置１０のSubscription dataが当該アプリケーションの提供をsubscribe又はallowしていることを条件としたアプリケーションサーバ３０での判断であってもよい。すると、ステップＳ１０６において、アプリケーションサーバ３０は、端末装置１０とってベストなビームの情報（e.g., SSB Index）を取得する。例えば、アプリケーションサーバ３０は、コアネットワークノード４０を介して、基地局２０（ｇＮＢ）から、当該SSB Indexの情報を取得してもよい。例えば、アプリケーションサーバ３０は、基地局２０（ｇＮＢ）又はコアネットワークノード４０が提供するＡＰＩを介して当該SSB Indexの情報を取得してもよい。本実施形態が、Edge Computingに適用される場合、当該ＡＰＩは、3GPP Network（基地局２０（ｇＮＢ）とコアネットワークを含む）とEdge Application Serverとの間のReference Point "EDGE-7"を介してアプリケーションサーバ３０へ提供されてもよい。例えば、Edge Application Serverは、（NEFによって開示されるAPIを介して）3GPPネットワーク機能及びAPIにアクセスすることができる。さらに又はこれに代えて、当該ＡＰＩは、3GPP Network（基地局２０（ｇＮＢ）とコアネットワークを含む）とEdge Enabler Serverとの間のReference Point "EDGE-2"及び、Edge Enabler ServerとEdge Application Serverとの間のReference Point "EDGE-3"を介してアプリケーションサーバ３０へ提供されてもよい。さらに又はこれに代えて、当該ＡＰＩは、3GPP Network（基地局２０（ｇＮＢ）とコアネットワークを含む）とEdge Data Network Configuration Serverとの間のReference Point "EDGE-8"、Edge Data Network Configuration ServerとEdge Enabler Serverとの間のReference Point "EDGE-6"及び、Edge Enabler ServerとEdge Application Serverとの間のReference Point "EDGE-3"を介してアプリケーションサーバ３０へ提供されてもよい。これらの詳細は後述される。

そして、アプリケーションサーバ３０は、取得したSSB Indexの情報に基づき、当該SSB Indexに予め関連付けられたＡＲ画像データの表示に用いる補正情報（e.g., 角度・距離）を決定する。そしてステップＳ１０７で、アプリケーションサーバ３０は当該補正情報を用いて、ＡＲ画像データのレンダリングを行い、レンダリングされた（e.g., 補正情報を用いて位置合わせされた）補正ＡＲ画像データを端末装置１０へ送信する。なお、ここでのレンダリングは、上述した、Cloudレンダリング、Edgeレンダリング又はSplitレンダリングのうちいずれかであってもよい。

ステップＳ１０８で、端末装置１０は、受信した補正ＡＲ画像データをディスプレイ１３０に表示させる。これにより、カメラ１４０が撮像した実オブジェクトに補正ＡＲ画像データに含まれる仮想オブジェクトを重畳させることができる。

このようにして、各ユーザ（端末装置１０）の位置に応じて適切な位置合わせが行われた補正ＡＲ画像データが、各ユーザ（端末装置１０）に提供され得る。ユーザは、適切な位置合わせが行われた補正ＡＲ画像データと実画像とが重畳されたＡＲ画像Ｍ１（図１参照）を視聴することができる。

なお、本実施形態が適用されるユースケースが、スタジアムＳＴ等の大規模施設でのＡＲ／ＶＲイベントである場合、その他の場合に比べて端末装置１０（を利用するユーザ）が移動する可能性が低い。そのため、端末装置１０が備えるカメラ１４０により撮像された１つの基準点と、端末装置１０にとって一番良いビーム（ＳＳＢ）に関連付けられた補正情報（１つのビームがカバーできるエリアの当該基準点からの向きと距離）のみを用いて仮想オブジェクトの位置合わせを行う場合であっても、ユーザに違和感を生じさせない程度でＡＲ画像をディプレイに表示することができる。

＜１．５．変形例＞
＜１．５．１．変形例１＞
上記第１の実施形態では、アプリケーションサーバ３０が、補正情報に基づき、ＡＲ画像データを補正した補正画像データを生成した場合を示した。上記例以外にも、アプリケーションサーバ３０がベストなビームに関連づけられた補正情報を端末装置１０に送信し、端末装置１０がＡＲ画像データを補正するようにしてもよい。そこで、第１の実施形態の変形例１では、端末装置１０が補正情報に基づいて補正ＡＲ画像データを生成する場合について説明する。

図１２は、本開示の第１の実施形態の変形例１に係る通信システムの動作例を示すシーケンス図である。図１２に示す通信システムの動作は、ステップＳ１０６でアプリケーションサーバ３０がベストなビームの情報を取得するまで図８に示す動作と同じである。
ステップＳ１０６で、ベストなビームの情報を取得したアプリケーションサーバ３０は、取得したSSB Indexの情報に基づき、当該SSB Indexの情報に関連づけられたＡＲ画像データの表示に用いる補正情報（e.g.，角度・距離）を決定する。

任意のタイミングにおいてアプリケーションサーバ３０は、端末装置１０へアプリケーション（e.g.，ＡＲ画像データ）を提供することを決定する。この決定のタイミングは、図８に示す動作と同じである。

そして、ステップＳ２０１で、アプリケーションサーバ３０は、ＡＲ画像データおよびベストなビームＡに対応する補正情報を端末装置１０へ送信する。

ステップＳ２０２で、端末装置１０は、受信したＡＲ画像データを、補正情報を用いて位置合わせ等の補正を行う。

続いて、ステップＳ１０８で、カメラ１４０が撮像した実オブジェクト（実画像）に補正ＡＲ画像データに含まれる仮想オブジェクトを重畳してディスプレイ１３０に表示する。

このようにして、各ユーザ（端末装置１０）の位置に応じた補正情報を用いて、端末装置１０が適切に位置合わせを行うことができる。ユーザは、適切な位置合わせが行われた補正ＡＲ画像データと実画像とが重畳されたＡＲ画像Ｍ１（図１参照）を視聴することができる。

＜１．５．２．変形例２＞
上記変形例１では、アプリケーションサーバ３０が、ベストなビームに基づき、補正情報を決定する場合を示した。上記例以外にも、端末装置１０がベストなビームに基づき、補正情報を決定するようにしてもよい。そこで、第１の実施形態の変形例２では、端末装置１０がベストなビームに基づき、補正情報を決定する場合について説明する。

図１３は、本開示の第１の実施形態の変形例２に係る通信システムの動作例を示すシーケンス図である。図１３に示す通信システムの動作は、ステップＳ１０６でアプリケーションサーバ３０がベストなビームの情報を取得するまで図８に示す動作と同じである。

任意のタイミングにおいてアプリケーションサーバ３０は、端末装置１０へアプリケーション（e.g.，ＡＲ画像データ）を提供することを決定する。この決定のタイミングは、図８に示す動作と同じである。

ステップＳ３０１で、アプリケーションサーバ３０は、ＡＲ画像データ及び全てのビームに対応する補正情報を端末装置１０に送信する。例えば、アプリケーションサーバ３０は、ビーム（SSB Index）と補正情報の組み合わせ全てを端末装置１０に送信する。

ステップＳ３０２で、端末装置１０は、受信した複数の補正情報の中から、ステップＳ１０４で決定したベストなビーム（ここでは、ビームＡ）に対応する補正情報を選択する。

なお、以降の動作は、図１２に示す変形例１の通信システムの動作と同じである。

このようにして、端末装置１０は、各ユーザ（端末装置１０）の位置に応じた補正情報を選択して、ＡＲ画像データの位置合わせを適切に行うことができる。ユーザは、適切な位置合わせが行われた補正ＡＲ画像データと実画像とが重畳されたＡＲ画像Ｍ１（図１参照）を視聴することができる。

＜２．第２の実施形態＞
第２の実施形態では、第１の実施形態に係るアプリケーションサーバ３０が行うＡＲ画像データの生成の詳細が説明される。具体的には、仮想オブジェクトのデータ（ＡＲ画像データ）から、端末装置１０の位置に応じて見えない部分（視聴方向に対して反対側の表面形状および色の情報）が削減されて、仮想オブジェクトのデータが端末装置１０へ提供される例が説明される。

本実施形態における通信システムの構成は、第１の実施形態における図４に示された通信システムと同様である。すなわち、本実施形態における通信システムは、端末装置１０（ＵＥ）、基地局２０（ｇＮＢ）、コアネットワークノード４０（e.g., ＵＰＦ）、アプリケーションサーバ３０（e.g., (Edge) Application Server）を含む。

本実施形態では、仮想オブジェクトのデータの一例として、３次元空間上に位置情報と属性情報（例えば、色情報や反射情報など）とを同時に持った点の集合であるPoint Cloudで構成されたデータである場合について説明される。しかし、仮想オブジェクトのデータの具体例はこれには限られない。言い換えると、３Ｄデータとしてレンダリングされた仮想オブジェクトのデータであればPoint Cloudで構成されたデータでなくともよい。

例えば、Point Cloudでは、３次元構造を示すgeometryと、色や反射情報等を示すattributeとにデータ分離されて符号化される。geometryの圧縮には、図１４に示すようなoctree符号化が用いられる。例えば、octree符号化は、Voxel表現されたデータにおいて、各ブロック内のポイントの有無を、八分木によって表現する手法である。この手法では、図１４に示すように、ポイントが存在するブロックは１、存在しないブロックは０で表現される。なお、図１４は、Point Cloudの構成を説明するための図である。

ＡＲ画像データにPoint Cloudを用いた場合、Point Cloudオブジェクトの３次元構造情報を、図１４に示したようなoctree符号化で均一に圧縮したGeometry-based Point Cloud Compression（G-PCC）ストリームを用いて配信する。なお、用語「G-PCCストリーム」は、上述した第１の実施形態及び変形例における仮想オブジェクトのデータ（ＡＲ画像データ）の一例であってもよい。このように、octree符号化で均一に圧縮する場合、配信されるG-PCCストリームは、周囲３６０°から視聴できる３次元情報を持ち、かつ、全周囲の精細さが同一となる。つまり、Point Cloudを構成するポイントが密か否か（すなわち、配信されるG-PCCストリームが高精細か否か）は、データ量に比例する。

そこで本実施形態では、G-PCCストリームを生成する際、Point Cloudオブジェクトの部分ごとにVoxelを区切る細かさ（octree depth）を変更し、当該部分毎に精細度を変えて符号化する。例えば、端末装置１０の位置に応じて端末装置１０から視聴可能な部分（視聴方向に対する表面形状および色の情報）については、高精細（depth=10）に設定して符号化する。一方、端末装置１０の位置に応じて端末装置１０から視聴不可能な部分（視聴方向に対して反対側の表面形状および色の情報）については、低精細（depth=5）又は無描画（depth=0）に設定して符号化する。

本実施形態では、当該視聴可能な部分が、第１の実施形態で説明した補正情報（e.g., １つのビーム（ＳＳＢ）がカバーできるエリアの当該基準点からの向きと距離の情報）に基づき決定（特定）される。これらの処理は、アプリケーションサーバ３０において実行されてもよい。そして当該符号化されたＡＲ画像データ（i.e.,G-PCCストリーム）が、アプリケーションサーバ３０から端末装置１０へ提供される。

例えば、G-PCCストリームにおいて高精細にレンダリングされた方向を示す情報は、DASH MPD（Dynamic Adaptive Streaming over HTTP）の拡張により、アプリケーションサーバ３０（MPDファイルサーバ）から端末装置１０（MPEG-DASHクライアント）へ提供されてもよい。MPD（The Media Presentation Description）は、XMLで記載され、Presentation、Period、AdaptationSet、Representation、Segmentで構成されている。このうち、AdaptationSetは、映像・音声・字幕などの単位を表現し、複数のRepresentationから構成される。Representationは、映像・音声のビットレートや解像度、アスペクト比などの情報である。このAdaptation Set内に高精細にレンダリングされた方向を示す情報（フィールド）が新しく定義され得る。即ち、gpcc:directionInfo要素のdirection属性に当該情報（フィールド）が新しく定義され得る。さらに、第１の実施形態で説明された補正情報（e.g., １つのビーム（ＳＳＢ）がカバーできるエリアの当該基準点からの向きと距離の情報）が端末装置１０へシグナリングされる場合（e.g., 図１２のシーケンス又は図１３のシーケンスが採用される場合）、これらの補正情報もAdaptation Set内のフィールド（i.e.,gpcc:directionInfo要素のdirection属性）として新しく定義されてもよい。

また、direction属性の取りうる値は、Point Cloudのローカル座標を基準として、0: X+，1: Y+，2: X-，3: Y-，4: Z+，5: Z-の６方向が設定され得る。第１の実施形態で説明された補正情報（e.g., １つのビーム（ＳＳＢ）がカバーできるエリアの当該基準点からの向きと距離の情報）も、同様に0: X+，1: Y+，2: X-，3: Y-，4: Z+，5: Z-の６方向が設定されてもよい。Point Cloudのローカル座標の座標系と、第１の実施形態で説明された補正情報に含まれる向きと距離を示すための座標系は、一致（同期）されていてもよい。又はこれに代えて、Point Cloudのローカル座標のうち、少なくとも1つの座標軸（e.g., x軸）が、第１の実施形態で説明されたL'（あるSSB indexで識別されるビームがカバーするエリアの中心部と、基準点との間の距離）が示す方向に一致（同期）していてもよい。

ここで、空間分割の方法、および、空間位置情報について説明する。

例えば、Point Cloudオブジェクトの形状は、最大frame by frameで変わる。そこで、Point Cloudオブジェクトの形状の変化に依存しない、一定の分割ルールを適用することで空間分割を行う。具体的には、Point Cloudオブジェクト全体を含むbox（以下適宜、object boxと称する）に対して、相対的に同じ空間位置を占める直方体ブロック（以下適宜、blockと称する）に含まれる部分Point Cloudオブジェクトを、１つの部分G-PCCストリームとして符号化する。

図１５は、本開示の第２の実施形態に係る空間分割の方法、および、空間位置情報について説明するための図である。図１５には、object boxをＸ軸方向で半分に分割する例が示されている。

図１５に示すように、時刻t0のPoint Cloudオブジェクト全体を含むobject boxが、部分Point Cloudオブジェクトt0-aおよびt0-bにx軸方向で半分に分割される。同様に、時刻t1では、部分Point Cloudオブジェクトt1-aおよびt1-bに分割され、時刻t2では、部分Point Cloudオブジェクトt2-aおよびt2-bに分割される。そして、aのG-PCCストリームは、部分Point Cloudオブジェクトt0-a、部分Point Cloudオブジェクトt1-a、および部分Point Cloudオブジェクトt2-aにより構成される。一方、bのG-PCCストリームは、部分Point Cloudオブジェクトt0-b、部分Point Cloudオブジェクトt1-b、および部分Point Cloudオブジェクトt2-bにより構成される。なお、図１５では、任意の時刻tにおいて、Point Cloudオブジェクト全体がx軸方向で部分Point Cloudオブジェクトa及び部分Point Cloudオブジェクトbに分割されているが、これには限られない。例えば、ユーザの視聴方向に応じてy軸方向で分割されてもよいし、z軸方向で分割されてもよい。又はこれに代えて、少なくとも1つの座標軸（e.g., x軸）が、第１の実施形態で説明されたL'（あるSSB indexで識別されるビームがカバーするエリアの中心部と、基準点との間の距離）が示す方向に一致（同期）していない場合、図１５で説明された分割は、第１の実施形態で説明されたL'が示す方向で分割されてもよい。

この方法によれば、部分G-PCCストリームに含まれる部分Point Cloudオブジェクトの全体Point Cloudオブジェクトに対する相対的空間位置が動的に不変となる。相対的空間位置が動的に変わる場合、視聴部分とそれを含む部分G-PCCストリームの関係性が動的に変化する。そのため、クライアントが視聴部分を高精細化するG-PCCストリームを取得する場合、視聴部分が不変であったとしても、取得する高精細なG-PCCストリームを切り替える必要が出てしまう。そこで、この空間分割の手法によって、視聴部分が不変であるときには、取得する高精細なG-PCCストリームを切り替える必要性をなくすことができる。

［アプリケーションサーバ（MPDファイルサーバ）の動作例］
図１６は、アプリケーションサーバ３０（MPDファイルサーバ）が、部分G-PCCストリームが格納されたファイルを生成する生成処理を説明するフローチャートである。なお、第１の実施形態の図８のシーケンスに示すステップＳ１０７、変形例の図１２のシーケンスに示すステップＳ２０１、図１３のシーケンスに示すステップＳ３０１の詳細な動作例ともいえる。

ステップＳ４０１において、アプリケーションサーバ３０（MPDファイルサーバ）は、Point Cloudオブジェクトを分割し、各部分Point Cloudオブジェクトを生成するのと同時に、空間位置情報およびグルーピング情報を生成する。より具体的には、アプリケーションサーバ３０（MPDファイルサーバ）は、端末装置１０（MPEG-DASHクライアント）にとってベストなビーム（SSB Index）に関連付けられた補正情報（e.g., １つのビーム（ＳＳＢ）がカバーできるエリアの当該基準点（実オブジェクト）からの向きと距離の情報）を使用して、端末装置１０から視聴可能な部分に対応する部分Point Cloudオブジェクトと、端末装置１０から視聴不可能な部分に対応する部分Point Cloudオブジェクトを生成する。より具体的には、１つのビーム（ＳＳＢ）がカバーできるエリアの当該基準点（実オブジェクト）からの向きが示す方向において、Point Cloudオブジェクト全体が複数に分割される。

ステップＳ４０２において、アプリケーションサーバ３０（MPDファイルサーバ）は、各部分Point Cloudオブジェクトのoctree depthを設定してからG-PCC符号化する。これにより、アプリケーションサーバ３０（MPDファイルサーバ）は、部分G-PCCストリームを生成する。これと同時に、アプリケーションサーバ３０（MPDファイルサーバ）は精細度情報を生成する。より具体的には、アプリケーションサーバ３０（MPDファイルサーバ）は、端末装置１０から視聴可能な部分に対応する部分Point Cloudオブジェクトについては、octree depthを所定の値（e.g., 10）に設定し、端末装置１０から視聴不可能な部分に対応する部分Point Cloudオブジェクトについては、octree depthをそれよりも低い値（e.g., 5又は0）に設定する。

ステップＳ４０３において、アプリケーションサーバ３０（MPDファイルサーバ）は、各部分G-PCCストリームを個別のファイルに格納して、メモリに記録する。

ステップＳ４０４において、アプリケーションサーバ３０（MPDファイルサーバ）は、各部分G-PCCストリームの空間位置情報、グルーピング情報、および精細度情報を含むMPDを生成してメモリに格納する。その後、アプリケーションサーバ３０（MPDファイルサーバ）は、メモリに記録された、部分G-PCCストリームが格納されたファイルとともにMPDを端末装置１０（MPEG-DASHクライアント）へ提供する。

［端末装置（MPEG-DASHクライアント）の動作例］
図１７は、端末装置１０（MPEG-DASHクライアント）が、部分G-PCCストリームが格納されたファイルを再生する再生処理を説明するフローチャートである。なお、第１の実施形態における図８のシーケンスに示すステップＳ１０７（変形例の図１２のシーケンスに示すステップＳ２０１、図１３のシーケンスに示すステップＳ３０１）及びステップＳ１０８の詳細な動作例ともいえる。

ステップＳ５０１において、端末装置１０（MPEG-DASHクライアント）は、MPDを取得する。より具体的には、MPDは、アプリケーションサーバ３０（MPDファイルサーバ）から、端末装置１０（MPEG-DASHクライアント）へ提供される。

ステップＳ５０２において、端末装置１０（MPEG-DASHクライアント）は、ステップＳ５０１で取得したMPDの空間位置情報に基づいて、視聴可能な部分G-PCCストリームのAdaptation Setと、視聴不可能な部分G-PCCストリームのAdaptation Setとを識別する。

ステップＳ５０３において、端末装置１０（MPEG-DASHクライアント）は、MPDの精細度情報に基づいて、視聴可能な部分G-PCCストリームについて、高精細なRepresentationを選択する。

ステップＳ５０４において、端末装置１０（MPEG-DASHクライアント）は、MPDの精細度情報に基づいて、視聴不可能な部分G-PCCストリームについて、低精細なRepresentationを選択する。

ステップＳ５０５において、端末装置１０（MPEG-DASHクライアント）は、ステップＳ５０３及びステップＳ５０４で選択したRepresentationから参照される部分G-PCCストリームを全て取得する。

ステップＳ５０６において端末装置１０（MPEG-DASHクライアント）は、取得した部分G-PCCストリームをデコードし、空間位置情報に基づいてPoint Cloudオブジェクトを再構成して表示画面をレンダリングする。そして、レンダリングされたＡＲ画像が、端末装置１０（MPEG-DASHクライアント）の表示（ディスプレイ）に表示される。

ステップＳ５０７において、端末装置１０（MPEG-DASHクライアント）は、ストリームの終端であるか否かを判定する。ステップＳ５０７において、端末装置１０（MPEG-DASHクライアント）が、ストリームの終端でないと判定した場合、処理はステップＳ５０８に進む。

ステップＳ５０８において、端末装置１０（MPEG-DASHクライアント）は、視野方向（視聴方向）が変更されたか否かを判定し、視野方向が変更されていないと判定した場合には処理はステップＳ５０６に戻り、視野方向が変更されたと判定した場合には処理はステップＳ５０２に戻って、以下、同様の処理が繰り返して行われる。ステップＳ５０８における視野方向の変更は、端末装置１０（MPEG-DASHクライアント）に備え付けられた種々のセンサ（上述したセンサの少なくとも１つ）により検出されてもよいし、端末装置１０（MPEG-DASHクライアント）にとってベストなビームに対応するSSB Indexが変更された（Beam switchingが行われた）ことにより検出されてもよい。

一方、ステップＳ５０７において、端末装置１０（MPEG-DASHクライアント）は、ストリームの終端であると判定した場合、処理は終了される。

これにより、端末装置１０は、その端末装置１０の位置から視聴可能な部分（視聴方向に対する表面形状および色の情報）については高精細となるように符号化されたG-PCCストリームを取得し、かつ、それ以外については低精細となる符号化されたG-PCCストリームを取得することができる。これにより、アプリケーションサーバ３０から端末装置１０へのデータ量を抑制しつつ、端末装置１０の実オブジェクトに対する位置を考慮したPoint Cloudオブジェクトの位置合わせを行ってAR画像を出力することができる。特に、スタジアムのような大規模施設においては、端末装置１０の数が膨大になることが想定されるため、ＡＲ／ＶＲイベントのようなユースケースを想定した場合、ネットワーク帯域幅の制限がボトルネックになり得る。したがって、１ユーザに対するデータ量抑制は、ユーザ全体としてのQuality of Experienceの劣化防止に寄与する。さらに、適用されるユースケースが、スタジアムＳＴ等の大規模施設でのＡＲ／ＶＲイベントである場合、その他の場合に比べて端末装置１０（を利用するユーザ）が移動する可能性が低い。ＡＲ／ＶＲイベントを視聴するユーザはスタジアム等の座席に着席した状態で視聴するためである。したがって、本実施形態のように、端末装置１０から視聴不可能な部分（視聴方向に対して反対側の表面形状および色の情報）について低精細（depth=5）又は無描画（depth=0）に設定して符号化したとしても、端末装置１０の移動によって視聴不可能な部分が可視化される可能性又は頻度は低く、この観点でも、ユーザのQuality of Experienceの劣化防止に寄与できる。

＜３．第３の実施形態＞
第３の実施形態では、第１、第２の実施形態及び変形例の応用例が説明される。

上述した第１、第２の実施形態及び変形例において、アプリケーションサーバ３０が取得する3GPP Network（基地局とコアネットワークを含む）の情報（e.g., 上述のビームに関する情報（e.g., SSBのIndex及びそれに対応するアンテナの設定情報のリスト）、ＡＲ画像データの提供先となる端末装置１０にとってベストなビームのSSB Index）のＡＰＩによる取得は、Edge Computingのアーキテクチャ及びEdge Computingに用いられる各種のＡＰＩによって実現されてもよい。

図１８は、Edge Computingが適用されたアプリケーションアーキテクチャの一例を示す図である。図１８に示す図は、例えば3GPP TR23.758に開示されている。

上述した第１、第２の実施形態及び変形例における端末装置１０は、図１８のＵＥに対応してもよい。又はこれに代えて、上述した第１、第２の実施形態及び変形例における端末装置１０は、図１８のＵＥ内の"Application Client(s)"及び"Edge Enabler Client"のうち少なくとも１つに対応していてもよい。上述した第１、第２の実施形態及び変形例における基地局２０（e.g., gNB）及び１又は複数のコアネットワークノード４０（e.g., UPF, AMF, SMF, NEF）は、図１８の"3GPP Network"に含まれていてもよい。上述した第１、第２の実施形態及び変形例におけるアプリケーションサーバ３０は、図１８のEdge Data Network内の"Edge Application Server(s)"及び"Edge Enabler Server"のうち少なくとも１つを含んでいてもよい。又はこれに代えて、Edge Data Network内の"Edge Application Server(s)"及び"Edge Enabler Server"は、異なるアプリケーションサーバであてもよい。さらに又はこれに代えて、上述した第１、第２の実施形態及び変形例におけるアプリケーションサーバ３０は、図１８のEdge Data Network Configuration Serverを含んでいてもよい。上述した" Application Function "は、図１８の"3GPP Network"（より具体的にはコアネットワーク）に含まれていてもよいし、Edge Data Networkに含まれていてもよい。

Edge Enabler Serverは、Edge Application ServerがEdge Data Networkで実行するために必要なサポート機能を提供する。Edge Enabler Serverの機能は、以下を含む。
- Edge Application ServerとのApplication Data Trafficの交換を可能にする構成情報のプロビジョニング、及び
-可用性などのEdge Application Serverに関連する情報をEdge Enabler Clientに提供すること。

したがって、Edge Enabler Serverは、上記２つの機能の少なくとも一部を含む機能（又は論理ノード）と称されてもよい。

Edge Enabler Clientは、アプリケーションクライアントに必要なサポート機能を提供する。Edge Enabler Clientの機能は以下を含む。
- Edge Application Serverとのアプリケーションデータトラフィックの交換を可能にする、構成情報の取得とプロビジョニング、及び
-エッジデータネットワークで利用可能なエッジアプリケーションサーバーの検出。

したがって、Edge Enabler Clientは、上記２つの機能の少なくとも一部を含む機能（又は論理ノード）と称されてもよい。

Edge Enabler Serverは、Edge Application Serverに対し、Location Reporting APIを開示（expose）する。これは、ＵＥの有効な（Valid）位置のトラッキングと確認をサポートするために行われる。Edge Enabler Server によって開示されるLocation Reporting APIは、ＵＥの位置（位置に関するイベント）をモニタリングするために、NEFにおいてAPI（e.g., northbound API）がリレー（中継、又は転送）され得る。Edge Application Serverは、現在のUEの位置チェックするためのワンタイム報告（単発的な報告）のために、Location Reporting APIをリクエストできる。Edge Application Serverは、UEの位置をトラックするための継続的な報告のためにも、Location Reporting APIをリクエストできる。

図１９は、本開示の第３の実施形態に係る通信システムの処理手順の一例を示すシーケンス図である。図１９では、Edge Enabler Serverが3GPP system（上述した第１、第２の実施形態及び変形例における基地局２０、コアネットワークノード４０を含むネットワーク、又はシステム）からＵＥ（端末装置１０）の位置を検出又は取得するための手順の一例を示している。本シーケンスは、図１８に記載されたReference point: EDGE-2を介して行われてもよい。なお、3GPP systemは3GPP networkとも称される。また、図１９のシーケンス図は、第１の実施形態における図８に示すシーケンスのステップＳ１０１及びステップＳ１０６のうち、少なくとも１つの詳細例であってもよい。

ステップＳ６０１で、Edge Enabler Server は、ＵＥの位置を取得するために、3GPP system (e.g., 5GS, EPS)と相互作用（Interact）（e.g., 通信）を行う。例えば、Edge Enabler ServerはＮＥＦから開示されたＡＰＩを使うことができる。Edge Enabler Serverは、3GPP systemへの位置報告要求のくり返しを避けるために、ＵＥの位置情報の更新をするための継続的位置報告を3GPP systemへ要求できる。これにより、Edge Enabler Serverはいつでも最新のＵＥの位置を検出できる。3GPP systemからEdge Enabler Serverへ提供されるＵＥの位置情報は、ＧＰＳ座標、セルＩＤ、トラッキングエリアＩＤ、及び住所（通り、区）を示す情報のうち、少なくとも１つを含んでいてもよい。さらに、又はこれに代えて、3GPP systemからEdge Enabler Serverへ提供されるＵＥの位置情報は、上述した第１、第２の実施形態及び変形例におけるビームの識別子（e.g., SSB Index）を含んでいてもよい。SSB Indexの代わりにCSI-RSのIndex又はPositioning Reference SignalのIndexが含まれていてもよい。

Edge Enabler Serverは、Edge Application Serverからリクエストされる位置情報の粒度（e.g., ＧＰＳ座標、セルＩＤ、トラッキングエリアＩＤ、住所、ビームの識別子（e.g., SSB Index））を考慮（consider）できる。

なお、図１９のステップＳ６０１における、3GPP systemからEdge Enabler ServerへのＵＥの位置情報の提供の詳細例は後述される。

図２０は、本開示の第３の実施形態に係る通信システムの処理手順の一例を示すシーケンス図である。図２０では、前述のLocation Reporting APIを介してEdge Application ServerがEdge Enabler ServerからＵＥ（端末装置１０）の位置報告を取得する一例を示している。本シーケンスは、図１８に記載されたReference point: EDGE-3を介して行われてもよい。また、図２０のシーケンス図は、第１の実施形態における図８に示すシーケンスのステップＳ１０１及びステップＳ１０６のうち、少なくとも１つの詳細例であってもよい。

ステップＳ７０１で、Edge Application Serverは、Edge Enabler ServerにLocation Reporting API Requestメッセージを送信し、Location Reporting APIを要求する。本メッセージはＵＥ（端末装置１０）の識別子と位置に関する情報（e.g., 位置の粒度）が含まれる。位置の粒度は、報告される位置情報（e.g., ＧＰＳ座標、セルＩＤ、トラッキングエリアＩＤ、及び住所（通り、区）を示す情報、及びビームの識別子（e.g., SSB Index）のうち、少なくとも１つ）のフォーマットを示す。

ステップＳ７０２で、Edge Enabler Serverは、ＵＥ（端末装置１０）の位置を確認する。

ステップＳ７０３で、Edge Enabler Serverは、要求された位置の粒度を考慮して、ＵＥ（端末装置１０）の位置情報（e.g., ＧＰＳ座標、セルＩＤ、トラッキングエリアＩＤ、及び住所（通り、区）を示す情報、及びビームの識別子（e.g., SSB Index）のうち、少なくとも１つ）をレスポンスメッセージ（Location Reporting API Responseメッセージ）で返信する。当該レスポンスメッセージはＵＥ（端末装置１０）の位置のタイムスタンプを含んでいてもよい。

なお、ＵＥ（端末装置１０）の位置情報の報告は、明示的なEdge Application Serverからの要求に基づいて行われなくともよい。例えば、Edge Application Serverは、Edge Enabler Serverに対し、Location Reporting APIはSubscribeしていてもよい。この場合、Edge Enabler Server側でＵＥ（端末装置１０）の位置情報が検出されたことをトリガとして、Edge Enabler ServerからEdge Application ServerへＵＥ（端末装置１０）の位置情報（e.g., ＧＰＳ座標、セルＩＤ、トラッキングエリアＩＤ、及び住所（通り、区）を示す情報、及びビームの識別子（e.g., SSB Index）のうち、少なくとも１つ）が報告されてもよい。

また、図１９に示したシーケンス図に関して説明された動作と、図２０に示したシーケンス図に関して説明された動作は、少なくとも一部が互いに組み合わされてもよい。これらの組み合わせが、上述した第１の実施形態における図８に示すシーケンスのステップＳ１０１及びステップＳ１０６のうち少なくとも一方の動作の詳細例であってもよい。

また、本実施形態では、ＵＥ（端末装置１０）の位置情報の3GPP systemからEdge Application Serverへの提供が、Reference point: EDGE-2及びReference point: EDGE-3を介して行われるものとしたがこれには限られない。例えば、ＵＥ（端末装置１０）の位置情報の3GPP systemからEdge Application Serverへの提供は、Reference point: EDGE-7を介してGPP systemからEdge Application Serverへ直接的に提供されてもよい。又はこれに代えて、例えば、ＵＥ（端末装置１０）の位置情報の3GPP systemからEdge Application Serverへの提供は、Reference point: EDGE-8,EDGE-6及びEDGE-3を介して提供されてもよい。

＜４．第４の実施形態＞
第４の実施形態では、第１、第２、第３の実施形態及び変形例の応用例が説明される。より具体的には第３の実施形態の図１９のステップＳ６０１における、3GPP systemからEdge Enabler ServerへのUEの位置情報の提供の詳細例が説明される。

本実施形態において、3GPP systemからEdge Enabler ServerへのUEの位置情報は、3GPP TS38.455に規定されたNR Positioning Protocol A (NRPPa)が用いられてもよい。NRPPaはNG-RAN node（e.g., 前述又は後述の基地局２０）とLMF（Location Management Function）との間の位置情報に関するプロトコルを定義し、少なくとも以下の２つの機能を提供する：
− E-CID（Enhanced Cell-ID (positioning method)） Location Information Transfer、及び
− OTDOA（Observed Time Difference of Arrival） Information Transfer。

すなわち、NG-RAN nodeからLMFへ報告されたUEの位置情報が、NEFを介して又は直接的にAPIを使ってEdge Enabler Server（又はEdge Application server、Edge Data Network Configuration Server）まで提供されてもよい。なお、LMFは、前述又は後述のコアネットワークノード４０（e.g., 図１９における5GS/EPSに含まれるノード）であってもよい。

NRPPaにおけるE-CID Location Information Transferは、E-CID ポジショニングのために、NG-RAN nodeにLMFとの間で位置情報の交換を許容する。E-CID Location Information Transferは、以下の手順を含む：
ａ）E-CID Measurement Initiation、
ｂ）E-CID Measurement Failure Indication、
ｃ）E-CID Measurement Report、及び
ｄ）E-CID Measurement Termination。

NRPPaにおけるOTDOA Information Transferは、OTDOAポジショニングのために、NG-RAN nodeにLMFとの間で位置情報の交換を許容する。OTDOA Information Transferは、手順OTDOA Information Exchangeを含む。

図２１は、手順E-CID Measurement Initiationを示すシーケンス図である。

図２１のステップＳ８０１において、LMFは、E-CID Measurement Initiation RequestメッセージをNG-RAN nodeへ送信する。E-CID Measurement Initiation Requestメッセージは、IE（Information Element）： Message Type、IE: NRPPa Transaction ID、IE: LMF UE Measurement ID、及びIE: Report Characteristicsを含み、さらに、IE: Measurement Periodicity、IE: Measurement Quantities（少なくとも１つのIE: Measurement Quantities Itemを含む）のうち少なくともいずれかを含んでもよい。IE: Measurement Quantities Itemは、NG-RANに報告させるMeasurement Quantityの種別を指定する。IE: Measurement Quantities Itemには、Cell-ID, Angle of Arrival, Timing Advance Type 1, Timing Advance Type 2, RSRP, 及びRSRQのうち、少なくとも１つが設定される。本実施形態では、さらに又はこれらに代えて、IE: Measurement Quantities Itemにビームの識別子（e.g., SSB Index）が設定されてもよい。本SSB Indexは、前述又は後述の端末装置１０にとってベストなビームの識別子であってもよい。

もし、NG-RAN nodeが要求されたE-CID Measurementを開始可能であれば、ステップＳ８０２において、NG-RAN nodeは、E-CID MEASUREMENT INITIATION RESPONSEメッセージをLMFへ送信する。E-CID MEASUREMENT INITIATION RESPONSEメッセージは、IE: Message Type、IE: NRPPa Transaction ID、IE: LMF UE Measurement ID、及びIE: RAN UE Measurement IDを含み、さらに、IE: E-CID Measurement Result、IE：Cell Portion IDのうち少なくともいずれかを含んでもよい。IE: E-CID Measurement Resultは、Serving Cell ID（サービングセルのNG-RAN Cell Global Identifier）、Serving Cell TAC（サービングセルのTracking Area Code）を含み、さらに、IE: NG-RAN Access Point Positionを含んでもよい。IE: NG-RAN Access Point Positionは、NG-RAN nodeの地理的位置を識別するのに使用される。IE: NG-RAN Access Point Positionは、例えば、前述又は後述のスタジアムSTに複数設定された基地局２０の位置を識別するための位置情報を示していてもよい。IE： Cell Portion IDは、対象となるUE（端末装置１０）のセル内での位置（cell portion）を示す。現在の仕様ではCell Portion IDは、整数0、1、・・・、4095のいずれかが設定され得るよう規定されている。このCell Portion IDが、前述又は後述の端末装置１０にとってベストなビームの識別子（e.g., SSB Index）に対応していてもよい。すなわち、SSB Index の値（e.g., 0、1、・・・、64）とCell Portion IDの値が一致していてもよいし、関連付けられていてもよい。

なお、NG-RAN nodeは、E-CID Measurement Initiation Requestメッセージ内のIE: Report Characteristicsに"OnDemand"が設定されている場合に、返送するE-CID MEASUREMENT INITIATION RESPONSEメッセージに上述したIE: E-CID Measurement Result、IE：Cell Portion IDのうち少なくともいずれかを含んでもよい。

もし、E-CID Measurement Initiation Requestメッセージ内のIE: Report Characteristicsに"Periodic"が設定されている場合、NG-RAN nodeは、手順E-CID Measurement Reportを使って上述したIE: E-CID Measurement Result、IE：Cell Portion IDのうち少なくともいずれかをLMFへ報告する。

図２２は、手順E-CID Measurement Reportを示すシーケンス図である。

図２２のステップＳ９０１において、NG-RAN node（e.g., 基地局２０）は、E-CID MEASUREMENT REPORTメッセージをLMFへ送信する。E-CID MEASUREMENT REPORTメッセージは、上述したE-CID MEASUREMENT INITIATION RESPONSEメッセージに含まれるIEと同じIEを少なくとも１つ含んでもよい。

NG-RAN node（e.g., 基地局２０）からLMF（e.g., コアネットワークノード４０）へ提供されるＵＥ（e.g., 端末装置１０）の位置情報がOTDOA Informationである場合、前述の通り、手順OTDOA Information Exchangeが使用される。

図２３は、手順OTDOA Information Exchangeを示すシーケンス図である。

図２３のステップＳ１００１において、LMFは、OTDOA INFORMATION REQUEST メッセージをNG-RAN nodeへ送信する。ステップＳ１００２において、本メッセージの受信に応じてNG-RAN nodeは、OTDOA INFORMATION RESPONSEメッセージをLMFへ送信する。OTDOA INFORMATION RESPONSEメッセージは、IE: Message Type、IE: NRPPa Transaction ID、及びIE: OTDOA Cellsのうち少なくとも１つを含む。IE: OTDOA Cellsは、Potisioning Reference Signal（PRS）をブロードキャストするServed cell(s)又はServed transmission point(s)を示す。Served cell(s)は、NG-RAN node（e.g., 基地局２０）によってサーブされる１又は複数のセルを示す。Served transmission point(s)はNG-RAN node（e.g., 基地局２０）（例えば、前述又は後述のgNB-DU）に備えられた１又は複数のtransmission point（e.g., アンテナ）を示す。IE: OTDOA Cellsは、１又は複数のOTDOA Cell Informationを含む。OTDOA Cell Informationは、セルID（e.g., NG-RAN Global Cell Identifier）、周波数情報、帯域幅情報、IE: NG-RAN Access Point Position、PRSのID、transmission point（TP）のIDのうち、少なくとも１つを含んでいてもよい。さらに、OTDOA Cell Informationは、前述又は上述のビーム識別子（e.g., SSB Index）を含んでいてもよい。さらに又はこれに代えて、OTDOA Cell Informationに含まれるPRSのIDは、前述又は上述のビーム識別子（e.g., SSB Index）と一致していていもよいし、互いに関連付けられていてもよい。なお、前述又は上述のビーム識別子は、前述又は後述の端末装置１０にとってベストなビームの識別子であってもよい。

本実施形態で説明されたこれらの手順により、端末装置１０にとってベストなビームの識別子が、基地局２０からコアネットワークノード４０まで提供される。そのため、前述又は後述のアプリケーションサーバ３０は、ＡＲ画像データの提供先となる端末装置１０にとってベストなビームのSSB Indexを、API等を介して（例えば第３の実施形態の手順を用いて）コアネットワーク４０から取得することができる。

なお、本実施形態におけるNG-RAN nodeからLMFへのUEの位置情報の提供手順は、他の実施形態（e.g., 第１、第２、第３の実施形態および変形例）とは独立に実施されてもよいし、組み合わせて実施されてもよい。

＜５．その他の実施形態＞
なお、上述した第１、第２の実施形態及び変形例における仮想オブジェクト位置合わせには、既存の自己位置推定方法が適用されてもよい。

自己位置推定の具体的な一例として、端末装置１０（e.g., ＡＲデバイス）は、実空間上の実オブジェクト上に提示されたサイズが既知のマーカ等を、自身に設けられたカメラ等の撮像部１４０により撮像する。そして、端末装置１０は、撮像された画像を解析することで、マーカ（ひいては、当該マーカが提示された実オブジェクト）に対する自身の相対的な位置及び姿勢のうち少なくともいずれかを推定する。なお、以降の説明では、端末装置１０が自身の位置及び姿勢を推定する場合に着目して説明するが、当該端末装置１０は、自身の位置及び姿勢のうちいずれかのみを推定してもよい。

具体的には、画像中に撮像されたマーカの向き（例えば、マーカの模様等の向き）に応じて、当該マーカに対する撮像部１４０（ひいては、当該撮像部１４０を備える端末装置１０）の相対的な方向を推定することが可能である。また、マーカのサイズが既知の場合には、画像中におけるマーカのサイズに応じて、当該マーカと撮像部１４０（即ち、当該撮像部１４０を備える端末装置１０）との間の距離を推定することが可能である。より具体的には、マーカをより遠くから撮像すると、当該マーカは、より小さく撮像されることとなる。また、このとき画像中に撮像される実空間上の範囲は、撮像部１４０の画角に基づき推定することが可能である。以上の特性を利用することで、画像中に撮像されたマーカの大きさ（換言すると、画角内においてマーカが占める割合）に応じて、当該マーカと撮像部１４０との間の距離を逆算することが可能である。以上のような構成により、端末装置１０は、マーカに対する自身の相対的な位置及び姿勢を推定することが可能となる。

また、例えば、上述した第１、第２の実施形態及び変形例に係る端末装置１０に、加速度センサや、角速度センサ（ジャイロセンサ）が設けられ、当該端末装置１０を装着したユーザの頭部の動き（換言すると、端末装置１０自体の動き）を検出可能に構成されていてもよい。具体的な一例として、端末装置１０は、ユーザの頭部の動きとして、ヨー（yaw）方向、ピッチ（pitch）方向、及びロール（roll）方向それぞれの成分を検出することで、当該ユーザの頭部の位置及び姿勢のうち少なくともいずれかの変化を認識してもよい。

また、所謂SLAM（simultaneous localization and mapping）と称される技術が、端末装置１０の自己位置推定に利用されてもよい。SLAMとは、カメラ等の撮像部１４０、各種センサ、エンコーダ等を利用することにより、自己位置推定と環境地図の作成とを並行して行う技術である。より具体的な一例として、SLAM（特に、Visual SLAM）では、撮像部１４０により撮像された動画像に基づき、撮像されたシーン（または、被写体）の３次元形状を逐次的に復元する。そして、撮像されたシーンの復元結果を、撮像部１４０の位置及び姿勢の検出結果と関連付けることで、周囲の環境の地図の作成と、当該環境における撮像部１４０（ひいては、端末装置１０）の位置及び姿勢の推定とが行われる。なお、撮像部１４０の位置及び姿勢については、例えば、端末装置１０に加速度センサや角速度センサ等の各種センサを設けることで、当該センサの検出結果に基づき相対的な変化を示す情報として推定することが可能である。もちろん、撮像部１４０の位置及び姿勢を推定可能であれば、その方法は、必ずしも加速度センサや角速度センサ等の各種センサの検知結果に基づく方法のみには限定されない。

以上のような構成のもとで、例えば、撮像部１４０による既知のマーカの撮像結果に基づく、当該マーカに対する端末装置１０の相対的な位置及び姿勢の推定結果が、上述したSLAMにおける初期化処理や位置補正に利用されてもよい。このような構成により、端末装置１０は、マーカが撮像部１４０の画角内に含まれない状況下においても、従前に実行された初期化や位置補正の結果を受けたSLAMに基づく自己位置推定により、当該マーカ（ひいては、当該マーカが提示された実オブジェクト）に対する自身の位置及び姿勢を推定することが可能となる。

以上の手法が、上述した第１、第２の実施形態及び変形例における位置合わせの手法と共に用いられてもよい。例えば、上述した第１、第２の実施形態及び変形例における位置合わせの手法がSLAMにおける初期化処理や位置補正に利用されてもよい。上述した第１、第２の実施形態及び変形例と既知の手法とを複数組み合わせることにより精度の高い仮想オブジェクトの実オブジェクトに対する位置合わせが実現され得る。

また、大規模施設の例としては上述したスタジアムＳＴ以外にも以下の施設が挙げられる。例えば、大規模施設の例として、コンサートホール、劇場、ライブハウス、広場、競技場、サーキット、競馬場、競輪場、スケートリンク、映画館、闘技場等が挙げられる。

また、同期信号の例としては、SSB、CSI-RS、Positioning Reference Signal等が挙げられる。すなわち、上述のしたいくつかの実施形態および変形例では、SSBの代わりにCSI-RS又はPositioning Reference Signalが使用されてもよい。上述のしたいくつかの実施形態におけるSSB Indexは、CSI-RSの識別子（e.g., CRI(CSI-RS Resource Indicator)）又はPRSの識別子（PRS-ID）に置き換えられてもよい。

また、上述した第１、第２の実施形態及び変形例は、主に3GPP 5G NR Standaloneを対象に説明されたが、適用対象はこれには限られない。例えば、上述した第１、第２の実施形態及び変形例は、主に3GPP 5G NR Non-Standaloneに適用されてもよい。

前述の通り、基地局２０により提供されるセルはServing cellと呼ばれる。Serving cellはPCell（Primary Cell）及びSCell（Secondary Cell）を含む。Dual Connectivity （e.g.EUTRA-EUTRA Dual Connectivity、EUTRA-NR Dual Connectivity（ENDC）、EUTRA-NR Dual Connectivity with 5GC、NR-EUTRA Dual Connectivity（NEDC）、NR-NR Dual Connectivity）がＵＥ（e.g.端末装置１０）に提供される場合、MN（Master Node）によって提供されるPCell及びゼロ又は1以上のSCell(s)はMaster Cell Groupと呼ばれる。さらに、Serving cellはPSCell（Primary Secondary Cell又はPrimary SCG Cell）を含んでもよい。すなわち、Dual Connectivity がUEに提供される場合、SN（Secondary Node）によって提供されるPSCell及びゼロ又は1以上のSCell(s)はSecondary Cell Group（SCG）と呼ばれる。特別な設定（e.g., PUCCH on SCell）がされていない限り、物理上りリンク制御チャネル（PUCCH）はPCell及びPSCellで送信されるが、SCellでは送信されない。また、Radio Link FailureもPCell及びPSCellでは検出されるが、SCellでは検出されない（検出しなくてよい）。このようにPCell及びPSCellは、Serving Cell(s)の中で特別な役割を持つため、Special Cell（SpCell）とも呼ばれる。１つのセルには、１つのDownlink Component Carrierと１つのUplink Component Carrier が対応付けられてもよい。また、１つのセルに対応するシステム帯域幅は、複数の帯域幅部分（Bandwidth Part）に分割されてもよい。この場合、１又は複数のBandwidth PartがUEに設定され、１つのBandwidth PartがActive BWPとして、ＵＥに使用されてもよい。また、セル毎、コンポーネントキャリア毎又はBWP毎に、端末装置１０が使用できる無線資源（例えば、周波数帯域、ヌメロロジー（サブキャリアスペーシング）、スロットフォーマット(Slot configuration)）が異なっていてもよい。

すなわち、上述した第１、第２の実施形態及び変形例における基地局２０は、3GPP 5G NR StandaloneとしてのNR-NR DCのMNまたはSNであってもよいし、3GPP 5G NR Non-StandaloneとしてのENDC、ENDC with 5GC、又はNEDCにおけるgNB (en-gNB)であってもよい。

さらにまた、上述したいくつかの実施形態および変形例における通信システムには、Local 5Gが適用されてもよい。例えば、図４における基地局（gNB）２０（e.g., スタジアムＳＴに複数配置されたgNB）、コアネットワークノード（UPF）４０、及びアプリケーションサーバ３０は、Local 5Gを構成するネットワークノードとして動作してもよい。例えば、スタジアムＳＴがLocal 5Gの提供エリアであってもよい。より具体的には、スタジアムＳＴに複数配置されたgNB及び当該gNBに接続されたUPFが属するPLMN（Public Land Mobile Network）は、MNOが提供する当該スタジアムＳＴ外のモバイルネットワークのPLMNとは異なってもよい。この場合、基地局２０、及びコアネットワークノード４０を介してアプリケーションサーバ３０まで提供される端末装置１０の位置情報（i.e., ビームの識別子）は、Local 5Gのネットワークであることを示す情報（e.g., 当該Local 5Gの識別子、当該Local 5Gを提供するPLMN ID、当該Local 5Gを提供するPLMNに属する基地局２０（e.g., gNB）の識別子（グローバルID）及びコアネットワークノード４０の識別子（グローバルID））と共に基地局２０、及びコアネットワークノード４０を介してアプリケーションサーバ３０まで提供されてもよい。提供方法は上述したいくつかの実施形態における手順、メッセージ、及びプロトコルが使用されてもよい。つまり、上述したLocal 5Gのネットワークであることを示す情報は、上述したいくつかの実施形態におけるメッセージに含まれてもよい。

＜６．補足＞
以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示の技術的範囲はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。

また、本明細書に記載された効果は、あくまで説明的または例示的なものであって限定的ではない。つまり、本開示に係る技術は、上記の効果とともに、または上記の効果に代えて、本明細書の記載から当業者には明らかな他の効果を奏しうる。

なお、本技術は以下のような構成も取ることができる。
（１）
トランシーバと、
実オブジェクトを撮像するためのカメラと、
前記カメラが撮像した前記実オブジェクトに仮想オブジェクトを重畳させる拡張現実画像を表示するためのディスプレイと、
プロセッサと、を有し、
前記プロセッサは、
互いに異なる方向にビームフォーミングされて基地局から送信された複数の同期信号の少なくとも１つを、前記トランシーバを介して受信し、
受信した少なくとも１つの前記同期信号の中から、無線品質が所定の閾値を満たす第１の同期信号を決定し、
前記第１の同期信号を前記基地局へ報告するために、前記第１の同期信号に対応するランダムアクセスオケージョンを用いてランダムアクセスプリアンブルを送信し、
前記ランダムアクセスプリアンブルの送信を含むランダムアクセス処理手順の完了後に、アプリケーションサーバから前記拡張現実画像に関する情報を受信するように構成され、
前記拡張現実画像に関する前記情報は、
前記拡張現実画像の表示に用いる補正情報、または、
前記補正情報に基づいて前記実オブジェクトに対する前記仮想オブジェクトの位置合わせが行われた拡張現実画像データであり、
前記拡張現実画像に関する前記情報が前記補正情報である場合、前記プロセッサは、前記補正情報を使用して前記実オブジェクトに対する前記仮想オブジェクトの位置合わせを行って前記拡張現実画像を生成して前記ディスプレイに出力し、
前記拡張現実画像に関する前記情報が前記補正情報に基づいて前記実オブジェクトに対する前記仮想オブジェクトの位置合わせが行われた前記拡張現実画像データである場合、前記プロセッサは、受信した前記拡張現実画像データに基づき拡張現実画像を前記ディスプレイに出力し、
前記補正情報は、
前記ビームフォーミングされて送信された前記第１の同期信号がカバーするエリアの前記実オブジェクトに対する位置を示すための情報であり、
前記エリアにおいて前記ディスプレイに表示させる前記仮想オブジェクトの向きおよび前記実オブジェクトから前記エリアまでの距離に関する情報を含む、
端末装置。
（２）
前記補正情報は、前記ビームフォーミングされて送信された前記第１の同期信号のインデックスに関連付けられる、（１）に記載の端末装置。
（３）
前記仮想オブジェクトは、Point Cloudオブジェクトであり、
前記Point Cloudオブジェクトは、複数の部分Point Cloudオブジェクトを含み、
複数の前記部分Point Cloudオブジェクトは、ユーザからの見え方に応じた精細度を有する、
（１）または（２）に記載の端末装置。
（４）
複数の前記部分Point Cloudオブジェクトは、前記ユーザが視聴可能な第１の部分Point Cloudオブジェクトを含み、
前記第１の部分Point Cloudオブジェクトのoctree depthは、他の前記部分Point Cloudオブジェクトよりも高精細に設定される、
（３）に記載の端末装置。
（５）
ネットワークインタフェースと、
端末装置に搭載されたカメラによって撮像された実オブジェクトに仮想オブジェクトを重畳させる拡張現実画像を生成するプロセッサと、を有し、
前記プロセッサは、
互いに異なる方向にビームフォーミングされて基地局から送信された複数の同期信号の少なくとも１つの中から、前記端末装置によって決定された第１の同期信号の情報を、前記基地局を介して取得し、
前記端末装置に搭載されたディスプレイに表示するための前記拡張現実画像に関する情報を、前記基地局を介して前記端末装置に送信するように構成され、
前記拡張現実画像に関する前記情報は、
前記第１の同期信号に予め関連付けられた前記拡張現実画像の表示に用いる補正情報、または、
前記補正情報に基づいて前記実オブジェクトに対する前記仮想オブジェクトの位置合わせが行われた拡張現実画像データであり、
前記拡張現実画像に関する前記情報が前記補正情報である場合、前記補正情報を使用して前記実オブジェクトに対する前記仮想オブジェクトの位置合わせを前記端末装置へ行わせるために、前記拡張現実画像データ及び前記補正情報を前記端末装置へ送信し、
前記拡張現実画像に関する前記情報が前記拡張現実画像データである場合、前記プロセッサは、前記補正情報を使用して前記実オブジェクトに対する前記仮想オブジェクトの位置合わせを行って前記拡張現実画像を生成して前記端末装置に送信し、
前記補正情報は、
前記ビームフォーミングされて送信された前記第１の同期信号がカバーするエリアの前記実オブジェクトに対する位置を示すための情報であり、
前記エリアにおいて前記ディスプレイに表示させる前記仮想オブジェクトの向きおよび前記実オブジェクトから前記エリアまでの距離に関する情報を含む、
アプリケーションサーバ。
（６）
前記補正情報は、前記ビームフォーミングされて送信された前記第１の同期信号のインデックスに関連付けられる、（５）に記載のアプリケーションサーバ。
（７）
前記仮想オブジェクトは、Point Cloudオブジェクトであり、
前記Point Cloudオブジェクトは、複数の部分Point Cloudオブジェクトを含み、
複数の前記部分Point Cloudオブジェクトは、ユーザからの見え方に応じた精細度を有する、
（５）または（６）に記載のアプリケーションサーバ。
（８）
複数の前記部分Point Cloudオブジェクトは、前記ユーザが視聴可能な第１の部分Point Cloudオブジェクトを含み、
前記第１の部分Point Cloudオブジェクトのoctree depthは、他の前記部分Point Cloudオブジェクトよりも高精細に設定される、
（７）に記載のアプリケーションサーバ。
（９）
トランシーバと、
実オブジェクトを撮像するためのカメラと、
前記カメラが撮像した前記実オブジェクトに仮想オブジェクトを重畳させる拡張現実画像を表示するためのディスプレイと、
プロセッサと、を有する端末装置に前記拡張現実画像を表示する表示方法であって、
互いに異なる方向にビームフォーミングされて基地局から送信された複数の同期信号の少なくとも１つを、前記トランシーバを介して受信することと、
受信した少なくとも１つの前記同期信号の中から、無線品質が所定の閾値を満たす第１の同期信号を決定することと、
前記第１の同期信号を前記基地局へ報告するために、前記第１の同期信号に対応するランダムアクセスオケージョンを用いてランダムアクセスプリアンブルを送信することと、
前記ランダムアクセスプリアンブルの送信を含むランダムアクセス処理手順の完了後に、アプリケーションサーバから前記拡張現実画像に関する情報を受信することと、を含み、
前記拡張現実画像に関する前記情報は、
前記拡張現実画像の表示に用いる補正情報、または、
前記補正情報に基づいて前記実オブジェクトに対する前記仮想オブジェクトの位置合わせが行われた拡張現実画像データであり、
前記拡張現実画像に関する前記情報が前記補正情報である場合、前記補正情報を使用して前記実オブジェクトに対する前記仮想オブジェクトの位置合わせを行って前記拡張現実画像を生成して前記ディスプレイに出力し、
前記拡張現実画像に関する前記情報が前記補正情報に基づいて前記実オブジェクトに対する前記仮想オブジェクトの位置合わせが行われた前記拡張現実画像データである場合、前記プロセッサは、受信した前記拡張現実画像データに基づき拡張現実画像を前記ディスプレイに出力し、
前記補正情報は、
前記ビームフォーミングされて送信された前記第１の同期信号がカバーするエリアの前記実オブジェクトに対する位置を示すための情報であり、
前記エリアにおいて前記ディスプレイに表示させる前記仮想オブジェクトの向きおよび前記実オブジェクトから前記エリアまでの距離に関する情報を含む、
受信方法。
（１０）
ネットワークインタフェースと、
端末装置に搭載されたカメラによって撮像された実オブジェクトに仮想オブジェクトを重畳させる拡張現実画像を生成するプロセッサと、を有するアプリケーションサーバが前記拡張現実画像に関する情報を送信する送信方法であって、
互いに異なる方向にビームフォーミングされて基地局から送信された複数の同期信号の少なくとも１つの中から、前記端末装置によって決定された第１の同期信号の情報を、前記基地局を介して取得し、
前記端末装置に搭載されたディスプレイに表示するための前記拡張現実画像に関する情報を、前記基地局を介して前記端末装置に送信すること、を含み
前記拡張現実画像に関する前記情報は、
前記第１の同期信号に予め関連付けられた前記拡張現実画像の表示に用いる補正情報、または、
前記補正情報に基づいて前記実オブジェクトに対する前記仮想オブジェクトの位置合わせが行われた拡張現実画像データであり、
前記拡張現実画像に関する前記情報が前記補正情報である場合、前記補正情報を使用して前記実オブジェクトに対する前記仮想オブジェクトの位置合わせを前記端末装置へ行わせるために、前記拡張現実画像データ及び前記補正情報を前記端末装置へ送信し、
前記拡張現実画像に関する前記情報が前記拡張現実画像データである場合、前記補正情報を使用して前記実オブジェクトに対する前記仮想オブジェクトの位置合わせを行って前記拡張現実画像を生成して前記端末装置に送信し、
前記補正情報は、
前記ビームフォーミングされて送信された前記第１の同期信号がカバーするエリアの前記実オブジェクトに対する位置を示すための情報であり、
前記エリアにおいて前記ディスプレイに表示させる前記仮想オブジェクトの向きおよび前記実オブジェクトから前記エリアまでの距離に関する情報を含む、
送信方法。

１０ ＵＥ
２０ 基地局
３０ アプリケーションサーバ
４０ コアネットワークノード
１００、２００ アンテナ部
１１０、２１０ 通信部（トランシーバ）
１２０、２３０ 記憶部（メモリ）
１３０ 表示部（ディスプレイ）
１４０ 撮像部（カメラ）
１５０、２４０、３３０ 制御部（プロセッサ）
２２０、３１０ ネットワーク通信部（NW interface）

Claims (10)

1. トランシーバと、
   実オブジェクトを撮像するためのカメラと、
   前記カメラが撮像した前記実オブジェクトに仮想オブジェクトを重畳させる拡張現実画像を表示するためのディスプレイと、
   プロセッサと、を有し、
   前記プロセッサは、
   互いに異なる方向にビームフォーミングされて基地局から送信された複数の同期信号の少なくとも１つを、前記トランシーバを介して受信し、
   受信した少なくとも１つの前記同期信号の中から、無線品質が所定の閾値を満たす第１の同期信号を決定し、
   前記第１の同期信号を前記基地局へ報告するために、前記第１の同期信号に対応するランダムアクセスオケージョンを用いてランダムアクセスプリアンブルを送信し、
   前記ランダムアクセスプリアンブルの送信を含むランダムアクセス処理手順の完了後に、アプリケーションサーバから前記拡張現実画像に関する情報を受信するように構成され、
   前記拡張現実画像に関する前記情報は、
   前記拡張現実画像の表示に用いる補正情報、または、
   前記補正情報に基づいて前記実オブジェクトに対する前記仮想オブジェクトの位置合わせが行われた拡張現実画像データであり、
   前記拡張現実画像に関する前記情報が前記補正情報である場合、前記プロセッサは、前記補正情報を使用して前記実オブジェクトに対する前記仮想オブジェクトの位置合わせを行って前記拡張現実画像を生成して前記ディスプレイに出力し、
   前記拡張現実画像に関する前記情報が前記補正情報に基づいて前記実オブジェクトに対する前記仮想オブジェクトの位置合わせが行われた前記拡張現実画像データである場合、前記プロセッサは、受信した前記拡張現実画像データに基づき拡張現実画像を前記ディスプレイに出力し、
   前記補正情報は、
   前記ビームフォーミングされて送信された前記第１の同期信号がカバーするエリアの前記実オブジェクトに対する位置を示すための情報であり、
   前記エリアにおいて前記ディスプレイに表示させる前記仮想オブジェクトの向きおよび前記実オブジェクトから前記エリアまでの距離に関する情報を含む、
   端末装置。
2. 前記補正情報は、前記ビームフォーミングされて送信された前記第１の同期信号のインデックスに関連付けられる、請求項１に記載の端末装置。
3. 前記仮想オブジェクトは、Point Cloudオブジェクトであり、
   前記Point Cloudオブジェクトは、複数の部分Point Cloudオブジェクトを含み、
   複数の前記部分Point Cloudオブジェクトは、ユーザからの見え方に応じた精細度を有する、
   請求項２に記載の端末装置。
4. 複数の前記部分Point Cloudオブジェクトは、前記ユーザが視聴可能な第１の部分Point Cloudオブジェクトを含み、
   前記第１の部分Point Cloudオブジェクトのoctree depthは、他の前記部分Point Cloudオブジェクトよりも高精細に設定される、
   請求項３に記載の端末装置。
5. ネットワークインタフェースと、
   端末装置に搭載されたカメラによって撮像された実オブジェクトに仮想オブジェクトを重畳させる拡張現実画像を生成するプロセッサと、を有し、
   前記プロセッサは、
   互いに異なる方向にビームフォーミングされて基地局から送信された複数の同期信号の少なくとも１つの中から、前記端末装置によって決定された第１の同期信号の情報を、前記基地局を介して取得し、
   前記端末装置に搭載されたディスプレイに表示するための前記拡張現実画像に関する情報を、前記基地局を介して前記端末装置に送信するように構成され、
   前記拡張現実画像に関する前記情報は、
   前記第１の同期信号に予め関連付けられた前記拡張現実画像の表示に用いる補正情報、または、
   前記補正情報に基づいて前記実オブジェクトに対する前記仮想オブジェクトの位置合わせが行われた拡張現実画像データであり、
   前記拡張現実画像に関する前記情報が前記補正情報である場合、前記補正情報を使用して前記実オブジェクトに対する前記仮想オブジェクトの位置合わせを前記端末装置へ行わせるために、前記拡張現実画像データ及び前記補正情報を前記端末装置へ送信し、
   前記拡張現実画像に関する前記情報が前記拡張現実画像データである場合、前記プロセッサは、前記補正情報を使用して前記実オブジェクトに対する前記仮想オブジェクトの位置合わせを行って前記拡張現実画像を生成して前記端末装置に送信し、
   前記補正情報は、
   前記ビームフォーミングされて送信された前記第１の同期信号がカバーするエリアの前記実オブジェクトに対する位置を示すための情報であり、
   前記エリアにおいて前記ディスプレイに表示させる前記仮想オブジェクトの向きおよび前記実オブジェクトから前記エリアまでの距離に関する情報を含む、
   アプリケーションサーバ。
6. 前記補正情報は、前記ビームフォーミングされて送信された前記第１の同期信号のインデックスに関連付けられる、請求項５に記載のアプリケーションサーバ。
7. 前記仮想オブジェクトは、Point Cloudオブジェクトであり、
   前記Point Cloudオブジェクトは、複数の部分Point Cloudオブジェクトを含み、
   複数の前記部分Point Cloudオブジェクトは、ユーザからの見え方に応じた精細度を有する、
   請求項６に記載のアプリケーションサーバ。
8. 複数の前記部分Point Cloudオブジェクトは、前記ユーザが視聴可能な第１の部分Point Cloudオブジェクトを含み、
   前記第１の部分Point Cloudオブジェクトのoctree depthは、他の前記部分Point Cloudオブジェクトよりも高精細に設定される、
   請求項７に記載のアプリケーションサーバ。
9. トランシーバと、
   実オブジェクトを撮像するためのカメラと、
   前記カメラが撮像した前記実オブジェクトに仮想オブジェクトを重畳させる拡張現実画像を表示するためのディスプレイと、
   プロセッサと、を有する端末装置に前記拡張現実画像を表示する表示方法であって、
   互いに異なる方向にビームフォーミングされて基地局から送信された複数の同期信号の少なくとも１つを、前記トランシーバを介して受信することと、
   受信した少なくとも１つの前記同期信号の中から、無線品質が所定の閾値を満たす第１の同期信号を決定することと、
   前記第１の同期信号を前記基地局へ報告するために、前記第１の同期信号に対応するランダムアクセスオケージョンを用いてランダムアクセスプリアンブルを送信することと、
   前記ランダムアクセスプリアンブルの送信を含むランダムアクセス処理手順の完了後に、アプリケーションサーバから前記拡張現実画像に関する情報を受信することと、を含み、
   前記拡張現実画像に関する前記情報は、
   前記拡張現実画像の表示に用いる補正情報、または、
   前記補正情報に基づいて前記実オブジェクトに対する前記仮想オブジェクトの位置合わせが行われた拡張現実画像データであり、
   前記拡張現実画像に関する前記情報が前記補正情報である場合、前記補正情報を使用して前記実オブジェクトに対する前記仮想オブジェクトの位置合わせを行って前記拡張現実画像を生成して前記ディスプレイに出力し、
   前記拡張現実画像に関する前記情報が前記補正情報に基づいて前記実オブジェクトに対する前記仮想オブジェクトの位置合わせが行われた前記拡張現実画像データである場合、前記プロセッサは、受信した前記拡張現実画像データに基づき拡張現実画像を前記ディスプレイに出力し、
   前記補正情報は、
   前記ビームフォーミングされて送信された前記第１の同期信号がカバーするエリアの前記実オブジェクトに対する位置を示すための情報であり、
   前記エリアにおいて前記ディスプレイに表示させる前記仮想オブジェクトの向きおよび前記実オブジェクトから前記エリアまでの距離に関する情報を含む、
   受信方法。
10. ネットワークインタフェースと、
    端末装置に搭載されたカメラによって撮像された実オブジェクトに仮想オブジェクトを重畳させる拡張現実画像を生成するプロセッサと、を有するアプリケーションサーバが前記拡張現実画像に関する情報を送信する送信方法であって、
    互いに異なる方向にビームフォーミングされて基地局から送信された複数の同期信号の少なくとも１つの中から、前記端末装置によって決定された第１の同期信号の情報を、前記基地局を介して取得し、
    前記端末装置に搭載されたディスプレイに表示するための前記拡張現実画像に関する情報を、前記基地局を介して前記端末装置に送信すること、を含み
    前記拡張現実画像に関する前記情報は、
    前記第１の同期信号に予め関連付けられた前記拡張現実画像の表示に用いる補正情報、または、
    前記補正情報に基づいて前記実オブジェクトに対する前記仮想オブジェクトの位置合わせが行われた拡張現実画像データであり、
    前記拡張現実画像に関する前記情報が前記補正情報である場合、前記補正情報を使用して前記実オブジェクトに対する前記仮想オブジェクトの位置合わせを前記端末装置へ行わせるために、前記拡張現実画像データ及び前記補正情報を前記端末装置へ送信し、
    前記拡張現実画像に関する前記情報が前記拡張現実画像データである場合、前記補正情報を使用して前記実オブジェクトに対する前記仮想オブジェクトの位置合わせを行って前記拡張現実画像を生成して前記端末装置に送信し、
    前記補正情報は、
    前記ビームフォーミングされて送信された前記第１の同期信号がカバーするエリアの前記実オブジェクトに対する位置を示すための情報であり、
    前記エリアにおいて前記ディスプレイに表示させる前記仮想オブジェクトの向きおよび前記実オブジェクトから前記エリアまでの距離に関する情報を含む、
    送信方法。

Images