(57)【要約】  一実施形態に係る無線端末は、ＭＢＭＳサービスに属するマルチキャストデータを基地局から受信する。前記無線端末は、前記マルチキャストデータに対応するフィードバック情報を前記基地局に送信するために複数の無線端末が共用する１又は複数の共通リソースプールを示す設定情報を受信し、前記設定情報は、前記フィードバック情報の属性と共通リソースプール及び／又は信号系列との対応関係を示す情報を含む受信部と、前記基地局に送信する前記フィードバック情報の属性と前記対応関係とに基づいて、前記フィードバック情報の送信に用いる特定の共通リソースプール及び／又は前記フィードバック情報の送信に用いる特定の信号系列を選択する制御部と、前記特定の共通リソースプール及び／又は前記特定の信号系列を用いて、前記フィードバック情報を前記基地局に送信する送信部と、を備える。
2018056108.tif 000002
【特許請求の範囲】
【請求項１】
ＭＢＭＳサービスに属するマルチキャストデータを基地局から受信する無線端末であって、
前記マルチキャストデータに対応するフィードバック情報を前記基地局に送信するために複数の無線端末が共用する１又は複数の共通リソースプールを示す設定情報を受信し、前記設定情報は、前記フィードバック情報の属性と共通リソースプール及び／又は信号系列との対応関係を示す情報を含む受信部と、
前記基地局に送信する前記フィードバック情報の属性と前記対応関係とに基づいて、前記フィードバック情報の送信に用いる特定の共通リソースプール及び／又は前記フィードバック情報の送信に用いる特定の信号系列を選択する制御部と、
前記特定の共通リソースプール及び／又は前記特定の信号系列を用いて、前記フィードバック情報を前記基地局に送信する送信部と、を備える
無線端末。
【請求項２】
前記フィードバック情報は、前記マルチキャストデータの受信に失敗したことを示すＮＡＣＫを含む
請求項１に記載の無線端末。
【請求項３】
前記属性は、前記マルチキャストデータが属する前記ＭＢＭＳサービスの識別情報を含む
請求項１に記載の無線端末。
【請求項４】
前記制御部は、前記マルチキャストデータの受信タイミングと前記フィードバック情報の送信タイミングとの間の時間オフセットを予め記憶し、
前記送信部は、前記時間オフセットに応じて定められる前記送信タイミングで前記フィードバック情報を前記基地局に送信する
請求項１に記載の無線端末。
【請求項５】
前記受信部は、所定期間内でマルチキャストデータを複数回受信し、
前記制御部は、前記所定期間内で複数回受信した前記マルチキャストデータに対応する１つのフィードバック情報を生成し、
前記送信部は、前記１つのフィードバック情報を前記基地局に送信する
請求項１に記載の無線端末。
【請求項６】
前記制御部は、
前記基地局から受信する無線信号の品質を測定し、
前記品質を示す値が閾値以上であることに応じて、前記フィードバック情報の送信を無効化し、
前記品質を示す値が前記閾値未満であることに応じて、前記フィードバック情報の送信を有効化する
請求項１に記載の無線端末。
【請求項７】
前記フィードバック情報は、前記マルチキャストデータの受信の成否を示すＡＣＫ／ＮＡＣＫであり、
前記制御部は、
前記基地局から受信する無線信号の品質を測定し、
前記品質を示す値が閾値以上であることに応じて、前記ＡＣＫの送信を無効化するとともに、前記ＮＡＣＫの送信を有効化し、
前記品質を示す値が前記閾値未満であることに応じて、前記ＡＣＫの送信及び前記ＮＡＣＫの送信の両方を有効化する
請求項１に記載の無線端末。
【請求項８】
前記送信部は、前記品質を示す値が閾値以上であるか否かを示す情報を前記基地局にさらに送信する
請求項７に記載の無線端末。
【請求項９】
前記受信部は、前記フィードバック情報の送信が必要とされる前記ＭＢＭＳサービスを示す所定情報を前記基地局からさらに受信し、
前記制御部は、前記所定情報に基づいて、前記フィードバック情報の送信が必要とされる前記ＭＢＭＳサービスを判断する
請求項１に記載の無線端末。
【請求項１０】
ＭＢＭＳサービスに属するマルチキャストデータを送信する基地局であって、
前記マルチキャストデータに対応するフィードバック情報を前記基地局に送信するために複数の無線端末が共用する１又は複数の共通リソースプールを示す設定情報を送信し、前記設定情報は、前記フィードバック情報の属性と共通リソースプール及び／又は信号系列との対応関係を示す情報を含む送信部と、
特定の共通リソースプール及び／又は特定の信号系列を用いて前記無線端末から送信された前記フィードバック情報を受信する受信部と、
前記特定の共通リソースプール及び／又は前記特定の信号系列と前記対応関係とに基づいて、前記無線端末から受信した前記フィードバック情報の属性を判断する制御部と、を備える
基地局。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、移動通信システムのための無線端末及び基地局に関する。
【背景技術】
【０００２】
移動通信システムの標準化プロジェクトである３ＧＰＰ（Ｔｈｉｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）において、無線端末にマルチキャスト／ブロードキャストサービスを提供するＭＢＭＳ（Ｍｕｌｔｉｍｅｄｉａ  Ｂｒｏａｄｃａｓｔ  Ｍｕｌｔｉｃａｓｔ  Ｓｅｒｖｉｃｅ）が仕様化されている。ＭＢＭＳ用の無線伝送方式としては、ＭＢＳＦＮ（Ｍｕｌｔｉｃａｓｔ  Ｂｒｏａｄｃａｓｔ  Ｓｉｎｇｌｅ  Ｆｒｅｑｕｅｎｃｙ  Ｎｅｔｗｏｒｋ）伝送及びＳＣ−ＰＴＭ（Ｓｉｎｇｌｅ  Ｃｅｌｌ  Ｐｏｉｎｔ−Ｔｏ−Ｍｕｌｔｉｐｏｉｎｔ）伝送の２つの方式がある。ＭＢＭＳは、同一の無線リソースを用いて複数の無線端末に同一のデータを送信するので、無線リソースの利用効率を高めることができる。
【発明の概要】
【０００３】
一実施形態に係る無線端末は、ＭＢＭＳサービスに属するマルチキャストデータを基地局から受信する。前記無線端末は、前記マルチキャストデータに対応するフィードバック情報を前記基地局に送信するために複数の無線端末が共用する１又は複数の共通リソースプールを示す設定情報を受信し、前記設定情報は、前記フィードバック情報の属性と共通リソースプール及び／又は信号系列との対応関係を示す情報を含む受信部と、前記基地局に送信する前記フィードバック情報の属性と前記対応関係とに基づいて、前記フィードバック情報の送信に用いる特定の共通リソースプール及び／又は前記フィードバック情報の送信に用いる特定の信号系列を選択する制御部と、前記特定の共通リソースプール及び／又は前記特定の信号系列を用いて、前記フィードバック情報を前記基地局に送信する送信部と、を備える。
【０００４】
一実施形態に係る基地局は、ＭＢＭＳサービスに属するマルチキャストデータを送信する。前記基地局は、前記マルチキャストデータに対応するフィードバック情報を前記基地局に送信するために複数の無線端末が共用する１又は複数の共通リソースプールを示す設定情報を送信し、前記設定情報は、前記フィードバック情報の属性と共通リソースプール及び／又は信号系列との対応関係を示す情報を含む送信部と、特定の共通リソースプール及び／又は特定の信号系列を用いて前記無線端末から送信された前記フィードバック情報を受信する受信部と、前記特定の共通リソースプール及び／又は前記特定の信号系列と前記対応関係とに基づいて、前記無線端末から受信した前記フィードバック情報の属性を判断する制御部と、を備える。
【図面の簡単な説明】
【０００５】
【図１】実施形態に係るＬＴＥシステムの構成を示す図である。
【図２】実施形態に係るＭＢＭＳに係るネットワーク構成を示す図である。
【図３】実施形態に係るＵＥ（無線端末）の構成を示す図である。
【図４】実施形態に係るｅＮＢ（基地局）の構成を示す図である。
【図５】実施形態に係るＬＴＥシステムにおける無線インターフェイスのプロトコルスタックを示す図である。
【図６】実施形態に係るＬＴＥシステムの下りリンクのチャネルの構成を示す図である。
【図７】実施形態に係るＬＴＥシステムの無線フレームの構成を示す図である。
【図８】実施形態に係るＳＣ−ＰＴＭの動作の一例を示す図である。
【図９】実施形態に係るＳＩＢ２０を示す図である。
【図１０】実施形態に係るＳＣＰＴＭ設定情報（ＳＣＰＴＭ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ）を示す図である。
【図１１】実施形態に係るＮＡＣＫ−ｏｎｌｙ  ｆｅｅｄｂａｃｋの動作シーケンスの一例を示す図である。
【図１２】実施形態に係る共通リソースプールの一例を示す図である。
【図１３】実施形態に係る共通リソースプールに係る動作シーケンスの一例を示す図である。
【図１４】実施例１に係る動作シーケンスを示す図である。
【図１５】実施例１に係る共通リソースプールの一例を示す図である。
【図１６】実施例２に係る動作シーケンスを示す図である。
【図１７】実施例３に係る動作を示す図である。
【図１８】実施例４に係る動作を示す図である。
【図１９】実施例６に係る動作を示す図である。
【図２０】付記に係る図である。
【発明を実施するための形態】
【０００６】
（移動通信システム）
実施形態に係る移動通信システムの構成について説明する。実施形態に係る移動通信システムは、３ＧＰＰで仕様が策定されているＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）システムである。図１は、実施形態に係るＬＴＥシステムの構成を示す図である。図２は、ＭＢＭＳに係るネットワーク構成を示す図である。
【０００７】
図１に示すように、ＬＴＥシステムは、無線端末（ＵＥ：Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）１００、無線アクセスネットワーク（Ｅ−ＵＴＲＡＮ：Ｅｖｏｌｖｅｄ−ＵＭＴＳ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）１０、及びコアネットワーク（ＥＰＣ：Ｅｖｏｌｖｅｄ  Ｐａｃｋｅｔ  Ｃｏｒｅ）２０を備える。Ｅ−ＵＴＲＡＮ１０及びＥＰＣ２０は、ＬＴＥシステムのネットワークを構成する。
【０００８】
ＵＥ１００は、移動型の通信装置である。ＵＥ１００は、当該ＵＥ１００が在圏するセル（サービングセル）を管理するｅＮＢ２００との無線通信を行う。
【０００９】
Ｅ−ＵＴＲＡＮ１０は、基地局（ｅＮＢ：ｅｖｏｌｖｅｄ  Ｎｏｄｅ−Ｂ）２００を含む。ｅＮＢ２００は、Ｘ２インターフェイスを介して相互に接続される。ｅＮＢ２００は、１又は複数のセルを管理する。ｅＮＢ２００は、当該ｅＮＢ２００が管理するセルとの接続を確立したＵＥ１００との無線通信を行う。ｅＮＢ２００は、無線リソース管理（ＲＲＭ）機能、ユーザデータ（以下、単に「データ」という）のルーティング機能、モビリティ制御・スケジューリングのための測定制御機能等を有する。「セル」は、無線通信エリアの最小単位を示す用語として用いられる。「セル」は、ＵＥ１００との無線通信を行う機能又はリソースを示す用語としても用いられる。
【００１０】
ＥＰＣ２０は、モビリティ管理エンティティ（ＭＭＥ）及びサービングゲートウェイ（Ｓ−ＧＷ）３００を含む。ＭＭＥは、ＵＥ１００に対する各種モビリティ制御等を行う。Ｓ−ＧＷは、データの転送制御を行う。ＭＭＥ／Ｓ−ＧＷ３００は、Ｓ１インターフェイスを介してｅＮＢ２００と接続される。
【００１１】
次に、ＭＢＭＳ向けのネットワークエンティティについて説明する。Ｅ−ＵＴＲＡＮ１０は、ＭＣＥ（Ｍｕｌｔｉ−Ｃｅｌｌ／Ｍｕｌｔｉｃａｓｔ  Ｃｏｏｒｄｉｎａｔｉｎｇ  Ｅｎｔｉｔｙ）１１を含む。ＭＣＥ１１は、Ｍ２インターフェイスを介してｅＮＢ２００と接続される。ＭＣＥ１１は、Ｍ３インターフェイスを介してＭＭＥ３００と接続される（図２参照）。ＭＣＥ１１は、ＭＢＳＦＮ無線リソース管理・割当等を行う。具体的には、ＭＣＥ１１は、ＭＢＳＦＮ伝送のスケジューリングを行う。これに対し、ＳＣ−ＰＴＭ伝送のスケジューリングはｅＮＢ２００により行われる。
【００１２】
ＥＰＣ２０は、ＭＢＭＳ  ＧＷ（ＭＢＭＳ  Ｇａｔｅｗａｙ）２１を含む。ＭＢＭＳ  ＧＷ２１は、Ｍ１インターフェイスを介してｅＮＢ２００と接続される。ＭＢＭＳ  ＧＷ２１は、Ｓｍインターフェイスを介してＭＭＥ３００と接続される。ＭＢＭＳ  ＧＷ２１は、ＳＧ−ｍｂ及びＳＧｉ−ｍｂインターフェイスを介してＢＭ−ＳＣ２２と接続される（図２参照）。ＭＢＭＳ  ＧＷ２１は、ｅＮＢ２００に対してＩＰマルチキャストのデータ伝送及びセッション制御等を行う。
【００１３】
ＥＰＣ２０は、ＢＭ−ＳＣ（Ｂｒｏａｄｃａｓｔ  Ｍｕｌｔｉｃａｓｔ  Ｓｅｒｖｉｃｅ  Ｃｅｎｔｅｒ）２２を含む。ＢＭ−ＳＣ２２は、ＳＧ−ｍｂ及びＳＧｉ−ｍｂインターフェイスを介してＭＢＭＳ  ＧＷ２１と接続される。ＢＭ−ＳＣ２２は、ＳＧｉインターフェイスを介してＰ−ＧＷ２３と接続される（図２参照）。ＢＭ−ＳＣ２２は、ＴＭＧＩ（Ｔｅｍｐｏｒａｒｙ  Ｍｏｂｉｌｅ  Ｇｒｏｕｐ  Ｉｄｅｎｔｉｔｙ）の管理・割当等を行う。
【００１４】
ＥＰＣ２０の外部のネットワーク（すなわち、インターネット）には、ＧＣＳ  ＡＳ（Ｇｒｏｕｐ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｓｅｒｖｉｃｅ  Ａｐｐｌｉｃａｔｉｏｎ  Ｓｅｒｖｅｒ）３１が設けられる。ＧＣＳ  ＡＳ３１は、グループ通信用のアプリケーションサーバである。ＧＣＳ  ＡＳ３１は、ＭＢ２−Ｕ及びＭＢ２−Ｃインターフェイスを介してＢＭ−ＳＣ２２と接続されるＧＣＳ  ＡＳ３１は、ＳＧｉインターフェイスを介してＰ−ＧＷ２３と接続される。ＧＣＳ  ＡＳ３１は、グループ通信におけるグループの管理及びデータ配信等を行う。
【００１５】
図３は、実施形態に係るＵＥ１００（無線端末）の構成を示す図である。図３に示すように、ＵＥ１００は、受信部１１０、送信部１２０、及び制御部１３０を備える。
【００１６】
受信部１１０は、制御部１３０の制御下で各種の受信を行う。受信部１１０は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換する。受信機は、ベースバンド信号を制御部１３０に出力する。
【００１７】
送信部１２０は、制御部１３０の制御下で各種の送信を行う。送信部１２０は、アンテナ及び送信機を含む。送信機は、制御部１３０が出力するベースバンド信号（送信信号）を無線信号に変換する。送信機は、無線信号をアンテナから送信する。
【００１８】
制御部１３０は、ＵＥ１００における各種の制御を行う。制御部１３０は、プロセッサ及びメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサと、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）と、を含む。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、コーデックを含んでもよい。コーデックは、音声・映像信号の符号化・復号を行う。プロセッサは、後述する各種の処理を実行する。
【００１９】
図４は、実施形態に係るｅＮＢ２００（基地局）の構成を示す図である。図４に示すように、ｅＮＢ２００は、送信部２１０、受信部２２０、制御部２３０、及びバックホール通信部２４０を備える。
【００２０】
送信部２１０は、制御部２３０の制御下で各種の送信を行う。送信部２１０は、アンテナ及び送信機を含む。送信機は、制御部２３０が出力するベースバンド信号（送信信号）を無線信号に変換する。送信機は、無線信号をアンテナから送信する。
【００２１】
受信部２２０は、制御部２３０の制御下で各種の受信を行う。受信部２２０は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換する。受信機は、ベースバンド信号を制御部２３０に出力する。
【００２２】
制御部２３０は、ｅＮＢ２００における各種の制御を行う。制御部２３０は、プロセッサ及びメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサとＣＰＵとを含む。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する各種の処理を実行する。
【００２３】
バックホール通信部２４０は、Ｘ２インターフェイスを介して隣接ｅＮＢと接続される。バックホール通信部２４０は、Ｓ１インターフェイスを介してＭＭＥ／Ｓ−ＧＷ３００と接続される。バックホール通信部２４０は、Ｘ２インターフェイス上で行う通信及びＳ１インターフェイス上で行う通信等に用いられる。
【００２４】
図５は、ＬＴＥシステムにおける無線インターフェイスのプロトコルスタックを示す図である。図５に示すように、無線インターフェイスプロトコルは、ＯＳＩ参照モデルの第１レイヤ乃至第３レイヤに区分されている。第１レイヤは物理（ＰＨＹ）レイヤである。第２レイヤは、ＭＡＣ（Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）レイヤ、ＲＬＣ（Ｒａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ）レイヤ、及びＰＤＣＰ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｃｏｎｖｅｒｇｅｎｃｅ  Ｐｒｏｔｏｃｏｌ）レイヤを含む。第３レイヤは、ＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）レイヤを含む。
【００２５】
物理レイヤは、符号化・復号、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行う。ＵＥ１００の物理レイヤとｅＮＢ２００の物理レイヤとの間では、物理チャネルを介してデータ及び制御信号が伝送される。
【００２６】
ＭＡＣレイヤは、データの優先制御、ＨＡＲＱ（Ｈｙｂｒｉｄ  ＡＲＱ）による再送処理等を行う。ＵＥ１００のＭＡＣレイヤとｅＮＢ２００のＭＡＣレイヤとの間では、トランスポートチャネルを介してデータ及び制御信号が伝送される。ｅＮＢ２００のＭＡＣレイヤは、上下リンクのトランスポートフォーマット（トランスポートブロックサイズ、変調・符号化方式（ＭＣＳ））、及びＵＥ１００への割当リソースブロックを決定するスケジューラを含む。
【００２７】
ＲＬＣレイヤは、ＭＡＣレイヤ及び物理レイヤの機能を利用してデータを受信側のＲＬＣレイヤに伝送する。ＵＥ１００のＲＬＣレイヤとｅＮＢ２００のＲＬＣレイヤとの間では、論理チャネルを介してデータ及び制御信号が伝送される。
【００２８】
ＰＤＣＰレイヤは、ヘッダ圧縮・伸張、及び暗号化・復号化を行う。
【００２９】
ＲＲＣレイヤは、制御信号を取り扱う制御プレーンでのみ定義される。ＵＥ１００のＲＲＣレイヤとｅＮＢ２００のＲＲＣレイヤとの間では、各種設定のためのメッセージ（ＲＲＣメッセージ）が伝送される。ＲＲＣレイヤは、無線ベアラの確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。ＵＥ１００のＲＲＣとｅＮＢ２００のＲＲＣとの間に接続（ＲＲＣ接続）がある場合、ＵＥ１００はＲＲＣコネクティッドモードであり、そうでない場合、ＵＥ１００はＲＲＣアイドルモードである。
【００３０】
ＲＲＣレイヤの上位に位置するＮＡＳ（Ｎｏｎ−Ａｃｃｅｓｓ  Ｓｔｒａｔｕｍ）レイヤは、セッション管理及びモビリティ管理等を行う。
【００３１】
図６は、ＬＴＥシステムの下りリンクのチャネルの構成を示す図である。図６（ａ）は、論理チャネル（Ｄｏｗｎｌｉｎｋ  Ｌｏｇｉｃａｌ  Ｃｈａｎｎｅｌ）とトランポートチャネル（Ｄｏｗｎｌｉｎｋ  Ｔｒａｎｓｐｏｒｔ  Ｃｈａｎｎｅｌ）との間のマッピングを示す。
【００３２】
図６（ａ）に示すように、ＰＣＣＨ（Ｐａｇｉｎｇ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）は、ページング情報、及びシステム情報変更を通知するための論理チャネルである。ＰＣＣＨは、トランスポートチャネルであるＰＣＨ（Ｐａｇｉｎｇ  Ｃｈａｎｎｅｌ）にマッピングされる。
【００３３】
ＢＣＣＨ（Ｂｒｏａｄｃａｓｔ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）は、システム情報のための論理チャネルである。ＢＣＣＨは、トランスポートチャネルであるＢＣＨ（Ｂｒｏａｄｃａｓｔ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）及びＤＬ−ＳＣＨ（Ｄｏｗｎｌｉｎｋ  Ｓｈａｒｅｄ  Ｃｈａｎｎｅｌ）にマッピングされる。
【００３４】
ＣＣＣＨ（Ｃｏｍｍｏｎ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）は、ＵＥ１００とｅＮＢ２００との間の送信制御情報のための論理チャネルである。ＣＣＣＨは、ＵＥ１００がネットワークとの間でＲＲＣ接続を有していない場合に用いられる。ＣＣＣＨは、ＤＬ−ＳＣＨにマッピングされる。
【００３５】
ＤＣＣＨ（Ｄｅｄｉｃａｔｅｄ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）は、ＵＥ１００とネットワークとの間の個別制御情報を送信するための論理チャネルである。ＤＣＣＨは、ＵＥ１００がＲＲＣ接続を有する場合に用いられる。ＤＣＣＨは、ＤＬ−ＳＣＨにマッピングされる。
【００３６】
ＤＴＣＨ（Ｄｅｄｉｃａｔｅｄ  Ｔｒａｆｆｉｃ  Ｃｈａｎｎｅｌ）は、データ送信のための個別論理チャネルである。ＤＴＣＨは、ＤＬ−ＳＣＨにマッピングされる。
【００３７】
ＳＣ−ＭＴＣＨ（Ｓｉｎｇｌｅ  Ｃｅｌｌ  Ｍｕｌｔｉｃａｓｔ  Ｔｒａｆｆｉｃ  Ｃｈａｎｎｅｌ）は、ＳＣ−ＰＴＭ伝送のための論理チャネルである。ＳＣ−ＭＴＣＨは、ＳＣ−ＰＴＭ伝送を用いてネットワークからＵＥ１００にデータを送信するための１対多チャネル（ｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔ  ｄｏｗｎｌｉｎｋ  ｃｈａｎｎｅｌ）である。
【００３８】
ＳＣ−ＭＣＣＨ（Ｓｉｎｇｌｅ  Ｃｅｌｌ  Ｍｕｌｔｉｃａｓｔ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）は、ＳＣ−ＰＴＭ伝送のための論理チャネルである。ＳＣ−ＭＴＣＨは、１又は複数のＳＣ−ＭＴＣＨのためのＭＢＭＳ制御情報をネットワークからＵＥ１００に送信するための１対多チャネル（ｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔ  ｄｏｗｎｌｉｎｋ  ｃｈａｎｎｅｌ）である。ＳＣ−ＭＣＣＨは、ＳＣ−ＰＴＭを用いてＭＢＭＳを受信する又は受信に興味を持つＵＥ１００に用いられる。また、ＳＣ−ＭＣＣＨは、１つのセルに１つのみ存在する。
【００３９】
ＭＣＣＨ（Ｍｕｌｔｉｃａｓｔ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）は、ＭＢＳＦＮ伝送のための論理チャネルである。ＭＣＣＨは、ネットワークからＵＥ１００へのＭＴＣＨ用のＭＢＭＳ制御情報の送信のために用いられる。ＭＣＣＨは、トランスポートチャネルであるＭＣＨ（Ｍｕｌｔｉｃａｓｔ  Ｃｈａｎｎｅｌ）にマッピングされる。
【００４０】
ＭＴＣＨ（Ｍｕｌｔｉｃａｓｔ  Ｔｒａｆｆｉｃ  Ｃｈａｎｎｅｌ）は、ＭＢＳＦＮ伝送のための論理チャネルである。ＭＴＣＨは、ＭＣＨにマッピングされる。
【００４１】
図６（ｂ）は、トランポートチャネル（Ｄｏｗｎｌｉｎｋ  Ｔｒａｎｓｐｏｒｔ  Ｃｈａｎｎｅｌ）と物理チャネル（Ｄｏｗｎｌｉｎｋ  Ｐｈｙｓｉｃａｌ  Ｃｈａｎｎｅｌ）との間のマッピングを示す。
【００４２】
図６（ｂ）に示すように、ＢＣＨは、ＰＢＣＨ（Ｐｈｙｓｉｃａｌ  Ｂｒｏａｄｃａｓｔ  Ｃｈａｎｎｅｌ）にマッピングされる。
【００４３】
ＭＣＨは、ＰＭＣＨ（Ｐｈｙｓｉｃａｌ  Ｍｕｌｔｉｃａｓｔ  Ｃｈａｎｎｅｌ）にマッピングされる。ＭＣＨは、複数のセルによるＭＢＳＦＮ伝送をサポートする。
【００４４】
ＰＣＨ及びＤＬ−ＳＣＨは、ＰＤＳＣＨ（Ｐｈｙｓｉｃａｌ  Ｄｏｗｎｌｉｎｋ  Ｓｈａｒｅｄ  Ｃｈａｎｎｅｌ）にマッピングされる。ＤＬ−ＳＣＨは、ＨＡＲＱ、リンクアダプテーション、及び動的リソース割当をサポートする。
【００４５】
ＰＤＣＣＨは、ＰＤＳＣＨ（ＤＬ−ＳＣＨ、ＰＣＨ）のリソース割り当て情報及びＤＬ−ＳＣＨに関するＨＡＲＱ情報等を運搬する。また、ＰＤＣＣＨは、上りリンクのスケジューリンググラントを運ぶ。
【００４６】
図７は、ＬＴＥシステムの無線フレームの構成を示す図である。ＬＴＥシステムにおいて、下りリンクにはＯＦＤＭＡ（Ｏｒｔｈｏｇｏｎａｌ  Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ）、上りリンクにはＳＣ−ＦＤＭＡ（Ｓｉｎｇｌｅ  Ｃａｒｒｉｅｒ  Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ）がそれぞれ適用される。
【００４７】
図７に示すように、無線フレームは、時間方向に並ぶ１０個のサブフレームで構成される。各サブフレームは、時間方向に並ぶ２個のスロットで構成される。各サブフレームの長さは１ｍｓであり、各スロットの長さは０．５ｍｓである。各サブフレームは、周波数方向に複数個のリソースブロック（ＲＢ）を含み、時間方向に複数個のシンボルを含む。各リソースブロックは、周波数方向に複数個のサブキャリアを含む。１つのシンボル及び１つのサブキャリアにより１つのリソースエレメント（ＲＥ）が構成される。また、ＵＥ１００に割り当てられる無線リソース（時間・周波数リソース）のうち、周波数リソースはリソースブロックにより特定でき、時間リソースはサブフレーム（又はスロット）により特定できる。
【００４８】
下りリンクにおいて、各サブフレームの先頭数シンボルの区間は、主に下りリンク制御信号を伝送するためのＰＤＣＣＨとして用いられる領域である。また、各サブフレームの残りの部分は、主に下りリンクデータを伝送するためのＰＤＳＣＨとして使用できる領域である。また、下りリンクにおいて、ＭＢＳＦＮ伝送向けのサブフレームであるＭＢＳＦＮサブフレームが設定され得る。
【００４９】
上りリンクにおいて、各サブフレームにおける周波数方向の両端部は、主に上りリンク制御信号を伝送するためのＰＵＣＣＨとして用いられる領域である。各サブフレームにおける残りの部分は、主に上りリンクデータを伝送するためのＰＵＳＣＨとして使用できる領域である。
【００５０】
（ＳＣ−ＰＴＭの概要）
ＭＢＭＳ用の無線伝送方式としては、ＭＢＳＦＮ伝送及びＳＣ−ＰＴＭ伝送の２つの方式がある。ＭＢＳＦＮ伝送においては、複数のセルからなるＭＢＳＦＮエリア単位で、ＰＭＣＨを介してデータが送信される。これに対し、ＳＣ−ＰＴＭ伝送においては、セル単位で、ＰＤＳＣＨを介してデータが送信される。以下においては、ＵＥ１００がＳＣ−ＰＴＭ受信を行うシナリオを主として想定するが、ＭＢＳＦＮを想定してもよい。
【００５１】
ＵＥ１００は、ＲＲＣコネクティッドモードでＭＢＭＳサービスを受信してもよい。ＵＥ１００は、ＲＲＣアイドルモードでＭＢＭＳサービスを受信してもよい。以下において、ＵＥ１００がＲＲＣアイドルモードでＭＢＭＳサービスを受信するケースを主として想定する。
【００５２】
図８は、ＳＣ−ＰＴＭの動作の一例を示す図である。
【００５３】
図８に示すように、ステップＳ１において、ＵＥ１００は、ｅＮＢ２００を介してＥＰＣ２０からＵＳＤ（Ｕｓｅｒ  Ｓｅｒｖｉｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ）を取得する。ＵＳＤは、各ＭＢＭＳサービスの基本的な情報を提供する。ＵＳＤは、ＭＢＭＳサービスごとに、当該ＭＢＭＳサービスを識別するＴＭＧＩと、当該ＭＢＭＳサービスが提供される周波数と、当該ＭＢＭＳサービスの提供開始・終了時間と、を含む。
【００５４】
ステップＳ２において、ＵＥ１００は、ＢＣＣＨを介してｅＮＢ２００からＳＩＢ２０を受信する。ＳＩＢ２０は、ＳＣ−ＭＣＣＨの取得に必要な情報（スケジューリング情報）を含む。図９は、ＳＩＢ２０を示す図である。図９に示すように、ＳＩＢ２０は、ＳＣ−ＭＣＣＨの内容が変更され得る周期を示すｓｃ−ｍｃｃｈ−ＭｏｄｉｆｉｃａｔｉｏｎＰｅｒｉｏｄ、ＳＣ−ＭＣＣＨの送信（再送）時間間隔を無線フレーム数で示すｓｃ−ｍｃｃｈ−ＲｅｐｅｔｉｔｉｏｎＰｅｒｉｏｄ、ＳＣ−ＭＣＣＨがスケジュールされる無線フレームのオフセットを示すｓｃ−ｍｃｃｈ−Ｏｆｆｓｅｔ、及びＳＣ−ＭＣＣＨがスケジュールされるサブフレームを示すｓｃ−ｍｃｃｈ−Ｓｕｂｆｒａｍｅ等を含む。
【００５５】
ステップＳ３において、ＵＥ１００は、ＳＩＢ２０に基づいて、ＳＣ−ＭＣＣＨを介してｅＮＢ２００からＳＣＰＴＭ設定情報（ＳＣＰＴＭ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ）を受信する。物理レイヤにおいてＳＣ−ＭＣＣＨの送信にはＳＣ−ＲＮＴＩ（Ｓｉｎｇｌｅ  Ｃｅｌｌ  ＲＮＴＩ）が用いられる。図１０は、ＳＣ−ＭＣＣＨ中のＳＣＰＴＭ設定情報（ＳＣＰＴＭ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ）を示す図である。図１０に示すように、ＳＣＰＴＭ設定情報は、ＳＣ−ＭＲＢ（Ｓｉｎｇｌｅ  Ｃｅｌｌ  ＭＢＭＳ  Ｐｏｉｎｔ  ｔｏ  Ｍｕｌｔｉｐｏｉｎｔ  Ｒａｄｉｏ  Ｂｅａｒｅｒ）を介して送信されるＭＢＭＳサービスに適用可能な制御情報を含む。ＳＣＰＴＭ設定情報は、当該情報を送信するセルにおける各ＳＣ−ＭＴＣＨの設定を含むｓｃ−ｍｔｃｈ−ＩｎｆｏＬｉｓｔ、及びＳＣ−ＭＲＢを介してＭＢＭＳサービスを提供する隣接セルのリストであるｓｃｐｔｍＮｅｉｇｈｂｏｕｒＣｅｌｌＬｉｓｔを含む。ｓｃ−ｍｔｃｈ−ＩｎｆｏＬｉｓｔは、１又は複数のＳＣ−ＭＴＣＨ−Ｉｎｆｏを含む。各ＳＣ−ＭＴＣＨ−Ｉｎｆｏは、ＳＣ−ＭＲＢを介して送信される進行中のＭＢＭＳセッションの情報（ｍｂｍｓＳｅｓｓｉｏｎＩｎｆｏ）、当該ＭＢＭＳセッションに対応するＧ−ＲＮＴＩ（Ｇｒｏｕｐ  ＲＮＴＩ）、及びＳＣ−ＭＴＣＨのためのＤＲＸ情報であるｓｃ−ｍｔｃｈ−ｓｃｈｅｄｕｌｉｎｇＩｎｆｏを含む。ｍｂｍｓＳｅｓｓｉｏｎＩｎｆｏは、ＭＢＭＳサービスを識別するＴＭＧＩ及びセッションＩＤ（ｓｅｓｓｉｏｎＩｄ）を含む。Ｇ−ＲＮＴＩは、マルチキャストグループ（具体的には、特定グループ宛てのＳＣ−ＭＴＣＨ）を識別するＲＮＴＩである。Ｇ−ＲＮＴＩは、ＴＭＧＩと１対１でマッピングされる。ｓｃ−ｍｔｃｈ−ｓｃｈｅｄｕｌｉｎｇＩｎｆｏは、ｏｎＤｕｒａｔｉｏｎＴｉｍｅｒＳＣＰＴＭ、ｄｒｘ−ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒＳＣＰＴＭ、ｓｃｈｅｄｕｌｉｎｇＰｅｒｉｏｄＳｔａｒｔＯｆｆｓｅｔＳＣＰＴＭを含む。ｓｃｈｅｄｕｌｉｎｇＰｅｒｉｏｄＳｔａｒｔＯｆｆｓｅｔＳＣＰＴＭは、ＳＣ−ＭＴＣＨ−ＳｃｈｅｄｕｌｉｎｇＣｙｃｌｅ及びＳＣ−ＭＴＣＨ−ＳｃｈｅｄｕｌｉｎｇＯｆｆｓｅｔを含む。
【００５６】
ステップＳ４において、ＵＥ１００は、ＳＣＰＴＭ設定情報（ＳＣＰＴＭ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ）中のＳＣ−ＭＴＣＨ−ＳｃｈｅｄｕｌｉｎｇＩｎｆｏに基づいて、ＳＣ−ＭＴＣＨを介して、自身が興味のあるＴＭＧＩに対応するＭＢＭＳサービス（マルチキャストデータ）を受信する。物理レイヤにおいて、ｅＮＢ２００は、Ｇ−ＲＮＴＩを用いてＰＤＣＣＨを送信した後、ＰＤＳＣＨを介してマルチキャストデータを送信する。
【００５７】
（ＮＡＣＫ−ｏｎｌｙ  ＨＡＲＱフィードバックの基本動作）
実施形態において、ＳＣ−ＰＴＭにフィードバックを導入する。以下において、フィードバック情報が送達確認情報（ＡＣＫ／ＮＡＣＫ）であるケースを主として想定する。また、ＳＣ−ＰＴＭ受信を行うＵＥ１００がＲＲＣアイドルモードであるケースを主として想定する。
【００５８】
ＵＥ１００の送信部１２０は、下りリンクのユニキャスト伝送が適用される場合、下りリンクデータを正しく受信したことを示す肯定応答（ＡＣＫ）及び下りリンクデータの受信に失敗したことを示す否定応答（ＮＡＣＫ）の何れかをフィードバック情報としてｅＮＢ２００に送信する。すなわち、下りリンクデータの受信に失敗すればＮＡＣＫを送信し、下りリンクデータを正しく受信すればＡＣＫを送信する。ＡＣＫとはＨＡＲＱ  ＡＣＫである。ＮＡＣＫとはＨＡＲＱ  ＮＡＣＫである。
【００５９】
一方、ＳＣ−ＰＴＭが適用される場合、制御部１３０は、ＡＣＫ及びＮＡＣＫのうちＮＡＣＫのみをフィードバック情報としてｅＮＢ２００に送信するように、ＡＣＫの送信を停止する。すなわち、下りリンクデータ（マルチキャストデータ）の受信に失敗すればＮＡＣＫを送信するが、下りリンクデータ（マルチキャストデータ）を正しく受信してもＡＣＫを送信しない。このように、ＳＣ−ＰＴＭについてはＮＡＣＫのみを送達確認情報として使用することにより、ＡＣＫの送信に伴う上りリンク無線リソース（例えば、ＰＵＣＣＨリソース）を節約することができる。
【００６０】
また、ＳＣ−ＰＴＭが適用される場合、ＵＥ１００の送信部１２０は、複数のＵＥ１００からなるＵＥグループ（マルチキャストグループ）で共通の無線リソース（例えばリソースエレメント等）、且つ共通の信号系列（例えばベースシーケンス等）を用いて、ＮＡＣＫを送信する。具体的には、このような共通リソースプールがｅＮＢ２００からＵＥグループごとに割り当てられており、ＵＥ１００は、自身が属するＵＥグループの共通リソースプールを用いてＮＡＣＫを送信する。ＵＥグループは、ＴＭＧＩ及び／又はＧ−ＲＮＴＩにより識別される。このような共通リソースプールの割り当ては、システム情報（ＳＩＢ：Ｓｙｓｔｅｍ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂｌｏｃｋ）によりブロードキャストで指定してもよいし、ＰＤＣＣＨでのＳＣ−ＰＴＭ割当時のＤＣＩで指定してもよい。
【００６１】
このように、共通リソースプールを用いることにより、ＵＥ１００個別のリソース割り当てが不要となるため、ＲＲＣアイドルモードのＵＥ１００であってもフィードバック情報をｅＮＢ２００に送信することができる。また、ＮＡＣＫの送信に伴う上りリンク無線リソース（例えばＰＵＣＣＨリソース）も節約することができる。
【００６２】
但し、このような共通リソースプールによるＮＡＣＫを適用することにより、複数のＵＥ１００のＮＡＣＫが合成されることになり、ｅＮＢ２００はＮＡＣＫの送信元ＵＥを識別することができない。しかしながら、再送をグループ内各ＵＥ１００にマルチキャストで行うことにより、どのＵＥ１００からのＮＡＣＫであるかを識別することを要しない。
【００６３】
次に、ｅＮＢ２００の動作について説明する。ｅＮＢ２００の受信部２２０は、下りリンクのユニキャスト伝送が適用される場合、下りリンクデータを正しく受信したことを示すＡＣＫ及び下りリンクデータの受信に失敗したことを示すＮＡＣＫの何れかをフィードバック情報としてＵＥ１００から受信する。一方、ＳＣ−ＰＴＭが適用される場合、ｅＮＢ２００の受信部２２０は、ＡＣＫ及びＮＡＣＫのうちＮＡＣＫのみをフィードバック情報としてＵＥ１００から受信する。ＳＣ−ＰＴＭが適用される場合、ｅＮＢ２００の制御部２３０は、ＵＥグループに対して、ＮＡＣＫの送信用に共通の無線リソース、且つ共通の信号系列を割り当てる。具体的には、このような共通リソースプールをＵＥグループごとに割り当てる。
【００６４】
次に、動作シーケンスの一例について説明する。図１１は、ＮＡＣＫ−ｏｎｌｙ  ｆｅｅｄｂａｃｋの動作シーケンスの一例を示す図である。
【００６５】
図１１に示すように、ステップＳ１０１において、ｅＮＢ２００は、ＮＡＣＫ送信用の共通リソースプールに関する設定情報をグループ内ＵＥ１００（ＵＥ１００−１、ＵＥ１００−２）に送信する。ＮＡＣＫ送信用の共通リソースプールに関する設定情報は、システム情報（ＳＩＢ）によりｅＮＢ２００からブロードキャスト伝送してもよい。設定情報は、個別のＲＲＣメッセージによりｅＮＢ２００からユニキャスト伝送してもよい。各ＵＥ１００は、設定情報を受信して記憶する。
【００６６】
ステップＳ１０２において、ｅＮＢ２００は、ＳＣ−ＰＴＭによるマルチキャスト伝送を開始する。
【００６７】
ステップＳ１０３において、ＵＥ１００（ＵＥ１００−１、ＵＥ１００−２）は、受信したマルチキャストデータの復号を試みる。
【００６８】
ステップＳ１０４において、ＵＥ１００（ＵＥ１００−１、ＵＥ１００−２）は、マルチキャストデータの復号に成功したか否かを確認する。ここでは、ＵＥ１００−１が復号に失敗し、ＵＥ１００−２が復号に成功した場合を想定する。
【００６９】
ステップＳ１０５において、ＵＥ１００−２は、ｅＮＢ２００へのフィードバック情報（ＮＡＣＫ）の送信を停止する。
【００７０】
一方、ステップＳ１０６において、ＵＥ１００−１は、ＮＡＣＫ送信用の共通リソースプールを用いて、ＮＡＣＫをｅＮＢ２００に送信する。
【００７１】
ステップＳ１０７において、ｅＮＢ２００は、ＮＡＣＫの受信に応じて、再送データをグループ内ＵＥ１００（ＵＥ１００−１、ＵＥ１００−２）に送信する。Ｓ１０４−２で受信に成功したＵＥ１００−２は、当該再送データを受信しなくてもよい。当該データが再送データであるか否かは、当該データを運ぶＰＤＳＣＨに対応するＰＤＣＣＨ内のＮＤＩ（Ｎｅｗ  Ｄａｔａ  Ｉｎｄｉｃａｔｏｒ）がトグルされているか否かによって判定可能である。具体的には、ＵＥ１００−２は、Ｓ１０３−２においてデータ（ＰＤＳＣＨ）を復号した時のＮＤＩ（ＰＤＣＣＨ内）とＳ１０７の再送時のＮＤＩとが同一の値であれば再送データであると判定し、これらが異なる値であれば再送データではないと判定する。
【００７２】
その後、ステップＳ１０８において、ＵＥ１００（ＵＥ１００−１、ＵＥ１００−２）は、新たに受信したマルチキャストデータの復号に成功したか否かを確認する。ここでは、ＵＥ１００−１及びＵＥ１００−２が何れも復号に失敗した場合（Ｓ１０９：ＮＯ）を想定する。
【００７３】
ステップＳ１１０において、ＵＥ１００−１及びＵＥ１００−２は、ＮＡＣＫ送信用の共通リソースプールを用いて、ＮＡＣＫをｅＮＢ２００に送信する。これらのＮＡＣＫは、合成された状態でｅＮＢ２００により受信される。
【００７４】
ステップＳ１１１において、ｅＮＢ２００は、ＮＡＣＫの受信に応じて、再送データをグループ内ＵＥ１００（ＵＥ１００−１、ＵＥ１００−２）に送信する。
【００７５】
このように、ＳＣ−ＰＴＭについてはＮＡＣＫのみを送達確認情報として使用することにより、ＡＣＫの送信に伴う上りリンク無線リソース（例えば、ＰＵＣＣＨリソース）を節約することができる。また、ＵＥグループごとの共通リソースプールを用いてＮＡＣＫを送信することにより、ＮＡＣＫの送信に伴う上りリンク無線リソースも節約することができる。
【００７６】
従って、ＮＡＣＫ−ｏｎｌｙ  ＨＡＲＱフィードバックによれば、マルチキャストデータを受信したＵＥ１００のうち、受信に失敗したＵＥ１００が同一リソース・同一信号系列でＮＡＣＫ情報をｅＮＢ２００にフィードバックすることにより、ｅＮＢ２００ではマルチパス合成の要領で受信が可能である。また、ＵＥ個別のリソース・信号系列設定が不要なため、ＲＲＣアイドルモードのＵＥ１００でもフィードバック送信が可能である。
【００７７】
次に、共通リソースプールについて説明する。ＵＥ１００の受信部１１０は、同一の下りリンク無線リソースを使用してｅＮＢ２００から複数のＵＥ１００に送信されるマルチキャストデータを受信する。制御部１３０は、共通リソースプールの中からフィードバック用リソースを選択する。共通リソースプールは、複数のＵＥ１００からなるグループ（ＵＥグループ）に対してｅＮＢ２００から割り当てられたリソースプールである。フィードバック用リソースは、フィードバック情報の送信に使用する上りリンク無線リソースである。送信部１２０は、選択されたフィードバック用リソースを使用して、フィードバック情報をｅＮＢ２００に送信する。
【００７８】
図１２は、共通リソースプールの一例を示す図である。図１２に示すように、共通リソースプールは、全ての上りリンク無線リソースのうちの一部である。共通リソースプールは、ｅＮＢ２００から各ＵＥ１００に個別に割り当てられる物理上りリンク制御チャネル（ＰＵＣＣＨ）とは異なる上りリンク無線リソースからなる。すなわち、上りリンク周波数帯の両端部よりも内側に共通リソースプールが設けられる。
【００７９】
また、共通リソースプールは、ＵＥグループごとに割り当てられる。例えば、グループ識別子（ＴＭＧＩ、Ｇ−ＲＮＴＩ）に対して共通リソースプールが対応付けられている。図１２の例において、所定の時間リソース（１つのサブフレーム又は１つの無線リソース）内に、３つのＵＥグループ（ｇｒｏｕｐ  １乃至ｇｒｏｕｐ  ３）に対応する３つの共通リソースプールが設けられている。このように、ＵＥグループごとに共通リソースプールを割り当てることにより、フィードバック用リソースをｅＮＢ２００が都度割り当てる場合に比べて、割り当てに伴うシグナリング（スケジューリング情報の送信）を削減することができる。また、ＵＥグループ内のＵＥ１００が共通リソースプール内でフィードバック情報を送信することが保証され、フィードバック制御が複雑にならず、かつ、上りリンク無線リソースの逼迫を回避することができる。
【００８０】
ＵＥ１００の受信部１１０は、共通リソースプールに関する設定情報をｅＮＢ２００から受信する。図１２に示すように、共通リソースプール（ｇｒｏｕｐ  ３）に関する設定情報は、時間軸上における基準点（０シンボル目）と共通リソースプールの始点との間の差分（Ｏｆｓ−ｓｙｍ）、周波数軸上における基準点（０ＲＢ目又はＰＵＣＣＨリソース端）と共通リソースプールの始点との間の差分（Ｏｆｓ−ＲＢ）、時間軸上における共通リソースプールの範囲（Ｒａｎｇｅ−ｓｙｍ）、周波数軸上における共通リソースプールの範囲（Ｒａｎｇｅ−ＲＢ）、のうち少なくとも１つを含む。ここで、時間軸上のパラメータ（Ｏｆｓ−ｓｙｍ、Ｒａｎｇｅ−ｓｙｍ）は、シンボル単位、スロット単位、サブフレーム単位、又は無線フレーム単位で表現される。周波数軸上のパラメータ（Ｏｆｓ−ＲＢ、Ｒａｎｇｅ−ＲＢ）は、サブキャリア単位又はリソースブロック（ＲＢ）単位で表現される。また、これらのパラメータは、周波数バンドごとに規定されてもよい。或いは、これらのパラメータは、所定数のＲＢからなる周波数単位であるサブバンド単位で規定されてもよい。さらに、共通リソースプールに関する設定情報は、「ＯＮ／ＯＦＦパターン」、「周期」を含んでもよい。ＯＮ／ＯＦＦパターンは、サブフレーム又はスロット毎の、あるフィードバック用リソースの有無を表現するパラメータである。周期は、ＯＮ／ＯＦＦパターンの周期を表現するパラメータである。
【００８１】
フィードバック用リソースが存在しないタイミング（ＯＦＦタイミング）に該当する受信信号（４サブフレーム前の受信）については、フィードバック情報の生成及び送信を省略可能である。また、フィードバック用リソースが存在しないタイミング（ＯＦＦタイミング）に該当する受信信号についてのフィードバック情報は、次にフィードバックリソースが存在するタイミング（ＯＮタイミング）において、まとめて送信してもよい。例えば、サブフレームｎとｎ＋１の両方が受信成功である場合にはＡＣＫを、どちらかひとつ以上が受信失敗である場合はＮＡＣＫを、サブフレーム（ｎ＋１）の４サブフレーム後のタイミングでｅＮＢ２００に送信（フィードバック）する。
【００８２】
ＵＥ１００の制御部１３０は、ｅＮＢ２００から自ＵＥ１００に割り当てられた固有情報、又は自ＵＥ１００に予め設定されている固有情報に基づいて、フィードバック情報の送信に使用する上りリンク無線リソース（フィードバック用リソース）を共通リソースプールの中から選択してもよい。このような固有情報に基づくリソース選択を行うことにより、フィードバック用リソース内でのＵＥ間のフィードバック用リソースの衝突を回避することができる。
【００８３】
ここで、ｅＮＢ２００から自ＵＥ１００に割り当てられた固有情報とは、例えばセルＲＮＴＩ（Ｃ−ＲＮＴＩ）である。自ＵＥ１００に予め設定されている固有情報とは、ＩＭＳＩ（Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｍｏｂｉｌｅ  Ｓｕｂｓｃｒｉｂｅｒ  Ｉｄｅｎｔｉｔｙ）又はＳ−ＴＭＳＩ（ＳＡＥ  Ｔｅｍｐｏｒａｒｙ  Ｍｏｂｉｌｅ  Ｓｕｂｓｃｒｉｂｅｒ  Ｉｄｅｎｔｉｔｙ）である。ＩＭＳＩは、ＵＩＭカードに格納されている固有情報である。Ｓ−ＴＭＳＩは、ＵＥ１００がネットワークに位置登録を行う際にＭＭＥからＵＥ１００に割り当てられる固有情報である。例えば、ＵＥ１００の制御部１３０は、固有情報の一部で周波数リソース（ＲＢ）を選択し、当該固有情報の残りの部分で時間リソース及び信号系列（シーケンス）を選択する。或いは、「固有情報ｍｏｄフィードバックリソースプールのＲＥ数」といった計算式によりフィードバック用リソースを選択してもよい。
【００８４】
ｅＮＢ２００の制御部２３０は、複数のＵＥ１００からなるグループに対して、フィードバック情報の送信に使用可能な共通リソースプールを割り当てる。ｅＮＢ２００の送信部２１０は、同一の下りリンク無線リソースを使用して複数のＵＥ１００にマルチキャストデータを送信する。ｅＮＢ２００の受信部２２０は、共通リソースプールの中から選択された上りリンク無線リソースを使用して送信されるフィードバック情報を複数のＵＥ１００から受信する。上述したように、共通リソースプールは、自ｅＮＢ２００から各ＵＥ１００に個別に割り当てる物理上りリンク制御チャネル（ＰＵＣＣＨ）とは異なる上りリンク無線リソースからなる。
【００８５】
ｅＮＢ２００の送信部２１０は、共通リソースプールに関する設定情報を複数のＵＥ１００に送信する。上述したように、設定情報は、時間軸上における基準点と共通リソースプールの始点との間の差分、周波数軸上における基準点と共通リソースプールの始点との間の差分、時間軸上における共通リソースプールの範囲、周波数軸上における共通リソースプールの範囲、のうち少なくとも１つを含む。設定情報は、「ＯＮ／ＯＦＦパターン」、「周期」を含んでもよい。共通リソースプールに関する設定情報は、システム情報（ＳＩＢ）によりｅＮＢ２００からブロードキャスト伝送してもよい。設定情報は、個別のＲＲＣメッセージによりｅＮＢ２００からユニキャスト伝送してもよい。設定情報は、グループＲＮＴＩでＣＲＣをスクランブルされたＤＣＩで伝送してもよい。
【００８６】
図１３は、共通リソースプールに係る動作シーケンスの一例を示す図である。
【００８７】
図１３に示すように、ステップＳ２０１において、ｅＮＢ２００は、共通リソースプールに関する設定情報（共通リソースプール情報）をグループ内ＵＥ１００（ＵＥ１００−１、ＵＥ１００−２）に送信する。各ＵＥ１００は、共通リソースプール情報を受信して記憶する。
【００８８】
ステップＳ２０２において、ｅＮＢ２００は、ＳＣＰＴＭによるマルチキャスト伝送を開始する。
【００８９】
ステップＳ２０３において、ＵＥ１００（ＵＥ１００−１、ＵＥ１００−２）は、自ＵＥの固有情報に基づいて、自グループに割り当てられた共通リソースプールの中からフィードバック用リソースを選択する。
【００９０】
ステップＳ２０４において、ＵＥ１００（ＵＥ１００−１、ＵＥ１００−２）は、選択したフィードバック用リソースを使用して、フィードバック情報をｅＮＢ２００に送信する。
【００９１】
（ＮＡＣＫ−ｏｎｌｙ  ＨＡＲＱフィードバックに係る実施例）
以下において、ＮＡＣＫ−ｏｎｌｙ  ＨＡＲＱフィードバックに係る実施例について説明する。以下の実施例１乃至７は、別個独立に実施してもよいし、２以上の実施例を組み合わせて実施してもよい。
【００９２】
（１）実施例１
実施例１において、ＵＥ１００の受信部１１０は、ＭＢＭＳサービスに属するマルチキャストデータをｅＮＢ２００から受信する。ＵＥ１００の受信部１１０は、マルチキャストデータに対応するフィードバック情報をｅＮＢ２００に送信するために複数のＵＥ１００が共用する１又は複数の共通リソースプールを示す設定情報をｅＮＢ２００から受信する。設定情報は、フィードバック情報の属性と共通リソースプールとの対応関係を示す情報を含む。
【００９３】
フィードバック情報は、マルチキャストデータの受信に失敗したことを示すＮＡＣＫを含む。フィードバック情報の属性は、当該マルチキャストデータが属するＭＢＭＳサービスの識別情報（ＴＭＧＩ）であってもよい。
【００９４】
ＵＥ１００の制御部１３０は、ｅＮＢ２００に送信するフィードバック情報の属性に基づいて、フィードバック情報の送信に用いる特定の共通リソースプールを選択する。ＵＥ１００の送信部１２０は、特定の共通リソースプールを用いてフィードバック情報をｅＮＢ２００に送信する。
【００９５】
ｅＮＢ２００の送信部２１０は、ＭＢＭＳサービスに属するマルチキャストデータを送信する。ｅＮＢ２００の送信部２１０は、マルチキャストデータに対応するフィードバック情報をｅＮＢ２００に送信するために複数のＵＥ１００が共用する１又は複数の共通リソースプールを示す設定情報をＵＥ１００に送信する。ｅＮＢ２００の受信部２２０は、特定の共通リソースプールを用いてＵＥ１００から送信されたフィードバック情報を受信する。ｅＮＢ２００の制御部２３０は、特定の共通リソースプールに基づいて、ＵＥ１００から受信したフィードバック情報の属性を判断する。
【００９６】
図１４は、実施例１に係る動作シーケンスを示す図である。図１４の初期状態において、ＵＥ１００は、ＲＲＣアイドルモードであり、ＴＭＧＩ＃１のＭＢＭＳサービスの受信に興味を持っている。
【００９７】
図１４に示すように、ステップＳ１１において、ｅＮＢ２００は、ブロードキャストシグナリング又はマルチキャストシグナリングにより、複数の共通リソースプールを示す設定情報をＵＥ１００に送信する。ブロードキャストシグナリングは、ＳＩＢ２０であってもよい。マルチキャストシグナリングは、ＳＣ−ＭＣＣＨであってもよい。ＵＥ１００は、ｅＮＢ２００から設定情報を受信して記憶する。
【００９８】
設定情報は、共通リソースプールとＴＭＧＩとの対応関係を示す情報（マッピング情報）を含む。ＴＭＧＩは、ＭＢＭＳサービスを識別するサービス識別子を含む。一例として、共通リソースプール＃１とＴＭＧＩ＃１とが対応付けられており、共通リソースプール＃２とＴＭＧＩ＃２とが対応付けられている。
【００９９】
ステップＳ１２において、ｅＮＢ２００は、ＳＣ−ＭＴＣＨによりＴＭＧＩ＃１のマルチキャストデータを送信する。ＵＥ１００は、ｅＮＢ２００からＴＭＧＩ＃１のマルチキャストデータを受信する。
【０１００】
ステップＳ１３において、ＵＥ１００は、ＴＭＧＩ＃１のマルチキャストデータの復号エラーを検知し、ＴＭＧＩ＃１のマルチキャストデータの受信に失敗したと判断する。
【０１０１】
ステップＳ１４において、ＵＥ１００は、設定情報に基づいて、ＴＭＧＩ＃１に対応する共通リソースプール＃１を選択する。ＵＥ１００は、共通リソースプール＃１に含まれる無線リソースをさらに選択してもよい。
【０１０２】
ステップＳ１５において、ＵＥ１００は、共通リソースプール＃１に含まれる無線リソースを用いてＮＡＣＫをｅＮＢ２００に送信する。ｅＮＢ２００は、ＵＥ１００からＮＡＣＫを受信する。
【０１０３】
ステップＳ１６において、ｅＮＢ２００は、共通リソースプール＃１で受信したＮＡＣＫを、対応するＴＭＧＩ＃１に対するＮＡＣＫであると判断する。ｅＮＢ２００は、ＮＡＣＫに基づいて、ＴＭＧＩ＃１のマルチキャストデータの再送及び／又はＭＣＳ等の調整（すなわち、リンクアダプテーション）を行ってもよい。
【０１０４】
実施例１において、設定情報中のマッピング情報は、共通リソースプールとＴＭＧＩとＡＣＫ／ＮＡＣＫとの対応関係を示す情報であってもよい。ＮＡＣＫ用の共通リソースプールに加えて、ＡＣＫ用の共通リソースプールが割り当てられる。この場合、フィードバック情報の属性は、ＴＭＧＩに加えて、ＡＣＫ／ＮＡＣＫを含んでもよい。一例として、共通リソースプール＃１とＴＭＧＩ＃１とＮＡＣＫとが対応付けられており、共通リソースプール＃３とＴＭＧＩ＃１とＡＣＫとが対応付けられる。このような設定情報を受信したＵＥ１００は、ＴＭＧＩ＃１のマルチキャストデータの受信に成功したことに応じて共通リソースプール＃３を選択し、共通リソースプール＃３に含まれる無線リソースを用いてＡＣＫをｅＮＢ２００に送信する。ｅＮＢ２００は、共通リソースプール＃３で受信したＡＣＫを、対応するＴＭＧＩ＃１に対するＡＣＫであると判断する。
【０１０５】
図１５は、実施例１に係る共通リソースプールの一例を示す図である。図１５（ａ）に示す例において、共通リソースプール＃１乃至＃３が確保されている。共通リソースプール＃１乃至＃３は、ＴＭＧＩ＃１乃至＃３にそれぞれ対応して確保されている。共通リソースプール＃１乃至＃３は、ＮＡＣＫの送信に用いられる。図１５（ｂ）に示す例において、共通リソースプール＃４及び＃５が確保されている。共通リソースプール＃４及び＃５は、ＴＭＧＩ＃４に対応して確保されている。共通リソースプール＃４はＡＣＫの送信に用いられ、共通リソースプール＃５はＮＡＣＫの送信に用いられる。図１５に示す例において、図１４に示す設定情報（Ｓ１１）は、例えば、サブフレーム番号とＮＡＣＫｏｎｌｙフィードバックとの対応付け情報、サブフレーム番号とＴＭＧＩとの対応付け情報、サブフレーム内の時間区間・周波数区間とＴＭＧＩとの対応付け情報、及び／又はサブフレーム内の時間区間・周波数区間とＡＣＫ・ＮＡＣＫとの対応付け情報を含んでもよい。
【０１０６】
（２）実施例２
実施例１は共通リソースプールを用いてＴＭＧＩを識別する実施例であるが、実施例２は信号系列を用いてＴＭＧＩを識別する実施例である。実施例２について、実施例１との相違点を主として説明する。実施例２において、共通リソースプールは、物理ランダムアクセスチャネル（ＰＲＡＣＨ）用のリソースプールと同様なリソースプールであってもよい。信号系列は、ランダムアクセスプリアンブル系列であってもよい。
【０１０７】
実施例２において、ＵＥ１００の受信部１１０は、ＭＢＭＳサービスに属するマルチキャストデータをｅＮＢ２００から受信する。ＵＥ１００の受信部１１０は、マルチキャストデータに対応するフィードバック情報をｅＮＢ２００に送信するために複数のＵＥ１００が共用する信号系列を示す設定情報をｅＮＢ２００から受信する。設定情報は、フィードバック情報の属性と信号系列との対応関係を示す情報を含む。信号系列を示す情報は、ベース系列に適用するサイクリックシフトであってもよい。
【０１０８】
ＵＥ１００の制御部１３０は、ｅＮＢ２００に送信するフィードバック情報の属性に基づいて、フィードバック情報の送信に用いる特定の信号系列を選択する。ＵＥ１００の送信部１２０は、特定の信号系列を用いてフィードバック情報をｅＮＢ２００に送信する。
【０１０９】
ｅＮＢ２００の送信部２１０は、ＭＢＭＳサービスに属するマルチキャストデータを送信する。ｅＮＢ２００の送信部２１０は、マルチキャストデータに対応するフィードバック情報をｅＮＢ２００に送信するために複数のＵＥ１００が共用する１又は複数の信号系列を示す設定情報をＵＥ１００に送信する。ｅＮＢ２００の受信部２２０は、特定の信号系列を用いてＵＥ１００から送信されたフィードバック情報を受信する。ｅＮＢ２００の制御部２３０は、特定の信号系列に基づいて、ＵＥ１００から受信したフィードバック情報の属性を判断する。
【０１１０】
図１６は、実施例２に係る動作シーケンスを示す図である。図１６の初期状態において、ＵＥ１００は、ＲＲＣアイドルモードであり、ＴＭＧＩ＃１のＭＢＭＳサービスの受信に興味を持っている。
【０１１１】
図１６に示すように、ステップＳ２１において、ｅＮＢ２００は、ブロードキャストシグナリング又はマルチキャストシグナリングにより、複数の信号系列を示す設定情報をＵＥ１００に送信する。ブロードキャストシグナリングは、ＳＩＢ２０であってもよい。マルチキャストシグナリングは、ＳＣ−ＭＣＣＨであってもよい。ＵＥ１００は、ｅＮＢ２００から設定情報を受信して記憶する。
【０１１２】
設定情報は、共通リソースプールと信号系列とＴＭＧＩとの対応関係を示す情報（マッピング情報）を含む。ＴＭＧＩは、ＭＢＭＳサービスを識別するサービス識別子を含む。一例として、共通リソースプール＃１と信号系列＃１とＴＭＧＩ＃１とが対応付けられており、共通リソースプール＃１と信号系列＃２とＴＭＧＩ＃２とが対応付けられている。
【０１１３】
ステップＳ２２において、ｅＮＢ２００は、ＳＣ−ＭＴＣＨによりＴＭＧＩ＃１のマルチキャストデータを送信する。ＵＥ１００は、ｅＮＢ２００からＴＭＧＩ＃１のマルチキャストデータを受信する。
【０１１４】
ステップＳ２３において、ＵＥ１００は、ＴＭＧＩ＃１のマルチキャストデータの復号エラーを検知し、ＴＭＧＩ＃１のマルチキャストデータの受信に失敗したと判断する。
【０１１５】
ステップＳ２４において、ＵＥ１００は、設定情報に基づいて、ＴＭＧＩ＃１に対応する信号系列＃１を選択する。
【０１１６】
ステップＳ２５において、ＵＥ１００は、共通リソースプール＃１かつ信号系列＃１を用いてＮＡＣＫをｅＮＢ２００に送信する。ｅＮＢ２００は、ＵＥ１００からＮＡＣＫを受信する。
【０１１７】
ステップＳ２６において、ｅＮＢ２００は、信号系列＃１で受信したＮＡＣＫを、対応するＴＭＧＩ＃１に対するＮＡＣＫであると判断する。ｅＮＢ２００は、ＮＡＣＫに基づいて、ＴＭＧＩ＃１のマルチキャストデータの再送及び／又はＭＣＳ等の調整（すなわち、リンクアダプテーション）を行ってもよい。
【０１１８】
実施例２において、設定情報中のマッピング情報は、共通リソースプールと信号系列とＴＭＧＩとＡＣＫ／ＮＡＣＫとの対応関係を示す情報であってもよい。この場合、ＮＡＣＫ用の信号系列に加えて、ＡＣＫ用の信号系列が割り当てられる。一例として、信号系列＃１とＴＭＧＩ＃１とＮＡＣＫとが対応付けられており、信号系列＃３とＴＭＧＩ＃１とＡＣＫとが対応付けられる。このような設定情報を受信したＵＥ１００は、ＴＭＧＩ＃１のマルチキャストデータの受信に成功したことに応じて信号系列＃３を選択し、信号系列＃３を用いてＡＣＫをｅＮＢ２００に送信する。ｅＮＢ２００は、信号系列＃３のＡＣＫを、対応するＴＭＧＩ＃１に対するＡＣＫであると判断する。
【０１１９】
（３）実施例３
実施例３は、フィードバック情報（ＮＡＣＫ）の送信タイミングに関する実施例である。実施例３は、実施例１及び／又は実施例２と組み合わせて実施される。
【０１２０】
実施例３において、ＵＥ１００の制御部１３０は、マルチキャストデータの受信タイミングとフィードバック情報の送信タイミングとの間の時間オフセットを予め記憶する。言い換えると、時間オフセットはシステム仕様により事前定義されている。時間オフセットは、サブフレーム数により表現されてもよい。ＵＥ１００の送信部１２０は、時間オフセットに応じて定められる送信タイミングでフィードバック情報をｅＮＢ２００に送信する。ｅＮＢ２００は、フィードバック情報の受信タイミングに基づいて、どのマルチキャストデータに対するフィードバック情報であるか判断する。
【０１２１】
以下において、マルチキャストデータを受信したサブフレーム（ｎ）の４サブフレーム後のサブフレーム（ｎ＋４）でＮＡＣＫを送信するケースを主として説明する。ＵＥ１００は、ｅＮＢ２００から設定情報（共通リソースプール情報）が送信されていることに応じて、ＳＣ−ＰＴＭ送信サブフレームの４サブフレーム後はフィードバックリソースが用意されている（フィードバック可能）と判断してもよい。
【０１２２】
図１７は、実施例３に係る動作を示す図である。図１７に示すように、ｅＮＢ２００は、サブフレーム＃１乃至＃３のそれぞれにおいてマルチキャストデータ（トランスポートブロック）をＳＣ−ＭＴＣＨにより送信する。ＵＥ１００は、サブフレーム＃１のマルチキャストデータの受信に失敗し、サブフレーム＃２及び＃３のマルチキャストデータの受信に成功する。ＵＥ１００は、サブフレーム＃１の４サブフレーム後のサブフレーム＃５において、共通リソースプールに含まれる無線リソースを用いてＮＡＣＫをｅＮＢ２００に送信する。
【０１２３】
（４）実施例４
実施例４は、実施例３を改良し、フィードバック情報を削減可能とする実施例である。
【０１２４】
実施例４において、ＵＥ１００の受信部１１０は、所定期間内でマルチキャストデータを複数回受信する。ＵＥ１００の制御部１３０は、所定期間内で複数回受信したマルチキャストデータに対応する１つのフィードバック情報を生成する。ＵＥ１００の送信部１２０は、生成した１つのフィードバック情報をｅＮＢ２００に送信する。このように、ＵＥ１００は、ある一定期間の全ＳＣ−ＰＴＭ受信の成功可否によって、フィードバックを行う。
【０１２５】
図１８は、実施例４に係る動作を示す図である。図１８に示すように、複数のサブフレームからなる所定期間（Ｄｕｒａｔｉｏｎ）が設定される。所定期間は、ｅＮＢ２００からＵＥ１００に設定されてもよいし、システム仕様により事前定義されてもよい。所定期間は、開始サブフレーム、終了サブフレーム、持続時間（サブフレーム数）などにより表現されてもよい。ここでは、所定期間が４サブフレームからなる一例を説明する。以下において、ｅＮＢ２００からＵＥ１００に対する設定は、ブロードキャストシグナリング（例えばＳＩＢ）、マルチキャストシグナリング（例えばＳＣ−ＭＣＣＨ）、又は専用シグナリング（例えばＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ）により行われる。
【０１２６】
ＵＥ１００は、１つの所定期間内において、全ＳＣ−ＰＴＭ受信に成功した場合は、フィードバックを行わない、又はＡＣＫを送信する。これに対し、ＵＥ１００は、１つの所定期間内において、１回でもＳＣ−ＰＴＭ受信に失敗した場合は、フィードバックを行う（すなわち、ＮＡＣＫを送信する）。或いは、ＵＥ１００は、１つの所定期間内において、ある規定回数以上、ＳＣ−ＰＴＭ受信に失敗した場合に限り、フィードバックを行ってもよい。この場合、当該既定回数は、ｅＮＢ２００からＵＥ１００に設定されていてもよい。
【０１２７】
図１８の例において、ＵＥ１００は、所定期間に対応するサブフレーム＃１乃至＃４のそれぞれにおいてマルチキャストデータ（ＳＣ−ＭＴＣＨ）を受信する。ＵＥ１００は、サブフレーム＃１、＃２、及び＃４のマルチキャストデータの受信（復号）に失敗し、サブフレーム＃３のマルチキャストデータの受信（復号）に成功する。ＵＥ１００は、当該所定期間が終了するサブフレーム＃４から４サブフレーム後のサブフレーム＃８においてＮＡＣＫをｅＮＢ２００に送信する。但し、規定回数として２以上の回数が設定されている場合、ＵＥ１００は、フィードバックを行なわなくてもよい。
【０１２８】
また、ＵＥ１００は、次の所定期間に対応するサブフレーム＃５乃至＃８のそれぞれにおいてマルチキャストデータ（ＳＣ−ＭＴＣＨ）を受信する。ＵＥ１００は、サブフレーム＃５乃至＃８のマルチキャストデータの受信（復号）に成功する。この場合、ＵＥ１００は、フィードバックを行わない。或いは、ＵＥ１００は、当該次の所定期間が終了するサブフレーム＃８から４サブフレーム後のサブフレーム＃１２においてＡＣＫをｅＮＢ２００に送信してもよい。
【０１２９】
（５）実施例５
実施例５は、フィードバックを行うべきＵＥ１００の数を限定することにより、フィードバック情報を削減可能とする実施例である。
【０１３０】
実施例５において、ＵＥ１００の制御部１３０は、ｅＮＢ２００から受信する無線信号（例えば参照信号）の品質を測定する。品質は、参照信号受信電力（ＲＳＲＰ）、参照信号受信品質（ＲＳＲＱ）、又は参照信号ＳＩＮＲ（ＲＳ−ＳＩＮＲ）であってもよい。ＵＥ１００の制御部１３０は、品質を示す値が閾値以上であることに応じて、フィードバック情報（ＮＡＣＫ）の送信を無効化する。これに対し、ＵＥ１００の制御部１３０は、品質を示す値が閾値未満であることに応じて、フィードバック情報（ＮＡＣＫ）の送信を有効化する。閾値は、ｅＮＢ２００からＵＥ１００に設定されてもよい。
【０１３１】
ここで、品質を示す値は、品質の測定値であってもよいし、品質の測定値から導かれる値であってもよい。一例として、品質を示す値は、ＲＳＲＰに基づくＣＥ（Ｃｏｖｅｒａｇｅ  Ｅｎｈａｎｃｅｍｅｎｔ）レベルであてもよい。ＵＥ１００は、ＲＳＲＰと閾値との比較結果に応じて自身のＣＥレベルを決定する。閾値のリストがネットワークからＵＥ１００に通知され、各閾値は、ＣＥレベルと対応付けられていてもよい。或いは、品質を示す値は、ＣＥレベルに対応する繰り返し送信回数（Ｒｅｐｅｔｉｔｉｏｎ回数）であってもよい。
【０１３２】
（６）実施例６
実施例６は、ＮＡＣＫ−ｏｎｌｙ  ＨＡＲＱフィードバックを前提として、特定のＵＥ１００のみＡＣＫもフィードバックする実施例である。実施例６において、実施例５と重複する説明を省略する。
【０１３３】
実施例６において、ＵＥ１００の制御部１３０は、ｅＮＢ２００から受信する無線信号の品質を測定する。ＵＥ１００の制御部１３０は、品質を示す値が閾値以上であることに応じて、ＡＣＫの送信を無効化するとともに、ＮＡＣＫの送信を有効化する。これに対し、ＵＥ１００の制御部１３０は、品質を示す値が閾値未満であることに応じて、ＡＣＫの送信及びＮＡＣＫの送信の両方を有効化する。これにより、無線状態が悪いＵＥ１００について、ｅＮＢ２００は、ＡＣＫが返って来ない場合に、ＮＡＣＫと見なして再送を行うことができる。
【０１３４】
ＡＣＫもフィードバックする場合、ｅＮＢ２００は、ＡＣＫもフィードバックするＵＥ１００（例えば、ＲＳＲＰ閾値を下回るＵＥ１００であって、ＳＣ−ＰＴＭ受信に興味があるＵＥ１００）を把握していることが好ましい。ＡＣＫが返ってこなければＮＡＣＫと見なして再送するような実装があるが、この場合、本当にＡＣＫが返ってこなかったのか、単に該当するＵＥ１００が居なかっただけなのかが分からないからである。
【０１３５】
よって、実施例６において、ＵＥ１００の送信部１２０は、品質を示す値が閾値以上であるか否かを示す情報をｅＮＢ２００にさらに送信してもよい。ＵＥ１００の送信部１２０は、品質を示す値が閾値未満になった際にＡＣＫを送信することにより、品質を示す値が閾値未満になった旨を暗示的にｅＮＢ２００に通知してもよい。当該情報は、ＲＲＣシグナリング（又はＭＡＣ制御要素等）によりＵＥ１００からｅＮＢ２００に送信されてもよい。当該情報を送信するためのリソースプールがｅＮＢ２００からＵＥ１００に設定されてもよい。
【０１３６】
図１９は、実施例６に係る動作を示す図である。図１９において、ＡＣＫの送信を無効化するとともに、ＮＡＣＫの送信を有効化するモードを「ＮＡＣＫ−ｏｎｌｙフィードバックモード」と表記し、ＡＣＫの送信及びＮＡＣＫの送信の両方を有効化するモードを「ＡＣＫ・ＮＡＣＫフィードバックモード」と表記している。
【０１３７】
図１９に示すように、ＮＡＣＫ−ｏｎｌｙフィードバックモード（Ｓ３１）のＵＥ１００は、無線品質を測定（Ｓ３２）し、無線品質を示す値を閾値と比較（Ｓ３３）する。無線品質を示す値が閾値未満である場合（Ｓ３３：ＹＥＳ）、ＵＥ１００は、ＡＣＫ・ＮＡＣＫフィードバックモードに移行（ｅｎｔｅｒ）し、その旨の通知又はＡＣＫをｅＮＢ２００に送信する（Ｓ３４、Ｓ３５）。ｅＮＢ２００は、ｅｎｔｅｒｉｎｇしているＵＥ１００が１つでもあれば、ＡＣＫが返ってくる可能性があると仮定し、ＡＣＫのモニタ（及びこれを用いた再送判断）を行う。
【０１３８】
ＡＣＫ・ＮＡＣＫフィードバックモードに移行したＵＥ１００は、無線品質を測定（Ｓ３６）し、無線品質を示す値を閾値と比較（Ｓ３７）する。無線品質を示す値が閾値以上である場合（Ｓ３７：ＮＯ）、ＵＥ１００は、ＡＣＫ・ＮＡＣＫフィードバックモードから脱し（ｌｅａｖｅ）、その旨の通知をｅＮＢ２００に送信する（Ｓ３８）。Ｓ３７で用いる閾値は、Ｓ３３で用いる閾値と同じであってもよいし、ヒステリシスを持たせるように異なる閾値を用いてもよい。
【０１３９】
このような動作は、ＵＥ１００がｅＮＢ２００のセルから出る際の動作に流用することができる。ＵＥ１００は、他のセルにセル再選択を行う際にも、ｌｅａｖｉｎｇと同様の動作、すなわち、ｅＮＢ２００に対する通知を行ってもよい。当該通知は、ＵＥ１００を識別するための情報を含んでもよい。ＵＥ１００を識別するための情報は、ＩＭＳＩであってもよいし、所定の信号系列であってもよい。
【０１４０】
（７）実施例７
実施例７は、フィードバックが行われるべきＭＢＭＳサービスの数を限定することにより、フィードバック用リソースを節約可能とする実施例である。
【０１４１】
実施例７において、ＵＥ１００の受信部１１０は、フィードバック情報（ＮＡＣＫ）の送信が必要とされるＭＢＭＳサービスを示す所定情報をｅＮＢ２００からさらに受信する。所定情報は、フィードバック情報の送信が必要とされるＭＢＭＳサービスのＴＭＧＩであってもよい。或いは、ｅＮＢ２００がＴＭＧＩごとにフラグ又はリソース設定情報をＵＥ１００に通知することにより、フィードバック情報の送信が必要とされるＭＢＭＳサービスをＵＥ１００に示してもよい。また、当該フラグ又は当該リソース設定情報は、フィードバックの種類を指定してもよい。例えば、ＮＡＣＫ−ｏｎｌｙ  ＨＡＲＱフィードバックの要否、ＨＡＲＱフィードバック（ＡＣＫ及びＮＡＣＫ）の要否、その他上記実施例で記述したフィードバックの種類を示すフラグが通知される。もしくは、前記フィードバックの種類に応じたフィードバック情報（例えば、ＮＡＣＫ−ｏｎｌｙ  ＨＡＲＱフィードバック用のリソース設定）が通知される。ＵＥ１００の制御部１３０は、所定情報に基づいて、フィードバック情報の送信が必要とされるＭＢＭＳサービス（ＴＭＧＩ）を判断する。そして、ＵＥ１００の制御部１３０は、フィードバック情報の送信が必要とされるＭＢＭＳサービス（ＴＭＧＩ）についてのみフィードバックを行うように制御する。
【０１４２】
ｅＮＢ２００は、フィードバックに利用可能な無線リソースの上限に基づいて、フィードバックの対象とするＴＭＧＩ数を判断する。或いは、フィードバックリソースの上限又はＴＭＧＩの上限数がＯＡＭ（もしくはＣＮ）からｅＮＢ２００に通知されてもよく、ｅＮＢ２００は、当該上限値の範囲内でフィードバックリソース量を制御する。一例として、ｅＮＢ２００は、用意出来るフィードバックリソース数に対してＴＭＧＩ数が多い場合、どのＴＭＧＩに対してフィードバックを行うのかを判断する。ｅＮＢ２００は、ＣＥレベルが大きい（Ｒｅｐｅｔｉｔｉｏｎ回数が多い）ＵＥ１００が受信に興味を持っているＴＭＧＩをフィードバック対象としてもよい。或いは、興味のあるＵＥ１００数が多いＴＭＧＩをフィードバック対象としてもよい。
【０１４３】
（その他の実施形態）
上述した実施形態において、フィードバック情報がＡＣＫ／ＮＡＣＫであるケースを主として想定していた。しかしながら、フィードバック情報は、チャネル状態情報（ＣＳＩ）であってもよい。ＣＳＩは、ＣＱＩ（Ｃｈａｎｎｅｌ  Ｑｕａｌｉｔｙ  Ｉｎｄｉｃａｔｏｒ）であってもよい。ＣＳＩは、、ＰＭＩ（Ｐｒｅｃｏｄｅｒ  Ｍａｔｒｉｘ  Ｉｎｄｉｃａｔｏｒ）であってもよい。フィードバック情報は、通知情報であってもよい。通知情報は、ＳＣ−ＰＴＭに適用するＭＣＳの変更禁止をＵＥ１００が希望することを示す情報である。具体的には、ＵＥ１００は、ＭＣＳを上げて欲しくないことを示す通知情報をｅＮＢ２００に送信する。ＵＥ１００は、マルチキャストデータの受信品質が閾値未満であることをトリガとして、ＭＣＳを上げて欲しくないことを示す通知情報をｅＮＢ２００に送信してもよい。ｅＮＢ２００は、ＭＣＳを上げて欲しくないことを示す通知情報をＵＥ１００から受信した場合、ＭＣＳを上げないように制御する。一方、ｅＮＢ２００は、ＭＣＳを上げて欲しくないことを示す通知情報をＵＥ１００から受信しない場合には、ＭＣＳを上げるように制御してもよい。或いは、通知情報は、マルチキャストデータの受信品質が閾値未満であることを示す情報であってもよい。この場合、ＭＣＳを変更するか否かはｅＮＢ２００の判断に委ねられる。或いは、通知情報は、ＭＣＳの変更をＵＥ１００が希望することを示す情報であってもよい。例えば、ＵＥ１００は、マルチキャストデータの受信品質が閾値以上であることをトリガとして、ＭＣＳを上げたいことを示す通知情報をｅＮＢ２００に送信する。或いは、通知情報は、ＭＣＳの変更をＵＥ１００が許容することを示す情報であってもよい。或いは、通知情報は、マルチキャストデータの受信品質が閾値以上であることを示す情報であってもよい。この場合、ＭＣＳを変更するか否かはｅＮＢ２００の判断に委ねられる。
【０１４４】
上述した実施形態において、移動通信システムとしてＬＴＥシステムを例示した。しかしながら、本開示はＬＴＥシステムに限定されない。ＬＴＥシステム以外の移動通信システムに本開示を適用してもよい。
【０１４５】
（付記）
（１．はじめに）
ＳＣ−ＰＴＭの再送及びフィードバックの必要性が検討されたが、結論がない。
【０１４６】
本付記では、リンクアダプテーションのためのフィードバック方式と、再送とについて詳細を検討する。
【０１４７】
（２．検討）
（２．１．背景）
フィードバックとリンクアダプテーション／再送を用いたスペクトル効率のシミュレーション評価は、２００７年のｅＭＢＭＳディスカッションのために複数のベンダーによって行われた。「単一セル伝送についての異なるアプローチを比較すると、（グループ固有の）アダプテーションと再送の可能性を含むＰＴＭは常にＰＴＰよりも効率的であり、セル内に多数のユーザがある場合その利得は顕著（１００％より大きい）であり得る。アダプテーションと再送の可能性がない単一セルのＰＴＭは、低ユーザ密度ではＰＴＰに比べて大幅に効率が悪い。
【０１４８】
観察１：リンクアダプテーションと再送は、より良いスペクトル効率のために有益である。
【０１４９】
Ｒｅｌ−１３  ＳＣ−ＰＴＭの研究でも、同様の議論が行われ、ＲＡＮ２はＲＡＮ１から次の回答を受けた。「ＲＡＮ１は、ＳＣ−ＰＴＭを受信するすべてのＵＥによってＣＳＩおよびＨＡＲＱまたはＨＡＲＱのみのフィードバックが提供され、ＳＣ−ＰＴＭを受信するすべてのＵＥがＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態にある場合のみを考慮している。ＣＳＩ及び／又はＨＡＲＱ−ＡＣＫフィードバックは、考慮されるケースにおいて利得をもたらすことができる。」ＴＲは、「セルごとに２つ以上のＵＥにサービスを配信する必要がある場合、ＵＬフィードバック付きＳＣ−ＰＴＭはユニキャストよりも優れたスペクトル効率を提供する」などの顕著な結論をキャプチャした。しかし、試験段階では、「ＨＡＲＱおよび再送信によって提供される利得が、システムの複雑さの増加の価値があるかどうかは結論付けられていない」。
【０１５０】
Ｒｅｌ−１４  Ｖ２Ｘの研究では、ＴＲが「ＤＬマルチキャスト／ブロードキャストの場合、ＲＡＮ１は、ＨＡＲＱフィードバック、ＣＳＩフィードバックという機能拡張でパフォーマンスの向上を観察した」をキャプチャした。この研究で「ＵｕベースのＶ２ＸのソリューションであるＳＣ−ＰＴＭとＭＢＳＦＮのＨＡＲＱフィードバックと再送信をサポートすることが推奨され、必要な追加調査が行われた」と結論付けられた後、最終的にフォローアップ作業項目の範囲から除外された。
【０１５１】
観測２：Ｒｅｌ−１３／１４の研究では、ＵＬフィードバックは、スペクトル効率と容量の点で性能が向上していることを再確認したが、今後の検討の必要性が確認された。
【０１５２】
ＦｅＭＴＣ／ｅＮＢ−ＩｏＴについて議論は開始されたが、議論の問題は過去の問題、すなわち、ＦｅＭＴＣ／ｅＮＢ−ＩｏＴとレガシーＬＴＥの間の問題、または、ファームウェアなどのマルチキャスト型サービスと音声ストリーミングなどのブロードキャスト型サービスとの間の問題と少し異なる。Ｒｅｌ−１４のフィードバックと再送信を正当化するポイントは次のとおりである。
【０１５３】
ＵＥの電力消費にも影響を及ぼすＴＢＳの制限に起因し、ユニキャストによる再送の確率は、レガシーＬＴＥよりも１２．２倍高く、大幅に増加する。
【０１５４】
ＴＢＳの制限または不要なバッテリ消費を引き起こす上位層の再送によるファームウェア全体の再取得に起因し、ユニキャストを介した再送パケットサイズは、失敗したパケットよりもはるかに大きくなる。
【０１５５】
リンクアダプテーションのブラインド繰り返しまたは機会が多すぎると、システムのスペクトル効率が悪くなる。
【０１５６】
さらに、ＲＡＮ２は、「ＲＲＣ＿ＩＤＬＥモードでのマルチキャスト受信はＮＢ−ＩｏＴとＭＴＣの両方で必要である」と「ＲＲＣ＿ＣＯＮＮＥＣＴＥＤモードでのマルチキャスト受信はＮＢ−ＩｏＴでは必須ではなく、ＭＴＣでは更なる検討がある」、すなわち、ＲＲＣ  ＩＤＬＥのＵＥのみがＳＣ−ＰＴＭを受信すると仮定することを合意したため、次の問題が現れる。
【０１５７】
アプリケーションレベルの再送信に依存する場合、ＲＲＣ接続確立／再開の要求の多くは同時に／連続して発生する。
【０１５８】
また、再送信の前に、Ｕｕを介した対応シグナリングの送受信が必要である。
【０１５９】
観察３：ＵＥの電力消費は、非効率的な再送信、例えばアプリケーション層では低下する。
【０１６０】
ＵＥの電力消費、スペクトル効率およびＮＷ輻輳の観点から、Ｒｅｌ−１４マルチキャスト拡張のためのＡＳレイヤにおけるフィードバックおよび再送信の導入を除外する技術的理由はない。
【０１６１】
提案１：ＲＡＮ２は、マルチキャスト拡張として、ＡＳ層におけるＵＬフィードバックおよびＤＬ再送信を導入することを決定すべきである。
【０１６２】
（２．２．フィードバックスキーム）
（２．２．１．一般）
ＴＲで言及されたＵＬフィードバックは、ＣＳＩフィードバックとＨＡＲＱフィードバックの両方であった。スペクトル効率に関して、ＣＳＩフィードバックとＨＡＲＱフィードバックの両方で最良の性能が観測され、準最適性能はＣＳＩフィードバックのみかＨＡＲＱフィードバックのみによって達成される。シグナリングオーバヘッドを考慮すると、ＣＳＩとＨＡＲＱの両方によるフィードバックは好ましくない。さらに、ＨＡＲＱフィードバック（すなわち、１ビット）は、ＣＳＩフィードバックよりも効率的である（すなわち、ＣＱＩおよびオプションでＰＭＩ  ＋  ＰＴＩ  ＋  ＲＩの４ビット）。また、ＨＡＲＱフィードバックは、セクション２．１で説明したように、リンクアダプテーションだけでなく再送信にも使用され、ＨＡＲＱフィードバックはマルチキャスト拡張のために直接的なものである。
【０１６３】
提案２：ＲＡＮ２は、ＨＡＲＱフィードバックがＲｅｌ−１４  ＳＣ−ＰＴＭのリンクアダプテーションおよび／または再送に使用されると仮定すべきである。
【０１６４】
一方、ＳＣ−ＰＴＭのＨＡＲＱフィードバックの課題は、ＲＲＣ＿ＩＤＬＥモードでのマルチキャストの受信がＮＢ−ＩｏＴとＭＴＣの両方で要求されるという合意に基づいて、ＩＤＬＥ  ＵＥからのフィードバックをどのように容易にするかである。換言すれば、現在のＵＬフィードバックは、ＰＵＣＣＨまたはＰＵＳＣＨ内に提供され、ＲＲＣ  ＩＤＬＥのＵＥのための専用リソースは割り当てられない。
【０１６５】
観察４：専用リソースのないＩＤＬＥ  ＵＥからのＨＡＲＱフィードバックが対処される必要がある。
【０１６６】
また、いくつかの興味深い特徴が以下のように観察された。
【０１６７】
「マルチポイントツーポイント」フィードバック：複数のフィードバックは、単一のＤＬデータのための複数のＵＥから来る。例えば、ｍＭＴＣのような多数のＵＥの可能性を考慮すると、ＵＬシグナリングの数は｛（ＴＭＧＩの数）×（＃ｏｆＴＢの数）×（ＵＥの数）｝で増加する可能性があるため、問題がある。
【０１６８】
「匿名」フィードバック：サービングセルは、誰がフィードバックを送信するかを区別する必要がない場合がある。すなわち、再送を開始するために１つのＮＡＣＫと多くのＮＡＣＫとの間に違いがないので、フィードバックに関連付けられたＴＭＧＩおよびＴＢの知識だけでリンクアダプテーションおよび／または再送を決定することができる。
【０１６９】
観察５：ＨＡＲＱフィードバックの数は、ＳＣ−ＰＴＭを受信するＵＥの数とともに増加する。
【０１７０】
観察６：マルチキャストのためのＨＡＲＱフィードバックは、送信側ＵＥの識別を要求していない。
【０１７１】
（２．２．２．詳細）
マルチキャストのためのＨＡＲＱフィードバックのいくつかのオプションは、以下のようにＶ２Ｘ研究で特定される。
【０１７２】
ＤＬマルチキャスト／ブロードキャスト送信のためのＨＡＲＱフィードバックが導入される場合、少なくとも１つのセルにおいて、２つのオプションがＨＡＲＱフィードバックリソース割り当てのために特定される。
【０１７３】
・ＵＥ共通リソース：同一のＤＬマルチキャスト／ブロードキャスト送信を受信している複数のＵＥが、同じリソース上でＨＡＲＱフィードバックを送信する。
【０１７４】
・ＵＥ特有のリソース：同じＤＬマルチキャスト／ブロードキャスト送信を受信する異なるＵＥは、異なるリソース上でＨＡＲＱフィードバックを送信する。
【０１７５】
２．２．１セクションの観察の意味では、「ＵＥ共通リソース」の概念は、ＦｅＭＴＣ／ｅＮＢ−ＩｏＴマルチキャストのフィードバックのベースラインでなければならない。
【０１７６】
提案３：ＲＡＮ２は、マルチキャストのフィードバックのために複数のＵＥ間で共通のリソースが割り当てられていると仮定する。
【０１７７】
ＩＤＬＥ  ＵＥからの送信は新しい概念ではない。例えば、ＲＲＣ接続確立前のＰＲＡＣＨ送信はＲｅｌ−８から許可され、ＩＤＬＥにおけるサイドリンク送信はＲｅｌ−１２で規定され、初期アクセス中の異なるＰＲＡＣＨリソースを伴うＣＥレベル報告はＲｅｌ−１３で導入された。  したがって、フィードバックスキームは、可能な限り既存の概念／仕様を再利用する必要があります。例えば、共通リソースは、Ｒｅｌ−１３  ＣＥレベル報告、すなわちＰＲＡＣＨ−ＰａｒａｍｅｔｅｒｓＬｉｓｔＣＥ−ｒ１３、および／またはＲｅｌ−１２リソースプール、例えばｄｉｓｃＴｘＰｏｏｌＣｏｍｍｏｎ−ｒ１２の概念と類似し得る。
【０１７８】
観察７：ＵＥ共通リソースは、開始点として、ＣＥレベルごとのＲｅｌ−１３  ＰＲＡＣＨリソースまたはサイドリンクのＲｅｌ−１２リソースプールとして表現され得る。
【０１７９】
セクション２．２．１で説明したように、サービングセルは、誰がそれを送信するかを知る必要はないが、ＨＡＲＱフィードバックに関連するＴＭＧＩとＴＢ（トランスポートブロック）とを区別する必要がある。１つのアプローチは、今のような時間領域マッピングである。すなわち、ＨＡＲＱフィードバックは、サブフレームｎ＋４（すなわち、データ受信の４ｍｓ後）に送信される。ＴＢを区別するために再利用される。
【０１８０】
提案４：ＲＡＮ２は、今のように、各トランスポートブロック（またはＨＡＲＱプロセス）を区別するために、サブフレームｎ＋４においてＨＡＲＱフィードバックが送信されると考えるべきである。
【０１８１】
ＴＭＧＩとＨＡＲＱフィードバックとをどのように区別するかに関しては、以下の２つの選択肢があり得る。
【０１８２】
Ａｌｔ．１：異なる信号、例えば、ＰＲＡＣＨでは、異なるプリアンブルが異なるＴＭＧＩにマッピングされる。
【０１８３】
Ａｌｔ．２：異なる無線リソース、例えば、サイドリンクのリソースプールでは、異なるプールが異なるＴＭＧＩにマップされる。
【０１８４】
サポートされるＴＭＧＩの数は、利用可能なリソース、すなわちプリアンブルの数（Ａｌｔ．１）またはフィードバックにどれだけのリソースを提供できるかによって制限される場合がある。標準化の観点からは、Ａｌｔ．１はＲＡＮ１を巻き込む必要があり、Ａｌｔ．２はＲＡＮ２で決定され得る。
【０１８５】
提案５：ＲＡＮ２は、各ＴＭＧＩが異なる信号、例えばプリアンブル、またはフィードバックプールなどの異なる無線リソースによって区別されるかどうかについて議論すべきである。
【０１８６】
ユニキャストに対する既存のＨＡＲＱフィードバックは、ＡＣＫとＮＡＣＫとからなる。ＡＣＫ／ＮＡＣＫは、データ配信、正確なリンクアダプテーションなどを確実にするために有益である。ＡＣＫがほとんどの場合であり、多くのＵＥがＳＣ−ＰＴＭを受信することを考慮すると、ＨＡＲＱフィードバックの数は、観測５で論じられているように、大幅に増加する。
【０１８７】
このような大規模なフィードバックを避けるために、Ｒｅｌ−１３  ＳＣ−ＰＴＭの研究ではＮＡＣＫのみのフィードバックが示唆されている。この方法では、ＵＥは、ＳＣ−ＰＴＭを受信できなかった場合にのみ、ＨＡＲＱフィードバック、すなわち、ＮＡＣＫを送信する。言い換えれば、ＵＥは、ＳＣ−ＰＴＭが成功に受信されている間はフィードバックを送信しない。言うまでもなく、より少ないＵＬシグナリングはＵＥの電力消費を最小にする。
【０１８８】
提案６：ＲＡＮ２は、ＮＡＣＫのみのフィードバックがＨＡＲＱフィードバックの数を制限するのに有益であるかどうか議論すべきである。
【０１８９】
共通リソースを持つＮＡＣＫのみのＨＡＲＱフィードバックの例は、図２０に示される。
【０１９０】
（２．２．３．さらなる最適化（時間が許せば））
このセクションでは、ＨＡＲＱフィードバックのためのさらなる最適化のいくつかについて議論する。
【０１９１】
ＡＣＫフィードバックがＳＣ−ＰＴＭにとって依然として有益である場合、例えばユニキャストの場合のように配信を成功させるためには、フィードバックの数を最小限に抑える方法について検討する価値がある。可能性の１つとして、１つのフィードバック内に複数のＴＢに対する複数のフィードバックをバンドルすること、すなわちフィードバックバンドリングが考えられる。この最適化により、ＵＥは、すべてのＳＣ−ＰＴＭ送信が一定の持続時間内に成功に受信された場合、ＡＣＫを送信する。それ以外の場合（すなわち、１つのＳＣ−ＰＴＭのみが復号に失敗した場合でも）、ＮＡＣＫを送信する。あるいは、すべてのＵＥがＮＡＣＫを送信し続けている間に、「ＲＳＲＰ＜設定された閾値」のようなカバレッジの悪いＵＥのサブセットのみがＡＣＫを送信することは有益かつ効率的であり得る。この選択肢では、ｅＮＢは、過度のオーバーヘッドを回避するためにすべてのＵＥがＡＣＫを送信することを要求せずに、最も問題のあるＵＥのパケット配信を確実に成功させることができる。しかし、ＡＣＫフィードバックは、ＮＡＣＫのみのフィードバック、すなわち提案６と比較して、いくらかの複雑性を有する可能性がある。例えば、ユニキャストと同じレベルの制御を必要とすることがある。ユニキャストのフィードバックメカニズムと同じ原則に基づいている場合、ＡＣＫまたはＮＡＣＫフィードバックが受信されないときにｅＮＢが再送信を実行し得るので、少なくとも、ｅＮＢは、指定された劣悪なカバレッジ領域内（ＡＣＫが送られる領域）にＵＥが位置するかどうかを知る必要がある。
【０１９２】
別の最適化として、提案６においてＮＡＣＫのみのフィードバックが有益であると特定された場合、より良好なリンクアダプテーションのために追加のフィードバックの１つを考慮することができる。例えば、ＵＥは、現在のＭＣＳ／繰り返しを維持するようにサービングセルに要求するフィードバックを送信することができる。言い換えれば、ＵＥは、より高いＭＣＳ／より低い繰り返しでＳＣ−ＰＴＭを復号することができないと予想したときに、このような要求が送信される。ＮＡＣＫとこのフィードバックとの組み合わせにより、サービングセルは、不要な受信失敗（例えば再送）なしにスペクトル効率を最大にすることができる。
【０１９３】
提案７：ＲＡＮ２は、時間が許せば、ＨＡＲＱフィードバックのためにさらなる最適化が必要かどうかを検討すべきである。
【０１９４】
（２．３．リンクアダプテーションと再送）
リンクアダプテーションは、基本的にＮＷ実装であり、ＣＳＩフィードバックおよびＨＡＲＱフィードバックは、ユニキャストスケジューリングのためのアルゴリズムの入力として仮定される。マルチキャストスケジューリングの場合、複数のＵＥのチャネル状態がとにかく異なるため、ＣＳＩフィードバックなどのあまりにも正確な情報は、役に立たないかもしれない。すなわち、マルチキャスト送信が特定のチャネルに対して最適化されない可能性がある。一方で、ＰＤＣＣＨを用いた動的スケジューリングは、時間的に変化する「グループ」状態と合わせているため、依然として有益である。これは、「ＲＡＮ２は、ＳＣ−ＭＴＣＨがＰＤＣＣＨによってスケジューリングされる従来のＳＣ−ＭＴＣＨメカニズムが、ＮＢ−ＩｏＴおよびＭＴＣのマルチキャストに再利用され、柔軟なスケジューリングを実現すると想定している」との合意に整合している。
【０１９５】
再送に関しては、ＨＡＲＱフィードバックは不可欠かつ直接的な情報である。ＤＬにおける非同期再送を考慮すると、ＰＤＣＣＨを用いた動的スケジューリングは、そのようなスケジューリングのより良い取り扱いを提供する。また、ＰＤＣＣＨにおけるＮＤＩ（Ｎｅｗ  Ｄａｔａ  Ｉｎｄｉｃａｔｏｒ）は、ＵＥが既にそれを正常に復号するとき、すなわちＵＥが別のＵＥの再送信を受信する必要がないときに、ＳＣ−ＰＴＭの重複受信を回避する。
【０１９６】
観測８：ＳＣ−ＭＴＣＨの動的スケジューリング、すなわち、（Ｍ／Ｎ）を用いたＰＤＣＣＨは、ＳＣ−ＰＴＭに対してリンクアダプテーションおよび／または再送が仮定される場合に有益である。
【０１９７】
［相互参照］
米国仮出願第６２／３９７４５９号（２０１６年９月２１日出願）の全内容が、参照により、本願明細書に組み込まれている。
【産業上の利用可能性】
【０１９８】
本開示は移動通信分野において有用である。
【図１】
2018056108.tif 000003
【図２】
2018056108.tif 000004
【図３】
2018056108.tif 000005
【図４】
2018056108.tif 000006
【図５】
2018056108.tif 000007
【図６】
2018056108.tif 000008
【図７】
2018056108.tif 000009
【図８】
2018056108.tif 000010
【図９】
2018056108.tif 000011
【図１０】
2018056108.tif 000012
【図１１】
2018056108.tif 000013
【図１２】
2018056108.tif 000014
【図１３】
2018056108.tif 000015
【図１４】
2018056108.tif 000016
【図１５】
2018056108.tif 000017
【図１６】
2018056108.tif 000018
【図１７】
2018056108.tif 000019
【図１８】
2018056108.tif 000020
【図１９】
2018056108.tif 000021
【図２０】
2018056108.tif 000022
【国際調査報告】
2018056108.tif 000023
2018056108.tif 000024
2018056108.tif 000025
2018056108.tif 000026