(57)【要約】      （修正有）【課題】ライセンス支援型アクセス（ＬＡＡ）セルに関連して、即ち、未ライセンス周波数スペクトルにおいて動作するセルラー通信ネットワークのセルに関連して、メディアアクセス制御（ＭＡＣ）プロトコルの観点でワイヤレスデバイスの動作の方法を提供する。【解決手段】ワイヤレスデバイスの動作の方法は、未ライセンス周波数スペクトルにおいて動作するセル上で、アップリンク（ＵＬ）送信を、対応するＵＬハイブリッド自動再送要求（ＨＡＲＱ）プロセスについて送信することと、上記ＵＬ  ＨＡＲＱプロセスについてローカルで維持されるステータスを、上記ＵＬ送信が成功したという仮定に基づいて、確認応答（ＡＣＫ）に設定することと、を含む。【選択図】図１３
2019208229.tif 000002
【特許請求の範囲】
【請求項１】
ワイヤレスデバイス（１８）の動作の方法であって、
未ライセンス周波数スペクトルにおいて動作するセル（１６）上で、アップリンク送信を、対応するアップリンク（ＵＬ）ハイブリッド自動再送要求（ＨＡＲＱ）プロセスについて送信すること（１００）と、
前記ＵＬ  ＨＡＲＱプロセスについてローカルで維持されるステータスを、前記ＵＬ送信が成功したという仮定に基づいて、確認応答（ＡＣＫ）に設定すること（１０２）と、
を含む方法。
【請求項２】
切り替えられていないＮＤＩ（New  Data  Indicator）を伴う対応するＵＬグラントの受信に応じてのみ、前記ＵＬ  ＨＡＲＱプロセスについて再送を実行すること（１０４，１０６）、をさらに含む、請求項１の方法。
【請求項３】
ワイヤレスデバイス（１８）の動作の方法であって、
前記ワイヤレスデバイス（１８）が未ライセンス周波数スペクトルにおいて動作するセル（１６）上のサブフレームにおいて有効なアップリンク（ＵＬ）グラントを有するかを判定すること（２００）と、
前記ワイヤレスデバイス（１８）が前記セル（１６）上の前記サブフレームにおいて有効なＵＬグラントを有するとの判定に応じて、ＵＬハイブリッド自動再送要求（ＨＡＲＱ）フィードバックタイマを開始すること（２０２）と、
を含む方法。
【請求項４】
前記ワイヤレスデバイス（１８）が対応するＵＬ送信を実行する場合、又は前記対応するＵＬ送信がＬＢＴ（Listen-Before-Talk）方式によりブロックされる場合、の双方において前記ＵＬ  ＨＡＲＱフィードバックタイマを開始すること、を含む、請求項３の方法。
【請求項５】
前記ＵＬ  ＨＡＲＱフィードバックタイマの満了に応じて、不連続受信（ＤＲＸ）再送タイマを開始すること（２０６）、をさらに含む、請求項３又は請求項４の方法。
【請求項６】
前記ＤＲＸ再送タイマが稼動している限り、ＤＲＸアクティブ時間のままでいること（２０８）、をさらに含む、請求項５の方法。
【請求項７】
対応するＨＡＲＱバッファのフラッシュに応じて前記ＵＬ  ＨＡＲＱフィードバックタイマを停止すること、をさらに含む、請求項５又は請求項６の方法。
【請求項８】
ＵＬ  ＨＡＲＱプロセスごとに１つのＵＬ  ＨＡＲＱラウンドトリップ時間（ＲＴＴ）タイマ及び１つのＤＲＸ再送タイマが維持される、請求項３〜７のいずれかの方法。
【請求項９】
ワイヤレスデバイス（１８）の動作の方法であって、
未ライセンス周波数スペクトルにおいて動作するセル（１６）上でアップリンク制御情報（ＵＣＩ）を送信すること、
を含み、前記ＵＣＩは、
１つ以上のダウンリンク（ＤＬ）ＨＡＲＱプロセスについてのハイブリッド自動再送要求（ＨＡＲＱ）フィードバック情報と、
前記１つ以上のＤＬ  ＨＡＲＱプロセスを識別する識別子と、
を含む、方法。
【請求項１０】
前記１つ以上のＤＬ  ＨＡＲＱプロセスは、明示的な識別子により、又は各ビットが前
記１つ以上のＤＬ  ＨＡＲＱプロセスのうちの１つに対応するビットマップにより識別される、請求項９の方法。
【請求項１１】
前記セル（１６）へサービスする基地局（１２）から、フィードバック制御情報を受信すること、をさらに含み、前記フィードバック制御情報は、前記ＵＣＩ内の前記ＤＬ  ＨＡＲＱフィードバックのバンドリングが実行されるべきかの標識を含む、請求項９又は請求項１０の方法。
【請求項１２】
前記フィードバック制御情報は、前記ワイヤレスデバイス（１８）が前記ＵＣＩ内でバンドリングすべきＤＬ  ＨＡＲＱフィードバックの数を指し示す情報をさらに含む、請求項１１の方法。
【請求項１３】
プライマリサービングセル（１４）及びセカンダリサービングセル（１６）を有するネットワークにおけるワイヤレスデバイス（１８）の動作の方法であって、
前記プライマリサービングセル（１４）からのダウンリンク（ＤＬ）送信の受信（９００）への応答として、前記プライマリサービングセル（１４）へハイブリッド自動再送要求（ＨＡＲＱ）フィードバックを提供すること（９０２）と、
前記セカンダリサービングセル（１６）からのＤＬ送信の受信（９０４）への応答として、前記プライマリサービングセル（１４）の代わりに前記セカンダリサービングセル（１６）へ、前記ＨＡＲＱフィードバックを提供すること（９０６）と、
を含む方法。
【請求項１４】
ワイヤレスデバイス（１８）の動作の方法であって、
前記ワイヤレスデバイス（１８）が未ライセンス周波数スペクトルにおいて動作するセル（１６）上のサブフレームにおいて有効なアップリンク（ＵＬ）グラントを有するかを判定すること（４００）と、
前記ワイヤレスデバイス（１８）が有効なＵＬグラントを有するとの判定に応じて、仕掛かり中のハイブリッド自動再送要求（ＨＡＲＱ）フィードバックをＵＬ共有チャネルへ多重化すること（４０２）と、
前記ワイヤレスデバイス（１８）が有効なＵＬグラントを有しないとの判定に応じて、ショートＬＢＴ（Listen-Before-Talk）動作の成功した後に仕掛かり中のダウンリンク（ＤＬ）ＨＡＲＱフィードバックをＵＬ制御チャネル上で送信すること（５０２）と、
を含む方法。
【請求項１５】
前記アップリンク制御チャネルは、ロングアップリンク制御チャネルである、請求項１４の方法。
【請求項１６】
ワイヤレスデバイス（１８）の動作の方法であって、
前記ワイヤレスデバイス（１８）が先行するサブフレームにおいてＵＬ送信を実行し且つ前記ワイヤレスデバイス（１８）がアップリンク（ＵＬ）ＬＢＴ（Listen-Before-Talk）のスキップが許可されるという明示的な標識を受信した場合に、未ライセンス周波数スペクトルにおいて動作するセル（１６）上のサブフレームにおける前記ＵＬ送信の前に前記ＵＬ  ＬＢＴをスキップすること（６０２）、
を含む方法。
【請求項１７】
前記先行するサブフレームにおける前記ＵＬ送信は、物理アップリンク共有チャネル（ＰＵＳＣＨ）送信であった、請求項１６の方法。
【請求項１８】
前記先行するサブフレームにおける前記ＵＬ送信は、ロング物理アップリンク制御チャネル（ＰＵＣＣＨ）送信であった、請求項１６の方法。
【請求項１９】
ワイヤレスデバイス（１８）の動作の方法であって、
先行するサブフレームの末尾よりもむしろＵＬサブフレームの冒頭においてアップリンク（ＵＬ）ＬＢＴ（Listen-Before-Talk）動作を実行すること、
を含む方法。
【請求項２０】
ワイヤレスデバイス（１８）の動作の方法であって、
前記ワイヤレスデバイス（１８）が短縮ダウンリンク（ＤＬ）サブフレームの標識を受信した場合に、未ライセンス周波数スペクトルにおいて動作するセル（１６）上のショートアップリンク（ＵＬ）制御チャネル上で仕掛かり中のハイブリッド自動再送要求（ＨＡＲＱ）フィードバックを送信すること（７０４）、
を含む方法。
【請求項２１】
前記ワイヤレスデバイス（１８）は、前記ショートＵＬ制御チャネル上での前記仕掛かり中のＨＡＲＱフィードバックの送信に先立って、ＬＢＴ（Listen-Before-Talk）を実行することを必要としない、請求項２０の方法。
【請求項２２】
前記仕掛かり中のＨＡＲＱフィードバックを送信すべき前記ショートＵＬ制御チャネルのリソースを判定すること（７０２）、をさらに含む、請求項２０又は請求項２１の方法。
【請求項２３】
前記ワイヤレスデバイス（１２）は、無線リソース制御（ＲＲＣ）構成及びＤＬ割り当て内に含まれる情報に基づいて、前記ショートＵＬ制御チャネルのリソースを判定する、請求項２２の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
［関連出願］
本出願は、２０１５年１２月７日に提出された仮特許出願第６２／２６４，０７５号の利益を主張し、その開示はここで全体として参照によりここに取り入れられる。
【０００２】
［技術分野］
本開示は、アップリンクＭＡＣ（Medium  Access  Control）プロトコルの観点に関連し、即ち、共有アップリンク（ＵＬ）チャネル（例えば、物理アップリンク共有チャネル（ＰＵＳＣＨ））上でデータを送信するための機能性と共に、ＵＬ制御チャネル（例えば、物理アップリンク制御チャネル（ＰＵＣＣＨ））又は共有ＵＬチャネル（例えば、ＰＵＳＣＨ）上での、ハイブリッド自動再送要求（ＨＡＲＱ）確認応答／否定確認応答（ＡＣＫ／ＮＡＣＫ）フィードバック及びスケジューリング要求の送信に関連する。
【背景技術】
【０００３】
ライセンス支援型アクセス（ＬＡＡ：Licensed  Assisted  Access）は、３ＧＰＰ（Third  Generation  Partnership  Project）ＬＴＥ（Long  Term  Evolution）機器が未ライセンスの５ギガヘルツ（ＧＨｚ）無線スペクトルにおいても動作することを促進する。未ライセンスの５ＧＨｚスペクトルは、ライセンス済みスペクトルを補うものとして使用される。デバイスは、ライセンス済みスペクトルにおいて（プライマリセル（ＰＣｅｌｌ）を用いて）接続を行い、及び、未ライセンススペクトルにおいて（セカンダリセル（ＳＣｅｌｌ）を用いて）追加的な送信キャパシティの恩恵を受けるためにキャリアアグリゲーション（ＣＡ）を使用することができる。ライセンス済みスペクトル及び未ライセンススペクトルを統合することに関わる変更を低減するために、ＰＣｅｌｌにおけるＬＴＥフ
レームタイミングがＳＣｅｌｌにおいて同時に使用される。
【０００４】
しかしながら、規制要件（regulatory  requirements）が、事前のチャネルセンシング無く未ライセンススペクトルにおいて送信を行うことを許可しないかもしれない。未ライセンススペクトルは類似の又は非類似のワイヤレス技術の他の無線機と共有されなければならないことから、いわゆるＬＢＴ（listen-before-talk）手続が適用される必要がある。今日、未ライセンスの５ＧＨｚスペクトルは、ＩＥＥＥ（Institute  of  Electrical  and  Electronics  Engineers）８０２．１１  ＷＬＡＮ（Wireless  Local  Area  Network）標準を実装する機器により主として使用されている。この標準は、そのマーケティングブランド“Ｗｉ−Ｆｉ”の下で知られている。多くの領域において、未ライセンススペクトルにおける単一の送信バーストの最大時間長に関する（４ミリ秒（ｍｓ）又は１０ｍｓといった）制約もまた存在する。
【０００５】
１．  ＬＴＥ
図１Ａは、基本的なＬＴＥダウンリンク物理リソースグリッドを示している。ＬＴＥは、ダウンリンクにおいてＯＦＤＭ（Orthogonal  Frequency  Division  Multiplex）を、アップリンク（ＵＬ）においてシングルキャリアＦＤＭＡ（Frequency  Division  Multiple  Access）ともいうＤＦＴ（Discrete  Fourier  Transform）拡散ＯＦＤＭ（DFT-spread  OFDM）を使用する。よって、基本的なＬＴＥのダウンリンク物理リソースを図１Ａに示したような時間−周波数グリッドとして理解することができ、各リソースエレメントは、１つのＯＦＤＭシンボルインターバルの期間中の１本のＯＦＤＭサブキャリアに相当する。各シンボルの時間長は、約７１．４マイクロ秒（μｓ）である。ＵＬサブフレームは、ダウンリンク（ＤＬ）と同じサブキャリア間隔を有し、ＤＬにおけるＯＦＤＭシンボルと同じ数のＳＣ−ＦＤＭＡ（Single  Carrier  FDMA）シンボルを時間ドメインにおいて有する。
【０００６】
図１Ｂは、ＬＴＥ無線フレームを示している。時間ドメインにおいて、ＬＴＥのＤＬ送信は、１０ｍｓの無線フレームの集合へ編成され、各無線フレームは、図１Ｂに示したように、長さＴSUBFRAME＝１ｍｓで等サイズの１０個のサブフレームからなる。通常のサイクリックプレフィクスについて、１つのサブフレームは、１４個のＯＦＤＭシンボルからなる。サブフレームは、２つの０．５ｍｓスロットへ分割される。通常のサイクリックプレフィクスについて、各スロットは、７個のＯＦＤＭシンボルからなる。そのうえ、ＬＴＥにおけるリソース割り当ては、典型的にはリソースブロック（ＲＢ）の観点で記述され、１リソースブロックは、時間ドメインにおける１つの０．５ｍｓスロット及び周波数ドメインにおける１２本の連続したサブキャリアに相当する。時間方向における２つの隣り合うリソースブロックのペア（１．０ｍｓ）は、リソースブロックペアとして知られている。リソースブロックは、周波数ドメインにおいて、システム帯域幅の一端から０で始まる形で付番される。
【０００７】
図１Ｃは、制御信号及びリファレンス信号の位置を示す、一例としてのＬＴＥの（１４個のＯＦＤＭシンボルを伴う）１．０ｍｓサブフレームを示している。ＤＬ送信は動的にスケジューリングされ、即ち、各サブフレームにおいて、基地局は、その時点のＤＬサブフレームにおいてどの端末がデータの送信先であり及びどのリソースブロック上でデータが送信されるかに関する制御情報を送信する。この制御シグナリングは、典型的には、各サブフレーム内の最初から１、２、３又は４個のＯＦＤＭシンボルにおいて送信され、数ｎ＝１、２、３又は４は制御フォーマットインジケータ（ＣＦＩ）として知られている。ＤＬサブフレームは、共通リファレンスシンボルをも含み、共通リファレンスシンボルは、受信機にとって既知であって、例えば制御情報のコヒーレント復調のために使用される。制御としてＣＦＩ＝３個のＯＦＤＭシンボルを伴うＤＬシステムが図１Ｃに示されている。
【０００８】
ＬＴＥリリース１１（Ｒｅｌ−１１）以降より、上述したリソース割り当ては、拡張物理ダウンリンク制御チャネル（ＥＰＤＣＣＨ）上でもスケジューリングされ得る。Ｒｅｌ−８からＲｅｌ−１０については、物理ダウンリンク制御チャネル（ＰＤＣＣＨ）のみが利用可能である。図１Ｃに示したリファレンスシンボルは、セル固有リファレンスシンボル（ＣＲＳ）であり、精細な時間及び周波数同期並びに何らかの送信モードについてのチャネル推定を含む複数の機能をサポートするために使用される。
【０００９】
１．１  ＰＤＣＣＨ及びＥＰＤＣＣＨ
ＰＤＣＣＨ／ＥＰＤＣＣＨは、スケジューリング決定及び電力制御コマンドなどのダウンリンク制御情報（ＤＣＩ）を搬送する。より具体的には、ＤＣＩは、次を含む：
・ダウンリンクスケジューリング割り当て  …  物理ダウンリンク共有チャネル（ＰＤＳＣＨ）リソース標識、トランスポートフォーマット、ハイブリッド自動再送要求（ＨＡＲＱ）情報、及び（該当する場合）空間多重化に関連する制御情報を含む。ＤＬスケジューリング割り当ては、ＤＬスケジューリング割り当てへの応答としてＨＡＲＱ確認応答の送信のために使用される物理アップリンク制御チャネル（ＰＵＣＣＨ）の電力制御のためのコマンドをも含む。
・アップリンクスケジューリンググラント  …  物理アップリンク共有チャネル（ＰＵＳＣＨ）リソース標識、トランスポートフォーマット、及びＨＡＲＱ関連情報を含む。アップリンクスケジューリンググラントは、ＰＵＳＣＨの電力制御のためのコマンドをも含む。
・スケジューリング割り当て／グラントに含まれるコマンドを補うものとして、端末のセットのための電力制御コマンド。
【００１０】
１つのＰＤＣＣＨ／ＥＰＤＣＣＨは、上で列挙した情報のグループのうちの１つを含む１つのＤＣＩメッセージを搬送する。複数の端末を同時にスケジューリングすることができ、各端末はＤＬ及びＵＬの双方で同時にスケジューリングされ得ることから、各サブフレーム内で複数のスケジューリングメッセージが送信される可能性があることは間違いない。各スケジューリングメッセージは、別々のＰＤＣＣＨ／ＥＰＤＣＣＨリソース上で送信され、結果として、典型的には、各セル内の各サブフレームの範囲内に複数の同時のＰＤＣＣＨ／ＥＰＤＣＣＨ送信が存在する。さらに、様々な無線チャネル条件をサポートするためにリンク適応を使用することができ、リンク適応では、無線チャネル条件に適合するように（Ｅ）ＰＤＣＣＨ用のリソース使用量を適応させることにより（Ｅ）ＰＤＣＣＨのコードレートが選択される。
【００１１】
１．２  ＣＡ
図２は、ＣＡの一例を示している。ＬＴＥ  Ｒｅｌ−１０標準は、２０メガヘルツ（ＭＨｚ）よりも大きな帯域幅をサポートする。ＬＴＥ  Ｒｅｌ−１０の１つの重要な観点は、ＬＴＥ  Ｒｅｌ−８との後方互換性を確保することである。これは、スペクトル互換性を含むべきである。そのことは、２０ＭＨｚよりも広いＬＴＥ  Ｒｅｌ−１０キャリアが、ＬＴＥ  Ｒｅｌ−８端末にとって複数個のＬＴＥキャリアとして見えるべきであることを示唆するであろう。そうした各キャリアは、コンポーネントキャリア（ＣＣ）として言及され得る。特に、早期のＬＴＥ  Ｒｅｌ−１０配備について、ＬＴＥ  Ｒｅｌ−１０対応端末の数は、多くのＬＴＥレガシー端末と比較してより少ないであろうと予期することができる。従って、レガシー端末についても、広いキャリアの効率的な使用を保証することが必要とされ、即ち、レガシー端末を広帯域ＬＴＥ  Ｒｅｌ−１０キャリアの全ての部分においてスケジューリングし得るようなキャリアを実装可能であることが必要とされる。これを獲得するための単純な手法は、ＣＡの手段によるはずである。ＣＡは、ＬＴＥ  Ｒｅｌ−１０端末が、Ｒｅｌ−８キャリアと同じ構造を有するか又は少なくともその可能性を有する複数のＣＣを受信できることを示唆する。図２にＣＡが示されている。ＣＡ対
応型のユーザ機器デバイス（ＵＥ）には、常にアクティブ化されているＰＣｅｌｌと、動的にアクティブ化され又は非アクティブ化され得る１つ以上のＳＣｅｌｌとが割り当てられる。
【００１２】
統合されるコンポーネントキャリアの数と共に個々のＣＣの帯域幅は、ＵＬとＤＬとで異なってよい。対称構成とは、ＤＬにおけるＣＣの数がＵＬにおけるＣＣの数と同一である構成をいう。一方、非対称構成とは、ＣＣの数が異なるケースをいう。セル内で構成されるＣＣの数は、端末に見えるＣＣの数とは異なってもよいことに留意することが重要である。例えば、セルが同数のＵＬ  ＣＣ及びＤＬ  ＣＣで構成される場合でさえも、端末は、ＵＬ  ＣＣよりも多くのＤＬ  ＣＣをサポートしてよい。
【００１３】
加えて、ＣＡの重要な特徴は、クロスキャリアスケジューリングを実行する能力である。その仕組みは、１つのＣＣ上の（Ｅ）ＰＤＣＣＨが、（Ｅ）ＰＤＣＣＨメッセージの冒頭に挿入される３ビットのＣＩＦ（Carrier  Indicator  Field）の手段により他のＣＣ上のデータ送信をスケジューリングすることを可能にする。所与のＣＣ上のデータ送信のために、ＵＥは、ただ１つのＣＣ（即ち、同じＣＣであるか又はクロスキャリアスケジューリングを介して異なるＣＣであるかのいずれか）の（Ｅ）ＰＤＣＣＨ上のスケジューリングメッセージを受信することを予期する。（Ｅ）ＰＤＣＣＨからＰＤＳＣＨへの上記マッピングが準静的に構成されてもよい。なお、Ｒｅｌ−１１ではＰＤＳＣＨのクロスサブフレームでのクロスキャリアスケジューリングはサポートされておらず、即ち、具体的なサブフレームでの（Ｅ）ＰＤＣＣＨグラントは、その同一の送信時間インターバル（ＴＴＩ）内のＰＤＳＣＨ割り当てに適用される。
【００１４】
２．  ＷＬＡＮ
図３は、ＬＢＴの仕組みの概略図である。ＷＬＡＮの典型的な配備では、メディアアクセスのためにＣＳＭＡ／ＣＡ（Carrier  Sense  Multiple  Access  with  Collision  Avoidance）が使用される。チャネルはＣＣＡ（Clear  Channel  Assessment）を実行するためにセンシングされ、チャネルがアイドルであると宣言される場合にのみ送信が開始される。チャネルがビジーであると宣言される場合には、送信はチャネルがアイドルであると見なされるまで本質的に延期される。同じ周波数を用いる複数のアクセスポイント（ＡＰ）のレンジが重複する場合、レンジ内の他のＡＰとの間の同じ周波数上での送信が検出され得るケースにおいて１つのＡＰに関連する複数の送信が延期されるかもしれない。複数のＡＰが互いにレンジ内にある場合、それらはチャネルを時間的に共用しなければならなくなり、個々のＡＰについてのスループットはひどく劣化し得る。
【００１５】
３．  ＬＴＥを用いた未ライセンススペクトルへのＬＡＡ
これまでのところ、ＬＴＥにより使用されるスペクトルは、ＬＴＥにとって専用（即ち、ラインセンス済みスペクトル）である。これは、ＬＴＥシステムが共存の課題に対処することを必要とせず、スペクトル効率を最大化することができるという利点を有する。しかしながら、ＬＴＥに割り当てられたスペクトルは有限であり、そのため、アプリケーション／サービスからのより大きなスループットを求める需要の一層の増加を満たすことができない。従って、３ＧＰＰにおいて、ライセンス済みスペクトルに加えて未ライセンススペクトルを活用するようにＬＴＥを拡張することに関する新たな研究項目が開始された。定義によると、未ライセンススペクトルを、複数の異なる技術によって同時に使用することができる。従って、ＬＴＥは、ＩＥＥＥ８０２．１１（Ｗｉ−Ｆｉ）といった他のシステムとの共存の課題を考慮する必要がある。ライセンス済みスペクトル内と同じやり方で未ライセンススペクトルにおいてＬＴＥを動作させることは、Ｗｉ−Ｆｉの性能を深刻に劣化させかねない。なぜなら、Ｗｉ−Ｆｉは、チャネルが占有されていることを一旦検出すると送信を行わないことになるためである。
【００１６】
そのうえ、未ライセンススペクトルを高い信頼性で利用する１つの手法は、ライセンス済みキャリア上で不可欠な制御信号及びチャネルを送信することである。即ち、ＵＥは、ライセンス済み帯域内のＰＣｅｌｌ及び未ライセンス帯域内の１つ以上のＳＣｅｌｌへ接続される。ここで使用されるところによれば、未ライセンススペクトル内のＳＣｅｌｌは、ＬＡＡ  ＳＣｅｌｌとして表記される。クロスキャリアスケジューリングのケースでは、ＬＡＡ  ＳＣｅｌｌについてのＰＤＳＣＨ及びＰＵＳＣＨグラントは、ＰＣｅｌｌ上で送信される。
【００１７】
未ライセンススペクトルを利用する他の手法は、スタンドアローンＬＡＡセルを利用することである。
【発明の概要】
【００１８】
本開示は、アップリンクＭＡＣ（Medium  Access  Control）プロトコルの観点に関連し、即ち、共有アップリンク（ＵＬ）チャネル（例えば、物理アップリンク共有チャネル（ＰＵＳＣＨ））上でデータを送信するための機能性と共に、ＵＬ制御チャネル（例えば、物理アップリンク制御チャネル（ＰＵＣＣＨ））又は共有ＵＬチャネル（例えば、ＰＵＳＣＨ）上での、ハイブリッド自動再送要求（ＨＡＲＱ）確認応答／否定確認応答（ＡＣＫ／ＮＡＣＫ）フィードバック及びスケジューリング要求の送信に関連する。特に、ライセンス支援型アクセス（ＬＡＡ）セルに関連して、より一般的に言うと未ライセンス周波数スペクトルにおいて動作するセルラー通信ネットワークのセルに関連して、ＭＡＣプロトコルの観点がここで開示される。
【００１９】
ある観点によれば、ワイヤレスデバイスの動作の方法は、未ライセンス周波数スペクトルにおいて動作するセル上で、ＵＬ送信を、対応するＵＬ  ＨＡＲＱプロセスについて送信することと、上記ＵＬ  ＨＡＲＱプロセスについてローカルで維持されるステータスを、上記ＵＬ送信が成功したという仮定に基づいて、“ＡＣＫ”に設定することと、を含む。１つの実施形態において、上記方法は、切り替えられていないＮＤＩ（New  Data  Indicator）を伴う対応するＵＬグラントの受信に応じてのみ、上記アップリンクＨＡＲＱプロセスについて再送を実行すること、をさらに含む
【００２０】
他の観点によれば、ワイヤレスデバイスの動作の方法は、上記ワイヤレスデバイスが未ライセンス周波数スペクトルにおいて動作するセル上のサブフレームにおいて有効なＵＬグラントを有するかを判定することと、上記ワイヤレスデバイスが上記セル上の上記サブフレームにおいて有効なＵＬグラントを有するとの判定に応じて、ＵＬ  ＨＡＲＱフィードバックタイマを開始することと、を含む。ある実施形態において、上記ワイヤレスデバイスが対応するＵＬ送信を実行するか、又は上記対応するＵＬ送信がＬＢＴ（Listen-Before-Talk）方式によりブロックされるかによって、上記ＵＬ  ＨＡＲＱフィードバックタイマが開始される。ある実施形態において、上記方法は、上記ＵＬ  ＨＡＲＱフィードバックタイマの満了に応じて、不連続受信（ＤＲＸ）再送タイマを開始すること、をさらに含む。ある実施形態において、上記方法は、上記ＤＲＸ再送タイマが稼動している限り、ＤＲＸアクティブ時間のままでいること、をさらに含む。ある実施形態において、上記方法は、対応するＨＡＲＱバッファのフラッシュ（flushing）に応じて上記ＵＬ  ＨＡＲＱフィードバックタイマを停止すること、をさらに含む。ある実施形態において、ＵＬ  ＨＡＲＱプロセスごとに１つのアップリンクＨＡＲＱラウンドトリップ時間（ＲＴＴ）タイマ及び１つのＤＲＸ再送タイマが維持される。
【００２１】
他の観点によれば、ワイヤレスデバイスの動作の方法は、未ライセンス周波数スペクトルにおいて動作するセル上でアップリンク制御情報（ＵＣＩ）を送信すること、を含み、上記ＵＣＩは、１つ以上のダウンリンク（ＤＬ）ＨＡＲＱプロセスについてのＨＡＲＱフィードバック情報と、上記１つ以上のＤＬ  ＨＡＲＱプロセスを識別する識別子と、を含
む。ある実施形態において、上記１つ以上のＤＬ  ＨＡＲＱプロセスは、明示的な識別子により、又は各ビットが上記１つ以上のＤＬ  ＨＡＲＱプロセスのうちの１つに対応するビットマップにより識別される。ある実施形態において、上記方法は、上記セルへサービスする基地局から、フィードバック制御情報を受信すること、をさらに含み、上記フィードバック制御情報は、ＵＣＩ内の上記ＤＬ  ＨＡＲＱフィードバックのバンドリングが実行されるべきかの標識を含む。ある実施形態において、上記フィードバック制御情報は、上記ワイヤレスデバイスがＵＣＩ内でバンドリングすべきＤＬ  ＨＡＲＱフィードバックの数を指し示す情報をさらに含む。
【００２２】
他の観点によれば、プライマリサービングセル及びセカンダリサービングセルを有するネットワークにおけるワイヤレスデバイスの動作の方法は、プライマリサービングセルからのＤＬ送信の受信への応答として、上記プライマリサービングセルへＨＡＲＱフィードバックを提供することと、セカンダリサービングセルからのＤＬ送信の受信への応答として、上記プライマリサービングセルの代わりに上記セカンダリサービングセルへ、ＨＡＲＱフィードバックを提供することと、を含む。いくつかの実施形態において、各ＵＬサービングセルは、対応するＤＬサービングセルについてのＨＡＲＱフィードバックを搬送する。
【００２３】
他の観点によれば、ワイヤレスデバイスの動作の方法は、上記ワイヤレスデバイスが未ライセンス周波数スペクトルにおいて動作するセル上のサブフレームにおいて有効なＵＬグラントを有するかを判定することと、上記ワイヤレスデバイスが有効なＵＬグラントを有するとの判定に応じて、仕掛かり中のＨＡＲＱフィードバックをＵＬ共有チャネルへ多重化することと、上記ワイヤレスデバイスが有効なＵＬグラントを有しないとの判定に応じて、ショートＬＢＴ動作の成功した後に仕掛かり中のＤＬ  ＨＡＲＱフィードバックをＵＬ制御チャネル上で送信することと、を含む。ある実施形態において、上記ＵＬ制御チャネルは、ロングＵＬ制御チャネルである。
【００２４】
他の観点によれば、ワイヤレスデバイスの動作の方法は、上記ワイヤレスデバイスが先行するサブフレームにおいてＵＬ送信を実行し且つ上記ワイヤレスデバイスがＵＬ  ＬＢＴのスキップが許可されるという明示的な標識を受信した場合に、未ライセンス周波数スペクトルにおいて動作するセル上のサブフレームにおけるＵＬ送信の前にＵＬ  ＬＢＴをスキップすること、を含む。ある実施形態において、上記先行するサブフレームにおける上記ＵＬ送信は、ＰＵＳＣＨ送信であった。ある実施形態において、上記先行するサブフレームにおける上記ＵＬ送信は、ロングＰＵＣＣＨ送信であった。
【００２５】
他の観点によれば、ワイヤレスデバイスの動作の方法は、先行するサブフレームの末尾よりもむしろＵＬサブフレームの冒頭においてＵＬ  ＬＢＴ動作を実行すること、を含む。
【００２６】
他の観点によれば、ワイヤレスデバイスの動作の方法は、上記ワイヤレスデバイスが短縮ＤＬサブフレームの標識を受信した場合に、未ライセンス周波数スペクトルにおいて動作するセル上のショートＵＬ制御チャネル上で仕掛かり中のハイブリッドＨＡＲＱフィードバックを送信すること、を含む。ある実施形態において、上記ワイヤレスデバイスは、上記ショートＵＬ制御チャネル上での上記仕掛かり中のＨＡＲＱフィードバックの送信に先立って、ＬＢＴを実行することを必要としない。ある実施形態において、上記仕掛かり中のＨＡＲＱフィードバックを送信すべきショートＵＬ制御チャネルのリソースを判定すること、をさらに含む。ある実施形態において、上記ワイヤレスデバイスは、無線リソース制御（ＲＲＣ）構成及びＤＬ割り当て内に含まれる情報に基づいて、上記ショートＵＬ制御チャネルのリソースを判定する。
【００２７】
当業者は、添付図面の図との関連において上記実施形態の以下の詳細な説明を読んだ後に、本開示のスコープを認識し及びその追加的な観点を理解するであろう。
【００２８】
当業者は、添付図面の図との関連において上記実施形態の以下の詳細な説明を読んだ後に、本開示のスコープを認識し及びその追加的な観点を理解するであろう。
【図面の簡単な説明】
【００２９】
本明細書に取り入れられ及び本明細書の一部をなす添付図面の図は、本開示の複数の観点を例示しており、その説明と併せて本開示の原理の説明に供される。
【００３０】
【図１Ａ】ＬＴＥ（Long  Term  Evolution）により使用される旧来の一例としてのＯＦＤＭ（Orthogonal  Frequency  Division  Multiplexing）ダウンリンク（ＤＬ）物理リソースグリッドを示している。
【図１Ｂ】ＯＦＤＭ時間ドメイン構造を示す、旧来のＬＴＥの無線フレームの例示である。
【図１Ｃ】制御信号及びリファレンス信号の位置を示す、ＬＴＥの一例としての（１４個のＯＦＤＭシンボルを伴う）１．０ｍｓのＯＦＤＭ  ＤＬサブフレームの例示である。
【図２】キャリアアグリゲーション（ＣＡ）の一例の概略図である。
【図３】ＬＢＴ（Listen-Before-Talk）方式を示す概略図である。
【図４Ａ】ここで開示される主題のいくつかの実施形態に係る例示的なショート物理アップリンク制御チャネル（ＰＵＣＣＨ）を描いている。
【図４Ｂ】ここで開示される主題のいくつかの実施形態に係る例示的なロングＰＵＣＣＨを描いている。
【図５Ａ】レガシーのアップリンク（ＵＬ）グラント送信方法を用いるＵＬバーストについて要する高いシグナリングオーバヘッドを描いている。
【図５Ｂ】本開示のいくつかの実施形態に係るＵＬグラント多重化の一例を描いている。
【図６】本開示のいくつかの実施形態に従ってユーザ機器デバイス（ＵＥ）が連続する４つのサブフレーム内の（物理ダウンリンク共有チャネル（ＰＤＳＣＨ）上の）ＤＬデータと共に後続する４つのサブフレームについて有効なＵＬグラントを受信した、物理アップリンク共有チャネル（ＰＵＳＣＨ）内のアップリンク制御情報（ＵＣＩ）の一例を描いている。
【図７】図６のケースと同様のケースを描いているが、ここでは最初の４つのサブフレームにおいてＰＤＳＣＨを受信したＵＥからのＵＣＩが後続の４つのサブフレームの全ての利用可能なシンボルをまたいで広がるロングＰＵＣＣＨへマッピングされ、一方でＰＵＳＣＨリソースは他のＵＥへ割り当てられるものと想定される。
【図８】相異なるＵＥが隣接するサブフレームにおいてそれらのＰＵＣＣＨフィードバックを提供する場合に追加的なＬＢＴフェーズが必要とされる実施形態の一例を示している。
【図９】本開示のいくつかの実施形態に係るバンドリングされるＰＵＣＣＨ送信を例示している。
【図１０】短縮されるＤＬサブフレームの末尾にショートＰＵＣＣＨ（ｓＰＵＣＣＨ）が位置する１つの例を示している。
【図１１】ＵＥが４サブフレーム毎の専用スケジューリング要求（Ｄ−ＳＲ）機会と共に構成される一例を描いている。
【図１２Ａ】本開示の実施形態が実装され得るセルラー通信ネットワークの例を示している。
【図１２Ｂ】本開示の実施形態が実装され得るセルラー通信ネットワークの例を示している。
【図１３】本開示のいくつかの実施形態に係る提案３を実装するための基地局及びワイヤレスデバイスの動作を示している。
【図１４】本開示のいくつかの実施形態に係る提案４〜７を実装するためのワイヤレスデバイスの動作を例示するフローチャートである。
【図１５】本開示のいくつかの実施形態に係る提案８又は提案９を実装するための基地局及びワイヤレスデバイスの動作を例示している。
【図１６】本開示のいくつかの実施形態に係る提案１１を実装するためのワイヤレスデバイスの動作を例示するフローチャートである。
【図１７】本開示のいくつかの実施形態に係る提案１２を実装するためのワイヤレスデバイスの動作を例示するフローチャートである。
【図１８】本開示のいくつかの実施形態に係る提案１３を実装するための基地局及びワイヤレスデバイスの動作を例示している。
【図１９】本開示のいくつかの実施形態に係る提案１５〜１７のうちのいくつか又は全てを実装するための基地局及びワイヤレスデバイスの動作を例示している。
【図２０】本開示のいくつかの実施形態に係る提案１８〜２０のうちのいくつか又は全てを実装するための基地局及びワイヤレスデバイスの動作を例示している。
【図２１】本開示のいくつかの実施形態に係る基地局の実施形態を例示している。
【図２２】本開示のいくつかの実施形態に係る基地局の実施形態を例示している。
【図２３】本開示のいくつかの実施形態に係るワイヤレスデバイスの実施形態を例示している。
【図２４】本開示のいくつかの実施形態に係るワイヤレスデバイスの実施形態を例示している。
【図２５】本開示のいくつかの実施形態に従って、プライマリサービングセル内及びセカンダリサービングセル内のワイヤレスデバイスの動作を例示している。
【図２６】本開示のいくつかの実施形態に従って、ＵＬサブフレームの直前のサブフレームの末尾でのＬＢＴ動作の実行に対し、ＵＬサブフレームの冒頭でのＬＢＴ動作の実行を例示している。
【発明を実施するための形態】
【００３１】
以下に説示する実施形態は、それら実施形態を当業者が実践することを可能にし及びそれら実施形態の実践の最良の形態を例示する情報を表す。添付図面の図を踏まえて以下の説明を読めば、当業者は、本開示の概念を理解し、ここで具体的には扱われていないそれら概念の応用を認識するであろう。それら概念及び応用は、本開示及び添付の特許請求の範囲のスコープ内に入るものと理解されるべきである。
【００３２】
以下に説示する実施形態は、それら実施形態を当業者が実践することを可能にし及びそれら実施形態の実践の最良の形態を例示する情報を表す。添付図面の図を踏まえて以下の説明を読めば、当業者は、本開示の概念を理解し、ここで具体的には扱われていないそれら概念の応用を認識するであろう。それら概念及び応用は、本開示のスコープ内に入るものと理解されるべきである。
【００３３】
無線ノード：ここで使用されるところによれば、“無線ノード”は、無線アクセスノードであるか又はワイヤレスデバイスであるかのいずれかである。
【００３４】
無線アクセスノード：ここで使用されるところによれば、“無線アクセスノード”は、ワイヤレスに信号を送信し及び／又は受信するように動作する、セルラー通信ネットワークの無線アクセスネットワーク内の任意のノードである。無線アクセスノードのいくつかの例は、限定ではないものの、基地局（例えば、３ＧＰＰ（Third  Generation  Partnership  Project）ＬＴＥ（Long  Term  Evolution）ネットワーク内の拡張又は進化型ノードＢ（ｅＮＢ））、高電力又はマクロ基地局、低電力基地局（例えば、マイクロ基地局、ピコ基地局若しくはホームｅＮＢなど）、及び中継ノードを含む。
【００３５】
ワイヤレスデバイス：ここで使用されるところによれば、“ワイヤレスデバイス”は、無線アクセスノードへワイヤレスに信号を送信し及び／又は受信することによりセルラー通信ネットワークへのアクセスを有する（即ち、セルラー通信ネットワークによりサービスされる）任意のタイプのデバイスである。ワイヤレスデバイスのいくつかの例は、限定ではないものの、３ＧＰＰ  ＬＴＥネットワーク内のユーザ機器デバイス（ＵＥ）及びマシンタイプ通信（ＭＴＣ）デバイスを含む。
【００３６】
ネットワークノード：ここで使用されるところによれば、“ネットワークノード”は、セルラー通信ネットワーク／システムの無線アクセスネットワーク又はコアネットワークのいずれかの部分にある任意のノードである。
【００３７】
ＬＢＴ（Listen-Before-Talk）：ここで使用されるところによれば、“ＬＢＴ”又は“ＬＢＴ方式”は、無線アクセスノード又はワイヤレスデバイスが未ライセンス周波数スペクトル内のチャネル上での送信前にそのチャネルをモニタリングしてそのチャネルがクリアであるかを判定する（例えば、ＣＣＡ（Clear  Channel  Assessment）を実行する）任意の方式である。
【００３８】
ＬＢＴセル：ここで使用されるところによれば、“ＬＢＴセル”は、送信前にＬＢＴ方式が実行されなければならない、未ライセンス周波数スペクトル内のチャネル上で動作するセルである。
【００３９】
ライセンス支援型アクセス（ＬＡＡ）セカンダリセル（ＳＣｅｌｌ）：ここで使用されるところによれば、“ＬＡＡ  ＳＣｅｌｌ”は、あるタイプのＬＢＴセルである。具体的には、“ＬＡＡ  ＳＣｅｌｌ”は、ライセンス済み周波数スペクトル内で動作する他のセル（即ち、プライマリセル（ＰＣｅｌｌ））からの支援を伴って未ライセンス周波数スペクトル内で動作する、ＬＴＥネットワーク内のＳＣｅｌｌである。
【００４０】
スタンドアローンＬＢＴセル：ここで使用されるところによれば、“スタンドアローンＬＢＴセル”は、ライセンス済み周波数スペクトル内で動作する他のセルからの支援を伴わずに自ら動作するタイプのＬＢＴセル（例えば、ＬＴＥネットワーク内のセル）である。
【００４１】
注：ここで与えられる説明は３ＧＰＰ  ＬＴＥに焦点を当てており、そのため３ＧＰＰ  ＬＴＥの専門用語が多くの場合使用される。しかしながら、ここで開示される概念は、３ＧＰＰ  ＬＴＥには限定されない。
【００４２】
なお、ここでの説明において、“セル”との用語への言及がなされる。但し、特に第５世代（５Ｇ）の概念に関して言うと、セルの代わりにビームが使用されてもよく、そのため、ここで説明される概念はセル及びビームの双方へ等しく適用可能であることに留意することが重要である。よって、いくつかの実施形態において、ここで説明される送信は、セルではなくビーム（例えば、未ライセンス周波数スペクトル内のビーム）上で実行されてもよい。
【００４３】
本開示では、アップリンク（ＵＬ）関連のメディアアクセス制御（ＭＡＣ）プロトコルの観点、即ち、物理アップリンク共有チャネル（ＰＵＳＣＨ）上でデータを送信するために要する機能性と共に、物理アップリンク制御チャネル（ＰＵＣＣＨ）又はＰＵＳＣＨ上での、ハイブリッド自動再送要求（ＨＡＲＱ）確認応答／否定確認応答（ＡＣＫ／ＮＡＣＫ）フィードバック及びスケジューリング要求の送信が検討される。
【００４４】
＜物理レイヤ上のＰＵＣＣＨの実現＞
本開示では、未ライセンススペクトル（ＬＴＥ−Ｕ）動作におけるスタンドアローンＬＴＥのためのＰＵＣＣＨの物理レイヤ設計が提供される。ショートＰＵＣＣＨ（ｓＰＵＣＣＨ）及びロングＰＵＣＣＨの設計という２つのオプションが、物理レイヤの視点から説明される。ＰＵＣＣＨ上でのＨＡＲＱフィードバック及びスケジューリング要求（ＳＲ）のＭＡＣプロトコル設計が以下に議論されるであろう。
【００４５】
３ＧＰＰ  ＬＴＥでは、ＨＡＲＱ−ＡＣＫ、ＳＲ及び周期的なチャネル状態情報（ＣＳＩ）を含むアップリンク制御情報（ＵＣＩ）をＰＵＣＣＨ上で送信することができる。未ライセンス帯域でのスタンドアローン動作については、ｅＮＢタイミング構成及びＨＡＲＱプロトコルに依存して、以下に説明するように、ＵＣＩ送信のために２つのＰＵＣＣＨフォーマットを考慮することができる。留意すべきこととして、スタンドアローンＬＴＥ−Ｕでは、各ＵＬサービングセルが対応するＤＬサービングセルについてのＨＡＲＱフィードバックを搬送することが有益である。これにより、１つのセルのチャネルステータスが全てのセルのＨＡＲＱ−ＡＣＫフィードバックを左右することが回避される。このアプローチは、典型的にＰＣｅｌｌのＰＵＣＣＨが全てのＳＣｅｌｌについてのＵＣＩを搬送するＬＴＥとは相違する。一方で、チャネル利用率及びＰＵＣＣＨフォーマット設計の点で、各スタンドアローンキャリアについて独立的なＰＵＣＣＨを有することが提案される。
【００４６】
［ショートＰＵＣＣＨ（ｓＰＵＣＣＨ）］
ｓＰＵＣＣＨは、時間ドメインにおいて１〜３個のＳＣ−ＦＤＭＡ（Single  Carrier  Frequency  Division  Multiple  Access）／ＯＦＤＭ（Orthogonal  Frequency  Division  Multiplexing）シンボルを占有し、インタレースによって帯域幅全体にわたる。ｓＰＵＣＣＨは、ＤＬの部分的なサブフレームの末尾において又は（少なくともＰＵＳＣＨが同じＵＥへスケジューリングされる場合）ＵＬサブフレームの一部として送信されることができる。ｓＰＵＣＣＨを送信する目的で、ＵＥにアグレッシブＬＢＴが適用されてよい。代替的に、規制要件によれば、ｓＰＵＣＣＨの時間長がデューティサイクルの５％を下回る場合にはＬＢＴを要しない。
【００４７】
図４Ａは、ここで説明される主題の一実施形態に係る例示的なｓＰＵＣＣＨを描いている。図４Ａに例示した実施形態において、ＰＵＣＣＨは、時間において２つのＳＣ−ＦＤＭＡ／ＯＦＤＭシンボルを、周波数ドメインにおいて１つのインタレースを占有する。図中に例示したように、２つのオプションとして、復調リファレンス信号（ＤＭＲＳ）及びＰＵＣＣＨのためのデータシンボルを、周波数多重化し又は時間多重化することができる。複数のＰＵＣＣＨ  ＵＥを、異なるインタレーシングパターンを割り当てることにより周波数ドメインで、及び／又は例えば単一のインタレース内で異なる直交カバーコード（ＯＣＣ）を適用することにより符号ドメインで多重化することができる。ｅＮＢシグナリングによって、ＵＥについて、シンボルの数、インタレーシングパターン及びＯＣＣ構成（もしあれば）を構成することができる。
【００４８】
ＨＡＲＱフィードバック及び対応するプロセス識別子（ＩＤ）は、明示的に列挙されるか、又は例えばビットマップ（プロセスごとに１又は２ビット）として提供されるかのいずれかであり得る。設計を３ＧＰＰリリース１３（Ｒｅｌ−１３）キャリアアグリゲーション（ＣＡ）に合わせるために、ｓＰＵＣＣＨ上のＵＣＩは、８ビットのＣＲＣ（Cyclic  Redundancy  Check）を付加され、ＴＢＣＣ（Tail  Biting  Convolutional  Code）を用いて符号化される。符号化されたシンボルは、周波数が先、時間が次という形で利用可能なリソースエレメント（ＲＥ）へマッピングされる。
【００４９】
［ロングＰＵＣＣＨ］
ロングＰＵＣＣＨは、時間ドメインにおいてサブフレーム全体を占有し、インタレース
によって帯域幅全体にわたる。ロングＰＵＣＣＨは、ｅＮＢにより明示的にスケジューリングされることができ、ＵＬチャネルへのアクセスを得るためにＵＥにおいてＬＢＴを要する。ロングＰＵＣＣＨは、ＰＵＳＣＨ送信に適合し、同一の又は異なるＵＥからのＰＵＳＣＨと多重化されることができる。
【００５０】
図４Ｂは、ここで説明される主題の一実施形態に係る例示的なロングＰＵＣＣＨを描いている。図４Ｂに例示した実施形態において、ＰＵＣＣＨは、１つのサブフレームにおいて１つのインタレースを占有する。周波数において帯域幅全体を占有する、スロットごとに１つのＤＭＲＳが存在し、これを異なるサイクリックシフトを適用することによりＰＵＳＣＨ  ＤＭＲＳと多重化することができる。ｓＰＵＣＣＨと同様、複数のＰＵＣＣＨ  ＵＥを、異なるインタレーシングパターンを割り当てることにより周波数ドメインで、及び／又は例えば単一のインタレース内で異なるＯＣＣを適用することにより符号ドメインで多重化することができる。同じサブフレーム内の残りのインタレースは、ＰＵＳＣＨ送信及び他のＵＥからのＰＵＣＣＨ／ＰＵＳＣＨ送信のために使用され得る。ｅＮＢシグナリングによって、ＵＥについて、インタレーシングパターン、サイクリックシフト（ＣＳ）及びＯＣＣ構成（もしあれば）を構成することができる。
【００５１】
ｓＰＵＣＣＨと同様に、ＰＵＣＣＨ．１上で、ＨＡＲＱフィードバック及び対応するプロセスＩＤは、明示的に列挙されるか、又は例えばビットマップ（プロセスごとに１又は２ビット）として提供されるかのいずれかであり得る。ロングＰＵＣＣＨ上のＵＣＩは、８ビットのＣＲＣを付加され、ＴＢＣＣを用いて符号化される。符号化されたシンボルは、周波数が先、時間が次という形で利用可能なＲＥへマッピングされる。
【００５２】
３ＧＰＰ  ＬＴＥでは、ＰＵＣＣＨ上でのＵＣＩ送信は、ＨＡＲＱ−ＡＣＫ、ＳＲ及び周期的なＣＳＩを含む。スタンドアローンＬＴＥ−Ｕについては、周期的なＣＳＩをサポートすることは困難となるはずである。よって、非周期的なＣＳＩフィードバックが、より不可欠であって、ＵＬ共有チャネル（ＵＬ−ＳＣＨ）データの有無によらずＵＬグラントによりスケジューリングされるＰＵＳＣＨ上でサポートされるべきである。同じサブフレーム内の例えばＨＡＲＱ及びＳＲなど、１つよりも多くのＵＣＩタイプがＰＵＣＣＨ上で送信される場合には、それらは連結され及び共同的に符号化され、そして、以下に説明するように、ＤＬ  ＨＡＲＱプロトコルに基づいてｅＮＢ構成に従ってｓＰＵＣＣＨフォーマットか又はロングＰＵＣＣＨフォーマットかのいずれかで送信される。
【００５３】
＜アップリンクＬＢＴアルゴリズム＞
［Ｒｅｌ−１３  ＬＡＡ  ＵＬ  ＬＢＴ］
Ｒｅｌ−１３の期間中に、ＵＬ  ＬＢＴのいくつかの観点が議論された。ＵＬ  ＬＢＴのフレームワークに関して、その議論は、セルフスケジューリング及びクロスキャリアスケジューリングのシナリオに焦点を当てた。
【００５４】
認識されたこととして、ＵＬ  ＬＢＴは、セルフスケジューリングを伴うＵＬ送信に追加的なＬＢＴのステップを課し、なぜならＵＬグラント自体がｅＮＢによるＤＬ  ＬＢＴを要するからである。従って、Ｒｅｌ−１３のＬＡＡは、セルフスケジューリングのためのＵＬ  ＬＢＴが（ＤＬの専用リファレンス信号（ＤＲＳ）と同様に）少なくとも２５μｓの単一のＣＣＡ時間長か、又は１ＣＣＡスロットが後に続く１６μｓの延期時間長を含む２５μｓの延期ピリオドを伴うランダムバックオフ方式かのいずれか、及び、Ｘ＝｛３，４，５，６，７｝から選択される最大競合ウィンドウサイズを使用すべきであることを推奨している。これらオプションは、他の未ライセンスＳＣｅｌｌによるＵＬのクロスキャリアスケジューリングにも適用可能である。
【００５５】
ライセンス済みＰＣｅｌｌによるクロスキャリアスケジューリングに関与するケースの
ためのショートＵＬ  ＬＢＴ手続は、さらなる研究のためにオープンなままである。審議中の他のオプションは、Ｗｉ−Ｆｉステーションにより使用されるものに類似する、本格的な（full-fledged）ランダムバックオフ手続である。
【００５６】
最後に、ＵＬ送信バーストがそれぞれのキャリア上でＤＬ送信バーストに続く（２つのバースト間に高々１６μｓのギャップを伴う）場合の、ＬＢＴ無しでのＵＬ送信のケースが、Ｒｅｌ−１４におけるさらなる研究のためにオープンで残された。
【００５７】
［スタンドアローンＵＬ  ＬＢＴアルゴリズム］
スタンドアローンのＵＬ  ＬＢＴ設計がＲｅｌ−１４  ＬＡＡにおいて仕様化される有望なＵＬ  ＬＡＡ  ＬＢＴアルゴリズムと整合することは不可欠である。そのうえ、ＵＬチャネルアクセスは、ダウンリンクと比較した場合に優位である必要がある。これら観点が以下の提案につながる。このようにして、本開示は、さらなる研究のための基礎としてＲｅｌ−１３  ＬＡＡ  ＵＬ  ＬＢＴのオプションを保つことを提案し、及び、ＵＬ  ＣＣＡエネルギー検出（ＣＣＡ−ＥＤ）閾値を少なくともＤＬ  ＣＣＡ−ＥＤ閾値と同程度に高くすることを提案する。
【００５８】
［ＵＬグラント送信］
レガシーのＵＬグラント送信では、各ＵＬサブフレームは、４ｍｓ早く送信される専用グラントによりスケジューリングされる。これは、図５Ａに見られるように、単一の４ｍｓのＵＬバーストを指し示すためにＵＬグラントを伴う４つの連続するサブフレームが必要とされることから、高いシグナリング負荷をもたらす。
【００５９】
図５Ａは、レガシーのＵＬグラント送信方法を用いるＵＬバーストのために要する高いシグナリングオーバヘッドを描いている。低負荷では、これは、そのサブフレームにおいてデータの無いＵＬグラントを単に送信するためにＤＬ  ＬＢＴを実行することを必要とするはずであることをさらに示唆し、それが未ライセンスチャネルの非効率的な使用をもたらす。ＵＬグラント送信とＵＬ送信との間の４ｍｓの遅延は、短いＤＬバーストの直後にＵＬバーストを続けることを困難にもする。
【００６０】
レガシーＵＬグラント送信の欠点は、ＵＬ  ＬＡＡのポテンシャルを有意に低下させるが、簡易な改善でそれに対処することができ、それら改善とは、単一のＤＬサブフレームから複数のＵＬサブフレームをスケジューリングすること、及びＵＬグラント受信とＵＬサブフレームとの間の最小の遅延を低減することである。これらが次に順に扱われるであろう。
【００６１】
マルチサブフレームスケジューリング：単一のＤＬサブフレームから複数のＵＬサブフレームをスケジューリングすることで、ＵＬ  ＬＡＡについてのシグナリングオーバヘッド及び隣接セルへ引き起こす干渉が低減される。所与の時点でＵＬトラフィックのみを伴う低負荷の状況について、１ＤＬサブフレームの範囲内から４つのＵＬサブフレームをスケジューリングすることが可能であれば、グラント送信のオーバヘッドは２５％まで低減される。個々のサブフレームにおいて異なる構成を指し示すことができれば、オーバヘッドの低減はいくらかより小さくなり得る。変調符号化方式（ＭＳＣ）、インタレース、サウンディングリファレンス信号（ＳＲＳ）構成、及びＤＭＲＳ構成などを変化させることが望まれるかもしれない。この特徴は、時間分割複信（ＴＤＤ）では既にサポートされており、なぜなら２つのＤＬサブフレームに対し３つのＵＬサブフレームを伴うコンフィグレーション０が、単一のＤＬサブフレームから複数のＵＬサブフレームをスケジューリングすることをサポートするからである。１つのＤＬサブフレームでスケジューリングされるＵＬサブフレームの数が、例えば１２個にまでさらに増加される場合、シグナリングオーバヘッドをさらに例えば８．３３％にまで低減することができ、ＬＡＡ  ＵＬ性能がさ
らに改善される。しかしながら、同一のＤＬサブフレームでスケジューリングされるＵＬサブフレームの最適な数は、トラフィックタイプ、トラフィック負荷及びＵＥバッファサイズといった多くの要因に依存する。従って、ｅＮＢは、理想的には、同じＤＬサブフレームでいくつのＵＬサブフレームがスケジューリングされるかを構成するための自由度を有するべきである。ＭＡＣプロトコルのインパクトは、以下で議論するように最小限である。このように、本開示の他の提案は、ＵＬについてマルチサブフレームスケジューリングをサポートすることである。
【００６２】
低減されたＵＬグラント遅延。アップリンク性能をさらに改善するために、４ｍｓというレガシーの固定的なＵＬグラント遅延は低減されるべきである。所与の時点でＵＬトラフィックのみを伴う低負荷の状況を考慮すると、ＵＬグラントの多重化のみがさらなる最適化無しで適用される場合、図５Ｂに描いた状況に結局なり得る。
【００６３】
図５Ｂは、本開示の一実施形態に係るＵＬグラント多重化の一例を描いている。ＵＬグラント送信のシグナリングオーバヘッドは低減されるが、ＵＬデータ送信のために以前のＵＬグラントサブフレームが使用される代わりに、それらは単にＵＬ送信が開始するまで空白に保たれる。よって、アップリンクスループットは限られたまま残る。
【００６４】
図５に描いた状況を可能な限り回避するように、ｅＮＢスケジューリングが最適化され得る。とはいえ、ＬＢＴの失敗に起因して、多重化されたＵＬグラント送信を計画されたサブフレームにおいてなし得ない都度、この状況は発生するであろう。図５Ｂにおける課題を解決するための最も自然であり単純な方法は、アップリンクについてグラント遅延を低減することである。このように、本開示の他の提案は、ＵＬグラントと対応するＵＬ送信との間の遅延を、４ｍｓ未満にまで低減することである。
【００６５】
＜ＰＵＳＣＨについてのアップリンクＨＡＲＱ＞
［提案１：非同期ＵＬ  ＨＡＲＱの採用］
ＬＡＡ研究項目フェーズの３ＧＰＰ技術報告（ＴＲ）３６．８８９  Ｖ１３．０．０のセクション７．２．２．２において、特にＰＵＳＣＨについて「ＬＡＡ  ＵＬのために非同期的なＨＡＲＱが推奨」されている。このことは、ＵＬの再送が初期の送信の１ラウンドトリップ時間（ＲＴＴ）（例えば、ｎ＋８）後にのみ生じるわけではなく、むしろ任意の時点で生じ得ることを意味する。これは、特にＬＢＴに起因して（再）送信がブロックされ先延ばしされる場合に有益であると考えられる。よって、３ＧＰＰ  Ｒｅｌ−１４の機能性との適合性を維持する目的で、本開示は、（ＬＡＡ  ＵＬについてＲｅｌ−１３研究項目（ＳＩ）において合意された通りの）非同期ＵＬ  ＨＡＲＱを採用することを提案する。
【００６６】
［提案２：非適応的アップリンクＨＡＲＱをサポートせず］
３ＧＰＰ  ＴＲ３６．８８９  Ｖ１３．０．０のセクション７．２．２．２において、「ＵＬ非同期ＨＡＲＱプロトコルでは、全ての送信又は再送を、物理ダウンリンク制御チャネル（ＰＤＣＣＨ）又は拡張ＰＤＣＣＨ（ｅＰＤＣＣＨ）を介してスケジューリングすべきである」こともまた合意された。言い換えると、非適応的なＨＡＲＱはもはやサポートされない。なぜなら、それは非同期ＨＡＲＱの概念には良好にフィットせず、ＤＬにおいてＡＣＫ／ＮＡＣＫを搬送するために信頼性の高いチャネルを要するはずだからである。ここで使用されるところによれば、“非適応的なＨＡＲＱ”との用語は、物理ＨＡＲＱインジケータチャネル（ＰＨＩＣＨ）上のＮＡＣＫが同一の周波数リソース上で同一のＭＣＳと共に初期の送信の１ＲＴＴ後のＨＡＲＱ再送をトリガするという動作モードをいう。ＰＨＩＣＨは、従来のようには使用され得ない：ＰＨＩＣＨ上のＡＣＫがＬＢＴによりブロックされる場合、ＵＥは、既存のＨＡＲＱパターン及びスケジューリング割り当てに従って非適応的な再送を実行するはずであった。よって、本開示は、非適応的なＵＬ  Ｈ
ＡＲＱをサポートしないことを提案する。
【００６７】
［提案３：ＵＬ  ＨＡＲＱは成功したと仮定し、ステータスをＡＣＫへ設定］
非同期ＨＡＲＱを導入する場合、ＵＥは、よって、送信の行われた全てのＵＬ  ＨＡＲＱプロセスが成功したものと仮定（ローカルのステータスをＡＣＫへ設定）すべきである。ＵＥは、ｅＮＢからの（ＮＤＩ（New  Data  Indicator）が切り替えられていない）ＵＬグラントの受信に応じてのみ、対応するＨＡＲＱプロセスについてＨＡＲＱ再送を実行する。プロセスインデックスは、ＵＬグラント内のＨＡＲＱプロセスインデックスフィールドにおいて指し示される。なお、ほとんどの送信試行はいずれにしろ成功し、よってフィードバック（ＰＨＩＣＨ）はそれ以上必要でないと見なすこともまた効率的である。よって、本開示は、ＵＬ  ＨＡＲＱプロセスの送信に応じて、ＵＥがその送信が成功したものと仮定してローカルで維持されるステータスをＡＣＫへ設定することを提案する。ＵＥは、ＵＬグラントの受信に応じてのみ、対応するＵＬ  ＨＡＲＱプロセスについてＨＡＲＱ再送を実行する。
【００６８】
３ＧＰＰ  ＴＲ３６．８８９  Ｖ１３．０．０は、ＵＬ  ＨＡＲＱバッファをフラッシュする新たな手段を導入する必要性にも言及している。これまでのところ、これは、ＨＡＲＱプロセスごとのカウンタ（CURRENT_TX_NB）と共になされ、ＵＥはそれをＲＴＴごとに（即ち、プロセスが再送を行う機会を有する都度）１回インクリメントする。非同期ＨＡＲＱが導入されると、再送は別の時点でなされ得る。従って、３ＧＰＰでは、プロセスの初期の送信からのサブフレーム数を判定するタイマ／カウンタを使用し、タイマ／カウンタが構成済みの閾値を上回る際にプロセスをフラッシュすることがより適切であろうという議論がなされた。しかし、ＨＡＲＱプロセスをフラッシュすることが必要か否かは、例えば不連続受信（ＤＲＸ）がどのようにハンドリングされるかに依存する。
【００６９】
３ＧＰＰによる研究では、ＤＲＸアクティブ時間を再定義する必要性もまた識別された。ＵＥは、ＨＡＲＱ再送について潜在的な来たるべきＵＬグラントを受信する目的で、どのサブフレームにおいてＰＤＣＣＨをモニタリングするものとされるかを判定する必要がある。具体的なＨＡＲＱプロセスのための再送はもはや特定のサブフレームに縛られないことから、ＵＬ再送のためのグラントは、原理上は、未だフラッシュされていない任意のプロセスについて任意のサブフレームに出現し得る。従って、簡易な解決策は、３ＧＰＰ  ＴＳ３６．３２１  Ｖ１２．７．０における条件を、「仕掛かり中のＨＡＲＱ再送についてのアップリンクグラントが生起可能であり且つ対応するＨＡＲＱバッファ内にデータがある」から、「アップリンクＨＡＲＱバッファのいずれか内にデータがある」へ変更すること、及び、前の段落において概説したようにバッファをフラッシュすることであろう。しかしながら、このアプローチは、再送を要しない場合でさえも各ＵＬ送信の後にかなり長い時間にわたってＵＥを連続的にウェイクアップしたまま保つことになる。
【００７０】
［提案４：ＵＥは有効なＵＬグラントを有するサブフレームにおいて“アップリンクＨＡＲＱフィードバックタイマ”を開始する］
非同期ＨＡＲＱの導入に起因して、幸運にも、ＵＥを連続的にウェイクアップしたまま保つことはもはや必要ではない。ｅＮＢは、（ＬＢＴが成功するものとして）任意のサブフレームにおいて任意のＵＬ  ＨＡＲＱプロセスのための再送をスケジューリングすることを可能とされる。従って、提案されるのは、Ｒｅｌ−８よりＤＬ  ＨＡＲＱについて使用されてきたＨＡＲＱ  ＲＴＴタイマ（HARQ  RTT  Timer）及びＤＲＸ再送タイマ（DRX-RetransmissionTimer）と同様の原理を使用することである。相違点は、ここで“ＵＬ  ＨＡＲＱフィードバックタイマ（UL  HARQ  Feedback  Timer）”として言及されるタイマが、ＵＬグラントが有効になるサブフレームにおいて（送信が発生する場合に加えてＬＢＴの不成功によりブロックされた場合の双方において）開始することである。ＵＬ  ＨＡＲＱフィードバックタイマは、再送のためのＵＬグラントが受信され得る最も早い時点
まで稼働する。よって、本開示は、有効なＵＬグラントを有するサブフレームにおいて、即ち、ＵＬ送信が発生する場合に加えてそれがＬＢＴによりブロックされる場合のいずれかにおいて、ＵＥがＵＬ  ＨＡＲＱフィードバックタイマを開始することを提案する。
【００７１】
［提案５：ＵＬ  ＨＡＲＱフィードバックタイマがＤＲＸ再送タイマをトリガする］
本開示は、ＵＬ  ＨＡＲＱフィードバックタイマの満了に応じて、ＵＥが対応するＤＲＸ再送タイマを開始し、上記ＤＲＸ再送タイマが稼動している限りアクティブ時間（Active  Time）のままでいることを提案する。
【００７２】
［提案６：ＨＡＲＱバッファのフラッシュがＵＬ  ＨＡＲＱフィードバックタイマを停止する］
本開示は、ＵＥがＵＬ  ＨＡＲＱフィードバックタイマを対応するＨＡＲＱバッファのフラッシュに応じて停止することをさらに提案する。
【００７３】
［提案７：ＵＬ  ＨＡＲＱプロセスごとに１つのＵＬ  ＨＡＲＱ  ＲＴＴタイマ及び１つのＤＲＸ再送タイマ］
本開示は、１つのＵＬ  ＨＡＲＱ  ＲＴＴタイマ及び１つのＤＲＸ再送タイマが各ＵＬ  ＨＡＲＱプロセスに関連付けられることをも提案する。
【００７４】
但し、注記されることとして、提案４〜７が合意可能であれば、ＵＬ  ＨＡＲＱバッファをフラッシュする強い必要性は存在せず、よって、本開示は、さしあたりそうした手段を導入することを提案しない。代替的に、本開示は、提案４〜７が採用される状況ではＵＬ  ＨＡＲＱバッファのフラッシュ（flushing）を行わなくてよいことを提案する。
【００７５】
ＬＡＡ研究項目のスコープにおいて、ｅＮＢが単一のＤＬサブフレームにおいて複数のＰＵＳＣＨ送信についてのＵＬグラントを送信し得るようなマルチサブフレームスケジューリングをサポートすることも議論された。この拡張は、トラフィックがＵＬに偏る都度リソース利用率及びスループットを最大化するために、有益であると考えられる。現在のところ、Ｌ１とＭＡＣとの間のインタラクションは、Ｌ１がグラント及び割り当てのタイミングをケアする手法でモデル化されている。ＤＣＩが（例えば、ＴＤＤについて）２つのＵＬグラントを含む場合、Ｌ１は、２つの適切なサブフレームにおいてそれらをＭＡＣへ提供する。同じモデル化が適用されるものとすると、マルチサブフレームＵＬスケジューリングは、ＭＡＣの仕様には何らの追加的なインパクトも有するものと予期されない。なお、提案４〜７において提案したＵＬ  ＨＡＲＱフィードバックタイマは、これらＵＬプロセスのいずれかのための再送が生じ得る最も早い時にＵＥがウェイクアップすることを保証する。
【００７６】
＜ＤＬ  ＨＡＲＱのためのＵＬフィードバック＞
ＤＬ  ＨＡＲＱプロトコルは、３ＧＰＰ  Ｒｅｌ−８より既に非同期的であり、よって、ＬＡＡによる使用のために準備が整っており、ＨＡＲＱフィードバック（ＡＣＫ／ＮＡＣＫ）をライセンス済みのＰＣｅｌｌのＰＵＣＣＨ上で高い信頼性で送信することができる。しかしながら、スタンドアローン動作について（例えば、スタンドアローンＬＡＡセルについて）（及び、デュアルコネクティビティを伴うＬＡＡについて）、アップリンク制御情報（ＵＣＩ）は、未ライセンススペクトル上で送信される。今日では、規制上のルールは、制御情報の送信が時間のうちの５％を超えてメディアを占有しない場合には、（ユーザプレーンデータ向けではない）制御情報についてＬＢＴを省略することを許容する。このルールに基づいてＰＵＣＣＨを設計することは、プロトコルの視点からは魅力的であるはずだが、結果として生じる衝突がシステム性能にネガティブなインパクトを与えかねない。そのうえ、この５％ルールを修正し又は否定する試みが無いとも言い切れない。従って、ＵＣＩなどの制御シグナリングへＬＢＴを適用することを検討することが提案さ
れる。
【００７７】
［提案８：ＵＣＩがＤＬ  ＨＡＲＱプロセスを識別する］
今日では、ＬＴＥのＤＬ  ＨＡＲＱの設計は、ＤＬ  ＨＡＲＱプロセスと対応するＨＡＲＱフィードバックとの間の固定的なタイミング関係に専ら依拠する。ＬＢＴに起因して、ＤＬ送信とＨＡＲＱフィードバックとの間の時間は変化することになり、従って、ＵＬにおいて送信されるＨＡＲＱフィードバック内にＨＡＲＱプロセスＩＤを含めることは必須であると考えられる。
【００７８】
ある種のバンドリングがＲＴＴを増加させることから、（サブフレームｎ＋４以内の）即座のフィードバックが概して好ましい。しかしながら、それは、ｅＮＢ及びＵＥが送信方向を（ＤＬからＵＬへ、ＵＬからＤＬへ）より高い頻度で切り替えることをも要し、それがオーバヘッドを増加させる。いずれにしろ、ＨＡＲＱフィードバック内にＨＡＲＱプロセスＩＤを含めることを必要とする場合、複数のＤＬプロセスについてのＨＡＲＱフィードバックを単一のＵＬメッセージへバンドリングすることは容易に可能である。ＨＡＲＱフィードバック及び対応するプロセスＩＤは、明示的に列挙されるか、又は例えばビットマップ（プロセスごとに又はトランスポートブロックごとに１ビット）として提供されるかのいずれかであり得る。よって、本開示は、ＵＣＩが明示的にか又はビットマップとしてかのいずれかでＤＬ  ＨＡＲＱプロセス識別子を収容することを提案する。
【００７９】
［提案９：ｅＮＢはＵＥがＵＣＩ内にＨＡＲＱフィードバックをバンドリングするか及びいくつバンドリングするかを制御する］
プロセスごとの即座のフィードバックはＩＰ（Internet  Protocol）レイヤ上で観測されるレイテンシを低減する一方で、フィードバックのバンドリングはスペクトル効率を改善する。これら“モード”のいずれが好ましいかは、例えばシステム負荷及び具体的なＵＥのキューに依存する。従って、ｅＮＢは、モード間の切り替えを行う手段を有するべきであり、即ち、ＨＡＲＱフィードバックを頻繁に要求するか、又は複数のプロセスについてのフィードバックをＵＥにバンドリングさせるかである。
【００８０】
［提案１０：各ＵＬサービングセルが対応するＤＬサービングセルについてのＨＡＲＱフィードバックを搬送する］
“物理レイヤ上のＰＵＣＣＨの実現”との見出しを付した上のセクションにおいて議論したように、各ＵＬサービングセルが対応するＤＬサービングセルについてのＨＡＲＱフィードバックを搬送することが提案される。ＬＴＥではこれとは異なり、典型的には、ＰＣｅｌｌのＰＵＣＣＨが全てのＳＣｅｌｌについてのＵＣＩを搬送する。但し、チャネル利用率及びＰＵＣＣＨフォーマット設計の点で、ＬＴＥの未ライセンスのスタンドアローンではそれを別々に保つことが提案される。
【００８１】
この要求は、ＤＬ割り当ての一部として明示的であるか、又はＵＣＩを送信するために適切なリソースの利用可能性に基づいてＵＥがそれを決定できるかのいずれかであり得る。その詳細は可変であって、ＰＵＣＣＨ設計にも依存してよく、それが以下で議論される。
【００８２】
ダウンリンクＨＡＲＱプロセスについてのＡＣＫ／ＮＡＣＫフィードバックの提供にここで焦点が当てられているが、その上で、専用スケジューリング要求（Ｄ−ＳＲ）及び／又はＣＳＩもまた送信される必要がある。
【００８３】
［提案１１：有効なＵＬグラントを伴うＵＥは仕掛かり中のＨＡＲＱ（及び恐らくは他のＵＣＩ）をＰＵＳＣＨへ多重化する］
原理上、同じＵＥからＰＵＳＣＨと同じサブフレームにおいて、他のＵＥからＰＵＳＣ
Ｈと同じサブフレームにおいて、同じＵＥ向けの物理ダウンリンク共有チャネル（ＰＤＳＣＨ）と同じサブフレームにおいて、他のＵＥ向けのＰＤＳＣＨと同じサブフレームにおいて、又は、（ＵＥがＵＬグラントを受信せずＰＤＳＣＨも検出しなかった）空のサブフレームにおいて、ＨＡＲＱフィードバック（ＵＣＩ）を送信することは可能であるべきである。
【００８４】
ＵＥが有効なＰＵＳＣＨグラントを有する場合、ＵＣＩ情報（何らかのものが利用可能な場合）を、追加的なリソースエレメントを使用するよりもむしろ、それらＰＵＳＣＨリソースへマッピングすることが望ましい。ＬＴＥでのように、ＰＵＳＣＨへのこのマッピングは、ＰＵＣＣＨのために追加的なリソースエレメントを割り当てることと比較して、より良好なキュービックメトリックなど、好適な送信特性を提供する。
【００８５】
図６は、ＰＵＳＣＨ内のＵＣＩの一例を描いており、ここで説明される主題の一実施形態に従って、ＵＥは、連続する４つのサブフレーム内のＤＬデータ（ＰＤＳＣＨ）と共に後続する４つのサブフレームについて有効なＵＬグラントを受信している。ＨＡＲＱフィードバックを（例えば、最後のＰＵＳＣＨサブフレームへ）バンドリングすることは可能である一方で、できる限り早期にＨＡＲＱフィードバックを送信することが好ましい。また、ＵＥがいずれにしろ割り当て済みのＵＬリソースを有することから、以下に示すマッピングが好ましいと見られる。よって、本開示は、有効なＵＬグラントを伴うＵＥが仕掛かり中のＨＡＲＱ及び恐らくは他のＵＣＩをＰＵＳＣＨへ多重化し得ることを提案する。
【００８６】
［提案１２：有効なＵＬグラントを伴わないＵＥは仕掛かり中のＨＡＲＱフィードバックをショートＬＢＴ成功に応じて（ロング）ＰＵＣＣＨ上で送信する］
図７は、ここで説明される主題の他の実施形態に係るＰＵＳＣＨ内のＵＣＩの一例を描いている。図７は図６のケースと同様のケースを描いているが、図７に示した実施形態では、最初の４つのサブフレームにおいてＰＤＳＣＨを受信したＵＥからのＵＣＩは、後続の４つのサブフレームの全ての利用可能なシンボルにまたがる（ロング）ＰＵＣＣＨへマッピングされ、一方でＰＵＳＣＨリソースは他のＵＥへ割り当てられるものと想定される。
【００８７】
ＰＵＳＣＨ送信リソースは明示的にグラントされるのに対し、ＵＥは、ＰＵＣＣＨリソースを、ＬＴＥにおいて定義されているものと同様のマッピングによりＤＬグラントから暗黙的に導出するものと想定される。ＰＵＣＣＨ送信を実行する前に、ＵＥは、ＬＢＴを実行しなければならない。Ｒｅｌ−１３研究項目においてＰＵＳＣＨについて議論されたように、先行するＰＤＳＣＨ送信が通常のＬＢＴの対象であったことから、短いＬＢＴだけを実行することが可能であると考えられる。言い換えると、ＰＵＣＣＨはスケジューリングされたＰＵＳＣＨと同じＬＢＴパラメータを使用し、それが単一のサブフレームにおいて複数の送信を多重化することを可能にする。
【００８８】
図７の例では、ＵＥは、後続のＤＬサブフレームに先立ってｅＮＢがＤＬ  ＬＢＴを実行できるように、４番目のＰＵＣＣＨ送信を短縮しなければならない。これは、サブフレーム８のためのＵＬリソースのスケジューリングに応じて、ｅＮＢが後続のサブフレーム９がＵＬサブフレームになるのか又はＤＬサブフレームになるのかを決定することも必要とすることを示唆する。ＤＬサブフレームが次に来るものとされる場合、先行するＵＬサブフレームはより早く終了する必要がある。この制約は望ましくないと考えられる一方で、それはＲｅｌ−１３において確立されたベースラインに従う。ｅＮＢは、サブフレームの短縮を指し示すためにＬＡＡ  Ｒｅｌ−１３において導入されたＰＤＣＣＨブロードキャストシグナリングを使用することができる。代替的に、その情報をＤＬ割り当ての一部として提供することができる。
【００８９】
［提案１３：ＵＬ  ＬＢＴのスキップ］
図８は、ここで説明される主題の他の実施形態に係る、隣接するサブフレームにおいて相異なるＵＥが自身のＰＵＣＣＨフィードバックを提供する場合に追加的なＬＢＴフェーズが必要とされる例を示している。ＤＬからＵＬへ及びＵＬからＤＬへの遷移時のＬＢＴに加えて、相異なるＵＥが自身のＰＵＣＣＨフィードバックを隣接するサブフレームにおいて提供する場合、追加的なＬＢＴフェーズが必要とされる。これが、図８においてハイライトされており、第１のＵＥは最初の２つのサブフレームにおいてＰＤＳＣＨを受信し、第２のＵＥは３番目及び４番目のサブフレームにおいてＰＤＳＣＨを受信する。ｅＮＢは、ＤＬ送信を立て続けに実行し得るものの、第２のＵＥは自身のＰＵＣＣＨ送信を実行する前にチャネルが開いているかをセンシングする必要がある。
【００９０】
図７の例と図８の例とを比較すると、ＵＥがＵＬサブフレームの冒頭でＬＢＴを実行すべきかを自ら判定することができないことが明らかとなる。先行するサブフレームをＵＬ送信のために使用した場合であっても、他のＵＥが後続のサブフレームにおいてＬＢＴを実行する必要があるか否かに依存して、そのサブフレームに先立って別のＬＢＴを行わなければならないかもしれない。従って、ｅＮＢが明示的にＵＬグラント（ＰＵＳＣＨ向け）において及びＤＬ割り当て（ＰＵＣＣＨ向け）においてＵＥが対応するＵＬサブフレームについてＬＢＴをスキップしてよいかを指し示すことが提案される。エラーケースを回避する目的で、ＵＥは、先行するサブフレームにおいてＵＬ送信を実行していなかった場合、スケジューリングされるＵＬサブフレームにおいて（ショート）ＬＢＴを実行すべきである。このミスマッチは、先行するサブフレームにおけるＵＥによるＬＢＴに起因して、又はＵＬグラント若しくはＤＬ割り当ての逸失に起因して発生し得るはずである。よって、本開示は、次の条件の双方が満たされる場合にＵＥが自身のＵＬ  ＬＢＴをスキップし得ることを提案する：１）ＵＥが先行するサブフレームにおいてＵＬ送信（ＰＵＣＣＨ又はＰＵＳＣＨ）を実行した；及び、２）ｅＮＢが明示的にＵＬグラント又はＤＬ割り当てにおいてＬＢＴのスキップを許可した。
【００９１】
図７及び図８の例において、ＵＥが自身のＰＵＣＣＨ送信が他のＵＥのＰＵＳＣＨ送信と同時に起こるかを知らない（知らなくてよい）こともまた指摘するに値する。言い換えると、上の提案２及び５は、ＰＵＣＣＨを送信するＵＥの視点から等価である。
【００９２】
［提案１４：ＵＥは先行するサブフレームの末尾ではなくＵＬサブフレームの冒頭においてＵＬ  ＬＢＴを実行する］
Ｒｅｌ−１３  ＬＡＡにおいて、ｅＮＢがＤＬサブフレームの開始に先立ってＤＬ  ＬＢＴを実行すること、及びＤＬバーストの最後のＰＤＳＣＨサブフレームを短縮して後続のＬＢＴのための余地を空けることが決定された。同様に、ＵＥの最後のＵＬ送信（ＰＵＳＣＨ又はＰＵＣＣＨ）を短縮することを考えることができるであろう。すると、ＵＥもまた、そのＵＬサブフレームに先立ってＵＬ  ＬＢＴを実行すべきである。しかしながら、このアプローチは、有意な欠点を有する：ｅＮＢが後続のサブフレームもまたＵＬサブフレームとなるのか（上の議論参照）を決定するのみならず、それが同一のＵＥへ割り当てられるのか又は他のＵＥへ割り当てられるのかをも決定することを要する。そうであれば、現時点のサブフレームがそれらサブフレーム全体にわたることができ、そうでなければ、現時点のサブフレームは短縮されなければならない。そうした“先を見ること（look-ahead）”は、重い処理であり、スケジューリング遅延を増加させる。次に、ｅＮＢがＰＵＣＣＨを送信しようとする自身のＵＥのうちの１つに対してＬＢＴを勝ち得るチャンスを有することが望ましいはずである。これら理由のために、本開示は、先行するサブフレームの末尾よりもむしろＵＬサブフレームの冒頭においてＵＬ  ＬＢＴを実行することを提案する。
【００９３】
［提案１５：ｅＮＢが短縮ＤＬサブフレームを指し示す場合、ＵＥは仕掛かり中のＨＡ
ＲＱフィードバック（及び恐らくは他のＵＣＩ）をｓＰＵＣＣＨ上で送信する］
本開示においてこれまでに、フィードバックバンドリングの概念が紹介された。図７の例では、ＵＥは自身のＨＡＲＱフィードバックをできる限り早く（即ち、ｎ＋４）提供しており、これはレイテンシの点で望ましい。いずれにしろサブフレームが他のＵＥのＰＵＳＣＨ送信のために使用される場合、即座のＨＡＲＱフィードバックに起因する追加的なオーバヘッドは無視できるほどである。しかしながら、ｅＮＢが中間的なサブフレームを必要としない場合、それらを空白のまま残し及びＵＥに単一のＰＵＣＣＨ送信内にＨＡＲＱフィードバックをバンドリングさせることが望ましいであろう。
【００９４】
図９は、ここで説明される手段の一実施形態に係るバンドリングされるＰＵＣＣＨ送信を例示している。バンドリングは特殊ケースであると考えられることから、ｅＮＢがＤＬ割り当てにおいてＵＥへＨＡＲＱフィードバックを先延ばしすることを命令することが提案される。図９の例では、最初の３つのダウンリンクサブフレームにおいてその標識が提供されており、よって、ＵＥはサブフレーム５、６及び７におけるＰＵＣＣＨを省略する。サブフレームの冒頭において、ＵＥは、（ショート）ＬＢＴを実行し、４つ全てのＤＬ  ＨＡＲＱプロセスについて仕掛かり中のＨＡＲＱフィードバックを送信する。
【００９５】
今日、ユーザトラフィックはＤＬに偏重している。よって、ｅＮＢがＵＬサブフレームよりも多くのＤＬサブフレームをスケジューリングしようとする機会が多いであろう。ＰＵＣＣＨのために複数のサブフレームの全体を費やすことは、望ましくないオーバヘッドを生み出すはずである。従って、これまでにここで説明したロングＰＵＣＣＨに加えて、ショートＰＵＣＣＨを提供することが提案される。このｓＰＵＣＣＨは、図１０に示したように、短縮されるＤＬサブフレームの末尾に現れ得る。
【００９６】
図１０は、ここでの主題の一実施形態に係る、短縮されたＤＬサブフレームの末尾にｓＰＵＣＣＨが位置する例を示している。サブフレーム１、２、３及び５、６、７は、ＵＥにそのＨＡＲＱフィードバックを先延ばしすることを命令する。サブフレーム４及び８における割り当てはこの標識を有さず、結果として、ＵＥはサブフレーム８において（サブフレーム１〜４についてのＨＡＲＱフィードバックを反映する）ＵＣＩの送信を、サブフレーム１２において（サブフレーム５〜８についてのＨＡＲＱフィードバックを反映する）ＵＣＩの送信を試行する。ＵＥは、これらサブフレームが空白であることを見出した場合、又はそれらサブフレームのいずれかについてＰＵＳＣＨグラントを受信した場合、以前の段落において説明したようにＵＣＩフィードバックを提供したであろう。しかし、この例では、ｅＮＢは、これらサブフレームを主にＤＬデータ転送のために使用することを決定した。サブフレーム７及び１１では、ｅＮＢは、ＰＤＣＣＨブロードキャストシグナリングを介して全てのＵＥへ、サブフレーム８及び１２が短縮されることになることを通知する。仕掛かり中のＨＡＲＱフィードバックを有するＵＥは、よって、そのフィードバックをｓＰＵＣＣＨ上で送信することになる。
【００９７】
よって、本開示は、ｅＮＢが短縮ＤＬサブフレームを指し示す場合に、ＵＥがｓＰＵＣＣＨ上で仕掛かり中のＨＡＲＱフィードバック（及び恐らくは他のＵＣＩ）を送信し得ることを提案する。
【００９８】
［提案１６：ＵＥは、ｓＰＵＣＣＨの送信に先立ってＬＢＴを実行しなくてよい］
ＵＣＩは純粋に制御シグナリングであること、及びそれがｅＮＢによるＤＬ送信のすぐ後に続くことから、ＵＥは、その送信に先立っていかなるＬＢＴをも実行しない。当然ながら、ｅＮＢがそのＤＬバーストの冒頭でＬＢＴを実行しなければならない。
【００９９】
［提案１７：ＵＥは、受信されるＤＬ割り当てと共に無線リソース制御（ＲＲＣ）構成に基づいて、ｓＰＵＣＣＨリソースを判定する（ＰＵＣＣＨと同様）］
ｓＰＵＣＣＨに続くサブフレームがＰＵＳＣＨのためにスケジューリングされる場合、それらＵＥは、そのＵＬサブフレームの冒頭において（ショート）ＬＢＴを実行することになる。ｅＮＢは、ｓＰＵＣＣＨの後に続けてＰＤＳＣＨ送信を意図している場合、短いギャップの後にそれを行い得る。これは、ｓＰＵＣＣＨの末尾において起きるべきである。上で言及したように、ｅＮＢは、それによりチャネルを取り戻すことになり、ＵＥが後続のサブフレームにおいて通常のＰＵＣＣＨを送信することを防止し得る。
【０１００】
ＰＵＣＣＨと同様、ＵＥは、受信されるＤＬ割り当てと共にＲＲＣ構成に基づいて、ｓＰＵＣＣＨリソースを判定する。
【０１０１】
＜Ｄ−ＳＲ＞
［提案１８：ネットワークは、ＲＲＣシグナリングを用いてＤ−ＳＲリソースと共にＵＥを構成し得る］
ＬＴＥでは、ｅＮＢは、典型的には、ＰＵＣＣＨ上のＤ−ＳＲリソースと共にＲＲＣ接続済みのＵＥを構成する。その周期性（例えば、１０、２０、４０サブフレーム）及び実際の時間／周波数リソースは、ＲＲＣを介して準静的に構成される。ＵＥの空のＰＤＣＰ（Packet  Data  Convergence  Protocol）キューへ上位レイヤからデータ（ＩＰパケット）が到着すると、バッファステータスレポート（ＢＳＲ）がトリガされる。ＵＥは、ＢＳＲを送信するための有効なＵＬグラントを有しない場合、次のＤ−ＳＲ機会においてＰＵＣＣＨを用いてＤ−ＳＲを送信する。同じ原理が、ＬＴＥの未ライセンススタンドアローンにも適用され得るであろう。但し、ＵＥは、ＰＵＣＣＨ上のＤ−ＳＲの送信に先立ってＬＢＴを実行するものと想定され得る。
【０１０２】
［提案１９：ＵＥは、ＬＢＴ成功後にＰＵＣＣＨ上のそれら機会においてＤ−ＳＲを送信し得る］
図１１は、ここで説明される主題の一実施形態に係る４サブフレームごとのＤ−ＳＲ機会と共にＵＥが構成される例を描いている。ｅＮＢと接続しているＵＥのどれもデータをアクティブに送信し又は受信していない時には、ｅＮＢは、ＤＬ送信を最小化し（ＤＲＳのみ）、ほとんどのサブフレームは空白となる。この例では、ＵＥは、図示した３番目のＤ−ＳＲ機会においてＤ−ＳＲの送信を試行し、そのサブフレームの冒頭での成功裏のＬＢＴの後にそれを行うことに成功する。
【０１０３】
［提案２０：サブフレームが短縮ＤＬサブフレームであることをｅＮＢがアナウンスした場合に、ＵＥはｓＰＵＣＣＨ上でそれら機会においてＤ−ＳＲを送信し得る］
一旦チャネルがＵＬ又はＤＬデータ送信により占有されると、Ｄ−ＳＲに先立つＵＥによるＬＢＴは、進行中のＰＤＳＣＨ／ＰＵＳＣＨデータバーストに起因して失敗する可能性が高い。しかしながら、一見すると問題のように見えるのは、実際には望ましい特性である：ｅＮＢは、自身のＵＥよりもアグレッシブな（Ｗｉ−Ｆｉに対しては依然としてフェアな）ＬＢＴ構成を用いることにより、データが利用可能になるとすぐに、チャネルを捕捉し及び効率的にＰＤＳＣＨ／ＰＵＳＣＨをスケジューリングすることができる。ＵＥがｅＮＢへ利用可能なデータについて通知できることを保証するために、ｅＮＢは、ＵＥのＤ−ＳＲ機会のうちの少なくともいくつかを短縮ＤＬサブフレーム（shortened  DL  subframes）として宣言するか、又はそれらを空白のまま残すべきである。図１１のシーケンスの後半部分に示したように、ＵＥは、Ｄ−ＳＲ（及びＨＡＲＱフィードバック）を送信するためにそれら機会を使用するであろう。
【０１０４】
ＵＥのＰＵＳＣＨリソースへＨＡＲＱフィードバックを多重化する必要性が存在する一方で、Ｄ−ＳＲについてはそれをする必要がない。その理由は、有効なＵＬグラントを有するＵＥがＰＵＳＣＨ上で送信されるＭＡＣ  ＰＤＵ（Protocol  Data  Unit）の内部に（より詳細な）バッファステータスレポートを含めることになるからである。
【０１０５】
＜ＣＳＩ＞
ＨＡＲＱフィードバック及びＤ−ＳＲ以外では、ＰＵＣＣＨはＣＳＩをも搬送する。ＬＴＥでは、それはＰＵＣＣＨへ及びＰＵＳＣＨへマッピングされ得る。
【０１０６】
［提案２１：ベースラインとして、非周期的なＣＳＩフィードバックのみがサポートされる。それはｅＮＢにより提供されるＵＬグラントに従ってＰＵＳＣＨへマッピングされる］
“物理レイヤ上のＰＵＣＣＨの実現”との見出しを付した上のセクションにおいて議論したように、非周期的なＣＳＩレポーティングは重要であると考えられる。ＬＴＥと同様に、非周期的なＣＳＩは、（ＵＬユーザデータの有無によらず）ＰＵＳＣＨへマッピングされる。従って、未ライセンススタンドアローンＬＴＥについて、この原理に従うことが提案される。
【０１０７】
図１２Ａ及び図１２Ｂは、本開示の実施形態が実装され得るセルラー通信ネットワークの例を示している。図１２Ａ及び図１２Ｂに示した例示的な実施形態は、セルラー通信ネットワーク１０（ここでは通信システムともいう）において実装される。図１２Ａの例では、セルラー通信ネットワーク１０は、基地局１２（例えば、ＬＴＥの専門用語におけるｅＮＢ）を含み、基地局１２は、ライセンス済み周波数スペクトル内のキャリアｆ１上で動作するセル１４、及び未ライセンス周波数スペクトル（例えば、５ギガヘルツ（ＧＨｚ）周波数スペクトル）内のキャリアｆ２上で動作するセル１６へサービスする。１つの例示的なＬＡＡ方式によれば、セル１４は、ワイヤレスデバイス１８（例えば、ＬＴＥ  ＵＥ）のＰＣｅｌｌとして構成され、セル１６は、ＬＡＡのためのＣＡ方式に従ってワイヤレスデバイス１８のＳＣｅｌｌとして構成される。そのため、ワイヤレスデバイス１８を基準とすると、セル１４はワイヤレスデバイス１８のＰＣｅｌｌ１４として言及され、セル１６はワイヤレスデバイス１８のＳＣｅｌｌ１６として、より正確にはＬＡＡ  ＳＣｅｌｌ１６として言及される。
【０１０８】
図１２Ｂでは、セル１４及び１６は、別個の基地局１２−１及び１２−２によってそれぞれサービスされる。この点において、セル１６は、スタンドアローンＬＡＡセル、又はワイヤレスデバイス１８に関してデュアルコネクティビティ方式に従って利用されるＬＡＡセルであり得る（基地局１２−１及び１２−２は、理想的でないバックホールリンクを介して接続される）。基地局１２−１及び１２−２は、コアネットワーク２０（例えば、ＥＰＣ（Evolved  Packet  Core））へ通信可能に接続され、いくつかの実施形態において、基地局−基地局インタフェース（例えば、ＬＴＥにおけるＸ２インタフェース）を介するか又はコアネットワーク２０を介するかのいずれかで互いに通信し得る。
【０１０９】
図１３は、本開示のいくつかの実施形態に係る、上の提案３を実装するための基地局１２−１（又は基地局１２−２）及びワイヤレスデバイス１８の動作を例示している。図示したように、非同期ＨＡＲＱを利用する場合、ワイヤレスデバイス１８は、ＬＡＡセル上の具体的なＵＬ  ＨＡＲＱプロセスについてＵＬ送信信号を送信する（ステップ１００）。ワイヤレスデバイス１８は、そのＵＬ送信が成功したものと仮定し、そのため、ＵＬ  ＨＡＲＱプロセスについてローカルで維持されるステータスをＡＣＫへ設定する（ステップ１０２）。ワイヤレスデバイス１８は、ＵＬ  ＨＡＲＱプロセスに対応する基地局１２−１（又は１２−２）からの（ＮＤＩの切り替えられていない）後続のＵＬグラントを受信してもしなくてもよい（ステップ１０４）。いくつかの実施形態では、ＵＬグラント内のＨＡＲＱプロセスインデックスフィールドにおいて、ＵＬ  ＨＡＲＱプロセスインデックスが指し示される。ワイヤレスデバイス１８は、ＵＬ  ＨＡＲＱプロセスについての対応するＵＬグラントの受信に応じて、当該ＨＡＲＱプロセスのためのＨＡＲＱ再送を実行するのみである（ステップ１０６）。
【０１１０】
図１４は、本開示のいくつかの実施形態に係る、上の提案４〜７を実装するためのワイヤレスデバイス１８の動作を例示するフローチャートである。図示したように、ワイヤレスデバイス１８は、ワイヤレスデバイス１８があるサブフレームにおいてＬＡＡセル上の有効なＵＬグラントを有するかを判定する（ステップ２００）。有効なＵＬグラントを有しない場合、ワイヤレスデバイス１８は、ＬＡＡセル上の有効なＵＬグラントのモニタリングを継続する。ワイヤレスデバイス１８は、そのサブフレームにおいてＬＡＡセル上の有効なＵＬグラントを有する場合、対応するＨＡＲＱプロセスについてＵＬ  ＨＡＲＱフィードバックタイマを開始する（ステップ２０２）。次いで、ワイヤレスデバイス１８は、そのＨＡＲＱプロセスについてアップリンクＨＡＲＱフィードバックタイマの満了をモニタリングする（ステップ２０４）。一旦ＵＬ  ＨＡＲＱフィードバックタイマが満了すると、この例では、ワイヤレスデバイス１８は、対応するＤＲＸ再送タイマを開始し、ＤＲＸ再送タイマが稼動している限りＤＲＸアクティブ時間のままでいる（ステップ２０６及び２０８）。なお、図１４はＵＬ  ＨＡＲＱフィードバックタイマ及びＤＲＸ再送タイマの双方を利用しているものの、代替的にプロセスは２つのタイマのうちの一方のみを使用してもよく、例えばＵＬ  ＨＡＲＱフィードバックタイマのみを使用してもよい（そのケースでは、ＵＬ  ＨＡＲＱフィードバックタイマの満了に応じていかなる所望のアクションが行われてもよく、そのアクションはＤＲＸ再送タイマの開始に限られない）。
【０１１１】
図１５は、本開示のいくつかの実施形態に係る、上の提案８又は９を実装するための基地局１２−１（又は基地局１２−２）及びワイヤレスデバイス１８の動作を例示している。図示したように、いくつかの実施形態において、基地局１２−１（又は基地局１２−２）は、ＵＣＩについてワイヤレスデバイス１８によりＨＡＲＱフィードバックのバンドリングが実行されるべきかを制御するためのフィードバック制御情報をワイヤレスデバイス１８へ送信する（ステップ３００）。フィードバック制御情報は、ＵＣＩにおいていくつのＨＡＲＱフィードバックをワイヤレスデバイス１８がバンドリングすべきかをも指し示してよい。破線により示されているように、ステップ３００はオプション的である。基地局１２−１（又は基地局１２−２）は、１つ以上のＤＬ  ＨＡＲＱプロセスについて、ＬＡＡ上でワイヤレスデバイス１８へ１つ以上のＤＬ送信信号を送信する（ステップ３０２）。ある時点において、ワイヤレスデバイス１８は、１つ以上のＤＬ  ＨＡＲＱプロセスのＤＬ  ＨＡＲＱプロセスＩＤを、例えば明示的に又はビットマップとして収容する（（バンドリングされる）ＨＡＲＱフィードバックを含む）ＵＣＩを送信する（ステップ３０４）。
【０１１２】
図１６は、本開示のいくつかの実施形態に係る、上の提案１１を実装するためのワイヤレスデバイス１８の動作を例示するフローチャートである。図示したように、ワイヤレスデバイス１８は、あるサブフレームにおいてＬＡＡセル上でワイヤレスデバイス１８が有効なＵＬグラントを有するかを判定する（ステップ４００）。ワイヤレスデバイス１８が有効なＵＬグラントを有しない場合、この例では処理が終了する。ワイヤレスデバイス１８は、そのサブフレームにおいてＬＡＡセル上で有効なＵＬグラントを有する場合、仕掛かり中のＨＡＲＱフィードバック（及び恐らくは他のＵＣＩ）をＰＵＳＣＨ上へ多重化する（ステップ４０２）。
【０１１３】
図１７は、本開示のいくつかの実施形態に係る、上の提案１２を実装するためのワイヤレスデバイス１８の動作を例示するフローチャートである。図示したように、ワイヤレスデバイス１８は、あるサブフレームにおいてＬＡＡセル上でワイヤレスデバイス１８が有効なＵＬグラントを有するかを判定する（ステップ５００）。ワイヤレスデバイス１８が有効なＵＬグラントを有する場合、この例では処理が終了する。ワイヤレスデバイス１８は、そのサブフレームにおいてＬＡＡセル上で有効なＵＬグラントを有しない場合、仕掛かり中のＨＡＲＱフィードバックを、成功裏のショートＬＢＴの後に（ロング）ＰＵＣＣ
Ｈ上で送信する（ステップ５０２）。
【０１１４】
なお、図１６及び図１７の処理は、ワイヤレスデバイス１８が、有効なＵＬグラントが存在する場合には仕掛かり中のＨＡＲＱフィードバック（及び恐らくは他のＵＣＩ）をＰＵＳＣＨ上へ多重化する一方、有効なＵＬグラントが存在しない場合には仕掛かり中のＨＡＲＱフィードバックをショートＬＢＴ成功後に（ロング）ＰＵＣＣＨ上で送信するという形で、併せて利用されてもよい。
【０１１５】
図１８は、本開示のいくつかの実施形態に係る、上の提案１３を実装するための基地局１２−１（又は基地局１２−２）及びワイヤレスデバイス１８の動作を例示している。図示したように、いくつかの実施形態において、基地局１２−１（又は基地局１２−２）は、ＬＡＡセルについてのＵＬグラント又はＤＬ割り当てをワイヤレスデバイス１８へ送信する（ステップ６００）。ワイヤレスデバイス１８は、（１）ワイヤレスデバイス１８が先行するサブフレームにおいてＵＬ送信（ＰＵＣＣＨ又はＰＵＳＣＨ）を実行した、且つ（２）基地局１２−１（又は基地局１２−２）がＵＬグラント（ＰＵＳＣＨ向け）又はＤＬ割り当て（ＰＵＣＣＨ向け）においてＬＡＡセルについてＬＢＴのスキップを明示的に許可した、の双方の場合にＬＡＡセルについてＵＬ  ＬＢＴをスキップする（ステップ６０２）。双方の条件が真であるものとすると、ワイヤレスデバイス１８は、ＬＢＴをスキップして、ＬＡＡセル上でＵＬ送信を実行する（ステップ６０４）。
【０１１６】
図１９は、本開示のいくつかの実施形態に係る、上の提案１５〜１７のうちのいくつか又は全てを実装するための基地局１２−１（又は基地局１２−２）及びワイヤレスデバイス１８の動作を例示している。図示したように、基地局１２−１（又は基地局１２−２）は、ＬＡＡセル上のサブフレームについてのＤＬ割り当てと、そのサブフレームが短縮ＤＬサブフレームであるという標識とを、ワイヤレスデバイス１８へ送信する（ステップ７００）。（破線の矢印で示されているように）オプションとして、ワイヤレスデバイス１８は、例えば受信されるＤＬ割り当てと共にＲＲＣ構成に基づいて、ＨＡＲＱフィードバックについて利用すべきｓＰＵＣＣＨリソースを判定する（ステップ７０２）。ワイヤレスデバイス１８は、短縮ＤＬサブフレームの標識の受信後に、ｓＰＵＣＣＨ上で（例えば、判定したｓＰＵＣＣＨリソースを用いて）、仕掛かり中のＨＡＲＱフィードバック（及び恐らくは他のＵＣＩ）を送信する（ステップ７０４）。
【０１１７】
図２０は、本開示のいくつかの実施形態に係る、上の提案１８〜２０のうちのいくつか又は全てを実装するための基地局１２−１（又は基地局１２−２）及びワイヤレスデバイス１８の動作を例示している。図示したように、基地局１２−１（又は基地局１２−２）は、例えばＲＲＣシグナリングを用いて、ワイヤレスデバイス１８をＤ−ＳＲリソースと共に構成する（ステップ８００）。ワイヤレスデバイス１８は、構成されたＤ−ＳＲリソースを利用する（ステップ８０２）。より具体的には、ワイヤレスデバイス１８は、ＬＢＴ成功後に、ＰＵＣＣＨ上のそれら機会においてＤ−ＳＲを送信してもよく、及び／又は、基地局１２−１（又は１２−２）がそのサブフレームを短縮ＤＬサブフレームであるとアナウンスした場合にｓＰＵＣＣＨ上のそれら機会においてＤ−ＳＲを送信してもよい。
【０１１８】
図２１は、本開示のいくつかの実施形態に係る基地局１２の概略図である。なお、この議論は、基地局１２−１及び１２−２に等しく適用可能である。基地局１２は、ＬＴＥ基地局（例えば、ｅＮＢ若しくはＰＣｅｌｌ基地局）、又はワイヤレスデバイス１８（ＬＴＥでは、ＵＥであり得る）とワイヤレスに通信可能な他のタイプの基地局（例えば、未ライセンススペクトルで動作するＳＣｅｌｌ無線局）であり得る。基地局１２は、送受信機２２、１つ以上のプロセッサ２４（例えば、１つ以上のＣＰＵ（Central  Processing  Units）、１つ以上のＡＳＩＣ（Application  Specific  Integrated  Circuits）及び／又は１つ以上のＦＰＧＡ（Field  Programmable  Gate  Arrays）など）、メモリ２６並
びにネットワークインタフェース２８を含む。１つ以上の送信機及び１つ以上の受信機を含み得る送受信機２２は、基地局１２がワイヤレス信号を送受信することを可能にする。プロセッサ２４は、例えば送受信機２２を介してワイヤレスに受信される信号に基づいて、メモリ２６内に記憶される命令を実行することができる。具体的には、いくつかの実施形態において、ここで説明した基地局１２の機能性は、メモリ２６内に記憶されるソフトウェアで実装され、プロセッサ２４により実行される。ネットワークインタフェース２８は、ワイヤレスリンクからの信号の送受信など、基地局１２がコアネットワークとインタラクションすることを可能にする。基地局１２は、１つ以上のワイヤレスデバイス１８とワイヤレスに通信することができる。
【０１１９】
いくつかの実施形態において、少なくとも１つのプロセッサ２４により実行された場合に、当該少なくとも１つのプロセッサ２４に、ここで説明した実施形態のいずれか１つに係る基地局１２（又は基地局１２−１若しくは１２−２）の機能性を遂行させる命令、を含むコンピュータプログラムが提供される。いくつかの実施形態において、上述したコンピュータプログラムプロダクトを収容する担体が提供される。その担体は、電子信号、光信号、無線信号又はコンピュータ読取可能な記憶媒体（例えば、メモリ２６などの、非一時的なコンピュータ読取可能な媒体）のうちの１つである。
【０１２０】
図２２は、本開示のいくつかの他の実施形態に係る基地局１２を例示している。なお、この議論は、基地局１２−１及び１２−２に等しく適用可能である。基地局１２は、各々がソフトウェアで実装される１つ以上のモジュール３０を含む。それらモジュール３０は、ここで説明した実施形態のいずれかに係る基地局１２の機能性を提供するように動作する。
【０１２１】
図２３は、本開示のいくつかの実施形態に係るワイヤレスデバイス１８の概略図である。ワイヤレスデバイス１８は、ライセンス済みスペクトル（例えば、ここで説明した例示的な実施形態ではライセンス済みＬＴＥスペクトル）、未ライセンススペクトル又はその双方からのリソースを用いて、ワイヤレス信号を送受信するように構成される。ワイヤレスデバイス１８は、１つ以上の送信機及び１つ以上の受信機を含む送受信機３２、１つ以上のプロセッサ３４（例えば、１つ以上のＣＰＵ、１つ以上のＡＳＩＣ及び／又は１つ以上のＦＰＧＡなど）並びにメモリ３６を含む。送受信機３２は、ワイヤレスデバイス１８がワイヤレス信号を送受信することを可能にする。プロセッサ３４は、例えば送受信機３２を介してワイヤレスに受信される信号に基づいて、メモリ３６内に記憶される命令を実行することができる。具体的には、いくつかの実施形態において、ここで説明したワイヤレスデバイス１８の機能性は、メモリ３６内に記憶されるソフトウェアで実装され、プロセッサ３４により実行される。
【０１２２】
いくつかの実施形態において、少なくとも１つのプロセッサ３４により実行された場合に、当該少なくとも１つのプロセッサ３４に、ここで説明した実施形態のいずれか１つに係るワイヤレスデバイス１８の機能性を遂行させる命令、を含むコンピュータプログラムが提供される。いくつかの実施形態において、上述したコンピュータプログラムプロダクトを収容する担体が提供される。その担体は、電子信号、光信号、無線信号又はコンピュータ読取可能な記憶媒体（例えば、メモリ３６などの、非一時的なコンピュータ読取可能な媒体）のうちの１つである。
【０１２３】
図２４は、本開示のいくつかの他の実施形態に係るワイヤレスデバイス１８を例示している。ワイヤレスデバイス１８は、各々がソフトウェアで実装される１つ以上のモジュール３８を含む。それらモジュール３８は、ここで説明した実施形態のいずれかに係るワイヤレスデバイス１８の機能性を提供するように動作する。
【０１２４】
図２５は、本開示のいくつかの実施形態に係る、プライマリサービングセル（ＰＳＣ）及びセカンダリサービングセル（ＳＳＣ）におけるワイヤレスデバイスの動作を例示している。図２５に例示した実施形態において、プライマリサービングセル１２−１及びＳＳＣ１２−２を有するネットワークにおいて動作しているワイヤレスデバイス１８は、ＰＳＣ１２−１からＤＬ送信を受信する（ステップ９００）。ＰＳＣからのＤＬ送信の受信への応答として、ワイヤレスデバイス１８は、ＰＳＣへＨＡＲＱフィードバックを提供する（ステップ９０２）。ワイヤレスデバイス１８は、ＳＳＣ１２−２からＤＬ送信を受信し（ステップ９０４）、ＰＳＣの代わりにＳＳＣへＨＡＲＱフィードバックを提供することにより応答する（ステップ９０６）。
【０１２５】
図２６は、本開示のいくつかの実施形態に従って、ＵＬサブフレームの直前のサブフレームの末尾でのＬＢＴ動作（網掛け部分）の実行に対し、ＵＬサブフレームの冒頭でのＬＢＴ動作の実行を例示している。
【０１２６】
本開示を通じて以下の頭字語が使用されているかもしれない。
・  μｓ              Microsecond
・  ３ＧＰＰ          Third  Generation  Partnership  Project
・  ５Ｇ              Fifth  Generation
・  ＡＣＫ            Acknowledgement
・  ＡＰ              Access  Point
・  ＡＳＩＣ          Application  Specific  Integrated  Circuit
・  ＢＳＲ            Buffer  Status  Report
・  ＣＡ              Carrier  Aggregation
・  ＣＣ              Component  Carrier
・  ＣＣＡ            Clear  Channel  Assessment
・  ＣＣＡ−ＥＤ      Clear  Channel  Assessment  Energy  Detection
・  ＣＦＩ            Control  Format  Indicator
・  ＣＩＦ            Carrier  Indicator  Field
・  ＣＰＵ            Central  Processing  Unit
・  ＣＲＣ            Cyclic  Redundancy  Check
・  ＣＲＳ            Cell  Specific  Reference  Symbol
・  ＣＳＩ            Channel  State  Information
・  ＣＳＭＡ／ＣＡ    Carrier  Sense  Multiple  Access  with  Collision  Avoidance
・  ＤＣＩ            Downlink  Control  Information
・  ＤＦＴ            Discrete  Fourier  Transform
・  ＤＬ              Downlink
・  ＤＭＲＳ          Demodulation  Reference  Signal
・  ＤＲＳ            Dedicated  Reference  Signal
・  ＤＲＸ            Discontinuous  Reception
・  Ｄ−ＳＲ          Dedicated  Scheduling  Request
・  ｅＮＢ            Enhanced  or  Evolved  Node  B
・  ＥＰＣ            Evolved  Packet  Core
・  ＥＰＤＣＣＨ      Enhanced  Physical  Downlink  Control  Channel
・  ＦＤＭＡ          Frequency  Division  Multiple  Access
・  ＦＰＧＡ          Field  Programmable  Gate  Array
・  ＧＨｚ            Gigahertz
・  ＨＡＲＱ          Hybrid  Automatic  Repeat  Request
・  ＩＤ              Identifier
・  ＩＰ              Internet  Protocol
・  ＬＡＡ            License  Assisted  Access
・  ＬＢＴ            Listen-Before-Talk
・  ＬＴＥ            Long  Term  Evolution
・  ＬＴＥ−Ｕ        Long  Term  Evolution  in  Unlicensed  Spectrum
・  ＭＡＣ            Medium  Access  Control
・  ＭＣＳ            Modulation  and  Coding  Scheme
・  ＭＨｚ            Megahertz
・  ｍｓ              Millisecond
・  ＭＴＣ            Machine  Type  Communication
・  ＮＡＣＫ          Negative  Acknowledgment
・  ＮＤＩ            New  Data  Indicator
・  ＯＣＣ            Orthogonal  Cover  Code
・  ＯＦＤＭ          Orthogonal  Frequency  Division  Multiplexing
・  ＰＣｅｌｌ        Primary  Cell
・  ＰＤＣＣＨ        Physical  Downlink  Control  Channel
・  ＰＤＣＰ          Packet  Data  Convergence  Protocol
・  ＰＤＳＣＨ        Physical  Downlink  Shared  Channel
・  ＰＤＵ            Protocol  Data  Unit
・  ＰＨＩＣＨ        Physical  Hybrid  Automatic  Repeat  Request  Indicator  Channel
・  ＰＳＣ            Primary  Serving  Cell
・  ＰＵＣＣＨ        Physical  Uplink  Control  Channel
・  ＰＵＳＣＨ        Physical  Uplink  Shared  Channel
・  ＲＥ              
・  Ｒｅｌ−ｎ        Release  n
・  ＲＲＣ            Radio  Resource  Control
・  ＲＴＴ            Round  Trip  Time
・  ＳＣｅｌｌ        Secondary  Cell
・  ＳＣ−ＦＤＭＡ    Single  Carrier  Frequency  Division  Multiple  Access
・  ＳＩ              Study  Item
・  ｓＰＵＣＣＨ      Short  Physical  Uplink  Control  Channel
・  ＳＲ              Scheduling  Request
・  ＳＲＳ            Sounding  Reference  Signal
・  ＳＳＣ            Second  Serving  Cell
・  ＴＢＣＣ          Tail  Biting  Convolutional  Code
・  ＴＤＤ            Time  Division  Duplexing
・  ＴＲ              Technical  Report
・  ＴＴＩ            Transmit  Time  Interval
・  ＵＣＩ            Uplink  Control  Information
・  ＵＥ              User  Equipment
・  ＵＬ              Uplink
・  ＵＬ−ＳＣＨ      Uplink  Shared  Channel
・  ＷＬＡＮ          Wireless  Local  Area  Network
【０１２７】
当業者は、本開示の実施形態に対する改善及び修正を認識するであろう。全てのそうした改善及び修正は、ここで開示した概念及び後続の特許請求の範囲のスコープの範囲内であるものと見なされる。
【図１Ａ】
2019208229.tif 000003
【図１Ｂ】
2019208229.tif 000004
【図１Ｃ】
2019208229.tif 000005
【図２】
2019208229.tif 000006
【図３】
2019208229.tif 000007
【図４Ａ】
2019208229.tif 000008
【図４Ｂ】
2019208229.tif 000009
【図５Ａ】
2019208229.tif 000010
【図５Ｂ】
2019208229.tif 000011
【図６】
2019208229.tif 000012
【図７】
2019208229.tif 000013
【図８】
2019208229.tif 000014
【図９】
2019208229.tif 000015
【図１０】
2019208229.tif 000016
【図１１】
2019208229.tif 000017
【図１２Ａ】
2019208229.tif 000018
【図１２Ｂ】
2019208229.tif 000019
【図１３】
2019208229.tif 000020
【図１４】
2019208229.tif 000021
【図１５】
2019208229.tif 000022
【図１６】
2019208229.tif 000023
【図１７】
2019208229.tif 000024
【図１８】
2019208229.tif 000025
【図１９】
2019208229.tif 000026
【図２０】
2019208229.tif 000027
【図２１】
2019208229.tif 000028
【図２２】
2019208229.tif 000029
【図２３】
2019208229.tif 000030
【図２４】
2019208229.tif 000031
【図２５】
2019208229.tif 000032
【図２６】
2019208229.tif 000033
【手続補正書】
【提出日】令和1年7月30日(2019.7.30)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ワイヤレスデバイスの動作の方法であって、
前記ワイヤレスデバイスが未ライセンス周波数スペクトルにおいて動作するセル上のサブフレームにおいて有効なアップリンク（ＵＬ）グラントを有するかを判定することと、
前記ワイヤレスデバイスが前記セル上の前記サブフレームにおいて有効なＵＬグラントを有するとの判定に応じて、ＵＬハイブリッド自動再送要求（ＨＡＲＱ）フィードバックタイマを開始することと、
前記ＵＬ  ＨＡＲＱフィードバックタイマの満了に応じて、不連続受信（ＤＲＸ）再送タイマを開始することと、
を含む方法。
【請求項２】
前記ワイヤレスデバイスが対応するＵＬ送信を実行する場合、又は前記対応するＵＬ送信がＬＢＴ（Listen-Before-Talk）方式によりブロックされる場合、の双方において前記ＵＬ  ＨＡＲＱフィードバックタイマを開始すること、を含む、請求項１の方法。
【請求項３】
前記ＤＲＸ再送タイマが稼動している限り、ＤＲＸアクティブ時間のままでいること、をさらに含む、請求項１の方法。
【請求項４】
対応するＨＡＲＱバッファのフラッシュに応じて前記ＵＬ  ＨＡＲＱフィードバックタイマを停止すること、をさらに含む、請求項１の方法。
【請求項５】
ＵＬ  ＨＡＲＱプロセスごとに１つのＵＬ  ＨＡＲＱラウンドトリップ時間（ＲＴＴ）タイマ及び１つのＤＲＸ再送タイマが維持される、請求項１の方法。
【請求項６】
ワイヤレスデバイスの動作の方法であって、
未ライセンス周波数スペクトルにおいて動作するセル上でアップリンク制御情報（ＵＣＩ）を送信すること、
を含み、前記ＵＣＩは、
複数のダウンリンク（ＤＬ）ＨＡＲＱプロセスについてのハイブリッド自動再送要求（ＨＡＲＱ）フィードバック情報と、
前記ＤＬ  ＨＡＲＱプロセスを識別する識別子と、
を含み、
前記方法は、前記セルへサービスする基地局から、フィードバック制御情報を受信すること、を含み、前記フィードバック制御情報は、前記ＵＣＩ内の前記ＤＬ  ＨＡＲＱフィードバックのバンドリングが実行されるべきかの標識を含む、
方法。
【請求項７】
前記ＤＬ  ＨＡＲＱプロセスは、明示的な識別子により、又は各ビットが前記ＤＬ  ＨＡＲＱプロセスのうちの１つに対応するビットマップにより識別される、請求項６の方法。
【請求項８】
前記フィードバック制御情報は、前記ワイヤレスデバイスが前記ＵＣＩ内でバンドリングすべきＤＬ  ＨＡＲＱフィードバックの数を指し示す情報をさらに含む、請求項６の方法。
【請求項９】
ワイヤレスデバイスであって、
未ライセンス周波数スペクトルにおいて動作するセル上でアップリンク制御情報（ＵＣＩ）を送信するように全体として構成される、処理回路、メモリ、及び送受信機回路、
を備え、前記ＵＣＩは、
複数のダウンリンク（ＤＬ）ＨＡＲＱプロセスについてのハイブリッド自動再送要求（ＨＡＲＱ）フィードバック情報と、
前記ＤＬ  ＨＡＲＱプロセスを識別する識別子と、
を含み、
前記処理回路、前記メモリ、及び前記送受信機回路は、前記セルへサービスする基地局から、フィードバック制御情報を受信するように全体として構成され、前記フィードバック制御情報は、前記ＵＣＩ内の前記ＤＬ  ＨＡＲＱフィードバックのバンドリングが実行されるべきかの標識を含む、
ワイヤレスデバイス。
【請求項１０】
前記ＤＬ  ＨＡＲＱプロセスは、明示的な識別子により、又は各ビットが前記ＤＬ  ＨＡＲＱプロセスのうちの１つに対応するビットマップにより識別される、請求項９のワイヤレスデバイス。
【請求項１１】
前記フィードバック制御情報は、前記ワイヤレスデバイスが前記ＵＣＩ内でバンドリングすべきＤＬ  ＨＡＲＱフィードバックの数を指し示す情報をさらに含む、請求項９のワイヤレスデバイス。
【外国語明細書】
2019208229000001.pdf