(57)【要約】  一実施形態に係る無線端末は、基地局の補助又は制御に基づいてコーデックアダプテーションを行う制御部を備える。前記制御部は、下りリンクの無線品質パラメータを測定し、前記基地局との接続を確立するプロシージャにおいて、前記無線品質パラメータを含む所定メッセージを前記基地局に送信する。
2017170159.tif 000002
【特許請求の範囲】
【請求項１】
基地局の補助又は制御に基づいてコーデックアダプテーションを行う制御部を備え、
前記制御部は、下りリンクの無線品質パラメータを測定し、
前記制御部は、前記基地局との接続を確立するプロシージャにおいて、前記無線品質パラメータを含む所定メッセージを前記基地局に送信する
無線端末。
【請求項２】
前記所定メッセージは、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｓｅｔｕｐ  Ｃｏｍｐｌｅｔｅメッセージである
請求項１に記載の無線端末。
【請求項３】
前記制御部は、第１測定設定情報又は第２測定設定情報に従って前記無線品質パラメータを測定し、
前記第１測定設定情報は、前記基地局からブロードキャストで設定される設定情報であり、
前記第２測定設定情報は、前記無線端末に事前設定された設定情報である
請求項１に記載の無線端末。
【請求項４】
前記制御部は、ＲＲＣ層エンティティ及び物理層エンティティを含み、
前記ＲＲＣ層エンティティは、前記接続を確立することに応じて、前記無線品質パラメータを測定させるための情報を前記物理層エンティティに通知し、
前記ＲＲＣ層エンティティは、前記所定メッセージの送信前に、前記無線品質パラメータを前記物理層エンティティから取得する
請求項１に記載の無線端末。
【請求項５】
前記ＲＲＣ層エンティティは、フィルタリング設定情報に基づいて前記無線品質パラメータのフィルタリングを行い、
前記フィルタリング設定情報は、前記基地局からブロードキャストで設定される設定情報である
請求項４に記載の無線端末。
【請求項６】
前記制御部は、前記プロシージャの前、又は前記プロシージャ中に、前記基地局が前記コーデックアダプテーションを補助又は制御する機能を有することを示すインディケーションを前記基地局から受信し、
前記制御部は、前記インディケーションの受信に応じて、前記ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｓｅｔｕｐ  Ｃｏｍｐｌｅｔｅメッセージに前記無線品質パラメータを含めることを決定する
請求項２に記載の無線端末。
【請求項７】
前記制御部は、前記プロシージャ中にＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｓｅｔｕｐメッセージを前記基地局から受信し、
前記ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｓｅｔｕｐメッセージは、前記インディケーションを含む
請求項６に記載の無線端末。
【請求項８】
前記制御部は、前記ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｓｅｔｕｐ  Ｃｏｍｐｌｅｔｅメッセージの送信後に、最小保証ビットレートを示す情報を前記基地局から受信し、受信した情報を用いて前記コーデックアダプテーションを行う
請求項２に記載の無線端末。
【請求項９】
前記制御部は、前記ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｓｅｔｕｐ  Ｃｏｍｐｌｅｔｅメッセージの送信後に、コーデックモード及び／又はコーデックレートを示す情報を前記基地局から受信し、受信した情報を用いて前記コーデックアダプテーションを行う
請求項２に記載の無線端末。
【請求項１０】
無線端末のコーデックアダプテーションを補助又は制御する制御部を備え、
前記制御部は、前記無線端末との接続を確立するプロシージャにおいて、下りリンクの無線品質パラメータを含む所定メッセージを前記無線端末から受信し、
前記制御部は、前記無線品質パラメータに基づいて、最小保証ビットレートを示す情報、又は、コーデックモード及び／又はコーデックレートを示す情報を前記無線端末に送信する
基地局。
【請求項１１】
基地局の補助又は制御に基づいてコーデックアダプテーションを行う制御部を備え、
前記制御部は、前記基地局との接続を確立するプロシージャにおいて所定メッセージを前記基地局に送信し、
前記所定メッセージは、前記コーデックアダプテーションに関するネゴシエーションを前記基地局に実行させるための情報を含み、
前記ネゴシエーションは、前記基地局と前記無線端末の通信相手との間で実行される
無線端末。
【請求項１２】
前記所定メッセージは、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔメッセージである
請求項１１に記載の無線端末。
【請求項１３】
無線端末のコーデックアダプテーションを補助又は制御する制御部を備え、
前記制御部は、前記無線端末との接続を確立するプロシージャにおいて所定メッセージを前記無線端末から受信し、
前記所定メッセージは、前記コーデックアダプテーションに関するネゴシエーションを自基地局に実行させるための情報を含み、
前記制御部は、前記情報の受信に応じて前記無線端末の通信相手と前記ネゴシエーションを行う
基地局。
【請求項１４】
基地局の補助又は制御に基づいてコーデックアダプテーションを行う制御部を備え、
前記制御部は、自無線端末のコーデックモード及び／又はコーデックレートを示すコーデック情報を前記基地局に送信し、
前記制御部は、前記コーデックモード及び／又は前記コーデックレートの変更、又は前記基地局からの問い合わせに応じて、前記コーデック情報を送信する
無線端末。
【請求項１５】
前記制御部は、前記基地局からＩＰパケットを受信し、
前記ＩＰパケットは、前記基地局が輻輳していないことを示す非輻輳情報を含み、
前記制御部は、前記非輻輳情報の受信に応じて前記コーデックレートを上昇させるよう前記コーデックアダプテーションを行う
請求項１４に記載の無線端末。
【請求項１６】
前記制御部は、前記コーデックモード及び／又は前記コーデックレートの変更を指示するＡＳ層シグナリングを前記基地局から受信し、
前記制御部は、前記ＡＳ層シグナリングの受信に応じて前記コーデックアダプテーションを行う
請求項１４に記載の無線端末。
【請求項１７】
無線端末のコーデックアダプテーションを補助又は制御する制御部を備え、
前記制御部は、前記無線端末のコーデックモード及び／又はコーデックレートを示すコーデック情報を前記無線端末から受信し、
前記制御部は、前記コーデック情報に基づいて前記コーデックアダプテーションを補助又は制御する
基地局。
【請求項１８】
基地局の補助又は制御に基づいてコーデックアダプテーションを行う制御部を備え、
前記制御部は、前記コーデックアダプテーションを実行させるためのトリガ情報をＡＳ層シグナリングにより前記基地局から受信し、
前記制御部は、前記トリガ情報の受信に応じて前記コーデックアダプテーションを行う
無線端末。
【請求項１９】
前記トリガ情報は、前記トリガ情報の更新を判断するためのタグ情報を含み、
前記制御部は、前記タグ情報に基づいて前記更新を検知したことに応じて、前記トリガ情報を適用する
請求項１８に記載の無線端末。
【請求項２０】
前記トリガ情報は、前記トリガ情報の適用を禁止する期間を定めるタイマ情報を含み、
前記制御部は、前記タイマ情報に基づいて前記期間の満了を検知したことに応じて、前記トリガ情報を適用する
請求項１８に記載の無線端末。
【請求項２１】
前記トリガ情報は、前記無線端末と前記基地局との間の無線通信の品質を示す無線品質パラメータの閾値を含み、
前記制御部は、
前記無線品質パラメータを測定し、
測定した無線品質パラメータが前記閾値を満たしたことに応じて、前記コーデックアダプテーションを行う
請求項１８に記載の無線端末。
【請求項２２】
前記制御部は、前記測定した無線品質パラメータが前記閾値を満たしたことに応じて、上りリンクバッファのデータ量を示すバッファステータス報告を前記基地局に送信する
請求項２１に記載の無線端末。
【請求項２３】
無線端末のコーデックアダプテーションを補助又は制御する制御部を備え、
前記制御部は、前記コーデックアダプテーションを実行させるためのトリガ情報をＡＳ層シグナリングにより前記無線端末に送信する
基地局。
【請求項２４】
基地局の補助又は制御に基づいてコーデックアダプテーションを行う制御部を備え、
前記制御部は、
前記コーデックアダプテーションのためのＡＳ層シグナリングを前記基地局から受信するＡＳ層エンティティと、
前記ＡＳ層エンティティよりも上位層に位置付けられ、前記コーデックアダプテーションを行う上位層エンティティと、を含み、
前記ＡＳ層エンティティは、前記ＡＳ層シグナリングに基づいて前記コーデックアダプテーションの必要性を判断し、前記必要性を示す通知を前記上位層エンティティに提供する
無線端末。
【請求項２５】
前記通知は、コーデックパラメータに関する情報を含み、
前記コーデックパラメータは、コーデックモード、コーデックレート、及び無線ビットレートのうち少なくとも１つを含む
請求項２４に記載の無線端末。
【請求項２６】
基地局の補助又は制御下でコーデックアダプテーションを行う制御部を備え、
前記制御部は、自無線端末で適用するコーデックモード及びコーデックレートのうち、一方を第１の選択方法により選択し、かつ、他方を第２の選択方法により選択し、
前記第１の選択方法は、前記基地局の補助又は制御と無関係な選択方法であり、
前記第２の選択方法は、前記基地局の補助又は制御に従った選択方法である
無線端末。
【請求項２７】
前記制御部は、
前記第１の選択方法により前記コーデックモードを選択し、
前記コーデックモードを選択した後、前記第２の選択方法により前記コーデックレートを選択する
請求項２６に記載の無線端末。
【請求項２８】
前記制御部は、
前記第２の選択方法により前記コーデックモードを選択し、
前記コーデックモードを選択した後、前記第１の選択方法により前記コーデックレートを選択する
請求項２６に記載の無線端末。
【請求項２９】
前記制御部は、前記第２の選択方法において、
前記基地局の負荷レベルを示す負荷情報を前記基地局から受信し、
前記負荷情報に基づいて前記コーデックモード又は前記コーデックレートを選択する
請求項２６に記載の無線端末。
【請求項３０】
コーデックアダプテーションに関するコマンドを基地局から受信し、前記コマンドに基づいて前記コーデックアダプテーションを行う制御部を備え、
前記制御部は、
前記コマンドを適用可能か否か判断し、
前記コマンドを適用不可と判断したことに応じて前記コマンドを無効化する
無線端末。
【請求項３１】
前記制御部は、前記コマンドを無効化することに応じて、前記コマンドを無効化することに関する通知を前記基地局に送信する
請求項３０に記載の無線端末。
【請求項３２】
前記通知は、前記無線端末が希望するコーデックパラメータを含み、
前記コーデックパラメータは、コーデックモード、コーデックレート、及び無線ビットレートのうち少なくとも１つを含む
請求項３１に記載の無線端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、移動通信システムにおいて用いられる無線端末及び基地局に関する。
【背景技術】
【０００２】
移動通信システムにおいて、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）パケットを用いた音声通信技術が実用化されている。無線端末は、ＲＡＮ（Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）を介して、音声データを含むＩＰパケットを通信相手と送受信する。ＲＡＮは、基地局を含む。無線端末の通信相手は、他の無線端末又はサーバ等である。【０００３】
無線端末は、音声データの符号化及び復号を行うコーデックを備える。コーデックは、映像データの符号化及び復号に用いられてもよい。無線端末は、通信相手とのネゴシエーションによりコーデックアダプテーションを行う。ネゴシエーションは、例えばＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）を用いて行われる。【０００４】
コーデックアダプテーションとは、コーデックモード及び／又はコーデックレートを適応化する技術である。コーデックモードは、例えば、ＡＭＲ（Ａｄａｐｔｉｖｅ  Ｍｕｌｔｉ−Ｒａｔｅ）、ＥＶＳ（Ｅｎｈａｎｃｅｄ  Ｖｏｉｃｅ  Ｓｅｒｖｉｃｅｓ）等である。コーデックレートは、符号化レート又はビットレートと称されることがある。【０００５】
このようなコーデックアダプテーションにＲＡＮ（基地局）が積極的に関与することにより、音声／映像品質を改善することができると考えられる。
【発明の概要】
【０００６】
一実施形態に係る無線端末は、基地局の補助又は制御に基づいてコーデックアダプテーションを行う制御部を備える。前記制御部は、下りリンクの無線品質パラメータを測定し、前記基地局との接続を確立するプロシージャにおいて、前記無線品質パラメータを含む所定メッセージを前記基地局に送信する。
【０００７】
一実施形態に係る基地局は、無線端末のコーデックアダプテーションを補助又は制御する制御部を備える。前記制御部は、前記無線端末との接続を確立するプロシージャにおいて、下りリンクの無線品質パラメータを含む所定メッセージを前記無線端末から受信する。前記制御部は、前記無線品質パラメータに基づいて、最小保証ビットレートを示す情報、又は、コーデックモード及び／又はコーデックレートを示す情報を前記無線端末に送信する。
【０００８】
一実施形態に係る無線端末は、基地局の補助又は制御に基づいてコーデックアダプテーションを行う制御部を備える。前記制御部は、前記基地局との接続を確立するプロシージャにおいて所定メッセージを前記基地局に送信する。前記所定メッセージは、前記コーデックアダプテーションに関するネゴシエーションを前記基地局に実行させるための情報を含む。前記ネゴシエーションは、前記基地局と前記無線端末の通信相手との間で実行される。
【０００９】
一実施形態に係る基地局は、無線端末のコーデックアダプテーションを補助又は制御する制御部を備える。前記制御部は、前記無線端末との接続を確立するプロシージャにおいて所定メッセージを前記無線端末から受信する。前記所定メッセージは、前記コーデックアダプテーションに関するネゴシエーションを自基地局に実行させるための情報を含む。前記制御部は、前記情報の受信に応じて前記無線端末の通信相手と前記ネゴシエーションを行う。
【００１０】
一実施形態に係る無線端末は、基地局の補助又は制御に基づいてコーデックアダプテーションを行う制御部を備える。前記制御部は、自無線端末のコーデックモード及び／又はコーデックレートを示すコーデック情報を前記基地局に送信する。前記制御部は、前記コーデックモード及び／又は前記コーデックレートの変更、又は前記基地局からの問い合わせに応じて、前記コーデック情報を送信する。
【００１１】
一実施形態に係る基地局は、無線端末のコーデックアダプテーションを補助又は制御する制御部を備える。前記制御部は、前記無線端末のコーデックモード及び／又はコーデックレートを示すコーデック情報を前記無線端末から受信する。前記制御部は、前記コーデック情報に基づいて前記コーデックアダプテーションを補助又は制御する。
【００１２】
一実施形態に係る無線端末は、基地局の補助又は制御に基づいてコーデックアダプテーションを行う制御部を備える。前記制御部は、前記コーデックアダプテーションを実行させるためのトリガ情報をＡＳ層シグナリングにより前記基地局から受信する。前記制御部は、前記トリガ情報の受信に応じて前記コーデックアダプテーションを行う。
【００１３】
一実施形態に係る基地局は、無線端末のコーデックアダプテーションを補助又は制御する制御部を備える。前記制御部は、前記コーデックアダプテーションを実行させるためのトリガ情報をＡＳ層シグナリングにより前記無線端末に送信する。
【００１４】
一実施形態に係る無線端末は、基地局の補助又は制御に基づいてコーデックアダプテーションを行う制御部を備える。前記制御部は、前記コーデックアダプテーションのためのＡＳ層シグナリングを前記基地局から受信するＡＳ層エンティティと、前記ＡＳ層エンティティよりも上位層に位置付けられ、前記コーデックアダプテーションを行う上位層エンティティと、を含む。前記ＡＳ層エンティティは、前記ＡＳ層シグナリングに基づいて前記コーデックアダプテーションの必要性を判断し、前記必要性を示す通知を前記上位層エンティティに提供する。
【００１５】
一実施形態に係る無線端末は、基地局の補助又は制御下でコーデックアダプテーションを行う制御部を備える。前記制御部は、自無線端末で適用するコーデックモード及びコーデックレートのうち、一方を第１の選択方法により選択し、かつ、他方を第２の選択方法により選択する。前記第１の選択方法は、前記基地局の補助又は制御と無関係な選択方法である。前記第２の選択方法は、前記基地局の補助又は制御に従った選択方法である。
【００１６】
一実施形態に係る無線端末は、コーデックアダプテーションに関するコマンドを基地局から受信し、前記コマンドに基づいて前記コーデックアダプテーションを行う制御部を備える。前記制御部は、前記コマンドを適用可能か否か判断し、前記コマンドを適用不可と判断したことに応じて前記コマンドを無効化する。
【図面の簡単な説明】
【００１７】
【図１】ＬＴＥシステムの構成を示す図である。
【図２】ＵＥ（無線端末）の構成を示す図である。
【図３】ｅＮＢ（基地局）の構成を示す図である。
【図４】ＬＴＥシステムにおける無線インターフェイスのプロトコルスタックの構成を示す図である。
【図５】ＬＴＥシステムにおいて用いられる無線フレームの構成を示す図である。
【図６】第１実施形態に係る動作シーケンス例を示す図である。
【図７】第１実施形態の変更例に係る動作シーケンス例を示す図である。
【図８】第２実施形態に係る動作シーケンス例を示す図である。
【図９】第２実施形態の変更例を示す図である。
【図１０】第３実施形態の変更例を示す図である。
【図１１】第４実施形態の動作パターン１を示す図である。
【図１２】第４実施形態の動作パターン２を示す図である。
【図１３】第５実施形態に係る動作シーケンス例を示す図である。
【発明を実施するための形態】
【００１８】
（移動通信システムの構成）
以下において、実施形態に係る移動通信システムの構成について説明する。図１は、実施形態に係る移動通信システムであるＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）システムの構成を示す図である。ＬＴＥシステムは、３ＧＰＰ（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）規格に基づく移動通信システムである。
【００１９】
図１に示すように、ＬＴＥシステムは、ＵＥ（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）１００、Ｅ−ＵＴＲＡＮ（Ｅｖｏｌｖｅｄ−ＵＭＴＳ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）１０、及びＥＰＣ（Ｅｖｏｌｖｅｄ  Ｐａｃｋｅｔ  Ｃｏｒｅ）２０を備える。
【００２０】
ＵＥ１００は、無線端末に相当する。ＵＥ１００は、移動型の通信装置であり、セル（サービングセル）との無線通信を行う。
【００２１】
Ｅ−ＵＴＲＡＮ１０は、無線アクセスネットワークに相当する。Ｅ−ＵＴＲＡＮ１０は、ｅＮＢ２００（ｅｖｏｌｖｅｄ  Ｎｏｄｅ−Ｂ）を含む。ｅＮＢ２００は、基地局に相当する。ｅＮＢ２００は、Ｘ２インターフェイスを介して相互に接続される。
【００２２】
ｅＮＢ２００は、１又は複数のセルを管理しており、自セルとの接続を確立したＵＥ１００との無線通信を行う。ｅＮＢ２００は、無線リソース管理（ＲＲＭ）機能、ユーザデータ（以下、単に「データ」という）のルーティング機能、モビリティ制御・スケジューリングのための測定制御機能等を有する。「セル」は、無線通信エリアの最小単位を示す用語として用いられる他に、ＵＥ１００との無線通信を行う機能を示す用語としても用いられる。
【００２３】
ＥＰＣ２０は、コアネットワークに相当する。ＥＰＣ２０は、ＭＭＥ（Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ）／Ｓ−ＧＷ（Ｓｅｒｖｉｎｇ−Ｇａｔｅｗａｙ）３００を含む。ＭＭＥは、ＵＥ１００に対する各種モビリティ制御等を行う。Ｓ−ＧＷは、データの転送制御を行う。ＭＭＥ／Ｓ−ＧＷ３００は、Ｓ１インターフェイスを介してｅＮＢ２００と接続される。
【００２４】
図２は、ＵＥ１００（無線端末）の構成を示す図である。図２に示すように、ＵＥ１００は、受信部１１０、送信部１２０、及び制御部１３０を備える。
【００２５】
受信部１１０は、制御部１３０の制御下で各種の受信を行う。受信部１１０は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換して制御部１３０に出力する。
【００２６】
送信部１２０は、制御部１３０の制御下で各種の送信を行う。送信部１２０は、アンテナ及び送信機を含む。送信機は、制御部１３０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。
【００２７】
制御部１３０は、ＵＥ１００における各種の制御を行う。制御部１３０は、プロセッサ及びメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行うベースバンドプロセッサと、メモリに記憶されるプログラムを実行して各種の処理を行うＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）と、を含む。プロセッサは、音声・映像データの符号化・復号を行うコーデックをさらに含む。プロセッサは、後述する処理を実行する。
【００２８】
図３は、ｅＮＢ２００（基地局）の構成を示す図である。図３に示すように、ｅＮＢ２００は、送信部２１０、受信部２２０、制御部２３０、及びバックホール通信部２４０を備える。
【００２９】
送信部２１０は、制御部２３０の制御下で各種の送信を行う。送信部２１０は、アンテナ及び送信機を含む。送信機は、制御部２３０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。
【００３０】
受信部２２０は、制御部２３０の制御下で各種の受信を行う。受信部２２０は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換して制御部２３０に出力する。
【００３１】
制御部２３０は、ｅＮＢ２００における各種の制御を行う。制御部２３０は、プロセッサ及びメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行うベースバンドプロセッサと、メモリに記憶されるプログラムを実行して各種の処理を行うＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）と、を含む。プロセッサは、後述する処理を実行する。
【００３２】
バックホール通信部２４０は、Ｘ２インターフェイスを介して隣接ｅＮＢ２００と接続され、Ｓ１インターフェイスを介してＭＭＥ／Ｓ−ＧＷ３００と接続される。バックホール通信部２４０は、Ｘ２インターフェイス上で行う通信及びＳ１インターフェイス上で行う通信等に用いられる。
【００３３】
図４は、ＬＴＥシステムにおける無線インターフェイスのプロトコルスタックの構成を示す図である。図４に示すように、無線インターフェイスプロトコルは、ＯＳＩ参照モデルの第１層乃至第３層に区分されており、第１層は物理（ＰＨＹ）層である。第２層は、ＭＡＣ（Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）層、ＲＬＣ（Ｒａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ）層、及びＰＤＣＰ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｃｏｎｖｅｒｇｅｎｃｅ  Ｐｒｏｔｏｃｏｌ）層を含む。第３層は、ＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）層を含む。
【００３４】
物理層、ＭＡＣ層、ＲＬＣ層、ＰＤＣＰ層、ＲＲＣ層は、ＡＳ（Ａｃｃｅｓｓ  Ｓｔｒａｔｕｍ）層エンティティ１００ａを構成する。上位層エンティティ１００ｂは、ＡＳ層エンティティ１００ａよりも上位層に位置付けられる。上位層エンティティ１００ｂは、ＮＡＳ（Ｎｏｎ−Ａｃｃｅｓｓ  Ｓｔｒａｔｕｍ）層を含む。上位層エンティティ１００ｂは、アプリケーション層等をさらに含んでもよい。上位層エンティティ１００ｂは、後述するコーデックアダプテーションを実行する。
【００３５】
物理層は、符号化・復号、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行う。ＵＥ１００の物理層とｅＮＢ２００の物理層との間では、物理チャネルを介してデータ及び制御情報が伝送される。
【００３６】
ＭＡＣ層は、データの優先制御、ハイブリッドＡＲＱ（ＨＡＲＱ）による再送処理、及びランダムアクセスプロシージャ等を行う。ＵＥ１００のＭＡＣ層とｅＮＢ２００のＭＡＣ層との間では、トランスポートチャネルを介してデータ及び制御情報が伝送される。ｅＮＢ２００のＭＡＣ層は、上下リンクのトランスポートフォーマット（トランスポートブロックサイズ、変調・符号化方式（ＭＣＳ））及びＵＥ１００への割当リソースブロックを決定するスケジューラを含む。
【００３７】
ＲＬＣ層は、ＭＡＣ層及び物理層の機能を利用してデータを受信側のＲＬＣ層に伝送する。ＵＥ１００のＲＬＣ層とｅＮＢ２００のＲＬＣ層との間では、論理チャネルを介してデータ及び制御情報が伝送される。
【００３８】
ＰＤＣＰ層は、ヘッダ圧縮・伸張、及び暗号化・復号化を行う。
【００３９】
ＲＲＣ層は、制御情報を取り扱う制御プレーンでのみ定義される。ＵＥ１００のＲＲＣ層とｅＮＢ２００のＲＲＣ層との間では、各種設定のためのメッセージ（ＲＲＣメッセージ）が伝送される。ＲＲＣ層は、無線ベアラの確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。ＵＥ１００のＲＲＣとｅＮＢ２００のＲＲＣとの間に接続（ＲＲＣ接続）がある場合、ＵＥ１００はＲＲＣコネクティッドモードであり、そうでない場合、ＵＥ１００はＲＲＣアイドルモードである。
【００４０】
ＲＲＣ層の上位に位置するＮＡＳ（Ｎｏｎ−Ａｃｃｅｓｓ  Ｓｔｒａｔｕｍ）層は、セッション管理及びモビリティ管理等を行う。
【００４１】
図５は、ＬＴＥシステムにおいて用いられる無線フレームの構成を示す図である。ＬＴＥシステムは、下りリンクにはＯＦＤＭＡ（Ｏｒｔｈｏｇｏｎａｌ  Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ）、上りリンクにはＳＣ−ＦＤＭＡ（Ｓｉｎｇｌｅ  Ｃａｒｒｉｅｒ  Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ）がそれぞれ適用される。
【００４２】
図５に示すように、無線フレームは、時間方向に並ぶ１０個のサブフレームで構成される。各サブフレームは、時間方向に並ぶ２個のスロットで構成される。各サブフレームの長さは１ｍｓであり、各スロットの長さは０．５ｍｓである。各サブフレームは、周波数方向に複数個のリソースブロック（ＲＢ）を含み、時間方向に複数個のシンボルを含む。各リソースブロックは、周波数方向に複数個のサブキャリアを含む。１つのシンボル及び１つのサブキャリアにより１つのリソースエレメント（ＲＥ）が構成される。また、ＵＥ１００に割り当てられる無線リソース（時間・周波数リソース）のうち、周波数リソースはリソースブロックにより特定でき、時間リソースはサブフレーム（又はスロット）により特定できる。
【００４３】
下りリンクにおいて、各サブフレームの先頭数シンボルの区間は、主に下りリンク制御情報を伝送するための物理下りリンク制御チャネル（ＰＤＣＣＨ）として用いられる領域である。また、各サブフレームの残りの部分は、主に下りリンクデータを伝送するための物理下りリンク共有チャネル（ＰＤＳＣＨ）として用いることができる領域である。
【００４４】
ｅＮＢ２００は、基本的には、ＰＤＣＣＨを用いて下りリンク制御情報（ＤＣＩ）をＵＥ１００に送信し、ＰＤＳＣＨを用いて下りリンクデータをＵＥ１００に送信する。ＰＤＣＣＨが搬送する下りリンク制御情報は、上りリンクスケジューリング情報、下りリンクスケジューリング情報、ＴＰＣコマンドを含む。上りリンクスケジューリング情報は上りリンク無線リソースの割当てに関するスケジューリング情報（ＵＬ  ｇｒａｎｔ）であり、下りリンクスケジューリング情報は、下りリンク無線リソースの割当てに関するスケジューリング情報である。ＴＰＣコマンドは、上りリンクの送信電力の増減を指示する情報である。ｅＮＢ２００は、下りリンク制御情報の送信先のＵＥ１００を識別するために、送信先のＵＥ１００の識別子（ＲＮＴＩ：Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｔｅｍｐｏｒａｒｙ  ＩＤ）でスクランブリングしたＣＲＣビットを下りリンク制御情報に含める。各ＵＥ１００は、自ＵＥ宛ての可能性がある下りリンク制御情報について、自ＵＥのＲＮＴＩでデスクランブリング後、ＣＲＣチェックをすることにより、ＰＤＣＣＨをブラインド復号（Ｂｌｉｎｄ  ｄｅｃｏｄｉｎｇ）し、自ＵＥ宛の下りリンク制御情報を検出する。ＰＤＳＣＨは、下りリンクスケジューリング情報が示す下りリンク無線リソース（リソースブロック）により下りリンクデータを搬送する。
【００４５】
上りリンクにおいて、各サブフレームにおける周波数方向の両端部は、主に上りリンク制御情報を伝送するための物理上りリンク制御チャネル（ＰＵＣＣＨ）として用いられる領域である。各サブフレームにおける残りの部分は、主に上りリンクデータを伝送するための物理上りリンク共有チャネル（ＰＵＳＣＨ）として用いることができる領域である。
【００４６】
ＵＥ１００は、基本的には、ＰＵＣＣＨを用いて上りリンク制御情報（ＵＣＩ）をｅＮＢ２００に送信し、ＰＵＳＣＨを用いて上りリンクデータをｅＮＢ２００に送信する。ＰＵＣＣＨが運搬する上りリンク制御情報は、ＣＱＩ（Ｃｈａｎｎｅｌ  Ｑｕａｌｉｔｙ  Ｉｎｄｉｃａｔｏｒ）、ＰＭＩ（Ｐｒｅｃｏｄｉｎｇ  Ｍａｔｒｉｘ  Ｉｎｄｉｃａｔｏｒ）、ＲＩ（Ｒａｎｋ  Ｉｎｄｉｃａｔｏｒ）、スケジューリング要求（ＳＲ）、ＨＡＲＱ  ＡＣＫ／ＮＡＣＫを含む。ＣＱＩは、下りリンクのチャネル品質を示すインデックスであり、下りリンク伝送に用いるべきＭＣＳの決定等に用いられる。ＰＭＩは、下りリンクの伝送のために用いることが望ましいプレコーダマトリックスを示すインデックスである。ＲＩは、下りリンクの伝送に用いることが可能なレイヤ数（ストリーム数）を示すインデックスである。ＳＲは、ＰＵＳＣＨリソースの割り当てを要求する情報である。ＨＡＲＱ  ＡＣＫ／ＮＡＣＫは、下りリンクデータを正しく受信したか否かを示す送達確認情報である。
【００４７】
（第１実施形態）
以下において、第１実施形態について説明する。
【００４８】
第１実施形態に係るＵＥ１００は、ｅＮＢ２００の補助又は制御に基づいてコーデックアダプテーションを行う。ｅＮＢ２００の補助に基づくコーデックアダプテーションは、「ｅＮＢ−ａｓｓｉｓｔｅｄ  Ｃｏｄｅｃ  Ａｄａｐｔａｔｉｏｎ」と称されてもよい。ｅＮＢ２００の制御に基づくコーデックアダプテーションは、「ｅＮＢ−ｃｏｎｔｒｏｌｌｅｄ  Ｃｏｄｅｃ  Ａｄａｐｔａｔｉｏｎ」と称されてもよい。「ｅＮＢ−ａｓｓｉｓｔｅｄ  Ｃｏｄｅｃ  Ａｄａｐｔａｔｉｏｎ」は、コーデックモード及び／又はコーデックレートをＵＥ１００が決定し、当該決定のための補助情報をｅＮＢ２００がＵＥ１００に提供する方式である。これに対し、「ｅＮＢ−ｃｏｎｔｒｏｌｌｅｄ  Ｃｏｄｅｃ  Ａｄａｐｔａｔｉｏｎ」は、コーデックモード及び／又はコーデックレートをｅＮＢ２００が決定し、コーデックモード及び／又はコーデックレートをｅＮＢ２００からＵＥ１００に指定する方式である。
【００４９】
第１実施形態においては、ＵＥ１００が、ＩＰパケットを用いた音声通信（ＶｏＬＴＥ：Ｖｏｉｃｅ  ｏｖｅｒ  ＬＴＥ）を行うために、ｅＮＢ２００との接続を確立するシナリオを想定する。
【００５０】
ＵＥ１００が呼を設定する際の初期状態としてＲＲＣコネクティッドモード及びＲＲＣアイドルモードが考えられる。
【００５１】
ＲＲＣコネクティッドモードのＵＥ１００は、例えばＶｏＬＴＥのための追加のベアラ（ＤＲＢ：Ｄａｔａ  Ｒａｄｉｏ  Ｂｅａｒｅｒ）を確立するために呼設定（ｃａｌｌ  ｓｅｔｕｐ）を行う。ｅＮＢ２００は、ＲＲＣコネクティッドモードのＵＥ１００の無線品質パラメータを測定報告及び／又はＣＳＩ（Ｃｈａｎｎｅｌ  Ｓｔａｔｅ  ｉｎｆｏｒｍａｔｉｏｎ）報告により取得可能である。よって、ｅＮＢ２００は、ＵＥ１００の無線品質を考慮して、当該追加のベアラについて適切なコーデックモード及び／又はコーデックレートを決定することができる。
【００５２】
ＲＲＣアイドルモードのＵＥ１００は、呼設定を行うためには、ｅＮＢ２００とのＲＲＣ接続を確立してＲＲＣコネクティッドモードに遷移する必要がある。すなわち、ＵＥ１００は、ランダムアクセスプロシージャを行う必要がある。ｅＮＢ２００は、ＲＲＣアイドルモードのＵＥ１００の無線品質パラメータを取得不能である。このため、ｅＮＢ２００は、ランダムアクセスプロシージャが完了し、ＵＥ１００から測定報告及び／又はＣＳＩ報告を受信した後でなければ、適切なコーデックモード及び／又はコーデックレートを決定することができない問題がある。第１実施形態は、このような問題を解決可能とする実施形態である。
【００５３】
（１）第１実施形態に係る無線端末
第１実施形態において、ＵＥ１００（無線端末）は、下りリンクの無線品質パラメータを測定する。ＵＥ１００は、ｅＮＢ２００との接続を確立するプロシージャ（すなわち、ランダムアクセスプロシージャ）において、無線品質パラメータを含む所定メッセージをｅＮＢ２００に送信する。第１実施形態において、所定メッセージは、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｓｅｔｕｐ  Ｃｏｍｐｌｅｔｅメッセージである。ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｓｅｔｕｐ  Ｃｏｍｐｌｅｔｅメッセージは、「Ｍｓｇ５」と称される。
【００５４】
ランダムアクセスプロシージャにおいてＵＥ１００がｅＮＢ２００に送信するメッセージとして、ランダムアクセスプリアンブル（Ｍｓｇ１）、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔメッセージ（Ｍｓｇ３）、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｓｅｔｕｐ  Ｃｏｍｐｌｅｔｅメッセージ（Ｍｓｇ５）の３つが挙げられる。無線品質パラメータをＭｓｇ１又はＭｓｇ３に含めてもよいが、Ｍｓｇ１又はＭｓｇ３はメッセージサイズが限定されている。よって、無線品質パラメータをＭｓｇ５に含めることが好ましい。
【００５５】
このように、第１実施形態によれば、ｅＮＢ２００がランダムアクセスプロシージャ中にＵＥ１００の無線品質を把握することができる。従って、より早い段階で、ｅＮＢ２００が適切なコーデックモード及び／又はコーデックレートを決定することができる。
【００５６】
なお、ＵＥ１００が測定する無線品質パラメータは、少なくともサービングセルから受信する無線信号の品質を示すパラメータであることが好ましい。無線品質パラメータとしては、ＲＲＣ層の仕様で規定された測定報告又は物理層の仕様で規定されたＣＳＩ報告を用いることができる。無線品質パラメータは、例えば、ＲＳＲＰ（Ｒｅｆｅｒｅｎｃｅ  Ｓｉｇｎａｌ  Ｒｅｃｅｉｖｅｄ  Ｐｏｗｅｒ）、ＲＳＲＱ（Ｒｅｆｅｒｅｎｃｅ  Ｓｉｇｎａｌ  Ｒｅｃｅｉｖｅｄ  Ｑｕａｌｉｔｙ）、ＲＳ−ＳＩＮＲ（Ｒｅｆｅｒｅｎｃｅ  Ｓｉｇｎａｌ−Ｓｉｇｎａｌ−ｔｏ−Ｉｎｔｅｒｆｅｒｅｎｃｅ  ｐｌｕｓ  Ｎｏｉｓｅ  ｐｏｗｅｒ  Ｒａｔｉｏ）、ＣＱＩ（Ｃｈａｎｎｅｌ  Ｑｕａｌｉｔｙ  Ｉｎｄｉｃａｔｏｒ）、ＰＭＩ（Ｐｒｅｃｏｄｉｎｇ  Ｍａｔｒｉｘ  Ｉｎｄｉｃａｔｏｒ）、ＲＩ（Ｒａｎｋ  Ｉｎｄｉｃａｔｏｒ）等である。ＲＳＲＰ、ＲＳＲＱ、及びＲＳ−ＳＩＮＲは、測定報告用の無線品質パラメータである。ＣＱＩ、ＰＭＩ、及びＲＩは、ＣＳＩ報告用の無線品質パラメータである。もしくは、これら報告方法以外にも、新たな無線報告テーブルを用いた報告方法としてもよい。無線報告テーブルは、例えば、Ｍｓｇ１やＭｓｇ３など、メッセージサイズが限定される場合に、報告サイズを減らすように定義されてもよい。この場合、例えばＲＳＲＰ値は解像度を荒くしたり、不規則にマッピングする事が考えられる。具体例として、４値へのマッピングの一例として、０：−９０ｄＢｍ未満、１：−９０ｄＢｍ以上−８５ｄＢｍ未満、２：−８５ｄＢｍ以上−７０ｄＢｍ未満、４：−７０ｄＢｍ以上、などが考えられる。
【００５７】
ｅＮＢ２００は、ＵＥ１００がどのように無線品質パラメータを測定したかを把握できる必要がある。例えば、ＣＱＩにはワイドバンドＣＱＩ及びサブバンドＣＱＩの２つの種類があるため、ｅＮＢ２００は、ＵＥ１００から受信したＣＱＩの種類を識別することが難しい。よって、ＵＥ１００は、第１測定設定情報又は第２測定設定情報に従って無線品質パラメータを測定する。これらの測定設定情報は、ＵＥ１００が測定すべき無線品質パラメータの種類を指定する情報を含んでもよい。
【００５８】
第１測定設定情報は、ｅＮＢ２００からブロードキャストで設定される情報である。例えば、ＳＩＢ（Ｓｙｓｔｅｍ  ｉｎｆｏｒｍａｔｉｏｎ  Ｂｌｏｃｋ）、ＰＤＣＣＨ（ＤＣＩ）若しくはＰＤＳＣＨ（ページングチャネル）、又はＭＣＣＨ（Ｍｕｔｉｃａｓｔ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）を用いたブロードキャストを利用可能である。ＭＣＣＨは、ＳＣ（Ｓｉｎｇｌｅ  Ｃｅｌｌ）−ＭＣＣＨであってもよい。以下において、ブロードキャストの送信にはＳＩＢ、ＰＤＣＣＨ、又は（ＭＣ−）ＭＣＣＨが用いられるものとする。このようなブロードキャスト情報は、ＲＲＣアイドルモードのＵＥ１００が受信可能な情報であり、ＵＥ１００は、ランダムアクセスプロシージャの開始前に第１測定設定情報を取得することができる。なお、第１測定設定情報は、ＵＥ１００が測定すべきセル又は周波数を指定する情報を含んでもよい。
【００５９】
第２測定設定情報は、ＵＥ１００に事前設定された情報である。例えば、第２測定設定情報は、仕様で規定値が指定される。
【００６０】
ＵＥ１００（制御部１３０）は、ＲＲＣ層エンティティ及び物理層エンティティを含む。無線品質パラメータの測定は、物理層エンティティにより行われる。これに対し、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｓｅｔｕｐ  Ｃｏｍｐｌｅｔｅメッセージ（Ｍｓｇ５）はＲＲＣメッセージであり、ＲＲＣ層エンティティにより送信される。このため、物理層とＲＲＣ層との間でやり取りが必要となる。先ず、ＲＲＣ層エンティティは、ｅＮＢ２００と接続を確立することに応じて、無線品質パラメータを測定させるための情報を物理層エンティティに通知する。例えば、ＲＲＣ層エンティティは、呼設定（例えば、ＶｏＬＴＥのためのＤＲＢ確立）の必要性を認識した際に、又はランダムアクセスプリアンブル（Ｍｓｇ１）を送信する際に、物理層エンティティへの通知を行う。無線品質パラメータを測定させるための情報とは、無線品質パラメータの測定を要求する情報であってもよいし、ＶｏＬＴＥ呼設定の可用性を通知する情報であってもよい。その際に、ＲＲＣ層エンティティは、上述した第１測定設定情報又は第２測定設定情報を物理層エンティティに提供してもよい。次に、ＲＲＣ層エンティティは、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｓｅｔｕｐ  Ｃｏｍｐｌｅｔｅメッセージ（Ｍｓｇ５）の送信前に、無線品質パラメータを物理層エンティティから取得する。
【００６１】
また、ＲＲＣ層エンティティは、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｓｅｔｕｐ  Ｃｏｍｐｌｅｔｅメッセージ（Ｍｓｇ５）の送信前に、フィルタリング設定情報に基づいて無線品質パラメータのフィルタリング（すなわち、平滑化）を行う。このようなフィルタリングは、Ｌ３フィルタリングと称される。フィルタリング設定情報は、Ｌ３フィルタリングに関する各種のパラメータを含む。このようなパラメータは、例えば、Ｌ３フィルタリングの対象とする無線品質パラメータを蓄積する期間を含む。フィルタリング設定情報は、上述した第１測定設定情報と同様に、ｅＮＢ２００からブロードキャストで設定されてもよい。この場合、フィルタリング設定情報は、上述した第１測定設定情報に含まれていてもよい。或いは、フィルタリング設定情報は、上述した第２測定設定情報と同様に、ＵＥ１００に事前設定されていてもよい。
【００６２】
ＵＥ１００は、ランダムアクセスプロシージャの前、又はランダムアクセスプロシージャ中に、ｅＮＢ２００がコーデックアダプテーションを補助又は制御する機能を有する（すなわち、コーデックアダプテーションをサポートする）ことを示すインディケーションをｅＮＢ２００から受信してもよい。インディケーションは、コーデックアダプテーションをサポートすることを示す明示的なインディケーションであってもよい。明示的なインディケーションは、ｅＮＢ２００からブロードキャストで送信される。或いは、明示的なインディケーションは、ランダムアクセスプロシージャ中にｅＮＢ２００から受信するＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｓｅｔｕｐメッセージ（Ｍｓｇ４）に含まれてもよい。或いは、上述した第１測定設定情報又はフィルタリング設定情報を暗示的なインディケーションとして用いてもよい。ＵＥ１００は、インディケーションの受信に応じて、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｓｅｔｕｐ  Ｃｏｍｐｌｅｔｅメッセージに無線品質パラメータを含めることを決定する。言い換えると、インディケーションを送信しないｅＮＢ２００（サービングセル）を介して呼を設定する場合、ＵＥ１００は、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｓｅｔｕｐ  Ｃｏｍｐｌｅｔｅメッセージ（Ｍｓｇ５）に無線品質パラメータを含めない。
【００６３】
ＵＥ１００は、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｓｅｔｕｐ  Ｃｏｍｐｌｅｔｅメッセージ（Ｍｓｇ５）の送信後に、ＤＲＢを確立するためのＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  ＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージをｅＮＢ２００から受信する。「ｅＮＢ−ａｓｓｉｓｔｅｄ  Ｃｏｄｅｃ  Ａｄａｐｔａｔｉｏｎ」の場合、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージは、最小保証ビットレートを示す情報を含む。最小保証ビットレートは、推奨ビットレートであってもよい（以下同様）。ＵＥ１００は、最小保証ビットレートを示す情報を用いてコーデックアダプテーションを行う。これに対し、「ｅＮＢ−ｃｏｎｔｒｏｌｌｅｄ  Ｃｏｄｅｃ  Ａｄａｐｔａｔｉｏｎ」の場合、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージは、コーデックモード及び／又はコーデックレートを示す情報を含む。ＵＥ１００は、コーデックモード及び／又はコーデックレートを示す情報を用いてコーデックアダプテーションを行う。
【００６４】
（２）基地局
第１実施形態に係るｅＮＢ２００（基地局）は、ＵＥ１００のコーデックアダプテーションを補助又は制御する。ｅＮＢ２００は、ＵＥ１００との接続を確立するプロシージャ（ランダムアクセスプロシージャ）において、下りリンクの無線品質パラメータを含む所定メッセージ（Ｍｓｇ５）をＵＥ１００から受信する。ｅＮＢ２００は、無線品質パラメータに基づいて、ランダムアクセスプロシージャ中にＵＥ１００の無線品質を把握する。
【００６５】
「ｅＮＢ−ａｓｓｉｓｔｅｄ  Ｃｏｄｅｃ  Ａｄａｐｔａｔｉｏｎ」の場合、ｅＮＢ２００は、無線品質パラメータに基づいて、最低限保証できるＭＣＳ及び無線リソース量（例えばセミパーシステントスケジューリングの設定）を決定する。これらの情報から、ｅＮＢ２００は、最小保証ビットレートを求めることができる。ｅＮＢ２００は、最小保証ビットレートを示す情報を含むＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  ＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージをＵＥ１００に送信する。最小保証ビットレートを示す情報は、最小保証ビットレートのインデックスであってもよい。
【００６６】
「ｅＮＢ−ｃｏｎｔｒｏｌｌｅｄ  Ｃｏｄｅｃ  Ａｄａｐｔａｔｉｏｎ」の場合、ｅＮＢ２００は、ＵＥ１００の無線能力情報をＭＭＥ３００から取得し、ＵＥ１００の能力も考慮して適切なコーデックモード及び／又はコーデックレートを決定する。ＵＥ１００の無線能力情報は、ＵＥ１００がサポートするコーデックモードの情報及びＵＥ１００がコーデックアダプテーションをサポートするか否かの情報を含む。例えば、ｅＮＢ２００は、Ｓ１インターフェイスを介して、ＵＥ１００の無線能力情報を含むＩｎｉｔｉａｌ  Ｃｏｎｔｅｘｔ  Ｓｅｔｕｐ  Ｒｅｑｕｅｓｔを受信する。そして、ｅＮＢ２００は、コーデックモード及び／又はコーデックレートを示す情報を含むＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  ＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージをＵＥ１００に送信する。
【００６７】
また、ｅＮＢ２００は、上述した第１測定設定情報、フィルタリング設定情報、及びインディケーションのうち少なくとも１つを送信する。
【００６８】
（３）動作シーケンス例
図６は、第１実施形態に係る動作シーケンス例を示す図である。図６の例において、ＵＥ１００の通信相手５００は、ＳＩＰ等を用いるエンティティである。図６の例において、ＵＥ１００の初期状態はＲＲＣアイドルモードである。なお、図６に示すステップの一部を省略してもよい。
【００６９】
図６に示すように、ステップＳ１００において、ＵＥ１００は、呼設定を行うと判断する。
【００７０】
ステップＳ１０１において、ｅＮＢ２００は、コーデックアダプテーションをサポートすることを示すインディケーション（Ｓｕｐｐｏｒｔ  Ｃｏｄｅｃ  Ａｄａｐｔａｔｉｏｎ）をＳＩＢにより送信する。ＵＥ１００は、インディケーションの受信に応じて、ｅＮＢ２００がコーデックアダプテーションをサポートすると判断する。
【００７１】
ステップＳ１０２において、ｅＮＢ２００は、第１測定設定情報（Ｍｅａｓ．  Ｃｏｎｆｉｇ）をＳＩＢにより送信する。ＵＥ１００は、ｅＮＢ２００から受信した第１測定設定情報を記憶する。
【００７２】
ステップＳ１０３において、ｅＮＢ２００は、フィルタリング設定情報（Ｌ３  ｆｉｌｔｅｒｉｎｇ  ｃｏｎｆｉｇ．）をＳＩＢにより送信する。ＵＥ１００は、ｅＮＢ２００から受信したフィルタリング設定情報を記憶する。
【００７３】
ステップＳ１０４において、ＵＥ１００は、物理ランダムアクセスチャネル（ＰＲＡＣＨ）上でランダムアクセスプリアンブル（Ｍｓｇ１）をｅＮＢ２００に送信する。ｅＮＢ２００は、ランダムアクセスプリアンブル（Ｍｓｇ１）を受信する。なお、ｅＮＢ２００は、ＵＥ１００から受信したランダムアクセスプリアンブルに基づいて、ＵＥ１００との間の上りリンク遅延を推定する。
【００７４】
ステップＳ１０５において、ＵＥ１００のＲＲＣ層エンティティは、ランダムアクセスプリアンブル（Ｍｓｇ１）の送信に応じて、無線品質パラメータの測定を物理層エンティティに要求する。ＵＥ１００の物理層エンティティは、無線品質パラメータの測定を開始する。
【００７５】
ステップＳ１０６において、ｅＮＢ２００は、下りリンク共有チャネル（ＤＬ−ＳＣＨ）上でランダムアクセス応答（ＲＡ  Ｒｅｓｐｏｎｓｅ）をＵＥ１００に送信する。ランダムアクセス応答（Ｍｓｇ２）は、ＭＡＣ制御要素（ＭＡＣ  ＣＥ）の一種であり、Ｍｓｇ２と称される。ランダムアクセス応答（Ｍｓｇ２）は、遅延推定の結果に基づくタイミング補正値であるタイミングアドバンス値（ＴＡ：Ｔｉｍｉｎｇ  Ａｄｖａｎｃｅ）と、上りリンク無線リソースの割り当て情報（ＵＬ  ｇｒａｎｔ）と、プリアンブル識別子（Ｐｒｅａｍｂｌｅ  ＩＤ）と、「Ｔｅｍｐｏｒａｒｙ  Ｃ−ＲＮＴＩ」と、を含む。なお、「Ｐｒｅａｍｂｌｅ  ＩＤ」は、ＵＥ１００から受信したランダムアクセスプリアンブルの信号系列を示すＩＤである。ＵＥ１００は、ランダムアクセス応答（Ｍｓｇ２）を受信する。
【００７６】
ステップＳ１０７において、ＵＥ１００は、ランダムアクセス応答（Ｍｓｇ２）に基づいて、上りリンク共有チャネル（ＵＬ−ＳＣＨ）上でＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔメッセージ（Ｍｓｇ３）をｅＮＢ２００に送信する。ｅＮＢ２００は、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔメッセージ（Ｍｓｇ３）を受信する。
【００７７】
ステップＳ１０８において、ｅＮＢ２００は、下りリンク共有チャネル（ＤＬ−ＳＣＨ）上でＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｓｅｔｕｐメッセージ（Ｍｓｇ４）をＵＥ１００に送信する。ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｓｅｔｕｐメッセージ（Ｍｓｇ４）は、コーデックアダプテーションをサポートすることを示すインディケーション（Ｓｕｐｐｏｒｔ  Ｃｏｄｅｃ  Ａｄａｐｔａｔｉｏｎ）を含んでもよい。
【００７８】
ステップＳ１０９において、ＵＥ１００のＲＲＣ層エンティティは、フィルタリング設定情報に基づいて、物理層エンティティから取得する無線品質パラメータのＬ３フィルタリングを行う。
【００７９】
ステップＳ１１０において、ＵＥ１００は、上りリンク共有チャネル（ＵＬ−ＳＣＨ）上でＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｓｅｔｕｐ  Ｃｏｍｐｌｅｔｅメッセージ（Ｍｓｇ５）をｅＮＢ２００に送信する。ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｓｅｔｕｐ  Ｃｏｍｐｌｅｔｅメッセージ（Ｍｓｇ５）は、Ｌ３フィルタリング後の無線品質パラメータ報告（Ｍｅａｓｕｒｅｍｅｎｔ  ｒｅｐｏｒｔｉｎｇ）を含む。
【００８０】
ステップＳ１１１において、ｅＮＢ２００は、無線品質パラメータ報告に基づいて、最小保証ビットレート、又は、コーデックモード及び／又はコーデックレートを決定する。
【００８１】
ステップＳ１１２において、ｅＮＢ２００は、下りリンク共有チャネル（ＤＬ−ＳＣＨ）上でＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  ＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージをＵＥ１００に送信する。ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージは、最小保証ビットレートを示す情報、又は、コーデックモード及び／又はコーデックレートを示す情報を含む。
【００８２】
ステップＳ１１３において、ＵＥ１００は、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージに含まれる情報を用いてコーデックアダプテーションを行う。例えば、ＵＥ１００の上位層エンティティ１００ｂは、ＳＩＰを用いて通信相手５００とのネゴシエーションを行い、コーデックモード及び／又はコーデックレートを決定する。その後、ＵＥ１００は、決定したコーデックモード及び／又はコーデックレートを用いて通信相手５００とのＩＰパケット通信を行う。
【００８３】
なお、前述の通り、Ｍｓｇ５以外のメッセージ（Ｍｓｇ１、Ｍｓｇ３）において、無線品質報告を行ってもよく、この場合、Ｌ３フィルタリングなどは適宜、当該報告タイミングに間に合うように実施される。
【００８４】
（第１実施形態の変更例）
以下において、第１実施形態の変更例について、第１実施形態との相違点を主として説明する。
【００８５】
第１実施形態の変更例に係るＵＥ１００は、ｅＮＢ２００との接続を確立するプロシージャ（ランダムアクセスプロシージャ）において所定メッセージをｅＮＢ２００に送信する。第１実施形態の変更例において、所定メッセージは、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔメッセージ（Ｍｓｇ３）である。ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔメッセージ（Ｍｓｇ３）は、コーデックアダプテーションに関するネゴシエーションをｅＮＢ２００に実行させるための情報を含む。当該情報は、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔメッセージ（Ｍｓｇ３）中のｃａｕｓｅフィールドに格納されてもよい。ｃａｕｓｅフィールドは、接続確立の理由を示す情報（ｅｓｔａｂｌｉｓｈｍｅｎｔ  ｃａｕｓｅ）が格納されるフィールドである。コーデックアダプテーションに関するネゴシエーションをｅＮＢ２００に実行させるための情報は、例えば「ｅＶｏＬＴＥ（ｅｎｈａｎｃｅｄ  ＶｏＬＴＥ）」とすることができる。なお、Ｃａｕｓｅフィールドに代えて、任意のフィールド・識別子を用いてもよい。
【００８６】
ｅＮＢ２００は、「ｅＶｏＬＴＥ」の受信に応じてＵＥ１００の通信相手とネゴシエーションを行う。ｅＮＢ２００は、自身のトラフィック負荷状態に基づいて適切なコーデックモード及びコーデックレートをネゴシエーションにより決定する。その後、ｅＮＢ２００は、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｓｅｔｕｐ  Ｃｏｍｐｌｅｔｅメッセージ（Ｍｓｇ５）で無線品質パラメータを取得し、無線品質パラメータに基づいて改めてネゴシエーションを行ってもよい。
【００８７】
このように、第１実施形態の変更例においては、ＵＥ１００の通信相手とのネゴシエーションを、ＵＥ１００の代わりにｅＮＢ２００が行う。また、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔメッセージ（Ｍｓｇ３）を活用することにより、第１実施形態よりも早い段階でコーデックアダプテーションを開始することができる。
【００８８】
なお、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔメッセージ（Ｍｓｇ３）に代えて、ランダムアクセスプリアンブル（Ｍｓｇ１）を用いてもよい。この場合、特殊なＰＲＡＣＨリソース又は特殊な信号系列を用いることにより、コーデックアダプテーションに関するネゴシエーションをｅＮＢ２００に要求してもよい。
【００８９】
図７は、第１実施形態の変更例に係る動作シーケンス例を示す図である。ここでは、図６に示した動作シーケンスとの相違点について説明する。
【００９０】
ステップＳ１５１において、ＵＥ１００は、ランダムアクセス応答（Ｍｓｇ２）に基づいて、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔメッセージ（Ｍｓｇ３）をｅＮＢ２００に送信する。ｅＮＢ２００は、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔメッセージ（Ｍｓｇ３）を受信する。ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔメッセージ（Ｍｓｇ３）は、接続確立の理由を示す情報（ｅｓｔａｂｌｉｓｈｍｅｎｔ  ｃａｕｓｅ）として「ｅＶｏＬＴＥ」を含む。
【００９１】
ステップＳ１５２において、ｅＮＢ２００は、「ｅＶｏＬＴＥ」の受信に応じてＵＥ１００の通信相手とネゴシエーションを開始する。ｅＮＢ２００は、自身のトラフィック負荷状態に基づいて適切なコーデックモード及びコーデックレートを通信相手５００とのネゴシエーションにより決定してもよい（ステップＳ１５３）。
【００９２】
その後、ステップＳ１１０において、ＵＥ１００は、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｓｅｔｕｐ  Ｃｏｍｐｌｅｔｅメッセージ（Ｍｓｇ５）をｅＮＢ２００に送信する。ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｓｅｔｕｐ  Ｃｏｍｐｌｅｔｅメッセージ（Ｍｓｇ５）は、Ｌ３フィルタリング後の無線品質パラメータ（Ｍｅａｓｕｒｅｍｅｎｔ  ｒｅｐｏｒｔｉｎｇ）を含む。
【００９３】
ステップＳ１５４において、ｅＮＢ２００は、無線品質パラメータに基づいて、最小保証ビットレート、又は、コーデックモード及び／又はコーデックレートを決定する。ｅＮＢ２００は、無線品質パラメータに基づいて適切なコーデックモード及びコーデックレートを通信相手５００とのネゴシエーションにより決定してもよい（ステップＳ１５５）。
【００９４】
ステップＳ１１２において、ｅＮＢ２００は、下りリンク共有チャネル（ＤＬ−ＳＣＨ）上でＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  ＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージをＵＥ１００に送信する。ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージは、最小保証ビットレートを示す情報、又は、コーデックモード及び／又はコーデックレートを示す情報を含む。なお、当該ネゴシエーションは、ｅＮＢ２００とＵＥ１００との間で実施されてもよい。
【００９５】
（第２実施形態）
以下において、第２実施形態について、第１実施形態との相違点を主として説明する。
【００９６】
第２実施形態においては、ＵＥ１００が、ＩＰパケットを用いた音声通信の間（ｏｎ−ｇｏｉｎｇ  ｃａｌｌ）にコーデックアダプテーションを行うシナリオを想定する。このようなシナリオにおいて、ｅＮＢ２００は、コーデックアダプテーションを適切に補助又は制御するために、ＵＥ１００が現在適用しているコーデックモード及び／又はコーデックレートを把握できることが好ましい。
【００９７】
第２実施形態に係るＵＥ１００は、ｅＮＢ２００の補助又は制御に基づいてコーデックアダプテーションを行うＵＥ１００を備える。ＵＥ１００は、自ＵＥ１００のコーデックモード及び／又はコーデックレートを示すコーデック情報をｅＮＢ２００に送信する。コーデック情報は、ＰＵＣＣＨ、ＭＡＣ  ＣＥ、ＲＲＣメッセージ等により送信される。ＵＥ１００は、コーデックモード及び／又はコーデックレートの変更、又はｅＮＢ２００からの問い合わせに応じて、コーデック情報を送信する。ｅＮＢ２００は、ＵＥ１００のコーデックモード及び／又はコーデックレートを示すコーデック情報をＵＥ１００から受信する。ｅＮＢ２００は、コーデック情報に基づいてコーデックアダプテーションを補助又は制御する。
【００９８】
これにより、ｅＮＢ２００は、コーデックアダプテーションを適切に補助又は制御することができる。なお、ｅＮＢ２００は、コーデック情報をＵＥ１００のスケジューリングに用いてもよい。具体的には、ｅＮＢ２００は、コーデック情報にもとづいてＵＥ１００に割り当てる無線リソース量（例えばＳＰＳ設定）を決定する。
【００９９】
第２実施形態において、ＵＥ１００は、ｅＮＢ２００からＩＰパケットを受信する。ｅＮＢ２００は、自身が輻輳していないことを示す非輻輳情報をＩＰパケット（ＩＰヘッダ）に含める。ＵＥ１００は、非輻輳情報に基づいてコーデックアダプテーションを行う。具体的には、ＵＥ１００は、非輻輳情報の受信に応じて、コーデックレートを上昇させるようコーデックアダプテーションを行う。既存のＬＴＥの仕様には、ｅＮＢ２００が、自身が輻輳していることを示す輻輳情報をＩＰパケット（ＩＰヘッダ）に含める技術であるＥＣＮ（Ｅｘｐｌｉｃｉｔ  Ｃｏｎｇｅｓｔｉｏｎ  Ｎｏｔｉｆｉｃａｔｉｏｎ）が存在する。しかしながら、既存のＥＣＮでは、コーデックレートを低下させることしかできない。これに対し、非輻輳情報をＩＰパケットに含めることにより、コーデックレートを上昇させることが可能となる。
【０１００】
或いは、ｅＮＢ２００は、コーデックモード及び／又はコーデックレートの変更を指示するＡＳ層シグナリングをＵＥ１００に送信してもよい。ＡＳ層シグナリングとは、例えば、ＰＤＣＣＨ、ＭＡＣ  ＣＥ、ＲＲＣメッセージ等である。このようなシグナリングは、ＥＣＮとは異なり、ＵＥ１００がＩＰパケットの送受信を中断している間にも適用可能である。ＵＥ１００のＡＳ層エンティティ１００ａは、ＡＳ層シグナリングにより受信した情報を上位層エンティティ１００ｂに転送する。ＵＥ１００の上位層エンティティ１００ｂは、ＡＳ層エンティティ１００ａから転送された情報に従ってコーデックアダプテーションを行う。
【０１０１】
図８は、第２実施形態に係る動作シーケンス例を示す図である。図８の例において、ＵＥ１００の初期状態はＲＲＣコネクティッドモードである。なお、図８に示すステップの一部を省略してもよい。
【０１０２】
図８に示すように、ステップＳ２０１において、ＵＥ１００は、通信相手５００とのネゴシエーションにより決定したコーデックモード及び／又はコーデックレートで通信相手５００とのＶｏＬＴＥ通信（ＶｏＬＴＥ  ｃａｌｌ）を行う。
【０１０３】
ステップＳ２０２及びＳ２０３において、ＵＥ１００は、通信相手５００とのネゴシエーションによりコーデックモード及び／又はコーデックレートを変更する（コーデックアダプテーション）。
【０１０４】
ステップＳ２０４において、ＵＥ１００は、コーデックモード及び／又はコーデックレートの変更に応じて、現在のコーデックモード及び／又はコーデックレートを示すコーデック情報（Ｃｏｄｅｃ  ｍｏｄｅ／ｒａｔｅ  ｃｈａｎｇｅ  ｉｎｄｉｃａｔｉｏｎ）をｅＮＢ２００に送信する。ＵＥ１００は、コーデックモード及び／又はコーデックレートを変更するときは常にコーデック情報をｅＮＢ２００に送信してもよい。ステップＳ２０４は、ｅＮＢ２００により事前に報告を設定（構成）された場合のみ、実行されてもよい。
【０１０５】
或いは、ステップＳ２０４に代えて、次のような方法（ステップＳ２０５及びＳ２０６）としてもよい。ステップＳ２０５において、ｅＮＢ２００は、現在のコーデックモード及び／又はコーデックレートをＵＥ１００に問い合わせる。ステップＳ２０６において、ＵＥ１００は、ｅＮＢ２００の問い合わせに応じて、現在のコーデックモード及び／又はコーデックレートを示すコーデック情報（Ｃｏｄｅｃ  ｍｏｄｅ／ｒａｔｅ  ｒｅｓｐｏｎｓｅ）をｅＮＢ２００に送信する。
【０１０６】
ステップＳ２０７において、ｅＮＢ２００は、ＵＥ１００の現在のコーデックモード及び／又はコーデックレートを変更することを決定する。例えば、ｅＮＢ２００は、現在よりもレートを上昇させることが可能であると判断する。
【０１０７】
ステップＳ２０８において、ｅＮＢ２００は、通信相手５００から受信したＩＰパケットがＥＣＮ可能パケット（拡張ＥＣＮを含む）である場合、当該ＩＰパケットのヘッダ内のＥＣＮ  ｂｉｔｓに非輻輳（ｎｏ  ｃｏｎｇｅｓｔｉｏｎ）を設定してＵＥ１００に送信する。ＵＥ１００は、非輻輳（ｎｏ  ｃｏｎｇｅｓｔｉｏｎ）がヘッダに設定されたＩＰパケットの受信に応じて、コーデックレートを上昇させるようコーデックアダプテーションを行う（ステップＳ２１１）。なお、拡張ＥＣＮは、現状のＥＣＮフォーマットとは異なる別の（ヘッダ）フォーマットであり、混雑無しの通知をサポートする。
【０１０８】
或いは、ステップＳ２０８に代えて、次のような方法（ステップＳ２０９及びＳ２１０）としてもよい。ステップＳ２０９において、ｅＮＢ２００は、コーデックモード及び／又はコーデックレートの変更を指示するＲＲＣメッセージ（例えば、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ）をＵＥ１００に送信する。ステップＳ２１０において、ＵＥ１００のＲＲＣ層エンティティは、コーデックモード及び／又はコーデックレートの変更指示を上位層エンティティ１００ｂに転送する。ＵＥ１００の上位層エンティティ１００ｂは、ＡＳ層エンティティ１００ａから転送された変更指示に従ってコーデックアダプテーションを行う（ステップＳ２１１）。
【０１０９】
（第２実施形態の変更例）
以下において、第２実施形態の変更例について、上述した第２実施形態との相違点を主として説明する。
【０１１０】
上述した第２実施形態において、ＵＥ１００のＡＳ層エンティティ１００ａ（ＲＲＣ層エンティティ）が、コーデックモード及び／又はコーデックレートの変更指示（以下、「コマンド」という）を上位層エンティティ１００ｂに転送する一例を説明した。
【０１１１】
しかしながら、ＵＥ１００のＡＳ層エンティティ１００ａは、ｅＮＢ２００から受信するコマンド又は補助情報（以下、「コマンド／補助情報」と表記する）に基づいて、コーデックアダプテーションの必要性を判断してもよい。補助情報は、第３実施形態及びその変更例において説明するトリガ情報であってもよい。
【０１１２】
図９は、第２実施形態の変更例を示す図である。
【０１１３】
ＵＥ１００は、ｅＮＢ２００の補助又は制御に基づいてコーデックアダプテーションを行う。ＵＥ１００（制御部１３０）は、コーデックアダプテーションのためのＡＳ層シグナリングをｅＮＢ２００から受信（ステップＳ２５１）するＡＳ層エンティティ１００ａと、ＡＳ層エンティティ１００ａよりも上位層に位置付けられ、コーデックアダプテーション（ステップＳ２５４）を行う上位層エンティティ１００ｂと、を含む。上述したように、ＡＳ層エンティティ１００ａは、物理層、ＭＡＣ層、ＲＬＣ層、ＰＤＣＰ層、及びＲＲＣ層を含む。以下において、ＡＳ層エンティティ１００ａを物理層エンティティ、ＭＡＣ層エンティティ、ＲＬＣ層エンティティ、ＰＤＣＰ層エンティティ、又はＲＲＣ層エンティティと読み替えてもよい。
【０１１４】
ＡＳ層シグナリングは、コーデックアダプテーションに関するコマンド／補助情報である。ＡＳ層シグナリングは、例えばＳＩＢ（すなわち、ブロードキャストシグナリング）であってもよい。この場合、コマンド／補助情報は、セル単位で用いられる。或いは、ＡＳ層シグナリングは、ＵＥ個別（ｄｅｄｉｃａｔｅｄ）シグナリングであってもよいし、（ＳＣ−）ＭＣＣＨであってもよい。ＵＥ個別シグナリングの場合、コマンド／補助情報は、コーデックアダプテーションの対象とするＤＲＢのリストを含んでもよい。
【０１１５】
ＡＳ層エンティティ１００ａは、ＡＳ層シグナリングに基づいてコーデックアダプテーションの必要性を判断（ステップＳ２５３）し、必要性を示す通知を上位層エンティティに提供（ステップＳ２５４）する。ＡＳ層エンティティ１００ａは、コーデックアダプテーションが必要と判断した場合にのみ、通知を上位層エンティティに提供する。言い換えると、ＡＳ層エンティティ１００ａは、コーデックアダプテーションが不要と判断した場合には、通知を上位層エンティティに提供しない。
【０１１６】
通知は、単にコーデックアダプテーションの必要性を示す通知（例えば、「ｃｏｄｅｃ−ａｄａｐｔａｔｉｏｎ−ｎｅｅｄｅｄ」）であってもよい。
【０１１７】
或いは、通知は、コーデックパラメータに関する情報を含んでもよい。コーデックパラメータは、コーデックモード、コーデックレート、及び無線ビットレートのうち少なくとも１つを含む。通知は、コーデックアダプテーションの対象とするＤＲＢの識別子を含んでもよい。
【０１１８】
以下において、通知に含まれる情報の具体例について説明する。
【０１１９】
第１に、通知に含まれる情報は、コーデックレートの上下を示す情報であってもよい。例えば、ＡＳ層エンティティ１００ａは、「ｃｏｄｅｃ−ｒａｔｅ−ｕｐ」、「ｃｏｄｅｃ−ｒａｔｅ−ｄｏｗｎ」といったように、現在のコーデックレートに対する相対的なレートを上位層エンティティ１００ｂに通知する。
【０１２０】
第２に、通知に含まれる情報は、コーデックモードの変更も含み得るレートの上下を示す情報であってもよい。例えば、ＡＳ層エンティティ１００ａは、「ｃｏｄｅｃ−ｕｐ−ｒｅｑｕｅｓｔ」、「ｃｏｄｅｃ−ｄｏｗｎ−ｒｅｑｕｅｓｔ」といったように、コーデックモード及び／又はコーデックレートの変更を要求する情報を上位層エンティティ１００ｂに通知する。
【０１２１】
第３に、通知に含まれる情報は、コーデックモードの変更（再選択）を示す情報であってもよい。例えば、ＡＳ層エンティティ１００ａは、「ｃｏｄｅｃ−ｍｏｄｅ−ｃｈａｎｇｅ−ｒｅｑｕｅｓｔ」といったように、コーデックモードの変更を要求する情報を上位層エンティティ１００ｂに通知する。
【０１２２】
第４に、通知に含まれる情報は、ｅＮＢ２００から通知された（最低保証）ビットレートであってもよい。例えば、ＡＳ層エンティティ１００ａは、「ｘｘｘ−ｂｐｓ−ｇｕａｒａｎｔｅｅｄ」といったように、ｅＮＢ２００から通知された（最低保証）ビットレートを示す情報を上位層エンティティ１００ｂに通知する。なお、通知に含まれる情報を量子化し、インデックス値を上位層エンティティ１００ｂに通知してもよい。具体的には、直値とインデックス値との間の対応関係を示すマッピングテーブルが事前定義されており、ＡＳ層エンティティ１００ａ及び上位層エンティティ１００ｂは、当該マッピングテーブルを用いて直値とインデックス値との間の変換を行う。例えば、インデックス値は、「００」＝２００ｋｂｐｓ、「０１」＝４００ｋｂｐｓ…といったように定義される。
【０１２３】
なお、ＡＳ層エンティティ１００ａから上位層エンティティ１００ｂに対する通知について説明したが、上位層エンティティ１００ｂからＡＳ層エンティティ１００ａに対して通知を行ってもよい。このような通知は、第２実施形態以外の実施形態にも適用可能である。例えば、上位層エンティティ１００ｂは、コーデックアダプテーションが完了した場合に、ＡＳ層エンティティ１００ａに対して当該完了を示す通知を行ってもよい。言い換えると、ＡＳ層エンティティ１００ａは上位層エンティティ１００ｂから当該コーデックアダプテーションが完了した旨の通知を受け取ってもよい。当該通知は、ＡＳ層シグナリングを用いて、ｅＮＢ２００に転送されてもよい。もしくは、ＡＳ層シグナリングを用いた所定の動作をトリガしてもよい。所定の動作とは、例えばＢＳＲである。なお、前記コーデックアダプテーションが正常に完了できなかった場合、ＡＳ層エンティティ１００ａは上位層エンティティ１００ｂから通知を受け取らない、もしくは、当該コーデックアダプテーションが正常に完了できなかった旨を示す通知を上位層エンティティ１００ｂから受け取ってもよい。
【０１２４】
（第３実施形態）
以下において、第３実施形態について、第１及び第２実施形態との相違点を主として説明する。
【０１２５】
第３実施形態に係るＵＥ１００は、コーデックアダプテーションを実行させるためのトリガ情報をＡＳ層シグナリングによりｅＮＢ２００から受信する。トリガ情報は、コーデックレートを上昇させるべきであるか又は低下させるべきであるかを示す情報を含んでもよい。
【０１２６】
ＡＳ層シグナリングは、例えばＳＩＢ（ブロードキャストシグナリング）である。この場合、トリガ情報は、セル単位で用いられる。或いは、ＡＳ層シグナリングは、ＵＥ個別（ｄｅｄｉｃａｔｅｄ）シグナリングであってもよいし、（ＳＣ−）ＭＣＣＨであってもよい。ＵＥ個別シグナリングの場合、トリガ情報は、コーデックアダプテーションの対象とするＤＲＢのリストを含んでもよい。
【０１２７】
ＵＥ１００は、トリガ情報の受信に応じてコーデックアダプテーションを行う。具体的には、ＵＥ１００のＡＳ層エンティティ１００ａは、ＡＳ層シグナリングにより受信したトリガ情報を上位層エンティティ１００ｂに転送する。ＵＥ１００の上位層エンティティ１００ｂは、ＡＳ層エンティティ１００ａから転送されたトリガ情報に従ってコーデックアダプテーションを行う。
【０１２８】
また、ｅＮＢ２００がトリガ情報を繰り返し送信し、ＵＥ１００がトリガ情報を繰り返し受信する場合、ＵＥ１００が全てのトリガ情報を適用することは好ましくない可能性がある。
【０１２９】
このため、トリガ情報は、トリガ情報の更新を判断するためのタグ情報（ｖａｌｕｅ  ｔａｇ）を含んでもよい。ｅＮＢ２００は、トリガ情報の内容を更新する際にタグ情報を更新（カウントアップ）してもよい。ＵＥ１００は、タグ情報が更新された際に、トリガ情報を適用してもよい。具体的には、ＵＥ１００のＡＳ層エンティティ１００ａは、前回受信したトリガ情報と今回受信したタグ情報とが異なる場合に限り、今回受信したタグ情報を適用する（すなわち、上位層エンティティ１００ｂに転送する）。
【０１３０】
或いは、トリガ情報は、トリガ情報の適用を禁止する期間（禁止期間）を定めるタイマ情報を含んでもよい。ＵＥ１００のＡＳ層エンティティ１００ａは、一のトリガ情報を適用した際に、禁止期間を計時するためのタイマを開始する。ＵＥ１００ＡＳ層エンティティ１００ａは、禁止期間中に受信したトリガ情報を適用しない（すなわち、上位層エンティティ１００ｂに転送しない）。そして、禁止期間（タイマ）が満了した後に受信したトリガ情報を適用する（すなわち、上位層エンティティ１００ｂに転送する）。
【０１３１】
（第３実施形態の変更例）
以下において、第３実施形態の変更例について、第３実施形態との相違点を主として説明する。
【０１３２】
図１０は、第３実施形態の変更例を示す図である。
【０１３３】
第３実施形態の変更例において、トリガ情報は、無線品質パラメータの閾値を含む。トリガ情報は、補助情報の一種であってもよい。図１０に示すように、ＵＥ１００のＡＳ層エンティティ１００ａは、閾値を含むトリガ情報をｅＮＢ２００から受信（ステップＳ３０１）する。
【０１３４】
無線品質パラメータは、ＵＥ１００とｅＮＢ２００との間の無線通信の品質を示すパラメータである。無線品質パラメータは、ＲＳＲＰ（Ｒｅｆｅｒｅｎｃｅ  Ｓｉｇｎａｌ  Ｒｅｃｅｉｖｅｄ  Ｐｏｗｅｒ）、ＲＳＲＱ（Ｒｅｆｅｒｅｎｃｅ  Ｓｉｇｎａｌ  Ｒｅｃｅｉｖｅｄ  Ｑｕａｌｉｔｙ）、ＲＳ−ＳＩＮＲ（Ｒｅｆｅｒｅｎｃｅ  Ｓｉｇｎａｌ−Ｓｉｇｎａｌ  ｔｏ  Ｉｎｔｅｒｆｅｒｅｎｃｅ  ｐｌｕｓ  Ｎｏｉｓｅ  ｐｏｗｅｒ  Ｒａｔｉｏ）、ビットレート、エラーレート、ＨＡＲＱ又はＲＬＣの再送回数のうち、少なくとも１つである。無線品質パラメータがビットレートである場合、ビットレートの閾値は、最大許容ビットレート及び／又は最低保証ビットレートであってもよい。
【０１３５】
ＵＥ１００のＡＳ層エンティティ１００ａは、無線品質パラメータを測定（ステップＳ３０２）し、測定した無線品質パラメータが閾値を満たしたか否かを判断（ステップＳ３０３）する。測定した無線品質パラメータが閾値を満たしたことに応じて、ＡＳ層エンティティ１００ａは、コーデックアダプテーションの必要性を示す通知を上位層エンティティ１００ｂに提供（ステップＳ３０４）する。上位層エンティティ１００ｂは、当該通知に応じて、コーデックアダプテーション（ステップＳ３０５）を行う。
【０１３６】
なお、「測定した無線品質パラメータが閾値を満たす」とは、測定した無線品質パラメータの値が閾値に達することを意味する。例えば、トリガ情報がＲＳＲＰの閾値を含む場合、ＵＥ１００は、測定したＲＳＲＰがＲＳＲＰの閾値に達した（例えば、測定したＲＳＲＰが閾値を下回った）ことに応じて、コーデックアダプテーションを行う。例えば、ＡＳ層エンティティ１００ａは、ＲＳＲＰが閾値を下回った場合にコーデックレートを下げる指示を上位層エンティティ１００ｂに通知してもよい。或いは、ＡＳ層エンティティ１００ａは、ＲＳＲＰが閾値を上回った場合にコーデックレートを上げる指示を上位層エンティティ１００ｂに行ってもよい。また、このように同じ無線品質パラメータ（例えばＲＳＲＰ）に対して、複数の閾値が設定されてもよく、これらそれぞれの閾値に対して、コーデックアダプテーションの種類（例えばレートを上げる／下げる等）に関する情報が紐付いてもよい。
【０１３７】
第３実施形態の変更例において、ＵＥ１００のＡＳ層エンティティ１００ａは、測定した無線品質パラメータが閾値を満たしたことに応じて、上りリンクバッファのデータ量を示すバッファステータス報告（ＢＳＲ）をｅＮＢ２００に送信（ステップＳ３０６）してもよい。言い換えると、ＡＳ層エンティティ１００ａは、上記閾値のいずれかが満たされた場合に、ＢＳＲをトリガする。或いは、ＡＳ層エンティティ１００ａは、上記閾値のいずれかが満たされ、上位層エンティティ１００ｂにコーデックアダプテーションを指示又は通知したことに応じて、ＢＳＲをトリガする。或いは、ＡＳ層エンティティ１００ａは、上記閾値のいずれかが満たされ、上位層エンティティ１００ｂがコーデックアダプテーションを完了したことに応じて、ＢＳＲをトリガする。ｅＮＢ２００は、ＢＳＲの値によって、コーデックアダプテーション（すなわち、コーデックモード及び／又はコーデックレートの変更）が実行されたか否か（もしくは適応後のレート）を推定することができる。
【０１３８】
ここで、第３実施形態の変更例に係る動作の一例について説明する。ＵＥ１００に閾値が設定された後、ＵＥ１００は、例えば隣接セルからの干渉を受け、エラーレートが悪化し、再送が増える。ＵＥ１００は、再送回数が閾値に達したことに応じて、コーデックアダプテーションが必要であると判断し、コーデックレートを下げる。ＵＥ１００はＢＳＲをｅＮＢ２００に送信し、ｅＮＢ２００は、ＢＳＲからコーデックレートが変更されたと推定する。この場合、ｅＮＢ２００は、ＭＣＳを調整する（下げる）、及び／又は追加リソース割当を行う。
【０１３９】
（第４実施形態）
以下において、第４実施形態について、第１乃至第３実施形態との相違点を主として説明する。
【０１４０】
上述した実施形態において、ＵＥ１００は、ｅＮＢ２００の補助又は制御に基づいてコーデックアダプテーションを行う。ｅＮＢ２００の補助又は制御は、ＡＳ層シグナリングによりＵＥ１００に提供される。ここで、コーデックアダプテーションは、コーデックモードのアダプテーション及びコーデックレートのアダプテーションの少なくとも一方を含む。
【０１４１】
しかしながら、ＵＥ１００は、コーデックモードのアダプテーション及びコーデックレートのアダプテーションの一方を、ｅＮＢ２００の補助又は制御に基づくことなく行ってもよい。コーデックモードのアダプテーション及びコーデックレートのアダプテーションの一方をＵＥ１００が自身の状況に応じて自律的に決定することができる。
【０１４２】
第４実施形態に係るＵＥ１００は、自ＵＥ１００で適用するコーデックモード及びコーデックレートのうち、一方を第１の選択方法により選択し、かつ、他方を第２の選択方法により選択する。
【０１４３】
第１の選択方法は、ｅＮＢ２００の補助又は制御と無関係な選択方法である。第１の選択方法において、ＵＥ１００の上位層エンティティ１００ｂは、ＡＳ層エンティティ１００ａと独立してコーデックアダプテーションを行う。
【０１４４】
これに対し、第２の選択方法は、ｅＮＢ２００の補助又は制御に従った選択方法である。第２の選択方法において、ＵＥ１００の上位層エンティティ１００ｂは、ＡＳ層エンティティ１００ａと連携してコーデックアダプテーションを行う。
【０１４５】
第４実施形態の動作パターン１において、ＵＥ１００は、第１の選択方法によりコーデックモードを選択する。ＵＥ１００は、コーデックモードを選択した後、第２の選択方法によりコーデックレートを選択する。すなわち、この動作パターンでは、コーデックアダプテーションのうちコーデックレートのアダプテーションにのみｅＮＢ２００の補助又は制御が適用される。
【０１４６】
図１１は、第４実施形態の動作パターン１を示す図である。図１１に示すように、ステップＳ４０１において、ＵＥ１００の上位層エンティティ１００ｂは、コマンド／補助情報（ＡＳ層シグナリング）に基づかずに最適なコーデックモードを選択する。ステップＳ４０２において、ＵＥ１００のＡＳ層エンティティ１００ａは、コマンド／補助情報をｅＮＢ２００から受信する。ステップＳ４０３において、ＵＥ１００の上位層エンティティ１００ｂ又はＡＳ層エンティティ１００ａは、コマンド／補助情報に基づいて最適なコーデックレートを選択する。
【０１４７】
第４実施形態の動作パターン２において、ＵＥ１００は、第２の選択方法によりコーデックモードを選択する。ＵＥ１００は、コーデックモードを選択した後、第１の選択方法によりコーデックレートを選択する。すなわち、この動作パターンでは、コーデックアダプテーションのうちコーデックモードのアダプテーションにのみｅＮＢ２００の補助又は制御が適用される。
【０１４８】
図１２は、第４実施形態の動作パターン２を示す図である。図１２に示すように、ステップＳ４５１において、ＵＥ１００のＡＳ層エンティティ１００ａは、コマンド／補助情報（ＡＳ層シグナリング）をｅＮＢ２００から受信する。ステップＳ４５２において、ＵＥ１００の上位層エンティティ１００ｂ又はＡＳ層エンティティ１００ａは、コマンド／補助情報に基づいて最適なコーデックモードを選択する。ステップＳ４５３において、ＵＥ１００の上位層エンティティ１００ｂは、コマンド／補助情報に基づかずに最適なコーデックレートを選択する。
【０１４９】
なお、第２の選択方法において、ｅＮＢ２００の補助又は制御には、上述した実施形態に係るＡＳ層シグナリングが用いられる。或いは、ｅＮＢ２００の補助又は制御として、ｅＮＢ２００の負荷レベルを示す情報をＡＳ層シグナリングによりＵＥ１００に提供してもよい。この場合、ＵＥ１００は、第２の選択方法において、ｅＮＢ２００の負荷レベルを示す負荷情報をｅＮＢ２００から受信し、負荷情報に基づいてコーデックアダプテーションを行う。負荷情報とは、ｅＮＢ２００の無線リソースの使用率、ｅＮＢ２００のバックホールの混雑レベル、ｅＮＢ２００のハードウェア（ＣＰＵ、メモリ）の使用率等を示す情報であってもよい。或いは、負荷情報は、ｅＮＢ２００において輻輳が生じていることを示す情報であってもよい。ＵＥ１００は、負荷情報に基づいてコーデックモード又はコーデックレートを選択する。
【０１５０】
（第５実施形態）
以下において、第５実施形態について、第１乃至第４実施形態との相違点を主として説明する。
【０１５１】
上述した実施形態において、ｅＮＢ２００からコマンドを受信したＵＥ１００が、コマンドに従ってコーデックアダプテーションを行うことを主として想定していた。しかしながら、ｅＮＢ２００が知り得ない事情により、コマンドに従ったコーデックアダプテーションが困難になるケースが生じ得る。そのようなケースとして、ＵＥ１００とｅＮＢ２００との間の無線リンクとは異なる特定の通信区間において障害が発生したケースが考えられる。特定の通信区間とは、コアネットワーク、インターネット、ＵＥ１００の通信相手の無線リンク等である。例えば、コアネットワークのルータに障害が発生した場合、コーデックレートを上げることが困難になり得る。
【０１５２】
第５実施形態に係るＵＥ１００は、コーデックアダプテーションに関するコマンドをｅＮＢ２００から受信し、コマンドに基づいてコーデックアダプテーションを行う。ＵＥ１００は、コマンドを適用可能か否か判断する。ＵＥ１００は、コマンドを適用不可と判断したことに応じて、コマンドを無効化する。言い換えると、ＵＥ１００は、コマンドを適用不可と判断したことに応じて、コマンドを上書き又は無視する。
【０１５３】
ＵＥ１００は、コマンドを無効化することに応じて、コマンドを無効化することに関する通知をｅＮＢ２００に送信してもよい。また、当該通知は、ＵＥ１００が希望するコーデックパラメータを含んでもよい。コーデックパラメータは、コーデックモード、コーデックレート、及び無線ビットレートのうち少なくとも１つを含む。ｅＮＢ２００は、ＵＥ１００からの通知に基づいてコーデックモード及び／又はコーデックレートの変更を判断し、新たなコマンドをＵＥ１００に送信してもよい。
【０１５４】
図１３は、第５実施形態に係る動作シーケンス例を示す図である。
【０１５５】
図１３に示すように、ステップＳ５０１において、ＵＥ１００のＡＳ層エンティティ１００ａは、コマンドをｅＮＢ２００から受信する。ステップＳ５０２において、ＡＳ層エンティティ１００ａは、コマンドを上位層エンティティ１００ｂに転送する。
【０１５６】
ステップＳ５０３において、上位層エンティティ１００ｂは、コマンドに従ってコーデックアダプテーションを行ってもよい。ステップＳ５０４において、上位層エンティティ１００ｂは、コマンドを適用可能か否か判断する。既にコマンドに従ってコーデックアダプテーションを行っている場合、上位層エンティティ１００ｂは、当該コマンドを継続して適用可能か否か判断してもよい。例えば、上位層エンティティ１００ｂは、ＵＥ１００とｅＮＢ２００との間の無線リンクとは異なる特定の通信区間において障害が発生した否かを判断してもよい。ここでは、上位層エンティティ１００ｂがコマンドを適用不可と判断したと仮定して説明を進める。
【０１５７】
ステップＳ５０５において、上位層エンティティ１００ｂは、コマンドを無効化することに関する通知をＡＳ層エンティティ１００ａに提供する。上述したように、当該通知は、上位層エンティティ１００ｂが希望するコーデックパラメータを含んでもよい。ステップＳ５０６において、上位層エンティティ１００ｂ及びＡＳ層エンティティ１００ａは、コマンドを無効化する。ステップＳ５０７において、ＡＳ層エンティティ１００ａは、上位層エンティティ１００ｂから提供された通知をｅＮＢ２００に送信する。
【０１５８】
（その他の実施形態）
上述した実施形態において、ＵＥ１００とその通信相手との間で１対１の通信を行うことを想定していた。しかしながら、ＵＥ１００は、ブロードキャスト又はマルチキャストの通信（例えば、ＭＢＭＳ又はＳＣ−ＰＴＭ）を行ってもよい。この場合、ＵＥ１００の通信相手はアプリケーションサーバ（例えば、ＧＣＳ  ＡＳ）であってもよい。
【０１５９】
上述した実施形態において、音声データに対するコーデックアダプテーションを主として説明した。しかしながら、音声データに代えて、又は音声データに加えて、映像データに対するコーデックアダプテーションを行ってもよい。例えば、映像ストリーミング等のリアルタイムアプリケーションに対してコーデックアダプテーションを行ってもよい。
【０１６０】
上述した実施形態において、ＵＥ１００がネットワークに通知するＵＥ能力情報（ＵＥ  Ｃａｐａｂｉｌｉｔｙ）について特に触れなかった。しかしながら、ＵＥ１００は、ｅＮＢ２００もしくはＭＭＥ３００に対して、コーデックアダプテーション機能のサポート可否及び／又は種類、サポートするコーデックモードの種類、サポートするコーデックレートの種類、のいずれかひとつ以上を、ＵＥ能力情報として通知してもよい。当該通知により、ｅＮＢ２００は、第１実施形態で説明した（最低保証）ビットレートをより適切に設定し、通知することができる。例えば、コーデックレートにあるマージンを加えたビットレートを通知することができる。また、ＵＥ１００は、自身がサポートするコーデックモード／レートをベースに、ビットレートの可変幅（すなわち、無線ビットレートの最大値及び／又は最小値）をｅＮＢ２００に通知してもよい。当該通知により、ｅＮＢ２００は、ＵＥ１００の無線環境と前記可変幅の情報等を基にして、適切に無線ビットレートを調整（例えば、無線リソーススケジューリング）することができる。
【０１６１】
上述した実施形態を別個独立に実施する場合に限らず、２以上の実施形態を組み合わせて実施してもよい。例えば、一の実施形態に係る一部の構成を他の実施形態に追加してもよい。或いは、一の実施形態に係る一部の構成を他の実施形態の一部の構成と置換してもよい。
【０１６２】
上述した実施形態において、移動通信システムとしてＬＴＥシステムを例示した。しかしながら、本発明はＬＴＥシステムに限定されない。ＬＴＥシステム以外のシステムに本発明を適用してもよい。
【０１６３】
（付記１）
（導入）
よりダイナミックな無線状態下で、柔軟で効率的なコーデック変更メカニズムを提供する可能性のあるＲＡＮの拡張を検討する。本付記は、ＲＡＮの観点から取り組むべき課題について検討する。
【０１６４】
（ＲＡＮ考査）
以下の点を可能にするために、下りリンクと上りリンクの両方におけるＡＭＲ、ＥＶＳ、およびビデオを含む異なるコーデックタイプに適用可能なメカニズムを調査することが１つの目的である。
【０１６５】
・コール設定時のコーデックモードとレートの選択。
【０１６６】
・進行中の通話中のコーデックレートアダプテーション。
【０１６７】
・コーダアダプテーションをセル全体で、またはＵＥ単位またはＤＲＢ単位でトリガするコーデックレートのアップ／ダウンサイドチューニング。
【０１６８】
ＥＣＮについてのこれまでの研究によれば、すべての音声コーデックとビデオコーデックが、必要に応じてデータレートの低下に適応できるため、コール設定時及びコール進行中のネットワーク負荷条件に基づくコーデック選択に対する要件がないと結論された。しかし、ＨＤ音声品質は無線伝送の信頼性に強く依存しており、無線状態は負荷条件の変更よりも急速に変化する可能性があるため、コーデックレートアダプテーションの必要性をトリガするためにＵＥまたはｅＮＢからのさらなる補助が必要かどうかをさらに検討する必要がある。ｅＮＢがコーデックアダプテーションを直接制御するかどうか、またはｅＮＢがＲＡＮ状態に基づくコーデックレートアダプテーションのトリガにのみ関与するかどうかといった、ｅＮＢがコーデックレートアダプテーションにどの程度関与すべきかを考慮する必要がある。
【０１６９】
提案１：コール設定時および進行中のボコーダレートアダプテーションのためのｅＮＢ補助コーデックアダプテーションおよびｅＮＢ制御コーデックアダプテーションアプローチの両方を研究すべきである。
【０１７０】
コール設定時においてｅＮＢ補助またはｅＮＢ制御コーデックアダプテーションが必要であると仮定すると、ｅＮＢは、コール設定前にＵＥがアイドル状態にあると仮定してコール設定中にＵＥの無線状態を取得する必要がある。しかしながら、既存のＲＲＣ手順は、ｅＮＢがコール設定の前にＤＬ無線状態を推定する手段を有していない。したがって、ｅＮＢは、ＵＥの無線状態を取得するための標準化された手段を有することが必要である。
【０１７１】
提案２：コール設定時のコーデックアダプテーションをサポートするために、ｅＮＢがコール設定前にＵＥのＤＬ無線状態をどのように取得するかを検討すべきである。
【０１７２】
ｅＮＢは、ＵＥがコーデックアダプテーションのより効果的なネゴシエーションを容易にするために、少なくともいくつかの補助を提供すると仮定すると、ｅＮＢは、少なくとも無線状態に基づいて必要なＭＣＳ、リソースブロック量（例えば、ＳＰＳ構成）およびＧＢＲを特定のＤＲＢに対して提供する柔軟性を有すること予想されるが、ｅＮＢで観測可能であれば、ｅＮＢは初期コーデックレートアダプテーションに関する情報に基づいてこれらを提供してもよい。そうでなければ、ｅＮＢは、初期無線パラメータについてより控えめなアプローチを取ることができる。ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎの一部としてこれらを提供してもよい。
【０１７３】
提案３：ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎのコール設定後にｅＮＢが特定のＤＲＢに必要なＭＣＳ、リソース、およびＧＢＲをどのように提供するかを検討すべきである。
【０１７４】
提案１及び３に示されているように、ｅＮＢからの補助のレベルは、ｅＮＢにある過去のアプリケーション層のみに残ったコーデックアダプテーションに関する情報に大きく依存する。ｅＮＢがコーデックの選択とアダプテーションを認識すべきではないという原則を継続する場合、コーデックレートネゴシエーションに影響する可能性のある他のＲＡＮファクタを示す新しいＩＰヘッダーフォーマットを定義するための調整が必要である。或いは、パケットが欠落する可能性を受け入れる。
【０１７５】
提案４：ｅＮＢ補助型ＥＣＮがｅＮＢ補助型アプローチの候補になるかどうかを検討する必要がある。
【０１７６】
ＥＣＮベースのソリューションは、現在または将来選択される特定のコーデックとは独立しているという利点があるが、ｅＮＢはコーデックレートに直接影響を与えることはできない。このコーデックレートの直接制御の欠如の欠点の１つは、すべてのネットワークエンティティがＥＣＮをサポートできると仮定することができても、クライアント端末が許容可能なレートにネゴシエートする遅延である。ＥＣＮベースのメカニズムは、輻輳制御のみを考慮する必要がある場合には、有効的であり得る。しかし、無線状態などのよりダイナミックな変化に対しては、ｅＮＢはレートアダプテーションをより直接的に制御することが許されるべきである。
【０１７７】
提案５：ｅＮＢ制御の直接レートアダプテーションがｅＮＢ制御アプローチの候補になるかどうかを検討する必要がある。
【０１７８】
（付記２）
（１．導入）
よりダイナミックな無線環境下で、柔軟で効率的なコーデック変更メカニズムを提供する潜在的なＲＡＮ拡張を検討することが目的の１つである。本付記は、ＲＡＮベースのコーデックレートアダプテーションの実現可能なソリューションについて検討する。
【０１７９】
（２．初期考察）
ＲＡＮベースのソリューションに対する以下の理解が合意された。
【０１８０】
合意：コーデック選択／アダプテーションの実現可能な候補ソリューションの原則として、以下を取り上げる。
【０１８１】
１．ＲＡＮによって導入されたレートアダプテーションメカニズムは、ＴＳ  ２６．１１４で規定されているレートアダプテーションメカニズムと共存することができる。
【０１８２】
２．ＲＡＮによって導入されるレートアダプテーションメカニズムは、推奨ビットレートを明示的に示す必要がある。
【０１８３】
３．過剰なピンポン調整を避ける。
【０１８４】
更に検討すべき事項：ＲＡＮによって導入されるレートアダプテーションメカニズムは、コーデックタイプに依存しない。
【０１８５】
潜在的なＲＡＮベースのソリューションに対する上記のベースライン仮定に加えて、ＲＡＮとＵＥとがどのように影響し合うか、どのエンティティがコーデックレート決定に最終的に責任を負うかを決定する必要がある。コール設定中のコーデックレートアダプテーションの必要性も考慮される。
【０１８６】
（２．１．ＲＡＮ制御コーデックレートアダプテーション）
ＲＡＮ制御コーデックレートアダプテーションをサポートするためには、ＲＡＮが、サポートされる各コーデックの種類ごとに特定のコーデックレートに関する情報を有する必要があるかを考慮する必要がある。  
【０１８７】
更に検討すべき事項：ＲＡＮによって導入されるレートアダプテーションメカニズムは、コーデックタイプに依存しない。
【０１８８】
ＲＡＮがコーデックタイプに関する特定の情報を持っていると仮定すると、ＲＡＮはコーデックレート、フレームアグリゲーション、冗長性レベル、および冗長性オフセットを認識することになる。これは、ＵＥの代わりにＲＡＮが本質的にコーデックレートアダプテーションのエンドポイントとして役立つことを意味する。そのようなコーデック関連情報がＲＡＮにおいて潜在的に利用可能であっても、将来のコーデックの変更がＡＳ層シグナリングへの更なる変更をもたらすので、コーデック固有のＡＳ層シグナリングをＵＥに提供しないことが望ましい。さらに、ＥＣＮベースソリューションの大きな欠点の１つが、このようなソリューションが動作するためにすべてのネットワークエンティティがＥＣＮをサポートする必要があることを考慮すべきである。以前の結論のように、ＥＣＮソリューションは、パス上のすべてのノードが正しく動作する必要がある。
【０１８９】
ＲＡＮ内のコーデック固有の情報についても同様である。そのようなソリューションはまた、ソリューションが動作するための特定のコーデック情報をＲＡＮが有することが必要である。
【０１９０】
提案１：ベースラインとして、コーデックレートアダプテーションのソリューションは、ＲＡＮがコーデック固有の情報を持つことを必要とすべきではない。
【０１９１】
コーデックレート調整の観点から、提案１は、ＲＡＮが、ＵＥがそのコーデックレートのダウンスイッチまたはアップスイッチを実行することを要求するかどうかを、例えば、その輻輳状態に基づいて決定することができることを意味する。しかしながら、ＲＡＮが許容コーデックレートのようなコーデックに関するいくつかの情報を有する場合、コーデックレートを調整するためのより効率的またはより速い手段につながることが考えられる。したがって、許容コーデックレートなどの特定のコーデック固有情報をＵＥから取得するオプションがＲＡＮにとって必要であるかどうかについて議論すべきである。
【０１９２】
提案２：ＲＡＮ制御コーデックレートアダプテーションがサポートされる場合、ＲＡＮは、オプションとして、サポートされたコーデック動作速度をＵＥから要求することができる。
【０１９３】
他の文献で説明されているように、レートアダプテーションは主に、使用された帯域幅が十分に低く、動作条件が変化したときのパケット損失および延長遅延を回避するために使用される。この観点から、ＲＡＮは、不必要な中断を防ぐためにＵＥに十分なリソースを提供できるかどうかを決定する最良の位置にある。したがって、ＲＡＮは、ＵＥへの最小ＧＢＲを決定することを許可されるべきである。提案１が合意されると仮定すると、最小ＧＢＲを満たすためにＲＡＮ制御コーデックアダプテーションを実現する方法を考慮する必要がある。ベースラインとして、合意された内容に基づいて、ＲＡＮは推奨ビットレートを明示的に示す必要がある。また、ＲＡＮがＵＥによって動作している特定のコーデックレートを有する場合、推奨コーデックレートは、提案２で提案されるように、サポートされたコーデックレートとマッチしてもよい。
【０１９４】
承認１：ＲＡＮ制御コーデックレートアダプテーションがサポートされている場合、ＲＡＮは推奨ビットレートを明示する必要がある。
【０１９５】
承認１に基づいて、推奨ビットレートがどのようにＵＥに提供されるべきかを考慮する必要もある。一般的な選択肢には、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ、ＰＤＣＣＨ、またはＭＡＣ  ＣＥの使用が含まれる。選択肢は、コーデックレート変更の緊急性に大きく依存される。例えば、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎでは、ＲＲＣ処理には通常１５ｍｓかかる。また、ＶｏＬＴＥレイテンシに関連する議論では、４０ｍｓから６０ｍｓまでのＣ−ＤＲＸ拡張が音声品質に重大な悪影響をもたらすかどうかが検討された。しかしながら、コーデックレートの変化は頻繁に変更されることが予想されていないので、ＲＲＣ処理遅延が依然として既存のエンドツーエンドのコーデックレートアダプテーションに十分な改善を提供できる。
【０１９６】
提案３：ＲＡＮ制御コーデックレートアダプテーションがサポートされる場合、コーデックビットレートがＵＥに提供されるメカニズムについて更に検討するべきである。
【０１９７】
ＲＡＮ制御レートアダプテーションの一部とみなされるべき別の問題は、複数のレートアダプテーションアルゴリズムが同時に使用される可能性と、レートアダプテーションアルゴリズム間の相互作用がどのように処理されるべきかである。レートアダプテーションに複数のアダプテーションアルゴリズムが使用されている場合、ＭＴＳＩクライアントによって使用され得るレートは、各アダプテーションアルゴリズムによって決定されたレートのいずれよりも高くないと仮定される。既存のレートアダプテーションアルゴリズムのレイテンシを考慮すると、既存のレートアダプテーションメカニズムがＲＡＮ制御レートアダプテーションアルゴリズムを頻繁にオーバーライドする場合、ＲＡＮ制御レートアダプテーションは有効でない可能性がある。
【０１９８】
提案４：ＲＡＮ制御コーデックレートアダプテーションがサポートされている場合、ＲＡＮ２は、並列コーデックレートアダプテーションアルゴリズムの下でＵＥの動作についてさらに議論する必要がある。
【０１９９】
（２．２．ＲＡＮ補助コーデックレートアダプテーション）
２．１節で論じたＲＡＮ制御コーデックレートアダプテーションとは対照的に、ＲＡＮ支援代替は、のレートアダプテーションの最終制御をＵＥに任せる。そのようなメカニズムは、原理的にＲＡＮ補助ＷＬＡＮインターワーキングと同様であり、コーデックレートを変更する必要性を評価するためのＲＡＮ条件がＵＥに提供され、ＵＥは、必要なレート調整のために上位レイヤにおいて最終決定を行う。ＲＡＮ補助コーデックレートアダプテーションの主な利点は、既存のコーデックレートアダプテーションアルゴリズムに最小限の影響を与えることができることである。さらに、ＲＡＮは、一般的にはＲＡＮの制御外にある特定のコーデックレートに関する詳細な情報を必要としない。このメカニズムは、以下の合意／結論と簡単に整合され得る。
【０２００】
「ＲＡＮによって導入されたレートアダプテーションメカニズムは、ＴＳ  ２６．１１４で規定されているレートアダプテーションメカニズムと共存することができる。」
「候補ソリューションがＲＡＮ関連であることを認める。」
【０２０１】
ＲＡＮ補助メカニズムの主な欠点は、特定のコーデックレートの直接制御の欠如と、望ましいコーデックレートに調整するために増加した遅延である。
【０２０２】
提案５：ＲＡＮ補助コーデックレートアダプテーションがＲＡＮ制御コーデックレートアダプテーションよりも好ましいかどうかを考慮すべきである。
【０２０３】
提案５が合意されている場合、ＵＥが把握していないＲＡＮ条件を考慮すると、必要となるＲＡＮからの補助情報を考慮すべきである。補助情報は、ＵＥが目標／所望のコーデックレートで動作していない場合に、ＵＥがコーデックレートを下げるかまたは上げるかのいずれかの動作を行うことが推奨される閾値を含み得る。該閾値は、例えば、信号強度、ドロップされたパケットの数、ＨＡＲＱ再送信の数である。該閾値は、専用シグナリングまたはブロードキャストを介してＵＥに設定されてもよい。ある意味では、これは、すべてのネットワークレイヤがＥＣＮをサポートする必要はなく、ＥＣＮソリューションを最大限に利用できる。すべてのネットワークレイヤがＥＣＮをサポートする必要があることは、ＥＣＮソリューションをサポートするための主な障害の１つである。
【０２０４】
提案６：提案５が合意され得る場合、コーデックレートアダプテーションのためにＲＡＮがどのようにＵＥに補助を提供するかと、該補助の内容とをさらに検討すべきである。
【０２０５】
（２．３．コール設定中のレートアダプテーション）
以下の点を可能にするために、下りリンクと上りリンクの両方におけるＡＭＲ、ＥＶＳ、およびビデオを含む異なるコーデックタイプに適用可能なメカニズムを調査することが１つの目的である。
【０２０６】
・コール設定時のコーデックモードとレートの選択
「ネットワークローディング条件に基づいて音声コーデックの選択を行う必要はない」と他の文献が指摘し、期待されているのは、ビデオコーデックが、常に、サポートされた最低コーデックレートから開始し、良好な条件下ではより高いレートに適応するということである。しかしながら、他の文献に指摘されているように、原材料を適切に符号化するためにコーデックがより高いコーデックレートで動作が保証される必要がある期間が存在する可能性があるため、ＵＥが最低コーデックレートから開始する場合、アップチューニング遅延が過剰であり、音声品質に影響し得る。例えば、オーディオ品質を保持するために、スピーチオンセット／トランジェントのような相関が弱い信号は高いビットレートで符号化される。ＲＡＮによって導入されるレートアダプテーションメカニズムは、進行中のコールに推奨されるビットレートを明示する必要があることが既に合意されていることを考慮して、コール設定時にも同じことを適用する必要があるかどうかを検討する必要がある。
【０２０７】
提案６：コーデックレートアダプテーションがコール設定時でサポートされるべきであるかどうか検討すべきである。
【０２０８】
提案６が合意される場合、ＲＡＮはコーデックアダプテーションの一部としてその輻輳状況を考慮することができると想定することができる。しかしながら、意図されたコーデックレートをサポートするためにＵＥに割り当てられる必要なリソースをＲＡＮが決定するためには、無線状態などの、ＵＥに特に関連する他の態様も必要である。
【０２０９】
提案７：コール設定時のコーデックレートアダプテーションをサポートするためにＵＥの無線状態などのＵＥ特定情報がＲＡＮにとって必要であるかどうかをさらに検討すべきである。
【０２１０】
［相互参照］
米国仮出願第６２／３１５８４３号（２０１６年３月３１日出願）及び米国仮出願第６２／３３５８３５号（２０１６年５月１３日出願）の全内容が、参照により、本願明細書に組み込まれている。
【産業上の利用可能性】
【０２１１】
本発明は移動通信分野において有用である。
【図１】
2017170159.tif 000003
【図２】
2017170159.tif 000004
【図３】
2017170159.tif 000005
【図４】
2017170159.tif 000006
【図５】
2017170159.tif 000007
【図６】
2017170159.tif 000008
【図７】
2017170159.tif 000009
【図８】
2017170159.tif 000010
【図９】
2017170159.tif 000011
【図１０】
2017170159.tif 000012
【図１１】
2017170159.tif 000013
【図１２】
2017170159.tif 000014
【図１３】
2017170159.tif 000015
【手続補正書】
【提出日】平成30年9月27日(2018.9.27)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
メモリと当該メモリと電気的に接続されるプロセッサとを備えるユーザ装置であって、
前記プロセッサは、
音声又は映像データの符号化及び／又は復号を行うコーデックを行う処理と、
前記コーデックのためのコーデックレートを適応化するコーデックアダプテーションを行う処理と、
基地局から、前記コーデックアダプテーションを行うための推奨ビットレートを含むＭＡＣ  ＣＥを受信する処理と、
前記推奨ビットレートに基づいて、通信相手とのネゴシエーションを行うことにより、前記コーデックアダプテーションを行う処理と、を実行するユーザ装置。
【請求項２】
前記プロセッサは、
前記通信相手とのネゴシエーションに基づくビットレートを含む情報を前記基地局に送信する処理をさらに実行する請求項１に記載のユーザ装置。
【請求項３】
前記プロセッサは、
ＭＡＣエンティティにおいて、前記基地局から受信した前記推奨ビットレートをＭＡＣエンティティより上位のエンティティに通知する処理をさらに実行する請求項１又は２に記載のユーザ装置。
【請求項４】
ユーザ装置のためのプロセッサであって、
音声又は映像データの符号化及び／又は復号を行うコーデックを行う処理と、
前記コーデックのためのコーデックレートを適応化するコーデックアダプテーションを行う処理と、
基地局から、前記コーデックアダプテーションを行うための推奨ビットレート  を含むＭＡＣ  ＣＥを受信する処理と、
前記推奨ビットレートに基づいて、通信相手とのネゴシエーションを行うことにより、前記コーデックアダプテーションを行う処理と、を実行するプロセッサ。
【請求項５】
ユーザ装置のための方法であって、
音声又は映像データの符号化及び／又は復号を行うコーデックを行い、
前記コーデックのためのコーデックレートを適応化するコーデックアダプテーションを行い、
基地局から、前記コーデックアダプテーションを行うための推奨ビットレート  を含むＭＡＣ  ＣＥを受信し、
前記推奨ビットレートに基づいて、通信相手とのネゴシエーションを行うことにより、前記コーデックアダプテーションを行う方法。
【請求項６】
メモリと当該メモリと電気的に接続されるプロセッサとを備える基地局であって、
前記プロセッサは、
ユーザ装置が音声又は映像データの符号化及び／又は復号を行うコーデックのためのコーデックレートを適応化するコーデックアダプテーションを行うための推奨ビットレートを含むＭＡＣ  ＣＥを、前記ユーザ装置に送信する処理を実行する基地局。
【国際調査報告】
2017170159.tif 000016
2017170159.tif 000017
2017170159.tif 000018
2017170159.tif 000019
2017170159.tif 000020