JP5882345B2 - 移動通信方法、ユーザ端末、及びプロセッサ - Google Patents

Description

本発明は、３ＧＰＰ規格に基づく移動通信システムにおける移動通信方法、ユーザ端末、及びプロセッサに関する。

移動通信システムでは、基地局の周辺にビルが建設されたり、当該基地局の周辺基地局の設置状況が変化したりすると、当該基地局に係る無線通信環境が変化する。このため、従来では、オペレータにより、測定機材を搭載した測定用車両を使用し、基地局からの無線信号の受信状態（以下、「無線状態」と称する）を測定して測定データを収集するドライブテストが行われている。

このような測定及び収集は、例えば基地局のカバレッジの最適化に貢献できるが、工数が多く、且つ費用が高いという課題がある。そこで、移動通信システムの標準化プロジェクトである３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）では、ユーザが所持するユーザ端末を使用して、当該測定及び収集を自動化するためのＭＤＴ（Ｍｉｎｉｍｉｚａｔｉｏｎ ｏｆ Ｄｒｉｖｅ Ｔｅｓｔｓ）の仕様策定が進められている（非特許文献１参照）。

ＭＤＴの一方式として、記録型のＭＤＴ（「Ｌｏｇｇｅｄ ＭＤＴ」と称される）がある。現行の仕様において、Ｌｏｇｇｅｄ ＭＤＴは、アイドル状態のユーザ端末が、ネットワークから設定された測定構成情報に従って無線状態の測定を行い、測定結果を位置情報及び時間情報と共に測定データとして記録し、記録した測定データを後でネットワークに報告するものである。

また、ＭＤＴの他の方式として、即座報告型のＭＤＴ（「Ｉｍｍｅｄｉａｔｅ ＭＤＴ」と称される）がある。現行の仕様において、Ｉｍｍｅｄｉａｔｅ ＭＤＴは、コネクティッド状態のユーザ端末が、ネットワークから設定された測定構成情報に従って無線状態の測定を行い、測定結果を位置情報と共に測定データとしてネットワークに報告するものである。

このように、現行のＭＤＴの仕様においては、ユーザ端末は、無線状態の測定、すなわち、低位レイヤ（物理レイヤ）での測定を行う。このような測定により得られた測定データをネットワークが収集することで、不感地帯（カバレッジホール）を特定し、当該カバレッジホールを解消するといったカバレッジ最適化を行うことができる。

３ＧＰＰ ＴＳ ３７．３２０ ｖ１０．１．０

しかしながら、現行のＭＤＴの仕様は、移動通信システムのカバレッジ最適化に寄与できるものの、通信容量（キャパシティ）の最適化には必ずしも適していない。例えば、無線状態は良好であるにもかかわらずキャパシティの少ない地帯（低キャパシティ地帯）を特定することは困難である。

そこで、本発明は、移動通信システムのキャパシティ最適化に寄与できる移動通信方法、ユーザ端末、及びプロセッサを提供する。

本発明に係る移動通信方法は、ＭＤＴ（Ｍｉｎｉｍｉｚａｔｉｏｎ ｏｆ Ｄｒｉｖｅ Ｔｅｓｔｓ）をサポートする移動通信システムにおける移動通信方法であって、ユーザ端末と、前記ユーザ端末との通信を行うネットワークと、の間の通信におけるＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）パラメータを測定するＭＤＴを、Ｉｍｍｅｄｉａｔｅ ＭＤＴ方式で行うステップを有することを特徴とする。

前記ステップは、前記ユーザ端末の位置情報を含む報告を、前記ユーザ端末から前記ネットワークに送信する報告ステップを含んでもよい。

前記報告ステップは、定期的に前記報告を前記ネットワークに送信するステップを含んでもよい。

前記ＱｏＳパラメータとは、物理レイヤよりも上位のレイヤで測定されるパラメータであってもよい。

前記ステップは、前記ＱｏＳパラメータをＱＣＩ（ＱｏＳ Ｃｌａｓｓ Ｉｄｅｎｔｉｆｉｅｒ）毎に測定する測定ステップを含んでもよい。

本発明に係るユーザ端末は、ＭＤＴ（Ｍｉｎｉｍｉｚａｔｉｏｎ ｏｆ Ｄｒｉｖｅ Ｔｅｓｔｓ）をサポートするユーザ端末であって、該ユーザ端末と、該ユーザ端末との通信を行うネットワークと、の間の通信におけるＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）パラメータを測定するＭＤＴを、Ｉｍｍｅｄｉａｔｅ ＭＤＴ方式で行う制御部を有することを特徴とする。

本発明に係るプロセッサは、ＭＤＴ（Ｍｉｎｉｍｉｚａｔｉｏｎ ｏｆ Ｄｒｉｖｅ Ｔｅｓｔｓ）をサポートするユーザ端末に備えられるプロセッサであって、該ユーザ端末と、該ユーザ端末との通信を行うネットワークと、の間の通信におけるＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）パラメータを測定するＭＤＴを、Ｉｍｍｅｄｉａｔｅ ＭＤＴ方式で行うことを特徴とする。

本発明の実施形態に係る移動通信システムの全体構成図である。 本発明の実施形態に係るｅＮＢ（基地局）のブロック図である。 本発明の実施形態に係るＵＥ（ユーザ端末）のブロック図である。 本発明の実施形態に係るＱＣＩテーブルを示す図である。 本発明の実施形態に係る定期報告型の動作パターン１の動作フロー図である。 本発明の実施形態に係る定期報告型の動作パターン２の動作フロー図である。 本発明の実施形態に係る定期報告型の動作パターン３の動作フロー図である。 本発明の実施形態に係る定期報告型の動作パターン４の動作フロー図である。 本発明の実施形態に係る定期報告型の動作パターン５の動作フロー図である。 本発明の実施形態に係るイベントトリガ型の動作パターン１の動作フロー図である。 本発明の実施形態に係るイベントトリガ型の動作パターン２の動作フロー図である。 本発明の実施形態に係るイベントトリガ型の動作パターン３の動作フロー図である。 本発明の実施形態に係るイベントトリガ型の動作パターン４の動作フロー図である。

図面を参照して、本発明の実施形態を説明する。以下の実施形態に係る図面において、同一又は類似の部分には同一又は類似の符号を付す。

（移動通信システムの構成）
図１は、本実施形態に係る移動通信システム１の全体構成図である。本実施形態に係る移動通信システム１は、３ＧＰＰで仕様が策定されているＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）又はＬＴＥ−Ａｄｖａｎｃｅｄに基づいて構成されており、上述したＩｍｍｅｄｉａｔｅ ＭＤＴをサポートする。

図１に示すように、移動通信システム１は、ｅＮＢ（ｅｖｏｌｖｅｄ Ｎｏｄｅ−Ｂ）１００、ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）２００、ＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）／Ｓ−ＧＷ（Ｓｅｒｖｉｎｇ Ｇａｔｅｗａｙ）３１０、及びＯＡＭ（Ｏｐｅｒａｔｉｏｎ ａｎｄ Ｍａｉｎｔｅｎａｎｃｅ）３２０を有する。本実施形態において、ｅＮＢ１００は基地局に相当し、ＵＥ２００はユーザ端末に相当する。

複数のｅＮＢ１００は、ＬＴＥの無線アクセスネットワークであるＥ−ＵＴＲＡＮ（Ｅｖｏｌｖｅｄ−ＵＭＴＳ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）１０を構成する。複数のＭＭＥ／Ｓ−ＧＷ３１０は、ＬＴＥのコアネットワークであるＥＰＣ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ）３００を構成する。本実施形態において、Ｅ−ＵＴＲＡＮ１０及びＥＰＣ３００は、ネットワークを構成する。また、ＯＡＭ３２０も当該ネットワークに含まれてもよい。

各ｅＮＢ１００は、オペレータによって設置される固定型の無線通信装置であり、ＵＥ２００との無線通信を行うように構成される。各ｅＮＢ１００は、隣接する他のｅＮＢ１００との通信をＸ２インターフェイス上で行い、ＭＭＥ／Ｓ−ＧＷ３１０との通信をＳ１インターフェイス上で行う。

各ｅＮＢ１００は、無線通信エリアの最小単位であるセルを１つ又は複数形成する。各ｅＮＢ１００は、セルを識別可能な参照信号を常時ブロードキャストしている。移動通信システム１では、１つ又は複数のセルによって１つのトラッキングエリア（ＴＡ）が構成される。ＴＡは、位置登録及びページングを行うエリア単位である。

ＵＥ２００は、ユーザが所持する可搬型の無線通信装置である。ＵＥ２００は、ｅＮＢ１００が形成するセルにアクセスし、当該セルに収容される。ＵＥ２００を収容するセルはサービングセルと称される。

また、ＵＥ２００は、１又は複数のアプリケーションを実行し、当該アプリケーションを用いて通信を行う。ＵＥ２００が通信先と通信実行中の状態はコネクティッド状態と称され、ＵＥ２００が待ち受け中の状態はアイドル状態と称される。

ＵＥ２００は、最も通信状態の良好なセルへサービングセルを切り替える。コネクティッド状態におけるサービングセルの切り替えはハンドオーバと称される。ハンドオーバは、サービングセル（ｅＮＢ１００）によって制御される。

ＵＥ２００は、サービングセルの制御下で、サービングセル及び隣接セルからの無線状態（以下、単に「無線状態」と称する）を測定し、測定結果に関する報告をサービングセルに送信する。このような報告は、メジャメント報告と称される。なお、無線状態とは、例えば参照信号受信電力（ＲＳＲＰ）や参照信号受信品質（ＲＳＲＱ）である。

ＭＭＥは、ＵＥ２００が在圏するＴＡ及び／又はセルを管理しており、ＵＥ２００に対する各種モビリティ管理を行うように構成される。Ｓ−ＧＷは、ＵＥ２００が送受信するユーザデータの転送制御を行うように構成される。ＯＡＭ３２０は、オペレータによって設置されるサーバ装置であり、Ｅ−ＵＴＲＡＮ１０の保守及び監視を行うように構成される。

ｅＮＢ１００は、必要に応じて、Ｉｍｍｅｄｉａｔｅ ＭＤＴのための構成情報（Ｃｏｎｆｉｇｕｒａｔｉｏｎ情報）を、自局配下の（コネクティッド状態の）ＵＥ２００に送信する。Ｉｍｍｅｄｉａｔｅ ＭＤＴは、上述したメジャメント報告の機能を拡張したものであり、ＵＥ２００の位置情報を報告に含めることができる。位置情報とは、ＵＥ２００がＧＰＳ機能を有している場合にはＧＰＳ位置情報であり、ＵＥ２００がＧＰＳ機能を有していない場合にはＲＦフィンガープリント情報である。

Ｉｍｍｅｄｉａｔｅ ＭＤＴが設定されたＵＥ２００からの測定データ（無線状態情報及び位置情報）を受信したｅＮＢ１００は、受信した測定データをＯＡＭ３２０に転送する。ＯＡＭ３２０は、このようにして得られた測定データに基づいてカバレッジ問題を発見すると、発見したカバレッジ問題を、オペレータに通知する、もしくは解消するためのネットワーク最適化を行う。

本実施形態では、ＵＥ２００は、Ｉｍｍｅｄｉａｔｅ ＭＤＴにおいて、無線状態の測定を行うだけでなく、ネットワークとの通信におけるＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ ＳｅｒｖｉｃｅＱｕａｌｉｔｙ）パラメータを測定する。ＱｏＳパラメータとは、例えば、パケットの伝送遅延、パケットのロス率、又は伝送遅延の揺らぎ（ジッタ）などであり、アプリケーションレベルで測定可能なパラメータである。ここで、ＵＥ２００は、ネットワークとの通信内容毎にＱｏＳパラメータを測定することが好ましい。通信内容とは、例えば、アプリケーション（サービス）又はベアラなどであるが、以下においては、アプリケーション毎にＱｏＳパラメータを測定する一例を説明する。

そして、ＵＥ２００は、測定したＱｏＳパラメータに関する情報を含む報告をネットワークに送信する。これにより、ネットワークは、ＱｏＳパラメータに関する情報に基づいて、キャパシティ最適化を図ることができる。例えば、無線状態は良好であるにもかかわらず、キャパシティの少ない地帯（低キャパシティ地帯）を特定できる。

次に、ｅＮＢ１００の構成を説明する。図２は、ｅＮＢ１００のブロック図である。

図２に示すように、ｅＮＢ１００は、アンテナ１０１、無線通信部１１０、ネットワーク通信部１２０、記憶部１３０、及び制御部１４０を有する。

アンテナ１０１は、無線信号の送受信に用いられる。無線通信部１１０は、例えば無線周波数（ＲＦ）回路やベースバンド（ＢＢ）回路等を用いて構成され、アンテナ１０１を介して無線信号を送受信する。ネットワーク通信部１２０は、他のネットワークエンティティ（ＭＭＥ／Ｓ−ＧＷ３１０、ＯＡＭ３２０、及び隣接ｅＮＢ１００など）との通信を行う。記憶部１３０は、例えばメモリを用いて構成され、ｅＮＢ１００の制御等に用いられる各種の情報を記憶する。制御部１４０は、例えばプロセッサを用いて構成され、ｅＮＢ１００が備える各種の機能を制御する。

制御部１４０は、ＵＥ２００に対して時間・周波数リソースを割り当てるスケジューラ機能を有する。また、制御部１４０は、ＵＥ２００からのメジャメント報告に基づいて当該ＵＥ２００のハンドオーバを制御する機能を有する。さらに、制御部１４０は、ＭＤＴのための測定構成情報を生成し、当該測定構成情報をＵＥ２００に送信する機能を有する。

次に、ＵＥ２００の構成を説明する。図３は、ＵＥ２００のブロック図である。

図３に示すように、ＵＥ２００は、アンテナ２０１、無線通信部２１０、ユーザインターフェイス部２２０、ＧＰＳ受信機２３０、バッテリ２４０、記憶部２５０、及び制御部２６０を有する。ただし、ＵＥ２００は、ＧＰＳ受信機２３０を有していなくてもよい。また、ＵＥ２００がカード型端末などであれば、ユーザインターフェイス部２２０及びバッテリ２４０を有していなくてもよい。

アンテナ２０１は、無線信号の送受信に用いられる。無線通信部２１０は、例えばＲＦ回路やＢＢ回路等を用いて構成され、アンテナ２０１を介して無線信号を送受信する。ユーザインターフェイス部２２０は、ユーザとのインターフェイスとして機能するディスプレイやボタン等である。バッテリ２４０は、充電可能なバッテリであって、ＵＥ２００の各ブロックに供給される電力を蓄える。記憶部２５０は、例えばメモリを用いて構成され、ＵＥ２００の制御等に用いられる各種の情報を記憶する。制御部２６０は、例えばプロセッサを用いて構成され、ＵＥ２００が備える各種の機能を制御する。

本実施形態では、制御部２６０は、１又は複数のアプリケーションを実行し、コネクティッド状態において、当該アプリケーションを用いて通信を行う。ＵＥ２００とネットワーク（ｅＮＢ１００）との通信には、アプリケーション種別に応じた優先制御（すなわち、ＱｏＳ制御）が適用される。ＱｏＳ制御は、ＵＥ２００及びネットワーク（ｅＮＢ１００）のそれぞれで行われる。ＬＴＥでは、ＱｏＳ制御におけるクラスを定めるために、ＱＣＩ（ＱｏＳ Ｃｌａｓｓ Ｉｄｅｎｔｉｆｉｅｒ）が規定されている。記憶部２５０は、ＱＣＩに関する情報（ＱＣＩテーブル）を予め記憶している。

図４は、ＱＣＩテーブルの一例を示す。図４に示すように、ＱＣＩは９段階定められており、ＱＣＩの１〜４は帯域保証されるＧＢＲ（Ｇｕａｒａｎｔｅｅｄ Ｂｉｔ Ｒａｔｅ）、５〜９は帯域保証されないＮｏｎ−ＧＢＲなど、ＱＣＩに応じて各ベアラでＱｏＳ制御される。また、各ＱＣＩには、要求されるＱｏＳパラメータの閾値（以下、「ＱＣＩ要求閾値」と称する）が対応付けられている。図４の例では、ＱＣＩ要求閾値として、遅延許容時間（Ｄｅｌａｙ Ｂｕｄｇｅｔ）、パケットロス率を示している。ｅＮＢ１００のスケジューラ機能は、ＵＥ２００が実行しているアプリケーションに対応したＱＣＩが示す優先度に応じて、優先制御（ＱｏＳ制御）を行う。

本実施形態では、制御部２６０は、図４に示すようなＱＣＩテーブルを用いて、ＭＤＴのための各種制御を行う。以下において、制御部２６０の機能を中心に、ＭＤＴに関連する移動通信システム１の動作を説明する。

（移動通信システムの動作）
ＭＤＴに関連する移動通信システム１の動作について、（１）定期報告型、（２）イベントトリガ型の順に説明する。

定期報告型は、ＵＥ２００がメジャメント報告を定期的にネットワークに送信する方式である。ＵＥ２００は、無線状態及びＱｏＳパラメータを定期的に測定するとともに、定期的にメジャメント報告を送信する。

イベントトリガ型は、所定の契機で報告送信を行う方式である。所定の契機で測定結果を記録する方式もイベントトリガ型に含まれる。

なお、以下の各動作パターンにおける開始時において、ＵＥ２００はコネクティッド状態であるとする。

（１）定期報告型
以下において、定期報告型の動作パターン１〜５について説明する。

（１．１）定期報告型の動作パターン１
図５は、定期報告型の動作パターン１の動作フロー図である。

図５に示すように、ステップＳ１００において、測定構成処理が行われる。

詳細には、ｅＮＢ１００の制御部１４０は、ＵＥ２００のための測定構成情報を生成した後、測定構成情報をＵＥ２００に送信するよう無線通信部１１０を制御する。当該測定構成情報は、無線状態情報の定期的な報告を指示する情報を含む。あるいは、当該測定構成情報は、ＱｏＳに係る定期的な報告を指示する情報を含んでもよい。この場合、測定の対象とすべきアプリケーション、ベアラ、又はＱＣＩ種別（１〜９の何れか）を指定する情報を含んでもよい。

ＵＥ２００の無線通信部２１０は、測定構成情報を受信する。ＵＥ２００の制御部２６０は、無線通信部２１０が受信した測定構成情報を記憶部２５０に記憶させる。また、制御部２６０は、当該測定構成情報に従って測定処理を開始する。本動作パターンでは、ＱｏＳに係る定期的な報告が指示されていない場合でも、ＱｏＳパラメータの測定が行われる。

次に、ステップＳ１０１において、制御部２６０は、無線通信部２１０が受信する無線信号に基づいて無線状態を測定する。制御部２６０は、サービングセル及び隣接セルのそれぞれについて無線状態の測定を行うことで得られた無線状態情報を記憶部２５０に記憶させる。その後、処理がステップＳ１０２に進む。

ステップＳ１０２において、制御部２６０は、実行中のアプリケーションについてＱｏＳパラメータを測定する。ここでは、ＱｏＳパラメータとして、パケット伝送遅延及びパケットロス率を測定する。制御部２６０は、測定したＱｏＳパラメータを記憶部２５０に記憶させる。その後、処理がステップＳ１０３に進む。なお、ステップＳ１０２の処理はステップＳ１００とステップＳ１０１との間でもよい。

ステップＳ１０３において、制御部２６０は、記憶部２５０に記憶されているＱＣＩテーブルを用いて、測定したＱｏＳパラメータを、実行中のアプリケーションに対応するＱＣＩ要求閾値と比較する。その後、処理がステップＳ１０４に進む。

ステップＳ１０４において、制御部２６０は、測定したＱｏＳパラメータが、実行中のアプリケーションに対応するＱＣＩ要求閾値を満たすか否かを確認する。ＱＣＩ要求閾値を満たす場合（ステップＳ１０４；ＹＥＳ）、処理がステップＳ１０５に進む。ＱＣＩ要求閾値を満たさない場合（ステップＳ１０４；ＮＯ）、処理がステップＳ１０６に進む。

ステップＳ１０５において、制御部２６０は、ＱＣＩ要求閾値を満たす旨のＱｏＳ報告情報を作成して、記憶部２５０に記憶させる。その後、処理がステップＳ１０７に進む。

これに対し、ステップＳ１０６において、制御部２６０は、ＱＣＩ要求閾値を満たしていない旨のＱｏＳ報告情報を作成して、記憶部２５０に記憶させる。例えば、ＱＣＩ要求閾値を満たさなかったＱＣＩ種別（１〜９の何れか）を示す情報、及び／又は、ＱＣＩ要求閾値を満たさなかったＱｏＳパラメータ（パケット伝送遅延、パケットロス率）を示す情報をＱｏＳ報告情報として作成し、記憶部２５０に記憶させる。その後、処理がステップＳ１０７に進む。

ステップＳ１０７において、制御部２６０は、ステップＳ１０１で測定され、記憶部２５０に記憶されている無線状態情報と、ステップＳ１０５又はＳ１０６で作成され、記憶部２５０に記憶されているＱｏＳ報告情報と、を含む報告をｅＮＢ１００に送信するよう無線通信部２１０を制御する。その後、処理がステップＳ１０１に戻る。

なお、本動作パターンでは、説明の便宜上、１つのアプリケーション（サービス）についてＱｏＳパラメータを測定する一例を説明したが、複数のアプリケーションについてＱｏＳパラメータを測定してもよい。この場合、各アプリケーションについてＱｏＳ報告情報を作成し、複数のＱｏＳ報告情報を１つの報告に含めて送信してもよい。あるいは、ＱＣＩ要求閾値を満たさなかったＱｏＳ報告情報を１つの報告に含めて送信してもよい。以下の定期報告型の動作パターン２〜５においても同様である。

また、ｅＮＢ１００に送信する報告には、直近に得られたＵＥ２００の位置情報が含まれる。以下の定期報告型の動作パターン２〜５においても同様である。

（１．２）定期報告型の動作パターン２
図６は、定期報告型の動作パターン２の動作フロー図である。ステップＳ１１０〜ステップＳ１１３の各処理は定期報告型の動作パターン１と同様であるため、ステップＳ１１４以降について説明する。

図６に示すように、ステップＳ１１４において、制御部２６０は、測定したＱｏＳパラメータが、実行中のアプリケーションに対応するＱＣＩ要求閾値を満たすか否かを確認する。ＱＣＩ要求閾値を満たす場合（ステップＳ１１４；ＹＥＳ）、処理がステップＳ１１７に進む。ＱＣＩ要求閾値を満たさない場合（ステップＳ１１４；ＮＯ）、処理がステップＳ１１６に進む。

ステップＳ１１６において、制御部２６０は、ＱＣＩ要求閾値を満たしていない旨のＱｏＳ報告情報を作成して、記憶部２５０に記憶させる。例えば、ＱＣＩ要求閾値を満たさなかったＱＣＩ種別（１〜９の何れか）を示す情報、及び／又は、ＱＣＩ要求閾値を満たさなかったＱｏＳパラメータ（パケット伝送遅延、パケットロス率）を示す情報をＱｏＳ報告情報として作成し、記憶部２５０に記憶させる。その後、処理がステップＳ１１７に進む。

ステップＳ１１７において、制御部２６０は、ステップＳ１１１で測定され、記憶部２５０に記憶されている無線状態情報を含む報告をｅＮＢ１００に送信するよう無線通信部２１０を制御する。ここで、ステップＳ１１６でＱｏＳ報告情報が作成されている場合には、制御部２６０は、当該ＱｏＳ報告情報も当該報告に含めて送信するよう制御する。その後、処理がステップＳ１１１に戻る。

このように、本動作パターンでは、ＱＣＩ要求閾値を満たす場合には報告対象としないため、動作パターン１と比べて、報告に含めるべき情報の量（すなわち、オーバーヘッド）を削減できる。

（１．３）定期報告型の動作パターン３
図７は、定期報告型の動作パターン３の動作フロー図である。ステップＳ１２０〜ステップＳ１２６の各処理は定期報告型の動作パターン１と同様であるため、ステップＳ１２７以降について説明する。

図７に示すように、ステップＳ１２７において、制御部２６０は、記憶部２５０に記憶されている無線状態情報に基づいて、ステップＳ１２１で測定した無線状態が無線状態閾値を満たすか否かを確認する。無線状態閾値は、例えば、記憶部２５０に予め記憶されている。無線状態閾値を満たす場合（ステップＳ１２７；ＹＥＳ）、処理がステップＳ１２８に進む。無線状態閾値を満たさない場合（ステップＳ１２７；ＮＯ）、処理がステップＳ１２９ａに進む。

ステップＳ１２８において、制御部２６０は、ステップＳ１２１で測定され、記憶部２５０に記憶されている無線状態情報と、ステップＳ１２５又はＳ１２６で作成され、記憶部２５０に記憶されているＱｏＳ報告情報と、を含む報告をｅＮＢ１００に送信するよう無線通信部２１０を制御する。その後、処理がステップＳ１２１に戻る。

一方、ステップＳ１２９ａにおいて、制御部２６０は、記憶部２５０に記憶されているＱｏＳ報告情報を保持したまま、ステップＳ１２９ｂにおいて、記憶部２５０に記憶されている無線状態情報含む報告をｅＮＢ１００に送信するよう無線通信部２１０を制御する。その後、処理がステップＳ１２１に戻る。なお、その後に無線状態が回復した場合には、処理がステップＳ１２１に戻った後のステップＳ１２８において、記憶部２５０に記憶されているＱｏＳ報告情報も併せて送信される。

このように、無線状態が劣化した状態においては、オーバーヘッドを削減することが好ましいため、ＱｏＳ報告情報を報告対象とせずに保持しておく。そして、無線状態が回復した後で当該ＱｏＳ報告情報を報告に含めて送信できる。

なお、動作パターン２と同様に、ステップＳ１２５を省略し、ＱＣＩ要求閾値を満たす場合には報告対象としないようにしてもよい。

（１．４）定期報告型の動作パターン４
図８は、定期報告型の動作パターン４の動作フロー図である。ステップＳ１３０〜ステップＳ１３６の各処理は定期報告型の動作パターン１と同様であるため、ステップＳ１３７以降について説明する。なお、本動作パターンは、ＱｏＳに係る報告に主眼を置いている。

図８に示すように、ステップＳ１３７において、制御部２６０は、記憶部２５０に記憶されている無線状態情報に基づいて、ステップＳ１３１で測定した無線状態が無線状態閾値を満たすか否かを確認する。無線状態閾値は、例えば、記憶部２５０に予め記憶されている。無線状態閾値を満たす場合（ステップＳ１３７；ＹＥＳ）、処理がステップＳ１３８に進む。無線状態閾値を満たさない場合（ステップＳ１３７；ＮＯ）、処理がステップＳ１３９に進む。

ステップＳ１３８において、制御部２６０は、ステップＳ１３１で測定され、記憶部２５０に記憶されている無線状態情報と、ステップＳ１３５又はＳ１３６で作成され、記憶部２５０に記憶されているＱｏＳ報告情報と、を含む報告をｅＮＢ１００に送信するよう無線通信部２１０を制御する。その後、処理がステップＳ１３１に戻る。

一方、ステップＳ１３９において、制御部２６０は、Ｉｍｍｅｄｉａｔｅ ＭＤＴ方式から、コネクティッド状態でのＬｏｇｇｅｄ ＭＤＴ（以下、「Ｌｏｇｇｅｄ ＭＤＴ ｉｎ Ｃｏｎｎｅｃｔｅｄ」と称する）方式に切り替える。

Ｌｏｇｇｅｄ ＭＤＴ ｉｎ Ｃｏｎｎｅｃｔｅｄ方式は、詳細については後述するが、即座に報告するのではなく、測定結果を記憶して事後的に報告するものであるため、ネットワークは無線環境の良い時に測定結果を収集でき、相対的に負荷が軽くなる。またＵＥも、報告の際に低い電力で送信できる可能性があるため、電力削減にもつながる。さらに、コネクティッド状態が維持されるため、ＱｏＳパラメータの測定も継続できる。

さらに、動作パターン２と同様に、ステップＳ１３５を省略し、ＱＣＩ要求閾値を満たす場合には報告対象としないようにしてもよい。

（１．５）定期報告型の動作パターン５
図９は、定期報告型の動作パターン５の動作フロー図である。ステップＳ１４０〜ステップＳ１４３の各処理は定期報告型の動作パターン１と同様であるため、ステップＳ１４４以降について説明する。なお、本動作パターンでは、無線状態の測定（ステップＳ１４１）は省略してもよい。

図９に示すように、ステップＳ１４４において、制御部２６０は、測定したＱｏＳパラメータが、実行中のアプリケーションに対応するＱＣＩ要求閾値を満たすか否かを確認する。ＱＣＩ要求閾値を満たす場合（ステップＳ１４４；ＹＥＳ）、処理がステップＳ１４５に進む。ＱＣＩ要求閾値を満たさない場合（ステップＳ１４４；ＮＯ）、処理がステップＳ１４７に進む。

ステップＳ１４５において、制御部２６０は、ＱＣＩ要求閾値を満たす旨のＱｏＳ報告情報を作成して、記憶部２５０に記憶させる。その後、処理がステップＳ１４６に進む。ステップＳ１４６において、制御部２６０は、当該ＱｏＳ報告情報を含む報告をｅＮＢ１００に送信するよう無線通信部２１０を制御する。ステップＳ１４１で無線状態が測定されている場合には、当該測定に無線状態情報を含めてもよい。その後、処理がステップＳ１４１に戻る。

一方、ステップＳ１４７において、制御部２６０は、報告の送信を中止する。その後、処理がステップＳ１４１に戻る。

このように、本動作パターンでは、ＱＣＩ要求閾値が満たされていない場合には、無線状態も劣化している可能性があるため、報告を中止する。これにより、再送が繰り返されてオーバーヘッドが増加することを防止できる。

（２）イベントトリガ型
以下において、イベントトリガ型の動作パターン１〜４について説明する。

（２．１）イベントトリガ型の動作パターン１
図１０は、イベントトリガ型の動作パターン１の動作フロー図である。

図１０に示すように、ステップＳ２００において、測定構成処理が行われる。

詳細には、ｅＮＢ１００の制御部１４０は、ＵＥ２００のための測定構成情報を生成した後、測定構成情報をＵＥ２００に送信するよう無線通信部１１０を制御する。当該測定構成情報は、ＱＣＩ要求閾値が満たされないことをトリガとして報告を行うよう指示する情報を含む。なお、測定の対象とすべきアプリケーション、ベアラ、又はＱＣＩ種別（１〜９の何れか）を指定する情報をさらに含んでもよい。

ＵＥ２００の無線通信部２１０は、測定構成情報を受信する。ＵＥ２００の制御部２６０は、無線通信部２１０が受信した測定構成情報を記憶部２５０に記憶させる。また、制御部２６０は、当該測定構成情報に従って測定処理を開始する。

次に、ステップＳ２０１において、制御部２６０は、無線通信部２１０が受信する無線信号に基づいて無線状態を測定する。制御部２６０は、サービングセル及び隣接セルのそれぞれについて無線状態の測定を行うことで得られた無線状態情報を記憶部２５０に記憶させる。その後、処理がステップＳ２０２に進む。

ステップＳ２０２において、制御部２６０は、実行中のアプリケーションについてＱｏＳパラメータを測定する。ここでは、ＱｏＳパラメータとして、パケット伝送遅延及びパケットロス率を測定する。制御部２６０は、測定したＱｏＳパラメータを記憶部２５０に記憶させる。その後、処理がステップＳ２０３に進む。

なお、ステップＳ２０２の処理はステップＳ２００とステップＳ２０１との間でもよい。また、本動作パターンでは、ステップＳ２０１は省略してもよい。

ステップＳ２０３において、制御部２６０は、記憶部２５０に記憶されているＱＣＩテーブルを用いて、測定したＱｏＳパラメータを、実行中のアプリケーションに対応するＱＣＩ要求閾値と比較する。その後、処理がステップＳ２０４に進む。

ステップＳ２０４において、制御部２６０は、測定したＱｏＳパラメータが、実行中のアプリケーションに対応するＱＣＩ要求閾値を満たすか否かを確認する。ＱＣＩ要求閾値を満たす場合（ステップＳ２０４；ＹＥＳ）、処理がステップＳ２０１に戻る。ＱＣＩ要求閾値を満たさない場合（ステップＳ２０４；ＮＯ）、処理がステップＳ２０５に進む。

ステップＳ２０５において、制御部２６０は、ＱＣＩ要求閾値を満たしていない旨のＱｏＳ報告情報を作成して、記憶部２５０に記憶させる。例えば、ＱＣＩ要求閾値を満たさなかったＱＣＩ種別（１〜９の何れか）を示す情報、及び／又は、ＱＣＩ要求閾値を満たさなかったＱｏＳパラメータ（パケット伝送遅延、パケットロス率）を示す情報をＱｏＳ報告情報として作成し、記憶部２５０に記憶させる。その後、処理がステップＳ２０６に進む。

ステップＳ２０６において、制御部２６０は、ステップＳ２０５で作成され、記憶部２５０に記憶されているＱｏＳ報告情報を含む報告をｅＮＢ１００に送信するよう無線通信部２１０を制御する。ステップＳ２０１で無線状態が測定されている場合には、当該報告に無線状態情報を含めてもよい。その後、処理がステップＳ２０１に戻る。

このように、本動作パターンは、定期報告型の動作パターンと比較して、オーバーヘッドをさらに削減できる。

なお、本動作パターンでは、説明の便宜上、１つのアプリケーション（サービス）についてＱｏＳパラメータを測定する一例を説明したが、複数のアプリケーションについてＱｏＳパラメータを測定してもよい。この場合、各アプリケーションについてＱｏＳ報告情報を作成し、複数のＱｏＳ報告情報を１つの報告に含めて送信してもよい。以下のイベントトリガ型の動作パターン２及び３においても同様である。

また、ｅＮＢ１００に送信する報告には、直近に得られたＵＥ２００の位置情報が含まれる。以下のイベントトリガ型の動作パターン２及び３においても同様である。

（２．２）イベントトリガ型の動作パターン２
図１１は、イベントトリガ型の動作パターン２の動作フロー図である。ステップＳ２１０〜ステップＳ２１３の各処理はイベントトリガ型の動作パターン１と同様であるため、ステップＳ２１４以降について説明する。

図１１に示すように、ステップＳ２１４において、制御部２６０は、測定したＱｏＳパラメータが、実行中のアプリケーションに対応するＱＣＩ要求閾値を満たすか否かを確認する。ＱＣＩ要求閾値を満たす場合（ステップＳ２１４；ＹＥＳ）、処理がステップＳ２１１に戻る。ＱＣＩ要求閾値を満たさない場合（ステップＳ２１４；ＮＯ）、処理がステップＳ２１５に進む。

ステップＳ２１５において、制御部２６０は、ＱＣＩ要求閾値を満たさなかったＱＣＩ種別（１〜９の何れか）を示す情報、及び／又は、ＱＣＩ要求閾値を満たさなかったＱｏＳパラメータ（パケット伝送遅延、パケットロス率）を示す情報をＱｏＳ報告情報として作成し、記憶部２５０に記憶させる。その後、処理がステップＳ２１６に進む。

ステップＳ２１６において、制御部２６０は、記憶部２５０に記憶されている無線状態情報に基づいて、ステップＳ２１１で測定した無線状態が無線状態閾値を満たすか否かを確認する。無線状態閾値は、例えば、記憶部２５０に予め記憶されている。無線状態閾値を満たす場合（ステップＳ２１６；ＹＥＳ）、処理がステップＳ２１７に進む。無線状態閾値を満たさない場合（ステップＳ２１６；ＮＯ）、処理がステップＳ２１８に進む。

ステップＳ２１７において、制御部２６０は、ステップＳ２１５で作成され、記憶部２５０に記憶されているＱｏＳ報告情報を含む報告をｅＮＢ１００に送信するよう無線通信部２１０を制御する。制御部２６０は、ステップＳ２１１で測定され、記憶部２５０に記憶されている無線状態情報を当該報告に含めてもよい。その後、処理がステップＳ２１１に戻る。

一方、ステップＳ２１８において、制御部２６０は、送信すべき報告を記憶部２５０に記憶させる。その後、処理がステップＳ２１１に戻る。なお、その後に無線状態が回復した場合には、処理がステップＳ２１１に戻った後のステップＳ２１７において、記憶部２５０に記憶されている報告も併せて送信される。

このように、無線状態が劣化した状態においては、オーバーヘッドを削減することが好ましいため、報告を送信せずに保持しておく。そして、無線状態が回復した後で当該報告を送信できる。

（２．３）イベントトリガ型の動作パターン３
図１２は、イベントトリガ型の動作パターン３の動作フロー図である。ステップＳ２２０〜ステップＳ２２３の各処理はイベントトリガ型の動作パターン１と同様であるため、ステップＳ２２４以降について説明する。

図１２に示すように、ステップＳ２２４において、制御部２６０は、測定したＱｏＳパラメータが、実行中のアプリケーションに対応するＱＣＩ要求閾値を満たすか否かを確認する。ＱＣＩ要求閾値を満たす場合（ステップＳ２２４；ＹＥＳ）、処理がステップＳ２２１に戻る。ＱＣＩ要求閾値を満たさない場合（ステップＳ２２４；ＮＯ）、処理がステップＳ２２５に進む。

ステップＳ２２５において、制御部２６０は、ＱＣＩ要求閾値を満たしていない旨のＱｏＳ報告情報を作成して、記憶部２５０に記憶させる。例えば、ＱＣＩ要求閾値を満たさなかったＱＣＩ種別（１〜９の何れか）を示す情報、及び／又は、ＱＣＩ要求閾値を満たさなかったＱｏＳパラメータ（パケット伝送遅延、パケットロス率）を示す情報をＱｏＳ報告情報として作成し、記憶部２５０に記憶させる。その後、処理がステップＳ２２６に進む。

ステップＳ２２６において、制御部２６０は、記憶部２５０に記憶されている無線状態情報に基づいて、ステップＳ２２１で測定した無線状態が無線状態閾値を満たすか否かを確認する。無線状態閾値は、例えば、記憶部２５０に予め記憶されている。無線状態閾値を満たす場合（ステップＳ２２６；ＹＥＳ）、処理がステップＳ２２７に進む。無線状態閾値を満たさない場合（ステップＳ２２６；ＮＯ）、処理がステップＳ２２８に進む。

ステップＳ２２７において、制御部２６０は、ステップＳ２２５で作成され、記憶部２５０に記憶されているＱｏＳ報告情報を含む報告をｅＮＢ１００に送信するよう無線通信部２１０を制御する。制御部２６０は、ステップＳ２２１で測定され、記憶部２５０に記憶されている無線状態情報を当該報告に含めてもよい。その後、処理がステップＳ２２１に戻る。

一方、ステップＳ２２８において、制御部２６０は、Ｉｍｍｅｄｉａｔｅ ＭＤＴ方式からＬｏｇｇｅｄ ＭＤＴ ｉｎ Ｃｏｎｎｅｃｔｅｄ方式に切り替える。

Ｌｏｇｇｅｄ ＭＤＴ ｉｎ Ｃｏｎｎｅｃｔｅｄ方式は、詳細については後述するが、即座に報告するのではなく、測定結果を記憶して事後的に報告するものであるため、ネットワークは無線環境の良い時に測定結果を収集でき、相対的に負荷が軽くなる。またＵＥも、報告の際に低い電力で送信できる可能性があるため、電力削減にもつながる。さらに、コネクティッド状態が維持されるため、ＱｏＳパラメータの測定も継続できる。

また、本動作パターンでは、測定構成処理（ステップＳ２２０）において、Ｌｏｇｇｅｄ ＭＤＴ ｉｎ Ｃｏｎｎｅｃｔｅｄ方式のための情報を測定構成情報に含めてもよい。例えば、Ｌｏｇｇｅｄ ＭＤＴ ｉｎ Ｃｏｎｎｅｃｔｅｄ方式において定期的な記録（ロギング）を行う場合には、記録間隔を指定する情報を測定構成情報に含める。あるいは、Ｌｏｇｇｅｄ ＭＤＴ ｉｎ Ｃｏｎｎｅｃｔｅｄ方式においてイベントトリガで記録（ロギング）を行う場合には、トリガとなるＱｏＳ閾値を指定する情報を測定構成情報に含める。また、記録時の時間情報を得るためのネットワーク絶対時間を測定構成情報に含めてもよい。さらに、測定データの継続時間を指定する情報を測定構成情報に含めてもよい。以下のイベントトリガ型の動作パターン４においても同様である。

（２．４）イベントトリガ型の動作パターン４
図１３は、イベントトリガ型の動作パターン４の動作フロー図である。ステップＳ２３０の処理はイベントトリガ型の動作パターン１と同様であるため、ステップＳ２３１以降について説明する。

図１３に示すように、ステップＳ２３１において、制御部２６０は、Ｌｏｇｇｅｄ ＭＤＴ ｉｎ Ｃｏｎｎｅｃｔｅｄを開始する。その後、処理がステップＳ２３２に進む。

ステップＳ２３２において、制御部２６０は、無線状態及びＱｏＳパラメータの測定を行う。その後、処理がステップＳ２３３に進む。

ステップＳ２３３において、制御部２６０は、測定したＱｏＳパラメータが、実行中のアプリケーションに対応するＱＣＩ要求閾値を満たすか否かを確認する。ＱＣＩ要求閾値を満たす場合（ステップＳ２３３；ＹＥＳ）、処理がステップＳ２３５に進む。ＱＣＩ要求閾値を満たさない場合（ステップＳ２３３；ＮＯ）、処理がステップＳ２３４に進む。

ステップＳ２３４において、制御部２６０は、ＱＣＩ要求閾値を満たしていない旨のＱｏＳ報告情報を作成して、記憶部２５０に記憶させる。例えば、ＱＣＩ要求閾値を満たさなかったＱＣＩ種別（１〜９の何れか）を示す情報、及び／又は、ＱＣＩ要求閾値を満たさなかったＱｏＳパラメータ（パケット伝送遅延、パケットロス率）を示す情報をＱｏＳ報告情報として作成する。また、制御部２６０は、測定構成情報に含まれるネットワーク絶対時間と、測定構成時からの経過時間（相対時間）とからなる時間情報を作成する。そして、無線状態情報、位置情報、時間情報、及びＱｏＳ報告情報を含む測定データを記憶部２５０に記録する。その後、処理がステップＳ２３５に進む。

ステップＳ２３５において、制御部２６０は、報告の契機（トリガ）が発生したか否かを確認する。報告の契機（トリガ）については、通常のＬｏｇｇｅｄ ＭＤＴと同様としてもよい。報告の契機が発生した場合（ステップＳ２３５；ＹＥＳ）、処理がステップＳ２３６に進む。報告の契機が発生しない場合（ステップＳ２３５；ＮＯ）、処理がステップＳ２３７に進む。

ステップＳ２３６において、制御部２６０は、記憶部２５０に保持されている全ての測定データを含む報告をネットワークに送信するよう無線通信部２１０を制御する。これにより、Ｌｏｇｇｅｄ ＭＤＴ ｉｎ Ｃｏｎｎｅｃｔｅｄ処理が終了する。

一方、ステップＳ２３７において、制御部２６０は、測定データの継続時間が満了したか否かを確認する。測定データの継続時間が満了した場合（ステップＳ２３７；ＹＥＳ）、処理がステップＳ２３８に進む。測定データの継続時間が満了していない場合（ステップＳ２３７；ＮＯ）、処理がステップＳ２３２に戻る。

ステップＳ２３８において、制御部２６０は、記憶部２５０に保持されている全ての測定データを削除する。この場合もＬｏｇｇｅｄ ＭＤＴ ｉｎ Ｃｏｎｎｅｃｔｅｄ処理が終了する。

このように、ＱＣＩ要求閾値を満たさなかったことをトリガとする場合には、トリガ発生時には、無線状態も劣化し、報告を行うことが困難である可能性がある。よって、ＱＣＩ要求閾値を満たさなかったことをトリガとする場合には、Ｉｍｍｅｄｉａｔｅ ＭＤＴ方式よりもＬｏｇｇｅｄ ＭＤＴ ｉｎ Ｃｏｎｎｅｃｔｅｄ方式を適用することで、より確実に報告を行うことができる。

（実施形態のまとめ）
以上説明したように、本実施形態によれば、ＭＤＴにおいて、ＵＥ２００が測定したＱｏＳパラメータに関するＱｏＳ報告情報をネットワークが収集できるため、移動通信システム１のキャパシティ最適化に寄与できる。例えば、無線状態は良好であるにもかかわらずキャパシティの少ない低キャパシティ地帯を特定可能になる。

［その他の実施形態］
上記のように、本発明は実施形態によって記載したが、この開示の一部をなす論述及び図面はこの発明を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施形態、実施例及び運用技術が明らかとなる。

例えば、上述した各実施形態では、ＬＴＥに基づいて構成される移動通信システムを例に説明したが、ＬＴＥに限らず、ＭＤＴをサポートする他の移動通信システム（例えば、Ｗ−ＣＤＭＡ）に対して本発明を適用してもよい。

上述した実施形態では、Ｉｍｍｅｄｉａｔｅ ＭＤＴにおいてＵＥ２００がＱｏＳパラメータを測定する一例を説明したが、ＵＥ２００がＱｏＳパラメータを測定するのではなく、ｅＮＢ１００がＱｏＳパラメータを測定してもよい。

また、ＱＣＩに係るＱｏＳパラメータ（パケット伝送遅延、パケットロス率）についてＱｏＳ測定を行なっていたが、他のＱｏＳパラメータ（ジッタなど）についてＱｏＳ測定を行ってもよい。

上述した実施形態では、ＱｏＳパラメータとはアプリケーションレベルで測定可能なパラメータであると説明したが、アプリケーションレイヤに限らず、物理レイヤ（レイヤ１）よりも上位のレイヤであればよい。例えば、ＱｏＳパラメータとはレイヤ２で測定可能なパラメータであってもよい。

このように本発明は、ここでは記載していない様々な実施形態等を包含するということを理解すべきである。

なお、米国仮出願第６１／５４１７１８号（２０１１年９月３０日出願）の全内容が、参照により、本願明細書に組み込まれている。

以上のように、本発明に係る移動通信方法、ユーザ端末、及びプロセッサによれば、移動通信システムのキャパシティ最適化に寄与できるため、移動体通信などの無線通信において有用である。

Claims (6)

1. ＭＤＴ（Ｍｉｎｉｍｉｚａｔｉｏｎ ｏｆ Ｄｒｉｖｅ Ｔｅｓｔｓ）をサポートする移動通信システムにおける移動通信方法であって、
   ユーザ端末と、前記ユーザ端末との通信を行うネットワークと、の間の通信におけるＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）パラメータを測定するＭＤＴを、Ｉｍｍｅｄｉａｔｅ ＭＤＴ方式で行うステップを有し、
   前記ＱｏＳパラメータは、パケットの伝送遅延及びパケットのロス率の少なくとも一方を含み、
   前記ステップにおいて、前記ユーザ端末は、前記ネットワークから指定された特定のベアラに対して前記ＱｏＳパラメータを測定することを特徴とする移動通信方法。
2. 前記ステップは、前記ユーザ端末の位置情報を含む報告を、前記ユーザ端末から前記ネットワークに送信する報告ステップを含むことを特徴とする請求項１に記載の移動通信方法。
3. 前記報告ステップは、定期的に前記報告を前記ネットワークに送信するステップを含むことを特徴とする請求項２に記載の移動通信方法。
4. 前記ステップは、前記ＱｏＳパラメータをＱＣＩ（ＱｏＳ Ｃｌａｓｓ Ｉｄｅｎｔｉｆｉｅｒ）毎に測定する測定ステップを含むことを特徴とする請求項１に記載の移動通信方法。
5. ＭＤＴ（Ｍｉｎｉｍｉｚａｔｉｏｎ ｏｆ Ｄｒｉｖｅ Ｔｅｓｔｓ）をサポートするユーザ端末であって、
   該ユーザ端末と、該ユーザ端末との通信を行うネットワークと、の間の通信におけるＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）パラメータを測定するＭＤＴを、Ｉｍｍｅｄｉａｔｅ ＭＤＴ方式で行う制御部を有し、
   前記ＱｏＳパラメータは、パケットの伝送遅延及びパケットのロス率の少なくとも一方を含み、
   前記制御部は、前記ネットワークから指定された特定のベアラに対して前記ＱｏＳパラメータを測定することを特徴とするユーザ端末。
6. ＭＤＴ（Ｍｉｎｉｍｉｚａｔｉｏｎ ｏｆ Ｄｒｉｖｅ Ｔｅｓｔｓ）をサポートするユーザ端末に備えられるプロセッサであって、
   該ユーザ端末と、該ユーザ端末との通信を行うネットワークと、の間の通信におけるＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）パラメータを測定するＭＤＴを、Ｉｍｍｅｄｉａｔｅ ＭＤＴ方式で行う処理を行い、
   前記ＱｏＳパラメータは、パケットの伝送遅延及びパケットのロス率の少なくとも一方を含み、
   前記処理は、前記ネットワークから指定された特定のベアラに対して前記ＱｏＳパラメータを測定する処理を含むことを特徴とするプロセッサ。

Images