(57)【要約】  基地局は、所定リソースブロック数に限定された狭周波数帯域を少なくとも１つ用いる無線端末との無線通信を行う。前記基地局は、前記狭周波数帯域を切り替えながら前記無線通信を行う周波数ホッピングのための設定情報を前記無線端末に送信する送信部と、前記周波数ホッピングの最初の周波数帯域及びホッピング先の周波数帯域を前記無線端末に割り当てる制御部と、を備える。前記最初の周波数帯域及び前記ホッピング先の周波数帯域のそれぞれは、前記狭周波数帯域と端数のリソースブロックとを含む。前記端数のリソースブロックは、前記所定リソースブロック数未満の数のリソースブロックである。前記制御部は、前記ホッピング先の周波数帯域に含まれる前記端数のリソースブロックの数を、前記最初の周波数帯域に含まれる前記端数のリソースブロックの数と一致させる。
2018143033.tif 000002
【特許請求の範囲】
【請求項１】
所定リソースブロック数に限定された狭周波数帯域を少なくとも１つ用いる無線端末との無線通信を行う基地局であって、
前記狭周波数帯域を切り替えながら前記無線通信を行う周波数ホッピングのための設定情報を前記無線端末に送信する送信部と、
前記周波数ホッピングの最初の周波数帯域及びホッピング先の周波数帯域を前記無線端末に割り当てる制御部と、を備え、
前記最初の周波数帯域及び前記ホッピング先の周波数帯域のそれぞれは、前記狭周波数帯域と端数のリソースブロックとを含み、
前記端数のリソースブロックは、前記所定リソースブロック数未満の数のリソースブロックであり、
前記制御部は、前記ホッピング先の周波数帯域に含まれる前記端数のリソースブロックの数を、前記最初の周波数帯域に含まれる前記端数のリソースブロックの数と一致させる、基地局。
【請求項２】
前記無線通信は、上りリンク通信であり、
前記端数のリソースブロックは、前記狭周波数帯域に隣接し、且つ、前記所定リソースブロック数未満の数のリソースブロックである、請求項１に記載の基地局。
【請求項３】
前記制御部は、前記ホッピング先の周波数帯域における前記狭周波数帯域と前記端数のリソースブロックとの間の周波数位置関係が、前記最初の周波数帯域における前記狭周波数帯域と前記端数のリソースブロックとの間の周波数位置関係と逆になるように、前記無線端末に対するリソースブロック割り当てを行う、請求項２に記載の基地局。
【請求項４】
所定リソースブロック数に限定された狭周波数帯域を少なくとも１つ用いて基地局との無線通信を行う無線端末であって、
前記狭周波数帯域を切り替えながら前記無線通信を行う周波数ホッピングのための設定情報と、前記周波数ホッピングの最初の周波数帯域及びホッピング先の周波数帯域の割り当てに関する割当情報と、を基地局から受信する受信部と、
前記設定情報と前記割当情報とに基づいて、前記周波数ホッピングを用いる前記無線通信を制御する制御部と、を備え、
前記最初の周波数帯域及び前記ホッピング先の周波数帯域のそれぞれは、前記基地局から割り当てられた前記狭周波数帯域を含み、
前記最初の周波数帯域及び前記ホッピング先の周波数帯域のうち一方の周波数帯域は、前記基地局から割り当てられた端数のリソースブロックをさらに含み、
前記端数のリソースブロックは、前記所定リソースブロック数未満の数のリソースブロックであり、
前記制御部は、前記最初の周波数帯域及び前記ホッピング先の周波数帯域のうち他方の周波数帯域について、前記端数のリソースブロックを前記無線通信に用いるか否かを決定する、無線端末。
【請求項５】
前記無線通信は、上りリンク通信であり、
前記端数のリソースブロックは、前記狭周波数帯域に隣接し、且つ、前記所定リソースブロック数未満の数のリソースブロックである、請求項４に記載の無線端末。
【請求項６】
前記制御部は、予め定められた規則に基づいて、前記他方の周波数帯域について前記端数のリソースブロックを前記無線通信に用いるか否かを決定する、請求項４に記載の無線端末。
【請求項７】
前記制御部は、前記基地局からの通知に基づいて、前記他方の周波数帯域について前記端数のリソースブロックを前記無線通信に用いるか否かを決定する、請求項４に記載の無線端末。
【請求項８】
前記他方の周波数帯域について前記端数のリソースブロックを前記無線通信に用いない場合、前記制御部は、前記他方の周波数帯域のリソースブロック数に対応するトランスポートブロックサイズを前記一方の周波数帯域及び前記他方の周波数帯域の両方に適用し、
前記他方の周波数帯域のリソースブロック数は、前記端数のリソースブロックを除外したリソースブロック数である、請求項４に記載の無線端末。
【請求項９】
前記一方の周波数帯域は、前記最初の周波数帯域であり、
前記他方の周波数帯域は、前記ホッピング先の周波数帯域である、請求項４に記載の無線端末。
【請求項１０】
前記一方の周波数帯域は、前記ホッピング先の周波数帯域であり、
前記他方の周波数帯域は、前記最初の周波数帯域である、請求項４に記載の無線端末。
【請求項１１】
所定リソースブロック数に限定された狭周波数帯域を少なくとも１つ用いる無線端末と、
前記狭周波数帯域を切り替えながら前記無線端末との無線通信を行う周波数ホッピングのための設定情報を前記無線端末に送信する基地局を有する無線通信システムであって、
前記無線端末は、
前記設定情報と、前記周波数ホッピングの最初の周波数帯域及びホッピング先の周波数帯域の割り当てに関する割当情報と、を前記基地局から受信する受信部と、
前記設定情報と前記割当情報とに基づいて、前記周波数ホッピングを用いる前記無線通信を制御する制御部と、を備え、
前記最初の周波数帯域及び前記ホッピング先の周波数帯域のそれぞれは、前記基地局から割り当てられた前記狭周波数帯域を含み、
前記最初の周波数帯域及び前記ホッピング先の周波数帯域のうち一方の周波数帯域は、前記基地局から割り当てられた端数のリソースブロックをさらに含み、
前記端数のリソースブロックは、前記所定リソースブロック数未満の数のリソースブロックであり、
前記制御部は、前記最初の周波数帯域及び前記ホッピング先の周波数帯域のうち他方の周波数帯域について、前記端数のリソースブロックを前記無線通信に用いるか否かを決定する、無線通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、移動通信システムのための基地局及び無線端末に関する。
【背景技術】
【０００２】
近年、人が介在することなく通信を行うＭＴＣ（Ｍａｃｈｉｎｅ  Ｔｙｐｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ）サービスを対象とした無線端末が検討されている。このような無線端末は、低コスト化、カバレッジ広域化、及び低消費電力化を実現することが求められる。【０００３】
移動通信システムの標準化プロジェクトである３ＧＰＰ（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）においては、システム送受信帯域の一部のみに送受信帯域幅を制限した新たな無線端末のカテゴリが規定されている。【０００４】
このような新たなカテゴリの無線端末は、無線信号の送受信に用いる周波数帯域幅が限定されており、システム送受信帯域の一部の狭周波数帯域を用いて無線通信を行う。狭周波数帯域は、例えば１．０８ＭＨｚの周波数帯域幅（すなわち、６リソースブロックの周波数帯域幅）を有する。【０００５】
このような背景下において、小容量のデータ通信のみが想定されるセンサだけではなく、センサよりも大容量のデータ通信が想定されるウェアラブル端末などにＭＴＣを用いるニーズが考えられる。このようなニーズを満たすためには、ＭＴＣにおけるスループットの増大が望まれる。
【発明の概要】
【０００６】
一実施形態に係る基地局は、所定リソースブロック数に限定された狭周波数帯域を少なくとも１つ用いる無線端末との無線通信を行う。前記基地局は、前記狭周波数帯域を切り替えながら前記無線通信を行う周波数ホッピングのための設定情報を前記無線端末に送信する送信部と、前記周波数ホッピングの最初の周波数帯域及びホッピング先の周波数帯域を前記無線端末に割り当てる制御部と、を備える。前記最初の周波数帯域及び前記ホッピング先の周波数帯域のそれぞれは、前記狭周波数帯域と端数のリソースブロックとを含む。前記端数のリソースブロックは、前記所定リソースブロック数未満の数のリソースブロックである。前記制御部は、前記ホッピング先の周波数帯域に含まれる前記端数のリソースブロックの数を、前記最初の周波数帯域に含まれる前記端数のリソースブロックの数と一致させる。
【０００７】
一実施形態に係る無線端末は、所定リソースブロック数に限定された狭周波数帯域を少なくとも１つ用いて基地局との無線通信を行う。前記無線端末は、前記狭周波数帯域を切り替えながら前記無線通信を行う周波数ホッピングのための設定情報と、前記周波数ホッピングの最初の周波数帯域及びホッピング先の周波数帯域の割り当てに関する割当情報と、を基地局から受信する受信部と、前記設定情報と前記割当情報とに基づいて、前記周波数ホッピングを用いる前記無線通信を制御する制御部と、を備える。前記最初の周波数帯域及び前記ホッピング先の周波数帯域のそれぞれは、前記基地局から割り当てられた前記狭周波数帯域を含む。前記最初の周波数帯域及び前記ホッピング先の周波数帯域のうち一方の周波数帯域は、前記基地局から割り当てられた端数のリソースブロックをさらに含む。前記端数のリソースブロックは、前記所定リソースブロック数未満の数のリソースブロックである。前記制御部は、前記最初の周波数帯域及び前記ホッピング先の周波数帯域のうち他方の周波数帯域について、前記端数のリソースブロックを前記無線通信に用いるか否かを決定する。
【図面の簡単な説明】
【０００８】
【図１】実施形態に係る移動通信システムの構成を示す図である。
【図２】実施形態に係る無線端末の構成を示す図である。
【図３】実施形態に係る基地局の構成を示す図である。
【図４】実施形態に係る移動通信システムにおける無線インターフェイスのプロトコルスタックの構成を示す図である。
【図５】実施形態に係る移動通信システムにおいて用いられる無線フレームの構成を示す図である。
【図６】実施形態に係る動作を説明するための図である。
【図７】実施形態に係る動作を説明するための図である。
【図８】実施形態に係る狭周波数帯域を示す図である。
【図９】実施形態に係る動作シーケンスを示す図である。
【図１０】実施形態に係る動作パターン１を示す図である。
【図１１】実施形態に係る動作パターン２においてホッピング先で端数のリソースブロックを用いない場合の動作を示す図である。
【図１２】実施形態に係る動作パターン２においてホッピング先で端数のリソースブロックを用いる場合の動作を示す図である。
【図１３】動作パターン３において最初のＰＵＳＣＨ送信で端数のＲＢを用いない場合の動作を示す図である。
【図１４】付記１に係るＲｅｌ−１３ＮＢ内のＰＲＢ拡張の例を示す図である。
【図１５】付記１に係るＰＲＢの数を適合させる例を示す図である。
【図１６】付記２に係る２０ＭＨｚシステム帯域幅における狭帯域インデックスおよび広帯域インデックスを示す図である。
【発明を実施するための形態】
【０００９】
（移動通信システムの構成）
実施形態に係る移動通信システムの構成について説明する。図１は、実施形態に係る移動通信システムであるＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）システムの構成を示す図である。ＬＴＥシステムは、３ＧＰＰ規格に基づく移動通信システムである。
【００１０】
図１に示すように、ＬＴＥシステムは、無線端末（ＵＥ：Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）１００、無線アクセスネットワーク（Ｅ−ＵＴＲＡＮ：Ｅｖｏｌｖｅｄ−ＵＭＴＳ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）１０、及びコアネットワーク（ＥＰＣ：Ｅｖｏｌｖｅｄ  Ｐａｃｋｅｔ  Ｃｏｒｅ）２０を備える。
【００１１】
ＵＥ１００は、移動型の通信装置であり、自身が在圏するセル（サービングセル）を管理するｅＮＢ２００との無線通信を行う。
【００１２】
Ｅ−ＵＴＲＡＮ１０は、基地局（ｅＮＢ：ｅｖｏｌｖｅｄ  Ｎｏｄｅ−Ｂ）２００を含む。ｅＮＢ２００は、Ｘ２インターフェイスを介して相互に接続される。ｅＮＢ２００は、１又は複数のセルを管理しており、自セルとの接続を確立したＵＥ１００との無線通信を行う。ｅＮＢ２００は、無線リソース管理（ＲＲＭ）機能、ユーザデータ（以下、単に「データ」という）のルーティング機能、モビリティ制御・スケジューリングのための測定制御機能等を有する。「セル」は、無線通信エリアの最小単位を示す用語として用いられる他に、ＵＥ１００との無線通信を行う機能又はリソースを示す用語としても用いられる。
【００１３】
ＥＰＣ２０は、モビリティ管理エンティティ（ＭＭＥ）及びサービングゲートウェイ（Ｓ−ＧＷ）３００を含む。ＭＭＥは、ＵＥ１００に対する各種モビリティ制御等を行う。Ｓ−ＧＷは、データの転送制御を行う。ＭＭＥ及びＳ−ＧＷは、Ｓ１インターフェイスを介してｅＮＢ２００と接続される。
【００１４】
図２は、ＵＥ１００（無線端末）の構成を示す図である。図２に示すように、ＵＥ１００は、受信部１１０、送信部１２０、及び制御部１３０を備える。
【００１５】
受信部１１０は、制御部１３０の制御下で各種の受信を行う。受信部１１０は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換して制御部１３０に出力する。
【００１６】
送信部１２０は、制御部１３０の制御下で各種の送信を行う。送信部１２０は、アンテナ及び送信機を含む。送信機は、制御部１３０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。
【００１７】
制御部１３０は、ＵＥ１００における各種の制御を行う。制御部１３０は、少なくとも１つのプロセッサ及びメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行うベースバンドプロセッサと、メモリに記憶されるプログラムを実行して各種の処理を行うＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）と、を含んでもよい。プロセッサは、後述する処理を実行する。
【００１８】
図３は、ｅＮＢ２００（基地局）の構成を示す図である。図３に示すように、ｅＮＢ２００は、送信部２１０、受信部２２０、制御部２３０、及びバックホール通信部２４０を備える。
【００１９】
送信部２１０は、制御部２３０の制御下で各種の送信を行う。送信部２１０は、アンテナ及び送信機を含む。送信機は、制御部２３０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。
【００２０】
受信部２２０は、制御部２３０の制御下で各種の受信を行う。受信部２２０は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換して制御部２３０に出力する。
【００２１】
制御部２３０は、ｅＮＢ２００における各種の制御を行う。制御部２３０は、少なくとも１つのプロセッサ及びメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行うベースバンドプロセッサと、メモリに記憶されるプログラムを実行して各種の処理を行うＣＰＵと、を含んでもよい。プロセッサは、後述する処理を実行する。
【００２２】
バックホール通信部２４０は、Ｘ２インターフェイスを介して隣接ｅＮＢと接続され、Ｓ１インターフェイスを介してＭＭＥ／Ｓ−ＧＷ３００と接続される。バックホール通信部２４０は、Ｘ２インターフェイス上で行う通信及びＳ１インターフェイス上で行う通信等に用いられる。
【００２３】
図４は、ＬＴＥシステムにおける無線インターフェイスのプロトコルスタックの構成を示す図である。図４に示すように、無線インターフェイスプロトコルは、ＯＳＩ参照モデルの第１レイヤ乃至第３レイヤに区分されており、第１レイヤは物理（ＰＨＹ）レイヤである。第２レイヤは、ＭＡＣ（Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）レイヤ、ＲＬＣ（Ｒａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ）レイヤ、及びＰＤＣＰ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｃｏｎｖｅｒｇｅｎｃｅ  Ｐｒｏｔｏｃｏｌ）レイヤを含む。第３レイヤは、ＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）レイヤを含む。
【００２４】
ＰＨＹレイヤは、符号化・復号、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行う。ＵＥ１００のＰＨＹレイヤとｅＮＢ２００のＰＨＹレイヤとの間では、物理チャネルを介してデータ及び制御情報が伝送される。
【００２５】
ＭＡＣレイヤは、データの優先制御、ハイブリッドＡＲＱ（ＨＡＲＱ）による再送処理、及びランダムアクセスプロシージャ等を行う。ＵＥ１００のＭＡＣレイヤとｅＮＢ２００のＭＡＣレイヤとの間では、トランスポートチャネルを介してデータ及び制御情報が伝送される。ｅＮＢ２００のＭＡＣレイヤは、上下リンクのトランスポートフォーマット（トランスポートブロックサイズ、変調・符号化方式（ＭＣＳ））及びＵＥ１００への割当リソースブロックを決定するスケジューラを含む。
【００２６】
ＲＬＣレイヤは、ＭＡＣレイヤ及びＰＨＹレイヤの機能を利用してデータを受信側のＲＬＣレイヤに伝送する。ＵＥ１００のＲＬＣレイヤとｅＮＢ２００のＲＬＣレイヤとの間では、論理チャネルを介してデータ及び制御情報が伝送される。
【００２７】
ＰＤＣＰレイヤは、ヘッダ圧縮・伸張、及び暗号化・復号化を行う。
【００２８】
ＲＲＣレイヤは、制御情報を取り扱う制御プレーンでのみ定義される。ＵＥ１００のＲＲＣレイヤとｅＮＢ２００のＲＲＣレイヤとの間では、各種設定のためのＲＲＣシグナリングが伝送される。ＲＲＣレイヤは、無線ベアラの確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。ＵＥ１００のＲＲＣとｅＮＢ２００のＲＲＣとの間に接続（ＲＲＣ接続）がある場合、ＵＥ１００はＲＲＣコネクティッドモードであり、そうでない場合、ＵＥ１００はＲＲＣアイドルモードである。
【００２９】
ＲＲＣレイヤの上位に位置するＮＡＳレイヤは、セッション管理及びモビリティ管理等を行う。ＵＥ１００のＮＡＳレイヤとＭＭＥ３００ＣのＮＡＳレイヤとの間では、ＮＡＳシグナリングが伝送される。
【００３０】
図５は、ＬＴＥシステムにおいて用いられる無線フレームの構成を示す図である。図５に示すように、無線フレームは、時間方向において１０個のサブフレームで構成される。各サブフレームは、時間方向において２個のスロットで構成される。各サブフレームの長さは１ｍｓであり、各スロットの長さは０．５ｍｓである。各サブフレームは、周波数方向において複数個のリソースブロック（ＲＢ）を含み、時間方向に複数個のシンボルを含む。リソースブロック（ＲＢ）は、ＰＲＢ（Ｐｈｙｓｉｃａｌ  Ｒｅｓｏｕｒｃｅ  Ｂｌｏｃｋ）と称されてもよい。各ＲＢは、周波数方向において複数個のサブキャリアを含む。具体的には、１２個のサブキャリア及び１つのスロットにより１つのＲＢが構成される。１つのシンボル及び１つのサブキャリアにより１つのリソースエレメント（ＲＥ）が構成される。また、ＵＥ１００に割り当てられる無線リソース（時間・周波数リソース）のうち、周波数リソースはＲＢにより特定でき、時間リソースはサブフレーム（又はスロット）により特定できる。
【００３１】
（実施形態に係る動作）
実施形態に係る動作について説明する。図６及び図７は、実施形態に係る動作を説明するための図である。以下においては、ＬＴＥシステムにおける上りリンクのＭＴＣについて主として説明する。
【００３２】
図６に示すように、ＬＴＥシステムのシステム周波数帯域の周波数帯域幅は１０ＭＨｚであり得る。システム送受信帯域の帯域幅は、例えば、５０ＲＢ＝９ＭＨｚである。ＭＴＣに対応するＵＥ（以下、「ＭＴＣ  ＵＥ」と称する）１００が対応可能な狭周波数帯域の帯域幅は、例えば、６ＲＢ＝１．０８ＭＨｚである。狭周波数帯域は、システム送受信帯域の一部である。以下において、６ＲＢからなる狭周波数帯域を「ＮＢ（Ｎａｒｒｏｗ  Ｂａｎｄ）」と称する。ＭＴＣは、ＮＢを用いてＭＴＣ  ＵＥ１００とｅＮＢ２００との間の無線通信（ＭＴＣ）を行う技術である。
【００３３】
図７に示すように、ＭＴＣ  ＵＥ１００は、システム送受信帯域の全体に亘って設けられる物理下りリンク制御チャネル（ＰＤＣＣＨ）を受信することができない。このため、ＰＤＣＣＨに代えて、ＭＴＣ用のＰＤＣＣＨであるＭ−ＰＤＣＣＨ（ＭＴＣ  Ｐｈｙｓｉｃａｌ  Ｄｏｗｎｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）が採用される。Ｍ−ＰＤＣＣＨは、ＭＴＣに用いる制御情報（ＤＣＩ：Ｄｏｗｎｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｉｎｆｏｒｍａｔｉｏｎ）の送信に用いられる。
【００３４】
また、ＭＴＣでは、送信側から受信側への信号の到達性を向上するために、繰り返し送信が採用されている。例えば、上りリンク通信において、図７に示すように、複数のサブフレームに亘って物理上りリンク共有チャネル（ＰＵＳＣＨ）の送信が繰り返される。
【００３５】
このような背景下において、小容量のデータ通信のみが想定されるセンサだけではなく、センサよりも大容量のデータ通信が想定されるウェアラブル端末などにＭＴＣを用いるニーズが考えられる。このようなニーズを満たすためには、ＭＴＣにおけるスループットの増大が望まれる。このため、実施形態において、ＭＴＣにおけるスループットを増大するために、ＭＴＣ  ＵＥ１００がＮＢの帯域幅よりも広い周波数帯域幅を用いて上りリンク通信を行う場合を想定する。
【００３６】
図８は、実施形態に係るＮＢを示す図である。図８に示すように、実施形態に係るＭＴＣ  ＵＥ１００は、複数のＮＢを含む帯域幅に対応可能である。当該帯域幅は、５ＭＨｚであり得る。５ＭＨｚの周波数帯域は、２５ＲＢからなる。１ＮＢが６ＲＢからなるため、５ＭＨｚの周波数帯域は、４ＮＢ及び１ＲＢからなる。１ＲＢは、５ＭＨｚの周波数帯域の中心の周波数位置に存在する。実施形態に係るＭＴＣ  ＵＥ１００は、少なくとも１つのＮＢを上りリンク通信に用いることに加えて、中心周波数に位置する１ＲＢを上りリンク通信に用いることが可能である。但し、上りリンク通信においてはＭＴＣ  ＵＥ１００が用いるＲＢは連続していることが要求されるため、中心周波数に位置する１ＲＢは、ＮＢ＃２又はＮＢ＃３と共に上りリンク通信に用いられる。
【００３７】
また、実施形態に係るＭＴＣ  ＵＥ１００は、周波数ホッピングによりＮＢを切り替えながら上りリンク通信を行う。具体的には、ＭＴＣ  ＵＥ１００は、所定周期でＮＢを切り替えながらＰＵＳＣＨの送信を行う。
【００３８】
図９は、実施形態に係る動作シーケンスを示す図である。ＭＴＣ  ＵＥ１００は、ＲＲＣコネクティッド状態であり得る。
【００３９】
図９に示すように、ステップＳ１において、ｅＮＢ２００は、ＲＲＣメッセージをＭＴＣ  ＵＥ１００に送信する。ＲＲＣメッセージは、周波数ホッピングのための設定情報（以下、「ＲＲＣパラメータ」と称する）を含む。ＲＲＣパラメータは、ＮＢ単位での周波数ホッピングを設定する情報である。ＲＲＣパラメータは、周波数ホッピングのホッピングパターンを示すパラメータ等を含み得る。具体的には、ＲＲＣパラメータは、オフセット及びホッピング間隔を含み得る。オフセットは、周波数ホッピングの各送信における周波数方向の差分（オフセット）をＮＢ単位で示すパラメータである。ホッピング間隔は、周波数ホッピングの各送信における時間方向の間隔をサブフレーム単位で示すパラメータである。また、ＰＤＳＣＨの周波数ホッピングを設定する場合、ＲＲＣパラメータは、周波数ホッピングの候補となるＮＢの数を示すパラメータであるホッピング数を含み得る。一例として、ホッピング数＝４、オフセット＝２、ホッピング間隔＝１の場合を想定すると、周波数ホッピングの各送信は以下のサブフレーム及びＮＢで行われることになる。
【００４０】
ｓｕｂｆｒａｍｅ＃１：ＮＢ＃１で送信
ｓｕｂｆｒａｍｅ＃２：ＮＢ＃３で送信
ｓｕｂｆｒａｍｅ＃３：ＮＢ＃５で送信
ｓｕｂｆｒａｍｅ＃４：ＮＢ＃７で送信
ｓｕｂｆｒａｍｅ＃５：ＮＢ＃１で送信
【００４１】
但し、この具体例では、複数のＮＢを含む帯域幅として、図８に示す５ＭＨｚの周波数帯域幅に代えて、１０ＭＨｚの周波数帯域幅を用いるケースを想定している。
【００４２】
他の例として、ホッピング数＝３、オフセット＝１、ホッピング間隔＝１の場合を想定すると、周波数ホッピングの各送信は以下のサブフレーム及びＮＢで行われることになる。
【００４３】
ｓｕｂｆｒａｍｅ＃１：ＮＢ＃１で送信
ｓｕｂｆｒａｍｅ＃２：ＮＢ＃２で送信
ｓｕｂｆｒａｍｅ＃３：ＮＢ＃３で送信
ｓｕｂｆｒａｍｅ＃４：ＮＢ＃１で送信
【００４４】
なお、ＲＲＣメッセージは、ＵＥ個別ＲＲＣメッセージ（例えば、ＲＲＣ接続再設定メッセージ）であり得る。ＲＲＣメッセージは、５ＭＨｚの周波数帯域を示すパラメータをさらに含んでもよい。ＲＲＣメッセージを受信したＵＥ１００は、ＲＲＣメッセージに含まれるパラメータを記憶する。
【００４５】
ステップＳ２において、ｅＮＢ２００は、Ｍ−ＰＤＣＣＨをＭＴＣ  ＵＥ１００に送信する。Ｍ−ＰＤＣＣＨは、ｅＮＢ２００がＭＴＣ  ＵＥ１００に割り当てた上りリンクの周波数帯域を示す割当情報を含む。このような割当情報は、上りリンクグラントと称されてもよい。割当情報は、ｅＮＢ２００がＭＴＣ  ＵＥ１００に割り当てたＮＢ及び／又はＲＢを示す情報である。ＮＢ及び／又はＲＢを示す情報は、ＮＢ及び／又はＲＢのインデックスであってもよいし、ＮＢ及び／又はＲＢの組み合わせ又は範囲を示す情報であってもよい。Ｍ−ＰＤＣＣＨは、ＰＵＳＣＨの繰り返し送信回数を示す情報を含む。Ｍ−ＰＤＣＣＨは、周波数ホッピングの適用開始を示すホッピングフラグを含む。Ｍ−ＰＤＣＣＨを受信したＭＴＣ  ＵＥ１００は、自身に割り当てられた周波数帯域を認識する。また、ＭＴＣ  ＵＥ１００は、ホッピングフラグに基づいて、ＰＵＳＣＨ送信に周波数ホッピングを適用すると判断する。
【００４６】
ステップＳ３において、ＭＴＣ  ＵＥ１００は、Ｍ−ＰＤＣＣＨを受信したサブフレームから所定サブフレーム後において、自身に割り当てられた周波数帯域を用いてＰＵＳＣＨをｅＮＢ２００に送信する。ステップＳ３におけるＰＵＳＣＨ送信は、周波数ホッピングの最初の送信である。周波数ホッピングの最初の周波数帯域は、Ｍ−ＰＤＣＣＨにより明示的に指定された周波数帯域であり得る。
【００４７】
ステップＳ４において、ＭＴＣ  ＵＥ１００は、ホッピング先の周波数帯域を用いてＰＵＳＣＨをｅＮＢ２００に送信する。ホッピング先の周波数帯域は、最初の周波数帯域及びＲＲＣパラメータに基づいて定められる。なお、ステップＳ４においてＰＵＳＣＨ上で送信されるデータは、ステップＳ３においてＰＵＳＣＨ上で送信されたデータと同じデータであり得る。
【００４８】
ステップＳ５において、ＭＴＣ  ＵＥ１００は、次のホッピング先の周波数帯域を用いてＰＵＳＣＨをｅＮＢ２００に送信する。以降のステップ（ステップＳ５、ステップＳ６、…）については、ＭＴＣ  ＵＥ１００は、繰り返し送信回数に応じた回数のＰＵＳＣＨ送信を行う。
【００４９】
このような動作において、周波数ホッピングのためのＲＲＣパラメータは、ＮＢ単位での周波数ホッピングを設定する。一方、ＭＴＣ  ＵＥ１００には、１ＮＢ未満の端数のＲＢ（例えば、図８に示す１ＲＢ）がｅＮＢ２００から割り当てられ得る。以下において、ＰＵＳＣＨの周波数ホッピングが設定されたＵＥ１００に端数のＲＢが割り当てられる場合の動作について説明する。表１は、ＰＵＳＣＨの最初の割り当て（Ｉｎｉｔｉａｌ）及びホッピング先の割り当て（ｈｏｐｐｉｎｇ）について、端数のＲＢが割り当てられるパターンを示す。
【００５０】
【表１】
2018143033.tif 000003
【００５１】
動作パターン１において、ＰＵＳＣＨの最初の割り当て及びホッピング先の割り当て（ｈｏｐｐｉｎｇ）のそれぞれが端数のＲＢを含む。
【００５２】
動作パターン２において、ＰＵＳＣＨの最初の割り当てが端数のＲＢを含む。一方、ホッピング先の割り当て（ｈｏｐｐｉｎｇ）は端数のＲＢを含まない。
【００５３】
動作パターン３において、ＰＵＳＣＨの最初の割り当てが端数のＲＢを含まない。一方、ホッピング先の割り当て（ｈｏｐｐｉｎｇ）は端数のＲＢを含む。
【００５４】
動作パターン１
動作パターン１において、ｅＮＢ２００は、所定ＲＢ数（６ＲＢ）に限定されたＮＢを少なくとも１つ用いるＭＴＣ  ＵＥ１００との上りリンク通信を行う。ｅＮＢ２００の送信部２１０は、ＮＢを切り替えながら上りリンク通信を行う周波数ホッピングのための設定情報（ＲＲＣパラメータ）をＭＴＣ  ＵＥ１００に送信する。ｅＮＢ２００の制御部２３０は、周波数ホッピングの最初の周波数帯域及びホッピング先の周波数帯域をＭＴＣ  ＵＥ１００に割り当てる。最初の周波数帯域及びホッピング先の周波数帯域のそれぞれは、少なくとも１つのＮＢと端数のＲＢとを含む。端数のＲＢは、所定ＲＢ数（６ＲＢ）未満の数のＲＢである。ｅＮＢ２００の制御部２３０は、ホッピング先の周波数帯域に含まれる端数のＲＢの数を、最初の周波数帯域に含まれる端数のＲＢの数と一致させる。
【００５５】
このように、動作パターン１によれば、周波数ホッピングの最初の周波数帯域の帯域幅及びホッピング先の周波数帯域の帯域幅を等しくすることが可能になる。よって、最初の周波数帯域及びホッピング先の周波数帯域の帯域幅のそれぞれに適用されるＰＨＹレイヤパラメータを等しくすることができる。
【００５６】
動作パターン１において、ｅＮＢ２００がＭＴＣ  ＵＥ１００に割り当てる端数のＲＢは、ｅＮＢ２００がＭＴＣ  ＵＥ１００に割り当てる少なくとも１つのＮＢに隣接する。これにより、ＲＢの連続性を担保することができる。また、動作パターン１において、ｅＮＢ２００の制御部２３０は、ホッピング先の周波数帯域におけるＮＢと端数のＲＢとの間の周波数位置関係が、最初の周波数帯域におけるＮＢと端数のＲＢとの間の周波数位置関係と逆になるように、ＭＴＣ  ＵＥ１００に対するＲＢ割り当てを行ってもよい。
【００５７】
図１０は、動作パターン１を示す図である。図１０において、ＭＴＣ  ＵＥ１００が対応可能な周波数帯域幅は、図８と同様に５ＭＨｚである。
【００５８】
図１０に示すように、ＭＴＣ  ＵＥ１００は、サブフレームＡにおいて最初のＰＵＳＣＨ送信を行い、次のサブフレームＢにおいてホッピング先のＰＵＳＣＨ送信を行う。最初のＰＵＳＣＨ送信に割り当てられた周波数帯域（最初のＰＵＳＣＨ送信帯域）は、ＮＢ＃２及び端数のＲＢ（１ＲＢ）である。ＮＢ＃２は、端数のＲＢ（１ＲＢ）に隣接する。ホッピング先のＰＵＳＣＨ送信に割り当てられた周波数帯域（ホッピング先のＰＵＳＣＨ送信帯域）は、ＮＢ＃３及び端数のＲＢ（１ＲＢ）である。ＮＢ＃３は、端数のＲＢ（１ＲＢ）に隣接する。
【００５９】
図１０において、最初のＰＵＳＣＨ送信帯域とホッピング先のＰＵＳＣＨ送信帯域とで、ＮＢと端数のＲＢ（１ＲＢ）との間の周波数位置関係が逆になっている。すなわち、ＮＢ単位で周波数ホッピングを行う場合でも、端数のＲＢ（１ＲＢ）の周波数ホッピングを行わない。このようなＲＢ割り当てをｅＮＢ２００が行うことにより、ＲＢの連続性を担保しつつ、端数のＲＢ（１ＲＢ）を有効に活用することが可能である。
【００６０】
動作パターン２
動作パターン２について、動作パターン１との相違点を主として説明する。動作パターン２において、ＭＴＣ  ＵＥ１００は、所定ＲＢ数に限定されたＮＢを少なくとも１つ用いてｅＮＢ２００との上りリンク通信を行う。ＭＴＣ  ＵＥ１００の受信部１１０は、ＮＢを切り替えながら上りリンク通信を行う周波数ホッピングのための設定情報（ＲＲＣパラメータ）と、周波数ホッピングの最初の周波数帯域及びホッピング先の周波数帯域の割り当てに関する割当情報と、をｅＮＢ２００から受信する。ＭＴＣ  ＵＥ１００の制御部１３０は、設定情報と割当情報とに基づいて、周波数ホッピングを用いる上りリンク通信を制御する。最初の周波数帯域及びホッピング先の周波数帯域のそれぞれは、ｅＮＢ２００から割り当てられた少なくとも１つのＮＢを含む。最初の周波数帯域は、ｅＮＢ２００から割り当てられた端数のＲＢをさらに含む。ＭＴＣ  ＵＥ１００の制御部１３０は、ホッピング先の周波数帯域について、端数のＲＢを上りリンク通信に用いるか否かを決定する。なお、動作パターン１と同様に、端数のＲＢは、ＮＢに隣接するＲＢである。
【００６１】
ＭＴＣ  ＵＥ１００の制御部１３０は、予め定められた規則に基づいて、ホッピング先の周波数帯域について端数のＲＢを上りリンク通信に用いるか否かを決定する。例えば、ＭＴＣ  ＵＥ１００の制御部１３０は、最初の周波数帯域が端数のＲＢを含む場合、ホッピング先の周波数帯域について端数のＲＢが明示的に割り当てられていなくても、ホッピング先の周波数帯域について端数のＲＢが割り当てられたと判断してもよい。或いは、ＭＴＣ  ＵＥ１００の制御部１３０は、最初の周波数帯域が端数のＲＢを含み、且つ、ホッピング先の周波数帯域が端数のＲＢを含まない場合、ホッピング先の周波数帯域について端数のＲＢが割り当てられないと判断してもよい。
【００６２】
或いは、ＭＴＣ  ＵＥ１００の制御部１３０は、ｅＮＢ２００からの通知に基づいて、ホッピング先の周波数帯域について端数のＲＢを上りリンク通信に用いるか否かを決定する。この場合、ＭＴＣ  ＵＥ１００の受信部１１０は、ホッピング先の周波数帯域について端数のＲＢを上りリンク通信に用いるべきか否かを示す通知情報をｅＮＢ２００から受信する。ＭＴＣ  ＵＥ１００の制御部１３０は、通知情報に基づいて、ホッピング先の周波数帯域について端数のＲＢを上りリンク通信に用いるか否かを決定する。通知情報は、ＲＲＣメッセージ（図９のステップＳ１）で送信されてもよいし、Ｍ−ＰＤＣＣＨ（図９のステップＳ２）で送信されてもよい。
【００６３】
予め定められた規則を用いる場合、ｅＮＢ２００からの通知を不要とすることができるため、シグナリングを削減することができる。一方、ｅＮＢ２００からの通知を用いる場合、ホッピング先の周波数帯域について端数のＲＢを上りリンク通信に用いるべきか否かをｅＮＢ２００が制御することができる。
【００６４】
次に、ホッピング先で端数のＲＢを用いない場合及びホッピング先で端数のＲＢを用いる場合のそれぞれの場合の動作を説明する。
【００６５】
図１１は、動作パターン２においてホッピング先で端数のＲＢを用いない場合の動作を示す図である。
【００６６】
図１１に示すように、ＭＴＣ  ＵＥ１００は、サブフレームＡにおいて最初のＰＵＳＣＨ送信を行い、次のサブフレームＢにおいてホッピング先のＰＵＳＣＨ送信を行う。最初のＰＵＳＣＨ送信に割り当てられた周波数帯域（最初のＰＵＳＣＨ送信帯域）は、ＮＢ＃２及び端数のＲＢ（１ＲＢ）である。ＮＢ＃２は、端数のＲＢ（１ＲＢ）に隣接する。ホッピング先のＰＵＳＣＨ送信に割り当てられた周波数帯域（ホッピング先のＰＵＳＣＨ送信帯域）は、ＮＢ＃４である。
【００６７】
このように、ホッピング先で端数のＲＢを用いない場合、最初のＰＵＳＣＨ送信帯域のＲＢ数とホッピング先のＰＵＳＣＨ送信帯域のＲＢ数とが一致しない。具体的には、最初のＰＵＳＣＨ送信帯域は、ホッピング先のＰＵＳＣＨ送信帯域に比べて端数のＲＢの分だけＲＢ数が多くなる。ここで、ＲＢ数は、トランスポートブロックサイズ（ＴＢＳ）と紐付いているため、ＲＢ数の相違を考慮してＴＢＳを決定する必要がある。
【００６８】
ＭＴＣ  ＵＥ１００の制御部１３０は、ホッピング先のＰＵＳＣＨ送信帯域のＲＢ数に対応するＴＢＳを、最初のＰＵＳＣＨ送信帯域及びホッピング先のＰＵＳＣＨ送信帯域の両方に適用する。ここで、ホッピング先のＰＵＳＣＨ送信帯域のＲＢ数は、端数のＲＢを除外したＲＢ数である。すなわち、ＭＴＣ  ＵＥ１００の制御部１３０は、端数のＲＢを除外したＲＢ数に応じてＴＢＳを決定し、決定したＴＢＳを最初のＰＵＳＣＨ送信及びホッピング先のＰＵＳＣＨ送信の両方に適用する。但し、ＭＴＣ  ＵＥ１００の制御部１３０は、最初のＰＵＳＣＨ送信に適用する符号化率を、ホッピング先のＰＵＳＣＨ送信に適用する符号化率よりも低く設定する。言い換えると、ホッピング先のＰＵＳＣＨで送信するトランスポートブロックに付加する冗長ビットの量よりも、最初のＰＵＳＣＨで送信するトランスポートブロックに付加する冗長ビットの量を増やす。なお、最初のＰＵＳＣＨ送信とホッピング先のＰＵＳＣＨ送信とで変調方式（変調オーダ）は同じであってもよい。
【００６９】
或いは、ＭＴＣ  ＵＥ１００の制御部１３０は、最初のＰＵＳＣＨ送信帯域に用いられるＴＢＳを、最初のＰＵＳＣＨ送信帯域及びホッピング先のＰＵＳＣＨ送信帯域の両方に適用してもよい。この場合、ｅＮＢ２００は、ＰＵＳＣＨ割り当て時に、ホッピング先（端数ＲＢ無し）のＰＵＳＣＨ送信帯域のＲＢ数で伝送可能な範囲内のＴＢＳになるようにＭＣＳを決定し、決定したＭＣＳをＵＥ１００にＭＰＤＣＣＨで通知する。
【００７０】
図１２は、動作パターン２においてホッピング先で端数のＲＢを用いる場合の動作を示す図である。
【００７１】
図１２に示すように、ＭＴＣ  ＵＥ１００の制御部１３０は、ホッピング先のＰＵＳＣＨ送信帯域を特定の周波数方向に端数ＲＢ分だけ拡張する。最初のＰＵＳＣＨ送信に割り当てられた周波数帯域（最初のＰＵＳＣＨ送信帯域）は、ＮＢ＃２及び端数のＲＢ（１ＲＢ）である。ホッピング先のＰＵＳＣＨ送信に割り当てられた周波数帯域（ホッピング先のＰＵＳＣＨ送信帯域）はＮＢ＃４であるが、端数のＲＢ（１ＲＢ）だけホッピング先のＰＵＳＣＨ送信帯域を拡張する。図１２において、低周波数方向に拡張する一例を示している。低周波数方向に拡張すべきか又は高周波数方向に拡張すべきかをｅＮＢ２００がＭＴＣ  ＵＥ１００に指示してもよい。このような指示は、ＲＲＣメッセージ又はＭ−ＰＤＣＣＨで送信されてもよい。なお、ホッピング先で端数のＲＢを用いる場合、最初のＰＵＳＣＨ送信帯域のＲＢ数とホッピング先のＰＵＳＣＨ送信帯域のＲＢ数とが一致するため、ＲＢ数の相違を考慮する必要はない。
【００７２】
動作パターン３
動作パターン３について、動作パターン２との相違点を主として説明する。動作パターン３において、最初の周波数帯域及びホッピング先の周波数帯域のそれぞれは、ｅＮＢ２００から割り当てられたＮＢを含む。ホッピング先の周波数帯域は、ｅＮＢ２００から割り当てられた端数のＲＢをさらに含む。ＭＴＣ  ＵＥ１００（制御部１３０）は、最初の周波数帯域について、端数のＲＢを上りリンク通信に用いるか否かを決定する。
【００７３】
ＭＴＣ  ＵＥ１００の制御部１３０は、予め定められた規則に基づいて、最初の周波数帯域について端数のＲＢを上りリンク通信に用いるか否かを決定する。例えば、ＭＴＣ  ＵＥ１００の制御部１３０は、ホッピング先の周波数帯域が端数のＲＢを含む場合、最初の周波数帯域について端数のＲＢが明示的に割り当てられていなくても、最初の周波数帯域について端数のＲＢが割り当てられたと判断してもよい。或いは、ＭＴＣ  ＵＥ１００の制御部１３０は、ホッピング先の周波数帯域が端数のＲＢを含み、且つ、最初の周波数帯域が端数のＲＢを含まない場合、最初の周波数帯域について端数のＲＢが割り当てられないと判断してもよい。
【００７４】
或いは、ＭＴＣ  ＵＥ１００の制御部１３０は、ｅＮＢ２００からの通知に基づいて、最初の周波数帯域について端数のＲＢを上りリンク通信に用いるか否かを決定する。この場合、ＭＴＣ  ＵＥ１００の受信部１１０は、最初の周波数帯域について端数のＲＢを上りリンク通信に用いるべきか否かを示す通知情報をｅＮＢ２００から受信する。ＭＴＣ  ＵＥ１００の制御部１３０は、通知情報に基づいて、最初の周波数帯域について端数のＲＢを上りリンク通信に用いるか否かを決定する。通知情報は、ＲＲＣメッセージ（図９のステップＳ１）で送信されてもよいし、Ｍ−ＰＤＣＣＨ（図９のステップＳ２）で送信されてもよい。
【００７５】
次に、最初のＰＵＳＣＨ送信で端数のＲＢを用いない場合及び最初のＰＵＳＣＨ送信で端数のＲＢを用いる場合のそれぞれの場合の動作を説明する。
【００７６】
図１３は、動作パターン３において最初のＰＵＳＣＨ送信で端数のＲＢを用いない場合の動作を示す図である。
【００７７】
図１３に示すように、ＭＴＣ  ＵＥ１００は、サブフレームＡにおいて最初のＰＵＳＣＨ送信を行い、次のサブフレームＢにおいてホッピング先のＰＵＳＣＨ送信を行う。最初のＰＵＳＣＨ送信に割り当てられた周波数帯域（最初のＰＵＳＣＨ送信帯域）は、ＮＢ＃１である。ホッピング先のＰＵＳＣＨ送信に割り当てられた周波数帯域（ホッピング先のＰＵＳＣＨ送信帯域）は、ＮＢ＃３及び端数のＲＢ（１ＲＢ）である。ＮＢ＃３は、端数のＲＢ（１ＲＢ）に隣接する。
【００７８】
このように、最初のＰＵＳＣＨ送信で端数のＲＢを用いない場合、最初のＰＵＳＣＨ送信帯域のＲＢ数とホッピング先のＰＵＳＣＨ送信帯域のＲＢ数とが一致しない。ＭＴＣ  ＵＥ１００の制御部１３０は、最初のＰＵＳＣＨ送信帯域のＲＢ数に対応するＴＢＳを、最初のＰＵＳＣＨ送信帯域及びホッピング先のＰＵＳＣＨ送信帯域の両方に適用する。ここで、最初のＰＵＳＣＨ送信帯域のＲＢ数は、端数のＲＢを除外したＲＢ数である。すなわち、ＭＴＣ  ＵＥ１００の制御部１３０は、端数のＲＢを除外したＲＢ数に応じてＴＢＳを決定し、決定したＴＢＳを最初のＰＵＳＣＨ送信及びホッピング先のＰＵＳＣＨ送信の両方に適用する。但し、ＭＴＣ  ＵＥ１００の制御部１３０は、最初のＰＵＳＣＨ送信に適用する符号化率は、ホッピング先のＰＵＳＣＨ送信に適用する符号化率よりも低い符号化率となる。なお、最初のＰＵＳＣＨ送信とホッピング先のＰＵＳＣＨ送信とで変調方式（変調オーダ）は同じであってもよい。
【００７９】
一方、最初のＰＵＳＣＨ送信で端数のＲＢを用いる場合、ＭＴＣ  ＵＥ１００の制御部１３０は、最初のＰＵＳＣＨ送信帯域を特定の周波数方向に端数ＲＢ分だけ拡張する。低周波数方向に拡張すべきか又は高周波数方向に拡張すべきかをｅＮＢ２００がＭＴＣ  ＵＥ１００に指示してもよい。このような指示は、ＲＲＣメッセージ又はＭ−ＰＤＣＣＨで送信されてもよい。なお、最初のＰＵＳＣＨ送信で端数のＲＢを用いる場合、最初のＰＵＳＣＨ送信帯域のＲＢ数とホッピング先のＰＵＳＣＨ送信帯域のＲＢ数とが一致するため、ＲＢ数の相違を考慮する必要はない。
【００８０】
動作パターン３における他の動作例について説明する。ＭＴＣ  ＵＥ１００には、最初のＰＵＳＣＨ送信に対してｅＮＢ２００から端数のＲＢが割り当てられず、ホッピング先のＰＵＳＣＨ送信に対してｅＮＢ２００から端数のＲＢが割り当てられる。このような前提下において、ＭＴＣ  ＵＥ１００の制御部１３０は、ホッピング先のＰＵＳＣＨ送信の際に、当該端数のＲＢの分だけＮＢ内の使用ＲＢを減らす。
【００８１】
一例として、最初のＰＵＳＣＨ送信に対して２ＮＢ（１２ＲＢ）が割り当てられ、ホッピング先のＰＵＳＣＨ送信に対して２ＮＢ（１２ＲＢ）及び当該２ＮＢに挟まれた端数のＲＢ（１ＲＢ）が割り当てられたケースを想定する。具体的には、図８の例では、ホッピング先のＰＵＳＣＨ送信に対してＮＢ＃２、ＮＢ＃３、及び端数のＲＢ（１ＲＢ）が割り当てられるケースを想定する。このようなケースにおいて、ＭＴＣ  ＵＥ１００の制御部１３０は、ホッピング先のＰＵＳＣＨ送信の際に、ＮＢ＃２の周波数方向端部に位置しており、且つ端数のＲＢに隣接しない１ＲＢをＰＵＳＣＨ送信に用いない。図８の例では、ＮＢ＃２における一番上のＲＢをＰＵＳＣＨ送信に用いない。或いは、ＭＴＣ  ＵＥ１００の制御部１３０は、ホッピング先のＰＵＳＣＨ送信の際に、ＮＢ＃３の周波数方向端部に位置しており、且つ端数のＲＢに隣接しない１ＲＢをＰＵＳＣＨ送信に用いない。図８の例では、ＮＢ＃３における一番下のＲＢをＰＵＳＣＨ送信に用いない。このような動作は、動作パターン３において常に行ってもよい。或いは、動作パターン３において、ホッピング先のＰＵＳＣＨ送信の割り当てＲＢ数（端数のＲＢを含むＲＢ数）が所定の数にならない場合に限って当該動作を適用してもよい。
【００８２】
このように、動作パターン３において端数のＲＢの分だけＮＢ内の使用ＲＢを減らすことにより、ＲＢの連続性を担保しつつ、最初のＰＵＳＣＨ送信とホッピング先のＰＵＳＣＨ送信とでＲＢ数を１２に揃えることができる。
【００８３】
なお、ホッピング先のＰＵＳＣＨ送信においてＰＵＳＣＨ送信に用いないＲＢ（すなわち、減らすＲＢ）は、予め定められたルール（例えば、ＮＢ内の割り当てＲＢのうち最も周波数の低いＲＢ又は高いＲＢを使用しないというルール）により決定されてもよい。或いは、当該減らすＲＢは、ｅＮＢ２００からＵＥ１００に明示的に指定されてもよい。当該指定は、動的な指定又は静的な指定であってもよい。
【００８４】
（変更例）
動作パターン２及び３において、端数のＲＢを除外したＲＢ数に応じてＴＢＳを決定し、決定したＴＢＳを最初のＰＵＳＣＨ送信及びホッピング先のＰＵＳＣＨ送信の両方に適用する一例を説明した。このようなＴＢＳ決定方法は動作パターン１においても用いることができる。すなわち、最初のＰＵＳＣＨ送信の割り当てが端数のＲＢを含み、且つ、ホッピング先のＰＵＳＣＨ送信の割り当ても端数のＲＢを含む場合において、端数のＲＢを除外したＲＢ数に応じてＴＢＳを決定してもよい。
【００８５】
また、隣接する端数ＲＢの有無に関わらず、端数ＲＢはＴＢＳ算出の際には数にカウントしないものとしてもよい。
【００８６】
（その他の実施形態）
実施形態において、ＮＢ単位での割り当てがされるシナリオを主として想定していた。しかしながら、ＮＢ内の一部のＲＢのみ利用するシナリオを想定してもよい。例えば、１サブフレーム時間内で２ＮＢを利用した送信を行う場合において、１ＮＢ目のＲＢ＃３，４，５，６と２ＮＢ目のＲＢ＃１，２，３，４とを用いて計８ＲＢ送信するシナリオが想定される。さらに、当該シナリオにおいて、１ＮＢ目と２ＮＢ目との間に端数ＲＢが含まれた場合には９ＲＢ送信となる。このようなシナリオにおいて、「ＮＢと端数ＲＢが隣接している」とは、「ＮＢ内で実際に割り当てられたＲＢと端数ＲＢが隣接している」と読み替えられる必要がある。
【００８７】
実施形態において、最初に端数のＲＢが割り当てられなかった第１のＵＥ（例えば、６ＲＢが割り当てられたＵＥ）は、端数のＲＢが割り当てられた第２のＵＥ（例えば、７ＲＢが割り当てられたＵＥ）が使用するホッピング先リソースを周波数方向において選択しないように、自身（第１のＵＥ）のホッピング先リソースを決定してもよい。このようなホッピング制御において、端数のＲＢの割当の実施有無に応じて、ホッピング先リソースを算出するルールを変更してもよい。ｅＮＢ２００は、（他の）ＵＥに端数のＲＢを割り当てた否か（又は、リソース算出ルールの変更）を第１のＵＥに通知してもよい。当該通知は、ＥＰＤＣＣＨにおいて伝送されてもよい。
【００８８】
実施形態では、ＭＴＣが上りリンク通信であるケースを主として説明したが、実施形態はこれに限定されるものではない。実施形態は、ＭＴＣが下りリンク通信であるケースにも適用可能である。例えば、実施形態に係る動作を物理下りリンク共有チャネル（ＰＤＳＣＨ）の周波数ホッピングに適用してもよい。
【００８９】
実施形態ではユニキャスト伝送を主として説明したが、実施形態に係る動作をマルチキャスト／ブロードキャスト伝送に適用してもよい。例えば、ＰＤＳＣＨを用いてマルチキャスト伝送を行うＳＣ−ＰＴＭに適用してもよい。
【００９０】
実施形態では特に触れていないが、ＭＴＣ  ＵＥ１００及びｅＮＢ２００が行う各処理をコンピュータに実行させるプログラムが提供されてもよい。また、プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ等の記録媒体であってもよい。
【００９１】
或いは、ＭＴＣ  ＵＥ１００及びｅＮＢ２００が行う各処理を実行するためのプログラムを記憶するメモリ及びメモリに記憶されたプログラムを実行するプロセッサによって構成されるチップセットが提供されてもよい。
【００９２】
実施形態では、移動通信システムの一例としてＬＴＥシステムを説明した。しかしながら、実施形態はこれに限定されるものではない。移動通信システムは、ＬＴＥシステム以外のシステムであってもよい。
【００９３】
（付記１）
（序論）
ＲＡＮＰ＃７２で、音声対応ウェアラブルデバイスおよび健康監視デバイスのために１Ｍｂｐｓより高いデータレートをサポートするタスクを含む、ＬＴＥ  ＷＩのためのさらに強化されたＭＴＣが承認された。本稿において、我々は、より高いデータレートのためにより大きい最大帯域幅を伴う周波数ホッピングの残っている問題を論じる。
【００９４】
ＲＡＮ１会合で、以下が合意された：
合意：
−より大きいＢＷをサポートするＦｅＭＴＣ  ＵＥに対するＰＤＳＣＨ割当ては、５ＭＨｚ最大ＰＤＳＣＨチャネル帯域幅で構成されるＵＥに対してＬＴＥリリース１３で規定される狭帯域の一部であるリソースブロックに限定される。
【００９５】
−２４ＰＲＢは、割り当てることができるＰＲＢの最大数である。
【００９６】
−より大きいＢＷをサポートするＦｅＭＴＣ  ＵＥに対するＰＤＳＣＨ割当ては、２０ＭＨｚ最大ＰＤＳＣＨチャネル帯域幅で構成されるＵＥに対してＬＴＥリリース１３で規定される狭帯域の一部であるリソースブロックに限定される。
【００９７】
−９６ＰＲＢは、割り当てることができるＰＲＢの最大数である。
【００９８】
−より大きいＢＷを持つＦｅＭＴＣ  ＵＥに対するＰＵＳＣＨ割当ては、少なくとも、ＬＴＥリリース１３で規定される狭帯域の一部でない一定のＰＲＢを含み得る。
【００９９】
−これは、奇数システム帯域幅の場合、少なくとも中央のＰＲＢを含む。
【０１００】
−今後の検討課題：どの狭帯域にも属さない帯域端におけるＰＲＢ
合意：
−最大５ＭＨｚ  ＰＤＳＣＨチャネル帯域幅で構成されるＲｅｌ−１４  ＢＬ／ＣＥ  ＵＥに対して、連続的および非連続的リソース割当てがサポートされる。
【０１０１】
合意：
−５ＭＨｚ最大ＰＤＳＣＨ／ＰＵＳＣＨチャネル帯域幅を動作させるＢＬ／ＣＥ  ＵＥに対してＰＤＳＣＨ／ＰＵＳＣＨ周波数ホッピングがサポートされる。
【０１０２】
−Ｒｅｌ−１３周波数ホッピングＲＲＣパラメータを再利用する。
【０１０３】
−今後の検討課題：奇数システム帯域幅で中央ＰＲＢをどのように取り扱うか
−今後の検討課題：ラップアラウンドが起こり得るかどうか
−（例えば、システム帯域幅より小さいＵＥ帯域幅を持つＰＵＳＣＨまたはＰＤＳＣＨに対して）ラップアラウンドを伴う周波数ホッピング・エラー・ケースが起こらないことを保証するかどうかはｅＮＢ実装次第である。
【０１０４】
−これは、これらのケースに対してＵＥ挙動を指定することを妨げない。
【０１０５】
−ＰＤＳＣＨ／ＰＵＳＣＨ周波数ホッピングは、ＣＥモードＡでＤＣＩを介して動的に使用可能および使用禁止にすることができる。
【０１０６】
（周波数ホッピングのリーミング問題）
より高いデータレートに対する周波数ホッピングが合意され、Ｒｅｌ−１３周波数ホッピングＲＲＣパラメータが再利用される。ＲＲＣパラメータは、ホッピングオフセットおよびホッピング間隔を有する。ＤＣＩ中の周波数ホッピングフラグがＯＮである場合、ＲＲＣパラメータによって設定されたホッピングが適用される。周波数ホッピングのリソース割当ては、ＤＣＩによって指示される初期リソース割当てに基づいている。
【０１０７】
ＰＤＳＣＨ周波数ホッピングに関して、ＰＤＳＣＨのリソース割当てはＲｅｌ−１３ＮＢ（Ｎａｒｒｏｗ  Ｂａｎｄ：狭帯域）内に位置するだけであるから、Ｒｅｌ−１３周波数ホッピングが旧式のＲＲＣパラメータに従う場合ラップアラウンド以外問題がない。他方、ＰＵＳＣＨについては、Ｒｅｌ−１３の一部でない少なくとも中央のＰＲＢをサポートすることが合意された。しかしながら、ＮＢの一部でない中央のＲＢをどのように扱うかはまだ決定されなかった。ＮＢの一部でないＰＲＢは、下の表２で示されるシステム帯域幅に依存し、表３は、状況がどのように３つのケースに分けられるかを示す。
【０１０８】
【表２】
2018143033.tif 000004
（表２  Ｒｅｌ−１３リソース割当ての一部でないＰＲＢの数）
【０１０９】
【表３】
2018143033.tif 000005
（表３  初期リソース割当てと周波数ホッピング後の割当てとの間のＮＢの一部でないＰＲＢの数のケース）
【０１１０】
ケース１は、初期リソース割当てが、Ｒｅｌ−１３ＮＢの一部でないＰＲＢまたは隣接ＰＲＢを含み、周波数ホッピング後のリソース割当てがＲｅｌ−１３ＮＢの一部でないＰＲＢまたは隣接ＰＲＢを同様に含むことを意味する。この場合、ＵＥは、追加の指示無しで両方のＰＲＢを利用する機会を有する。しかしながら、周波数ホッピング後のリソース割当ては、ＤＣＩによって指示されるリソース割当てから少し変更される。
【０１１１】
提案１：初期リソース割当てがＲｅｌ−１３ＮＢの一部でないＰＲＢを含む場合、Ｒｅｌ−１３ＮＢの一部でないＰＲＢは周波数ホッピング後のリソース割当てのために使用されるべきである。
【０１１２】
ケース２およびケース３に関して、初期リソース割当てまたは周波数ホッピング後のリソース割当てのうちの１つだけがＲｅｌ−１３ＮＢの一部でないＰＲＢを有さない。したがって、Ｒｅｌ−１３ＮＢの一部でないＰＲＢをどのように扱うかを決定すべきである。我々は次の２つの方法を提言する：
（１）Ｒｅｌ−１３ＮＢ内のＰＲＢ拡張
（２）ＮＢの一部でない、含まれているＰＲＢまたは隣接ＰＲＢの存在に応じてＰＲＢの数を適合させる。
【０１１３】
（１．Ｒｅｌ−１３ＮＢ内のＰＲＢ拡張）
下の図１４で示されるように、初期リソース割当ては、Ｒｅｌ−１３ＮＢの一部でないＰＲＢを有し、周波数ホッピング後のリソース割当ては、Ｒｅｌ−１３ＮＢの一部でないＰＲＢの代わりにＮＢ内のＰＲＢを拡張する。この方法は、Ｒｅｌ−１３ＮＢの一部でないＰＲＢが存在しない場合でも、初期リソース割当てと周波数ホッピング後のリソース割当てとの間でＰＲＢの数を維持することができる。しかしながら、拡張されたＰＲＢ内でＲｅｌ−１３ｅＭＴＣ  ＵＥと他のＲｅｌ−１４ＦｅＭＴＣ  ＵＥとのオーバーラップが起こり得る。オーバーラップを回避するために、ＵＬ許可を送信するとき、このようなリソース割当てを考慮に入れるべきである。この方法は、ＦｅＭＴＣに対してＰＲＢの数を維持することができる一方、オーバーラップを回避するためにＲｅｌ−１３ＦｅＭＴＣ  ＵＥおよび他のＲｅｌ−１４ＦｅＭＴＣ  ＵＥに対するリソース割当てが少し制限されることになる。
【０１１４】
（２．ＮＢの一部でない、含まれているＰＲＢまたは隣接ＰＲＢの存在に応じてＰＲＢの数を適合させる）
第２の方法は、図１５に示されるように、リソース割当てのうちの１つがＮＢの一部でないＰＲＢを含まない場合、ＮＢの一部でないＰＲＢを適合させる。例えば、初期リソース割当ては、ＮＢ内の８個のＰＲＢおよびＲｅｌ−１３ＮＢの一部でない１個のＰＲＢ（中央（／端））を有する一方、周波数ホッピング後のリソース割当ては、ＮＢ内の８個のＰＲＢだけを有する。この場合、ＮＢ内のＰＲＢの使用法がホッピングの間に変化しないので、オーバーラップは生じない。他方、ＰＲＢの数が初期と周波数ホッピング状態とで異なるので、我々はＴＢＳフォーマット／サイズをどのように決定するかを考慮すべきである。最も簡単な方法の１つは、ＵＥがただ初期リソース割当てのＰＲＢの数を使用し、ＰＲＢの数が変化する場合でも周波数ホッピング後の伝送に対して同じＴＢＳが使用されることである。異なる数のＰＲＢを用いたその後の伝送のために符号化レートを調整しなければならないので、この方法は潜在的な問題を有するおそれがある。しかしながら、この問題は、ｅＮＢスケジューラによって解決することができる（例えば、ＭＣＳインデックスを調整する）。加えるに、割り当てられるＰＲＢの数は、初期および周波数ホッピング後の両方のリソース割当てに対して２ａ＊３ｂ＊５ｃとすべきであるから、ｅＮＢは、割り当てられるＰＲＢの数について注意すべきである。
【０１１５】
２つの方法を比較すると、Ｒｅｌ−１３ＮＢ内のＰＲＢ拡張は、衝突回避のためのスケジューリング制限に起因してシステム効率を低下させる場合がある。加えるに、第２の方法は、旧式のｅＭＴＣ  ＵＥに影響を与えずに符号化レートを調整することを可能にする。したがって、我々は、第２の方法がＲｅｌ−１４に採用されるほうを好む。他の見地から、ＮＢの一部でない端のＰＲＢをサポートするべきかどうかまだ決定されていない。しかしながら、第２の方法は、同様に、ＦｅＭＴＣ伝送のために端のＰＲＢをサポートする場合に適用可能とすることができる。
【０１１６】
提案２：初期リソース割当てと周波数ホッピングリソース割当てとの間のＰＲＢの数が異なる場合、ＮＢの一部でない、含まれているＰＲＢまたは隣接するＰＲＢの存在に応じてＰＲＢの数を適合させる。 
【０１１７】
（付記２）
（１．序論）
ＲＡＮＰ＃７２で、音声対応ウェアラブルデバイスおよび健康監視デバイスのために１Ｍｂｐｓより高いデータレートをサポートするタスクを含む、ＬＴＥ  ＷＩのためのさらに強化されたＭＴＣが承認された。本稿において、我々は、より高いデータレートのためのＲＢ割振りを論じる。
【０１１８】
−ＲＡＮ１会合で、以下が合意された：
合意：
−次のＲＡＮ１合意は、非ＢＬ  ＵＥ用のＰＵＳＣＨに対する最大チャネルＢＷについて修正される。
【０１１９】
−修正前
−Ｒｅｌ−１４非ＢＬ  ＵＥは、５または２０ＭＨｚの最大ＰＤＳＣＨ／ＰＵＳＣＨチャネル帯域幅を持つ接続モードでＣＥモードＡをサポートすることができる。
【０１２０】
−修正後
−Ｒｅｌ−１４非ＢＬ  ＵＥは、５または２０ＭＨｚの最大ＰＤＳＣＨチャネル帯域幅を持つ接続モードでＣＥモードＡをサポートすることができる。
【０１２１】
−Ｒｅｌ−１４非ＢＬ  ＵＥは、５ＭＨｚの最大ＰＵＳＣＨチャネル帯域幅を持つ接続モードでＣＥモードＡをサポートすることができる。
【０１２２】
−Ｒｅｌ−１４非ＢＬ  ＵＥは、１．４、５または２０ＭＨｚの最大ＰＤＳＣＨチャネル帯域幅を持つ接続モードでＣＥモードＢをサポートすることができる。
【０１２３】
−Ｒｅｌ−１４非ＢＬ  ＵＥは、１．４ＭＨｚの最大ＰＵＳＣＨチャネル帯域幅を持つ接続モードでＣＥモードＢをサポートすることができる。
【０１２４】
合意：
−より大きいＢＷをサポートするＦｅＭＴＣ  ＵＥに対するＰＤＳＣＨ割当ては、５ＭＨｚ最大ＰＤＳＣＨチャネル帯域幅で構成されるＵＥに対してＬＴＥリリース１３で規定される狭帯域の一部であるリソースブロックに限定される。
【０１２５】
−２４ＰＲＢは、割り当てることができるＰＲＢの最大数である。
【０１２６】
−より大きいＢＷをサポートするＦｅＭＴＣ  ＵＥに対するＰＤＳＣＨ割当ては、２０ＭＨｚ最大ＰＤＳＣＨチャネル帯域幅で構成されるＵＥに対してＬＴＥリリース１３で規定される狭帯域の一部であるリソースブロックに限定される。
【０１２７】
−９６ＰＲＢは、割り当てることができるＰＲＢの最大数である。
【０１２８】
−より大きいＢＷを持つＦｅＭＴＣ  ＵＥに対するＰＵＳＣＨ割当ては、少なくとも、ＬＴＥリリース１３で規定される狭帯域の一部でない一定のＰＲＢを含み得る。
【０１２９】
−これは、奇数システム帯域幅の場合、少なくとも中央のＰＲＢを含む。
【０１３０】
−今後の検討課題：どの狭帯域にも属さない帯域端におけるＰＲＢ
合意：
−最大５ＭＨｚ  ＰＤＳＣＨチャネル帯域幅で構成されるＲｅｌ−１４  ＢＬ／ＣＥ  ＵＥに対して、連続的および非連続的リソース割当てがサポートされる。
【０１３１】
−最大２０ＭＨｚ  ＰＤＳＣＨチャネル帯域幅で構成されるＲｅｌ−１４非ＢＬ  ＵＥに対して、連続的および非連続的リソース割当てがサポートされる。
【０１３２】
（２．リソース割当ての残っている問題）
前の会合で、ＲＡＮ１は、ＢＬおよび非ＢＬ  ＵＥが下の表４で示される次の帯域幅をサポートし得ることを合意した。しかしながら、リソース割当ての詳細は、まだ決定されなかった。我々は、ＣＥモードとＤＬ／ＵＬとの間で議論を切り離す必要がある。本節において、我々は、各リソース割当てに関する我々の見解を１つずつ論じる。
【０１３３】
【表４】
2018143033.tif 000006
（表４  ＢＬ／ＣＥ  ＵＥおよび非ＢＬ  ＵＥに対するチャネル帯域幅）
【０１３４】
（２．１．ＢＬ／ＣＥ  ＵＥに対するリソース割当て）
（２．１．１．ＣＥモードＡ）
ＲＡＮ１＃８７で、５ＭＨｚ  ＤＬおよびＵＬに対するさまざまな候補リソース割当て方式が多くの企業によって提案された。候補方式は、分散型／局在型と局在型のみとの間で分類された。分散型／局在型は、非ＭＴＣ  ＵＥを含んだ連続的および非連続的リソース割当ての組合せを意味する。他方、局在型のみは、ただ連続的リソース割当てのみを意味する。本稿において、我々は、上記の候補リソース割当て方式に基づいて我々の見解を共有する。
【０１３５】
（２．１．１．１．ＰＤＳＣＨ）
ＲＡＮ１は、「最大５ＭＨｚ  ＰＤＳＣＨチャネル帯域幅で構成されるＲｅｌ−１４  ＢＬ／ＣＥ  ＵＥに対して、連続的および非連続的リソース割当てがサポートされる」ことを合意した。したがって、分散型および局在型リソースマッピングの組合せがＰＤＳＣＨに対して合意された。局在型のみのリソース割当て方式は、候補から除外された。以下は、連続的および非連続的リソース割当てに対応する、リソース割当ての選択肢である。      
【０１３６】
ＲＡＮ１＃８７提案
−リソース割当ては、ＣＥモードＡにおいて５ＭＨｚのより大きいチャネル帯域幅を持つＰＤＳＣＨに対してサポートされる。
【０１３７】
−分散型／局在型
−選択肢１：開始狭帯域インデックス（または広帯域インデックス）＋ＮＢビットマップ＋既存の狭帯域内のリソース割当て
−選択肢２：開始狭帯域インデックス（または広帯域インデックス）＋５ＭＨｚ広帯域内のＲＢＧのビットマップ
−選択肢３：広帯域インデックス＋（局在型／分散型フラグを含む）広帯域内のリソース割当てタイプ２に基づいた分散型割当て
【０１３８】
（開始狭帯域インデックスまたは広帯域インデックス）
選択肢−１および選択肢−２は、開始狭帯域または広帯域インデックスである２タイプの指示を有する。これらの２つの指示を比較すると、ビットサイズとスケジューリング柔軟性との間にトレードオフがある。下の図１６で示されるように、開始狭帯域インデックスは、各１．４ＭＨｚを指示することができる。他方、広帯域インデックスは、ただ各５ＭＨｚを指示することができる。狭帯域指示粒度は、広帯域インデックス作成より多くのスケジューリング柔軟性を提供する。旧式ＵＥとの多重化をより取り扱いやすくし、したがって、我々は、開始狭帯域インデックスをサポートする。
【０１３９】
提案１：ＲＡＮ１は、旧式ＵＥとの多重化のために開始狭帯域インデックスをサポートすべきである。
【０１４０】
加えるに、５ＭＨｚ幅またはより小さい帯域幅において、狭帯域インデックス付けが使用される場合を除いて、キャリア配置は何もインデックス付けを必要としないことになる。
【０１４１】
所見１：開始狭帯域インデックスは、２０ＭＨｚなどの５ＭＨｚより大きいシステム帯域幅に対して使用される。
【０１４２】
我々は、スケジューリング柔軟性、ビットサイズおよび旧式ＵＥとの多重化の複雑度の面から３つの選択肢を論じる。
【０１４３】
選択肢−１：開始狭帯域インデックス＋ＮＢビットマップ＋既存の狭帯域内のリソース割当て
-選択肢−１は、ＮＢ内のリソース割当てがＮＢ毎の指示である場合、他の２つの方法より高いスケジューリング柔軟性を有する。しかしながら、ＮＢ内のリソース割当てがＮＢ毎に指示される場合、ＮＢの数＊ＮＢ毎のリソース割当てビットのように、オーバーヘッドビットが必要とされる。したがって、既存の狭帯域内のリソース割当ては、選択肢−１において限定されるべきである。例えば、ビットサイズを削減するために、既存の狭帯域内のリソース割当ては、ただ１つのＮＢ内でまたはＮＢ間で共通のリソース割当てを指示することができる。しかしながら、この限定は、スケジューリング柔軟性を低下させ、ＵＥ多重化のリソース割当てが制限されることになる。
【０１４４】
選択肢−２：開始狭帯域インデックス＋５ＭＨｚ広帯域内のＲＢＧのビットマップ
-選択肢−２は、選択肢−１以上のスケジューリング柔軟性を有する。さらに、選択肢−２は、ＮＢ内のリソース割当てを指示することができるので、旧式ＵＥと容易に多重化することができる。しかしながら、ビットサイズの見地から、選択肢−２のビットサイズは、選択肢−１より少し大きい。例えば、５ＭＨｚシステム帯域幅でＲＢＧサイズ＝２の場合、総ビットサイズは１２ビットである。ＲＢＧサイズ＝３の場合、総ビットサイズは、９ビットの選択肢−１より小さい８ビットまで減少する。
【０１４５】
選択肢−３：広帯域インデックス＋（局在型／分散型フラグを含む）広帯域内のリソース割当てタイプ２に基づいた分散型割当て
-選択肢−３は、リソース割当てタイプ２に基づいた分散型割当てをサポートする。上述のように、広帯域のスケジューリング柔軟性は、狭帯域インデックス指示より良くない。ＵＥ多重化複雑度の見地から、リソース割当てタイプ２は、ただ１つのギャップだけを作ることができる。したがって、リソース割当てタイプ２は、２つ以上の旧式のリソース割当てを回避することができない。加えるに、ＶＲＢの旧式のギャップ長は、システム帯域幅に応じた固定値である。ＦｅＭＴＣが分散型リソース割当てタイプ２を使用する場合、固定値は、より大きい最大帯域幅（すなわち５ＭＨｚ）に依存するべきである。この固定ギャップ長は、旧式ＵＥと多重化するのに適していない。したがって、選択肢−３を用いて旧式ＵＥと多重化することは、他の選択肢より難しい。我々がギャップ長の可変値をサポートするとしても、ギャップ指示のための追加のビットが必要になる。
【０１４６】
これらの選択肢の特徴の概要が下の表５に示される。スケジューリング柔軟性、ビットサイズおよび多重化を考慮に入れると、選択肢−２が最も合理的である。さらに、ＲＢＧサイズは２または３とすべきである。
【０１４７】
提案２：ＣＥモードＡにおけるＰＤＳＣＨに対して、開始狭帯域インデックス＋５ＭＨｚ広帯域内のＲＢＧのビットマップがサポートされるべきである。ＲＢＧサイズは２または３とすべきである。
【０１４８】
【表５】
2018143033.tif 000007
（表５  ＣＥモードＡにおけるＢＬ／ＣＥ  ＵＥを用いたＰＤＳＣＨに対する選択肢の特徴）
【０１４９】
＊１  既存の狭帯域内でただ１つのリソース割当てを指示する場合
（２．１．１．２．ＰＵＣＣＨ）
表４で示されるように、ＣＥモードＡにおけるＢＬ／ＣＥ  ＵＥは、５ＭＨｚ  ＰＵＳＣＨ伝送をサポートする。加えるに、ＲＡＮ１は、「より大きいＢＷを持つＦｅＭＴＣ  ＵＥに対するＰＵＳＣＨ割当ては、少なくとも、ＬＴＥリリース１３で規定される狭帯域の一部でない一定のＰＲＢを含み得る」ことを合意した。これは、連続的なリソース割当てのために５ＭＨｚシステム帯域幅におけるＵＬに対して２５ＰＲＢを使用してより低いＰＡＰＲを達成できることを意味する。したがって、ＰＵＳＣＨリソース割当ては、ＣＥモードＡにおけるＢＬ／ＣＥ  ＵＥに対して連続的なマッピングとするべきであり、連続的リソース割当てに対する次の５候補がＲＡＮ１  ８７でリストアップされた。
【０１５０】
ＲＡＮ１＃８７提案
−連続的リソース割当ては、ＣＥモードＡにおいて５ＭＨｚのより大きいチャネル帯域幅を持つＰＵＳＣＨに対してサポートされる。
【０１５１】
−選択肢Ａ：開始狭帯域インデックス（または広帯域インデックス）＋５ＭＨｚ広帯域内の既存のＰＵＳＣＨタイプ０
−選択肢Ｂ：既存のＰＵＳＣＨタイプ０（ＲＩＶ限定）
−選択肢Ｃ：開始ＲＢインデックス＋ＲＢの数
−選択肢Ｄ：開始狭帯域インデックス＋ＮＢの数
−選択肢Ｅ：開始ＮＢインデックス＋ＲＢの数
【０１５２】
初めに、ＲＩＶが限定された既存のＰＵＳＣＨタイプ０は、０から（システム帯域幅−１）まで変動する開始ＲＢ位置および２５ＰＲＢで限定される長さをＲＩＶが指示することを意味する。他方、選択肢−Ｃは、同様に、ビットサイズが最適化なしで選択肢−Ｂより大きい場合がある、開始ＲＢ位置および長さを指示することができる。最適化が適用される場合、ビットサイズは選択肢−Ｂと同じである。したがって、我々は、選択肢−Ｂおよび選択肢−Ｃが同じであると仮定し、今後、本節の残りで選択肢−Ｂだけを考慮する。
【０１５３】
上記の５つの選択肢の間でスケジューリング柔軟性を比較すると、開始点およびリソース割当ての粒度がＲＢ粒度に基づいているので、選択肢−Ｂが最も高いスケジューリング柔軟性を有する。選択肢−Ａおよび選択肢−Ｅは、リソース割当ての粒度に基づいてＮＢ開始点＋ＲＢを指示することができ、したがって、選択肢−Ａおよび選択肢−Ｅのスケジューリング柔軟性は、選択肢−Ｂより低い。選択肢−Ｄは、ＮＢに基づく粒度を有するので、スケジューリング柔軟性が最も低い。
【０１５４】
ＵＥの旧式ＵＥとの多重化の複雑度からは、すべての選択肢に問題がない。しかしながら、リソース利用からの相違がある。例えば、選択肢−Ｂは、同じＮＢで旧式ＵＥと多重化することができる。しかしながら、選択肢−Ｅは、開始ＮＢ内で旧式ＵＥと多重化することができない。選択肢−Ａは、開始ＮＢ内で旧式ＵＥと多重化するための制限がない一方、割当て可能なＲＢの数は、選択肢−Ｂと比較して減少することになる。選択肢−Ｄは、開始ＮＢのものでも終了ＮＢのものでもないリソース割当て内で旧式ＵＥと多重化することができる。
【０１５５】
より高いデータレートを考慮に入れると、ＣＥモードＡにおけるＢＬ／ＣＥ  ＵＥ  ＰＵＳＣＨに対して、選択肢−Ｂが最も好ましい。
【０１５６】
提案３：ＣＥモードＡにおけるＰＵＳＣＨに対して、既存のＰＵＳＣＨタイプ０がサポートされるべきである。
【０１５７】
【表６】
2018143033.tif 000008
（表６  ＣＥモードＡにおけるＢＬ／ＣＥ  ＵＥを用いたＰＵＳＣＨに対する選択肢の特徴）
【０１５８】
（２．１．２．ＰＤＳＣＨに対するＣＥモードＢ）
前の会合で、ＣＥモードＢに対するより大きい最大ＰＤＳＣＨがＲｅｌ−１４に採用され、５ＭＨｚ  ＰＤＳＣＨがサポートされている。ＰＤＳＣＨ  ＣＥモードＢに対して使用される旧式のＤＣＩ６−１Ｂに基づいたリソース割当てを考慮すると、多くの繰返しの場合リソース割当ては多くのスケジューリング柔軟性を必要としないので、ＤＣＩ６−１Ｂリソース割当ては、ＮＢインデックスの指示が期待される４ＰＲＢまたは６ＰＲＢを意味する１ビットだけを有する。加えるに、細かいリソース割当てがサポートされるときでも、スケジューリング利得は大きくないことになる。したがって、ビットサイズは、ＣＥモードＢに対する最も重要なファクタである。小さいビット長は、ＤＣＩ符号化レートを低く保つことができる。したがって、我々は、ＣＥモードＢにおけるＰＤＳＣＨに対して「開始ＮＢインデックス＋ＮＢビットマップ」を指示するようにサポートする。例えば、開始ＮＢインデックスおよびＮＢビットマップは、２０ＭＨｚシステム帯域幅に対して８ビット（４ビット＋４ビット）からなる。
【０１５９】
提案４：ＣＥモードＢにおけるＰＤＳＣＨに対して、開始ＮＢインデックス＋ＮＢビットマップがサポートされるべきである。
【０１６０】
（２．２．非ＢＬ  ＵＥに対するＲＢ割振り）
（２．２．１．ＣＥモードＡ）
（２．２．１．１．ＰＤＳＣＨ）
表４で示されるように、ＣＥモードＡにおける非ＢＬ  ＵＥは、５ＭＨｚおよび２０ＭＨｚをサポートすることができる。標準化努力の削減および複雑度の軽減を考慮すると、ＢＬ／ＣＥ  ＵＥと非ＢＬ  ＵＥとの間のＲＢ割振りの同じ方式が好ましい。したがって、我々は、「開始狭帯域インデックス＋ＲＢＧのビットマップ」をサポートする。しかしながら、非ＢＬ  ＵＥが２０ＭＨｚを受信するように構成されるとき、開始狭帯域インデックスは必要とされない。
【０１６１】
提案５：ＣＥモードＡにおける非ＢＬ  ＵＥのＰＤＳＣＨに対して、開始狭帯域インデックス＋ＲＢＧのビットマップがサポートされるべきである。非ＢＬ  ＵＥが２０ＭＨｚ  ＰＤＳＣＨを動作させる場合、開始狭帯域インデックスは除外されるべきである。
【０１６２】
（２．２．１．２．ＰＵＳＣＨ）
ＣＥモードＡにおける非ＢＬ  ＵＥに対するＰＵＳＣＨは、ＣＥモードＡにおけるＢＬ／ＣＥ  ＵＥ  ＰＵＳＣＨと同じ５ＭＨｚをサポートする。したがって、我々は、別の新しいリソース割当て方式をサポートする必要がない。我々は、既存のＰＵＳＣＨタイプ０である、同じ方式をサポートする。
【０１６３】
提案６：ＣＥモードＡで５ＭＨｚ  ＰＵＳＣＨを動作させる非ＢＬ  ＵＥに対して、既存のＰＵＳＣＨタイプ０がサポートされるべきである。
【０１６４】
（２．２．２．ＣＥモードＢ）
（２．２．２．１．ＰＤＳＣＨ）
ＣＥモードＢにおける非ＢＬ  ＵＥ  ＰＤＳＣＨに関して、ＵＥは、１．４ＭＨｚまたは５ＭＨｚまたは２０ＭＨｚに設定されることになる。標準化努力および複雑度の軽減を考慮に入れると、ＲＢ割振りの同じ方式が好ましい。１．４ＭＨｚチャネル帯域幅は、旧式のｅＭＴＣと同じである。したがって、旧式のリソース割当て方法（狭帯域インデックス＋１ビット）を再利用することができる。他方、５ＭＨｚおよび２０ＭＨｚに関して、リソース割当ては５ＭＨｚ  ＢＬ／ＣＥ  ＵＥに基づくべきであり、それは、開始ＮＢインデックス＋ＮＢビットマップがサポートされるべきであるということである。しかしながら、ＵＥが２０ＭＨｚに設定されるとき、ＢＬ／ＣＥ  ＵＥは、帯域幅全体を受信することができるので、開始ＮＢインデックスは必要でない。
【０１６５】
提案７：ＣＥモードＢにおけるＰＤＳＣＨに対するＲｅｌ−１３ｅＭＴＣのリソース割当て（狭帯域インデックスおよび１ビット）は、１．４ＭＨｚ帯域幅でＣＥモードＢにおける非ＢＬ  ＵＥ  ＰＤＳＣＨに対して再利用されるべきである。
【０１６６】
提案８：狭帯域インデックス＋ＮＢビットマップは、５ＭＨｚおよび２０ＭＨｚでＣＥモードＢにおける非ＢＬ  ＵＥ  ＰＤＳＣＨに対してサポートされるべきである。非ＢＬ  ＵＥが２０ＭＨｚ  ＰＤＳＣＨを動作させる場合、開始狭帯域インデックスは除外されるべきである。
【０１６７】
（２．２．２．２．ＰＵＳＣＨ）
ＣＥモードＢにおける非ＢＬ  ＵＥに対するＰＵＳＣＨは、Ｒｅｌ−１３ｅＭＴＣリソース割当ての帯域幅と同じ１．４ＭＨｚをサポートする。したがって、我々は、別の新しいリソース割当て方式をサポートする必要がない。我々は、狭帯域インデックス＋３ビットである、同じ方式をサポートする。
【０１６８】
提案９：ＣＥモードＢにおけるＰＵＳＣＨに対するＲｅｌ−１３ｅＭＴＣのリソース割当て（狭帯域インデックスおよび３ビット）は、１．４ＭＨｚ帯域幅でＣＥモードＢにおける非ＢＬ  ＵＥ  ＰＵＳＣＨに対して再利用されるべきである。
【０１６９】
米国仮出願第６２／４５４１９３号（２０１７年２月３日出願）の全内容が、参照により、本願明細書に組み込まれている。
【産業上の利用可能性】
【０１７０】
本発明は移動通信分野において有用である。
【図１】
2018143033.tif 000009
【図２】
2018143033.tif 000010
【図３】
2018143033.tif 000011
【図４】
2018143033.tif 000012
【図５】
2018143033.tif 000013
【図６】
2018143033.tif 000014
【図７】
2018143033.tif 000015
【図８】
2018143033.tif 000016
【図９】
2018143033.tif 000017
【図１０】
2018143033.tif 000018
【図１１】
2018143033.tif 000019
【図１２】
2018143033.tif 000020
【図１３】
2018143033.tif 000021
【図１４】
2018143033.tif 000022
【図１５】
2018143033.tif 000023
【図１６】
2018143033.tif 000024
【国際調査報告】
2018143033.tif 000025
2018143033.tif 000026