(57)【要約】  ユーザ端末は、上りリンクにおけるデータの遅延に関する測定を行う制御部と、前記測定の結果を示す情報を無線基地局に報告する送信部とを備える。
2016185986.tif 000002
【特許請求の範囲】
【請求項１】
上りリンクにおけるデータの遅延に関する測定を行う制御部と、
前記測定の結果を示す情報を無線基地局に報告する送信部とを備えることを特徴とするユーザ端末。
【請求項２】
前記送信部は、前記測定の結果が生成されたタイミングで、前記測定の結果を前記無線基地局に報告することを特徴とする請求項１に記載のユーザ端末。
【請求項３】
前記送信部は、所定の閾値を上回った前記測定の結果が生成されたタイミングで、前記測定の結果を前記無線基地局に報告することを特徴とする請求項２に記載のユーザ端末。
【請求項４】
前記所定の閾値は、前記無線基地局から個別に受信した前記測定を設定するための情報に含まれることを特徴とする請求項３に記載のユーザ端末。
【請求項５】
前記送信部は、所定のタイミングで、前記測定の結果を生成すると共に前記測定の結果を前記無線基地局に報告し、
前記所定のタイミングを示す情報は、前記無線基地局から個別に受信した測定を設定するための情報に含まれることを特徴とする請求項１に記載のユーザ端末。
【請求項６】
前記遅延は、キューイング遅延であることを特徴とする請求項１から５のいずれか一項に記載のユーザ端末。
【請求項７】
記憶部と、
少なくとも位置情報を含むＭＤＴ測定の結果を生成するとともに、前記ＭＤＴ測定の結果を前記記憶部に格納する制御部と、
前記記憶部に格納された前記ＭＤＴ測定の結果を無線基地局に報告する送信部とを備え、
前記制御部は、セルラ通信以外の通信によって生じる装置内干渉が検出される前に、前記ＭＤＴ測定の結果を前記記憶部に格納することを特徴とするユーザ端末。
【請求項８】
前記制御部は、
前記装置内干渉が検出された場合であっても、前記ＭＤＴ測定の結果を格納するための設定情報を維持するとともに、
前記装置内干渉が解消した場合に、前記設定情報に従って前記ＭＤＴ測定の結果の前記記憶部への格納を再開することを特徴とする請求項７に記載のユーザ端末。
【請求項９】
前記制御部は、
前記装置内干渉を検出すると、前記ＭＤＴ測定結果の前記記憶部への格納を停止することを特徴とする請求項７又は８に記載のユーザ端末。
【請求項１０】
前記制御部は、
前記装置内干渉を検出すると、前記装置内干渉が生じていることを示すインディケーションを前記無線基地局に報告することを特徴とする請求項７から９のいずれか一項に記載のユーザ端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線環境の測定結果を無線基地局に報告するユーザ端末に関する。
【背景技術】
【０００２】
移動通信システムの標準化プロジェクトである３ＧＰＰ（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）では、ユーザが所持するユーザ端末を利用することによって、無線環境の測定及び収集を自動化する技術であるＭＤＴ（Ｍｉｎｉｍｉｚａｔｉｏｎ  ｏｆ  Ｄｒｉｖｅ  Ｔｅｓｔ）の仕様策定が進められている（例えば、非特許文献１）。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】3GPP TS 37.320 V12.2.0: “Radio measurement collection for Minimization of Drive Tests (MDT); Overall description; Stage 2”, 2014-09
【発明の概要】
【０００４】
第１の特徴に係るユーザ端末は、上りリンクにおけるデータの遅延に関する測定を行う制御部と、前記測定の結果を示す情報を無線基地局に報告する送信部とを備える。
【０００５】
第２の特徴に係るユーザ端末は、記憶部と、少なくとも位置情報を含むＭＤＴ測定の結果を生成するとともに、前記ＭＤＴ測定の結果を前記記憶部に格納する制御部と、前記記憶部に格納された前記ＭＤＴ測定の結果を無線基地局に報告する送信部とを備える。前記制御部は、セルラ通信以外の通信によって生じる装置内干渉が検出される前に、前記ＭＤＴ測定の結果を前記記憶部に格納する。
【図面の簡単な説明】
【０００６】
【図１】第一実施形態に係るＬＴＥシステムの構成図である。
【図２】第一実施形態に係るＵＥ１００のブロック図である。
【図３】第一実施形態に係るｅＮＢ２００のブロック図である。
【図４】第一実施形態に係る無線インターフェイスのプロトコルスタック図である。
【図５】第一実施形態に係るＬＴＥシステムで使用される無線フレームの構成図である。
【図６】第一実施形態に係る適用シーンを説明するための図である。
【図７】第一実施形態に係る移動通信方法を示すシーケンス図である。
【図８】第一実施形態に係る移動通信方法を示すシーケンス図である。
【図９】変更例１に係る移動通信方法を示すシーケンス図である。
【図１０】変更例１に係る移動通信方法を示すシーケンス図である。
【図１１】変更例２に係る装置内干渉を説明するための図である。
【図１２】付記１に係る、ＵＥによるＩＤＣ干渉関連動作の異なるフェーズを示す図である。
【図１３】付記５に係る、Ｉｍｍｅｉｄａｔｅ  ＭＤＴを示すシーケンス図である。
【図１４】付記５に係る、Ｌｏｇｇｅｄ  ＭＤＴ  ｉｎ  Ｃｏｎｎｅｃｔｅｄを示すシーケンス図である。
【発明を実施するための形態】
【０００７】
［開示の概要］
第１に、開示の概要に係るユーザ端末は、他のユーザ端末との直接的な通信であるＤ２Ｄ通信を行うためのサイドリンクを介して、前記他のユーザ端末に送信したデータの送達確認情報を受信する受信部と、前記送達確認情報に基づいて、前記サイドリンクのサービス品質の測定結果を生成する制御部と、無線基地局とセルラ通信を行うための上りリンクを介して、前記サービス品質の測定結果を前記無線基地局に報告する送信部とを備える。
【０００８】
開示の概要では、ユーザ端末は、Ｄ２Ｄ通信を行うためのサイドリンクのサービス品質の測定結果を無線基地局に報告する。これによって、サービス品質の測定結果を用いて適切なスケジューリングを行うことができる。例えば、サービス品質を満たしていないユーザ端末に割り当てるリソース量を増大することができる。
【０００９】
第２に、開示の概要に係るユーザ端末は、無線基地局に対する上りリンクにおけるデータの上り遅延時間の測定結果を生成する制御部と、前記上り遅延時間の測定結果を無線基地局に報告する送信部とを備える。
【００１０】
開示の概要では、ユーザ端末は、無線基地局に対する上りリンクにおけるデータの上り遅延時間の測定結果を無線基地局に報告する。これによって、上り遅延時間の測定結果を用いて適切なスケジューリングを行うことができる。例えば、上り遅延値時間が大きいユーザ端末に割り当てるリソース量を増大することができる。
【００１１】
第３に、開示の概要に係るユーザ端末は、少なくとも位置情報を含むＭＤＴ測定結果を生成するとともに、前記ＭＤＴ測定結果を記憶部に格納する制御部と、前記記憶部に記憶された前記ＭＤＴ測定結果を無線基地局に報告する送信部とを備え、前記制御部は、セルラ通信以外の通信によって生じる装置内干渉が検出される前において、前記ＭＤＴ測定結果を前記記憶部に格納する。
【００１２】
開示の概要では、ユーザ端末は、セルラ通信以外の通信によって生じる装置内干渉が検出される前において、ＭＤＴ測定結果を記憶部に格納する。すなわち、装置内干渉が検出される後におけるＭＤＴ測定結果が記憶部に格納されないため、装置内干渉によって悪影響を受けたＭＤＴ測定結果の記憶部への格納が抑制される。従って、ユーザ端末の負荷増大を抑制しながらも、無線基地局などの上位ノードによって、装置内干渉によって悪影響を受けたＭＤＴ測定結果を除外する手間を省くことができる。
【００１３】
［第一実施形態］
以下において、移動通信システムとして、３ＧＰＰ規格に基づいたＬＴＥシステムを例に挙げて、第一実施形態を説明する。
【００１４】
（システム構成）
第一実施形態に係るＬＴＥシステムのシステム構成について説明する。図１は、第一実施形態に係るＬＴＥシステムの構成図である。
【００１５】
図１に示すように、第一実施形態に係るＬＴＥシステムは、ＵＥ（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）１００、Ｅ−ＵＴＲＡＮ（Ｅｖｏｌｖｅｄ−ＵＭＴＳ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）１０、及びＥＰＣ（Ｅｖｏｌｖｅｄ  Ｐａｃｋｅｔ  Ｃｏｒｅ）２０を備える。
【００１６】
ＵＥ１００は、ユーザ端末に相当する。ＵＥ１００は、移動型の通信装置であり、ｅＮＢ２００によって形成されるセル（ＵＥ１００がＲＲＣコネクティッド状態である場合には、サービングセル）との無線通信を行う。ＵＥ１００の構成については後述する。
【００１７】
Ｅ−ＵＴＲＡＮ１０は、無線アクセスネットワークに相当する。Ｅ−ＵＴＲＡＮ１０は、ｅＮＢ２００（ｅｖｏｌｖｅｄ  Ｎｏｄｅ−Ｂ）を含む。ｅＮＢ２００は、無線基地局に相当する。ｅＮＢ２００は、Ｘ２インターフェイスを介して相互に接続される。ｅＮＢ２００の構成については後述する。
【００１８】
ｅＮＢ２００は、１又は複数のセルを形成しており、自セルとの接続を確立したＵＥ１００との無線通信を行う。ｅＮＢ２００は、無線リソース管理（ＲＲＭ）機能、ユーザデータのルーティング機能、モビリティ制御・スケジューリングのための測定制御機能などを有する。「セル」は、無線通信エリアの最小単位を示す用語として使用される他に、ＵＥ１００との無線通信を行う機能を示す用語としても使用される。
【００１９】
ＥＰＣ２０は、コアネットワークに相当する。ＥＰＣ２０は、ＭＭＥ（Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ）／Ｓ−ＧＷ（Ｓｅｒｖｉｎｇ−Ｇａｔｅｗａｙ）３００を含む。ＭＭＥは、ＵＥ１００に対する各種モビリティ制御などを行う。Ｓ−ＧＷは、ユーザデータの転送制御を行う。ＭＭＥ／Ｓ−ＧＷ３００は、Ｓ１インターフェイスを介してｅＮＢ２００と接続される。なお、Ｅ−ＵＴＲＡＮ１０及びＥＰＣ２０は、ＬＴＥシステムのネットワークを構成する。
【００２０】
図２は、ＵＥ１００のブロック図である。図２に示すように、ＵＥ１００は、複数のアンテナ１０１、無線送受信機１１０、ユーザインターフェイス１２０、ＧＮＳＳ（Ｇｌｏｂａｌ  Ｎａｖｉｇａｔｉｏｎ  Ｓａｔｅｌｌｉｔｅ  Ｓｙｓｔｅｍ）受信機１３０、バッテリ１４０、メモリ１５０、及びプロセッサ１６０を備える。メモリ１５０及びプロセッサ１６０は、制御部を構成する。無線送受信機１１０及びプロセッサ１６０は、送信部及び受信部を構成する。ＵＥ１００は、ＧＮＳＳ受信機１３０を有していなくてもよい。また、メモリ１５０をプロセッサ１６０と一体化し、このセット（すなわち、チップセット）をプロセッサとしてもよい。
【００２１】
アンテナ１０１及び無線送受信機１１０は、無線信号の送受信に用いられる。無線送受信機１１０は、プロセッサ１６０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナ１０１から送信する。また、無線送受信機１１０は、アンテナ１０１が受信する無線信号をベースバンド信号（受信信号）に変換してプロセッサ１６０に出力する。
【００２２】
ユーザインターフェイス１２０は、ＵＥ１００を所持するユーザとのインターフェイスであり、例えば、ディスプレイ、マイク、スピーカ、及び各種ボタンなどを含む。ユーザインターフェイス１２０は、ユーザからの操作を受け付けて、受け付けた操作の内容を示す信号をプロセッサ１６０に出力する。ＧＮＳＳ受信機１３０は、ＵＥ１００の地理的な位置を示す位置情報を得るために、ＧＮＳＳ信号を受信して、受信した信号をプロセッサ１６０に出力する。バッテリ１４０は、ＵＥ１００の各ブロックに供給すべき電力を蓄える。
【００２３】
メモリ１５０は、プロセッサ１６０により実行されるプログラム、及びプロセッサ１６０による処理に使用される情報を記憶する。プロセッサ１６０は、ベースバンド信号の変調・復調及び符号化・復号などを行うベースバンドプロセッサと、メモリ１５０に記憶されるプログラムを実行して各種の処理を行うＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）とを含む。プロセッサ１６０は、さらに、音声・映像信号の符号化・復号を行うコーデックを含んでもよい。プロセッサ１６０は、後述する各種の処理及び各種の通信プロトコルを実行する。
【００２４】
図３は、ｅＮＢ２００のブロック図である。図３に示すように、ｅＮＢ２００は、複数のアンテナ２０１、無線送受信機２１０、ネットワークインターフェイス２２０、メモリ２３０、及びプロセッサ２４０を備える。メモリ２３０及びプロセッサ２４０は、制御部を構成する。無線送受信機２１０（及び／又はネットワークインターフェイス２２０）及びプロセッサ２４０は、送信部及び受信部を構成する。また、メモリ２３０をプロセッサ２４０と一体化し、このセット（すなわち、チップセット）をプロセッサとしてもよい。
【００２５】
アンテナ２０１及び無線送受信機２１０は、無線信号の送受信に用いられる。無線送受信機２１０は、プロセッサ２４０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナ２０１から送信する。また、無線送受信機２１０は、アンテナ２０１が受信する無線信号をベースバンド信号（受信信号）に変換してプロセッサ２４０に出力する。
【００２６】
ネットワークインターフェイス２２０は、Ｘ２インターフェイスを介して隣接ｅＮＢ２００と接続され、Ｓ１インターフェイスを介してＭＭＥ／Ｓ−ＧＷ３００と接続される。ネットワークインターフェイス２２０は、Ｘ２インターフェイス上で行う通信及びＳ１インターフェイス上で行う通信に用いられる。
【００２７】
メモリ２３０は、プロセッサ２４０により実行されるプログラム、及びプロセッサ２４０による処理に使用される情報を記憶する。プロセッサ２４０は、ベースバンド信号の変調・復調及び符号化・復号などを行うベースバンドプロセッサと、メモリ２３０に記憶されるプログラムを実行して各種の処理を行うＣＰＵとを含む。プロセッサ２４０は、後述する各種の処理及び各種の通信プロトコルを実行する。
【００２８】
図４は、ＬＴＥシステムにおける無線インターフェイスのプロトコルスタック図である。図４に示すように、無線インターフェイスプロトコルは、ＯＳＩ参照モデルの第１層乃至第３層に区分されており、第１層は物理（ＰＨＹ）層である。第２層は、ＭＡＣ（Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）層、ＲＬＣ（Ｒａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ）層、及びＰＤＣＰ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｃｏｎｖｅｒｇｅｎｃｅ  Ｐｒｏｔｏｃｏｌ）層を含む。第３層は、ＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）層を含む。
【００２９】
物理層は、符号化・復号、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行う。ＵＥ１００の物理層とｅＮＢ２００の物理層との間では、物理チャネルを介してユーザデータ及び制御情報が伝送される。
【００３０】
ＭＡＣ層は、データの優先制御、ハイブリッドＡＲＱ（ＨＡＲＱ）による再送処理、及びランダムアクセス手順などを行う。ＵＥ１００のＭＡＣ層とｅＮＢ２００のＭＡＣ層との間では、トランスポートチャネルを介してユーザデータ及び制御情報が伝送される。ｅＮＢ２００のＭＡＣ層は、上下リンクのトランスポートフォーマット（トランスポートブロックサイズ、変調・符号化方式（ＭＣＳ））及びＵＥ１００への割当リソースブロックを決定するスケジューラを含む。
【００３１】
ＲＬＣ層は、ＭＡＣ層及び物理層の機能を利用してデータを受信側のＲＬＣ層に伝送する。ＵＥ１００のＲＬＣ層とｅＮＢ２００のＲＬＣ層との間では、論理チャネルを介してユーザデータ及び制御情報が伝送される。
【００３２】
ＰＤＣＰ層は、ヘッダ圧縮・伸張、及び暗号化・復号化を行う。また、ＰＤＣＰ層には、データユニット（ＰＤＣＰ  ＰＤＵ）を送信するための送信エンティティ又はデータユニット（ＰＤＣＰ  ＰＤＵ）を受信するための受信エンティティが形成されることに留意すべきである。
【００３３】
ＲＲＣ層は、制御情報を取り扱う制御プレーンでのみ定義される。ＵＥ１００のＲＲＣ層とｅＮＢ２００のＲＲＣ層との間では、各種設定のための制御情報（ＲＲＣメッセージ）が伝送される。ＲＲＣ層は、無線ベアラの確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。ＵＥ１００のＲＲＣとｅＮＢ２００のＲＲＣとの間に接続（ＲＲＣ接続）がある場合に、ＵＥ１００はＲＲＣコネクティッド状態であり、ＵＥ１００のＲＲＣとｅＮＢ２００のＲＲＣとの間に接続（ＲＲＣ接続）がない場合に、ＵＥ１００はＲＲＣアイドル状態である。
【００３４】
ＲＲＣ層の上位に位置するＮＡＳ（Ｎｏｎ−Ａｃｃｅｓｓ  Ｓｔｒａｔｕｍ）層は、セッション管理及びモビリティ管理などを行う。
【００３５】
図５は、ＬＴＥシステムで使用される無線フレームの構成図である。ＬＴＥシステムは、下りリンクにはＯＦＤＭＡ（Ｏｒｔｈｏｇｏｎａｌ  Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅｘｉｎｇ  Ａｃｃｅｓｓ）、上りリンクにはＳＣ−ＦＤＭＡ（Ｓｉｎｇｌｅ  Ｃａｒｒｉｅｒ  Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ）がそれぞれ適用される。
【００３６】
図５に示すように、無線フレームは、時間方向に並ぶ１０個のサブフレームで構成される。各サブフレームは、時間方向に並ぶ２個のスロットで構成される。各サブフレームの長さは１ｍｓであり、各スロットの長さは０．５ｍｓである。各サブフレームは、周波数方向に複数個のリソースブロック（ＲＢ）を含み、時間方向に複数個のシンボルを含む。各リソースブロックは、周波数方向に複数個のサブキャリアを含む。１つのシンボル及び１つのサブキャリアにより１つのリソースエレメント（ＲＥ）が構成される。また、ＵＥ１００に割り当てられる無線リソース（時間・周波数リソース）のうち、周波数リソースはリソースブロックにより特定でき、時間リソースはサブフレーム（又はスロット）により特定できる。
【００３７】
（適用シーン）
以下において、適用シーンについて説明する。図６は、第一実施形態に係る適用シーンを説明するための図である。
【００３８】
図６に示すように、適用シーンでは、ｅＮＢ２００が有するセル内にＵＥ１００＃１が少なくとも在圏しているケースを想定する。このようなケースにおいて、ＵＥ１００＃１及びｅＮＢ２００は、セルラ通信を行っており、ＵＥ１００＃１及びＵＥ１００＃２は、ＵＥ間の直接的な通信であるＤ２Ｄ通信を行っている。
【００３９】
ＵＥ１００＃２は、ｅＮＢ２００が有するセル内に位置していてもよい（Ｉｎ−Ｃｏｖｅｒａｇｅ）。或いは、ＵＥ１００＃２は、ｅＮＢ２００が有するセル内に位置していなくてもよい（Ｏｕｔ−ｏｆ−Ｃｏｖｅｒａｇｅ）。
【００４０】
但し、ＵＥ１００＃１とＵＥ１００＃２との間のＤ２Ｄ通信で用いる無線リソースは、ｅＮＢ２００によって指定される。具体的には、ｅＮＢ２００は、ＵＥ１００＃１に対して、Ｄ２Ｄ通信で用いる無線リソースの割り当て情報を含むメッセージ（ＤＣＩ；Ｄｏｗｎｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｉｎｆｏｒｍａｔｉｏｎ）を送信する。このようなメッセージは、“ＤＣＩ  Ｆｏｒｍａｔ  ５”と称されることもある。
【００４１】
このような前提下において、ＵＥ１００＃１（受信部）は、Ｄ２Ｄ通信を行うためのサイドリンクを介して、ＵＥ１００＃２に送信したデータの送達確認情報をＵＥ１００＃２から受信する。ＵＥ１００＃１（制御部）は、送達確認情報に基づいて、サイドリンクのサービス品質の測定結果を生成する。ＵＥ１００＃１（送信部）は、ｅＮＢ２００とセルラ通信を行うための上りリンクを介して、サービス品質の測定結果をｅＮＢ２００に報告する。
【００４２】
サービス品質の測定結果は、サイドリンクにおいて消失したデータ量（以下、サイドリンクデータロス）、サイドリンクにおけるＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）層のスループット（以下、サイドリンクＩＰスループット）、ＵＥ１００＃２が受信に成功したデータ量（以下、サイドリンクデータ量）の中から選択された１以上のデータである。
【００４３】
サイドリンクデータロスは、例えば、以下に示す式によって算出可能である。
【００４４】
【数１】
2016185986.tif 000003
【００４５】
但し、Ｍ（Ｔ，ｑｃｉ）は、サイドリンクにおけるＱＣＩ（ＱｏＳ  Ｃｌａｓｓ  Ｉｄｅｎｔｉｆｉｅｒ）毎のパケットのロスを示す値である。Ｄｌｏｓｓ（Ｔ，ｑｃｉ）は、サイドリンクで消失したＰＤＣＰ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｃｏｎｖｅｒｇｅｎｃｅ  Ｐｒｏｔｏｃｏｌ）パケットの数であり、時間Ｔにおいて上位レイヤに導かれなかったＱＣＩ＝ｑｃｉのＰＤＣＰパケットの数を示している。Ｎｌｏｓｓ（Ｔ，ｑｃｉ）は、サイドリンクで送信されたＰＤＣＰ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｃｏｎｖｅｒｇｅｎｃｅ  Ｐｒｏｔｏｃｏｌ）パケットの総数であり、時間ＴにおけるＱＣＩ＝ｑｃｉのＰＤＣＰパケットの総数を示している。Ｔは、サイドリンクデータロスの測定が行われる期間を示している。
【００４６】
サイドリンクＩＰスループットは、例えば、以下に示す式によって算出可能である。
【００４７】
【数２】
2016185986.tif 000004
【００４８】
但し、ＴｈｐＴｉｍｅＳＩは、データ量が１つのＴＴＩにおいて十分に送信可能な量である場合に、“０”がセットされるパラメータであり、他の場合には、“Ｔ１−Ｔ２”がセットされるパラメータである。Ｔ１は、測定期間の最後においてデータが継続している場合には、測定期間の終了時間がセットされるパラメータであり、他の場合には、測定期間に含まれるＴＴＩのうち、データ送信に用いられた最後のＴＴＩの終了時間がセットされるパラメータである。Ｔ２は、測定期間の最初においてデータが継続している場合には、測定期間の開始時間がセットされるパラメータであり、他の場合には、測定期間に含まれるＴＴＩのうち、データ送信に用いられた最初のＴＴＩの開始時間がセットされるパラメータである。ＴｈｐＶｏｌＩＰは、サイドリンクで受信されたＰＤＣＰ層のＳＤＵ（単位＝ｋｂｉｔｓ）から、データ送信で用いられた最後のＴＴＩで受信したデータ量を差し引いた値である。
【００４９】
サイドリンクデータ量は、測定期間においてＵＥ１００＃２が受信に成功したＰＤＣＰ層のＳＤＵのビット数である。
【００５０】
ここで、サービス品質の測定結果をｅＮＢ２００に報告するタイミングとしては、（Ａ）Ｉｍｍｅｄｉａｔｅ  ＭＤＴを利用するケース及び（Ｂ）Ｌｏｇｇｅｄ  ＭＤＴ  ｉｎ  Ｃｏｎｎｅｃｔｅｄを利用するケースが考えられる。
【００５１】
（Ａ）Ｉｍｍｅｄｉａｔｅ  ＭＤＴ
Ｉｍｍｅｄｉａｔｅ  ＭＤＴでは、接続状態にあるＵＥ１００は、ｅＮＢ２００から測定設定情報（ＲＲＭ  Ｍｅａｓｕｒｅｍｅｎｔ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ）を受信し、測定設定情報に含まれる各種の測定設定パラメータを記憶する。測定設定パラメータは、サービス品質の測定結果を報告するトリガである報告トリガを含む。ＵＥ１００は、報告トリガに対応するイベントの発生に応じて、サービス品質の測定結果を生成するとともに、サービス品質の測定結果をｅＮＢ２００に報告する。
【００５２】
具体的には、上述したＵＥ１００＃１は、サービス品質の測定結果が生成されたタイミングで、サービス品質の測定結果をｅＮＢ２００に報告する。或いは、ＵＥ１００＃１は、所定の閾値を下回ったサービス品質の測定結果が生成されたタイミングで、所定の閾値を下回ったサービス品質の測定結果をｅＮＢ２００に報告してもよい。
【００５３】
所定の閾値は、測定設定情報に含まれることが好ましい。所定の閾値は、予め定義された値であってもよい。サービス品質の測定結果は、ＵＥ１００の位置情報を含むことが好ましい。
【００５４】
（Ｂ）Ｌｏｇｇｅｄ  ＭＤＴ  ｉｎ  Ｃｏｎｎｅｃｔｅｄ
Ｌｏｇｇｅｄ  ＭＤＴ  ｉｎ  Ｃｏｎｎｅｃｔｅｄでは、接続状態にあるＵＥ１００は、ｅＮＢ２００から測定設定情報（Ｌｏｇｇｅｄ  Ｍｅａａｓｕｒｅｍｅｎｔ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ）を受信し、測定設定情報に含まれる各種のＭＤＴ設定パラメータを記憶する。ＭＤＴ設定パラメータは、サービス品質の測定結果を生成するトリガである生成トリガを含む。ＵＥ１００は、生成トリガに対応するイベントの発生に応じて、サービス品質の測定結果を記憶部に記憶（ログ）する。ＵＥ１００は、ｅＮＢ２００から受信する報告要求に応じて、記憶部に記憶されたサービス品質の測定結果をｅＮＢ２００に報告する。
【００５５】
具体的には、上述したＵＥ１００＃１は、サービス品質の測定結果を記憶部に格納する。上述したＵＥ１００＃１は、ｅＮＢ２００から報告要求を受信したタイミングで、記憶部に記憶されたサービス品質の測定結果をｅＮＢ２００に報告する。或いは、ＵＥ１００＃１は、ｅＮＢ２００から報告要求を受信したタイミングで、記憶部に記憶されたサービス品質の測定結果のうち、所定の閾値を下回るサービス品質の測定結果をｅＮＢ２００に報告する。ここで、ＵＥ１００＃１は、所定の閾値を下回るサービス品質の測定結果のみを記憶部に格納するように構成されていてもよい。
【００５６】
所定の閾値は、測定設定情報に含まれることが好ましい。所定の閾値は、予め定義された値であってもよい。サービス品質の測定結果は、ＵＥ１００の位置情報を含むことが好ましい。
【００５７】
Ｌｏｇｇｅｄ  ＭＤＴ  ｉｎ  Ｃｏｎｎｅｃｔｅｄにおいて、ＵＥ１００は、ＲＲＣアイドル状態からＲＲＣコネクティッド状態に遷移する場合に、サービス品質の測定結果が記憶部に格納されている旨を示す情報（Ａｖａｉｌａｂｌｅ  Ｉｎｄｉｃａｔｉｏｎ）をｅＮＢ２００に通知してもよい。或いは、ＵＥ１００は、ソースのｅＮＢ２００からターゲットのｅＮＢ２００へのハンドオーバを行う際に、サービス品質の測定結果が記憶部に格納されている旨を示す情報（Ａｖａｉｌａｂｌｅ  Ｉｎｄｉｃａｔｉｏｎ）をターゲットのｅＮＢ２００に送信してもよい。このようなケースにおいて、ｅＮＢ２００は、サービス品質の測定結果が記憶部に格納されている旨を示す情報（Ａｖａｉｌａｂｌｅ  Ｉｎｄｉｃａｔｉｏｎ）に応じて、サービス品質の測定結果の報告要求をＵＥ１００に送信する。
【００５８】
或いは、ｅＮＢ２００は、Ｄ２Ｄ通信で用いるＵＥ１００のバッファの状態を示すバッファステータスレポート（ＢＳＲ）をＵＥ１００から受信するとともに、バッファステータスレポートに基づいて、Ｄ２Ｄ通信で送信すべきデータがあるか否かを判定してもよい。ｅＮＢ２００は、Ｄ２Ｄ通信で送信すべきデータがない場合に、Ｄ２Ｄ通信が終了したと判定して、サービス品質の測定結果の報告要求をＵＥ１００に送信する。
【００５９】
（移動通信方法）
以下において、第一実施形態に係る移動通信方法について説明する。図７及び図８は、第一実施形態に係る移動通信方法を示すシーケンス図である。ここでは、ＵＥ１００＃１及びｅＮＢ２００がセルラ通信を行っており、ＵＥ１００＃１及びＵＥ１００＃２がＤ２Ｄ通信を行うケースを例示する。ここでは、ＵＥ１００＃１からＵＥ１００＃２に対してデータを送信し、ＵＥ１００＃２からＵＥ１００＃１に対して送達確認情報を送信するケースについて主として説明する。
【００６０】
第１に、Ｉｍｍｅｄｉａｔｅ  ＭＤＴについて図７を参照しながら説明する。
【００６１】
図７に示すように、ステップＳ１０において、ｅＮＢ２００は、ＵＥ１００＃１とＵＥ１００＃２との間のＤ２Ｄ通信で用いる無線リソースを指定するメッセージ（ＤＣＩ  Ｆｏｒｍａｔ  ５）をＵＥ１００＃１に送信する。
【００６２】
ステップＳ１１Ａ又はステップＳ１１Ｂにおいて、ＵＥ１００＃１及びＵＥ１００＃２は、ｅＮＢ２００によって指定された無線リソースを用いてＤ２Ｄ通信を行う。
【００６３】
ステップＳ１２において、ｅＮＢ２００は、測定設定情報をＵＥ１００＃１に送信する。測定設定情報に含まれる各種の測定設定パラメータを記憶する。測定設定パラメータは、サービス品質の測定結果を報告するトリガである報告トリガを含む。ステップＳ１２において、測定設定情報は、サイドリンクのサービス品質の測定を要求する情報を含む。測定設定情報は、ＲＲＭ  Ｍｅａｓｕｒｅｍｅｎｔ  Ｃｏｎｆｉｇｕｒａｔｉｏｎに含まれていてもよい。
【００６４】
ステップＳ１３Ａ又はステップＳ１３Ｂにおいて、ＵＥ１００＃１は、ＵＥ１００＃２から受信する送達確認情報に基づいて、サイドリンクのサービス品質を測定する。
【００６５】
ステップＳ１４Ａ又はステップＳ１４Ｂにおいて、ＵＥ１００＃１は、報告トリガに対応するイベントの発生に応じて、サービス品質の測定結果を生成する。ＵＥ１００＃１は、サービス品質の測定結果が生成されたタイミングで、サービス品質の測定結果をｅＮＢ２００に報告してもよい。或いは、ＵＥ１００＃１は、所定の閾値を下回ったサービス品質の測定結果が生成されたタイミングで、所定の閾値を下回ったサービス品質の測定結果をｅＮＢ２００に報告してもよい。
【００６６】
ステップＳ１５において、ＵＥ１００＃１及びＵＥ１００＃２は、Ｄ２Ｄ通信を終了する。
【００６７】
ステップＳ１６において、ｅＮＢ２００は、測定設定情報をＵＥ１００＃１に送信する。ステップＳ１６において、測定設定情報は、サイドリンクのサービス品質の測定及び報告を要求する情報を含まない。或いは、測定設定情報は、サイドリンクのサービス品質の測定及び報告を解除する情報を含んでもよい。
【００６８】
第２に、Ｌｏｇｇｅｄ  ＭＤＴ  ｉｎ  Ｃｏｎｎｅｃｔｅｄについて図８を参照しながら説明する。
【００６９】
図８に示すように、ステップＳ２０において、ｅＮＢ２００は、ＵＥ１００＃１とＵＥ１００＃２との間のＤ２Ｄ通信で用いる無線リソースを指定するメッセージ（ＤＣＩ  Ｆｏｒｍａｔ  ５）をＵＥ１００＃１に送信する。
【００７０】
ステップＳ２１Ａ又はステップＳ２１Ｂにおいて、ＵＥ１００＃１及びＵＥ１００＃２は、ｅＮＢ２００によって指定された無線リソースを用いてＤ２Ｄ通信を行う。
【００７１】
ステップＳ２２において、ｅＮＢ２００は、測定設定情報をＵＥ１００＃１に送信する。測定設定情報に含まれる各種の測定設定パラメータを記憶する。測定設定パラメータは、サービス品質の測定結果を生成するトリガである生成トリガを含む。ステップＳ２２において、測定設定情報は、サイドリンクのサービス品質の測定及び報告を要求する情報を含む。測定設定情報は、ＲＲＭ  Ｍｅａｓｕｒｅｍｅｎｔ  Ｃｏｎｆｉｇｕｒａｔｉｏｎに含まれていてもよい。
【００７２】
ステップＳ２３Ａ又はステップＳ２３Ｂにおいて、ＵＥ１００＃１は、ＵＥ１００＃２から受信する送達確認情報に基づいて、サイドリンクのサービス品質を測定する。ＵＥ１００＃１は、生成トリガに対応するイベントの発生に応じて、サービス品質の測定結果を記憶部に記憶（ログ）する。ここで、ＵＥ１００＃１は、所定の閾値を下回るサービス品質の測定結果のみを記憶部に格納してもよい。
【００７３】
ステップＳ２４において、ＵＥ１００＃１及びＵＥ１００＃２は、Ｄ２Ｄ通信を終了する。
【００７４】
ステップＳ２５において、ＵＥ１００＃１は、コネクティッド状態からアイドル状態に遷移する。
【００７５】
ステップＳ２６において、ＵＥ１００＃１は、アイドル状態からコネクティッド状態に遷移する。
【００７６】
ステップＳ２７において、ｅＮＢ２００は、サービス品質の測定結果の報告要求をＵＥ１００＃１に送信する。上述したように、ｅＮＢ２００は、ＵＥ１００＃１から通知される情報（Ａｖａｉｌａｂｌｅ  Ｉｎｄｉｃａｔｉｏｎ）に応じて、サービス品質の測定結果の報告要求をＵＥ１００＃１に送信してもよく、ＵＥ１００＃１から通知される情報（Ｄ２Ｄ通信のＢＳＲ）に応じて、サービス品質の測定結果の報告要求をＵＥ１００＃１に送信してもよい。
【００７７】
ステップＳ２８において、ＵＥ１００＃１は、ｅＮＢ２００から報告要求を受信したタイミングで、記憶部に記憶されたサービス品質の測定結果をｅＮＢ２００に報告する。或いは、ＵＥ１００＃１は、ｅＮＢ２００から報告要求を受信したタイミングで、記憶部に記憶されたサービス品質の測定結果のうち、所定の閾値を下回るサービス品質の測定結果をｅＮＢ２００に報告してもよい。
【００７８】
上述した第一実施形態では、ＵＥ１００＃１（データの送信側／送達確認情報の受信側）がサービス品質の測定結果をｅＮＢ２００に報告するケースについて主として記載した。しかしながら、ＵＥ１００＃２（データの受信側／送達確認情報の送信側）がサービス品質の測定結果をｅＮＢ２００に報告してもよい。このようなケースでは、ステップＳ１２或いはステップＳ２２において、ｅＮＢ２００は、測定設定情報をＵＥ１００＃２に送信してもよい。
【００７９】
（作用及び効果）
第一実施形態では、ＵＥ１００は、Ｄ２Ｄ通信を行うためのサイドリンクのサービス品質の測定結果をｅＮＢ２００に報告する。これによって、サービス品質の測定結果を用いて適切なスケジューリングを行うことができる。例えば、サービス品質を満たしていないＵＥ１００に割り当てるリソース量を増大することができる。
【００８０】
［変更例１］
以下において、第一実施形態の変更例１について説明する。以下においては、第一実施形態に対する相違点について主として説明する。
【００８１】
具体的には、第一実施形態では、ＭＤＴにおいてサービス品質の測定結果を報告する手順について説明した。これに対して、変更例１では、ＭＤＴにおいてｅＮＢ２００に対する上りリンクにおけるデータの上り遅延時間の測定結果を報告する手順について説明する。ここで、上り遅延時間とは、上りリンクで送信すべきデータがＵＥ１００で生成されてから受信側（ｅＮＢ２００）でデータが受信されるまでの遅延時間、或いは、上りリンクで送信すべきデータがＵＥ１００で生成されてから受信側（ｅＮＢ２００）でデータが受信された旨が通知されるまでの遅延時間（ＵＬ  ｑｕｅｕｉｎｇ  ｄｅｌａｙ）である。
【００８２】
詳細には、ＵＥ１００（制御部）は、ｅＮＢ２００に対する上りリンクにおけるデータの上り遅延時間の測定結果を生成する。ＵＥ１００（送信部）は、上り遅延時間の測定結果をｅＮＢ２００に報告する。
【００８３】
ここで、上り遅延時間の測定結果をｅＮＢ２００に報告するタイミングとしては、第一実施形態と同様に、（Ａ）Ｉｍｍｅｄｉａｔｅ  ＭＤＴを利用するケース及び（Ｂ）Ｌｏｇｇｅｄ  ＭＤＴ  ｉｎ  Ｃｏｎｎｅｃｔｅｄを利用するケースが考えられる。
【００８４】
（Ａ）Ｉｍｍｅｄｉａｔｅ  ＭＤＴ
Ｉｍｍｅｄｉａｔｅ  ＭＤＴでは、接続状態にあるＵＥ１００は、ｅＮＢ２００から測定設定情報（ＲＲＭ  Ｍｅａｓｕｒｅｍｅｎｔ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ）を受信し、測定設定情報に含まれる各種の測定設定パラメータを記憶する。測定設定パラメータは、上り遅延時間の測定結果を報告するトリガである報告トリガを含む。ＵＥ１００は、報告トリガに対応するイベントの発生に応じて、上り遅延時間の測定結果を生成するとともに、上り遅延時間の測定結果をｅＮＢ２００に報告する。
【００８５】
具体的には、ＵＥ１００は、上り遅延時間の測定結果が生成されたタイミングで、上り遅延時間の測定結果をｅＮＢ２００に報告する。或いは、ＵＥ１００は、所定の閾値を上回った上り遅延時間の測定結果が生成されたタイミングで、所定の閾値を上回った上り遅延時間の測定結果をｅＮＢ２００に報告してもよい。
【００８６】
所定の閾値は、測定設定情報に含まれることが好ましい。所定の閾値は、予め定義された値であってもよい。上り遅延時間の測定結果は、ＵＥ１００の位置情報を含むことが好ましい。
【００８７】
（Ｂ）Ｌｏｇｇｅｄ  ＭＤＴ  ｉｎ  Ｃｏｎｎｅｃｔｅｄ
Ｌｏｇｇｅｄ  ＭＤＴ  ｉｎ  Ｃｏｎｎｅｃｔｅｄでは、接続状態にあるＵＥ１００は、ｅＮＢ２００から測定設定情報（Ｌｏｇｇｅｄ  Ｍｅａａｓｕｒｅｍｅｎｔ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ）を受信し、測定設定情報に含まれる各種のＭＤＴ設定パラメータを記憶する。ＭＤＴ設定パラメータは、上り遅延時間の測定結果を生成するトリガである生成トリガを含む。ＵＥ１００は、生成トリガに対応するイベントが発生した際に、上り遅延時間の測定結果を記憶部に記憶（ログ）する。ＵＥ１００は、ｅＮＢ２００から受信する報告要求に応じて、記憶部に記憶された上り遅延時間の測定結果をｅＮＢ２００に報告する。
【００８８】
具体的には、ＵＥ１００は、上り遅延時間の測定結果を記憶部に格納する。ＵＥ１００は、ｅＮＢ２００から報告要求を受信したタイミングで、記憶部に記憶された上り遅延時間の測定結果をｅＮＢ２００に報告する。或いは、ＵＥ１００は、ｅＮＢ２００から報告要求を受信したタイミングで、記憶部に記憶された上り遅延時間の測定結果のうち、所定の閾値を上回った上り遅延時間の測定結果をｅＮＢ２００に報告する。ここで、ＵＥ１００は、所定の閾値を上回った上り遅延時間の測定結果のみを記憶部に格納するように構成されていてもよい。
【００８９】
所定の閾値は、測定設定情報に含まれることが好ましい。所定の閾値は、予め定義された値であってもよい。上り遅延時間の測定結果は、ＵＥ１００の位置情報を含むことが好ましい。
【００９０】
Ｌｏｇｇｅｄ  ＭＤＴ  ｉｎ  Ｃｏｎｎｅｃｔｅｄにおいて、ＵＥ１００は、ＲＲＣアイドル状態からＲＲＣコネクティッド状態に遷移する場合に、上り遅延時間の測定結果が記憶部に格納されている旨を示す情報（Ａｖａｉｌａｂｌｅ  Ｉｎｄｉｃａｔｉｏｎ）をｅＮＢ２００に通知してもよい。或いは、ＵＥ１００は、ソースのｅＮＢ２００からターゲットのｅＮＢ２００へのハンドオーバを行う際に、上り遅延時間の測定結果が記憶部に格納されている旨を示す情報（Ａｖａｉｌａｂｌｅ  Ｉｎｄｉｃａｔｉｏｎ）をターゲットのｅＮＢ２００に送信してもよい。このようなケースにおいて、ｅＮＢ２００は、上り遅延時間の測定結果が記憶部に格納されている旨を示す情報（Ａｖａｉｌａｂｌｅ  Ｉｎｄｉｃａｔｉｏｎ）に応じて、上り遅延時間の測定結果の報告要求をＵＥ１００に送信する。
【００９１】
（移動通信方法）
以下において、変更例１に係る移動通信方法について説明する。図９及び図１０は、変更例１に係る移動通信方法を示すシーケンス図である。
【００９２】
第１に、Ｉｍｍｅｄｉａｔｅ  ＭＤＴについて図９を参照しながら説明する。
【００９３】
図９に示すように、ステップＳ４０において、ＵＥ１００は、ＲＲＣコネクティッド状態である。
【００９４】
ステップＳ４１において、ｅＮＢ２００は、測定設定情報をＵＥ１００に送信する。測定設定情報に含まれる各種の測定設定パラメータを記憶する。測定設定パラメータは、上り遅延時間の測定結果を報告するトリガである報告トリガを含む。測定設定情報は、ＲＲＭ  Ｍｅａｓｕｒｅｍｅｎｔ  Ｃｏｎｆｉｇｕｒａｔｉｏｎに含まれていてもよい。
【００９５】
ステップＳ４２Ａ又はステップＳ４２Ｂにおいて、ＵＥ１００は、上り遅延時間のサービス品質を測定する。
【００９６】
ステップＳ４３Ａ又はステップＳ４３Ｂにおいて、ＵＥ１００は、報告トリガに対応するイベントの発生に応じて、上り遅延時間の測定結果を生成する。ＵＥ１００は、上り遅延時間の測定結果が生成されたタイミングで、上り遅延時間の測定結果をｅＮＢ２００に報告してもよい。或いは、ＵＥ１００は、所定の閾値を上回った上り遅延時間の測定結果が生成されたタイミングで、所定の閾値を上回った上り遅延時間の測定結果をｅＮＢ２００に報告してもよい。
【００９７】
図１０に示すように、ステップＳ５０において、ＵＥ１００は、ＲＲＣコネクティッド状態である。
【００９８】
ステップＳ５１において、ｅＮＢ２００は、測定設定情報をＵＥ１００に送信する。測定設定情報に含まれる各種の測定設定パラメータを記憶する。測定設定パラメータは、上り遅延時間の測定結果を生成するトリガである生成トリガを含む。測定設定情報は、ＲＲＭ  Ｍｅａｓｕｒｅｍｅｎｔ  Ｃｏｎｆｉｇｕｒａｔｉｏｎに含まれていてもよい。
【００９９】
ステップＳ５２において、ＵＥ１００は、上り遅延時間のサービス品質を測定する。ＵＥ１００は、生成トリガに対応するイベントの発生に応じて、上り遅延時間の測定結果を記憶部に記憶（ログ）する。ここで、ＵＥ１００は、所定の閾値を上回った上り遅延時間の測定結果のみを記憶部に格納してもよい。
【０１００】
ステップＳ５３において、ＵＥ１００は、コネクティッド状態からアイドル状態に遷移する。
【０１０１】
ステップＳ５４において、ＵＥ１００は、アイドル状態からコネクティッド状態に遷移する。
【０１０２】
ステップＳ５５において、ｅＮＢ２００は、上り遅延時間の測定結果の報告要求をＵＥ１００に送信する。上述したように、ｅＮＢ２００は、ＵＥ１００から通知される情報（Ａｖａｉｌａｂｌｅ  Ｉｎｄｉｃａｔｉｏｎ）に応じて、上り遅延時間の測定結果の報告要求をＵＥ１００に送信する。
【０１０３】
ステップＳ５６において、ＵＥ１００は、ｅＮＢ２００から報告要求を受信したタイミングで、記憶部に記憶された上り遅延時間の測定結果をｅＮＢ２００に報告する。或いは、ＵＥ１００は、ｅＮＢ２００から報告要求を受信したタイミングで、記憶部に記憶された上り遅延時間の測定結果のうち、所定の閾値を上回った上り遅延時間の測定結果をｅＮＢ２００に報告してもよい。
【０１０４】
上述した変更例１において、ＵＥ１００は、上り遅延時間の測定結果のばらつきを推定するための情報（以下、報告情報）をｅＮＢ２００に報告する。報告情報は、平均上り遅延時間、下位５％の上り遅延時間、上位５％の上り遅延時間等を含んでもよい。
【０１０５】
（作用及び効果）
変更例１では、ＵＥ１００は、ｅＮＢ２００に対する上りリンクにおけるデータの上り遅延時間の測定結果をｅＮＢ２００に報告する。これによって、上り遅延時間の測定結果を用いて適切なスケジューリングを行うことができる。例えば、上り遅延時間が大きいＵＥ１００に割り当てるリソース量を増大することができる。
【０１０６】
［変更例２］
以下において、第一実施形態の変更例２について説明する。以下においては、第一実施形態に対する相違点について主として説明する。
【０１０７】
具体的には、第一実施形態では、ＭＤＴにおいてサービス品質の測定結果を報告する手順について説明した。これに対して、変更例２では、ＭＤＴにおいて少なくとも位置情報を含むＭＤＴ測定結果を報告する手順について説明する。ＭＤＴ測定結果は、既存のＭＤＴで報告される内容と同様であり、少なくともＵＥ１００の地理的な位置を示す位置情報を含んでいればよい。ＭＤＴ測定結果は、ｅＮＢ２００からセルラ通信によって受信する信号の受信品質（ＲＳＲＰやＲＳＲＱ）を含んでもよい。
【０１０８】
詳細には、ＵＥ１００は、セルラ通信を行う機能に加えて、セルラ通信以外の通信（例えば、ＷｉＦｉやＢｌｕｅＴｏｏｔｈ）を行う機能を有するデュアル端末である。また、変更例２では、Ｌｏｇｇｅｄ  ＭＤＴ  ｉｎ  ＩｄｌｅによってＭＤＴ測定結果を報告するケースを主として想定している。
【０１０９】
ここで、第０段階として、ＵＥ１００は、セルラ通信に加えて、セルラ通信以外の通信（例えば、ＷｉＦｉやＢｌｕｅＴｏｏｔｈ）を開始する。すなわち、ＵＥ１００内においてセルラ通信及びセルラ通信以外の通信が同時に行われ状態（ＩＤＣ；Ｉｎ  Ｄｅｖｉｃｅ  Ｃｏｅｘｉｓｔｅｎｃｅ）が生じる。上述した装置内干渉とは、ＩＤＣによって生じる干渉である。
【０１１０】
第１段階として、ＵＥ１００は、装置内干渉を検出する。具体的には、ＵＥ１００は、装置内干渉が所定閾値を超えたことを検出する（図１１に示すＰｈａｓｅ１の開始タイミング）。
【０１１１】
第２段階として、ＵＥ１００は、装置内干渉が生じていることを示すインディケーションをｅＮＢ２００に報告する（図１１に示すＰｈａｓｅ２の開始タイミング）。
【０１１２】
第３段階として、ｅＮＢ２００は、装置内干渉を解消するための手順を実行する。例えば、ｅＮＢ２００は、周波数の変更（ＦＤＭ  Ｓｏｌｕｔｉｏｎ）やセルラ通信のスケジューリングタイミングの変更（ＴＤＭ  Ｓｏｌｕｔｉｏｎ）などを行う（図１１に示すＰｈａｓｅ３の開始タイミング）。
【０１１３】
なお、図１１に示すＰｈａｓｅ１〜３及び装置内干渉を解消するための手順については、既存の３ＧＰＰ規格書ＴＳ３６．３００  Ｖ．１２．５．０の２３．４．２に記載されていることに留意すべきである。
【０１１４】
このようなケースにおいて、ＵＥ１００（制御部）は、少なくとも位置情報を含むＭＤＴ測定結果を生成するとともに、ＭＤＴ測定結果を記憶部に格納する。ＵＥ１００（送信部）は、記憶部に記憶されたＭＤＴ測定結果をｅＮＢ２００に報告する。このようなケースにおいて、ＵＥ１００（制御部）は、セルラ通信以外の通信によって生じる装置内干渉が検出される前において、ＭＤＴ測定結果を記憶部に格納する。すなわち、ＵＥ１００は、図１１に示すＰｈａｓｅ１よりも前のＭＤＴ測定結果を記憶部に格納する。言い換えると、ＵＥ１００は、図１１に示すＰｈａｓｅ１以降のＭＤＴ測定結果を記憶部に格納しない。
【０１１５】
変更例２において、ＵＥ１００（制御部）は、セルラ通信以外の通信を開始した後に記憶部に格納されたＭＤＴ測定結果を破棄することが好ましい。すなわち、ＵＥ１００は、図１１に示すＰｈａｓｅ１よりも前の段階であっても、セルラ通信以外の通信を開始した後に記憶部に格納されたＭＤＴ測定結果を破棄する。ＵＥ１００は、セルラ通信以外の通信の開始に応じて、ＭＤＴ測定結果の記憶部への格納を停止してもよい。
【０１１６】
或いは、ＵＥ１００（制御部）は、装置内干渉が検出された場合であっても、ＭＤＴ測定結果を格納するための設定情報を維持するとともに、装置内干渉が解消した場合に、設定情報に従ってＭＤＴ測定結果の記憶部への格納を再開することが好ましい。すなわち、ＵＥ１００は、図１１に示すＰｈａｓｅ３以降において、ＭＤＴ測定結果の記憶部への格納を再開する。
【０１１７】
（作用及び効果）
変更例３に係るＵＥ１００は、セルラ通信以外の通信によって生じる装置内干渉が検出される前において、ＭＤＴ測定結果を記憶部に格納する。すなわち、装置内干渉が検出される後におけるＭＤＴ測定結果が記憶部に格納されないため、装置内干渉によって悪影響を受けたＭＤＴ測定結果の記憶部への格納が抑制される。従って、ＵＥ１００の負荷増大を抑制しながらも、ｅＮＢ２００などの上位ノードによって、装置内干渉によって悪影響を受けたＭＤＴ測定結果を除外する手間を省くことができる。
【０１１８】
［第二実施形態］
ＵＥ１００（プロセッサ１６０）は、上りリンクのＰＤＣＰのキューイング遅延を検出しない場合（スパイクを検出しない場合又はＰＤＣＰキューイングの遅延率が閾値未満の場合）、ｅＮＢ２００への報告のために、上りリンクのＰＤＣＰキューイング遅延の測定結果（ｕｌ−ＰＤＣＰ−ＤｅｌａｙＲｅｓｕｌｔ）を作成しなくてもよい（ＰＤＣＰキューイング遅延の測定結果の作成を制限してもよい）。なお、スパイクとは、単位時間内のＰＤＣＰパケットのうちの数パケットのキューイング遅延が突発的に閾値を超えてしまう状況である。また、ＰＤＣＰキューイングの遅延率とは、単位時間内のＰＤＣＰパケットのうち、キューイング遅延が閾値を超えたＰＤＣＰパケットの割合である。
【０１１９】
また、ＵＥ１００は、上りリンクのＰＤＣＰのキューイング遅延を検出しない場合でも、上りリンクのＰＤＣＰキューイング遅延の測定結果（ｕｌ−ＰＤＣＰ−ＤｅｌａｙＲｅｓｕｌｔ）を作成してもよい（測定結果に含めるｅｘｃｅｓｓＤｅｌａｙは０として作成する）。
【０１２０】
また、ＵＥ１００は、上りリンクのＰＤＣＰのキューイング遅延を検出した場合であってもＰＤＣＰキューイングの遅延率が閾値（０以上）未満の場合には、ｅＮＢ２００への報告のために、上りリンクのＰＤＣＰキューイング遅延の測定結果（ｕｌ−ＰＤＣＰ−ＤｅｌａｙＲｅｓｕｌｔ）を作成しなくてもよい。
【０１２１】
ＵＥ１００は、上りリンクのＰＤＣＰキューイング遅延の測定結果を作成しなかった場合には、ｅＮＢ２００へ上りリンクのＰＤＣＰキューイング遅延の測定結果を報告しなくてもよい。
【０１２２】
［その他の実施形態］
本発明は上述した実施形態によって説明したが、この開示の一部をなす論述及び図面は、この発明を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施形態、実施例及び運用技術が明らかとなろう。
【０１２３】
実施形態では特に触れていないが、サービス品質の測定結果は、サイドリンクのＳＩＮＲ、サイドリンクのＢＬＥＲ、セルラ通信の下りリンクのＳＩＮＲ、セルラ通信の下りリンクのＢＬＥＲ、セルラ通信以外の通信（例えば、Ｗｉｆｉ）の上りリンク又は下りリンクのＳＩＮＲ、セルラ通信以外の通信（例えば、Ｗｉｆｉ）の上りリンク又は下りリンクのＢＬＥＲ、Ｄ２Ｄ  Ｄｉｓｃｏｖｅｒｙの送信をトリガしてから実際にＤ２Ｄ  Ｄｉｓｃｏｖｅｒｙを送信するまでの遅延等を含んでもよい。
【０１２４】
変更例１では特に触れていないが、上り遅延時間の測定結果をｅＮＢ２００に報告するＵＥ１００は、ｅＮＢ２００によって指定されてもよい。例えば、ｅＮＢ２００は、ＵＥ１００から受信する周期的な音声パケットを監視するとともに、周期的な音声パケットのジッタに基づいて上り遅延時間を推定する。ｅＮＢ２００は、推定された遅延時間が閾値よりも大きいＵＥ１００を、上り遅延時間の測定結果を報告するＵＥ１００として指定する。
【０１２５】
実施形態では、ＭＤＴを利用するケースを用いて説明したが、これに限られず、ＭＤＴを利用しないでサービス品質の測定結果を報告してもよい。同様に、変更例１では、ＭＤＴを利用するケースを用いて説明したが、これに限られず、ＭＤＴを利用しないで上り遅延時間の測定結果を報告してもよい。
【０１２６】
実施形態では特に触れていないが、ＵＥ１００及びｅＮＢ２００が行う各処理をコンピュータに実行させるプログラムが提供されてもよい。また、プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ等の記録媒体であってもよい。
【０１２７】
或いは、ＵＥ１００及びｅＮＢ２００が行う各処理を実行するためのプログラムを記憶するメモリ及びメモリに記憶されたプログラムを実行するプロセッサによって構成されるチップが提供されてもよい。
【０１２８】
実施形態では、移動通信システムの一例としてＬＴＥシステムを説明した。しかしながら、実施形態はこれに限定されるものではない。移動通信システムは、ＬＴＥシステム以外のシステムであってもよい。
【０１２９】
［付記１］
（１．はじめに）
「Ｅ−ＵＴＲＡＮのための駆動試験の最小化のさらなる強化」が合意された。重要な目的のうちの１つは、範囲およびネットワーク最適化のためのチャネル条件を正確に反映するために、ＵＥからのさらなるフィードバックのプロビジョンを研究することである。研究項目はまた、以下の目的を指摘した。
【０１３０】
・強化された範囲最適化使用の場合：
ＭＤＴ測定結果にインパクトを与える追加のフィードバックの、多様な機能を取り扱うＵＥからのプロビジョン（たとえば、ＩＤＣのような新たなタイプの支援情報等）を考慮し、そのような情報が達成し得る利点が何であるかを分析する。
【０１３１】
本付記では、ＭＤＴ測定結果および潜在的な解決策に対するＩＤＣ干渉のインパクトについて議論される。
【０１３２】
（２．議論）
ＦｅＭＤＴ研究項目の一部として、チャネル条件をＭＤＴ測定結果へ正確に反映するいくつかのメカニズムを研究するべきである。ＭＤＴ測定結果にインパクトを与える典型的な要因のうちの１つは、ＩＤＣ干渉である。デバイス内共存のための干渉回避のためのＴＲによれば、ＷｉＦｉおよびＢｌｕｅｔｏｏｔｈは、ＬＴＥデバイスに対して干渉し得る。現在の仕様によれば、ＵＥは、自身では解決することができないＩＤＣ問題を経験し、ネットワーク介入が必要される場合、ＩＤＣ問題をｅＮＢへレポートするために、専用のＲＲＣシグナリングを介してＩＤＣインジケーションを送り得る。それは、もしもＵＥがＣＯＮＮモードであれば、ｅＮＢが、ＩｎＤｅｖｉｃｅＣｏｅｘＩｎｄｉｃａｔｉｏｎメッセージに基づいて、ＩＤＣ問題が発生したか否かを検出できることを意味する。したがって、ＲＡＮ２は、迅速なＭＤＴの場合を研究する必要はない。なぜなら、ｅＮＢ／ＮＷは、実施によって、特有の（すなわち、ＩＤＣ共存問題を有する）ＵＥから受信したＭＤＴデータをどのようにして処理するのかを決定でき得るからである。
【０１３３】
観察：ＲＡＮ２は、ＩＤＣ干渉を経験した場合、ＩＤＬＥ  ＵＥがどのようにしてＬｏｇｇｅｄ  ＭＤＴを実行するのかに注目するべきである。
【０１３４】
ＷｉＦｉおよびＢｌｕｅｔｏｏｔｈ  Ｔｘが、ＬＴＥラジオのＲｘに対する干渉を引き起こすのであれば、ＩＤＣ干渉によって、測定結果が劣化される。ｅＮＢ／ＮＷは、ログデータが劣化されたか否かを検出できないので、ＵＥは、劣化されていない測定結果のみをログするべきである。したがって、ＵＥは、ＩＤＣ干渉を検出した場合、可能な限り早急にＭＤＴロギングを停止すべきである。ＴＳ  ３６．３００のセクション２３．４．２によれば、ＩＤＣ干渉の３つのフェーズが、図１２に図示されている。
【０１３５】
−フェーズ１：ＵＥは、ＩＤＣ干渉の開始を検出するが、ＩＤＣインジケーションのｅＮＢへの送信をまだ開始しない。
【０１３６】
ＩＤＬＥ  ＵＥは、ＩＤＣ干渉状態のフェーズ１をトリガした場合に、ＭＤＴロギングを停止すべきであると提案する。
【０１３７】
提案１：ＩＤＬＥ  ＵＥは、ＩＤＣ干渉のフェーズ１の開始をトリガした場合、ロギングを停止すべきである。
【０１３８】
問題１：ＵＥは「すべてのログデータ」または「劣化されたデータのみ」を廃棄するべきであるか？
この質問は、ログデータが廃棄されるか否かである。２つの代替案があると考えられる。
【０１３９】
代替案１：ＵＥは、ＩＤＣ干渉検出に先立って、すべてのログデータを廃棄する。
【０１４０】
代替案２：ＵＥは、劣化したログデータのみを検出し廃棄する。
【０１４１】
ＵＥが単に「すべてのログデータ」を廃棄するのであれば、それはより簡単であろう。一方、多過ぎるＵＥの複雑さ無しで回避され得るのであれば、良好なログデータを完全に廃棄しないことが常に良い。後者の場合、ＵＥは、ＩＤＣ問題を検出した場合、ロギングを停止するが、劣化していないログデータを維持するべきである。代替案２の場合、劣化したログデータのみを廃棄するための２つのオプションが考慮され得る。
【０１４２】
オプション１：ＵＥが、フェーズ１の前に、すべてのログデータを維持する。
【０１４３】
オプション２：ＵＥは、ＷｉＦｉ／Ｂｌｕｅｔｏｏｔｈを使用することを開始した後に収集されたログデータを廃棄する。
【０１４４】
オプション１は、オプション２よりはるかに単純である。しかしながら、ログデータのいくつかが、フェーズ１の前に既に劣化しているという可能性がある。なぜなら、フェーズ１は、ＩＤＣ干渉の検出から開始し、その詳細はＵＥ実施に委ねられるからである。したがって、「ＵＥは、干渉を評価するために、既存のＬＴＥ測定および／またはＵＥ内部調整に依存し、詳細は、ＵＥ実施に委ねられる」。また、ＩＤＣ干渉の検出は、ＵＥ実施に委ねられているので、ＵＥは、ＩＤＣ干渉が非常に小さいのであれば、フェーズ１をトリガしないことがあり得る。言い換えれば、干渉が（少なくともＵＥの観点から）非常に小さく、ＵＥが決してフェーズ１をトリガしないが、実際、ログデータが既に幾分劣化されていることがあり得る。このシナリオでは、ＩＤＣ干渉は公式には検出されていないので、「劣化された」ログデータがレポートされるであろう。したがって、ＵＥがＷｉＦｉ／Ｂｌｕｅｔｏｏｔｈを使用し始めるや否や、測定結果が劣化され得る。ログデータの劣化状態の不確定性によって、オプション１が選択されたのであれば、ＵＥは、フェーズ１が検出されたことを、ログに含める（または、我々がインジケーションを用いるのであれば、ログ可用性インジケーションに含める）べきである。ログの終わりに向かうデータのいくつかを回収または廃棄した場合、ｅＮＢ／ＮＷは、データ全体を廃棄する（または、インジケーションが使用されるのであれば、データを取得するか否かの）オプションを有し得る。別のオプションは、ＵＥが、ＷｉＦｉ／Ｂｌｕｅｔｏｏｔｈの使用を開始／停止した場合、ログにインジケーション（たとえば、タイム・スタンプ）を追加することをＵＥに許可することであろう。そして、ｅＮＢ／ＮＷは、これらのインジケーションに基づいて、レポートされたログから、劣化した測定結果を除去し得る。
【０１４５】
オプション１とは対照的に、オプション２が適用される場合、ＭＤＴログの精度が高められる。しかしながら、ＵＥの複雑さは増加される。なぜなら、ＵＥは、劣化した結果を完全に除去するためにＷｉＦｉ／Ｂｌｕｅｔｏｏｔｈの使用を開始した時にログしなければならないからである。これは、前述したオプションに対する相補的な解決策であり、すなわち、ＵＥは、ＷｉＦｉ／Ｂｌｕｅｔｏｏｔｈの使用を開始／停止した時にタイムスタンプのようなインジケーションを追加し、これら２つのオプションの主な相違は、ｅＮＢ／ＮＷがフィルタリングを実行している（オプション１）か、またはＵＥがフィルタリングを実行している（オプション２）かであることに注目されたい。
【０１４６】
結論として、劣化していないログデータのみを維持することは困難であると考えられる。したがって、ＵＥが、ＩＤＣ干渉のフェーズ１の開始を検出した場合に、常にすべてのログデータを廃棄する代替案１が優先される。
【０１４７】
提案２：ＵＥは、ＩＤＣ干渉のフェーズ１の開始を検出した場合、すべてのログデータを常に廃棄する。
【０１４８】
問題２：どのＵＥがＭＤＴ設定を廃棄、または、ＩＤＣ問題が解決された場合にロギングを再開するために、ＭＤＴ設定を記憶するのであろうか？
ＵＥの観点から、提案２が合意された場合に、ＵＥがＭＤＴ設定をも廃棄するのであれば、それはより簡単である。しかしながら、３ＧＰＰは、ｅＮＢが、可能な限り多くＩＳＭ帯域へトラフィックをオフロードすることを可能にするメカニズムを研究している。ＵＥが、ＩＤＣ干渉を検出した場合、または、ＷｉＦｉまたはＢｌｕｅｔｏｏｔｈが使用されている場合、ＵＥが、ＭＤＴ設定を廃棄するのであれば、ＮＷがＩＳＭ帯域近くのＬＴＥ帯域でデータを収集する機会は少なくなるであろう。したがって、ＵＥがＭＤＴ設定を維持しているのであれば、ＩＤＣ問題が解決された後に、ロギングを再開することが好適となるであろう。「ＩＤＣ問題が解決される」という定義は、ＴＳ  ３６．３００に記載されている「ＵＥがもはやＩＤＣ問題を被っていない場合」と連携されるべきである。
【０１４９】
ロギングが再開される必要があり、（前述した問題１における決定に依存して）既存のログが存在する場合には、ＵＥに関するいかなる問題もあるはずがない。なぜなら、ＵＥは、既にこの状況を、以下のＵＥ振る舞いを可能にする現在の仕様に基づいて良好に取り扱うことができ得るからである。ＵＥが、ＩＤＬＥ＝＞ＣＯＮＮ＝＞ＩＤＬＥへと移行し、ログ結果が、ＣＯＮＮ中に回収されないのであれば、ＵＥは、ログされたＭＤＴを再開し、１つのログ測定結果を生成する。
【０１５０】
提案３：ＩＤＣ問題が解決された後、ＵＥは、ＭＤＴ設定を維持し、ロギングを再開する。
【０１５１】
［付記２］
（１．はじめに）
ＦｅＭＤＴ研究項目の一部として、重要な目的のうちの１つは、ビデオトラフィックおよびＭＭＴＥＬのＱｏＳをサポートするために必要とされる強化の研究である。以下について合意できた。
【０１５２】
合意：
１  ＵＬとＤＬとの両方のためのレイテンシメトリックが、ＧＢＲトラフィックのために望ましい。
【０１５３】
ＦＦＳ：要求された／望ましい／許容可能な精度
上記の合意に従って、ＵＬ遅れ測定を行うこともまた合意可能である。しかしながら、既存の仕様は、ＵＬ遅れ測定のための何れのＬ２測定をも有しておらず、したがって、本付記において、可能な解決策に関する詳細を議論する。
【０１５４】
（２．議論）
いくつかの解決策が提案された。これらは、以下のように、３つの代替案に分類され得ると考える。
【０１５５】
代替案１．ｅＮＢは、ＵＥから何ら支援なく、ＵＬキュー遅れを推定する。
【０１５６】
代替案２．ＵＥは、各ＰＤＣＰ  ＰＤＵを、システム時間情報を用いてタグ付けし、ｅＮＢは、提供されたシステム時間情報を用いて、ＵＬキュー遅れを決定する。
【０１５７】
代替案３．ＵＥは、ＵＬ遅れを決定する際にｅＮＢを支援するために、ＵＬキュー遅れが、設定されたしきい値を超えたか否かを判定し、データまたは遅れ関連パラメータをレポートする。
【０１５８】
代替案１に関して、ｅＮＢは、周期的な音声パケットを受信する際に（結果としてジッタになる）変化があるか否かを判定するために、周期的な音声パケットを（たとえば、２０ミリ秒毎に）モニタし得る。この代替案は、ＵＬレイテンシが、ＵＥ側への追加の複雑さ無しで測定され得るという利点を有する。さらに、ＱｏＳ関連情報が、ｅＮＢにおいて測定される。これは、Ｌ２測定のための既存のポリシと連携されている。さらに、代替案１は、ｅＮＢ実施に基づいて達成され得る。これは、標準化された作業が必要とされないことを意味する。しかしながら、ｅＮＢは、トラフィックがＵＥのＰＤＣＰバッファ内にいつ到着するのかを知らないので、高い測定精度が期待されることはできない。
【０１５９】
代替案２に関し、ＵＥは、ＰＤＣＰパケットへタイムスタンプを追加し、ｅＮＢは、受信したＰＤＣＰパケットを正しく復号した時間に関連して提供されたタイムスタンプを用いてレイテンシを計算する。代替案１とは対照的に、この代替案は、ｅＮＢが、正確なＵＬレイテンシ測定結果を計算することを可能にする。なぜなら、ｅＮＢは、ＵＥによって追加されたタイムスタンプを使用でき得るからである。しかしながら、この代替案は、多くのロギングを必要とするであろうから、ＵＥとｅＮＢとの両方のための過度の負荷を結果的にもたらすであろう。したがって、これらの複雑さをどのようにして緩和するのかを考慮するべきである。実施ベースのプロシージャの一例は、代替案１と代替案２との組合せであり、ｅＮＢは、代替案１を用いてレイテンシを粗く推定し、ＵＥに対して、たとえば、推定されたレイテンシ、または、レイテンシの分散（すなわち、ジッタ）がしきい値を超えた場合、特定のＵＥのためのＰＤＣＰパケットへタイムスタンプを追加することを要求する。別の可能性は、ｅＮＢが、ＰＤＣＰパケットが、タイムスタンプされ、ＭＤＴ設定の一部としてレポートされる必要のある短い測定持続時間（たとえば、５秒）を設定することである。これは、ＵＥが、ＭＤＴの持続時間中に測定およびログする必要のあるＰＤＣＰパケットの数を低減するであろう。この短い測定持続時間の開始時間は、ｅＮＢによって制御されるべきである。
【０１６０】
代替案３に関し、ＵＬレイテンシを決定するためにすべての複雑さは、ＵＥに存在する。これは、ＵＥに対する著しい負荷をもたらすので、代替案３が選択されるのであれば、このような複雑さを最小化するための方法を考慮することが不可欠である。代替案３は、ｅＮＢが、代替案１を用いてレイテンシを推定し、たとえば、推定されたレイテンシ、または、レイテンシの分散が、しきい値を超える場合、特定のＵＥに対して、ＵＬレイテンシを測定することを要求するという点において代替案２に類似している。さらに、代替案３では、ＵＥは、ある遅れしきい値を超えるデータのみをログしレポートできるように、いくつかのフィルタリングを実行し得ることがさらに仮定される。あるいは、ｅＮＢがレイテンシの分散を計算できるように、ＵＥが、いくつかの遅れ関連パラメータをｅＮＢへレポートすることも可能である。レポートされるべき可能な遅れ関連パラメータは、たとえば、「測定されたＰＤＣＰ  ＳＤＵの数」を、平均、ｘ％、ｙ％最悪／最良レイテンシ測定結果とともに含む。
【０１６１】
提案１：ＲＡＮ２は、上記３つの代替案を、候補解決策として、ＴＲにおける可能な強化とともに取り込むべきである。
【０１６２】
提案２：ＲＡＮ２は、ＵＥベースの解決策が導入された場合のために、ＵＥとｅＮＢ／ＮＷとの両方の複雑さを最小化し、それらをＴＲの中に取り込むための方法を研究すべきである。
【０１６３】
［付記３］
（導入）
新しいＷＩ「Ｆｕｒｔｈｅｒ  Ｅｎｈａｎｃｅｍｅｎｔｓ  ｏｆ  Ｍｉｎｉｍｉｚａｔｉｏｎ  ｏｆ  Ｄｒｉｖｅ  Ｔｅｓｔｓ  ｆｏｒ  Ｅ−ＵＴＲＡＮ」が承認された。作業項目は以下の目的を含む。
【０１６４】
ＱｏＳ検証使用事例の拡張：
ＭＭＴＥＬ音声およびビデオトラフィックのためのＱｏＳおよびそれの制限ファクタのより良い理解をサポートするために、ＭＤＴ測定および手順を以下のように指定する：
１．ＵＬ  ＰＤＣＰキューイング遅延測定
２．（ＰＤＣＰ  ＳＤＵのＵＬドロッピングを除く）ＵＬおよびＤＬについてのデータ損失測定
３．トラフィックドロップメトリック収集
以下の合意が達成された。
【０１６５】
ＵＬ  ＰＤＣＰキューイング遅延測定は、ＵＥごとにＱＣＩごとに実施されるべきであり、（ＰＤＣＴアッパーＳＡＰにおけるパケット到着から、パケットがＲＬＣに配信され始めるまで）ＵＥのＰＤＣＰレイヤのみにおいて観測されるパケット遅延を反映すべきである。
【０１６６】
（議論）
（ロケーション情報の必要性）
他の文献によれば、ＵＬキューイング遅延の根本原因はスケジューリングである。報告されたＵＬキューイング測定が許容できない場合、ＮＷは、遅延を低減するようにスケジューリングアルゴリズムを修正するであろうと仮定するのが簡単である。さもなければ、キューイング遅延は残存するであろう。キューイング遅延測定の結果がｅＮＢのみに使用される場合、ロケーション情報とともにキューイング遅延測定を報告することは不要であり得ると理解される。一方、ロケーション情報は、ＴＣＥがキューイング遅延の根本原因を検出するために有用である。例えば、良好なＤＬおよびＵＬカバレージの下で過大なキューイング遅延が生じた場合、ＴＣＥは、問題の根本原因がスケジューリングであると判断することができる。ＴＣＥは、既存のＭＤＴ測定結果からＤＬカバレージ情報とＵＬカバレージ情報の両方を収集し得ることに留意されたい。したがって、キューイング遅延測定のためでさえロケーション情報が報告されるべきであることを選好する。
【０１６７】
提案１：ＵＬ  ＰＤＣＰキューイング遅延測定結果とともにロケーション情報が報告されるべきである。
【０１６８】
（Ｉｍｍｅｄｉａｔｅ  ＭＤＴまたはＬｏｇｇｅｄ  ＭＤＴ  ｉｎ  Ｃｏｎｎｅｃｔｅｄ）
考慮すべき別のポイントは、どのタイプの処理、Ｉｍｍｅｄｉａｔｅ  ＭＤＴまたはＬｏｇｇｅｄ  ＭＤＴ  ｉｎ  Ｃｏｎｎｅｃｔｅｄが、ＵＬ  ＰＤＣＰキューイング遅延測定に適用可能であるべきかである。ＵＬ  ＰＤＣＰキューイング遅延測定のみで十分であるとＲＡＮ２が判断した場合、問題の根本原因はスケジューリングに起因し得るので、Ｉｍｍｅｄｉａｔｅ  ＭＤＴは不要である。これは、スケジューリングアルゴリズムが修正されるまでキューイング遅延は改善され得ないことを意味する。ＮＷがスケジューリングアルゴリズムを頻繁に更新しないと仮定すると、ＮＷがキューイング遅延測定をリアルタイムで取得する利益はないと考える。そうである場合、Ｒｅｌ−１２においてすでに規格化されている、Ｌｏｇｇｅｄ  ＭＤＴ  ｉｎ  Ｃｏｎｎｅｃｔｅｄは、シグナリングオーバーヘッドがより少なく、ＵＥとＮＷの両方の複雑さが低減され得るので、好ましい。Ｉｍｍｅｄｉａｔｅ  ＭＤＴでは、ＮＷは、問題の程度を評価するために、報告された測定の多くの断片をつなぎ合わせる必要があり得る。
【０１６９】
しかしながら、既存のＩｍｍｅｄｉａｔｅ  ＭＤＴは、ｅＮＢが、報告された測定を直接使用することを可能にするように設計されている。例えば、ｅＮＢは、ＵＥの変化する状態に調整するために無線パラメータを更新することがある。前のセクションで述べたように、ｅＮＢ／ＮＷは、ＵＬ  ＰＤＣＰキューイング遅延測定に基づいて総ＵＬ遅延を推定し得る可能性がある。特定のサービスの総ＵＬレイテンシが予想閾値を超える場合、ｅＮＢ／ＮＷは、意図されたサービスのためのＱｏＳを実現するために、例えば、できるだけ早く無線パラメータを更新するオプションを有するべきである。この観点から、ＰＤＣＰキューイング遅延測定報告にＩｍｍｅｄｉａｔｅ  ＭＤＴが適用されることを選好する。
【０１７０】
提案２：ＰＤＣＰキューイング遅延測定報告にＩｍｍｅｄｉａｔｅ  ＭＤＴが適用される。
【０１７１】
（測定構成および報告メカニズム）
提案２が合意された場合、ＵＥがすべての測定結果を報告すべきか、または特定の測定結果、例えば、遅延閾値を超えることを報告すべきか、をも考慮すべきである。ＵＬ遅延測定の研究の結果によれば、遅延スパイクがＵＥベンダーとｅＮＢベンダーの両方にとって問題の主因であるので、後者を選好する。したがって、ＵＥは、構成された遅延閾値を超えるＵＬ  ＰＤＣＰキューイング遅延測定結果を報告し始め、構成された遅延閾値を測定値が下回った後に報告するのを止めるべきである。進入条件と離脱条件とのためにヒステリシスが適用される必要がある場合、それは今後の検討課題である。遅延閾値に関して、我々は、それが、例えば、ＵＬ  ＰＤＣＰキューイング遅延測定構成を使用してｅＮＢ／ＮＷによって構成可能であるべきと考える。
【０１７２】
提案３：ＵＥは、構成された遅延閾値を超えるＵＬ  ＰＤＣＰキューイング遅延測定結果を報告し始め、構成された遅延閾値をＵＬ  ＰＤＣＰキューイング遅延測定値が下回った後に報告するのを止めるべきである。
【０１７３】
（ＵＬ  ＰＤＣＰ遅延特性を収集する必要性）
提案３が合意された場合、ＮＷは、構成された閾値を超えるＵＬ  ＰＤＣＰキューイング遅延測定結果のみを収集することができる。したがって、ＵＬ  ＰＤＣＰ遅延特性がＮＷによって補正される必要がある場合、追加の支援情報がＵＥによって提供されるべきである。ネットワーク最適化のための主要な目的のうちの１つは、適用例に、特にＧＢＲタイプトラフィックに適した制限内にジッタおよび平均レイテンシを保つことであると理解されている。
【０１７４】
ＮＷがＵＬ  ＰＤＣＰ遅延特性を推定するためには、少なくとも測定されたＵＬ  ＰＤＣＰ  ＳＤＵの数と平均ＵＬ  ＰＤＣＰキューイング遅延とが必要であると考える。そうである場合、ＵＥは、平均ＵＬ  ＰＤＣＰキューイング遅延を計算し、測定されたＵＬ  ＰＤＣＰ  ＳＤＵの数とともにそれを後で報告すべきである。したがって、ｅＮＢは、ＵＬ  ＰＤＣＰキューイング遅延測定構成を使用して平均ＵＬ  ＰＤＣＰキューイング遅延を計算することをＵＥに要求するオプションを有するべきである。情報はすでに統計的であるので、ＵＥが測定サンプルのロケーション情報を報告することは不要である。
【０１７５】
提案４：ｅＮＢは、ＵＬ  ＰＤＣＰキューイング遅延測定構成を使用して平均ＵＬ  ＰＤＣＰキューイング遅延を計算することをＵＥに要求するオプションを有するべきである。
【０１７６】
提案５：要求された場合、ＵＥは、平均ＵＬ  ＰＤＣＰキューイング遅延を計算し、測定されたＵＬ  ＰＤＣＰ  ＳＤＵの数とともにそれを後で報告すべきである。
【０１７７】
ユーザ装置（ＵＥ）は、ＵＥにおいて測定された上りリンクＰＤＣＰキューイング遅延測定結果と共に位置情報を基地局（ｅＮＢ）又はネットワークへ報告する。
【０１７８】
ユーザ装置（ＵＥ）は、ＩｍｍｅｄｉａｔｅＭＤＴによって、ＵＥにおいて測定された上りリンクＰＤＣＰキューイング遅延測定結果を基地局（ｅＮＢ）又はネットワークへ報告する。
【０１７９】
ユーザ装置（ＵＥ）は、遅延閾値を超える上りリンクＰＤＣＰキューイング遅延測定結果を報告し、測定結果が閾値の範囲に入った後に、上りリンクＰＤＣＰキューイング遅延測定結果の報告を停止する。
【０１８０】
その場合において、遅延閾値は、ｅＮＢ又はネットワークからＵＥに退位して設定される。
【０１８１】
ユーザ装置（ＵＥ）は、平均上りリンクＰＤＣＰキューイング遅延測定結果を計算し、平均上りリンクＰＤＣＰキューイング遅延の計算はｅＮＢ又はネットワークからＵＥへ上りリンクＰＤＣＰキューイング遅延測定設定で要求される。
【０１８２】
ユーザ装置（ＵＥ）は、その後、測定した上りリンクＰＤＣＰ  ＳＤＵの数と共に平均上りリンクＰＤＣＰキューイング遅延測定結果を報告する。
【０１８３】
その場合において、ＵＥは、ｅＮＢ又はネットワークからの要求によって測定結果を報告する。
【０１８４】
［付記４］
（１．導入）
ＦｅＭＤＴ作業項目の下で、ＵＬ  ＰＤＣＰキューイング遅延のための測定構成および報告メカニズムが議論された。スパイクが検出されないときのＵＥ挙動が依然として今後の検討課題であると考える。この付記では、この問題と、仕様をどのように修正すべきかの候補とを議論する。
【０１８５】
（２．議論）
（２．１．過剰遅延比の測定報告マッピング）
ＵＥが、構成された遅延閾値を超えるＳＤＵと、測定値期間中にＵＥによって受信されたＳＤＵの総数との比として、ＵＬ  ＰＤＣＰ  ＳＤＵキューイング遅延を報告することが合意された。測定された量のマッピングは、以下のようにＴＳ  ３６．３１４の表４．２．１．１．１−１に定義されている。
【０１８６】
【表１】
2016185986.tif 000005
【０１８７】
測定された量の値がちょうどボーダー（例えば、０．０７９）上にある場合、ＵＥは報告される値を検出し得ないので、この表が更新されるべきであると考える。すべてのパケットのレイテンシが構成された閾値を超える事例を考慮に入れるために、右側の「＜記号」は「≦記号」に変更されるべきである。したがって、次のように表を更新することを提案する。
【０１８８】
【表２】
2016185986.tif 000006
【０１８９】
提案１：ＴＳ  ３６．３１４中の表４．２．１．１．１−１の右側の「＜記号」は「≦記号」に置き換えられるべきである。
【０１９０】
（２．２．スパイクが検出されないときのＵＬ  ＰＤＣＰ遅延測定報告）
測定結果は、構成された閾値を超えるパケット遅延と、測定／報告期間中のパケットの総数との比に変換されることが合意された。
【０１９１】
合意
ＰＤＣＰ  ＳＤＵの数および／または検出されたイベントが報告されることになる場合、数または比のコーディングは、ＭＢＳＦＮ  ＢＬＥＲ報告のために定義されたもののコーディング原理を再利用する。
【０１９２】
この合意について、ＵＥは、イベントが検出された（すなわち、ＵＥによってスパイクが検出された）ときのみＵＬ  ＰＤＣＰキューイング遅延測定結果を報告することができると理解される。ＵＬ遅延測定の研究の結果によれば、遅延スパイクは、ＵＥとｅＮＢの両方にとって問題の主因である。したがって、測定／報告期間内にＵＥによってスパイクが検出されない場合、ＰＤＣＰキューイング遅延測定結果の報告にあまり要点はない。ＵＬ  ＰＤＣＰキューイング遅延測定報告は周期的であるので、ＮＷが測定結果を受信しない場合、ＮＷは、測定／報告期間中にスパイクがないことを理解することができる。さらに、ＵＥが、遅延スパイクの検出にかかわらずすべての測定を報告することを要求される場合、スパイクが予想されない場合、過大な量のスパイクなしの報告があり得る。
【０１９３】
ＵＥは、スパイクが検出されないときにＵＬ  ＰＤＣＰキューイング遅延測定結果を報告しない場合、ＲＡＮ２は、どのようにこの合意が仕様に取り込まれるかを議論すべきである。ＴＳ  ３６．３３１によれば、ＵＬ  ＰＤＣＰキューイング遅延測定報告のトリガは以下の通りである。
【０１９４】
１＞ｕｌ−ＰＤＣＰ−ＤｅｌａｙＲｅｓｕｌｔが利用可能である場合、
２＞ｕｌ−ＰＤＣＰ−ＤｅｌａｙＲｅｓｕｌｔを受信値に設定する。
ｕｌ−ＰＤＣＰ−ＤｅｌａｙＲｅｓｕｌｔは、ｅｘｃｅｓｓＤｅｌａｙおよびｑｃｉ−Ｉｄから構成される。ｅｘｃｅｓｓＤｅｌａｙは、ＴＳ  ３６．３１４における上述の表を基準とする。
【０１９５】
過大な遅延が検出ないときにＵＬ  ＰＤＣＰ遅延測定の報告を防ぐための１つの可能性は、以下のように過剰遅延比のマッピングを修正することであると考える。
【０１９６】
【表３】
2016185986.tif 000007
は、
【０１９７】
【表４】
2016185986.tif 000008
【０１９８】
のように変更される。
【０１９９】
これは、ＵＥが遅延閾値に基づいてＵＬ  ＰＤＣＰ遅延を検出しない場合、ｕｌ−ＰＤＣＰ−ＤｅｌａｙＲｅｓｕｌｔが作成されないことを意味する。さらに、遅延スパイクが検出されないときにＵＥがＵＬ遅延を報告しないことをステージ２に取り込むのが良いだろうと考える。場合によっては、ＴＳ  ３７．３２０のセクション５．２．１．１において測定−−Ｍ６の下に、「ＮＯＴＥ」が以下のように追加され得るだろう。
【０２００】
ＮＯＴＥ：ＵＥが、ネットワークによって構成された遅延閾値および遅延報告間隔に基づいてＵＬ  ＰＤＣＰ遅延を検出しない場合、ＵＥは、その期間内にＵＬ  ＰＤＣＰ遅延測定を報告しない。
【０２０１】
［付記５］
（ＵＥベースのＱｏＳ測定）
−基本的仮定
ＡＣＫ／ＮＡＣＫを用いた１対１のＤ２Ｄ通信が導入される。
サイドリンクＱｏＳ測定にはモード１通信のみが仮定される
−測定識別情報
サイドリンクデータ損失
サイドリンクスケジュールされたＩＰスループット
サイドリンクデータボリューム
サイドリンクパケット遅延／アップリンクパケット遅延
ダウンリンクＳＩＮＲ／（今後の検討課題）サイドリンクＳＩＮＲ／ＷＬＡＮダウンリンクＳＩＮＲ
ダウンリンクＢＬＥＲ／（今後の検討課題）サイドリンクＢＬＥＲ／ＷＬＡＮダウンリンクＢＬＥＲ
−可能な報告トリガ
周期的
イベント
ＰＤＣＰ  ＳＤＵごとに
ＱｏＳ測定結果が閾値よりも悪い
−測定構成の可能なＩＥ
測定ターゲット（任意）
データ損失、スケジュールされたＩＰスループット、データボリューム、パケット遅延など
報告／ロギングトリガ
周期的、ＰＤＣＰ  ＳＤＵごとに、結果が閾値よりも小さいなど
【０２０２】
（ＵＥベースのＱｏＳ測定のためのＭＤＴ）
−Ｉｍｍｅｄｉａｔｅ  ＭＤＴ
構成
ＵＥベースのＱｏＳ測定のための新しいＩＥを導入するとともに既存のＲＲＭ測定構成を再利用する。これは、既存のＲＲＭ測定構成への「アドオン」によって達成され得る。
報告方法およびログ利用可能な指示
利用可能な指示なしに報告トリガごとに
−Ｌｏｇｇｅｄ  ＭＤＴ  ｉｎ  Ｃｏｎｎｅｃｔｅｄ
構成
ＵＥベースのＱｏＳ測定のための新しいＩＥを導入するとともに既存のロギングされた測定構成を再利用する。これは、既存のロギングされた測定構成への「アドオン」によって達成され得る。
報告方法およびログ利用可能な指示
選択肢１：ＩＤＬＥからＣＯＮＮへ（および随意としてＨＯごとに）
選択肢２：利用可能な指示なし（ｅＮＢ実装形態まで）
注：この場合、ロギングされたＭＤＴ、ＰＤＣＰ  ＳＤＵの数、平均ＱｏＳ測定結果、ならびに（随意の）９５％ワーストＱｏＳ測定結果および（随意の）５％ワーストＱｏＳ測定結果のようないくつかの他の結果。
【０２０３】
［測定識別情報］
（サイドリンクデータ損失）
ＱＣＩごとのサイドリンクにおけるパケット損失レート。この測定値はＤＲＢについてのパケット損失を指す。１つのパケットは１つのＰＤＣＰ  ＳＤＵに対応する。基準点はＰＤＣＰアッパーＳＡＰである。測定はＱＣＩごとに別々に行われる。
詳細な定義：
【０２０４】
【数１】
2016185986.tif 000009
【０２０５】
【表５】
2016185986.tif 000010
【０２０６】
（サイドリンクＩＰスループット）
サイドリンクにおけるＭＤＴについてのスケジュールされたＩＰスループット。データバーストの最後のＴＴＩ中で送信されるデータを除外することによる、送信がいくつかのＴＴＩにわたって分割されることを要求するのに十分大きいデータバーストについてのサイドリンクにおけるＰＤＣＰ  ＳＤＵビットのスループットのｅＮＢ推定値。データ送信時間のみ、すなわち、サイドリンクを介したデータ送信が開始したがまだ終了していないときのみが考慮される。測定はＤ２Ｄ  ＵＥごとに実施される。成功した受信について、基準点はＭＡＣアッパーＳＡＰである。
【０２０７】
この測定値は、測定期間のための以下の式によって取得される。
【０２０８】
【数２】
2016185986.tif 000011
【０２０９】
【表６】
2016185986.tif 000012
【０２１０】
（サイドリンクデータボリューム）
サイドリンクにおけるＭＤＴについてのデータボリューム。測定期間中にサイドリンクにおいて１つのＤ２Ｄ  ＵＥによって正常に受信されるＰＤＣＰ  ＳＤＵビットの量。測定は、Ｄ２Ｄ  ＵＥごとにＱＣＩごとに実施される。単位はキロビットである。
【０２１１】
（サイドリンクパケット遅延／アップリンクパケット遅延）
ＱＣＩごとのサイドリンク／アップリンクにおけるパケット遅延。この測定値はＤＲＢについてのパケット遅延を指す。パケットの到着について、基準点はＰＤＣＰアッパーＳＡＰである。成功した受信について、基準点はＭＡＣロウアーＳＡＰである。測定はＱＣＩごとに別々に行われる。
【０２１２】
詳細な定義：
【数３】
2016185986.tif 000013
【０２１３】
【表７】
2016185986.tif 000014
【０２１４】
（ＵＥベースのＱｏＳ測定のためのＭＤＴ）
［フローチャート］
−Ｉｍｍｅｄｉａｔｅ  ＭＤＴ
図１３は、この場合のフローチャートを示す。
【０２１５】
注：ｅＮＢは、ＵＥのＢＳＲに基づいてＤ２Ｄ終了に気づき得る。
【０２１６】
−Ｌｏｇｇｅｄ  ＭＤＴ  ｉｎ  Ｃｏｎｎｅｃｔｅｄ
選択肢１：ＩＤＬＥからＣＯＮＮへ（およびオプションとしてＨＯごとに）
既存のＬｏｇｇｅｄ  ＭＤＴ  ｉｎ  Ｃｏｎｎｅｃｔｅｄの手順を再利用することができる。
【０２１７】
図１４は、この場合のフローチャートを示す。
【０２１８】
選択肢２：利用可能な指示なし（ｅＮＢ実装形態まで）
ｅＮＢはＵＥのＢＳＲに基づいてＤ２Ｄ終了に気づき得るので、ｅＮＢは、Ｄ２Ｄ通信が完了した後にＱｏＳ測定ログを取り出すことができる。
【０２１９】
［相互参照］
米国仮出願第６２／１６２１６７号（２０１５年５月１５日出願）、米国仮出願第６２／２３２９３４号（２０１５年９月２５日出願）、及び米国仮出願第６２／２７５０４７号（２０１６年１月５日出願）の全内容が参照により本願明細書に組み込まれている。
【産業上の利用可能性】
【０２２０】
本発明は、通信分野において有用である。
【図１】
2016185986.tif 000015
【図２】
2016185986.tif 000016
【図３】
2016185986.tif 000017
【図４】
2016185986.tif 000018
【図５】
2016185986.tif 000019
【図６】
2016185986.tif 000020
【図７】
2016185986.tif 000021
【図８】
2016185986.tif 000022
【図９】
2016185986.tif 000023
【図１０】
2016185986.tif 000024
【図１１】
2016185986.tif 000025
【図１２】
2016185986.tif 000026
【図１３】
2016185986.tif 000027
【図１４】
2016185986.tif 000028
【手続補正書】
【提出日】平成29年11月13日(2017.11.13)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
上りリンクにおけるデータパケットのキューイング遅延の測定を設定するための設定情報を無線基地局から個別に受信する受信部と、
前記測定を行う制御部と、
前記測定の結果を単位時間毎に前記無線基地局に報告する送信部とを備え、
前記測定情報は、前記単位時間の長さを示す情報と、前記キューイング遅延に関する閾値を示す閾値情報を、を含み、
前記制御部は、前記単位時間毎に前記測定を行い、
前記送信部は、前記単位時間内において、前記閾値を超えた前記キューイング遅延が測定される場合、前記測定の結果を報告し、
前記送信部は、前記単位時間内において、前記閾値を超えた前記キューイング遅延が測定されない場合、前記測定の結果を報告しないユーザ端末。
【請求項２】
通信方法であって、
無線基地局が、ユーザ端末に対して、上りリンクにおけるデータパケットのキューイング遅延の測定を設定するための設定情報を個別に送信する送信ステップと、
前記ユーザ端末が、前記測定を行う測定ステップと、
前記ユーザ端末が、前記測定の結果を単位時間毎に前記無線基地局に報告する送信ステップと、を備え、
前記測定情報は、前記単位時間の長さを示す情報と、前記キューイング遅延に関する閾値を示す閾値情報を、を含み、
前記測定ステップは、前記ユーザ端末が前記単位時間毎に前記測定を行うステップを含み、
前記送信ステップにおいて、
前記ユーザ端末は、前記単位時間内において、前記閾値を超えた前記キューイング遅延が測定される場合、前記測定の結果を報告し、
前記ユーザ端末は、前記単位時間内において、前記閾値を超えた前記キューイング遅延が測定されない場合、前記測定の結果を報告しない、通信方法。
【請求項３】
ユーザ端末を制御するためのプロセッサであって、
上りリンクにおけるデータパケットのキューイング遅延の測定を設定するための設定情報を無線基地局から個別に受信する受信処理と、
前記測定を行う測定処理と、
前記測定の結果を単位時間毎に前記無線基地局に報告する送信処理と、を実行し、
前記測定情報は、前記単位時間の長さを示す情報と、前記キューイング遅延に関する閾値を示す閾値情報を、を含み、
前記測定処理ステップは、前記ユーザ端末が前記単位時間毎に前記測定を行うステップを含み、
前記送信ステップにおいて、
前記プロセッサは、前記単位時間内において、前記閾値を超えた前記キューイング遅延が測定される場合、前記測定の結果を報告し、
前記プロセッサは、前記単位時間内において、前記閾値を超えた前記キューイング遅延が測定されない場合、前記測定の結果を報告しない、プロセッサ。
【国際調査報告】
2016185986.tif 000029
2016185986.tif 000030
2016185986.tif 000031
2016185986.tif 000032
2016185986.tif 000033
2016185986.tif 000034
2016185986.tif 000035
2016185986.tif 000036