(57)【特許請求の範囲】
【請求項１】
ユーザ装置であって、
コントローラを備え、
前記コントローラは、
送信時間間隔が１サブフレームよりも短い第１物理下りリンク共有チャネル（ＰＤＳＣＨ）により基地局から送信される第１データの受信を試み、
送信時間間隔が１サブフレームである第２ＰＤＳＣＨにより前記基地局から送信される第２データの受信を試み、
前記基地局から制御情報を受信し、
前記制御情報に基づいて、前記第１データの再送を要求するか否かについての第１ハイブリッド自動再送要求（ＨＡＲＱ）フィードバックと前記第２データの再送を要求するか否かについての第２ＨＡＲＱフィードバックとをまとめて、前記基地局へ通知し、
前記制御情報は、前記第１ＨＡＲＱフィードバックと前記第２ＨＡＲＱフィードバックとをまとめて通知するタイミングと、前記第１ＨＡＲＱフィードバックと前記第２ＨＡＲＱフィードバックとを通知する際における前記第１ＨＡＲＱフィードバックと前記第２ＨＡＲＱフィードバックとの順番とを指定する
ユーザ装置。
【請求項２】
ユーザ装置に用いられる方法であって、
送信時間間隔が１サブフレームよりも短い第１物理下りリンク共有チャネル（ＰＤＳＣＨ）により基地局から送信される第１データの受信を試みるステップと、
送信時間間隔が１サブフレームである第２ＰＤＳＣＨにより前記基地局から送信される第２データの受信を試みるステップと
前記基地局から制御情報を受信するステップと、
前記制御情報に基づいて、前記第１データの再送を要求するか否かについての第１ハイブリッド自動再送要求（ＨＡＲＱ）フィードバックと前記第２データの再送を要求するか否かについての第２ＨＡＲＱフィードバックとをまとめて、前記基地局へ通知するステップと、を有し、
前記制御情報は、前記第１ＨＡＲＱフィードバックと前記第２ＨＡＲＱフィードバックとをまとめて通知するタイミングと、前記第１ＨＡＲＱフィードバックと前記第２ＨＡＲＱフィードバックとを通知する際における前記第１ＨＡＲＱフィードバックと前記第２ＨＡＲＱフィードバックとの順番とを指定する
方法。
【請求項３】
ユーザ装置を制御するプロセッサであって、
前記プロセッサは、
送信時間間隔が１サブフレームよりも短い第１物理下りリンク共有チャネル（ＰＤＳＣＨ）により基地局から送信される第１データの受信を試みる処理と、
送信時間間隔が１サブフレームである第２ＰＤＳＣＨにより前記基地局から送信される第２データの受信を試みる処理と、
前記基地局から制御情報を受信する処理と、
前記制御情報に基づいて、前記第１データの再送を要求するか否かについての第１ハイブリッド自動再送要求（ＨＡＲＱ）フィードバックと前記第２データの再送を要求するか否かについての第２ＨＡＲＱフィードバックとをまとめて、前記基地局へ通知する処理と、を実行し、
前記制御情報は、前記第１ＨＡＲＱフィードバックと前記第２ＨＡＲＱフィードバックとをまとめて通知するタイミングと、前記第１ＨＡＲＱフィードバックと前記第２ＨＡＲＱフィードバックとを通知する際における前記第１ＨＡＲＱフィードバックと前記第２ＨＡＲＱフィードバックとの順番とを指定する
プロセッサ。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、無線通信装置に関する。
【背景技術】
【０００２】
移動通信システムの標準化プロジェクトである３ＧＰＰ（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）により規定されたＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）システムでは、物理下りリンク共有チャネル（ＰＤＳＣＨ：Ｐｈｙｓｉｃａｌ  Ｄｏｗｎｌｉｎｋ  Ｓｈａｒｅｄ  ＣＨａｎｎｅｌ）を用いて、基地局からユーザ端末へデータが伝送される（非特許文献１参照）。【０００３】
近年、下りリンクデータの遅延時間を低減させるために、物理下りリンク共有チャネルよりも送信時間間隔が短いショート物理下りリンク共有チャネル（ｓＰＤＣＣＨ：ｓｈｏｒｔ−ＰＤＣＣＨ）に関する仕様策定が進められている。ショート物理下りリンク共有チャネルを用いることにより、データの送信遅延を低減できる。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】３ＧＰＰ技術仕様書「ＴＳ３６．３００  Ｖ１４．１．０」  ２０１６年１２月３０日
【発明の概要】
【０００５】
一の実施形態に係る第１の無線通信装置は、コントローラを備える。前記コントローラは、第１の物理チャネルにより第２の無線通信装置から送信される第１の情報の受信を試み、前記第１の物理チャネルよりも送信時間間隔が短い第２の物理チャネルにより前記第２の無線通信装置から送信される第２の情報の受信を試み、かつ、前記第１情報の再送を要求するか否かについての第１の結果と前記第２情報の再送を要求するか否かについての第２の結果とをまとめて、前記第２の無線通信装置へ通知する、よう構成される。
【０００６】
一の実施形態に係る第１の無線通信装置は、コントローラを備える。前記コントローラは、制御領域、データ領域、ショート制御領域、及びショートデータ領域のモニタを制御するよう構成される。前記ショート制御領域は、前記制御領域よりも短い時間間隔で配置される。前記ショートデータ領域は、前記データ領域よりも短い時間間隔で配置される。前記コントローラは、前記ショート制御領域をモニタするかどうかを判定するために用いられる制御情報を第２の無線通信装置から受信し、かつ、前記制御情報に基づいて、前記ショート制御領域をモニタするかどうかを判定するよう構成される。前記制御情報は、第１の制御領域から前記第１の制御領域の次に配置される第２の制御領域までの間に配置される複数のショート制御領域のうち、一部のショート制御領域をモニタするかどうかを判定するために用いられる。
【０００７】
一の実施形態に係る第１の無線通信装置は、コントローラを備える。前記コントローラは、制御領域、データ領域、ショート制御領域、及びショートデータ領域のモニタを制御するよう構成される。前記ショート制御領域は、前記制御領域よりも短い時間間隔で配置される。前記ショートデータ領域は、前記データ領域よりも短い時間間隔で配置される。前記コントローラは、第２の無線通信装置との通信を実行に応じて、前記ショート制御領域をモニタするかどうかを判定するためのタイマをスタートし、前記タイマが起動している間、前記ショート制御領域のモニタを実行し、かつ、前記タイマの満了に応じて、前記ショート制御領域のモニタを終了する。
【図面の簡単な説明】
【０００８】
【図１】図１は、移動通信システムの構成を示す図である。
【図２】図２は、無線インターフェイスのプロトコルスタック図である。
【図３】図３は、無線フレームの構成図である。
【図４】図４は、ｓＰＤＳＣＨを説明するための図である。
【図５】図５は、ｓＰＵＳＣＨを説明するための図である。
【図６】図６は、ｓＤＣＩの一例を説明するための図である。
【図７】図７は、ｓＤＣＩの一例を説明するための図である。
【図８】図８は、ｓＤＣＩの一例を説明するための図である。
【図９】図９は、ｓＤＣＩの一例を説明するための図である。
【図１０】図１０は、ＵＥ１００のブロック図である。
【図１１】図１１は、ＢＳ２００のブロック図である。
【図１２】図１２は、第１実施形態に係る動作（動作パターン１−１）を説明するためのシーケンス図である。
【図１３】図１３は、第１実施形態に係る動作（動作パターン１−１）を説明するための図である。
【図１４】図１４は、第１実施形態に係る動作（動作パターン１−２）を説明するためのシーケンス図である。
【図１５】図１５は、第１実施形態に係る動作（動作パターン１−２）を説明するための図である。
【図１６】図１６は、第２実施形態に係る動作（動作パターン２−１）を説明するためのシーケンス図である。
【図１７】図１７は、第２実施形態に係る動作（動作パターン２−１）を説明するためのフローチャートである。
【図１８】図１８は、第２実施形態に係る動作（動作パターン２−１）を説明するための図である。
【図１９】図１９は、第２実施形態に係る動作（動作パターン２−２）を説明するためのフローチャートである。
【発明を実施するための形態】
【０００９】
［実施形態の概要］
一の実施形態に係る第１の無線通信装置は、コントローラを備える。前記コントローラは、第１の物理チャネルにより第２の無線通信装置から送信される第１の情報の受信を試み、前記第１の物理チャネルよりも送信時間間隔が短い第２の物理チャネルにより前記第２の無線通信装置から送信される第２の情報の受信を試み、かつ、前記第１情報の再送を要求するか否かについての第１の結果と前記第２情報の再送を要求するか否かについての第２の結果とをまとめて、前記第２の無線通信装置へ通知する、よう構成される。
【００１０】
前記コントローラは、前記第２の無線通信装置から制御情報を受信するよう構成されてもよい。前記制御情報は、前記前記第１の結果と前記第２の結果とをまとめて通知するタイミングを指定してもよい。
【００１１】
前記コントローラは、前記第２の無線通信装置から制御情報を受信するよう構成されてもよい。前記制御情報は、前記第１の情報の受信タイミングと前記第２の情報の受信タイミングとの組み合わせを指定してもよい。
【００１２】
前記コントローラは、前記第２の無線通信装置から制御情報を受信するよう構成されてもよい。前記制御情報は、前記第１の結果と前記第２の結果とを通知する際における前記第１の結果と前記第２の結果との順番を指定してもよい。
【００１３】
一の実施形態に係る第１の無線通信装置は、コントローラを備える。前記コントローラは、制御領域、データ領域、ショート制御領域、及びショートデータ領域のモニタを制御するよう構成される。前記ショート制御領域は、前記制御領域よりも短い時間間隔で配置される。前記ショートデータ領域は、前記データ領域よりも短い時間間隔で配置される。前記コントローラは、前記ショート制御領域をモニタするかどうかを判定するために用いられる制御情報を第２の無線通信装置から受信し、かつ、前記制御情報に基づいて、前記ショート制御領域をモニタするかどうかを判定するよう構成される。前記制御情報は、第１の制御領域から前記第１の制御領域の次に配置される第２の制御領域までの間に配置される複数のショート制御領域のうち、一部のショート制御領域をモニタするかどうかを判定するために用いられる。
【００１４】
前記制御情報は、モニタすべき一部のショート制御領域、モニタを開始すべきショート制御領域、及び、前記モニタすべき一部のショート制御領域が含まれる期間、の少なくともいずれかを示してもよい。
【００１５】
前記制御情報は、前記ショートデータ領域においてデータの送信に用いられる時間・周波数リソースを指定するために用いられるショート制御情報であってもよい。
【００１６】
前記コントローラは、前記ショート制御情報のサイズに応じて、前記ショート制御領域をモニタするかどうかを判定するよう構成されてもよい。
【００１７】
前記コントローラは、閾値を示す情報を前記第２の無線通信装置から受信し、かつ、前記ショート制御情報のサイズと前記閾値との比較によって、前記ショート制御領域をモニタするかどうかを判定するよう構成されてもよい。
【００１８】
前記コントローラは、前記ショート制御領域をモニタするかどうかを判定するためのタイマを起動し、かつ、前記制御情報に基づいて、一部のショート制御領域をモニタしないと判定した場合であっても、前記タイマが満了するまで前記ショート制御領域のモニタを実行するよう構成されてもよい。
【００１９】
一の実施形態に係る第１の無線通信装置は、コントローラを備える。前記コントローラは、制御領域、データ領域、ショート制御領域、及びショートデータ領域のモニタを制御するよう構成される。前記ショート制御領域は、前記制御領域よりも短い時間間隔で配置される。前記ショートデータ領域は、前記データ領域よりも短い時間間隔で配置される。前記コントローラは、第２の無線通信装置との通信を実行に応じて、前記ショート制御領域をモニタするかどうかを判定するためのタイマをスタートし、前記タイマが起動している間、前記ショート制御領域のモニタを実行し、かつ、前記タイマの満了に応じて、前記ショート制御領域のモニタを終了する。
【００２０】
前記コントローラは、スケジューリング要求を前記第２の無線通信装置へ送信したことに応じて、前記タイマをスタートするよう構成されてもよい。
【００２１】
前記コントローラは、上りリンクにおけるショートデータ領域において情報を送信したことに応じて、前記タイマをスタートするよう構成されてもよい。
【００２２】
前記コントローラは、下りリンクにおけるショートデータ領域において情報を受信したことに応じて、前記タイマをスタートするよう構成されてもよい。
【００２３】
［実施形態］
（移動通信システム）
以下において、移動通信システムについて説明する。図１は、移動通信システムの構成を示す図である。移動通信システムの一例として、ＬＴＥシステムを例に挙げて説明する。
【００２４】
図１に示すように、ＬＴＥシステムは、ＵＥ（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）１００、Ｅ−ＵＴＲＡＮ（Ｅｖｏｌｖｅｄ  Ｕｎｉｖｅｒｓａｌ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）１０、及びＥＰＣ（Ｅｖｏｌｖｅｄ  Ｐａｃｋｅｔ  Ｃｏｒｅ）２０を備える。
【００２５】
ＵＥ１００は、無線通信装置（無線端末）に相当する。ＵＥ１００は、移動型の通信装置である。ＵＥ１００は、セル（後述するＢＳ２００）と無線通信を行う。ＵＥ１００の構成は後述する。
【００２６】
Ｅ−ＵＴＲＡＮ１０は、無線アクセスネットワークに相当する。Ｅ−ＵＴＲＡＮ１０は、ＢＳ（ＢＡＳＥ  ＳＴＡＴＩＯＮ）２００を含む。ＢＳ２００は、基地局に相当する。ＢＳ２００は、例えば、ｅＮＢ２００（ｅｖｏｌｖｅｄ  Ｎｏｄｅ−Ｂ）である。ＢＳ２００は、ＵＥ１００と無線通信を実行可能なノードであってもよい。例えば、ＢＳ２００は、ｇＮＢ（ｎｅｘｔ  Ｇｅｎｅｒａｔｉｏｎ  Ｎｏｄｅ−Ｂ）であってもよい。ＢＳ２００は、Ｘ２インターフェイスを介して相互に接続されてもよい。ＢＳ２００の構成は後述する。
【００２７】
ＢＳ２００は、１又は複数のセルを管理する。ＢＳ２００は、ＢＳ２００が管理するセルとの接続を確立したＵＥ１００との無線通信を行う。ＢＳ２００は、無線リソース管理（ＲＲＭ）機能、ユーザデータ（以下、「データ」と称することがある）のルーティング機能、モビリティ制御・スケジューリングのための測定制御機能等を有する。
【００２８】
「セル」は、無線通信エリアの最小単位を示す用語として使用される。「セル」は、ＵＥ１００との無線通信を行う機能を示す用語としても使用されてもよい。「セル」は、下りリンクリソースであってもよく、下りリンクリソースと上りリンクリソースとの組み合わせであってもよい。下りリソースのキャリア周波数と上りリソースのキャリア周波数との間のリンクは、下りリソース上で送信されるシステム情報に含まれてもよい。
【００２９】
ＥＰＣ２０は、コアネットワークに相当する。ＥＰＣ２０は、Ｅ−ＵＴＲＡＮ１０と共にネットワークを構成してもよい。ＥＰＣ２０は、ＭＭＥ（Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ）３００、及びＳＧＷ（Ｓｅｒｖｉｎｇ  Ｇａｔｅｗａｙ）４００を含む。
【００３０】
ＭＭＥ３００は、例えば、ＵＥ１００に対する各種モビリティ制御を行う。ＳＧＷ４００は、例えば、データの転送制御を行う。ＭＭＥ３００及びＳＧＷ４００は、Ｓ１インターフェイスを介してＢＳ２００と接続される。
【００３１】
図２は、ＬＴＥシステムにおける無線インターフェイスのプロトコルスタック図である。図２に示すように、無線インターフェイスプロトコルは、ＯＳＩ参照モデルの第１層（レイヤ１）乃至第３層（レイヤ３）に区分されている。第１層は、物理（ＰＨＹ）層（物理レイヤ）である。第２層（レイヤ２）は、ＭＡＣ（Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）層（ＭＡＣレイヤ）、ＲＬＣ（Ｒａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ）層（ＲＬＣレイヤ）、及びＰＤＣＰ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｃｏｎｖｅｒｇｅｎｃｅ  Ｐｒｏｔｏｃｏｌ）層（ＰＲＣＰレイヤ）を含む。第３層（レイヤ３）は、ＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）層（ＲＲＣレイヤ）を含む。
【００３２】
物理レイヤは、符号化・復号化、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行う。ＵＥ１００の物理レイヤとＢＳ２００の物理レイヤとの間では、物理チャネルを介してデータ及び制御信号が伝送される。
【００３３】
ＭＡＣレイヤは、データの優先制御、ハイブリッドＡＲＱ（ＨＡＲＱ：Ｈｙｂｒｉｄ  Ａｕｔｏｍａｔｉｃ  Ｒｅｐｅａｔ  Ｒｅｑｕｅｓｔ）による再送処理、及びランダムアクセス手順等を行う。ＵＥ１００のＭＡＣレイヤとＢＳ２００のＭＡＣレイヤとの間では、トランスポートチャネルを介してデータ及び制御信号が伝送される。ＢＳ２００のＭＡＣレイヤは、スケジューラ（ＭＡＣ  スケジューラ）を含む。スケジューラは、上下リンクのトランスポートフォーマット（トランスポートブロックサイズ、変調・符号化方式（ＭＣＳ：Ｍｏｄｕｌａｔｉｏｎ  ａｎｄ  Ｃｏｄｉｎｇ  Ｓｃｈｅｍｅ））及びＵＥ１００への割当リソースブロックを決定する。
【００３４】
ＲＬＣレイヤは、ＭＡＣレイヤ及び物理レイヤの機能を利用してデータを受信側のＲＬＣレイヤに伝送する。ＵＥ１００のＲＬＣレイヤとＢＳ２００のＲＬＣレイヤとの間では、論理チャネルを介してデータ及び制御信号が伝送される。
【００３５】
ＰＤＣＰレイヤは、ヘッダ圧縮・伸張、及び暗号化（サイファリング）・復号化（デサイファリング）を行う。
【００３６】
ＲＲＣレイヤは、制御信号を取り扱う制御プレーンでのみ定義される。ＵＥ１００のＲＲＣレイヤとＢＳ２００のＲＲＣレイヤとの間では、各種設定のためのメッセージ（ＲＲＣメッセージ）が伝送される。ＲＲＣレイヤは、無線ベアラの確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。ＵＥ１００のＲＲＣとＢＳ２００のＲＲＣとの間にＲＲＣ接続がある場合、ＵＥ１００は、ＲＲＣコネクティッド状態である。ＵＥ１００のＲＲＣとＢＳ２００のＲＲＣとの間にＲＲＣ接続がない場合、ＵＥ１００は、ＲＲＣアイドル状態である。
【００３７】
ＲＲＣレイヤの上位に位置するＮＡＳ（Ｎｏｎ−Ａｃｃｅｓｓ  Ｓｔｒａｔｕｍ）レイヤは、例えば、セッション管理及びモビリティ管理を行う。
【００３８】
（無線フレーム構成）
図３は、無線フレームの構成図である。ＬＴＥシステムでは、下りリンクにＯＦＤＭＡ（Ｏｒｔｈｏｇｏｎａｌ  Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅｘｉｎｇ  Ａｃｃｅｓｓ）が適用される。上りリンクにはＳＣ−ＦＤＭＡ（Ｓｉｎｇｌｅ  Ｃａｒｒｉｅｒ  Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ）が適用される。
【００３９】
図３に示すように、無線フレームは、時間方向に並ぶ１０個のサブフレームで構成される。各サブフレームは、時間方向に並ぶ２個のスロットで構成される。各サブフレームの長さは１ｍｓである。各スロットの長さは０．５ｍｓである。各サブフレームは、周波数方向に複数個のリソースブロック（ＲＢ）を含む。各サブフレームは、時間方向に複数個のシンボルを含む。各リソースブロックは、周波数方向に複数個のサブキャリアを含む。１つのサブキャリア及び１つのシンボルによりリソースエレメント（ＲＥ）が構成される。
【００４０】
下りリンクにおいて、各サブフレームの先頭数シンボルの区間は、主に物理下りリンク制御チャネル（ＰＤＣＣＨ）として使用できる制御領域である。各サブフレームの残りの区間は、主に物理下りリンク共有チャネル（ＰＤＳＣＨ）として使用できる領域である。下りリンクにおいて、各サブフレームには、セル固有参照信号などの参照信号が分散して配置される。
【００４１】
上りリンクにおいて、各サブフレームにおける周波数方向の両端部は、主に物理上りリンク制御チャネル（ＰＵＣＣＨ）として使用される制御領域である。各サブフレームにおける周波数方向の中央部は、主に物理上りリンク共有チャネル（ＰＵＳＣＨ）として使用できる領域である。
【００４２】
（物理チャネル）
物理下りリンク制御チャネル（ＰＤＣＣＨ）は、下り制御情報を運搬するために用いられる。ＰＤＣＣＨは、ＰＤＳＣＨ（下りリンク共有チャネル（ＤＬ−ＳＣＨ）、ページングチャネル（ＰＣＨ））のリソース割り当て情報及びＤＬ−ＳＣＨに関するＨＡＲＱ情報（ＡＣＫ／ＮＡＣＫ）をＵＥ１００に知らせてもよい。ＰＤＣＣＨは、上りリンクスケジューリンググラントを運搬してもよい。ＰＤＣＣＨは、サイドリンクスケジューリンググラントを運搬してもよい。
【００４３】
物理下りリンク共有チャネル（ＰＤＳＣＨ）は、ユーザデータ及び制御情報を運搬するために用いられる。ＰＤＳＣＨは、ＤＬ−ＳＣＨ及びＰＣＨを運搬してもよい。
【００４４】
ショート物理下りリンク制御チャネル（ｓＰＤＣＣＨ：ｓｈｏｒｔ  ＰＤＣＣＨ）は、制御情報を運搬するために用いられる。ｓＰＤＣＣＨは、ＰＤＣＣＨと同じ種類の情報を運搬してもよい。制御情報は、例えば、後述するショート下り制御情報（ｓＤＣＩ：ｓｈｏｒｔ  Ｄｏｗｎｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｉｎｆｏｒｍａｔｉｏｎ）である。ｓＰＤＣＣＨは、ＰＤＣＣＨよりも送信時間間隔（ＴＴＩ：Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｔｉｍｅ  Ｉｎｔｅｒｖａｌ）が短くてもよい。
【００４５】
ＰＤＣＣＨは、システム帯域全体で送信されるのに対し、ｓＰＤＣＣＨは、システム帯域全体で送信されなくてもよい。ｓＰＤＣＣＨは、システム帯域の一部で送信されてもよい。
【００４６】
ショート物理下りリンク共有チャネル（ｓＰＤＳＣＨ：ｓｈｏｒｔ  ＰＤＳＣＨ）は、ユーザデータ及び制御情報を運搬するために用いられる。ｓＰＤＳＣＨは、ＰＤＳＣＨと同じ種類の情報を運搬してもよい。ｓＰＤＳＣＨは、ＰＤＳＣＨよりもＴＴＩが短くてもよい。
【００４７】
ＰＤＳＣＨ（及びＰＤＣＣＨ）のＴＴＩは、１サブフレームである。一方、ｓＰＤＳＣＨ（及びｓＰＤＣＣＨ）の送信時間間隔（ｓＴＴＩ）は、例えば、７シンボル（１スロット）であってもよい。この場合、１サブフレームは、２ｓＴＴＩで表される。ｓＰＤＳＣＨ（及びｓＰＤＣＣＨ）のｓＴＴＩは、２シンボル又は３シンボルであってもよい（図４参照）。この場合、１サブフレームは、６ｓＴＴＩで表される。
【００４８】
物理上りリンク制御チャネル（ＰＵＣＣＨ）は、制御情報を運搬するために用いられる。ＰＵＣＣＨは、下り送信に応じたＨＡＲＱ情報（ＡＣＫ（Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）／ＮＡＣＫ（Ｎｅｇａｔｉｖｅ  Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ））を運搬してもよい。ＰＵＣＣＨは、スケジューリング要求（ＳＲ）を運搬してもよい。ＰＵＣＣＨは、ＣＳＩ（Ｃｈａｎｎｅｌ  Ｓｔａｔｅ  Ｉｎｆｏｒｍａｔｉｏｎ）報告を運搬してもよい。
【００４９】
物理上りリンク共有チャネル（ＰＵＳＣＨ）は、ユーザデータ及び制御情報を運搬するために用いられる。ＰＵＳＣＨは、上りリンク共有チャネル（ＵＬ−ＳＣＨ））を運搬してもよい。
【００５０】
ショート物理上りリンク制御チャネル（ｓＰＵＣＣＨ：ｓｈｏｒｔ  ＰＵＣＣＨ）は、制御情報を運搬するために用いられる。ｓＰＵＣＣＨは、ＰＵＣＣＨと同じ種類の情報を運搬してもよい。ｓＰＵＣＣＨは、ＰＵＣＣＨよりもＴＴＩが短くてもよい。
【００５１】
ショート物理上りリンク共有チャネル（ｓＰＵＳＣＨ：ｓｈｏｒｔ  ＰＵＳＣＨ）は、ユーザデータ及び上り制御情報を運搬するために用いられる。ｓＰＵＳＣＨは、ＰＵＳＣＨと同じ種類の情報を運搬してもよい。ｓＰＵＳＣＨは、ＰＵＳＣＨよりもＴＴＩが短くてもよい。
【００５２】
ＰＵＳＣＨ（及びＰＵＣＣＨ）のＴＴＩは、１サブフレームである。一方、ｓＰＵＳＣＨ（及びｓＰＵＣＣＨ）の送信時間間隔（ｓＴＴＩ）は、例えば、７シンボル（１スロット）であってもよい（図５（Ａ）参照）。この場合、１サブフレームは、２ｓＴＴＩで表される。ｓＰＵＳＣＨ（及びｓＰＵＣＣＨ）のｓＴＴＩは、４シンボルであってもよい（図５（Ｂ）参照）。この場合、１サブフレームは、４ｓＴＴＩで表される。ｓＰＵＳＣＨ（及びｓＰＵＣＣＨ）のｓＴＴＩは、２シンボル又は３シンボルであってもよい（図５（ｃ）参照）。この場合、１サブフレームは、６ｓＴＴＩで表される。
【００５３】
各スロットの先頭から４番目のシンボルは、復調参照信号（ＤＭＲＳ：Ｄｅｍｏｄｕｌａｔｉｏｎ  Ｒｅｆｅｒｅｎｃｅ  ｓｉｇｎａｌ）を送信するためのシンボルであってもよい。１サブフレームは、４ｓＴＴＩで表される場合、ＤＭＲＳは、２つの送信時間間隔（ｓＴＴＩ）間で共有される。
【００５４】
下りリンクのｓＴＴＩが７シンボルである場合、上りリンクのｓＴＴＩが７シンボルであってもよい。下りリンクのｓＴＴＩが２シンボル（又は３シンボル）である場合、上りリンクのｓＴＴＩが２シンボル（又は３シンボル）であってもよい。下りリンクのｓＴＴＩが２シンボル（又は３シンボル）である場合、上りリンクのｓＴＴＩが７シンボルであってもよい。下りリンクのｓＴＴＩと上りリンクのｓＴＴＩとの組み合わせは、その他のシンボルの組み合わせであってもよい。
【００５５】
ＵＥ１００（コントローラ）は、ＰＵＣＣＨ、ＰＵＳＣＨ、ｓＰＵＣＣＨ、及びｓＰＵＳＣＨのモニタを制御するように構成される。
【００５６】
（ショート下り制御情報）
ショート下り制御情報（ｓＤＣＩ：ｓｈｏｒｔＤＣＩ）の一例について、図６−図９を用いて説明する。図６−図９は、ショート下り制御情報の一例を説明するための図である。
【００５７】
ＰＤＣＣＨが送信される領域は、制御領域（以下、ＰＤＣＣＨ領域）である。ＰＤＳＣＨが送信される領域は、データ領域（以下、ＰＤＳＣＨ領域）である。ｓＰＤＣＣＨが送信される領域は、ショート制御領域（以下、ｓＰＤＣＣＨ領域）である。ｓＰＤＳＣＨが送信される領域は、ショートデータ領域（以下、ｓＰＤＳＣＨ領域）である。
【００５８】
ｓＰＤＣＣＨ領域は、ＰＤＣＣＨよりも短い時間間隔で配置される。これにより、ｓＰＤＣＣＨの送信時間間隔は、ＰＤＣＣＨの送信時間間隔よりも短い。時間方向において、第１のＰＤＣＣＨ領域から第１のＰＤＣＣＨ領域の次に配置される第２のＰＤＣＣＨ領域までの間に複数のｓＰＤＣＣＨ領域が配置される。
【００５９】
ｓＰＤＳＣＨ領域は、ＰＤＳＣＨよりも短い時間間隔で配置される。これにより、ｓＰＤＳＣＨの送信時間間隔は、ＰＤＳＣＨの送信時間間隔よりも短い。ｓＰＤＣＣＨ領域と同様に、時間方向において、第１のＰＤＣＣＨ領域から第２のＰＤＣＣＨ領域までの間に複数のｓＰＤＳＣＨ領域が配置される。時間方向におけるｓＰＤＳＣＨ領域の幅は、ｓＴＴＩと同じであってもよい。
【００６０】
ｓＰＤＣＣＨ領域は、（レガシーＵＥのための）ＰＤＣＣＨ領域と重複してもよい。１サブフレーム中の最初のｓＰＤＣＣＨ領域は、ＰＤＣＣＨ領域と重複してもよい。ｓＰＤＣＣＨ領域及びｓＰＤＳＣＨ領域は、（レガシーＵＥのための）ＰＤＳＣＨ領域と重複してもよい。１サブフレーム中の２番目以降のｓＰＤＣＣＨ領域は、ＰＤＳＣＨ領域と重複してもよい。
【００６１】
ｓＰＤＣＣＨ領域では、ショート下り制御情報（ｓＤＣＩ）がｓＰＤＣＣＨを介して送信される。ｓＤＣＩは、ショートデータ領域（ｓＰＤＳＣＨ領域）で情報（ユーザデータ及び／又は制御情報）が送信される時間・周波数リソースを指定するために用いられる。ｓＤＣＩは、ｓＰＤＳＣＨ領域における時間・周波数リソースを指定するための情報（リソース割り当て情報）を含むことができる。リソース割り当て情報は、時間及び／又は周波数リソースを示す情報である。ｓＤＣＩは、リソース割り当て情報を含むスケジューリング情報を含んでいてもよい。「時間・周波数リソース」は、ｓＰＤＳＣＨを受信するためにＵＥ１００がサーチすべきスペースを領域（時間及び／又は周波数領域）であってもよい。
【００６２】
ｓＤＣＩ（又はスケジューリング情報）は、その他の情報を含んでいてもよい。例えば、ｓＤＣＩ（又はスケジューリング情報）は、ＭＣＳ情報、ＲＶ（Ｒｅｄｕｎｄａｎｃｙ  Ｖｅｒｓｉｏｎ）情報、ＨＡＲＱ  ＩＤ情報、及びＤＣＩフォーマット情報の少なくともいずれかを含んでいてもよい。ＢＳ２００は、その他の情報をＵＥ１００へ通知する場合には、ｓＤＣＩ（又はスケジューリング情報）にリソース割り当て情報を含めなくてもよい。すなわち、ｓＤＣＩ（又はスケジューリング情報）は、リソース割り当て情報以外のその他の情報のみを含んでいてもよい。ｓＤＣＩが時間・周波数リソースを指定しないケースであっても、後述する動作が実行されてもよい。
【００６３】
ｓＤＣＩは、ＵＥ固有の情報（ＵＥ  ｓｐｅｃｉｆｉｃ）であってもよい。例えば、ｓＤＣＩは、セル内のＵＥ１００のうち、所定のＵＥに向けた情報であってもよい。ｓＤＣＩは、ＵＥ共通の情報（ｎｏｎ−ＵＥ  ｓｐｅｃｉｆｉｃ）であってもよい。例えば、セル内の全ＵＥに向けた情報であってもよい。
【００６４】
以下、ｓＤＣＩの送信方法の一例について説明する。各ケースは、適宜組み合わされてもよい。同一の内容についての説明は省略する。
【００６５】
（Ａ）第１のケース
図６に示すように、ｓＤＣＩは、所定のｓＰＤＣＣＨ領域に対応する所定のｓＰＤＳＣＨ領域における時間・周波数リソースを指定するための第１のｓＤＣＩ（Ｆａｓｔ  ＤＣＩ）であってもよい。
【００６６】
例えば、最初のｓＰＤＣＣＨ領域と最初のｓＰＤＳＣＨ領域とが対応付けられている。最初のｓＰＤＣＣＨの後に配置される第２のｓＰＤＣＣＨ領域と、最初のｓＰＤＳＣＨ領域の直後に配置される第２のｓＰＤＳＣＨ領域とが対応付けられている。他のｓＰＤＣＣＨ領域及び他のｓＰＤＳＣＨ領域も同様である。２番目以降のｓＰＤＣＣＨ領域は、対応するｓＰＤＳＣＨ領域と時間方向において重複してもよい。最初のｓＰＤＣＣＨ領域は、対応するｓＰＤＳＣＨ領域と時間方向において重複しなくてもよい。
【００６７】
第１のｓＰＤＣＣＨ領域においてｓＰＤＣＣＨを介して送信される第１のｓＤＣＩは、第１のｓＰＤＳＣＨ領域においてｓＰＤＳＣＨを介して送信される情報の時間・周波数リソースを示す。同様に、第２のｓＰＤＣＣＨ領域においてｓＰＤＣＣＨを介して送信される第１のｓＤＣＩは、第２のｓＰＤＳＣＨ領域においてｓＰＤＳＣＨを介して送信される情報の時間・周波数リソースを示す。
【００６８】
第１のｓＤＣＩは、ＰＤＣＣＨ領域で送信されてもよい。この場合において、第１のｓＤＣＩは、ｓＰＤＣＣＨを介して送信されてもよい。第１のｓＤＣＩは、ＰＤＣＣＨを介して送信されてもよい。
【００６９】
第１のｓＤＣＩは、ＵＥ個別の情報であってもよい。例えば、第２の（及び第３の）ｓＰＤＣＣＨ領域でｓＰＤＣＣＨを介してＵＥ  Ａへ送信される第１のｓＤＣＩは、第２の（及び第３の）ｓＰＤＳＣＨ領域でｓＰＤＳＣＨを介してＵＥ  Ａへ送信される情報の時間・周波数リソースを示してもよい。第４の（及び第５の）ｓＰＤＣＣＨ領域でｓＰＤＣＣＨを介してＵＥ  Ｂへ送信される第１のｓＤＣＩは、第４の（及び第５の）ｓＰＤＳＣＨ領域でｓＰＤＳＣＨを介してＵＥ  Ｂへ送信される情報の時間・周波数リソースを示してもよい。
【００７０】
（Ｂ）第２のケース
図７に示すように、ｓＤＣＩは、複数のｓＰＤＳＣＨ領域における時間・周波数リソースを指定するための第２のｓＤＣＩ（Ｓｌｏｗ  ＤＣＩ）であってもよい。
【００７１】
第２のｓＤＣＩは、１サブフレーム中の最初のｓＰＤＣＣＨ領域においてのみ送信されてもよい。第２のｓＤＣＩを送信するためのｓＰＤＣＣＨ領域は、第１のｓＤＣＩを送信するためのｓＰＤＣＣＨ領域と異なっていてもよい。第２のｓＤＣＩは、ＰＤＣＣＨ領域でのみ送信されてもよい。この場合において、第２のｓＤＣＩは、ｓＰＤＣＣＨを介して送信されてもよい。第２のｓＤＣＩは、ＰＤＣＣＨを介して送信されてもよい。
【００７２】
第２のｓＤＣＩは、ＵＥ共通の情報であってもよい。従って、各ＵＥ１００を制御するＢＳ２００は、自セルに在圏する複数のＵＥ１００に共通の１つのｓＤＣＩを、第２のｓＤＣＩとして送信してもよい。
【００７３】
例えば、第２のｓＤＣＩは、ＵＥ  Ａ宛てに送信予定のｓＰＤＳＣＨの時間・周波数リソース（例えば、第２及び第３のｓＰＤＳＣＨ領域）と、ＵＥ  Ｂ宛てに送信予定のｓＰＤＳＣＨの時間・周波数リソース（例えば、第４及び第５のｓＰＤＳＣＨ領域）とを示してもよい。
【００７４】
第２のｓＤＣＩは、（第２のｓＤＣＩの生成時点において送信予定の）第１のｓＤＣＩの内容を示してもよい。第２のｓＤＣＩは、最初の第１のｓＤＣＩの内容を示さなくてもよい。すなわち、第２のｓＤＣＩは、２番目以降の各ｓＰＤＳＣＨ領域で送信予定の第１のｓＤＣＩの内容を示してもよい。第１のｓＤＣＩの内容は、リソース割り当て情報であってもよい。第１のｓＤＣＩの内容は、スケジューリング情報であってもよい。第１のｓＤＣＩの内容は、ＭＣＳ情報、ＲＶ（Ｒｅｄｕｎｄａｎｃｙ  Ｖｅｒｓｉｏｎ）情報、ＨＡＲＱ  ＩＤ情報、及びＤＣＩフォーマット情報の少なくともいずれであってもよい。
【００７５】
（Ｃ）第３のケース
図８に示すように、第２のｓＤＣＩは、ＵＥ個別の情報であってもよい。従って、ＢＳ２００は、複数の第２のｓＤＣＩを、複数の第２のｓＤＣＩのそれぞれを受け取り先である各ＵＥ１００へ送信してもよい。
【００７６】
例えば、第２のｓＤＣＩは、ＵＥ  Ａ宛てにのみ送信予定のｓＰＤＳＣＨの時間・周波数リソース（例えば、第２及び第３のｓＰＤＳＣＨ領域）を示してもよい。第２のｓＤＣＩは、ＵＥ  Ｂ宛てにのみ送信予定のｓＰＤＳＣＨの時間・周波数リソース（例えば、第４及び第５のｓＰＤＳＣＨ領域）を示してもよい。従って、第２のｓＤＣＩは、セル内の複数のＵＥ１００のうち、所定のＵＥ１００宛ての制御情報であってもよい。
【００７７】
（Ｄ）第４のケース
図９に示すように、第２のｓＤＣＩは、ＰＤＣＣＨ領域（又は最初のｓＰＤＣＣＨ領域）において送信されるだけでなく、ＰＤＣＣＨ領域よりも後ろのｓＰＤＣＣＨ領域において送信されもよい。
【００７８】
後ろのｓＰＤＣＣＨ領域において送信される第２のｓＤＣＩは、第１のｓＤＣＩと同様に、所定のｓＰＤＣＣＨ領域に対応する所定のｓＰＤＳＣＨ領域における時間・周波数リソースを示してもよい。例えば、第４のｓＰＤＣＣＨ領域において送信される第２のｓＤＣＩは、第４のｓＰＤＳＣＨ領域において送信される情報の時間・周波数リソースを示してもよい。
【００７９】
（無線端末）
実施形態に係るＵＥ１００（無線端末）について説明する。図１０は、ＵＥ１００のブロック図である。図１０に示すように、ＵＥ１００は、レシーバ（Ｒｅｃｅｉｖｅｒ：受信部）１１０、トランスミッタ（Ｔｒａｎｓｍｉｔｔｅｒ：送信部）１２０、及びコントローラ（Ｃｏｎｔｒｏｌｌｅｒ：制御部）１３０を備える。レシーバ１１０とトランスミッタ１２０とは、一体化されたトランシーバ（送受信部）であってもよい。
【００８０】
レシーバ１１０は、コントローラ１３０の制御下で各種の受信を行う。レシーバ１１０は、アンテナを含む。レシーバ１１０は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換する。レシーバ１１０は、ベースバンド信号をコントローラ１３０に出力する。
【００８１】
トランスミッタ１２０は、コントローラ１３０の制御下で各種の送信を行う。トランスミッタ１２０は、アンテナを含む。トランスミッタ１２０は、コントローラ１３０が出力するベースバンド信号（送信信号）を無線信号に変換する。トランスミッタ１３０は、無線信号をアンテナから送信する。
【００８２】
コントローラ１３０は、ＵＥ１００における各種の制御を行う。コントローラ１３０は、プロセッサ及びメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に使用される情報を記憶する。プロセッサは、ベースバンドプロセッサとＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）とを含む。ベースバンドプロセッサは、例えば、ベースバンド信号の変調・復調及び符号化・復号化を行う。ＣＰＵは、メモリに記憶されるプログラムを実行することにより、各種の処理を行う。プロセッサは、音声・映像信号の符号化・復号化を行うコーデックを含んでもよい。プロセッサは、後述する各種の処理及び上述した各種の通信プロトコルを実行する。
【００８３】
ＵＥ１００は、ＧＮＳＳ（Ｇｌｏｂａｌ  Ｎａｖｉｇａｔｉｏｎ  Ｓａｔｅｌｌｉｔｅ  Ｓｙｓｔｅｍ）受信機を備えていてもよい。ＧＮＳＳ受信機は、ＵＥ１００の地理的な位置を示す位置情報を得るために、ＧＮＳＳ信号を受信できる。ＧＮＳＳ受信機は、ＧＮＳＳ信号をコントローラ１３０に出力する。ＵＥ１００は、ＵＥ１００の位置情報を取得するためのＧＰＳ（Ｇｌｏｂａｌ  Ｐｏｓｉｔｉｏｎｉｎｇ  Ｓｙｓｔｅｍ）機能を有していてもよい。
【００８４】
本明細書では、ＵＥ１００が備えるレシーバ１１０、トランスミッタ１２０及びコントローラ１３０の少なくともいずれかが実行する処理を、便宜上、ＵＥ１００が実行する処理（動作）として説明する。
【００８５】
（基地局）
実施形態に係るＢＳ２００（基地局）について説明する。図１１は、ＢＳ２００のブロック図である。図１１に示すように、ＢＳ２００は、レシーバ（受信部）２１０、トランスミッタ（送信部）２２０、コントローラ（制御部）２３０、及びネットワークインターフェイス２４０を備える。トランスミッタ２１０とレシーバ２２０は、一体化されたトランシーバ（送受信部）であってもよい。
【００８６】
レシーバ２１０は、コントローラ２３０の制御下で各種の受信を行う。レシーバ２１０は、アンテナを含む。レシーバ２１０は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換する。レシーバ２１０は、ベースバンド信号をコントローラ２３０に出力する。
【００８７】
トランスミッタ２２０は、コントローラ２３０の制御下で各種の送信を行う。トランスミッタ２２０は、アンテナを含む。トランスミッタ２２０は、コントローラ２３０が出力するベースバンド信号（送信信号）を無線信号に変換する。トランスミッタ２２０は、無線信号をアンテナから送信する。
【００８８】
コントローラ２３０は、ＢＳ２００における各種の制御を行う。コントローラ２３０は、プロセッサ及びメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に使用される情報を記憶する。プロセッサは、ベースバンドプロセッサとＣＰＵとを含む。ベースバンドプロセッサは、例えば、ベースバンド信号の変調・復調及び符号化・復号化等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行することにより各種の処理を行う。プロセッサは、後述する各種の処理及び上述した各種の通信プロトコルを実行する。
【００８９】
ネットワークインターフェイス２４０は、Ｘ２インターフェイスを介して隣接ＢＳ２００と接続される。ネットワークインターフェイス２４０は、Ｓ１インターフェイスを介してＭＭＥ３００及びＳＧＷ４００と接続される。ネットワークインターフェイス２４０は、例えば、Ｘ２インターフェイス上で行う通信及びＳ１インターフェイス上で行う通信に使用される。
【００９０】
本明細書では、ＢＳ２００が備えるトランスミッタ２１０、レシーバ２２０、コントローラ２３０、及びネットワークインターフェイス２４０の少なくともいずれかが実行する処理を、便宜上、ＢＳ２００が実行する処理（動作）として説明する。
【００９１】
［第１実施形態］
第１実施形態について説明する。第１実施形態では、第１の無線通信装置（例えば、ＵＥ１００）が、異なる物理チャネルにおける再送要求に関する結果をまとめて第２の無線通信装置（例えば、ＢＳ２００）へ通知できる。
【００９２】
（Ａ）動作パターン１−１
動作パターン１−１について、図１２及び図１３を用いて説明する。図１２は、第１実施形態に係る動作（動作パターン１−１）を説明するためのシーケンス図である。図１３は、第１実施形態に係る動作（動作パターン１−１）を説明するための図である。
【００９３】
図１２に示すように、ステップＳ１１０において、ＢＳ２００は、制御情報をＵＥ１００へ送信してもよい。ＵＥ１００は、制御情報をＢＳ２００から受信してもよい。
【００９４】
ＢＳ２００は、制御情報を個別シグナリングによりＵＥ１００へ送信してもよい。例えば、ＢＳ２００は、制御情報をＲＲＣ設定情報（ＲＲＣ  ｃｏｎｆｉｇ）としてＲＲＣメッセージ（例えば、ＲＲＣ接続再確立メッセージ）により送信してもよい。ＢＳ２００は、制御情報をＤＣＩとして、ＵＥ１００へ送信してもよい。ＢＳ２００は、制御情報をブロードキャストシグナリング（例えば、ＳＩＢ（Ｓｙｓｔｅｍ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂｌｏｃｋ））／グループキャストシグナリングにより、ＵＥ１００へ送信してもよい。
【００９５】
制御情報の内容については、後述する。
【００９６】
ステップＳ１２０において、ＢＳ２００は、ＰＤＳＣＨにより第１の情報をＵＥ１００へ送信する。例えば、図１３に示すように、ＢＳ２００は、サブフレームｎにおけるＰＤＳＣＨ領域において、ＰＤＳＣＨを介して第１の情報をＵＥ１００へ送信する。ＵＥ１００は、ＰＤＳＣＨにより送信される第１の情報の受信を試みる。
【００９７】
ステップＳ１３０において、ＢＳ２００は、ｓＰＤＳＣＨにより第２の情報をＵＥ１００へ送信する。例えば、図１３に示すように、ＢＳ２００は、サブフレームｎ＋２におけるｓＰＤＳＣＨ領域において、ｓＰＤＳＣＨを介して第２の情報をＵＥ１００へ送信する。ＵＥ１００は、ｓＰＤＳＣＨにより送信される第２の情報の受信を試みる。
【００９８】
ステップＳ１４０において、ＵＥ１００は、第１の情報の再送を要求するか否かについての第１の結果と第２の情報の再送を要求するか否かについての第２の結果とをまとめてＢＳ２００へ通知する。例えば、図１３に示すように、ＵＥ１００は、サブフレームｎ＋４において、第１の結果と第２の結果とをまとめてＢＳ２００へ通知してもよい。
【００９９】
第１の結果は、情報の再送を要求しないこと（ＡＣＫ：Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）又は情報の際を要求すること（ＮＡＣＫ：Ｎｅｇａｔｉｖｅ  Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）を示す結果である。第２の結果は、情報の再送を要求しないこと又は情報の際を要求することを示す結果である。第１の結果及び第２の結果を示す情報は、例えば、ＨＡＲＱによる再送処理のために用いられる情報（ＨＡＲＱ−ＡＣＫ）であってもよい。第１の結果は、第１の情報の受信が成功又は失敗したことを示す受信結果（第１の受信結果）であってもよい。第２の結果は、第２の情報の受信が成功又は失敗したことを示す受信結果（第２の受信結果）であってもよい。
【０１００】
ＵＥ１００は、第１の結果を示す第１の送達確認情報と第２の結果を示す第２の送達確認情報と多重化してもよい（Ｍｕｌｔｉｐｌｅｘｉｎｇ）。第１の送達確認情報と第２の送達確認情報とは、異なる符号を付すことにより識別可能であってもよい。或いは、ＵＥ１００は、第１の結果と第２の結果とを１つのデータとして１つの送達確認情報に含めてもよい。
【０１０１】
ＵＥ１００は、送達確認情報（第１の送達確認情報及び第２の送達確認情報）を同じ時間・周波数リソースを用いて、ＢＳ２００へ送信できる。これにより、ＵＥ１００は、第１の結果と第２の結果とをまとめてＢＳ２００へ通知できる。
【０１０２】
ＵＥ１００は、第１の結果と第２の結果とを示す１つの送達確認情報をＢＳ２００へ送信してもよい（Ｂｕｎｄｌｉｎｇ）。具体的には、ＵＥ１００は、第１の情報及び第２の情報の両方の受信に成功したことに応じて、ＡＣＫを示す送達確認情報をＢＳ２００へ送信してもよい。ＵＥ１００は、第１の情報及び第２の情報の少なくとも一方の受信に失敗したことに応じて、ＮＡＣＫを示す送達確認情報をＢＳ２００へ送信してもよい。
【０１０３】
ＵＥ１００は、ＰＵＣＣＨ、ＰＵＳＣＨ、ｓＰＵＣＣＨ、及びｓＰＵＳＣＨのいずれかのチャネルを介して送達確認情報をＢＳ２００へ送信できる。遅延を低減するために、ＵＥ１００は、ｓＰＵＣＣＨ及びｓＰＵＳＣＨのいずれかのチャネルを介して送達確認情報をＢＳ２００へ送信してもよい。
【０１０４】
現状、ＰＵＳＣＨの送達確認情報の送信タイミング（第１の送信タイミング）は、ＰＵＳＣＨの受信から４サブフレーム（４ＴＴＩ）後である。一方、ｓＰＵＳＣＨの送達確認情報の送信タイミング（第２の送信タイミング）は、例えば、ｓＰＵＳＣＨの受信からｘＴＴＩ後である場合、第１の送信タイミングと第２の送信タイミングとが一致した場合に、ＵＥ１００は、送達確認情報を送信してもよい。
【０１０５】
第１の送信タイミングと第２の送信タイミングとが一致しない場合、ＵＥ１００は、一方の送信タイミングで、送達確認情報を送信してもよい。ＵＥ１００は、第１の送信タイミングと第２の送信タイミングとのうち、早い送信タイミングで送達確認情報を送信してもよい。これにより、遅延を低減できる。ＵＥ１００は、第１の送信タイミングと第２の送信タイミングとのうち、遅い送信タイミングで送達確認情報を送信してもよい。早い送信タイミングでは送達確認情報の送信準備が間に合わない場合に有効である。第１の送信タイミングと第２の送信タイミングとが一致しない場合、ＵＥ１００は、第１の送信タイミング及び第２の送信タイミングと異なるタイミングで送達確認情報を送信してもよい。例えば、ＵＥ１００は、送達確認情報の送信準備が完了した時点で送達確認情報を送信してもよい。
【０１０６】
ＵＥ１００は、ＢＳ２００から受信した制御情報に基づいて、送達確認情報をＢＳ２００へ送信してもよい。以下に、制御情報の一例を示す。各制御情報は、組み合わされてもよい。
【０１０７】
制御情報は、送達確認情報を通知するタイミングを指定してもよい。これにより、ＵＥ１００は、制御情報に基づいて、送達確認情報を通知するタイミングを決定できる。
【０１０８】
例えば、制御情報は、送達確認情報を送信すべき（及び／又は送信すべきでない）サブフレーム番号を指定してもよい。制御情報は、当該サブフレーム番号を示すビット列であってもよい。制御情報は、当該サブフレーム番号の直値（例えば、サブフレームｎ＋４）を示してもよい。
【０１０９】
制御情報は、送達確認情報を送信すべき（及び／又は送信すべきでない）タイミングとして、ｓＰＵＣＣＨ領域及び／又はｓＰＵＳＣＨ領域（の時間）を指定してもよい。例えば、制御情報は、ｓＰＵＣＣＨ領域及び／又はｓＰＵＳＣＨ領域が含まれる（サブフレーム番号及び）スロット番号を指定してもよい。制御情報は、ｓＰＵＣＣＨ領域及び／又はｓＰＵＳＣＨ領域を示すインデックス値（例えば、ｓＴＴＩのインデックス値）を指定してもよい。インデックス値は、ビット列により示されてもよい。
【０１１０】
制御情報は、第１の情報の受信タイミングと第２の情報の受信タイミングとの組み合わせを指定してもよい。これにより、ＵＥ１００は、制御情報に基づいて、まとめて通知することが可能である第１の結果と第２の結果と（の組み合わせ）を決定できる。
【０１１１】
例えば、ＵＥ１００は、ＰＤＳＣＨの受信タイミング及びｓＰＤＳＣＨの受信タイミングの組み合わせと、インデックス値とが対応付けられたリストを有していてもよい。制御情報は、当該リストのインデックス値であってもよい。ＵＥ１００は、個別シグナリング及び／又はブロードキャストシグナリングにより、当該リストをＢＳ２００から受信してもよい。
【０１１２】
ＰＤＳＣＨの受信タイミングは、サブフレーム番号により示されてもよい。ｓＰＤＳＣＨの受信タイミングは、サブフレーム番号（及び／又はｓＰＵＳＣＨ領域を示すインデックス値）により示されてもよい。ＰＤＳＣＨ及びｓＰＤＳＣＨの受信タイミングは、送達確認情報の送信タイミングを基準としたオフセット値により示されてもよい。例えば、ＰＤＳＣＨの受信タイミングは、送達確認情報の送信タイミングよりもｎサブフレーム前のサブフレーム番号を示してもよい。ｓＰＤＳＣＨの受信タイミングは、送達確認情報の送信タイミングよりもｎ−１サブフレーム前のサブフレーム番号（及び／又はｓＰＵＳＣＨ領域を示すインデックス値）を示してもよい。
【０１１３】
制御情報は、第１の結果と第２の結果とを通知する際における第１の結果と第２の結果との順番を指定してもよい。これにより、ＵＥ１００は、第１の結果と第２の結果との順番を決定できる。ＢＳ２００は、ＵＥ１００から受信する送達確認情報に含まれる第１の結果と第２の結果との順番を把握することができる。
【０１１４】
例えば、制御情報は、第１の結果が第２の結果よりも先に配置されることを示してもよい。制御情報は、第２の結果が第１の結果よりも先に配置されることを示してもよい。制御情報は、受信タイミングが早い方が先に配置されることを示してもよい。制御情報は、受信タイミングが遅い方が先に配置されることを示してもよい。
【０１１５】
具体的には、制御情報が第１の結果が第２の結果よりも先に配置されることを示す場合、ＵＥ１００は、第１の結果が第２の結果よりも先に配置されるように、送達確認情報を生成する。
【０１１６】
ＵＥ１００は、ＰＤＳＣＨを先に受信し、ｓＰＤＳＣＨを後に受信したケースについて説明する。制御情報が、受信タイミングが早い方が先に配置されることを示す場合、ＵＥ１００は、受信タイミングが早いＰＤＳＣＨを介して受信した第１の情報に関する第１の結果を先に配置されるように、送達確認情報を生成する。ＵＥ１００は、ＰＤＳＣＨよりも受信タイミングが遅いＰＤＳＣＨを介して受信した第２の情報に関する第２の結果が第１の結果よりも後に配置されるように、送達確認情報を生成する。
【０１１７】
制御情報は、第１の結果と第２の結果とをまとめて通知することを許可するか否かを示してもよい。これにより、ＵＥ１００は、制御情報に基づいて、第１の結果と第２の結果とをまとめて通知すべきか否かを決定できる。
【０１１８】
ＵＥ１００は、第１の結果と第２の結果とをまとめて通知することを許可されたことに応じて、ステップＳ１４０の処理を実行してもよい。ＵＥ１００は、第１の結果と第２の結果とをまとめて通知することを拒否されたことに応じて、第１の結果を示す送達確認情報と、第２の結果を示す送達確認情報と、を別々の時間・周波数リソースを用いて、ＢＳ２００へ送信してもよい。
【０１１９】
ＢＳ２００は、チャネル環境に応じて、第１の結果と第２の結果とをまとめて通知することを許可するか否かを決定してもよい。例えば、ＢＳ２００は、ＵＥ１００とＢＳ２００との間の無線環境が良好である（閾値以上である）ことに応じて、第１の結果と第２の結果とをまとめて通知することを許可してもよい。ＢＳ２００は、ＵＥ１００とＢＳ２００との間の無線環境が悪いこと（閾値未満である）に応じて、第１の結果と第２の結果とをまとめて通知することを許可してもよい。
【０１２０】
ＵＥ１００とＢＳ２００との間の無線環境は、ＵＥ１００において測定された無線環境（例えば、ＢＳ２００及び／又は他のＵＥ１００からの無線信号の受信レベル（ＲＳＲＰ（Ｒｅｆｅｒｅｎｃｅ  Ｓｉｇｎａｌ  Ｒｅｃｅｉｖｅｄ  Ｐｏｗｅｒ）及び／又はＲＳＲＱ（Ｒｅｆｅｒｅｎｃｅ  Ｓｉｇｎａｌ  Ｒｅｃｅｉｖｅｄ  Ｑｕａｌｉｔｙ））であってもよい。ＢＳ２００は、ＵＥ１００から無線環境の測定報告を受信してもよい。ＢＳ２００において測定された無線環境（例えば、ＵＥ１００及び／又は他のＵＥ１００からの無線信号の受信レベル（ＲＳＲＰ及び／又はＲＳＲＱ）であってもよい。
【０１２１】
ＢＳ２００は、ＵＥ１００からの送達確認情報に基づいて、ＨＡＲＱによる再送処理を実行するか否かを判定する。
【０１２２】
ＢＳ２００は、第１の結果が受信失敗（ＮＡＣＫ）を示す場合、ＰＤＳＣＨで送信した第１の情報の再送を開始する。ＢＳ２００は、第２の結果が受信失敗（ＮＡＣＫ）を示す場合、ｓＰＤＳＣＨで送信した第２の情報の再送を開始する。ＢＳ２００は、第１の情報をＰＤＳＣＨ又はｓＰＤＳＣＨにより再送してもよい。ＢＳ２００は、第２の情報をＰＤＳＣＨ又はｓＰＤＳＣＨにより再送してもよい。
【０１２３】
ＢＳ２００は、第１の結果が受信成功（ＡＣＫ）を示す場合、ＰＤＳＣＨで送信した第１の情報の再送を省略する。ＢＳ２００は、第２の結果が受信成功（ＡＣＫ）を示す場合、ｓＰＤＳＣＨで送信した第２の情報の再送を省略する。
【０１２４】
ＢＳ２００が、Ｂｕｎｄｌｉｎｇに基づく１つの送達確認情報を受信したケースを説明する。ＢＳ２００は、送達確認情報が受信失敗（ＮＡＣＫ）を示す場合、第１の情報及び第２の情報の両方を再送する。ＢＳ２００は、第１の情報及び第２の情報をＰＤＳＣＨ又はｓＰＤＳＣＨにより再送してもよい。ＢＳ２００は、送達確認情報が受信成功（ＡＣＫ）を示す場合、再送を省略する。
【０１２５】
以上のように、ＵＥ１００は、異なる物理チャネルにおける再送要求に関する結果（第１の結果及び第２の結果）をまとめてＢＳ２００へ通知する。これにより、複数の物理チャネルで用いられる上り無線リソースを低減できるため、上り無線リソースを有効に活用することができる。本出願に係る技術は、上りリンクの送信タイミングが少ないＴＤＤ（Ｔｉｍｅ  Ｄｉｖｉｓｉｏｎ  Ｄｕｐｌｅｘ）方式が適用される通信システムにおいて、特に有効である。
【０１２６】
（Ｂ）動作パターン１−２
動作パターン１−２について、図１４及び図１５を用いて説明する。図１４は、第１実施形態に係る動作（動作パターン１−２）を説明するためのシーケンス図である。図１５は、第１実施形態に係る動作（動作パターン１−２）を説明するための図である。上述と同様の内容は、説明を省略する。
【０１２７】
動作パターン１−１は、下りリンクに対する送達確認情報を送信するケースである。動作パターン１−２は、上りリンクに対する送達確認情報を送信するケースである。
【０１２８】
図１４に示すように、ステップＳ２１０において、ＢＳ２００は、制御情報をＵＥ１００へ送信してもよい。ＵＥ１００は、制御情報をＢＳ２００から受信してもよい。
【０１２９】
上述と同様に、ＢＳ２００は、制御情報を個別シグナリングにより送信してもよい。ＢＳ２００は、制御情報をブロードキャストシグナリング／グループキャストシグナリングにより、ＵＥ１００へ送信してもよい。
【０１３０】
制御情報は、ＢＳ２００が再送要求に関する結果（送達確認情報）をまとめてＵＥ１００へ通知するタイミングを指定してもよい。タイミングを指定する方法は、上述と同様である。
【０１３１】
制御情報は、まとめて通知する再送要求に関する結果（の組み合わせ）を指定してもよい。例えば、制御情報は、ＰＵＳＣＨ及びｓＰＵＳＣＨの送信リソース割り当て、すなわち、第１の情報及び第２の情報の送信に用いられる時間・周波数リソースであってもよい。第１の情報、ＰＵＳＣＨによりＵＥ１００からＢＳ２００へ送信される情報である。第２の情報、ｓＰＵＳＣＨによりＵＥ１００からＢＳ２００へ送信される情報である。これらの時間・周波数リソースを用いて送信されるＰＵＳＣＨ（第１の情報）及びｓＰＵＳＣＨ（第２の情報）に対する再送要求の結果がまとめてＵＥ１００へ通知されることを示してもよい。
【０１３２】
制御情報は、第１の結果と第２の結果とを通知する際における第１の結果と第２の結果との順番を指定してもよい。上述と同様に、第１の結果は、第１の情報の再送を要求するか否かについて示す（ＡＣＫ／ＮＡＣＫ）。第２の結果は、第２の情報の再送を要求するか否かについて示す（ＡＣＫ／ＮＡＣＫ）。
【０１３３】
制御情報は、第１の結果と第２の結果とをまとめて通知するか否かを示してもよい。上述と同様に、ＢＳ２００は、チャネル環境に応じて、第１の結果と第２の結果とをまとめて通知するか否かを決定してもよい。
【０１３４】
ステップＳ２２０において、ＵＥ１００は、ＰＵＳＣＨにより第１の情報をＢＳ２００へ送信する。例えば、図１５に示すように、ＵＥ１００は、サブフレームｎにおけるＰＵＳＣＨ領域において、ＰＵＳＣＨを介して第１の情報をＢＳ２００へ送信する。ＵＥ１００は、制御情報により指定された時間・周波数リソースを用いて、第１の情報をＢＳ２００へ送信してもよい。ＢＳ２００は、ＰＵＳＣＨにより送信される第１の情報の受信を試みる。
【０１３５】
ステップＳ２３０において、ＵＥ１００は、ｓＰＵＳＣＨにより第２の情報をＢＳ２００へ送信する。例えば、図１５に示すように、ＵＥ１００は、サブフレームｎ＋２におけるｓＰＵＳＣＨ領域において、ｓＰＵＳＣＨを介して第２の情報をＢＳ２００へ送信する。ＵＥ１００は、制御情報により指定された時間・周波数リソースを用いて、第２の情報をＢＳ２００へ送信してもよい。ＢＳ２００は、ｓＰＤＳＣＨにより送信される第２の情報の受信を試みる。
【０１３６】
ステップＳ２４０において、ＢＳ２００は、第１の情報の再送を要求するか否かについての第１の結果と第２の情報の再送を要求するか否かについての第２の結果とをまとめてＵＥ１００へ通知する。例えば、図１５に示すように、ＢＳ２００は、サブフレームｎ＋４において、第１の結果と第２の結果とをまとめてＵＥ１００へ通知してもよい。
【０１３７】
ＵＥ１００は、制御情報に基づいて、ＢＳ２００が第１の結果と第２の結果とをまとめて通知したか否かを判定してもよい。ＵＥ１００は、制御情報に基づいて、送達確認情報の内容（例えば、第１の結果と第２の結果とのどちらが先に配置されているか）を判定してもよい。
【０１３８】
ＵＥ１００は、ＢＳ２００からの送達確認情報に基づいて、ＨＡＲＱによる再送処理を実行するか否かを判定する。
【０１３９】
ＵＥ１００は、第１の結果が受信失敗（ＮＡＣＫ）を示す場合、ＰＵＳＣＨで送信した第１の情報の再送を開始する。ＵＥ１００は、第２の結果が受信失敗（ＮＡＣＫ）を示す場合、ｓＰＵＳＣＨで送信した第２の情報の再送を開始する。ＵＥ１００は、第１の情報をＰＵＳＣＨ又はｓＰＵＳＣＨにより再送してもよい。ＵＥ１００は、第２の情報をＰＵＳＣＨ又はｓＰＵＳＣＨにより再送してもよい。
【０１４０】
ＵＥ１００は、第１の結果が受信成功（ＡＣＫ）を示す場合、ＰＵＳＣＨで送信した第１の情報の再送を省略する。ＵＥ１００は、第２の結果が受信成功（ＡＣＫ）を示す場合、ｓＰＵＳＣＨで送信した第２の情報の再送を省略する。
【０１４１】
以上のように、ＢＳ２００は、異なる物理チャネルにおける再送要求に関する結果（第１の結果及び第２の結果）をまとめてＵＥ１００へ通知する。これにより、複数の物理チャネルで用いられる下り無線リソースを低減できるため、下り無線リソースを有効に活用することができる。
【０１４２】
［第２実施形態］
第２実施形態について説明する。第２実施形態では、ＵＥ１００が、一部のｓＰＤＣＣＨ領域（ショート制御領域）をモニタするかどうかを判定できる。
【０１４３】
（Ａ）動作パターン２−１
動作パターン２−１について、図１６−図１８を用いて説明する。図１６は、第２実施形態に係る動作（動作パターン２−１）を説明するためのシーケンス図である。図１７は、第２実施形態に係る動作（動作パターン２−１）を説明するためのフローチャートである。図１８は、第２実施形態に係る動作（動作パターン２−１）を説明するための図である。上述と同様の内容は、説明を省略する。
【０１４４】
図１６に示すように、ステップＳ３１０において、ＢＳ２００は、制御情報をＵＥ１００へ送信する。上述と同様に、ＢＳ２００は、制御情報を個別シグナリングにより送信してもよい。ＢＳ２００は、制御情報をブロードキャストシグナリング／グループキャストシグナリングにより、ＵＥ１００へ送信してもよい。ＢＳ２００は、制御情報をＲＲＣメッセージにより送信してもよい。
【０１４５】
ＢＳ２００は、ＰＤＣＣＨ領域の時間・周波数リソースを用いて、ＰＤＣＣＨにより制御情報を送信してもよい。ＢＳ２００は、ｓＰＤＣＣＨ領域の時間・周波数リソースを用いて、ｓＰＤＣＣＨにより制御情報を送信してもよい。ＢＳ２００は、ｓＤＣＩ（第１のｓＤＣＩ（Ｆａｓｔ  ＤＣＩ）及び／又は第２のｓＤＣＩ（Ｓｌｏｗ  ＤＣＩ））に制御情報を含めてもよい。
【０１４６】
制御情報は、セル内の各ＵＥ１００に個別に適用されるものであってもよい。制御情報は、セル内の全ＵＥ１００に共通に適用されるものであってもよい。
【０１４７】
第２実施形態における制御情報は、ＵＥ１００がｓＰＤＣＣＨ領域をモニタするかどうかを判定するために用いられてもよい。例えば、制御情報は、第１のＰＤＣＣＨから第２のＰＤＣＣＨの次に配置される第２のＰＤＣＣＨまでの間に配置される複数のｓＰＤＣＣＨ領域のうち、一部のｓＰＤＣＣＨ領域をモニタするかどうか判定するために用いられる。
【０１４８】
モニタするか判定するために用いられるｓＰＤＣＣＨ領域は、第１のｓＤＣＩが送信される第１のｓＰＤＣＣＨ領域であってもよい。モニタするか判定するために用いられるｓＰＤＣＣＨ領域は、第２のｓＤＣＩが送信される第２のｓＰＤＣＣＨ領域であってもよい。モニタするか判定するために用いられるｓＰＤＣＣＨ領域は、第１のｓＰＤＣＣＨ領域と第２のｓＰＤＣＣＨ領域の両方であってもよい。
【０１４９】
ＵＥ１００は、制御情報をＢＳ２００から受信する（図１７のＳ４１０）。ＵＥ１００は、制御情報に基づいて、ｓＰＤＣＣＨ領域をモニタするかどうかを判定する（図１７のＳ４２０）。ＵＥ１００は、ＢＳ２００から後述する複数の制御情報を受信してもよい。ＵＥ１００は、複数の制御情報のうち、少なくともいずれかに基づいて、ｓＰＤＣＣＨ領域をモニタするかどうかを判定してもよい。
【０１５０】
ＵＥ１００がｓＰＤＣＣＨ領域をモニタするかどうかを判定する方法の例を説明する。
【０１５１】
制御情報は、モニタすべき一部のｓＰＤＣＣＨ領域、モニタを開始すべきｓＰＤＣＣＨ領域、及び、モニタすべき一部のｓＰＤＣＣＨ領域が含まれる期間、の少なくともいずれかを示してもよい。
【０１５２】
制御情報は、１サブフレーム内のうち、モニタすべき一部のｓＰＤＣＣＨ領域をｓＴＴＩのインデックス値で示してもよい。例えば、ｓＴＴＩが２シンボルのケースにおいて、制御情報は、「｛０，０，１，０，１，１｝」を示すビット列を示してもよい。ＵＥ１００は、ｓＴＴＩのインデックス値が２，４，５であるｓＰＤＣＣＨ領域（♯２，４，５）をモニタすると決定してもよい。
【０１５３】
制御情報は、１サブフレーム内のうち、モニタを開始すべきｓＰＤＣＣＨ領域をｓＴＴＩのインデックス値で示してもよい。制御情報はｓＴＴＩのインデックス値の３を示してもよい。ＵＥ１００は、ｓＴＴＩのインデックス値が３，４，５であるｓＰＤＣＣＨ領域（♯３，４，５）をモニタすると決定してもよい。
【０１５４】
制御情報は、１サブフレーム内のうち、モニタすべき一部のｓＰＤＣＣＨ領域が含まれる期間をスロット番号で示してもよい。例えば、制御情報は、「｛０，１｝」を示すスロット番号のビット列を示してもよい。ＵＥ１００は、スロット番号が１の期間に含まれるｓＰＤＣＣＨ領域（♯３，４，５）をモニタすると決定してもよい。制御情報は、「｛１，０｝」を示すスロット番号のビット列を示す場合、ＵＥ１００は、ｓＰＤＣＣＨ領域（♯０，１，２）をモニタすると決定してもよい。制御情報は、「｛１，１｝」を示すスロット番号のビット列を示す場合、ＵＥ１００は、ｓＰＤＣＣＨ領域（♯０−５）をモニタすると決定してもよい。制御情報は、「｛０，０｝」を示すスロット番号のビット列を示す場合、ＵＥ１００は、ｓＰＤＣＣＨ領域のモニタを省略すると決定してもよい。
【０１５５】
制御情報は、モニタすべきでない一部のｓＰＤＣＣＨ領域、モニタを開始すべきでないｓＰＤＣＣＨ、及び、前記モニタすべきでない一部のｓＰＤＣＣＨが含まれる期間、の少なくともいずれかを示してもよい。
【０１５６】
制御情報は、第１のｓＤＣＩの受信の必要性を示すインディケーションであってもよい。当該インディケーションは、第１のｓＤＣＩの受信が必要であることを示してもよい。当該インディケーションは、第１のｓＤＣＩの受信が必要でないことを示してもよい。インディケーションは、ｓＤＣＩに含まれてもよい。制御情報は、（インディケーションを含む）ｓＤＣＩであってもよい。
【０１５７】
ＵＥ１００は、第１のｓＤＣＩの受信が必要でないことを示すインディケーションの受信に応じて、ｓＰＤＣＣＨ領域をモニタしないと判定してもよい。ＵＥ１００は、第１のｓＤＣＩの受信が必要であることを示すインディケーションの受信に応じて、ｓＰＤＣＣＨ領域をモニタすると判定してもよい。
【０１５８】
例えば、ＢＳ２００は、送信予定の第１のｓＤＣＩに含まれる各情報（例えば、ＭＣＳ情報など）を示す値として、予め規定された（ｐｒｅｄｅｆｉｎｅｄ）デフォルト値を用いる場合には、第１のｓＤＣＩの受信が必要でないことを示すインディケーションを第２のｓＤＣＩに含めてもよい。ＢＳ２００は、送信予定の第１のｓＤＣＩに含まれる各情報を示す値として、デフォルト値と異なる値を用いる場合には、第１のｓＤＣＩの受信が必要であることを示すインディケーションを第２のｓＤＣＩに含めてもよい。ＢＳ２００は、第１のｓＤＣＩにおいてデフォルト値が用いられるか否かを示すインディケーションを第２のｓＤＣＩに含めてもよい。ＢＳ２００は、第１のｓＤＣＩにおいてデフォルト値が用いられるか否かを示すインディケーションを第１のｓＤＣＩに含めてもよい。これにより、第１のｓＤＣＩの送信に用いられるリソース量を低減できる。
【０１５９】
ＵＥ１００は、第１のｓＤＣＩにおいてデフォルト値が用いられることを示すインディケーションの受信に応じて、ｓＰＤＣＣＨ領域をモニタしないと判定してもよい。ＵＥ１００は、第１のｓＤＣＩにおいてデフォルト値が用いられないことを示すインディケーションの受信に応じて、ｓＰＤＣＣＨ領域をモニタすると判定してもよい。
【０１６０】
ＢＳ２００は、前のサブフレームで送信した第１のｓＤＣＩと同じ内容を送信予定の次の第１のｓＤＣＩに含める場合には、第１のｓＤＣＩの受信が必要でないことを示すインディケーションを第２のｓＤＣＩに含めてもよい。ＢＳ２００は、第１のｓＤＣＩの内容（設定）を更新しない場合には、第１のｓＤＣＩの受信が必要でないことを示すインディケーションを第２のｓＤＣＩに含めてもよい。ＢＳ２００は、前のサブフレームで送信した第１のｓＤＣＩと異なる内容を送信予定の次の第１のｓＤＣＩに含める場合には、第１のｓＤＣＩの受信が必要であることを示すインディケーションを第２のｓＤＣＩに含めてもよい。
【０１６１】
ＢＳ２００は、第１のｓＤＣＩが前の第１のｓＤＣＩと同じであるか否かを示すインディケーションを第２のｓＤＣＩに含めてもよい。ＵＥ１００は、第１のｓＤＣＩが前の第１のｓＤＣＩと同じであることを示すインディケーションの受信に応じて、ｓＰＤＣＣＨ領域をモニタしないと判定してもよい。ＵＥ１００は、第１のｓＤＣＩが前の第１のｓＤＣＩと異なることを示すインディケーションの受信に応じて、ｓＰＤＣＣＨ領域をモニタすると判定してもよい。
【０１６２】
制御情報は、ｓＤＣＩであってもよい。ＵＥ１００は、第２のｓＤＣＩのサイズに応じて、ｓＰＤＣＣＨ領域をモニタするかどうかを判定してもよい。例えば、ＵＥ１００は、第２のｓＤＣＩのサイズと閾値（第１の閾値及び／又は第２の閾値）との比較によって、ｓＰＤＣＣＨ領域をモニタするかどうかを判定してもよい。
【０１６３】
ＵＥ１００は、ＰＤＣＣＨ領域よりも後に配置されるｓＰＤＣＣＨ領域においてｓＰＤＣＣＨにより送信される第２のｓＤＣＩを用いてもよい。ＵＥ１００は、ＰＤＣＣＨ領域においてｓＰＤＣＣＨ（又はＰＤＣＣＨ）により送信される第２のｓＤＣＩを用いてもよい。
【０１６４】
ＵＥ１００は、閾値（第１の閾値及び／又は第２の閾値）の情報をＢＳ２００から受信してもよい。閾値の情報は、制御情報に含まれていてもよい。閾値の情報は、ＲＲＣメッセージに含まれていてもよい。第２の閾値は、第１の閾値よりも大きい値である。
【０１６５】
ＢＳ２００は、第２のｓＤＣＩで十分にデータが送信可能である（空き容量がある）場合には、第１のｓＤＣＩの送信を省略してもよい。第１のｓＤＣＩの送信が省略される場合には、ＵＥ１００は、ｓＰＤＣＣＨ領域のモニタを省略できる。ＢＳ２００は、第１のｓＤＣＩの送信が必要か否かに応じて、第２のｓＤＣＩのサイズを変更してもよい。
【０１６６】
ＵＥ１００は、第２のｓＤＣＩのサイズが第１の閾値よりも小さいことに応じて、ｓＰＤＣＣＨ領域をモニタしないと判定してもよい。ＵＥ１００は、第２のｓＤＣＩのサイズが第１の閾値よりも大きいことに応じて、ｓＰＤＣＣＨ領域をモニタすると判定してもよい。ＵＥ１００は、第２のｓＤＣＩのサイズが第２の閾値よりも小さいことに応じて、ｓＰＤＣＣＨ領域をモニタすると判定してもよい。ＵＥ１００は、第２のｓＤＣＩのサイズが第２の閾値よりも大きいことに応じて、ｓＰＤＣＣＨ領域をモニタしないと判定してもよい。
【０１６７】
制御情報は、第１のｓＤＣＩに含まれる情報及び／又は第２のｓＤＣＩに含まれる情報を示してもよい。制御情報は、第１のｓＤＣＩに含まれる情報のリスト及び／又は第２のｓＤＣＩに含まれる情報のリストであってもよい。従って、ＢＳ２００は、ＰＤＣＣＨにより送信される通常のＤＣＩに含まれる各種情報のうち、全ての種類の情報ではなく、一部の情報のみを第１のｓＤＣＩ及び／又は第２のｓＤＣＩに含めてもよい。
【０１６８】
制御情報は、第１のｓＤＣＩに含まれる情報が第２のｓＤＣＩに全て含まれることを示してもよい。制御情報は、第１のｓＤＣＩ（及び／又は第２のｓＤＣＩ）に含まれる情報にはデフォルト値が用いられることを示してもよい。
【０１６９】
ＵＥ１００は、第１のｓＤＣＩを受信する必要がない場合には、第１のｓＤＣＩが送信されるｓＰＤＣＣＨ領域をモニタしないと判定してもよい。例えば、制御情報が、第１のｓＤＣＩに含まれる情報が第２のｓＤＣＩに全て含まれることを示すことに応じて、ＵＥ１００は、第１のｓＤＣＩが送信されるｓＰＤＣＣＨ領域をモニタしないと判定してもよい。第１のｓＤＣＩに含まれる情報にはデフォルト値が用いられることを示すことに応じて、ＵＥ１００は、第１のｓＤＣＩが送信されるｓＰＤＣＣＨ領域をモニタしないと判定してもよい。ＵＥ１００は、第１のｓＤＣＩに含まれる情報が自身の通信に必要ない情報であることに応じて、第１のｓＤＣＩが送信されるｓＰＤＣＣＨ領域をモニタしないと判定してもよい。
【０１７０】
同様に、ＵＥ１００は、第２のｓＤＣＩを受信する必要がない場合には、第２のｓＤＣＩが送信されるｓＰＤＣＣＨ領域をモニタしないと判定してもよい。
【０１７１】
ステップＳ３２０において、ＵＥ１００は、判定結果に応じて、ｓＰＤＣＣＨ領域のモニタを制御する（図１７のＳ４３０）。
【０１７２】
ＵＥ１００は、モニタすると判定したｓＰＤＣＣＨ領域をモニタする。ＵＥ１００は、モニタしないと判定したｓＰＤＣＣＨ領域のモニタを省略する。これにより、ＵＥ１００のモニタ負荷を低減することができる。ＢＳ２００は、ｓＰＤＣＣＨの送信を省略した場合には、ｓＰＤＣＣＨ領域において他の情報（例えば、ｓＰＤＳＣＨ）を送信してもよい。これにより、無線リソースの利用効率が向上できる。
【０１７３】
ＵＥ１００は、制御情報を受信しなかった場合、又は、制御情報の受信に失敗した場合には、全てのｓＰＤＣＣＨ領域をモニタしてもよい。
【０１７４】
以上のように、ＵＥ１００は、一部のｓＰＤＣＣＨ領域をモニタすべきかどうかを判定できる。例えば、ＰＤＣＣＨ領域において、１サブフレーム中の全てのｓＰＤＣＣＨ領域をモニタすべきかどうかが示す情報が送信された場合には、ＵＥ１００は、全てのｓＰＤＣＣＨ領域をモニタする又はモニタしない。この場合、ＰＤＣＣＨ領域を過ぎた後にＵＥ１００へのデータが急に発生した場合には、次のサブフレームまでＵＥ１００は、データを受信することができない。或いは、例えば、サブフレームの前半における複数のｓＰＤＣＣＨ領域では、所定のＵＥ１００へのデータのみを送信する場合、他のＵＥ１００は、サブフレームの前半における複数のｓＰＤＣＣＨ領域を受信する必要がない。本実施形態に係るＵＥ１００は、一部のｓＰＤＣＣＨ領域をモニタすべきかどうかを判定できるため、このようなケースにおいて特に有効である。
【０１７５】
（Ｂ）動作パターン２−２
動作パターン２−２について、図１９を用いて説明する。図１９は、第２実施形態に係る動作（動作パターン２−２）を説明するためのフローチャートである。上述と同様の内容は、説明を省略する。
【０１７６】
動作パターン２−２は、ＵＥ１００が、タイマを用いて、ｓＰＤＣＣＨ領域をモニタするかどうかを判定するケースである。
【０１７７】
図１９に示すように、ステップＳ５１０において、ＵＥ１００は、タイマ情報をＢＳ２００から受信してもよい。ＵＥ１００は、個別シグナリング（例えば、ＲＲＣメッセージ（ＲＲＣ接続再確立メッセージ）、ＤＣＩ、又はｓＤＣＩ）によりタイマ情報を受信してもよい。ＵＥ１００は、ブロードキャストシグナリング（例えば、ＳＩＢ（Ｓｙｓｔｅｍ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂｌｏｃｋ））／グループキャストシグナリングによりタイマ情報を受信してもよい。
【０１７８】
タイマ情報は、ショート制御領域をモニタすべきするかどうかを判定するためのタイマについての情報である。タイマ情報は、タイマ値を示してもよい。タイマ値は、予めＵＥ１００に設定されていてもよい。
【０１７９】
ステップＳ５２０において、ＵＥ１００は、ＢＳ２００との通信の実行に応じて、タイマをスタートする。
【０１８０】
ＵＥ１００は、無線リソースの割り当てを要求するためのスケジューリング要求（ＳＲ）をＢＳ２００へ送信したことに応じて、タイマをスタートしてもよい。ＵＥ１００は、ｓＰＵＳＣＨ領域においてｓＰＵＳＣＨにより情報をＢＳ２００へ送信したことに応じて、タイマをスタートしてもよい。ＵＥ１００は、ｓＰＤＳＣＨ領域においてｓＰＤＳＣＨにより情報をＢＳ２００から受信したことに応じて、タイマをスタートしてもよい。
【０１８１】
ＵＥ１００は、各動作の実行により、各動作に対応付けられた各タイマを実行してもよい。各タイマのタイマ値は異なっていてもよい。各タイマのタイマ値は同じであってもよい。
【０１８２】
ステップＳ５３０において、ＵＥ１００は、ｓＰＤＣＣＨ領域をモニタするかどうかを判定する。
【０１８３】
ＵＥ１００は、タイマが起動している間、ｓＰＤＣＣＨ領域のモニタを実行してもよい。ＵＥ１００は、タイマが満了するまで、ｓＰＤＣＣＨ領域のモニタを継続してもよい。ＵＥ１００は、タイマの満了に応じて、ｓＰＤＣＣＨ領域のモニタを終了してもよい。
【０１８４】
ＵＥ１００は、ＳＲをＢＳ２００へ送信した場合、ｓＰＤＣＣＨにより無線リソースの割り当てがＢＳ２００から送信される可能性がある。ＵＥ１００は、ＳＲをＢＳ２００へ送信した後、ｓＰＤＣＣＨ領域のモニタを継続することによって無線リソースの割り当てを受信できる。一方で、ＵＥ１００は、タイマが満了しても、無線リソースの割り当てを受信できない場合には、ｓＰＤＣＣＨにより無線リソースの割り当てが送信されないと判定する。これにより、ＵＥ１００は、無駄なｓＰＤＣＣＨ領域のモニタを省略できる。
【０１８５】
ＵＥ１００は、タイマが満了する前に無線リソースの割り当てを受信した場合、タイマを終了してもよい。ＵＥ１００は、タイマの終了に応じて、ｓＰＤＣＣＨ領域のモニタを終了してもよい。
【０１８６】
ＵＥ１００は、ｓＰＵＳＣＨにより情報をＢＳ２００へ送信した場合、当該情報の送達確認情報がＢＳ２００から送信される可能性がある。ＵＥ１００は、ｓＰＵＳＣＨにより情報をＢＳ２００へ送信した後、ｓＰＤＣＣＨ領域のモニタを継続することによって送達確認情報を受信できる。一方で、ＵＥ１００は、タイマが満了しても、送達確認情報を受信できない場合には、ｓＰＤＣＣＨにより送達確認情報が送信されないと判定する。これにより、ＵＥ１００は、無駄なｓＰＤＣＣＨ領域のモニタを省略できる。
【０１８７】
ＵＥ１００は、タイマが満了する前に送達確認情報を受信した場合、タイマを終了してもよい。ＵＥ１００は、タイマの終了に応じて、ｓＰＤＣＣＨ領域のモニタを終了してもよい。
【０１８８】
ＵＥ１００は、ｓＰＤＳＣＨにより情報をＢＳ２００から受信した場合、ｓＰＤＳＣＨにより情報がＢＳ２００からさらに送信される可能性がある。ＵＥ１００は、ｓＰＵＳＣＨにより情報をＢＳ２００から受信した後、ｓＰＤＣＣＨ領域のモニタを継続することによってｓＰＤＳＣＨによりさらに送信される情報を受信できる。一方で、ＵＥ１００は、タイマが満了しても、情報を受信できない場合には、ｓＰＤＣＣＨにより情報が送信されないと判定する。これにより、ＵＥ１００は、無駄なｓＰＤＣＣＨ領域のモニタを省略できる。
【０１８９】
ＵＥ１００は、タイマが満了する前に情報の受信が完了した場合、タイマを終了してもよい。ＵＥ１００は、タイマの終了に応じて、ｓＰＤＣＣＨ領域のモニタを終了してもよい。
【０１９０】
ＵＥ１００は、動作パターン２−１における制御情報に基づいて、（一部の）ｓＰＤＣＣＨ領域をモニタしないと判定した場合であっても、タイマが満了するまで、ｓＰＤＣＣＨ領域のモニタを継続してもよい。ＵＥ１００の通信動作により、ｓＰＤＣＣＨ領域における情報の送信がトリガされる可能性があるためである。このように、ＵＥ１００は、タイマによる判定を制御情報に基づく判定よりも優先してもよい。
【０１９１】
ＵＥ１００は、タイマが満了する前であっても、動作パターン２−１における制御情報に基づいて、ｓＰＤＣＣＨ領域を継続的にモニタする動作を終了してもよい。例えば、ＵＥ１００は、ＵＥ１００が通信動作を実行した後に制御情報を受信した場合には、制御情報にＵＥ１００の通信動作が反映されている可能性が高い。このように、ＵＥ１００は、制御情報に基づく判定をタイマによる判定よりも優先してもよい。
【０１９２】
ステップＳ５４０において、ＵＥ１００は、タイマの満了に応じて、ｓＰＤＣＣＨ領域のモニタを通常通りに実行する。例えば、ＵＥ１００は、制御情報に基づく判定を実行してもよい。
【０１９３】
［その他の実施形態］
上述した実施形態によって、本出願の内容を説明したが、この開示の一部をなす論述及び図面は、本出願の内容を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施形態、実施例及び運用技術が明らかとなろう。
【０１９４】
上述した各実施形態では、ＰＤＣＣＨ、ＰＤＳＣＨ、ＰＵＣＣＨ及びＰＵＳＣＨを例に挙げて説明したが、これに限られない。所定のチャネルよりも送信時間間隔が短いチャネルが規定された場合に、上述の内容が適用されてもよい。
【０１９５】
例えば、ＰＤＣＣＨは、以下の少なくともいずれかのチャネルに置き換えられてもよい。
【０１９６】
・拡張物理下りリンク制御チャネル（ＥＰＤＣＣＨ：Ｅｎｈａｎｃｅｄ  ｐｈｙｓｉｃａｌ  ｄｏｗｎｌｉｎｋ  ｃｏｎｔｒｏｌ  ｃｈａｎｎｅｌ）
・マシーンタイプコミュニケーション物理下りリンク制御チャネル（ＭＰＤＣＣＨ：ＭＴＣ  （Ｍａｃｈｉｎｅ−Ｔｙｐｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）  ｐｈｙｓｉｃａｌ  ｄｏｗｎｌｉｎｋ  ｃｏｎｔｒｏｌ  ｃｈａｎｎｅｌ）
・リレー物理下りリンク制御チャネル（Ｒ−ＰＤＣＣＨ：Ｒｅｌａｙ  ｐｈｙｓｉｃａｌ  ｄｏｗｎｌｉｎｋ  ｃｏｎｔｒｏｌ  ｃｈａｎｎｅｌ）
・狭帯域物理下りリンク制御チャネル（ＮＰＤＣＣＨ：Ｎａｒｒｏｗｂａｎｄ  Ｐｈｙｓｉｃａｌ  ｄｏｗｎｌｉｎｋ  ｃｏｎｔｒｏｌ  ｃｈａｎｎｅｌ）
【０１９７】
例えば、ＰＤＳＣＨは、以下のチャネルに置き換えられてもよい。
・狭帯域物理下りリンク共有チャネル（ＮＰＤＳＣＨ：Ｎａｒｒｏｗｂａｎｄ  Ｐｈｙｓｉｃａｌ  ｄｏｗｎｌｉｎｋ  ｓｈａｒｅｄ  ｃｈａｎｎｅｌ）
【０１９８】
例えば、ＰＵＳＣＨは、以下のチャネルに置き換えられてもよい。
・狭帯域物理上りリンク共有チャネル（ＮＰＵＳＣＨ：Ｎａｒｒｏｗｂａｎｄ  Ｐｈｙｓｉｃａｌ  ｕｐｌｉｎｋ  ｓｈａｒｅｄ  ｃｈａｎｎｅｌ）
【０１９９】
上述した各実施形態（各動作パターン）に係る内容は、適宜組み合わせて実行されてもよい。上述した各シーケンスにおいて、必ずしも全ての動作が必須の構成ではない。例えば、各シーケンスにおいて、一部の動作のみが実行されてもよい。
【０２００】
上述した各実施形態では特に触れていないが、上述した各ノード（ＵＥ１００、ＢＳ２００など）のいずれかが行う各処理をコンピュータに実行させるプログラムが提供されてもよい。プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ等の記録媒体であってもよい。
【０２０１】
ＵＥ１００及びＢＳ２００のいずれかが行う各処理を実行するためのプログラムを記憶するメモリ及びメモリに記憶されたプログラムを実行するプロセッサによって構成されるチップが提供されてもよい。
【０２０２】
上述した各実施形態では、移動通信システムの一例としてＬＴＥシステムを説明したが、ＬＴＥシステムに限定されるものではなく、ＬＴＥシステム以外のシステムに本出願に係る内容を適用してもよい。例えば、５Ｇにおいて運用される通信システムにおいて、本出願に係る内容が適用されてもよい。
【０２０３】
日本国特許出願第２０１７−０１８６１１号（２０１７年２月３日出願）の全内容が、参照により、本願明細書に組み込まれている。
【産業上の利用可能性】
【０２０４】
本発明は移動通信分野において有用である。
【図１】
0006736045.tif 000002
【図２】
0006736045.tif 000003
【図３】
0006736045.tif 000004
【図４】
0006736045.tif 000005
【図５】
0006736045.tif 000006
【図６】
0006736045.tif 000007
【図７】
0006736045.tif 000008
【図８】
0006736045.tif 000009
【図９】
0006736045.tif 000010
【図１０】
0006736045.tif 000011
【図１１】
0006736045.tif 000012
【図１２】
0006736045.tif 000013
【図１３】
0006736045.tif 000014
【図１４】
0006736045.tif 000015
【図１５】
0006736045.tif 000016
【図１６】
0006736045.tif 000017
【図１７】
0006736045.tif 000018
【図１８】
0006736045.tif 000019
【図１９】
0006736045.tif 000020