(57)【特許請求の範囲】
【請求項１】
同一の下りリンク無線リソースを使用して基地局から複数のユーザ端末に送信されるマルチキャスト／ブロードキャストデータを受信する受信部と、
前記複数のユーザ端末からなるグループに対して前記基地局から割り当てられたリソースプールの中から、フィードバック情報の送信に使用する上りリンク無線リソースを選択する制御部と、
前記選択された上りリンク無線リソースを使用して、前記フィードバック情報を前記基地局に送信する送信部と、を備え、
前記制御部は、前記基地局からの通知を受信することに応じて、前記リソースプールを使用して前記フィードバック情報を送信する第１のモードから、前記基地局から各ユーザ端末に個別に割り当てられる物理上りリンク制御チャネルを使用して前記フィードバック情報を送信する第２のモードに切り替えることを特徴とするユーザ端末。
【請求項２】
前記リソースプールは、前記基地局から各ユーザ端末に個別に割り当てられる物理上りリンク制御チャネルとは異なる上りリンク無線リソースからなることを特徴とする請求項１に記載のユーザ端末。
【請求項３】
前記受信部は、前記リソースプールに関する設定情報を前記基地局から受信し、
前記設定情報は、時間軸上における基準点と前記リソースプールの始点との間の差分、周波数軸上における基準点と前記リソースプールの始点との間の差分、時間軸上における前記リソースプールの範囲、周波数軸上における前記リソースプールの範囲、のうち少なくとも１つを含むことを特徴とする請求項１に記載のユーザ端末。
【請求項４】
前記制御部は、前記基地局から自ユーザ端末に割り当てられた固有情報、又は自ユーザ端末に予め設定されている固有情報に基づいて、前記フィードバック情報の送信に使用する上りリンク無線リソースを前記リソースプールの中から選択することを特徴とする請求項１に記載のユーザ端末。
【請求項５】
前記送信部は、前記ユーザ端末がＲＲＣアイドル状態にある場合において、前記リソースプールの中から選択された上りリンク無線リソースを使用して前記フィードバック情報を送信することを特徴とする請求項１に記載のユーザ端末。
【請求項６】
前記送信部は、タイミングアドバンス調整を行うことなく、前記ＲＲＣアイドル状態における前記フィードバック情報の送信を行うことを特徴とする請求項５に記載のユーザ端末。
【請求項７】
前記リソースプールには、周波数方向及び／又は時間方向における送信誤差を許容するためのガード領域が設けられることを特徴とする請求項５に記載のユーザ端末。
【請求項８】
前記受信部は、前記リソースプールに関する設定情報を前記基地局から受信し、
前記設定情報は、前記フィードバック情報の送信に適用される開ループ送信電力制御パラメータを含むことを特徴とする請求項５に記載のユーザ端末。
【請求項９】
前記送信部は、前記ＲＲＣアイドル状態における前記フィードバック情報の送信の必要性が前記基地局から通知された場合に限り、前記ＲＲＣアイドル状態における前記フィードバック情報の送信を行うことを特徴とする請求項５に記載のユーザ端末。
【請求項１０】
前記フィードバック情報は、複数のインデックス値のうち１つであり、
前記基地局から前記ユーザ端末に対して、前記複数のインデックス値に対応する複数のリソースプールが割り当てられ、
前記フィードバック情報として所定のインデックス値を前記基地局に送信する場合、前記制御部は、前記複数のリソースプールのうち前記所定のインデックス値に対応するリソースプールを選択することを特徴とする請求項１に記載のユーザ端末。
【請求項１１】
前記複数のリソースプールのそれぞれに、前記複数のユーザ端末に共通の無線リソース及び／又は前記複数のユーザ端末に共通の信号系列が対応付けられ、
前記送信部は、前記選択されたリソースプールに対応する前記共通の無線リソース及び／又は前記共通の信号系列を使用して、前記フィードバック情報を前記基地局に送信することを特徴とする請求項１０に記載のユーザ端末。
【請求項１２】
複数のユーザ端末からなるグループに対して、フィードバック情報の送信に使用可能なリソースプールを割り当てる制御部と、
同一の下りリンク無線リソースを使用して前記複数のユーザ端末にマルチキャスト／ブロードキャストデータを送信する送信部と、
前記リソースプールの中から選択された上りリンク無線リソースを使用して送信される前記フィードバック情報を前記複数のユーザ端末から受信する受信部と、を備え、
前記制御部は、上りリンクの負荷状態と関連するパラメータに基づいて、前記リソースプールを使用して前記フィードバック情報を送信する第１のモードから、前記基地局から各ユーザ端末に個別に割り当てられる物理上りリンク制御チャネルを使用して前記フィードバック情報を送信する第２のモードに切り替えるか否かを判断し、判断結果を前記複数のユーザ端末に通知することを特徴とする基地局。
【請求項１３】
前記リソースプールは、自基地局から各ユーザ端末に個別に割り当てる物理上りリンク制御チャネルとは異なる上りリンク無線リソースからなることを特徴とする請求項１２に記載の基地局。
【請求項１４】
前記送信部は、前記リソースプールに関する設定情報を前記複数のユーザ端末に送信し、
前記設定情報は、時間軸上における基準点と前記リソースプールの始点との間の差分、周波数軸上における基準点と前記リソースプールの始点との間の差分、時間軸上における前記リソースプールの範囲、周波数軸上における前記リソースプールの範囲、のうち少なくとも１つを含むことを特徴とする請求項１２に記載の基地局。
【請求項１５】
同一の下りリンク無線リソースを使用して基地局から複数のユーザ端末に送信されるマルチキャスト／ブロードキャストデータを受信するステップと、
前記複数のユーザ端末からなるグループに対して前記基地局から割り当てられたリソースプールの中から、フィードバック情報の送信に使用する上りリンク無線リソースを選択するステップと、
前記選択された上りリンク無線リソースを使用して、前記フィードバック情報を前記基地局に送信するステップと、
前記基地局からの通知を受信することに応じて、前記リソースプールを使用して前記フィードバック情報を送信する第１のモードから、前記基地局から各ユーザ端末に個別に割り当てられる物理上りリンク制御チャネルを使用して前記フィードバック情報を送信する第２のモードに切り替えるステップと、を備えることを特徴とするユーザ端末の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、移動通信システムにおけるユーザ端末及び基地局に関する。
【背景技術】
【０００２】
移動通信システムにおいて、ユーザ端末と基地局との間の下りリンクには、ユニキャスト（ＰＴＰ：Ｐｏｉｎｔ  Ｔｏ  Ｐｏｉｎｔ）伝送が適用されることが一般的である。【０００３】
下りリンクのユニキャスト伝送において、ユーザ端末は、下りリンクに関するフィードバック情報を基地局に送信する。フィードバック情報とは、下りリンクデータを正しく受信したか否かを示す送達確認情報（ＡＣＫ／ＮＡＣＫ）、及び下りリンクのチャネル状態を示すチャネル状態情報（ＣＳＩ）である。基地局は、フィードバック情報に基づいて、下りリンクデータの送信を制御する。【０００４】
近年では、マルチキャスト／ブロードキャスト（ＰＴＭ：Ｐｏｉｎｔ  Ｔｏ  Ｍｕｌｔｉｐｏｉｎｔ）伝送が注目されている（例えば、非特許文献１参照）。【０００５】
下りリンクのマルチキャスト／ブロードキャスト伝送において、基地局は、同一の下りリンク無線リソースを使用して、複数のユーザ端末に同一の下りリンクデータ（以下、適宜「マルチキャスト／ブロードキャストデータ」という）を送信する。マルチキャスト／ブロードキャスト伝送は、ユニキャスト伝送に比べて、下りリンク無線リソースの利用効率を高めることができる。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】３ＧＰＰ寄書「ＲＰ−１４２２０５」
【発明の概要】
【０００７】
第１の側面に係るユーザ端末は、同一の下りリンク無線リソースを使用して基地局から複数のユーザ端末に送信されるマルチキャスト／ブロードキャストデータを受信する受信部と、前記基地局と自ユーザ端末との間の無線状態が閾値よりも悪い場合、下りリンクに関するフィードバック情報を前記基地局に送信する送信部と、前記無線状態が前記閾値よりも良い場合、前記フィードバック情報の送信を停止する制御部と、を備える。
【０００８】
第２の側面に係る基地局は、同一の下りリンク無線リソースを使用して複数のユーザ端末にマルチキャスト／ブロードキャストデータを送信する送信部と、前記複数のユーザ端末のうち特定ユーザ端末からのみ、下りリンクに関するフィードバック情報を受信する受信部と、前記フィードバック情報に基づいて、前記マルチキャスト／ブロードキャストデータの送信を制御する制御部と、を備える。前記特定ユーザ端末とは、自基地局との間の無線状態が閾値よりも悪いユーザ端末である。
【０００９】
第３の側面に係るユーザ端末は、同一の下りリンク無線リソースを使用して基地局から複数のユーザ端末に送信されるマルチキャスト／ブロードキャストデータを受信する受信部と、前記複数のユーザ端末からなるグループに対して前記基地局から割り当てられたリソースプールの中から、前記フィードバック情報の送信に使用する上りリンク無線リソースを選択する制御部と、前記選択された上りリンク無線リソースを使用して、前記フィードバック情報を前記基地局に送信する送信部と、を備える。
【００１０】
第４の側面に係る基地局は、複数のユーザ端末からなるグループに対して、フィードバック情報の送信に使用可能なリソースプールを割り当てる制御部と、同一の下りリンク無線リソースを使用して前記複数のユーザ端末にマルチキャスト／ブロードキャストデータを送信する送信部と、前記リソースプールの中から選択された上りリンク無線リソースを使用して送信される前記フィードバック情報を前記複数のユーザ端末から受信する受信部と、を備える。
【００１１】
第５の側面に係るユーザ端末は、下りリンクのユニキャスト伝送が適用される場合、下りリンクデータを正しく受信したことを示す肯定応答及び下りリンクデータの受信に失敗したことを示す否定応答の何れかをフィードバック情報として基地局に送信する送信部と、下りリンクのマルチキャスト／ブロードキャスト伝送が適用される場合、前記肯定応答及び前記否定応答のうち前記否定応答のみをフィードバック情報として基地局に送信するように、前記肯定応答の送信を停止する制御部と、を備える。
【００１２】
第６の側面に係る基地局は、下りリンクのユニキャスト伝送が適用される場合、下りリンクデータを正しく受信したことを示す肯定応答及び下りリンクデータの受信に失敗したことを示す否定応答の何れかをフィードバック情報としてユーザ端末から受信する受信部を備える。下りリンクのマルチキャスト／ブロードキャスト伝送が適用される場合、前記受信部は、前記肯定応答及び前記否定応答のうち前記否定応答のみをフィードバック情報としてユーザ端末から受信する。
【００１３】
第７の側面に係るユーザ端末は、複数のユーザ端末に対するマルチキャスト／ブロードキャスト送信をサポートする移動通信システムにおいて用いられる。前記ユーザ端末は、ＲＲＣアイドル状態においてマルチキャスト／ブロードキャストデータを受信する受信部と、前記マルチキャスト／ブロードキャストデータの受信状態に基づいて、前記ＲＲＣアイドル状態からＲＲＣコネクティッド状態に遷移するための接続要求メッセージを基地局に送信する送信部と、前記マルチキャスト／ブロードキャストデータに関する情報を前記接続要求メッセージに含める制御部と、を備える。
【００１４】
第８の側面に係る基地局は、複数のユーザ端末に対するマルチキャスト／ブロードキャスト送信を行う。前記基地局は、ＲＲＣアイドル状態においてマルチキャスト／ブロードキャストデータを受信するユーザ端末から、ＲＲＣコネクティッド状態に遷移するための接続要求メッセージを受信する受信部を備える。前記接続要求メッセージは、前記マルチキャスト／ブロードキャストデータの受信状態に基づいて前記ユーザ端末から送信される。前記接続要求メッセージは、前記マルチキャスト／ブロードキャストデータに関する情報を含む。
【図面の簡単な説明】
【００１５】
【図１】第１実施形態乃至第４実施形態に係るＬＴＥシステムの構成図である。
【図２】第１実施形態乃至第４実施形態に係る無線インターフェイスのプロトコルスタック図である。
【図３】第１実施形態乃至第４実施形態に係る無線フレームの構成図である。
【図４】第１実施形態乃至第４実施形態に係るＵＥのブロック図である。
【図５】第１実施形態乃至第４実施形態に係るｅＮＢのブロック図である。
【図６】第１実施形態乃至第４実施形態に係るＳＣＰＴＭ関連動作を説明するための図である。
【図７】第１実施形態に係る動作シーケンスの一例を示す図である。
【図８】第２実施形態に係るフィードバック用リソースプールの一例を示す図である。
【図９】第２実施形態に係る動作シーケンスの一例を示す図である。
【図１０】第３実施形態に係る動作シーケンスの一例を示す図である。
【図１１】第４実施形態に係る動作シーケンスの一例を示す図である。
【発明を実施するための形態】
【００１６】
［実施形態の概要］
上述したマルチキャスト／ブロードキャスト伝送の信頼性を高めるために、上述したユニキャスト伝送におけるフィードバックの仕組みをマルチキャスト／ブロードキャスト伝送に導入する場合を想定する。
【００１７】
この場合、多数のユーザ端末が１つの基地局にフィードバック情報を送信し得る。その結果、フィードバック制御が複雑になるとともに、上りリンク無線リソースが逼迫する虞がある。
【００１８】
そこで、実施形態は、マルチキャスト／ブロードキャスト伝送において効率的なフィードバックを可能とするユーザ端末及び基地局を提供する。
【００１９】
第１実施形態に係るユーザ端末は、同一の下りリンク無線リソースを使用して基地局から複数のユーザ端末に送信されるマルチキャスト／ブロードキャストデータを受信する受信部と、前記基地局と自ユーザ端末との間の無線状態が閾値よりも悪い場合、下りリンクに関するフィードバック情報を前記基地局に送信する送信部と、前記無線状態が前記閾値よりも良い場合、前記フィードバック情報の送信を停止する制御部と、を備える。
【００２０】
第１実施形態において、前記受信部は、前記閾値を設定するための設定情報を前記基地局から受信する。前記制御部は、前記設定情報に基づいて前記閾値を設定する。
【００２１】
第１実施形態において、前記送信部は、前記無線状態が前記閾値よりも悪化した際に、前記フィードバック情報の送信に使用する上りリンク無線リソースの割り当てを要求するための第１の情報を前記基地局に送信する。
【００２２】
第１実施形態において、前記送信部は、前記無線状態が前記閾値よりも良化した際に、前記上りリンク無線リソースの解放を要求するための第２の情報を前記基地局に送信する。
【００２３】
第１実施形態において、前記制御部は、前記基地局からの通知に応じて、前記フィードバック情報の送信停止を有効化する第１のモードから、前記フィードバック情報の送信停止を無効化する第２のモードに切り替える。
【００２４】
第１実施形態に係る基地局は、同一の下りリンク無線リソースを使用して複数のユーザ端末にマルチキャスト／ブロードキャストデータを送信する送信部と、前記複数のユーザ端末のうち特定ユーザ端末からのみ、下りリンクに関するフィードバック情報を受信する受信部と、前記フィードバック情報に基づいて、前記マルチキャスト／ブロードキャストデータの送信を制御する制御部と、を備える。前記特定ユーザ端末とは、自基地局との間の無線状態が閾値よりも悪いユーザ端末である。
【００２５】
第１実施形態において、前記送信部は、前記閾値を設定するための設定情報を前記複数のユーザ端末に送信する。
【００２６】
第１実施形態において、前記受信部は、前記フィードバック情報の送信に使用する上りリンク無線リソースの割り当てを要求するための第１の情報を前記特定ユーザ端末から受信する。前記制御部は、前記第１の情報の受信に応じて、前記上りリンク無線リソースを前記特定ユーザ端末に割り当てる。
【００２７】
第１実施形態において、前記受信部は、前記上りリンク無線リソースの解放を要求するための第２の情報を前記特定ユーザ端末から受信する。前記制御部は、前記第２の情報の受信に応じて、前記上りリンク無線リソースを解放する。
【００２８】
第１実施形態において、前記受信部は、複数の特定ユーザ端末から複数のフィードバック情報を受信する。前記制御部は、前記複数のフィードバック情報に基づいて、前記複数の特定ユーザ端末のうち前記無線状態が最も悪い特定ユーザ端末を選出し、選出した特定ユーザ端末のフィードバック情報に従って前記マルチキャスト／ブロードキャストデータの送信を制御する。
【００２９】
第１実施形態において、前記制御部は、上りリンクの負荷状態と関連するパラメータに基づいて、前記特定ユーザ端末からのみ前記フィードバック情報を受信する第１のモードから、前記複数のユーザ端末の全てから前記フィードバック情報を受信する第２のモードに切り替えるか否かを判断し、判断結果を前記複数のユーザ端末に通知する。
【００３０】
第２実施形態に係るユーザ端末は、同一の下りリンク無線リソースを使用して基地局から複数のユーザ端末に送信されるマルチキャスト／ブロードキャストデータを受信する受信部と、前記複数のユーザ端末からなるグループに対して前記基地局から割り当てられたリソースプールの中から、前記フィードバック情報の送信に使用する上りリンク無線リソースを選択する制御部と、前記選択された上りリンク無線リソースを使用して、前記フィードバック情報を前記基地局に送信する送信部と、を備える。
【００３１】
第２実施形態において、前記リソースプールは、前記基地局から各ユーザ端末に個別に割り当てられる物理上りリンク制御チャネルとは異なる上りリンク無線リソースからなる。
【００３２】
第２実施形態において、前記受信部は、前記リソースプールに関する設定情報を前記基地局から受信する。前記設定情報は、時間軸上における基準点と前記リソースプールの始点との間の差分、周波数軸上における基準点と前記リソースプールの始点との間の差分、時間軸上における前記リソースプールの範囲、周波数軸上における前記リソースプールの範囲、のうち少なくとも１つを含む。
【００３３】
前記設定情報で指定されるリソースプールは、例えば異なる時間リソースにおいて異なる周波数リソースを組み合わせた所定のパターンを示してもよい。
【００３４】
第２実施形態において、前記制御部は、前記基地局から自ユーザ端末に割り当てられた固有情報、又は自ユーザ端末に予め設定されている固有情報に基づいて、前記フィードバック情報の送信に使用する上りリンク無線リソースを前記リソースプールの中から選択する。
【００３５】
第２実施形態において、前記制御部は、前記基地局からの通知に応じて、前記リソースプールを使用して前記フィードバック情報を送信する第１のモードから、前記基地局から各ユーザ端末に個別に割り当てられる物理上りリンク制御チャネルを使用して前記フィードバック情報を送信する第２のモードに切り替える。
【００３６】
第２実施形態に係る基地局は、複数のユーザ端末からなるグループに対して、フィードバック情報の送信に使用可能なリソースプールを割り当てる制御部と、同一の下りリンク無線リソースを使用して前記複数のユーザ端末にマルチキャスト／ブロードキャストデータを送信する送信部と、前記リソースプールの中から選択された上りリンク無線リソースを使用して送信される前記フィードバック情報を前記複数のユーザ端末から受信する受信部と、を備える。
【００３７】
第２実施形態において、前記リソースプールは、自基地局から各ユーザ端末に個別に割り当てる物理上りリンク制御チャネルとは異なる上りリンク無線リソースからなる。
【００３８】
第２実施形態において、前記送信部は、前記リソースプールに関する設定情報を前記複数のユーザ端末に送信する。前記設定情報は、時間軸上における基準点と前記リソースプールの始点との間の差分、周波数軸上における基準点と前記リソースプールの始点との間の差分、時間軸上における前記リソースプールの範囲、周波数軸上における前記リソースプールの範囲、のうち少なくとも１つを含む。
【００３９】
前記設定情報で指定されるリソースプールは、例えば異なる時間リソースにおいて異なる周波数リソースを組み合わせた所定のパターンを示してもよい。
【００４０】
第２実施形態において、前記制御部は、上りリンクの負荷状態と関連するパラメータに基づいて、前記リソースプールを使用して前記フィードバック情報を送信する第１のモードから、前記基地局から各ユーザ端末に個別に割り当てられる物理上りリンク制御チャネルを使用して前記フィードバック情報を送信する第２のモードに切り替えるか否かを判断し、判断結果を前記複数のユーザ端末に通知する。
【００４１】
第２実施形態において、前記フィードバック情報は、複数のインデックス値のうち１つである。前記基地局から前記ユーザ端末に対して、前記複数のインデックス値に対応する複数のリソースプールが割り当てられる。前記フィードバック情報として所定のインデックス値を前記基地局に送信する場合、前記制御部は、前記複数のリソースプールのうち前記所定のインデックス値に対応するリソースプールを選択する。
【００４２】
第２実施形態において、前記複数のリソースプールのそれぞれに、前記複数のユーザ端末に共通の無線リソース及び／又は前記複数のユーザ端末に共通の信号系列が対応付けられる。前記送信部は、前記選択されたリソースプールに対応する前記共通の無線リソース及び／又は前記共通の信号系列を使用して、前記フィードバック情報を前記基地局に送信する。
【００４３】
第３実施形態に係るユーザ端末は、下りリンクのユニキャスト伝送が適用される場合、下りリンクデータを正しく受信したことを示す肯定応答及び下りリンクデータの受信に失敗したことを示す否定応答の何れかをフィードバック情報として基地局に送信する送信部と、下りリンクのマルチキャスト／ブロードキャスト伝送が適用される場合、前記肯定応答及び前記否定応答のうち前記否定応答のみをフィードバック情報として基地局に送信するように、前記肯定応答の送信を停止する制御部と、を備える。
【００４４】
第３実施形態において、前記マルチキャスト／ブロードキャスト伝送が適用される場合、前記送信部は、前記基地局と前記マルチキャスト／ブロードキャスト伝送を行う複数のユーザ端末で共通の無線リソース、且つ共通の信号系列を使用して、前記否定応答を送信する。
【００４５】
第３実施形態において、前記マルチキャスト／ブロードキャスト伝送が適用される場合、前記送信部は、前記複数のユーザ端末で共通の無線リソース、且つ共通の信号系列を使用して、前記否定応答の復調参照信号を送信する。
【００４６】
第３実施形態において、前記マルチキャスト／ブロードキャスト伝送が適用される場合、前記制御部は、前記基地局からの通知に応じて、前記否定応答のみをフィードバック情報として基地局に送信する第１のモードから、前記肯定応答及び前記否定応答の何れかをフィードバック情報として基地局に送信する第２のモードに切り替える。
【００４７】
第３実施形態において、前記送信部は、前記否定応答とは異なる通知情報を前記基地局にさらに送信する。前記通知情報は、前記マルチキャスト／ブロードキャスト伝送に適用する変調方式及び／又は符号化方式の変更禁止を前記ユーザ端末が希望することを示す情報、又は前記変調方式及び／又は前記符号化方式の変更を前記ユーザ端末が希望することを示す情報である。
【００４８】
第３実施形態に係る基地局は、下りリンクのユニキャスト伝送が適用される場合、下りリンクデータを正しく受信したことを示す肯定応答及び下りリンクデータの受信に失敗したことを示す否定応答の何れかをフィードバック情報としてユーザ端末から受信する受信部を備える。下りリンクのマルチキャスト／ブロードキャスト伝送が適用される場合、前記受信部は、前記肯定応答及び前記否定応答のうち前記否定応答のみをフィードバック情報としてユーザ端末から受信する。
【００４９】
第３実施形態において、前記基地局は、前記マルチキャスト／ブロードキャスト伝送が適用される場合、自基地局と前記マルチキャスト／ブロードキャスト伝送を行う複数のユーザ端末に対して、前記否定応答の送信用に共通の無線リソース、且つ共通の信号系列を割り当てる制御部を備える。
【００５０】
第３実施形態において、前記マルチキャスト／ブロードキャスト伝送が適用される場合、前記制御部は、前記複数のユーザ端末に対して、前記否定応答の復調参照信号の送信用に共通の無線リソース、且つ共通の信号系列を割り当てる。
【００５１】
第３実施形態において、前記マルチキャスト／ブロードキャスト伝送が適用される場合、上りリンクの負荷状態と関連するパラメータに基づいて、前記否定応答のみをフィードバック情報として送信する第１のモードから、前記肯定応答及び前記否定応答の何れかをフィードバック情報として送信する第２のモードに切り替えるか否かを判断し、判断結果を前記複数のユーザ端末に通知する。
【００５２】
［第１実施形態］
以下において、３ＧＰＰ規格に基づく移動通信システムであるＬＴＥシステムに本発明を適用する場合の実施形態を説明する。
【００５３】
（ＬＴＥシステムの概要）
先ず、ＬＴＥシステムのシステム構成について説明する。図１は、ＬＴＥシステムの構成図である。
【００５４】
図１に示すように、ＬＴＥシステムは、ＵＥ（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）１００、Ｅ−ＵＴＲＡＮ（Ｅｖｏｌｖｅｄ−ＵＭＴＳ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）１０、及びＥＰＣ（Ｅｖｏｌｖｅｄ  Ｐａｃｋｅｔ  Ｃｏｒｅ）２０を備える。
【００５５】
ＵＥ１００は、ユーザ端末に相当する。ＵＥ１００は、移動型の通信装置であり、セル（サービングセル）との無線通信を行う。ＵＥ１００の構成については後述する。
【００５６】
Ｅ−ＵＴＲＡＮ１０は、無線アクセスネットワークに相当する。Ｅ−ＵＴＲＡＮ１０は、ｅＮＢ２００（ｅｖｏｌｖｅｄ  Ｎｏｄｅ−Ｂ）を含む。ｅＮＢ２００は、基地局に相当する。ｅＮＢ２００は、Ｘ２インターフェイスを介して相互に接続される。ｅＮＢ２００の構成については後述する。
【００５７】
ｅＮＢ２００は、１又は複数のセルを管理しており、自セルとの接続を確立したＵＥ１００との無線通信を行う。ｅＮＢ２００は、無線リソース管理（ＲＲＭ）機能、ユーザデータ（以下、単に「データ」という）のルーティング機能、モビリティ制御・スケジューリングのための測定制御機能等を有する。「セル」は、無線通信エリアの最小単位を示す用語として使用される他に、ＵＥ１００との無線通信を行う機能を示す用語としても使用される。
【００５８】
ＥＰＣ２０は、コアネットワークに相当する。ＥＰＣ２０は、ＭＭＥ（Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ）／Ｓ−ＧＷ（Ｓｅｒｖｉｎｇ−Ｇａｔｅｗａｙ）３００を含む。ＭＭＥは、ＵＥ１００に対する各種モビリティ制御等を行う。Ｓ−ＧＷは、データの転送制御を行う。ＭＭＥ／Ｓ−ＧＷ３００は、Ｓ１インターフェイスを介してｅＮＢ２００と接続される。Ｅ−ＵＴＲＡＮ１０及びＥＰＣ２０は、ネットワークを構成する。
【００５９】
また、Ｅ−ＵＴＲＡＮ１０は、ＭＣＥ（Ｍｕｌｔｉ−Ｃｅｌｌ／Ｍｕｌｔｉｃａｓｔ  Ｃｏｏｒｄｉｎａｔｉｎｇ  Ｅｎｔｉｔｙ）を含む。ＭＣＥは、Ｍ２インターフェイスを介してｅＮＢ２００と接続され、Ｍ３インターフェイスを介してＭＭＥ３００と接続される。ＭＣＥは、ＭＢＳＦＮ無線リソース管理・割当等を行う。
【００６０】
ＥＰＣ２０は、ＭＢＭＳ  ＧＷ（Ｍｕｌｔｉｍｅｄｉａ  Ｂｒｏａｄｃａｓｔ  Ｍｕｌｔｉｃａｓｔ  Ｓｅｒｖｉｃｅ  Ｇａｔｅｗａｙ）を含む。ＭＢＭＳ  ＧＷは、Ｍ１インターフェイスを介してｅＮＢ２００と接続され、Ｓｍインターフェイスを介してＭＭＥ３００と接続され、ＳＧ−ｍｂ及びＳＧｉ−ｍｂインターフェイスを介してＢＭ−ＳＣ（後述）と接続される。ＭＢＭＳ  ＧＷは、ＭＢＭＳ用のＳ−ＧＷのような役割を果たし、ｅＮＢ２００に対してＩＰマルチキャストのデータ伝送やセッション制御を行う。
【００６１】
また、ＥＰＣ２０は、ＢＭ−ＳＣ（Ｂｒｏａｄｃａｓｔ  Ｍｕｌｔｉｃａｓｔ  Ｓｅｒｖｉｃｅ  Ｃｅｎｔｅｒ）を含む。ＢＭ−ＳＣは、ＳＧ−ｍｂ及びＳＧｉ−ｍｂインターフェイスを介してＭＢＭＳ  ＧＷと接続され、ＳＧｉインターフェイスを介してＰ−ＧＷと接続される。ＢＭ−ＳＣは、ＭＢＭＳ用のＰ−ＧＷのような役割を果たし、主にＴＭＧＩ（Ｔｅｍｐｏｒａｒｙ  Ｍｏｂｉｌｅ  Ｇｒｏｕｐ  Ｉｄｅｎｔｉｔｙ）の管理・割当等を行う。
【００６２】
さらに、ＥＰＣ２０の外部（すなわち、インターネット）には、ＧＣＳ  ＡＳ（Ｇｒｏｕｐ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｓｅｒｖｉｃｅ  Ａｐｐｌｉｃａｔｉｏｎ  Ｓｅｒｖｅｒ）が設けられる。ＧＣＳ  ＡＳは、グループ通信用のアプリケーションサーバーである。ＧＣＳ  ＡＳは、ＭＢ２−Ｕ及びＭＢ２−Ｃインターフェイスを介してＢＭ−ＳＣと接続され、ＳＧｉインターフェイスを介してＰ−ＧＷと接続される。ＧＣＳ  ＡＳは、グループ通信におけるグループの管理やデータ配信（ＭＢＭＳを使うか、ユニキャストを使うかの判断も含む）等を行う。
【００６３】
図２は、ＬＴＥシステムにおける無線インターフェイスのプロトコルスタック図である。図２に示すように、無線インターフェイスプロトコルは、ＯＳＩ参照モデルの第１層乃至第３層に区分されており、第１層は物理（ＰＨＹ）層である。第２層は、ＭＡＣ（Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）層、ＲＬＣ（Ｒａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ）層、及びＰＤＣＰ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｃｏｎｖｅｒｇｅｎｃｅ  Ｐｒｏｔｏｃｏｌ）層を含む。第３層は、ＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）層を含む。
【００６４】
物理層は、符号化・復号、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行う。ＵＥ１００の物理層とｅＮＢ２００の物理層との間では、物理チャネルを介してデータ及び制御信号が伝送される。
【００６５】
ＭＡＣ層は、データの優先制御、ハイブリッドＡＲＱ（ＨＡＲＱ）による再送処理、及びランダムアクセス手順等を行う。ＵＥ１００のＭＡＣ層とｅＮＢ２００のＭＡＣ層との間では、トランスポートチャネルを介してデータ及び制御信号が伝送される。ｅＮＢ２００のＭＡＣ層は、上下リンクのトランスポートフォーマット（トランスポートブロックサイズ、変調・符号化方式（ＭＣＳ））及びＵＥ１００への割当リソースブロックを決定するスケジューラを含む。
【００６６】
ＲＬＣ層は、ＭＡＣ層及び物理層の機能を利用してデータを受信側のＲＬＣ層に伝送する。ＵＥ１００のＲＬＣ層とｅＮＢ２００のＲＬＣ層との間では、論理チャネルを介してデータ及び制御信号が伝送される。
【００６７】
ＰＤＣＰ層は、ヘッダ圧縮・伸張、及び暗号化・復号化を行う。
【００６８】
ＲＲＣ層は、制御信号を取り扱う制御プレーンでのみ定義される。ＵＥ１００のＲＲＣ層とｅＮＢ２００のＲＲＣ層との間では、各種設定のためのメッセージ（ＲＲＣメッセージ）が伝送される。ＲＲＣ層は、無線ベアラの確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。ＵＥ１００のＲＲＣとｅＮＢ２００のＲＲＣとの間に接続（ＲＲＣ接続）がある場合、ＵＥ１００はＲＲＣコネクティッド状態であり、そうでない場合、ＵＥ１００はＲＲＣアイドル状態である。
【００６９】
ＲＲＣ層の上位に位置するＮＡＳ（Ｎｏｎ−Ａｃｃｅｓｓ  Ｓｔｒａｔｕｍ）層は、セッション管理及びモビリティ管理等を行う。
【００７０】
図３は、ＬＴＥシステムで使用される無線フレームの構成図である。ＬＴＥシステムは、下りリンクにはＯＦＤＭＡ（Ｏｒｔｈｏｇｏｎａｌ  Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅｘｉｎｇ  Ａｃｃｅｓｓ）、上りリンクにはＳＣ−ＦＤＭＡ（Ｓｉｎｇｌｅ  Ｃａｒｒｉｅｒ  Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ）がそれぞれ適用される。
【００７１】
図３に示すように、無線フレームは、時間方向に並ぶ１０個のサブフレームで構成される。各サブフレームは、時間方向に並ぶ２個のスロットで構成される。各サブフレームの長さは１ｍｓであり、各スロットの長さは０．５ｍｓである。各サブフレームは、周波数方向に複数個のリソースブロック（ＲＢ）を含み、時間方向に複数個のシンボルを含む。各リソースブロックは、周波数方向に複数個のサブキャリアを含む。１つのシンボル及び１つのサブキャリアにより１つのリソースエレメント（ＲＥ）が構成される。また、ＵＥ１００に割り当てられる無線リソース（時間・周波数リソース）のうち、周波数リソースはリソースブロックにより特定でき、時間リソースはサブフレーム（又はスロット）により特定できる。
【００７２】
下りリンクにおいて、各サブフレームの先頭数シンボルの区間は、主に下りリンク制御信号を伝送するための物理下りリンク制御チャネル（ＰＤＣＣＨ）として使用される領域である。また、各サブフレームの残りの部分は、主に下りリンクデータを伝送するための物理下りリンク共有チャネル（ＰＤＳＣＨ）として使用できる領域である。また、各サブフレームには、セル固有参照信号（ＣＲＳ：Ｃｅｌｌ  ｓｐｅｃｉｆｉｃ  Ｒｅｆｅｒｅｎｃｅ  Ｓｉｇｎａｌ）などの下りリンク参照信号が配置される。
【００７３】
上りリンクにおいて、各サブフレームにおける周波数方向の両端部は、主に上りリンク制御信号を伝送するための物理上りリンク制御チャネル（ＰＵＣＣＨ）として使用される領域である。各サブフレームにおける残りの部分は、主に上りリンクデータを伝送するための物理上りリンク共有チャネル（ＰＵＳＣＨ）として使用できる領域である。また、各サブフレームには、サウンディング参照信号（ＳＲＳ）などの上りリンク参照信号が配置される。
【００７４】
（ＵＥ１００の構成）
図４は、ＵＥ１００（ユーザ端末）の構成を示すブロック図である。図４に示すように、ＵＥ１００は、受信部１１０、送信部１２０、及び制御部１３０を備える。
【００７５】
受信部１１０は、制御部１３０の制御下で各種の受信を行う。受信部１１０は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換して制御部１３０に出力する。
【００７６】
送信部１２０は、制御部１３０の制御下で各種の送信を行う。送信部１２０は、アンテナ及び送信機を含む。送信機は、制御部１３０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。
【００７７】
制御部１３０は、ＵＥ１００における各種の制御を行う。制御部１３０は、プロセッサ及びメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に使用される情報を記憶する。プロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行うベースバンドプロセッサと、メモリに記憶されるプログラムを実行して各種の処理を行うＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）と、を含む。プロセッサは、音声・映像信号の符号化・復号を行うコーデックを含んでもよい。プロセッサは、後述する各種の処理及び上述した各種の通信プロトコルを実行する。
【００７８】
ＵＥ１００は、ユーザインターフェイス及びバッテリを備えてもよい。ユーザインターフェイスは、ＵＥ１００を所持するユーザとのインターフェイスであり、例えば、ディスプレイ、マイク、スピーカ、及び各種ボタン等を含む。ユーザインターフェイスは、ユーザからの操作を受け付けて、該操作の内容を示す信号を制御部１３０に出力する。バッテリは、ＵＥ１００の各ブロックに供給すべき電力を蓄える。
【００７９】
（ｅＮＢ２００の構成）
図５は、ｅＮＢ２００（基地局）のブロック図である。図５に示すように、ｅＮＢ２００は、送信部２１０、受信部２２０、制御部２３０、及びバックホール通信部２４０を備える。
【００８０】
送信部２１０は、制御部２３０の制御下で各種の送信を行う。送信部２１０は、アンテナ及び送信機を含む。送信機は、制御部１３０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。
【００８１】
受信部２２０は、制御部２３０の制御下で各種の受信を行う。受信部２２０は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換して制御部２３０に出力する。
【００８２】
制御部２３０は、ｅＮＢ２００における各種の制御を行う。制御部２３０は、プロセッサ及びメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に使用される情報を記憶する。プロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行うベースバンドプロセッサと、メモリに記憶されるプログラムを実行して各種の処理を行うＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）と、を含む。プロセッサは、後述する各種の処理及び上述した各種の通信プロトコルを実行する。
【００８３】
バックホール通信部２４０は、Ｘ２インターフェイスを介して隣接ｅＮＢ２００と接続され、Ｓ１インターフェイスを介してＭＭＥ／Ｓ−ＧＷ３００と接続される。バックホール通信部２４０は、Ｘ２インターフェイス上で行う通信及びＳ１インターフェイス上で行う通信等に使用される。
【００８４】
（ユニキャスト伝送）
ＬＴＥシステムにおいて、ＵＥ１００とｅＮＢ２００との間の下りリンクには、ユニキャスト（ＰＴＰ：Ｐｏｉｎｔ  Ｔｏ  Ｐｏｉｎｔ）伝送が適用されることが一般的である。下りリンクのユニキャスト伝送において、ｅＮＢ２００は、ＵＥ１００からのフィードバック情報に基づいて、ＵＥ１００への下りリンクデータの送信を制御する。ＵＥ１００は、下りリンクに関するフィードバック情報をｅＮＢ２００に送信する。フィードバック情報とは、送達確認情報（ＡＣＫ／ＮＡＣＫ）及びチャネル状態情報（ＣＳＩ）である。
【００８５】
下りリンクにおいて、ｅＮＢ２００は、ＰＤＣＣＨを使用して下りリンク制御信号（ＤＣＩ：Ｄｏｗｎｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｉｎｆｏｒｍａｔｉｏｎ）をＵＥ１００に送信し、ＰＤＳＣＨを使用して下りリンク制御信号及び／又は下りリンクデータをＵＥ１００に送信する。ＰＤＣＣＨが搬送する下りリンク制御信号は、上りリンクＳＩ（Ｓｃｈｅｄｕｌｉｎｇ  Ｉｎｆｏｒｍａｔｉｏｎ）、下りリンクＳＩ、ＴＰＣビットを含む。上りリンクＳＩは上りリンク無線リソースの割当てに関するスケジューリング情報であり、下りリンクＳＩは、下りリンク無線リソースの割当てに関するスケジューリング情報である。ＴＰＣビットは、上りリンクの送信電力の増減を指示する情報である。ｅＮＢ２００は、下りリンク制御信号の送信先のＵＥ１００を識別するために、送信先のＵＥ１００の識別子（ＲＮＴＩ：Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｔｅｍｐｏｒａｒｙ  ＩＤ）でスクランブリングしたＣＲＣビットを下りリンク制御信号に含める。各ＵＥ１００は、自ＵＥ宛ての可能性がある下りリンク制御信号について、自ＵＥのＲＮＴＩでＣＲＣビットをデスクランブリングすることにより、ＰＤＣＣＨをブラインド復号（Ｂｌｉｎｄ  ｄｅｃｏｄｉｎｇ）して、自ＵＥ宛の下りリンク制御信号を検出する。ＰＤＳＣＨは、下りリンクＳＩが示す下りリンク無線リソース（リソースブロック）によりデータを搬送する。
【００８６】
上りリンクにおいて、ＵＥ１００は、ＰＵＣＣＨを使用して上りリンク制御信号をｅＮＢ２００に送信し、ＰＵＳＣＨを使用して上りリンク制御信号及び／又は上りリンクデータをｅＮＢ２００に送信する。ＰＵＣＣＨが運搬する上りリンク制御信号は、ＣＱＩ（Ｃｈａｎｎｅｌ  Ｑｕａｌｉｔｙ  Ｉｎｄｉｃａｔｏｒ）、ＰＭＩ（Ｐｒｅｃｏｄｉｎｇ  Ｍａｔｒｉｘ  Ｉｎｄｉｃａｔｏｒ）、ＲＩ（Ｒａｎｋ  Ｉｎｄｉｃａｔｏｒ）、ＳＲ（Ｓｃｈｅｄｕｌｉｎｇ  Ｒｅｑｕｅｓｔ）、ＡＣＫ／ＮＡＣＫを含む。ＣＱＩは、下りリンクのチャネル品質を示すインデックス値であり、下りリンク伝送に使用すべきＭＣＳの決定等に使用される。ＰＭＩは、下りリンクの伝送のために使用することが望ましいプレコーダマトリックスを示すインデックス値である。ＲＩは、下りリンクの伝送に使用可能なレイヤ数（ストリーム数）を示すインデックス値である。ＣＱＩ、ＰＭＩ、及びＲＩは、ＵＥ１００が下りリンク参照信号を利用してチャネル推定を行うことにより得られる情報であり、下りリンクのチャネル状態を示すチャネル状態情報（ＣＳＩ）である。ＳＲは、上りリンク無線リソース（リソースブロック）の割当てを要求する情報である。ＡＣＫ／ＮＡＣＫは、下りリンクデータを正しく受信したか否かを示す送達確認情報である。ＰＵＳＣＨは、主に上りリンクデータを搬送するが、上りリンク制御信号の搬送にも使用可能である。
【００８７】
（マルチキャスト／ブロードキャスト伝送）
ＬＴＥシステムにおいて、マルチキャスト／ブロードキャスト伝送を実現するために、ＭＢＭＳが規定されている。
【００８８】
ＭＢＭＳにおいて、複数のセルは、ＭＢＳＦＮ（Ｍｕｌｔｉｃａｓｔ−Ｂｒｏａｄｃａｓｔ  Ｓｉｎｇｌｅ−Ｆｒｅｑｕｅｎｃｙ  Ｎｅｔｗｏｒｋ）サブフレームと称される特別な下りリンクサブフレームを使用して、マルチキャスト／ブロードキャストデータを送信する。具体的には、同一のＭＢＳＦＮエリアに属する複数のセルは、同一のマルチキャスト／ブロードキャストデータを送信する。ＵＥ１００は、複数のセルから送信されるマルチキャスト／ブロードキャストデータを受信する。
【００８９】
このようなＭＢＭＳの仕組みにおいて、ＭＢＳＦＮサブフレームがＭＢＭＳ用となってしまうことに加えて、ＭＢＳＦＮサブフレームは動的に変更できない。よって、ＭＢＭＳは、無線リソースの無駄が生じ易い。
【００９０】
一方で、無線リソースの利用効率を高めつつマルチキャスト伝送を実現するために、単一セルＰＴＭ伝送（ＳＣＰＴＭ）の導入が検討されている。図６は、第１実施形態に係るＳＣＰＴＭ関連動作を説明するための図である。
【００９１】
図６に示すように、ＳＣＰＴＭにおいて、ｅＮＢ２００は、ＰＤＳＣＨを使用して、単一のセルによりマルチキャストデータを送信する。すなわち、ＭＢＳＦＮエリア単位でのマルチキャスト／ブロードキャスト伝送が適用されるＭＢＭＳとは異なり、ＳＣＰＴＭは、セル単位でのマルチキャスト／ブロードキャスト伝送が適用される。同一のマルチキャストデータを受信する複数のＵＥ１００（ＵＥ１００−１、ＵＥ１００−２…）は、ＵＥグループを構成する。当該ＵＥグループ内の各ＵＥ１００には、共通のグループ識別子（例えば、グループＲＮＴＩ）が割り当てられている。グループ識別子は、ｅＮＢ２００（又はＭＣＥ）により割り当てられる。或いは、グループ識別子は、コアネットワーク（ＥＰＣ２０）のエンティティにより割り当てられてもよい。或いは、グループ識別子は、アプリケーションサーバ（例えば、ＧＧＳ  ＡＳ）により割り当てられてもよい。
【００９２】
ｅＮＢ２００は、グループ識別子を使用して、ＵＥグループを構成する各ＵＥ１００に同一の下りリンク制御信号（下りリンクＳＩ等）及び下りリンクデータ（マルチキャストデータ）を送信する。例えば、ｅＮＢ２００は、グループ識別子でスクランブリングしたＣＲＣビットを下りリンク制御信号に含めて、ＰＤＣＣＨにより下りリンク制御信号を送信する。また、ｅＮＢ２００は、下りリンクＳＩが示す下りリンク無線リソース（少なくとも１つのリソースブロック）を使用して、ＰＤＳＣＨによりマルチキャストデータを送信する。
【００９３】
各ＵＥ１００は、グループ識別子でＣＲＣビットをデスクランブリングすることにより、ＰＤＣＣＨをブラインド復号（Ｂｌｉｎｄ  ｄｅｃｏｄｉｎｇ）して、自ＵＥ１００が属するＵＥグループ宛の下りリンク制御信号を検出する。そして、各ＵＥ１００は、ＰＤＣＣＨ（下りリンク制御信号）が示す下りリンク無線リソース（リソースブロック）を使用してマルチキャストデータを受信する。
【００９４】
このようなＳＣＰＴＭの仕組みは、ＰＤＳＣＨにおいてリソースブロック単位でのリソース割り当てが可能である。このため、必要最小限の無線リソースを使用してマルチキャストデータを送受信可能であり、かつ、割り当て無線リソースを動的又は準静的に変更可能である。よって、ＳＣＰＴＭは、ＭＢＭＳに比べて無線リソースの無駄が生じ難い。
【００９５】
（ＵＥ１００の動作）
以下において、ＳＣＰＴＭにフィードバックを導入する場合のＵＥ１００の動作について説明する。具体的には、図６において、ｅＮＢ２００と、ＵＥグループに含まれる１つのＵＥ１００（例えばＵＥ１００−１）との間の動作を説明する。
【００９６】
図６に示すように、ＵＥ１００の受信部１１０は、同一の下りリンク無線リソースを使用してｅＮＢ２００から複数のＵＥ１００に送信されるマルチキャストデータを受信する。同一の下りリンク無線リソースは、ＰＤＳＣＨに含まれる少なくとも１つのリソースブロックである。上述したように、複数のＵＥ１００は、同一のグループ識別子が割り当てられたＵＥグループを構成する。
【００９７】
ＵＥ１００の送信部１２０は、ｅＮＢ２００と自ＵＥ１００との間の無線状態が閾値よりも悪い場合、下りリンクに関するフィードバック情報をｅＮＢ２００に送信する。無線状態とは、例えば、受信部１１０がｅＮＢ２００から受信する下りリンク参照信号の受信電力（ＲＳＲＰ）及び／又は受信品質（ＲＳＲＱ）である。或いは、無線状態は、ＳＣＰＴＭで割り当てられたリソースにおける参照信号受信電力及び／又は参照信号受信品質であってもよい。或いは、帯域が所定のサブバンドに分割される場合、無線状態は、サブバンド毎に得られた参照信号受信電力のうちの最低値又は参照信号受信品質のうちの最低値であってもよい。フィードバック情報をｅＮＢ２００に送信する条件は、様々な無線状態を組み合わせた条件であってもよい。この条件はＡＮＤ条件であってもよいし、ＯＲ条件であってもよい。ＡＮＤ条件の例を挙げると、ＳＣＰＴＭで割り当てられたリソースにおける無線状態が第１の閾値よりも悪く、かつ、サブバンド毎に得られた無線状態のうちの最低値が第２の閾値よりも悪い場合に、フィードバック情報をｅＮＢ２００に送信するとしてもよい。
【００９８】
なお、「無線状態が閾値よりも悪い」とは、無線状態がＲＳＲＰ／ＲＳＲＱである場合には、ＲＳＲＰ／ＲＳＲＱが閾値よりも低いことを意味する。但し、「無線状態が閾値よりも悪い」とは、無線状態が干渉レベル、雑音レベル、又は誤り率である場合には、干渉レベル／雑音レベル／誤り率が閾値よりも高いことを意味する。
【００９９】
一方、「無線状態が閾値よりも良い」とは、無線状態がＲＳＲＰ／ＲＳＲＱである場合には、ＲＳＲＰ／ＲＳＲＱが閾値よりも高いことを意味する。但し、「無線状態が閾値よりも良い」とは、無線状態が干渉レベル、雑音レベル、又は誤り率である場合には、干渉レベル／雑音レベル／誤り率が閾値よりも低いことを意味する。
【０１００】
無線状態は、制御部１３０により測定される。また、下りリンクに関するフィードバック情報は、送達確認情報（ＡＣＫ／ＮＡＣＫ）及びチャネル状態情報（ＣＳＩ）であり、制御部１３０により生成される。ここでは、フィードバック情報が送達確認情報（ＡＣＫ／ＮＡＣＫ）である場合を主として想定する。
【０１０１】
ＵＥ１００の制御部１３０は、無線状態が閾値よりも良い場合、フィードバック情報の送信を停止する。
【０１０２】
このように、ＵＥ１００は、自身の無線状態が良好である場合、フィードバック情報の送信を停止する。すなわち、ＵＥ１００は、自身の無線状態が良好でない場合に限り、フィードバック情報をｅＮＢ２００に送信する。
【０１０３】
ＵＥ１００の無線状態が良好である場合、送達確認情報としてＡＣＫを送信する可能性が高いため、マルチキャストデータの再送の必要性が低い。また、ｅＮＢ２００は、無線状態の劣悪なＵＥ１００に適応させてマルチキャストデータを送信するため、ＵＥ１００の無線状態が良好である場合、リンクアダプテーションの必要性が低い。よって、無線状態が良好なＵＥ１００がフィードバック情報を送信しないことにより、フィードバックに伴う上りリンク無線リソース（例えば、ＰＵＣＣＨリソース）を節約することができる。
【０１０４】
ＵＥ１００の受信部１１０は、閾値を設定するための設定情報をｅＮＢ２００から受信する。制御部１３０は、当該設定情報に基づいて閾値を設定する。このように、ｅＮＢ２００が閾値を制御可能とすることにより、フィードバックに必要な上りリンク無線リソースの量をｅＮＢ２００の状況（上りリンクの負荷状態等）に応じて調整することができる。
【０１０５】
ここで、閾値の設定情報は、システム情報（ＳＩＢ）によりｅＮＢ２００からブロードキャスト伝送してもよいし、個別のＲＲＣメッセージによりｅＮＢ２００からユニキャスト伝送してもよい。或いは、閾値の設定情報は、グループＲＮＴＩでＣＲＣをスクランブルされたＤＣＩで伝送してもよい。閾値の設定情報は、閾値を直接的に示す情報であってもよいし、基準値に対する閾値の相対値（オフセット値）を示す情報であってもよい。
【０１０６】
ＵＥ１００の制御部１３０は、無線状態が閾値よりも悪化した際に、フィードバック情報の送信に使用する上りリンク無線リソースの割り当てを要求するための第１の情報をｅＮＢ２００に送信してもよい。例えば、第１の情報は、スケジューリング要求（ＳＲ）である。或いは、第１の情報は、ランダムアクセスプリアンブルであってもよい。或いは、第１の情報は、ＲＲＣメッセージ（割り当て要求）であってもよい。また、ＵＥ１００の制御部１３０は、無線状態が閾値よりも良化した際に、上りリンク無線リソースの解放を要求するための第２の情報をｅＮＢ２００に送信してもよい。これにより、フィードバック用リソースを常時割り当てる場合に比べて、フィードバックに伴う上りリンク無線リソースを節約することができる。或いは、制御部１３０は、無線状態が閾値よりも良化した際に、無線状態が閾値よりも良化したことを示す情報をｅＮＢ２００に送信してもよい。この場合、上りリンク無線リソースを解放するか否かはｅＮＢ２００の判断に委ねられる。
【０１０７】
（ｅＮＢ２００の動作）
以下において、ＳＣＰＴＭにフィードバックを導入する場合のｅＮＢ２００の動作について説明する。具体的には、図６において、ｅＮＢ２００と、ＵＥグループに含まれる１つのＵＥ１００（例えばＵＥ１００−１）との間の動作を説明する。
【０１０８】
図６に示すように、ｅＮＢ２００の送信部２１０は、同一の下りリンク無線リソースを使用して複数のＵＥ１００（ＵＥグループ）にマルチキャストデータを送信する。ｅＮＢ２００の受信部２２０は、複数のＵＥ１００のうち特定ＵＥ１００からのみ、下りリンクに関するフィードバック情報を受信する。特定ＵＥ１００とは、自ｅＮＢ２００との間の無線状態が閾値よりも悪いＵＥ１００である。ｅＮＢ２００の制御部２３０は、フィードバック情報に基づいて、マルチキャストデータの送信を制御する。
【０１０９】
このように、無線状態が良好ではないＵＥ１００のみからフィードバック情報を受信することにより、フィードバックに伴う上りリンク無線リソース（例えば、ＰＵＣＣＨリソース）を節約することができる。
【０１１０】
ｅＮＢ２００の送信部２１０は、閾値を設定するための設定情報を複数のＵＥ１００に送信する。このように、ｅＮＢ２００が閾値を制御可能とすることにより、フィードバックに必要な上りリンク無線リソースの量をｅＮＢ２００の状況（上りリンクの負荷状態等）に応じて調整することができる。上述したように、閾値の設定情報は、システム情報（ＳＩＢ）によりｅＮＢ２００からブロードキャスト伝送してもよいし、個別のＲＲＣメッセージによりｅＮＢ２００からユニキャスト伝送してもよいし、グループＲＮＴＩでＣＲＣをスクランブルされたＤＣＩで伝送してもよい。
【０１１１】
ｅＮＢ２００の受信部２２０は、フィードバック情報の送信に使用する上りリンク無線リソースの割り当てを要求するための第１の情報を特定ＵＥ１００から受信する。ｅＮＢ２００の制御部２３０は、第１の情報の受信に応じて、当該上りリンク無線リソースを特定ＵＥ１００に割り当てる。また、ｅＮＢ２００の受信部２２０は、上りリンク無線リソースの解放を要求するための第２の情報を特定ＵＥ１００から受信する。制御部２３０は、第２の情報の受信に応じて、当該上りリンク無線リソースを解放する。これにより、フィードバック用リソースを常時割り当てる場合に比べて、フィードバックに伴う上りリンク無線リソースを節約することができる。或いは、受信部２２０は、無線状態が閾値よりも良化したことを示す情報を特定ＵＥ１００から受信してもよい。
【０１１２】
ｅＮＢ２００の受信部２２０は、複数の特定ＵＥ１００から複数のフィードバック情報を受信し得る。この場合、ｅＮＢ２００の制御部２３０は、複数のフィードバック情報に基づいて、複数の特定ＵＥ１００のうち無線状態が最も悪い特定ＵＥ１００を選出し、選出した特定ＵＥ１００のフィードバック情報に従ってマルチキャストデータの送信を制御する。具体的には、ｅＮＢ２００の制御部２３０は、最悪の条件に合わせて、再送、リンクアダプテーション、送信ダイバーシチ／ＭＩＭＯストリーム数、送信電力等の制御を行う。
【０１１３】
ｅＮＢ２００の制御部２３０は、そのような送信制御を行っても、受信ＮＧであるＵＥ１００（ＮＡＣＫを送信するＵＥ１００）が存在する場合には、ＡＲＱ又はＨＡＲＱ等の再送を当該ＵＥ１００に対してユニキャストで行ってもよい。或いは、マルチキャスト伝送からユニキャスト伝送への切り替えを行ってもよい。
【０１１４】
（動作シーケンスの一例）
以下において、第１実施形態に係る動作シーケンスの一例について説明する。図７は、第１実施形態に係る動作シーケンスの一例を示す図である。図７において、破線で示すシグナリングは必須ではなく、省略してもよい。
【０１１５】
図７に示すように、ステップＳ１００において、ｅＮＢ２００は、閾値を設定するための設定情報を複数のＵＥ１００に送信する。
【０１１６】
ステップＳ１０１において、設定情報を受信したＵＥ１００（ＵＥ１００−１、ＵＥ１００−２）は、当該設定情報に基づいて閾値を設定する。
【０１１７】
ステップＳ１０２において、ｅＮＢ２００は、ＳＣＰＴＭによるマルチキャスト伝送を開始する。
【０１１８】
ステップＳ１０３において、ＵＥ１００（ＵＥ１００−１、ＵＥ１００−２）は、無線状態を測定する。上述したように、無線状態とは、例えばＲＳＲＰ及び／又はＲＳＲＱである。
【０１１９】
ステップＳ１０４において、ＵＥ１００（ＵＥ１００−１、ＵＥ１００−２）は、無線状態を閾値と比較する。ここでは、ＵＥ１００−１の無線状態が閾値よりも悪く、ＵＥ１００−２の無線状態が閾値よりも良い場合を想定する。
【０１２０】
ステップＳ１０５において、ＵＥ１００−２は、ｅＮＢ２００へのフィードバック情報の送信を停止する。
【０１２１】
一方、ステップＳ１０６において、ＵＥ１００−１は、フィードバック情報の送信に使用する上りリンク無線リソース（フィードバック用リソース）の割り当てを要求するための第１の情報（割り当て要求）をｅＮＢ２００に送信する。
【０１２２】
ステップＳ１０７において、ｅＮＢ２００は、ＵＥ１００−１からの第１の情報の受信に応じて、フィードバック用リソースをＵＥ１００−１に割り当てる。
【０１２３】
ステップＳ１０８において、ＵＥ１００−１は、フィードバック用リソースを使用して、下りリンクに関するフィードバック情報をｅＮＢ２００に送信する。
【０１２４】
その後、ステップＳ１０９において、ＵＥ１００（ＵＥ１００−１、ＵＥ１００−２）は、無線状態を測定する。
【０１２５】
ステップＳ１１０において、ＵＥ１００（ＵＥ１００−１、ＵＥ１００−２）は、無線状態を閾値と比較する。ここでは、ＵＥ１００−１の無線状態が閾値よりも良く、ＵＥ１００−２の無線状態が閾値よりも良い場合を想定する。
【０１２６】
ステップＳ１１１において、ＵＥ１００−２は、ｅＮＢ２００へのフィードバック情報の送信停止を継続する。
【０１２７】
一方、ステップＳ１１２において、ＵＥ１００−１は、フィードバック用リソースの解放を要求するための第２の情報をｅＮＢ２００に送信する。ｅＮＢ２００は、第２の情報の受信に応じて、ＵＥ１００−１のフィードバック用リソースを解放する。
【０１２８】
ステップＳ１１３において、ＵＥ１００−１は、ｅＮＢ２００へのフィードバック情報の送信を停止する。
【０１２９】
（第１実施形態のまとめ）
上述したように、ＳＣＰＴＭにおいて、無線状態が良好なＵＥ１００がフィードバック情報を送信しないことにより、フィードバックに伴う上りリンク無線リソース（例えば、ＰＵＣＣＨリソース）を節約することができる。特に、ｅＮＢ２００が多数のＵＥ１００に対してマルチキャスト伝送を行う場合でも、フィードバック制御が複雑にならず、かつ、上りリンク無線リソースの逼迫を回避することができる。従って、ＳＣＰＴＭにおいて効率的なフィードバックを可能とすることができる。
【０１３０】
［第１実施形態の変更例］
上述した第１実施形態の動作を有効化するか否かを上りリンクの負荷状態に応じて切り替えてもよい。
【０１３１】
第１実施形態の変更例において、ｅＮＢ２００の制御部２３０は、上りリンクの負荷状態と関連するパラメータに基づいて、特定ＵＥ１００からのみフィードバック情報を受信する第１のモードから、複数のＵＥ１００の全てからフィードバック情報を受信する第２のモードに切り替えるか否かを判断する。ここで、上りリンクの負荷状態と関連するパラメータとは、例えば、グループ内ＵＥ数、全グループ内ＵＥ数、セル内全（接続）ＵＥ数等である。当該パラメータが一定値未満である場合、上りリンクの負荷が低いと判断し、第１のモード（第１実施形態の動作）から第２のモード（ユニキャスト伝送と同様のモード、すなわち、グループ内全ＵＥがフィードバックを行うモード）に切り替えると判断する。そして、ｅＮＢ２００は、判断結果を複数のＵＥ１００に通知する。
【０１３２】
ＵＥ１００の制御部１３０は、ｅＮＢ２００からの通知に応じて、フィードバック情報の送信停止を有効化する第１のモードから、フィードバック情報の送信停止を無効化する第２のモードに切り替える。
【０１３３】
ここでは、第１のモードから第２のモードへの切り替えについて説明したが、第２のモードから第１のモードへの切り替えも可能である。具体的には、ｅＮＢ２００は、上りリンクの負荷状態と関連するパラメータが一定値以上である場合、上りリンクの負荷が高いと判断し、第２のモードから第１のモードに切り替えると判断し、判断結果を複数のＵＥ１００に通知する。
【０１３４】
［第２実施形態］
第２実施形態について、第１実施形態との相違点を主として説明する。第２実施形態は、ＳＣＰＴＭにフィードバックを導入する点については第１実施形態と同様である。しかしながら、第２実施形態は、フィードバック用リソースの割り当て方式が第１実施形態とは異なる。
【０１３５】
（ＵＥ１００の動作）
以下において、第２実施形態に係るＵＥ１００の動作について説明する。具体的には、図６において、ｅＮＢ２００と、ＵＥグループに含まれる１つのＵＥ１００（例えばＵＥ１００−１）との間の動作を説明する。
【０１３６】
図６に示すように、ＵＥ１００の受信部１１０は、同一の下りリンク無線リソースを使用してｅＮＢ２００から複数のＵＥ１００に送信されるマルチキャストデータを受信する。制御部１３０は、フィードバック用リソースプールの中からフィードバック用リソースを選択する。フィードバック用リソースプールは、複数のＵＥ１００からなるグループ（ＵＥグループ）に対してｅＮＢ２００から割り当てられたリソースプールである。フィードバック用リソースは、フィードバック情報の送信に使用する上りリンク無線リソースである。送信部１２０は、選択されたフィードバック用リソースを使用して、フィードバック情報をｅＮＢ２００に送信する。
【０１３７】
図８は、フィードバック用リソースプールの一例を示す図である。
【０１３８】
図８に示すように、フィードバック用リソースプールは、全ての上りリンク無線リソースのうちの一部である。
【０１３９】
フィードバック用リソースプールは、ｅＮＢ２００から各ＵＥ１００に個別に割り当てられる物理上りリンク制御チャネル（ＰＵＣＣＨ）とは異なる上りリンク無線リソースからなる。すなわち、上りリンク周波数帯の両端部よりも内側にフィードバック用リソースプールが設けられる。
【０１４０】
また、フィードバック用リソースプールは、ＵＥグループごとに割り当てられる。例えば、グループ識別子に対してフィードバック用リソースプールが対応付けられている。図８の例において、所定の時間リソース（１つのサブフレーム又は１つの無線リソース）内に、３つのＵＥグループ（ｇｒｏｕｐ  １乃至ｇｒｏｕｐ  ３）に対応する３つのフィードバック用リソースプールが設けられている。
【０１４１】
このように、ＵＥグループごとにフィードバック用リソースプールを割り当てることにより、フィードバック用リソースをｅＮＢ２００が都度割り当てる場合に比べて、割り当てに伴うシグナリング（スケジューリング情報の送信）を削減することができる。また、ＵＥグループ内のＵＥ１００がフィードバック用リソースプール内でフィードバック情報を送信することが保証され、フィードバック制御が複雑にならず、かつ、上りリンク無線リソースの逼迫を回避することができる。
【０１４２】
ＵＥ１００の受信部１１０は、フィードバック用リソースプールに関する設定情報をｅＮＢ２００から受信する。図８に示すように、フィードバック用リソースプール（ｇｒｏｕｐ  ３）に関する設定情報は、時間軸上における基準点（０シンボル目）とフィードバック用リソースプールの始点との間の差分（Ｏｆｓ−ｓｙｍ）、周波数軸上における基準点（０ＲＢ目又はＰＵＣＣＨリソース端）とフィードバック用リソースプールの始点との間の差分（Ｏｆｓ−ＲＢ）、時間軸上におけるフィードバック用リソースプールの範囲（Ｒａｎｇｅ−ｓｙｍ）、周波数軸上におけるフィードバック用リソースプールの範囲（Ｒａｎｇｅ−ＲＢ）、のうち少なくとも１つを含む。
【０１４３】
ここで、時間軸上のパラメータ（Ｏｆｓ−ｓｙｍ、Ｒａｎｇｅ−ｓｙｍ）は、シンボル単位、スロット単位、サブフレーム単位、又は無線フレーム単位で表現される。周波数軸上のパラメータ（Ｏｆｓ−ＲＢ、Ｒａｎｇｅ−ＲＢ）は、サブキャリア単位又はリソースブロック（ＲＢ）単位で表現される。また、これらのパラメータは、周波数バンドごとに規定されてもよい。或いは、これらのパラメータは、所定数のＲＢからなる周波数単位であるサブバンド単位で規定されてもよい。
【０１４４】
さらに、フィードバック用リソースプールに関する設定情報は、「ＯＮ／ＯＦＦパターン」、「周期」を含んでもよい。ＯＮ／ＯＦＦパターンは、サブフレーム又はスロット毎の、あるフィードバック用リソースの有無を表現するパラメータである。周期は、ＯＮ／ＯＦＦパターンの周期を表現するパラメータである。
【０１４５】
フィードバック用リソースが存在しないタイミング（ＯＦＦタイミング）に該当する受信信号（４サブフレーム前の受信）については、フィードバック情報の生成及び送信を省略可能である。また、フィードバック用リソースが存在しないタイミング（ＯＦＦタイミング）に該当する受信信号についてのフィードバック情報は、次にフィードバックリソースが存在するタイミング（ＯＮタイミング）において、まとめて送信してもよい。例えば、サブフレームｎとｎ＋１の両方が受信成功である場合にはＡＣＫを、どちらかひとつ以上が受信失敗である場合はＮＡＣＫを、サブフレーム(ｎ＋１)の４サブフレーム後のタイミングでｅＮＢ２００に送信（フィードバック）する。
【０１４６】
ＵＥ１００の制御部１３０は、ｅＮＢ２００から自ＵＥ１００に割り当てられた固有情報、又は自ＵＥ１００に予め設定されている固有情報に基づいて、フィードバック情報の送信に使用する上りリンク無線リソース（フィードバック用リソース）をフィードバック用リソースプールの中から選択してもよい。このような固有情報に基づくリソース選択を行うことにより、フィードバック用リソース内でのＵＥ間のフィードバック用リソースの衝突を回避することができる。
【０１４７】
ここで、ｅＮＢ２００から自ＵＥ１００に割り当てられた固有情報とは、例えばセルＲＮＴＩ（Ｃ−ＲＮＴＩ）である。自ＵＥ１００に予め設定されている固有情報とは、ＩＭＳＩ（Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｍｏｂｉｌｅ  Ｓｕｂｓｃｒｉｂｅｒ  Ｉｄｅｎｔｉｔｙ）又はＳ−ＴＭＳＩ（ＳＡＥ  Ｔｅｍｐｏｒａｒｙ  Ｍｏｂｉｌｅ  Ｓｕｂｓｃｒｉｂｅｒ  Ｉｄｅｎｔｉｔｙ）である。ＩＭＳＩは、ＵＩＭカードに格納されている固有情報である。Ｓ−ＴＭＳＩは、ＵＥ１００がネットワークに位置登録を行う際にＭＭＥからＵＥ１００に割り当てられる固有情報である。
【０１４８】
例えば、ＵＥ１００の制御部１３０は、固有情報の一部で周波数リソース（ＲＢ）を選択し、当該固有情報の残りの部分で時間リソース及び信号系列（シーケンス）を選択する。或いは、「固有情報modフィードバックリソースプールのＲＥ数」といった計算式によりフィードバック用リソースを選択してもよい。
【０１４９】
後述する第３実施形態を第２実施形態と組み合わせる場合、固有情報に基づくリソース選択を不要としてもよい。
【０１５０】
（ｅＮＢ２００の動作）
以下において、第２実施形態に係るｅＮＢ２００の動作について説明する。具体的には、図６において、ｅＮＢ２００と、ＵＥグループに含まれる１つのＵＥ１００（例えばＵＥ１００−１）との間の動作を説明する。
【０１５１】
図６に示すように、ｅＮＢ２００の制御部２３０は、複数のＵＥ１００からなるグループに対して、フィードバック情報の送信に使用可能なフィードバック用リソースプールを割り当てる。ｅＮＢ２００の送信部２１０は、同一の下りリンク無線リソースを使用して複数のＵＥ１００にマルチキャストデータを送信する。ｅＮＢ２００の受信部２２０は、フィードバック用リソースプールの中から選択された上りリンク無線リソースを使用して送信されるフィードバック情報を複数のＵＥ１００から受信する。
【０１５２】
上述したように、フィードバック用リソースプールは、自ｅＮＢ２００から各ＵＥ１００に個別に割り当てる物理上りリンク制御チャネル（ＰＵＣＣＨ）とは異なる上りリンク無線リソースからなる。
【０１５３】
ｅＮＢ２００の送信部２１０は、フィードバック用リソースプールに関する設定情報を複数のＵＥ１００に送信する。上述したように、設定情報は、時間軸上における基準点とフィードバック用リソースプールの始点との間の差分、周波数軸上における基準点とフィードバック用リソースプールの始点との間の差分、時間軸上におけるフィードバック用リソースプールの範囲、周波数軸上におけるフィードバック用リソースプールの範囲、のうち少なくとも１つを含む。設定情報は、「ＯＮ／ＯＦＦパターン」、「周期」を含んでもよい。
【０１５４】
フィードバック用リソースプールに関する設定情報は、システム情報（ＳＩＢ）によりｅＮＢ２００からブロードキャスト伝送してもよいし、個別のＲＲＣメッセージによりｅＮＢ２００からユニキャスト伝送してもよいし、グループＲＮＴＩでＣＲＣをスクランブルされたＤＣＩで伝送してもよい。
【０１５５】
（動作シーケンスの一例）
以下において、第２実施形態に係る動作シーケンスの一例について説明する。図９は、第２実施形態に係る動作シーケンスの一例を示す図である。
【０１５６】
図９に示すように、ステップＳ２０１において、ｅＮＢ２００は、フィードバック用リソースプールに関する設定情報（フィードバック用リソースプール情報）をグループ内ＵＥ１００（ＵＥ１００−１、ＵＥ１００−２）に送信する。各ＵＥ１００は、フィードバック用リソースプール情報を受信して記憶する。
【０１５７】
ステップＳ２０２において、ｅＮＢ２００は、ＳＣＰＴＭによるマルチキャスト伝送を開始する。
【０１５８】
ステップＳ２０３において、ＵＥ１００（ＵＥ１００−１、ＵＥ１００−２）は、自ＵＥの固有情報に基づいて、自グループに割り当てられたフィードバック用リソースプールの中からフィードバック用リソースを選択する。
【０１５９】
ステップＳ２０４において、ＵＥ１００（ＵＥ１００−１、ＵＥ１００−２）は、選択したフィードバック用リソースを使用して、フィードバック情報をｅＮＢ２００に送信する。
【０１６０】
（第２実施形態のまとめ）
上述したように、ＵＥグループごとにフィードバック用リソースプールを割り当てることにより、フィードバック用リソースをｅＮＢ２００が都度割り当てる場合に比べて、割り当てに伴うシグナリング（スケジューリング情報の送信）を削減することができる。また、ＵＥグループ内のＵＥ１００がフィードバック用リソースプール内でフィードバック情報を送信することが保証され、フィードバック制御が複雑にならず、かつ、上りリンク無線リソースの逼迫を回避することができる。
【０１６１】
［第２実施形態の変更例１］
上述した第２実施形態の動作を有効化するか否かを上りリンクの負荷状態に応じて切り替えてもよい。
【０１６２】
第２実施形態の変更例において、ｅＮＢ２００の制御部２３０は、上りリンクの負荷状態と関連するパラメータに基づいて、リソースプールを使用してフィードバック情報を送信する第１のモードから、ｅＮＢ２００から各ＵＥ１００に個別に割り当てられる物理上りリンク制御チャネル（ＰＵＣＣＨ）を使用してフィードバック情報を送信する第２のモードに切り替えるか否かを判断する。上りリンクの負荷状態と関連するパラメータは、第１実施形態の変更例と同様である。当該パラメータが一定値未満である場合、上りリンクの負荷が低いと判断し、第１のモード（第２実施形態の動作）から第２のモード（ユニキャスト伝送と同様のモード、すなわち、ＰＵＣＣＨ／ＰＵＳＣＨを使用してフィードバックを行うモード）に切り替えると判断する。そして、ｅＮＢ２００は、判断結果を複数のＵＥ１００に通知する。
【０１６３】
ＵＥ１００の制御部１３０は、ｅＮＢ２００からの通知に応じて、リソースプールを使用してフィードバック情報を送信する第１のモードから、ｅＮＢ２００から各ＵＥ１００に個別に割り当てられる物理上りリンク制御チャネル（ＰＵＣＣＨ）を使用してフィードバック情報を送信する第２のモードに切り替える。
【０１６４】
ここでは、第１のモードから第２のモードへの切り替えについて説明したが、第２のモードから第１のモードへの切り替えも可能である。具体的には、ｅＮＢ２００は、上りリンクの負荷状態と関連するパラメータが一定値以上である場合、上りリンクの負荷が高いと判断し、第２のモードから第１のモードに切り替えると判断し、判断結果を複数のＵＥ１００に通知する。
【０１６５】
また、フィードバック用のリソースプール毎に、無線状態の閾値設定を行ってもよい。ＵＥ１００は、測定結果が当該閾値の範囲内である場合に、該当するリソースプールを用いてもよい。これにより、無線状態に応じてリソースプールを使い分けることができる。
【０１６６】
［第２実施形態の変更例２］
上述した第２実施形態において、ＵＥ１００がＲＲＣコネクティッド状態であるかＲＲＣアイドル状態であるかについて特に触れなかった。本変更例において、ＵＥ１００がＲＲＣアイドル状態である場合について説明する。
【０１６７】
本変更例において、ＲＲＣコネクティッド状態のＵＥ１００だけではなく、ＲＲＣアイドル状態のＵＥ１００もリソースプールを使用可能である。ＲＲＣアイドル状態にあるＵＥ１００は、リソースプールの中から選択された上りリンク無線リソースを使用してフィードバック情報を送信する。フィードバック情報は、例えばＡＣＫ／ＮＡＣＫ（ＨＡＲＱ  ＡＣＫ／ＮＡＣＫ）である。但し、第３実施形態において説明するように、フィードバック情報は、ＡＣＫ／ＮＡＣＫのうちＮＡＣＫのみであってもよい。
【０１６８】
本変更例において、ＵＥ１００は、タイミングアドバンス（ＴＡ）調整を行うことなく、ＲＲＣアイドル状態におけるフィードバック情報の送信を行う。ＴＡ調整とは、ＵＥ１００とｅＮＢ２００との間の伝搬遅延に基づいてＵＥ１００の送信タイミングを調整する制御である。ＲＲＣコネクティッド状態のＵＥ１００は、ｅＮＢ２００から受信するＴＡ値に応じてＴＡ調整を行う。これに対し、ＲＲＣアイドル状態のＵＥ１００は、ｅＮＢ２００からＴＡを受信することが困難であるため、ＴＡ調整を行わずにフィードバック情報を送信する。
【０１６９】
但し、リソースプールには、周波数方向及び／又は時間方向における送信誤差を許容するためのガード領域が設けられることが好ましい。ガード領域は、ｅＮＢ２００がＵＥ１００に通知するリソースプールの外側又は内側に設けられる。リソースプールの外側にガード領域が設けられる場合、ｅＮＢ２００によるスケジューリング実装により、１ＲＢ（周波数方向）及び／又は１サブフレーム（時間方向）のガード領域が設けられる。その場合、ｅＮＢ２００は、ガード領域に相当するリソースを割り当てないようにする。リソースプールの内側にガード領域が設けられる場合、仕様上の規定として、リソースプール境界近傍の数サブキャリア、数ＳＣ−ＦＤＭＡシンボル、1ＲＢ、又は１サブフレーム等のリソースの使用が禁止される。なお、フィードバック用のリソースプールは、フィードバックリソースの外側にガード領域を付けたもの又はこれの寄せ集めであってもよい。
【０１７０】
また、ＲＲＣアイドル状態にあるＵＥ１００には、閉ループ送信電力制御を適用することが困難である。このため、ｅＮＢ２００は、リソースプールに関する設定情報として、フィードバック情報の送信に適用される開ループ送信電力制御パラメータをＵＥ１００に送信することが好ましい。例えば、ｅＮＢ２００は、ブロードキャストするシステム情報ブロック（ＳＩＢ）内に開ループ送信電力制御パラメータを含める。ＵＥ１００は、開ループ送信電力制御パラメータを受信し、開ループ送信電力制御パラメータに基づいてフィードバック情報の送信時の送信電力を制御する。
【０１７１】
なお、開ループ送信電力制御パラメータがＲＲＣコネクティッド状態のＵＥ１００にも適用される場合、開ループ送信電力制御パラメータを、ＲＲＣコネクティッド状態のＵＥ１００用とＲＲＣアイドル状態のＵＥ１００用とでそれぞれ異ならせてもよい。ＲＲＣコネクティッド状態のＵＥ１００の数はｅＮＢ２００が把握しているため、送信電力を高め（言い換えると、厳密）に設定する。これに対し、ＲＲＣアイドル状態のＵＥ１００の数はｅＮＢ２００が把握していないため、送信電力を低め（言い換えると、マージン付き）に設定する。具体的には、ｅＮＢ２００は、ＲＲＣコネクティッド状態のＵＥ１００に比べて、ＲＲＣアイドル状態のＵＥ１００の送信電力を低めに設定する。又は、ｅＮＢ２００は、自セル内に在圏するＲＲＣアイドル状態のＵＥ１００が所定数であるとより多めに見積もり、当該所定数分送信電力を分配することにより、ＲＲＣアイドル状態のＵＥ１００の送信電力を設定してもよい。
【０１７２】
なお、開ループ送信電力制御パラメータは、既存のパラメータ（ＰＲＡＣＨ、ＰＵＳＣＨ／ＳＲＳ、ＰＵＣＣＨ等のパラメータ）とは別に設定してもよい。なお、ＳＲＳの送信電力パラメータの一部にはＰＵＳＣＨの送信電力パラメータが用いられる。或いは、開ループ送信電力制御パラメータは、既存のパラメータ（例えばＰＲＡＣＨパラメータ）にオフセットを加える形で規定してもよい。オフセットについては、例えば、ＳＩＢにより可変値とする、又は規格で固定値を規定する。
【０１７３】
ｅＮＢ２００は、ＲＲＣアイドル状態におけるフィードバック情報の送信の必要性についてＵＥ１００に通知してもよい。当該通知は、ＳＩＢにより行われてもよい。ＵＥ１００は、ＲＲＣアイドル状態におけるフィードバック情報の送信の必要性（すなわち、フィードバック要）をｅＮＢ２００から通知された場合に限り、ＲＲＣアイドル状態におけるフィードバック情報の送信を行う。
【０１７４】
［第２実施形態の変更例３］
上述した第２実施形態において、ＵＥグループ（Ｇ−ＲＮＴＩ）ごとにフィードバック用リソースプール（以下、単に「リソースプール」という）を割り当てる一例を説明した。本変更例において、フィードバック情報の内容に応じてリソースプールを細分化する一例を説明する。
【０１７５】
フィードバック情報は、複数のインデックス値のうち１つである。フィードバック情報がＣＱＩである場合、一般的なＣＱＩフィードバックにおいて、ＵＥ１００は、複数のＭＣＳに対応する複数のＣＱＩの中から選択したＣＱＩをフィードバックする。フィードバック情報がＰＭＩである場合、一般的なＰＭＩフィードバックにおいて、ＵＥ１００は、複数のプレコーダに対応する複数のＰＭＩの中から選択したＰＭＩをフィードバックする。フィードバック情報がＲＩである場合、一般的なＲＩフィードバックにおいて、ＵＥ１００は、複数のランクに対応する複数のＲＩの中から選択したＲＩをフィードバックする。
【０１７６】
第２実施形態の変更例３において、ｅＮＢ２００からＵＥ１００に対して、複数のインデックス値に対応する複数のリソースプールが割り当てられる。具体的には、ｅＮＢ２００は、複数のリソースプールを設定し、各リソースプールに対してインデックス値を対応付ける。リソースプールとインデックス値との対応関係は、１対１であってもよい。ｅＮＢ２００は、ＭＣＳ毎に異なるリソースプール、ＰＭＩ毎に異なるリソースプール、ＲＩ毎に異なるリソースプールを対応付ける。或いは、リソースプールとインデックス値との対応関係は、１対多であってもよい。例えば、ｅＮＢ２００は、ＭＣＳ０〜５といったように、複数のインデックス値を１つのリソースプールに対応付けてもよい。１対多の場合、１対１の場合に比べて消費リソースを削減することができる。
【０１７７】
ＵＥ１００は、フィードバック情報として所定のインデックス値をｅＮＢ２００に送信する場合、複数のリソースプールのうち所定のインデックス値に対応するリソースプールを選択する。そして、ＵＥ１００は、選択したリソースプールに含まれるフィードバック用リソースを使用して、所定のインデックス値をフィードバック情報としてｅＮＢ２００に送信する。
【０１７８】
第２実施形態の変更例３において、複数のリソースプールのそれぞれに、複数のＵＥ１００に共通の無線リソース（リソースエレメント）及び／又は複数のＵＥ１００に共通の信号系列（ベースシーケンス、サイクリックシフト）が対応付けられる。ここで「複数のＵＥ１００」は、同一のＵＥグループに含まれるＵＥ１００である。ＵＥ１００は、選択したリソースプールに対応する共通の無線リソース及び／又は共通の信号系列を使用して、フィードバック情報をｅＮＢ２００に送信する。その結果、複数のＵＥ１００が同一のインデックス値をｅＮＢ２００に送信する場合、同一のインデックス値（同一のフィードバック信号）が合成された状態でｅＮＢ２００により受信される。ｅＮＢ２００は、リソースプール毎に、フィードバック信号の有無を電力ドメインで検出する。例えば、ｅＮＢ２００は、１つのリソースプール内でフィードバック信号を検出した場合、当該１つのリソースプールに対応するインデックス値がＵＥ１００から送信されたと判断する。なお、このような方法をＮＡＣＫに適用するケースを第３実施形態において説明する。
【０１７９】
なお、リソースプールとフィードバック値（インデックス値）との対応関係は、ＳＩＢ（又は個別シグナリング、若しくは、グループＲＮＴＩでＣＲＣをスクランブルされたＤＣＩ）でｅＮＢ２００からＵＥ１００に通知・設定できてもよい。或いは、当該対応関係は、事前定義されていてもよい。複数パターンの対応関係が事前定義され、１つのパターンを指定するための識別子をｅＮＢ２００からＵＥ１００に通知・設定できてもよい。
【０１８０】
また、リソースプールの無線リソース（時間・周波数）、及び／又はフィードバック信号の信号系列（シーケンス・サイクリックシフト）は、ＳＩＢ（又は個別シグナリング、若しくは、グループＲＮＴＩでＣＲＣをスクランブルされたＤＣＩ）でｅＮＢ２００からＵＥ１００に通知・設定できてもよい。
【０１８１】
［第２実施形態の変更例４］
上述した第２実施形態において、ｅＮＢ２００が設定情報を用いて所定の時間幅及び所定の周波数幅を有するリソースプールをＵＥ１００に通知する一例を説明した。しかしながら、リソースプールは、時間の経過に応じて周波数リソースが変化（ホッピング）するものであってもよい。例えば、リソースプールは、スロット間で周波数リソースが変化するものであってもよい。本変更例において、設定情報で指定されるリソースプールは、例えば異なる時間リソースにおいて異なる周波数リソースを組み合わせた所定のパターン（ホッピングパターン）を示してもよい。
【０１８２】
［第２実施形態の変更例５］
上述した第２実施形態において、ＲＲＣコネクティッド状態のＵＥ１００においてＳＣＰＴＭ用のフィードバックのタイミングが周期的なフィードバック（Ｐｅｒｉｏｄｉｃ  ＣＳＩ  ｆｅｅｄｂａｃｋ）のタイミングと衝突した場合を考慮していなかった。このような衝突が生じた場合、ＵＥ１００は、Ｐｅｒｉｏｄｉｃ  ＣＳＩ  ｆｅｅｄｂａｃｋ等の送信を優先し、ＳＣＰＴＭ用フィードバックを省略する。或いは、このような衝突が生じた場合、ＰＵＣＣＨ及びＰＵＳＣＨの同時送信をサポートするＵＥ１００は、Ｐｅｒｉｏｄｉｃ  ＣＳＩ  ｆｅｅｄｂａｃｋ及びＳＣ−ＰＴＭ用フィードバックの両方を送信してもよい。
【０１８３】
上述した第２実施形態において、ＲＲＣコネクティッド状態のＵＥ１００においてＳＣＰＴＭ用のフィードバックのタイミングがＰＵＳＣＨ送信のタイミングと衝突した場合を考慮していなかった。このような衝突が生じた場合、ＵＥ１００は、ＰＵＳＣＨに多重してＳＣ−ＰＴＭ用フィードバックを送信する。或いは、このような衝突が生じた場合、ＰＵＣＣＨ及びＰＵＳＣＨの同時送信をサポートするＵＥ１００は、ＰＵＳＣＨ及びＳＣ−ＰＴＭ用フィードバックの両方を送信してもよい。
【０１８４】
ＰＵＣＣＨとＳＣ−ＰＴＭ用フィードバックとの同時送信に関するＵＥ  ｃａｐａｂｉｌｉｔｙ、及びＰＵＳＣＨとＳＣ−ＰＴＭ用フィードバックとの同時送信に関するＵＥ  ｃａｐａｂｉｌｉｔｙを定義してもよい。ＵＥ１００はそのようなＵＥ  ｃａｐａｂｉｌｉｔｙをｅＮＢ２００に通知し、ＵＥ  ｃａｐａｂｉｌｉｔｙに基づいて動作する。
【０１８５】
［第３実施形態］
第３実施形態について、第１実施形態及び第２実施形態との相違点を主として説明する。第３実施形態は、ＳＣＰＴＭにフィードバックを導入する点については第１実施形態及び第２実施形態と同様である。また、第３実施形態において、フィードバック情報が送達確認情報（ＡＣＫ／ＮＡＣＫ）である場合を想定する。
【０１８６】
（ＵＥ１００の動作）
以下において、第３実施形態に係るＵＥ１００の動作について説明する。具体的には、図６において、ｅＮＢ２００と、ＵＥグループに含まれる１つのＵＥ１００（例えばＵＥ１００−１）との間の動作を説明する。
【０１８７】
ＵＥ１００の送信部１２０は、下りリンクのユニキャスト伝送が適用される場合、下りリンクデータを正しく受信したことを示す肯定応答（ＡＣＫ）及び下りリンクデータの受信に失敗したことを示す否定応答（ＮＡＣＫ）の何れかをフィードバック情報としてｅＮＢ２００に送信する。すなわち、下りリンクデータの受信に失敗すればＮＡＣＫを送信し、下りリンクデータを正しく受信すればＡＣＫを送信する。
【０１８８】
一方、ＳＣＰＴＭが適用される場合、制御部１３０は、ＡＣＫ及びＮＡＣＫのうちＮＡＣＫのみをフィードバック情報としてｅＮＢ２００に送信するように、ＡＣＫの送信を停止する。すなわち、下りリンクデータ（マルチキャストデータ）の受信に失敗すればＮＡＣＫを送信するが、下りリンクデータ（マルチキャストデータ）を正しく受信してもＡＣＫを送信しない。
【０１８９】
このように、ＳＣＰＴＭについてはＮＡＣＫのみを送達確認情報として使用することにより、ＡＣＫの送信に伴う上りリンク無線リソース（例えば、ＰＵＣＣＨリソース）を節約することができる。
【０１９０】
また、ＳＣＰＴＭが適用される場合、ＵＥ１００の送信部１２０は、ｅＮＢ２００とＳＣＰＴＭを行う複数のＵＥ１００（ＵＥグループ）で共通の無線リソース（リソースエレメント）、且つ共通の信号系列（ベースシーケンス、サイクリックシフト）を使用して、ＮＡＣＫを送信する。具体的には、このような共通リソースがｅＮＢ２００からＵＥグループごとに割り当てられており、ＵＥ１００は、自身が属するＵＥグループの共通リソースを使用してＮＡＣＫを送信する。
【０１９１】
これにより、ＮＡＣＫの送信に伴う上りリンク無線リソース（例えば、ＰＵＣＣＨリソース）も節約することができる。
【０１９２】
但し、このような共通リソースによるＮＡＣＫを適用することにより、複数のＵＥ１００のＮＡＣＫが合成されることになり、ｅＮＢ２００はＮＡＣＫの送信元ＵＥを識別することができない。しかしながら、再送をグループ内各ＵＥ１００にマルチキャストで行うことにより、どのＵＥ１００からのＮＡＣＫであるかを識別することを要しない。
【０１９３】
また、ＳＣＰＴＭが適用される場合、ＵＥ１００の送信部１２０は、複数のＵＥ１００で共通の無線リソース、且つ共通の信号系列を使用して、ＮＡＣＫの復調参照信号（ＤＭＲＳ）を送信することが好ましい。これにより、ＮＡＣＫがｅＮＢ２００において良好に復調される。なお、「ＮＡＣＫのＤＭＲＳ」とは、ＮＡＣＫに付随するＤＭＲＳであって、ＮＡＣＫとは別のＤＭＲＳを指す。或いは、ＤＭＲＳの系列にＮＡＣＫを含める場合、「ＮＡＣＫのＤＭＲＳ」とは、ＮＡＣＫを含むＤＭＲＳを指す。
【０１９４】
（ｅＮＢ２００の動作）
以下において、ＳＣＰＴＭにフィードバックを導入する場合のｅＮＢ２００の動作について説明する。具体的には、図６において、ｅＮＢ２００と、ＵＥグループに含まれる１つのＵＥ１００（例えばＵＥ１００−１）との間の動作を説明する。
【０１９５】
図６に示すように、ｅＮＢ２００の受信部２２０は、下りリンクのユニキャスト伝送が適用される場合、下りリンクデータを正しく受信したことを示すＡＣＫ及び下りリンクデータの受信に失敗したことを示すＮＡＣＫの何れかをフィードバック情報としてＵＥ１００から受信する。一方、ＳＣＰＴＭが適用される場合、ｅＮＢ２００の受信部２２０は、ＡＣＫ及びＮＡＣＫのうちＮＡＣＫのみをフィードバック情報としてＵＥ１００から受信する。
【０１９６】
ＳＣＰＴＭが適用される場合、ｅＮＢ２００の制御部２３０は、自ｅＮＢ２００とＳＣＰＴＭを行う複数のＵＥ１００（ＵＥグループ）に対して、ＮＡＣＫの送信用に共通の無線リソース、且つ共通の信号系列を割り当てる。具体的には、このような共通リソースをＵＥグループごとに割り当てる。また、ＳＣＰＴＭが適用される場合、ｅＮＢ２００の制御部２３０は、複数のＵＥ１００に対して、ＮＡＣＫの復調参照信号（ＤＭＲＳ）の送信用に共通の無線リソース、且つ共通の信号系列を割り当てることが好ましい。
【０１９７】
（動作シーケンスの一例）
以下において、第３実施形態に係る動作シーケンスの一例について説明する。図１０は、第３実施形態に係る動作シーケンスの一例を示す図である。
【０１９８】
図１０に示すように、ステップＳ３０１において、ｅＮＢ２００は、ＮＡＣＫ送信用の共通リソースに関する設定情報をグループ内ＵＥ１００（ＵＥ１００−１、ＵＥ１００−２）に送信する。ＮＡＣＫ送信用の共通リソースに関する設定情報は、システム情報（ＳＩＢ）によりｅＮＢ２００からブロードキャスト伝送してもよいし、個別のＲＲＣメッセージによりｅＮＢ２００からユニキャスト伝送してもよい。各ＵＥ１００は、設定情報を受信して記憶する。
【０１９９】
ステップＳ３０２において、ｅＮＢ２００は、ＳＣＰＴＭによるマルチキャスト伝送を開始する。
【０２００】
ステップＳ３０３において、ＵＥ１００（ＵＥ１００−１、ＵＥ１００−２）は、受信したマルチキャストデータの復号を試みる。
【０２０１】
ステップＳ３０４において、ＵＥ１００（ＵＥ１００−１、ＵＥ１００−２）は、マルチキャストデータの復号に成功したか否かを確認する。ここでは、ＵＥ１００−１が復号に失敗し、ＵＥ１００−２が復号に成功した場合を想定する。
【０２０２】
ステップＳ３０５において、ＵＥ１００−２は、ｅＮＢ２００へのフィードバック情報（ＮＡＣＫ）の送信を停止する。
【０２０３】
一方、ステップＳ３０６において、ＵＥ１００−１は、ＮＡＣＫ送信用の共通リソースを使用して、ＮＡＣＫをｅＮＢ２００に送信する。
【０２０４】
ステップＳ３０７において、ｅＮＢ２００は、ＮＡＣＫの受信に応じて、再送データをグループ内ＵＥ１００（ＵＥ１００−１、ＵＥ１００−２）に送信する。
【０２０５】
その後、ステップＳ３０８において、ＵＥ１００（ＵＥ１００−１、ＵＥ１００−２）は、新たに受信したマルチキャストデータの復号に成功したか否かを確認する。ここでは、ＵＥ１００−１及びＵＥ１００−２が何れも復号に失敗した場合（Ｓ３０９:ＮＯ）を想定する。
【０２０６】
ステップＳ３１０において、ＵＥ１００−１及びＵＥ１００−２は、ＮＡＣＫ送信用の共通リソースを使用して、ＮＡＣＫをｅＮＢ２００に送信する。これらのＮＡＣＫは、合成された状態でｅＮＢ２００により受信される。
【０２０７】
ステップＳ３１１において、ｅＮＢ２００は、ＮＡＣＫの受信に応じて、再送データをグループ内ＵＥ１００（ＵＥ１００−１、ＵＥ１００−２）に送信する。
【０２０８】
（第３実施形態のまとめ）
上述したように、ＳＣＰＴＭについてはＮＡＣＫのみを送達確認情報として使用することにより、ＡＣＫの送信に伴う上りリンク無線リソース（例えば、ＰＵＣＣＨリソース）を節約することができる。また、ＵＥグループごとの共通リソースを使用してＮＡＣＫを送信することにより、ＮＡＣＫの送信に伴う上りリンク無線リソースも節約することができる。
【０２０９】
［第３実施形態の変更例１］
上述した第３実施形態の動作を有効化するか否かを上りリンクの負荷状態に応じて切り替えてもよい。
【０２１０】
第３実施形態の変更例１において、ＳＣＰＴＭが適用される場合、ｅＮＢ２００の制御部２３０は、上りリンクの負荷状態と関連するパラメータに基づいて、ＮＡＣＫのみをフィードバック情報として送信する第１のモードから、ＡＣＫ及びＮＡＣＫの何れかをフィードバック情報として送信する第２のモードに切り替えるか否かを判断する。上りリンクの負荷状態と関連するパラメータは、第１実施形態の変更例と同様である。当該パラメータが一定値未満である場合、上りリンクの負荷が低いと判断し、第１のモード（第３実施形態の動作）から第２のモード（ユニキャスト伝送と同様のモード、すなわち、ＡＣＫ及びＮＡＣＫの何れかをフィードバック情報として送信するモード）に切り替えると判断する。そして、ｅＮＢ２００は、判断結果を複数のＵＥ１００に通知する。
【０２１１】
ＵＥ１００の制御部１３０は、ｅＮＢ２００からの通知に応じて、ＮＡＣＫのみをフィードバック情報としてｅＮＢ２００に送信する第１のモードから、ＡＣＫ及びＮＡＣＫの何れかをフィードバック情報としてｅＮＢ２００に送信する第２のモードに切り替える。
【０２１２】
ここでは、第１のモードから第２のモードへの切り替えについて説明したが、第２のモードから第１のモードへの切り替えも可能である。具体的には、ｅＮＢ２００は、上りリンクの負荷状態と関連するパラメータが一定値以上である場合、上りリンクの負荷が高いと判断し、第２のモードから第１のモードに切り替えると判断し、判断結果を複数のＵＥ１００に通知する。
【０２１３】
［第３実施形態の変更例２］
上述した第３実施形態において、リンクアダプテーション（特に、ＭＣＳの変更）について特に触れなかった。しかしながら、ｅＮＢ２００は、ＮＡＣＫの受信に応じてＭＣＳを変更することにより、ＣＱＩフィードバック無しでリンクアダプテーションを実現してもよい。例えば、ｅＮＢ２００は、ＮＡＣＫを受信した場合、それまで使用していたＭＣＳに比べてエラー耐性が高いＭＣＳに変更する。ｅＮＢ２００は、ＮＡＣＫを受信しない場合、それまで使用していたＭＣＳに比べてエラー耐性が低いＭＣＳに変更する。以下において、エラー耐性が高いＭＣＳに変更することを「ＭＣＳを下げる」と称し、エラー耐性が低いＭＣＳに変更することを「ＭＣＳを上げる」と称する。
【０２１４】
ｅＮＢ２００がＮＡＣＫを受信しないことに応じてＭＣＳを上げる場合、マルチキャストデータを辛うじて受信（復号）できていたＵＥ１００において、以降のマルチキャストデータを受信（復号）できなくなる可能性がある。
【０２１５】
第３実施形態の変更例２において、ＵＥ１００は、ＮＡＣＫとは異なる通知情報をｅＮＢ２００にさらに送信する。通知情報は、ＳＣＰＴＭに適用するＭＣＳの変更禁止をＵＥ１００が希望することを示す情報である。具体的には、ＵＥ１００は、ＭＣＳを上げて欲しくないことを示す通知情報をｅＮＢ２００に送信する。ＵＥ１００は、マルチキャストデータの受信品質が閾値未満であることをトリガとして、ＭＣＳを上げて欲しくないことを示す通知情報をｅＮＢ２００に送信してもよい。通知情報の送信には、第２実施形態及びその変更例２、３で説明したようなリソースプールを使用してもよい。具体的には、ｅＮＢ２００が通知情報用のリソースプールをＵＥ１００に設定・通知し、ＵＥ１００は当該リソースプール内で共通の無線リソース及び／又は共通の信号系列で通知情報をｅＮＢ２００に送信する。
【０２１６】
ｅＮＢ２００は、ＭＣＳを上げて欲しくないことを示す通知情報をＵＥ１００から受信した場合、ＭＣＳを上げないように制御する。一方、ｅＮＢ２００は、ＭＣＳを上げて欲しくないことを示す通知情報をＵＥ１００から受信しない場合には、ＭＣＳを上げるように制御してもよい。或いは、通知情報は、マルチキャストデータの受信品質が閾値未満であることを示す情報であってもよい。この場合、ＭＣＳを変更するか否かはｅＮＢ２００の判断に委ねられる。
【０２１７】
或いは、通知情報は、ＭＣＳの変更をＵＥ１００が希望することを示す情報であってもよい。例えば、ＵＥ１００は、マルチキャストデータの受信品質が閾値以上であることをトリガとして、ＭＣＳを上げたいことを示す通知情報をｅＮＢ２００に送信する。或いは、通知情報は、ＭＣＳの変更をＵＥ１００が許容することを示す情報であってもよい。
【０２１８】
或いは、通知情報は、マルチキャストデータの受信品質が閾値以上であることを示す情報であってもよい。この場合、ＭＣＳを変更するか否かはｅＮＢ２００の判断に委ねられる。
【０２１９】
なお、第３実施形態の変更例２は、通信を開始する前にＭＣＳを決定したい場合には若干不向きである。よって、ｅＮＢ２００は、通信を開始する前にＭＣＳを決定したい場合には第２実施形態の変更例３を適用し、通信を開始した後にＭＣＳを変更したい場合には第３実施形態の変更例２を適用してもよい。
【０２２０】
［第４実施形態］
第４実施形態について、第１実施形態乃至第３実施形態との相違点を主として説明する。第４実施形態は、ＲＲＣアイドル状態のＵＥ１００によるフィードバックを想定する。図１１は、第４実施形態に係る動作シーケンスの一例を示す図である。
【０２２１】
第４実施形態に係るＵＥ１００は、ＲＲＣアイドル状態においてｅＮＢ２００からＳＣＰＴＭによりマルチキャストデータを受信する（ステップＳ４０１）。ＵＥ１００は、マルチキャストデータの受信状態に基づいて、ＲＲＣアイドル状態からＲＲＣコネクティッド状態に遷移するための接続要求メッセージ（ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔ）をｅＮＢ２００に送信する（ステップＳ４０２）。例えば、ＵＥ１００は、マルチキャストデータの受信品質の劣化に応じて、接続要求メッセージをｅＮＢ２００に送信する。
【０２２２】
ＵＥ１００は、マルチキャストデータに関する情報を接続要求メッセージに含める。ｅＮＢ２００は、マルチキャストデータに関する情報を含む接続要求メッセージを受信する。
【０２２３】
接続要求メッセージは、接続理由を示すフィールド（ＥｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅ）を含む。ＵＥ１００は、マルチキャストデータに関する情報を、接続理由を示すフィールドに含めてもよい。例えば、マルチキャストデータに関する情報は、マルチキャストデータの受信失敗を示す情報（ＳＣ−ＰＴＭ  ｒｅｃｅｐｔｉｏｎ  ｆａｉｌｕｒｅ）、マルチキャストデータの送信に適用することが推奨される変調・符号化方式を示す情報（Ｄｅｓｉｒｅｄ  ＭＣＳ）、マルチキャストデータに対応するＴＭＧＩ（Ｔｅｍｐｏｒａｒｙ  Ｍｏｂｉｌｅ  Ｇｒｏｕｐ  Ｉｄｅｎｔｉｔｙ）情報、マルチキャストデータに対応する論理チャネルＩＤ、マルチキャストデータに対応するＧ−ＲＮＴＩ（Ｇｒｏｕｐ  ＲＮＴＩ）、のうち少なくとも１つを含む。例えば{TMGI, SC-PTM reception failure (true/false), Desired MCS}といったように、２以上の情報からなるリスト形式としてもよい。
【０２２４】
ｅＮＢ２００は、マルチキャストデータに関する情報を含む接続要求メッセージに対する応答として、拒否応答（Ｒｅｊｅｃｔ）を送信する（ステップＳ４０３）。ＵＥ１００は、拒否応答の受信に応じて、ＲＲＣアイドル状態を維持する。
【０２２５】
ｅＮＢ２００は、受信した接続要求メッセージからマルチキャストデータに関する情報を取得し、取得した情報に基づいて、マルチキャスト送信（ＳＣＰＴＭ）のリンクアダプテーションを行う（ステップＳ４０４）。リンクアダプテーションは、例えば適応変調及び／又は送信電力制御である。ｅＮＢ２００は、取得した情報に基づいて、ＵＥ１００が受信に失敗データの再送を行ってもよい。なお、ｅＮＢ２００は、ステップＳ４０３と同時若しくはそれとは別に又はステップＳ４０4に代えて、ＵＥ１００に対してＳＣ−ＰＴＭのフィードバック用のリソース割当を行ってもよい。
【０２２６】
［その他の実施形態］
上述した第１実施形態乃至第４実施形態は、別個独立して実施される場合に限定されない。第１実施形態乃至第４実施形態のうち２以上の実施形態を組み合わせて実施してもよい。例えば、第２実施形態に係るリソースプールを使用して、第３実施形態に係るＮＡＣＫのみのフィードバックを行ってもよい。
【０２２７】
ｅＮＢ２００は、上述した第１実施形態乃至第４実施形態（及びそれらの変更例）に係る複数のフィードバック方法のうち、何れのフィードバック方法を適用するかをＵＥ１００に指示してもよい。このような指示は、例えばＳＩＢにより行われてもよい。
【０２２８】
上述した第１実施形態乃至第４実施形態において、ＳＣＰＴＭにフィードバックを導入する一例について説明した。しかしながら、本発明はＳＣＰＴＭに限定されない。例えば、ＭＢＭＳにフィードバックを導入する場合にも本発明を適用してもよい。
【０２２９】
上述した第２実施形態の変更例２において、フィードバック情報送信用の送信電力制御パラメータを、ＳＩＢによりｅＮＢ２００からＵＥ１００に送信する一例を説明した。これにより、ＲＲＣアイドル状態のＵＥ１００は、ｅＮＢ２００から受信した送信電力制御パラメータに基づいて、フィードバック情報の送信時の送信電力を制御していた。しかしながら、このような送信電力制御パラメータを用いることに代えて、ＲＲＣアイドル状態のＵＥ１００は、事前定義された送信電力でフィードバック情報を送信してもよい。ここで、事前定義された送信電力で送信されるフィードバック情報は、例えば、フィードバック用リソースプールを用いて送信されるフィードバック情報（第２実施形態参照）、及び／又はＮＡＣＫのみのフィードバック情報（第３実施形態参照）である。
【０２３０】
具体的には、ＲＲＣアイドル状態のＵＥ１００は、自ＵＥの最大の送信電力でフィードバック情報を送信する。ここで、ＵＥの最大の送信電力は、ＵＥ  ｃａｐａｂｉｌｉｔｙによって定まる。詳細には、ＵＥの能力による最大送信電力値（例えば、＋１０ｄＢｍしか送信できない回路構成であれば、その値）となる。但し、ＳＩＢ１でｐ−ｍａｘがセルから報知されている場合は、当該セルにおいては、このｐ−ｍａｘ値が最大送信電力値となる。例えば、＋３１ｄＢｍで送信できる能力があるＵＥであっても、報知されたｐ−ｍａｘ値が＋１５ｄＢｍであれば、＋１５ｄＢｍが最大送信電力値となる。さらに、最大送信電力値を定めるファクターとして、バンド毎のＵＥ  ｐｏｗｅｒ  ｃｌａｓｓがある。例えば、ほぼ全てのバンドがＵＥ  ｐｏｗｅｒ  ｃｌａｓｓ  ３（＋２３ｄＢｍ）であるが、Ｂａｎｄ  １４だけはｃｌａｓｓ  １（＋３１ｄＢｍ）が許されている。
【０２３１】
或いは、ＲＲＣアイドル状態のＵＥ１００は、ＲＡＣＨの初期送信電力でフィードバック情報を送信する。ＲＡＣＨの初期送信電力とは、ランダムアクセスプリアンブルの１回目の送信電力であってもよい。通常、ＲＡＣＨ（ランダムアクセスプリアンブル）の送信電力は、「preambleInitialReceivedTargetPower + DELTA_PREAMBLE + (PREAMBLE_TRANSMISSION_COUNTER - 1) * powerRampingStep」の計算式により決定される。ここで、preambleInitialReceivedTargetPowerは、ＲＡＣＨの初期送信電力に相当する。preambleInitialReceivedTargetPowerは、ＳＩＢ２で通知されるパラメータである。或いは、「preambleInitialReceivedTargetPower + DELTA_PREAMBLE」をＲＡＣＨの初期送信電力とみなしてもよい。通常のDELTA_PREAMBLEは、プリアンブルフォーマット毎の（固定）オフセット値である。但し、フィードバック用に新たなDELTA_PREAMBLEを導入してもよい。このような新たなDELTA_PREAMBLEは、ｅＮＢ２００からＵＥ１００に設定（或いは報知）されてもよい。このような新たなDELTA_PREAMBLEは、フィードバックの種別毎に設けられてもよい。例えば、ＡＣＫ／ＮＡＣＫは重要なので、より高い送信電力となるような値が設定される。これに対し、ＣＳＩフィードバックは、干渉等を考慮して、少し低めの送信電力に設定されてもよい。 
【０２３２】
上述した第２実施形態の変更例２において、ｅＮＢ２００が、ＲＲＣアイドル状態におけるフィードバック情報の送信の必要性についてＳＩＢによりＵＥ１００に通知（ブロードキャスト）する一例を説明した。これにより、ＵＥ１００（特に、ＲＲＣアイドル状態のＵＥ１００）は、フィードバックが必要であることをｅＮＢ２００から通知された場合に限り、フィードバック情報の送信を有効化していた。以下において、このような通知の具体例について説明する。
【０２３３】
ｅＮＢ２００は、上述した実施形態に係るフィードバック情報の送信許可を示す許可情報（以下、単に「許可情報」という）、及び当該フィードバック情報の送信リソースに関連する設定情報（以下、単に「設定情報」という）を通知する。ＵＥ１００は、サービングセルから許可情報が通知されている時は、上述した実施形態に係るフィードバックを行うことができる。或いは、許可情報を不要としてもよい。この場合、ＵＥ１００は、設定情報が通知されている時に、暗示的に許可がなされていると判断してもよい。
【０２３４】
設定情報は、例えば、第２実施形態に係るフィードバック用リソースプールの設定情報、及び／又は第３実施形態に係るＮＡＣＫ送信用の共通リソース（無線リソース、信号系列）等を含む。ＵＥ１００は、サービングセルからブロードキャストされる設定情報を予め取得し、サービングセルから許可情報が報知されている場合に設定情報を適用してもよい。言い換えると、設定情報を取得したＵＥ１００は、許可情報が報知されていない場合には設定情報を適用しない。設定情報を適用するか否かの判断基準は、許可情報だけでなく、ＵＥ１００のフィードバック能力、ＵＥ１００のＳＣ−ＰＴＭ受信の興味を含んでもよい。ＵＥ１００は、上述した実施形態に係るフィードバックの能力を有する場合に限り、設定情報を適用する。また、ＵＥ１００は、自ＵＥがＳＣ−ＰＴＭ受信に興味がある場合に限り、設定情報を適用する。なお、上述した実施形態に係るフィードバックの能力を有しないＵＥ１００及びＳＣＰＴＭ受信に興味がないＵＥ１００は、ＲＲＣアイドル状態からＲＲＣコネクティッド状態に遷移し、ユニキャスト受信を行ってもよい。
【０２３５】
ｅＮＢ２００は、許可情報及び／又は設定情報をＳＩＢ２０又はＳＣ−ＭＣＣＨ（Ｓｉｎｇｌｅ−Ｃｅｌｌ  Ｍｕｌｔｉｃａｓｔ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）で通知する。ここで、ＳＩＢ２０は、ＳＣＰＴＭ用のＳＩＢである。ＳＣ−ＭＣＣＨは、ＳＣＰＴＭ用の制御チャネルであって、かつ、ＤＬ−ＳＣＨ（ＰＤＳＣＨ）にマッピングされる論理チャネルである。但し、ＳＣ−ＭＣＣＨは、ＳＩＢ２０に比べて、ＴＭＧＩ（Ｇ−ＲＮＴＩ）毎の設定を通知できるとともにセットアップ時間が短い。よって、ｅＮＢ２００は、許可情報及び／又は設定情報を、ＳＩＢ２０よりもＳＣ−ＭＣＣＨにより送信することが好ましい。ＳＣ−ＭＣＣＨで通知する場合、ｅＮＢ２００は、フィードバック方式をＴＭＧＩ（Ｇ−ＲＮＴＩ）毎に設定してもよい。ｅＮＢ２００は、ＳＣＰＴＭ送信時に許可情報をＰＤＣＣＨでＵＥ１００に通知してもよい。この場合、許可情報の送信には、新たなＤＣＩフォーマットが適用されてもよいし、既存のＤＣＩフォーマットに新たなビットを追加してもよい。なお、第１実施形態乃至第３実施形態で記載された各種の情報もＳＣ−ＭＣＣＨで通知してもよい。
【０２３６】
なお、上述した第１実施形態乃至第４実施形態において、移動通信システムとしてＬＴＥシステムを例示した。しかしながら、本発明はＬＴＥシステムに限定されない。ＬＴＥシステム以外のシステムに本発明を適用してもよい。
【０２３７】
［付記］
以下において、上述した実施形態について補足説明する。
【０２３８】
（導入）
RAN2＃89-bisでは、SC-PTMのIDLEモード受信がサポートされることが合意された。
【０２３９】
（合意事項）
１．我々はIDLEのUEによるSC-PTMの受信をサポートすることを意図し、サービス継続性などといった関連する側面を調査する。
【０２４０】
RAN1＃80-bisにおいて、SC-PTM送信のためのPHY側面についてのLS応答が合意され、以下のように、SC-PTM送信のためのHARQのみ又はHARQ/CSIフィードバックを有することを暗示する。
【０２４１】
Answer：RAN1は、SC-PTMを受信する全てのUEによりCSI及びHARQ又はHARQのみのフィードバックが提供され、かつ、SC-PTMを受信する全てのUEがRRC_CONNECTED状態にあるケースのみを考慮した。考慮するケースにおいてCSI及び/又はHARQ-ACKフィードバックはゲインをもたらすことができる。SC-PTMを受信しているUEのグループがRRC_IDLE及びRRC_CONNECTED状態の両方のUEからなる場合、リンクアダプテーション及び/又はHARQ再送が適用されないかもしれない。[...]
【０２４２】
本付記では、SC-PTM送信のための可能なリンクアダプテーションメカニズムがConnected及びIdleの両方のUEについて考慮する。
【０２４３】
（考察）
・RRC Connectedモードでのリンクアダプテーション
RAN1からのLSに加えて、RAN2＃89-bisでは、評価に基づくリソース効率についての議論が行われ、すべての結果が、HARQ/CSIフィードバックを伴うSC-PTMはフィードバックのないものに比べてより多くのゲインを有することを示した。よって、RAN2は、ULフィードバックを持つSC-PTM送信を設定するオプションを想定する必要がある。
【０２４４】
提案1：サービングセルは、ULフィードバックを持つSC-PTM送信を設定する手段を持つべきである。
【０２４５】
次のようにULフィードバックのためのいくつかの想定が評価において見られた。
【０２４６】
想定1：HARQ及びCSIの両方のフィードバック
想定2：CSIのみのフィードバックのみ
想定3：HARQのみのフィードバック
【０２４７】
HARQ及びCSIフィードバックの両方は、周波数利用効率で最高のパフォーマンスを提供するが、最大のオーバーヘッドの原因になり得る。CSIのみのフィードバック方式は、準最適な性能を示し、それはまた、HARQのみのフィードバック方式についても言える（技術4及び「PTM-RA + NR」）。フィードバックに起因するオーバーヘッドを考慮すると、HARQフィードバック（すなわち、1ビット）は、CSIフィードバックよりも有益である（すなわち、CQIのための4ビット、及び必要に応じてPMI + PTI + RI）。よって、HARQのみのフィードバックはSC-PTMに好ましい方式である。また、HARQフィードバックは、HARQ再送だけではなくMCSを調整するために使用することができ、CSIフィードバックより容易な制御機構を必要とすると予想される。
【０２４８】
提案2：RAN2は、RRC Connected中のリンクアダプテーションのためにHARQフィードバックを持つSC-PTMを想定するべきである。
【０２４９】
現在の方式はユニキャスト伝送のために設計されているので、提案2が許容される場合には、SC-PTM伝送のための既存のHARQフィードバックスキームを再利用するための問題がある。SC-PTM送信が複数のUEによって受信されることを考慮すると、対応するHARQフィードバックのためのPUCCHリソースが複数のUEによって共有され、既存のHARQフィードバックの受信は複数のフィードバック送信を想定していない。よって、そのような複数のHARQフィードバックの送信は受信エラーを引き起こす。可能な解決策は、「NACKのみ」の方式である。「NACKのみ」のフィードバックの概念に加えて、サービングセル内の受信機が電力ドメインでNACKを検出する場合、SR/PRACHのように事前定義された及び/又はグループ固有のシーケンスにより複数の複数のUEがNACK信号を送信する。複数のNACK信号は空中で合成され、受信機におけるマルチパス上の単一のNACKフィードバックとして見ることができるので、SC-PTM送信のためのフィードバックリソースは複数のUEによって共有されてもよい。
【０２５０】
提案3：RAN2は、SC-PTM送信を受信する複数のUE間で共有するフィードバックリソース内の「NACKのみ」のフィードバックを想定すべきである。
【０２５１】
提案2が合意されない場合、すなわち、HARQフィードバックが想定されない場合、RRCシグナリングによる「ソフト」リンクアダプテーション、例えば、UEAssistanceInformation又はMBMSInterestIndicationなどのUEからのSC-PTMのためのインディケーションが有用な代替であるかどうかを検討すべきである。UEは、インディケーション中でSC-PTMの受信エラー及び/又は所望のMCSをサービングセルに通知すべきであり、そして、サービングセルは、SC-PTMの堅牢性を高めることができる。この方式は、サブフレームレベルで必要とされていると想定されない。従って、このような準動的なリンクアダプテーションは小さいRAN1への影響で採用することができる。
【０２５２】
提案4：提案2が合意されない場合、RAN2は、UEからのRRCシグナリングによるフィードバックに基づいて、ConnectedにおけるSC-PTMのリンクアダプテーションを検討すべきである。
【０２５３】
・RRC Idleモードでのリンクアダプテーション
LS応答は、RAN1は、SC-PTMを受信する全てのUEによりCSI及びHARQ又はHARQのみのフィードバックが提供され、かつ、SC-PTMを受信する全てのUEがRRC_CONNECTED状態にあるケースのみを考慮していることを言及するが、SC-PTMを受信しているUEのグループがRRC_IDLE及びRRC_CONNECTED状態の両方のUEからなる場合、CSI及び/又はHARQフィードバックに基づくリンクアダプテーション及び/又はHARQ再送が適用されないかもしれない。UEがSC-PTMの受信問題を経験する場合、UEは、SC-PTMの継続的な受信のための2つの方法を持つことが許可されている。UEは、RRC Connectedに遷移し、その後、（提案2が受け入れ可能である場合）SC-PTMに対応するHARQフィードバックを送信するか、又はMBMSサービスのためのユニキャストベアラを確立する。これらの動作は、スタンダードのインパクトが予想されない又は（もしあれば）最小限であるので、ベースラインにすべきである。
【０２５４】
考察1：SC-PTMの受信の問題が発生したときに、IdleのUEはRRC Connectedに遷移する必要がある。
【０２５５】
しかし、RRC Connectedへの遷移は、UEの追加の消費電力だけでなく、サービングセルの追加の負荷も引き起こし得る。例えば、UEは、（SC-PTM受信の代わりに）MBMSサービスのための新たなユニキャストベアラを確立することを決定した場合、同じデータがまだSC-PTMで提供されているので、周波数利用効率の低下を引き起こすことがある。複数のユニキャストベアラの確立を回避するために、SC-PTMのためのHARQフィードバックを導入することができると考えられる。HARQフィードバックは、ほとんどの場合で良好に機能するが、SC-PTMの受信のみに興味があるUEのための電力消費を改善するための余地がある。
【０２５６】
また、いくつかの失敗ケース、例えば輻輳によるRRCConnectionRejectが考慮されるべきである。SC-PTMの悪い受信を経験するUEはRRCConnectionRequestを開始するが、サービングセルによって拒否された場合、UEは、サービス継続のためのセル再選択を行い、RRCConnectionRequestを再起動し得る。これはUEのための電力の効率的な方法ではなく、サービングセルがSC-PTMの現在のMCSが十分であるかどうかを知る方法はない。
【０２５７】
したがって、IdleのUEによりSC-PTMの受信をサポートし、関連する側面を調査することが同意されたので、IdleのUEが関与するリンクアダプテーションを取り扱う方法を検討する価値がある。
【０２５８】
提案5：RAN2は、IdleのUEに対するリンクアダプテーションをどのように取り扱うかを考慮すべきであり、Idleモードで可能な機能強化を検討するべきである。
【０２５９】
提案5が合意された場合、UEがRRC Idleに留まる場合のリンクアダプテーションのメカニズムを検討する価値がある。二つの可能な選択肢が考えられる。
【０２６０】
選択肢1：RRC Connected要求による「リラックス」リンクアダプテーション
RAN2＃89-bisでの議論は、多くのエラーが発生したらUEはCONNECTするであろうと指摘した。そして、eNBは、劣悪なリンクについて把握し、「リラックス」リンクアダプテーションとして堅牢性を高めることができる。仕様への影響として、例えば目的のTMGI（複数可）に対応するSC-PTMの受信エラーに起因する遷移であることを明確にするために、RRC Connected要求における確立原因（EstablishmentCause）が拡張されてもよい。この選択肢では、サービングセルは、確立原因がSC-PTMのリンクアダプテーションのためだけのものである場合、常にRRC Connected要求を拒否するオプションを有していてもよい。
【０２６１】
選択肢2：NACKのみのフィードバックプールを持つ「正確な」リンクアダプテーション
この選択肢は、NACKのみの方式、すなわち、提案3を想定し、また、PRACHリソース及び/又はD2Dリソースプールのような「フィードバックプール」を想定している。IdleのUEが、タイミング調整及びRRC Connectedへの遷移なしで、「フィードバックプール」内でNACKを送信することが許容される。「フィードバックプール」がRRC Connectedのためにも定義されている場合、RRC Connected及びIdleのための共通のフィードバックプールがSC-PTMを受信するすべてのUEによって共有されてもよい。これらの利点と引き換えに、仕様への最大の影響が想定される。
【０２６２】
Idle UEのためのSC-PTMの受信品質が無視されない場合、すなわち、ベストエフォート型の受信である場合、RAN2はIdle UEで、SC-PTM受信の少なくとも中程度の品質を確保する方法を議論する必要がある。選択肢1は、エラーデータの再送信が想定されていないのでデータの損失を引き起こす可能性があるが、現在の仕様の単純な拡張で動作する。選択肢2は、リンクアダプテーションだけでなく、再送の利益を持っており、標準化に大きな努力が予想される一方で、Idle及びConnectedの両方のUEのための統合ソリューションを提供し得る。SC-PTMがMCPTT使用のためのものと想定すると、よりロバストな受信、すなわちデータ損失を最小限にすることが望ましい。よって、選択肢2はRAN2でさらに検討する価値がある。
【０２６３】
提案6：RAN2は、SC-PTMデータが正常に受信されない場合、Idle UEがリンクアダプテーション/再送のためのフィードバックを送信することを許可すべきかどうかを議論すべきである。
【０２６４】
[相互参照]
日本国特許出願第２０１５−０１４０２１（２０１５年１月２８日出願）及び米国仮出願第６２／１６２２０４号（２０１５年５月１５日出願）の全内容が参照により本願明細書に組み込まれている。
【産業上の利用可能性】
【０２６５】
本発明は通信分野において有用である。
【図１】
0006626846.tif 000002
【図２】
0006626846.tif 000003
【図３】
0006626846.tif 000004
【図４】
0006626846.tif 000005
【図５】
0006626846.tif 000006
【図６】
0006626846.tif 000007
【図７】
0006626846.tif 000008
【図８】
0006626846.tif 000009
【図９】
0006626846.tif 000010
【図１０】
0006626846.tif 000011
【図１１】
0006626846.tif 000012