▶ テレフオンアクチーボラゲット エル エム エリクソン（パブル）の特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-09-22
(45)【発行日】2022-10-03
(54)【発明の名称】アップリンクＭＡＣプロトコルの観点
(51)【国際特許分類】
H04W 28/04 20090101AFI20220926BHJP
H04W 52/02 20090101ALI20220926BHJP
H04W 72/12 20090101ALI20220926BHJP
H04W 72/04 20090101ALI20220926BHJP
【ＦＩ】
H04W28/04 110
H04W52/02 111
H04W72/12 150
H04W72/04 136
H04W72/04 137
【請求項の数】
5
【外国語出願】
(21)【出願番号】P 2021016000
(22)【出願日】2021-02-03
(62)【分割の表示】P 2019126377の分割
【原出願日】2016-12-01
(65)【公開番号】P2021083103
(43)【公開日】2021-05-27
【審査請求日】2021-02-17
(31)【優先権主張番号】62/264,075
(32)【優先日】2015-12-07
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】598036300
【氏名又は名称】テレフオンアクチーボラゲット エルエム エリクソン（パブル）
(74)【代理人】
【識別番号】110003281
【氏名又は名称】特許業務法人大塚国際特許事務所
(72)【発明者】
【氏名】ウィーマン、ヘニング
(72)【発明者】
【氏名】サーリン、ヘンリク
(72)【発明者】
【氏名】ヤン、ユ
(72)【発明者】
【氏名】ドラッゲ、オスキャル
(72)【発明者】
【氏名】チェン、ジュン－フ
(72)【発明者】
【氏名】クーラパティ、ハビッシュ
(72)【発明者】
【氏名】バーリストレーム、マティアス
【審査官】松野 吉宏
(56)【参考文献】
【文献】米国特許出願公開第２００９／０１６８７３１（ＵＳ，Ａ１）
【文献】米国特許出願公開第２０１１／０２０５９２８（ＵＳ，Ａ１）
【文献】国際公開第２０１５／０１８０４５（ＷＯ，Ａ１）
【文献】Qualcomm Incorporated，Uplink considerations for LAA-LTE，3GPP TSG-RAN WG2#90 R2-152703，フランス，3GPP，2015年05月16日
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｂ ７／２４ － ７／２６
Ｈ０４Ｗ ４／００ － ９９／００
３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１－４
ＳＡ ＷＧ１－４
ＣＴ ＷＧ１、４
(57)【特許請求の範囲】
【請求項1】
ワイヤレスデバイスの動作の方法であって、前記ワイヤレスデバイスがセル上のサブフレームにおいて有効なアップリンク（ＵＬ）グラントを有するかを判定することと、
前記ワイヤレスデバイスが前記セル上の前記サブフレームにおいて有効なＵＬグラントを有するとの判定に応じて、ＵＬハイブリッド自動再送要求（ＨＡＲＱ）フィードバックタイマを開始することと、
前記ＵＬ ＨＡＲＱフィードバックタイマの満了に応じて、不連続受信（ＤＲＸ）再送タイマを開始することと、
を含む方法。
【請求項2】
前記ワイヤレスデバイスが対応するＵＬ送信を実行する場合、又は前記対応するＵＬ送信がＬＢＴ（Listen-Before-Talk）方式によりブロックされる場合、の双方において前記ＵＬ ＨＡＲＱフィードバックタイマを開始すること、を含む、請求項１に記載の方法。
【請求項3】
前記ＤＲＸ再送タイマが稼動している限り、ＤＲＸアクティブ時間のままでいること、をさらに含む、請求項１に記載の方法。
【請求項4】
対応するＨＡＲＱバッファのフラッシュに応じて前記ＵＬ ＨＡＲＱフィードバックタイマを停止すること、をさらに含む、請求項１に記載の方法。
【請求項5】
ＵＬ ＨＡＲＱプロセスごとに１つのＵＬ ＨＡＲＱラウンドトリップ時間（ＲＴＴ）タイマ及び１つのＤＲＸ再送タイマが維持される、請求項１に記載の方法。
【発明の詳細な説明】
【技術分野】
【0001】
［関連出願］
本出願は、２０１５年１２月７日に提出された仮特許出願第６２／２６４，０７５号の利益を主張し、その開示はここで全体として参照によりここに取り入れられる。
本出願は、２０１５年１２月７日に提出された仮特許出願第６２／２６４，０７５号の利益を主張し、その開示はここで全体として参照によりここに取り入れられる。
【0002】
［技術分野］
本開示は、アップリンクＭＡＣ（Medium Access Control）プロトコルの観点に関連し、即ち、共有アップリンク（ＵＬ）チャネル（例えば、物理アップリンク共有チャネル（ＰＵＳＣＨ））上でデータを送信するための機能性と共に、ＵＬ制御チャネル（例えば、物理アップリンク制御チャネル（ＰＵＣＣＨ））又は共有ＵＬチャネル（例えば、ＰＵＳＣＨ）上での、ハイブリッド自動再送要求（ＨＡＲＱ）確認応答／否定確認応答（ＡＣＫ／ＮＡＣＫ）フィードバック及びスケジューリング要求の送信に関連する。
本開示は、アップリンクＭＡＣ（Medium Access Control）プロトコルの観点に関連し、即ち、共有アップリンク（ＵＬ）チャネル（例えば、物理アップリンク共有チャネル（ＰＵＳＣＨ））上でデータを送信するための機能性と共に、ＵＬ制御チャネル（例えば、物理アップリンク制御チャネル（ＰＵＣＣＨ））又は共有ＵＬチャネル（例えば、ＰＵＳＣＨ）上での、ハイブリッド自動再送要求（ＨＡＲＱ）確認応答／否定確認応答（ＡＣＫ／ＮＡＣＫ）フィードバック及びスケジューリング要求の送信に関連する。
【背景技術】
【0003】
ライセンス支援型アクセス（ＬＡＡ：Licensed Assisted Access）は、３ＧＰＰ（Third Generation Partnership Project）ＬＴＥ（Long Term Evolution）機器が未ライセンスの５ギガヘルツ（ＧＨｚ）無線スペクトルにおいても動作することを促進する。未ライセンスの５ＧＨｚスペクトルは、ライセンス済みスペクトルを補うものとして使用される。デバイスは、ライセンス済みスペクトルにおいて（プライマリセル（ＰＣｅｌｌ）を用いて）接続を行い、及び、未ライセンススペクトルにおいて（セカンダリセル（ＳＣｅｌｌ）を用いて）追加的な送信キャパシティの恩恵を受けるためにキャリアアグリゲーション（ＣＡ）を使用することができる。ライセンス済みスペクトル及び未ライセンススペクトルを統合することに関わる変更を低減するために、ＰＣｅｌｌにおけるＬＴＥフ
レームタイミングがＳＣｅｌｌにおいて同時に使用される。
レームタイミングがＳＣｅｌｌにおいて同時に使用される。
【0004】
しかしながら、規制要件（regulatory requirements）が、事前のチャネルセンシング無く未ライセンススペクトルにおいて送信を行うことを許可しないかもしれない。未ライセンススペクトルは類似の又は非類似のワイヤレス技術の他の無線機と共有されなければならないことから、いわゆるＬＢＴ（listen-before-talk）手続が適用される必要がある。今日、未ライセンスの５ＧＨｚスペクトルは、ＩＥＥＥ（Institute of Electrical and Electronics Engineers）８０２．１１ ＷＬＡＮ（Wireless Local Area Network）標準を実装する機器により主として使用されている。この標準は、そのマーケティングブランド“Ｗｉ－Ｆｉ”の下で知られている。多くの領域において、未ライセンススペクトルにおける単一の送信バーストの最大時間長に関する（４ミリ秒（ｍｓ）又は１０ｍｓといった）制約もまた存在する。
【0005】
１． ＬＴＥ
図１Ａは、基本的なＬＴＥダウンリンク物理リソースグリッドを示している。ＬＴＥは、ダウンリンクにおいてＯＦＤＭ（Orthogonal Frequency Division Multiplex）を、アップリンク（ＵＬ）においてシングルキャリアＦＤＭＡ（Frequency Division Multiple Access）ともいうＤＦＴ（Discrete Fourier Transform）拡散ＯＦＤＭ（DFT-spread OFDM）を使用する。よって、基本的なＬＴＥのダウンリンク物理リソースを図１Ａに示したような時間－周波数グリッドとして理解することができ、各リソースエレメントは、１つのＯＦＤＭシンボルインターバルの期間中の１本のＯＦＤＭサブキャリアに相当する。各シンボルの時間長は、約７１．４マイクロ秒（μｓ）である。ＵＬサブフレームは、ダウンリンク（ＤＬ）と同じサブキャリア間隔を有し、ＤＬにおけるＯＦＤＭシンボルと同じ数のＳＣ－ＦＤＭＡ（Single Carrier FDMA）シンボルを時間ドメインにおいて有する。
図１Ａは、基本的なＬＴＥダウンリンク物理リソースグリッドを示している。ＬＴＥは、ダウンリンクにおいてＯＦＤＭ（Orthogonal Frequency Division Multiplex）を、アップリンク（ＵＬ）においてシングルキャリアＦＤＭＡ（Frequency Division Multiple Access）ともいうＤＦＴ（Discrete Fourier Transform）拡散ＯＦＤＭ（DFT-spread OFDM）を使用する。よって、基本的なＬＴＥのダウンリンク物理リソースを図１Ａに示したような時間－周波数グリッドとして理解することができ、各リソースエレメントは、１つのＯＦＤＭシンボルインターバルの期間中の１本のＯＦＤＭサブキャリアに相当する。各シンボルの時間長は、約７１．４マイクロ秒（μｓ）である。ＵＬサブフレームは、ダウンリンク（ＤＬ）と同じサブキャリア間隔を有し、ＤＬにおけるＯＦＤＭシンボルと同じ数のＳＣ－ＦＤＭＡ（Single Carrier FDMA）シンボルを時間ドメインにおいて有する。
【0006】
図１Ｂは、ＬＴＥ無線フレームを示している。時間ドメインにおいて、ＬＴＥのＤＬ送信は、１０ｍｓの無線フレームの集合へ編成され、各無線フレームは、図１Ｂに示したように、長さＴSUBFRAME＝１ｍｓで等サイズの１０個のサブフレームからなる。通常のサイクリックプレフィクスについて、１つのサブフレームは、１４個のＯＦＤＭシンボルからなる。サブフレームは、２つの０．５ｍｓスロットへ分割される。通常のサイクリックプレフィクスについて、各スロットは、７個のＯＦＤＭシンボルからなる。そのうえ、ＬＴＥにおけるリソース割り当ては、典型的にはリソースブロック（ＲＢ）の観点で記述され、１リソースブロックは、時間ドメインにおける１つの０．５ｍｓスロット及び周波数ドメインにおける１２本の連続したサブキャリアに相当する。時間方向における２つの隣り合うリソースブロックのペア（１．０ｍｓ）は、リソースブロックペアとして知られている。リソースブロックは、周波数ドメインにおいて、システム帯域幅の一端から０で始まる形で付番される。
【0007】
図１Ｃは、制御信号及びリファレンス信号の位置を示す、一例としてのＬＴＥの（１４個のＯＦＤＭシンボルを伴う）１．０ｍｓサブフレームを示している。ＤＬ送信は動的にスケジューリングされ、即ち、各サブフレームにおいて、基地局は、その時点のＤＬサブフレームにおいてどの端末がデータの送信先であり及びどのリソースブロック上でデータが送信されるかに関する制御情報を送信する。この制御シグナリングは、典型的には、各サブフレーム内の最初から１、２、３又は４個のＯＦＤＭシンボルにおいて送信され、数ｎ＝１、２、３又は４は制御フォーマットインジケータ（ＣＦＩ）として知られている。ＤＬサブフレームは、共通リファレンスシンボルをも含み、共通リファレンスシンボルは、受信機にとって既知であって、例えば制御情報のコヒーレント復調のために使用される。制御としてＣＦＩ＝３個のＯＦＤＭシンボルを伴うＤＬシステムが図１Ｃに示されている。
【0008】
ＬＴＥリリース１１（Ｒｅｌ－１１）以降より、上述したリソース割り当ては、拡張物理ダウンリンク制御チャネル（ＥＰＤＣＣＨ）上でもスケジューリングされ得る。Ｒｅｌ－８からＲｅｌ－１０については、物理ダウンリンク制御チャネル（ＰＤＣＣＨ）のみが利用可能である。図１Ｃに示したリファレンスシンボルは、セル固有リファレンスシンボル（ＣＲＳ）であり、精細な時間及び周波数同期並びに何らかの送信モードについてのチャネル推定を含む複数の機能をサポートするために使用される。
【0009】
１．１ ＰＤＣＣＨ及びＥＰＤＣＣＨ
ＰＤＣＣＨ／ＥＰＤＣＣＨは、スケジューリング決定及び電力制御コマンドなどのダウンリンク制御情報（ＤＣＩ）を搬送する。より具体的には、ＤＣＩは、次を含む：
・ダウンリンクスケジューリング割り当て … 物理ダウンリンク共有チャネル（ＰＤＳＣＨ）リソース標識、トランスポートフォーマット、ハイブリッド自動再送要求（ＨＡＲＱ）情報、及び（該当する場合）空間多重化に関連する制御情報を含む。ＤＬスケジューリング割り当ては、ＤＬスケジューリング割り当てへの応答としてＨＡＲＱ確認応答の送信のために使用される物理アップリンク制御チャネル（ＰＵＣＣＨ）の電力制御のためのコマンドをも含む。
・アップリンクスケジューリンググラント … 物理アップリンク共有チャネル（ＰＵＳＣＨ）リソース標識、トランスポートフォーマット、及びＨＡＲＱ関連情報を含む。アップリンクスケジューリンググラントは、ＰＵＳＣＨの電力制御のためのコマンドをも含む。
・スケジューリング割り当て／グラントに含まれるコマンドを補うものとして、端末のセットのための電力制御コマンド。
ＰＤＣＣＨ／ＥＰＤＣＣＨは、スケジューリング決定及び電力制御コマンドなどのダウンリンク制御情報（ＤＣＩ）を搬送する。より具体的には、ＤＣＩは、次を含む：
・ダウンリンクスケジューリング割り当て … 物理ダウンリンク共有チャネル（ＰＤＳＣＨ）リソース標識、トランスポートフォーマット、ハイブリッド自動再送要求（ＨＡＲＱ）情報、及び（該当する場合）空間多重化に関連する制御情報を含む。ＤＬスケジューリング割り当ては、ＤＬスケジューリング割り当てへの応答としてＨＡＲＱ確認応答の送信のために使用される物理アップリンク制御チャネル（ＰＵＣＣＨ）の電力制御のためのコマンドをも含む。
・アップリンクスケジューリンググラント … 物理アップリンク共有チャネル（ＰＵＳＣＨ）リソース標識、トランスポートフォーマット、及びＨＡＲＱ関連情報を含む。アップリンクスケジューリンググラントは、ＰＵＳＣＨの電力制御のためのコマンドをも含む。
・スケジューリング割り当て／グラントに含まれるコマンドを補うものとして、端末のセットのための電力制御コマンド。
【0010】
１つのＰＤＣＣＨ／ＥＰＤＣＣＨは、上で列挙した情報のグループのうちの１つを含む１つのＤＣＩメッセージを搬送する。複数の端末を同時にスケジューリングすることができ、各端末はＤＬ及びＵＬの双方で同時にスケジューリングされ得ることから、各サブフレーム内で複数のスケジューリングメッセージが送信される可能性があることは間違いない。各スケジューリングメッセージは、別々のＰＤＣＣＨ／ＥＰＤＣＣＨリソース上で送信され、結果として、典型的には、各セル内の各サブフレームの範囲内に複数の同時のＰＤＣＣＨ／ＥＰＤＣＣＨ送信が存在する。さらに、様々な無線チャネル条件をサポートするためにリンク適応を使用することができ、リンク適応では、無線チャネル条件に適合するように（Ｅ）ＰＤＣＣＨ用のリソース使用量を適応させることにより（Ｅ）ＰＤＣＣＨのコードレートが選択される。
【0011】
１．２ ＣＡ
図２は、ＣＡの一例を示している。ＬＴＥ Ｒｅｌ－１０標準は、２０メガヘルツ（ＭＨｚ）よりも大きな帯域幅をサポートする。ＬＴＥ Ｒｅｌ－１０の１つの重要な観点は、ＬＴＥ Ｒｅｌ－８との後方互換性を確保することである。これは、スペクトル互換性を含むべきである。そのことは、２０ＭＨｚよりも広いＬＴＥ Ｒｅｌ－１０キャリアが、ＬＴＥ Ｒｅｌ－８端末にとって複数個のＬＴＥキャリアとして見えるべきであることを示唆するであろう。そうした各キャリアは、コンポーネントキャリア（ＣＣ）として言及され得る。特に、早期のＬＴＥ Ｒｅｌ－１０配備について、ＬＴＥ Ｒｅｌ－１０対応端末の数は、多くのＬＴＥレガシー端末と比較してより少ないであろうと予期することができる。従って、レガシー端末についても、広いキャリアの効率的な使用を保証することが必要とされ、即ち、レガシー端末を広帯域ＬＴＥ Ｒｅｌ－１０キャリアの全ての部分においてスケジューリングし得るようなキャリアを実装可能であることが必要とされる。これを獲得するための単純な手法は、ＣＡの手段によるはずである。ＣＡは、ＬＴＥ Ｒｅｌ－１０端末が、Ｒｅｌ－８キャリアと同じ構造を有するか又は少なくともその可能性を有する複数のＣＣを受信できることを示唆する。図２にＣＡが示されている。ＣＡ対
応型のユーザ機器デバイス（ＵＥ）には、常にアクティブ化されているＰＣｅｌｌと、動的にアクティブ化され又は非アクティブ化され得る１つ以上のＳＣｅｌｌとが割り当てられる。
図２は、ＣＡの一例を示している。ＬＴＥ Ｒｅｌ－１０標準は、２０メガヘルツ（ＭＨｚ）よりも大きな帯域幅をサポートする。ＬＴＥ Ｒｅｌ－１０の１つの重要な観点は、ＬＴＥ Ｒｅｌ－８との後方互換性を確保することである。これは、スペクトル互換性を含むべきである。そのことは、２０ＭＨｚよりも広いＬＴＥ Ｒｅｌ－１０キャリアが、ＬＴＥ Ｒｅｌ－８端末にとって複数個のＬＴＥキャリアとして見えるべきであることを示唆するであろう。そうした各キャリアは、コンポーネントキャリア（ＣＣ）として言及され得る。特に、早期のＬＴＥ Ｒｅｌ－１０配備について、ＬＴＥ Ｒｅｌ－１０対応端末の数は、多くのＬＴＥレガシー端末と比較してより少ないであろうと予期することができる。従って、レガシー端末についても、広いキャリアの効率的な使用を保証することが必要とされ、即ち、レガシー端末を広帯域ＬＴＥ Ｒｅｌ－１０キャリアの全ての部分においてスケジューリングし得るようなキャリアを実装可能であることが必要とされる。これを獲得するための単純な手法は、ＣＡの手段によるはずである。ＣＡは、ＬＴＥ Ｒｅｌ－１０端末が、Ｒｅｌ－８キャリアと同じ構造を有するか又は少なくともその可能性を有する複数のＣＣを受信できることを示唆する。図２にＣＡが示されている。ＣＡ対
応型のユーザ機器デバイス（ＵＥ）には、常にアクティブ化されているＰＣｅｌｌと、動的にアクティブ化され又は非アクティブ化され得る１つ以上のＳＣｅｌｌとが割り当てられる。
【0012】
統合されるコンポーネントキャリアの数と共に個々のＣＣの帯域幅は、ＵＬとＤＬとで異なってよい。対称構成とは、ＤＬにおけるＣＣの数がＵＬにおけるＣＣの数と同一である構成をいう。一方、非対称構成とは、ＣＣの数が異なるケースをいう。セル内で構成されるＣＣの数は、端末に見えるＣＣの数とは異なってもよいことに留意することが重要である。例えば、セルが同数のＵＬ ＣＣ及びＤＬ ＣＣで構成される場合でさえも、端末は、ＵＬ ＣＣよりも多くのＤＬ ＣＣをサポートしてよい。
【0013】
加えて、ＣＡの重要な特徴は、クロスキャリアスケジューリングを実行する能力である。その仕組みは、１つのＣＣ上の（Ｅ）ＰＤＣＣＨが、（Ｅ）ＰＤＣＣＨメッセージの冒頭に挿入される３ビットのＣＩＦ（Carrier Indicator Field）の手段により他のＣＣ上のデータ送信をスケジューリングすることを可能にする。所与のＣＣ上のデータ送信のために、ＵＥは、ただ１つのＣＣ（即ち、同じＣＣであるか又はクロスキャリアスケジューリングを介して異なるＣＣであるかのいずれか）の（Ｅ）ＰＤＣＣＨ上のスケジューリングメッセージを受信することを予期する。（Ｅ）ＰＤＣＣＨからＰＤＳＣＨへの上記マッピングが準静的に構成されてもよい。なお、Ｒｅｌ－１１ではＰＤＳＣＨのクロスサブフレームでのクロスキャリアスケジューリングはサポートされておらず、即ち、具体的なサブフレームでの（Ｅ）ＰＤＣＣＨグラントは、その同一の送信時間インターバル（ＴＴＩ）内のＰＤＳＣＨ割り当てに適用される。
【0014】
２． ＷＬＡＮ
図３は、ＬＢＴの仕組みの概略図である。ＷＬＡＮの典型的な配備では、メディアアクセスのためにＣＳＭＡ／ＣＡ（Carrier Sense Multiple Access with Collision Avoidance）が使用される。チャネルはＣＣＡ（Clear Channel Assessment）を実行するためにセンシングされ、チャネルがアイドルであると宣言される場合にのみ送信が開始される。チャネルがビジーであると宣言される場合には、送信はチャネルがアイドルであると見なされるまで本質的に延期される。同じ周波数を用いる複数のアクセスポイント（ＡＰ）のレンジが重複する場合、レンジ内の他のＡＰとの間の同じ周波数上での送信が検出され得るケースにおいて１つのＡＰに関連する複数の送信が延期されるかもしれない。複数のＡＰが互いにレンジ内にある場合、それらはチャネルを時間的に共用しなければならなくなり、個々のＡＰについてのスループットはひどく劣化し得る。
図３は、ＬＢＴの仕組みの概略図である。ＷＬＡＮの典型的な配備では、メディアアクセスのためにＣＳＭＡ／ＣＡ（Carrier Sense Multiple Access with Collision Avoidance）が使用される。チャネルはＣＣＡ（Clear Channel Assessment）を実行するためにセンシングされ、チャネルがアイドルであると宣言される場合にのみ送信が開始される。チャネルがビジーであると宣言される場合には、送信はチャネルがアイドルであると見なされるまで本質的に延期される。同じ周波数を用いる複数のアクセスポイント（ＡＰ）のレンジが重複する場合、レンジ内の他のＡＰとの間の同じ周波数上での送信が検出され得るケースにおいて１つのＡＰに関連する複数の送信が延期されるかもしれない。複数のＡＰが互いにレンジ内にある場合、それらはチャネルを時間的に共用しなければならなくなり、個々のＡＰについてのスループットはひどく劣化し得る。
【0015】
３． ＬＴＥを用いた未ライセンススペクトルへのＬＡＡ
これまでのところ、ＬＴＥにより使用されるスペクトルは、ＬＴＥにとって専用（即ち、ラインセンス済みスペクトル）である。これは、ＬＴＥシステムが共存の課題に対処することを必要とせず、スペクトル効率を最大化することができるという利点を有する。しかしながら、ＬＴＥに割り当てられたスペクトルは有限であり、そのため、アプリケーション／サービスからのより大きなスループットを求める需要の一層の増加を満たすことができない。従って、３ＧＰＰにおいて、ライセンス済みスペクトルに加えて未ライセンススペクトルを活用するようにＬＴＥを拡張することに関する新たな研究項目が開始された。定義によると、未ライセンススペクトルを、複数の異なる技術によって同時に使用することができる。従って、ＬＴＥは、ＩＥＥＥ８０２．１１（Ｗｉ－Ｆｉ）といった他のシステムとの共存の課題を考慮する必要がある。ライセンス済みスペクトル内と同じやり方で未ライセンススペクトルにおいてＬＴＥを動作させることは、Ｗｉ－Ｆｉの性能を深刻に劣化させかねない。なぜなら、Ｗｉ－Ｆｉは、チャネルが占有されていることを一旦検出すると送信を行わないことになるためである。
これまでのところ、ＬＴＥにより使用されるスペクトルは、ＬＴＥにとって専用（即ち、ラインセンス済みスペクトル）である。これは、ＬＴＥシステムが共存の課題に対処することを必要とせず、スペクトル効率を最大化することができるという利点を有する。しかしながら、ＬＴＥに割り当てられたスペクトルは有限であり、そのため、アプリケーション／サービスからのより大きなスループットを求める需要の一層の増加を満たすことができない。従って、３ＧＰＰにおいて、ライセンス済みスペクトルに加えて未ライセンススペクトルを活用するようにＬＴＥを拡張することに関する新たな研究項目が開始された。定義によると、未ライセンススペクトルを、複数の異なる技術によって同時に使用することができる。従って、ＬＴＥは、ＩＥＥＥ８０２．１１（Ｗｉ－Ｆｉ）といった他のシステムとの共存の課題を考慮する必要がある。ライセンス済みスペクトル内と同じやり方で未ライセンススペクトルにおいてＬＴＥを動作させることは、Ｗｉ－Ｆｉの性能を深刻に劣化させかねない。なぜなら、Ｗｉ－Ｆｉは、チャネルが占有されていることを一旦検出すると送信を行わないことになるためである。
【0016】
そのうえ、未ライセンススペクトルを高い信頼性で利用する１つの手法は、ライセンス済みキャリア上で不可欠な制御信号及びチャネルを送信することである。即ち、ＵＥは、ライセンス済み帯域内のＰＣｅｌｌ及び未ライセンス帯域内の１つ以上のＳＣｅｌｌへ接続される。ここで使用されるところによれば、未ライセンススペクトル内のＳＣｅｌｌは、ＬＡＡ ＳＣｅｌｌとして表記される。クロスキャリアスケジューリングのケースでは、ＬＡＡ ＳＣｅｌｌについてのＰＤＳＣＨ及びＰＵＳＣＨグラントは、ＰＣｅｌｌ上で送信される。
【0017】
未ライセンススペクトルを利用する他の手法は、スタンドアローンＬＡＡセルを利用することである。
【発明の概要】
【0018】
本開示は、アップリンクＭＡＣ（Medium Access Control）プロトコルの観点に関連し、即ち、共有アップリンク（ＵＬ）チャネル（例えば、物理アップリンク共有チャネル（ＰＵＳＣＨ））上でデータを送信するための機能性と共に、ＵＬ制御チャネル（例えば、物理アップリンク制御チャネル（ＰＵＣＣＨ））又は共有ＵＬチャネル（例えば、ＰＵＳＣＨ）上での、ハイブリッド自動再送要求（ＨＡＲＱ）確認応答／否定確認応答（ＡＣＫ／ＮＡＣＫ）フィードバック及びスケジューリング要求の送信に関連する。特に、ライセンス支援型アクセス（ＬＡＡ）セルに関連して、より一般的に言うと未ライセンス周波数スペクトルにおいて動作するセルラー通信ネットワークのセルに関連して、ＭＡＣプロトコルの観点がここで開示される。
【0019】
ある観点によれば、ワイヤレスデバイスの動作の方法は、未ライセンス周波数スペクトルにおいて動作するセル上で、ＵＬ送信を、対応するＵＬ ＨＡＲＱプロセスについて送信することと、上記ＵＬ ＨＡＲＱプロセスについてローカルで維持されるステータスを、上記ＵＬ送信が成功したという仮定に基づいて、“ＡＣＫ”に設定することと、を含む。１つの実施形態において、上記方法は、切り替えられていないＮＤＩ（New Data Indicator）を伴う対応するＵＬグラントの受信に応じてのみ、上記アップリンクＨＡＲＱプロセスについて再送を実行すること、をさらに含む
【0020】
他の観点によれば、ワイヤレスデバイスの動作の方法は、上記ワイヤレスデバイスが未ライセンス周波数スペクトルにおいて動作するセル上のサブフレームにおいて有効なＵＬグラントを有するかを判定することと、上記ワイヤレスデバイスが上記セル上の上記サブフレームにおいて有効なＵＬグラントを有するとの判定に応じて、ＵＬ ＨＡＲＱフィードバックタイマを開始することと、を含む。ある実施形態において、上記ワイヤレスデバイスが対応するＵＬ送信を実行するか、又は上記対応するＵＬ送信がＬＢＴ（Listen-Before-Talk）方式によりブロックされるかによって、上記ＵＬ ＨＡＲＱフィードバックタイマが開始される。ある実施形態において、上記方法は、上記ＵＬ ＨＡＲＱフィードバックタイマの満了に応じて、不連続受信（ＤＲＸ）再送タイマを開始すること、をさらに含む。ある実施形態において、上記方法は、上記ＤＲＸ再送タイマが稼動している限り、ＤＲＸアクティブ時間のままでいること、をさらに含む。ある実施形態において、上記方法は、対応するＨＡＲＱバッファのフラッシュ（flushing）に応じて上記ＵＬ ＨＡＲＱフィードバックタイマを停止すること、をさらに含む。ある実施形態において、ＵＬ ＨＡＲＱプロセスごとに１つのアップリンクＨＡＲＱラウンドトリップ時間（ＲＴＴ）タイマ及び１つのＤＲＸ再送タイマが維持される。
【0021】
他の観点によれば、ワイヤレスデバイスの動作の方法は、未ライセンス周波数スペクトルにおいて動作するセル上でアップリンク制御情報（ＵＣＩ）を送信すること、を含み、上記ＵＣＩは、１つ以上のダウンリンク（ＤＬ）ＨＡＲＱプロセスについてのＨＡＲＱフィードバック情報と、上記１つ以上のＤＬ ＨＡＲＱプロセスを識別する識別子と、を含
む。ある実施形態において、上記１つ以上のＤＬ ＨＡＲＱプロセスは、明示的な識別子により、又は各ビットが上記１つ以上のＤＬ ＨＡＲＱプロセスのうちの１つに対応するビットマップにより識別される。ある実施形態において、上記方法は、上記セルへサービスする基地局から、フィードバック制御情報を受信すること、をさらに含み、上記フィードバック制御情報は、ＵＣＩ内の上記ＤＬ ＨＡＲＱフィードバックのバンドリングが実行されるべきかの標識を含む。ある実施形態において、上記フィードバック制御情報は、上記ワイヤレスデバイスがＵＣＩ内でバンドリングすべきＤＬ ＨＡＲＱフィードバックの数を指し示す情報をさらに含む。
む。ある実施形態において、上記１つ以上のＤＬ ＨＡＲＱプロセスは、明示的な識別子により、又は各ビットが上記１つ以上のＤＬ ＨＡＲＱプロセスのうちの１つに対応するビットマップにより識別される。ある実施形態において、上記方法は、上記セルへサービスする基地局から、フィードバック制御情報を受信すること、をさらに含み、上記フィードバック制御情報は、ＵＣＩ内の上記ＤＬ ＨＡＲＱフィードバックのバンドリングが実行されるべきかの標識を含む。ある実施形態において、上記フィードバック制御情報は、上記ワイヤレスデバイスがＵＣＩ内でバンドリングすべきＤＬ ＨＡＲＱフィードバックの数を指し示す情報をさらに含む。
【0022】
他の観点によれば、プライマリサービングセル及びセカンダリサービングセルを有するネットワークにおけるワイヤレスデバイスの動作の方法は、プライマリサービングセルからのＤＬ送信の受信への応答として、上記プライマリサービングセルへＨＡＲＱフィードバックを提供することと、セカンダリサービングセルからのＤＬ送信の受信への応答として、上記プライマリサービングセルの代わりに上記セカンダリサービングセルへ、ＨＡＲＱフィードバックを提供することと、を含む。いくつかの実施形態において、各ＵＬサービングセルは、対応するＤＬサービングセルについてのＨＡＲＱフィードバックを搬送する。
【0023】
他の観点によれば、ワイヤレスデバイスの動作の方法は、上記ワイヤレスデバイスが未ライセンス周波数スペクトルにおいて動作するセル上のサブフレームにおいて有効なＵＬグラントを有するかを判定することと、上記ワイヤレスデバイスが有効なＵＬグラントを有するとの判定に応じて、仕掛かり中のＨＡＲＱフィードバックをＵＬ共有チャネルへ多重化することと、上記ワイヤレスデバイスが有効なＵＬグラントを有しないとの判定に応じて、ショートＬＢＴ動作の成功した後に仕掛かり中のＤＬ ＨＡＲＱフィードバックをＵＬ制御チャネル上で送信することと、を含む。ある実施形態において、上記ＵＬ制御チャネルは、ロングＵＬ制御チャネルである。
【0024】
他の観点によれば、ワイヤレスデバイスの動作の方法は、上記ワイヤレスデバイスが先行するサブフレームにおいてＵＬ送信を実行し且つ上記ワイヤレスデバイスがＵＬ ＬＢＴのスキップが許可されるという明示的な標識を受信した場合に、未ライセンス周波数スペクトルにおいて動作するセル上のサブフレームにおけるＵＬ送信の前にＵＬ ＬＢＴをスキップすること、を含む。ある実施形態において、上記先行するサブフレームにおける上記ＵＬ送信は、ＰＵＳＣＨ送信であった。ある実施形態において、上記先行するサブフレームにおける上記ＵＬ送信は、ロングＰＵＣＣＨ送信であった。
【0025】
他の観点によれば、ワイヤレスデバイスの動作の方法は、先行するサブフレームの末尾よりもむしろＵＬサブフレームの冒頭においてＵＬ ＬＢＴ動作を実行すること、を含む。
【0026】
他の観点によれば、ワイヤレスデバイスの動作の方法は、上記ワイヤレスデバイスが短縮ＤＬサブフレームの標識を受信した場合に、未ライセンス周波数スペクトルにおいて動作するセル上のショートＵＬ制御チャネル上で仕掛かり中のハイブリッドＨＡＲＱフィードバックを送信すること、を含む。ある実施形態において、上記ワイヤレスデバイスは、上記ショートＵＬ制御チャネル上での上記仕掛かり中のＨＡＲＱフィードバックの送信に先立って、ＬＢＴを実行することを必要としない。ある実施形態において、上記仕掛かり中のＨＡＲＱフィードバックを送信すべきショートＵＬ制御チャネルのリソースを判定すること、をさらに含む。ある実施形態において、上記ワイヤレスデバイスは、無線リソース制御（ＲＲＣ）構成及びＤＬ割り当て内に含まれる情報に基づいて、上記ショートＵＬ制御チャネルのリソースを判定する。
【0027】
当業者は、添付図面の図との関連において上記実施形態の以下の詳細な説明を読んだ後に、本開示のスコープを認識し及びその追加的な観点を理解するであろう。
【0028】
当業者は、添付図面の図との関連において上記実施形態の以下の詳細な説明を読んだ後に、本開示のスコープを認識し及びその追加的な観点を理解するであろう。
【図面の簡単な説明】
【0029】
本明細書に取り入れられ及び本明細書の一部をなす添付図面の図は、本開示の複数の観点を例示しており、その説明と併せて本開示の原理の説明に供される。
【0030】
【図1A】ＬＴＥ（Long Term Evolution）により使用される旧来の一例としてのＯＦＤＭ（Orthogonal Frequency Division Multiplexing）ダウンリンク（ＤＬ）物理リソースグリッドを示している。
【図1B】ＯＦＤＭ時間ドメイン構造を示す、旧来のＬＴＥの無線フレームの例示である。
【図1C】制御信号及びリファレンス信号の位置を示す、ＬＴＥの一例としての（１４個のＯＦＤＭシンボルを伴う）１．０ｍｓのＯＦＤＭ ＤＬサブフレームの例示である。
【図2】キャリアアグリゲーション（ＣＡ）の一例の概略図である。
【図3】ＬＢＴ（Listen-Before-Talk）方式を示す概略図である。
【図4A】ここで開示される主題のいくつかの実施形態に係る例示的なショート物理アップリンク制御チャネル（ＰＵＣＣＨ）を描いている。
【図4B】ここで開示される主題のいくつかの実施形態に係る例示的なロングＰＵＣＣＨを描いている。
【図5A】レガシーのアップリンク（ＵＬ）グラント送信方法を用いるＵＬバーストについて要する高いシグナリングオーバヘッドを描いている。
【図5B】本開示のいくつかの実施形態に係るＵＬグラント多重化の一例を描いている。
【図6】本開示のいくつかの実施形態に従ってユーザ機器デバイス（ＵＥ）が連続する４つのサブフレーム内の（物理ダウンリンク共有チャネル（ＰＤＳＣＨ）上の）ＤＬデータと共に後続する４つのサブフレームについて有効なＵＬグラントを受信した、物理アップリンク共有チャネル（ＰＵＳＣＨ）内のアップリンク制御情報（ＵＣＩ）の一例を描いている。
【図7】図６のケースと同様のケースを描いているが、ここでは最初の４つのサブフレームにおいてＰＤＳＣＨを受信したＵＥからのＵＣＩが後続の４つのサブフレームの全ての利用可能なシンボルをまたいで広がるロングＰＵＣＣＨへマッピングされ、一方でＰＵＳＣＨリソースは他のＵＥへ割り当てられるものと想定される。
【図8】相異なるＵＥが隣接するサブフレームにおいてそれらのＰＵＣＣＨフィードバックを提供する場合に追加的なＬＢＴフェーズが必要とされる実施形態の一例を示している。
【図9】本開示のいくつかの実施形態に係るバンドリングされるＰＵＣＣＨ送信を例示している。
【図10】短縮されるＤＬサブフレームの末尾にショートＰＵＣＣＨ（ｓＰＵＣＣＨ）が位置する１つの例を示している。
【図11】ＵＥが４サブフレーム毎の専用スケジューリング要求（Ｄ－ＳＲ）機会と共に構成される一例を描いている。
【図12A】本開示の実施形態が実装され得るセルラー通信ネットワークの例を示している。
【図12B】本開示の実施形態が実装され得るセルラー通信ネットワークの例を示している。
【図13】本開示のいくつかの実施形態に係る提案３を実装するための基地局及びワイヤレスデバイスの動作を示している。
【図14】本開示のいくつかの実施形態に係る提案４～７を実装するためのワイヤレスデバイスの動作を例示するフローチャートである。
【図15】本開示のいくつかの実施形態に係る提案８又は提案９を実装するための基地局及びワイヤレスデバイスの動作を例示している。
【図16】本開示のいくつかの実施形態に係る提案１１を実装するためのワイヤレスデバイスの動作を例示するフローチャートである。
【図17】本開示のいくつかの実施形態に係る提案１２を実装するためのワイヤレスデバイスの動作を例示するフローチャートである。
【図18】本開示のいくつかの実施形態に係る提案１３を実装するための基地局及びワイヤレスデバイスの動作を例示している。
【図19】本開示のいくつかの実施形態に係る提案１５～１７のうちのいくつか又は全てを実装するための基地局及びワイヤレスデバイスの動作を例示している。
【図20】本開示のいくつかの実施形態に係る提案１８～２０のうちのいくつか又は全てを実装するための基地局及びワイヤレスデバイスの動作を例示している。
【図21】本開示のいくつかの実施形態に係る基地局の実施形態を例示している。
【図22】本開示のいくつかの実施形態に係る基地局の実施形態を例示している。
【図23】本開示のいくつかの実施形態に係るワイヤレスデバイスの実施形態を例示している。
【図24】本開示のいくつかの実施形態に係るワイヤレスデバイスの実施形態を例示している。
【図25】本開示のいくつかの実施形態に従って、プライマリサービングセル内及びセカンダリサービングセル内のワイヤレスデバイスの動作を例示している。
【図26】本開示のいくつかの実施形態に従って、ＵＬサブフレームの直前のサブフレームの末尾でのＬＢＴ動作の実行に対し、ＵＬサブフレームの冒頭でのＬＢＴ動作の実行を例示している。
【発明を実施するための形態】
【0031】
以下に説示する実施形態は、それら実施形態を当業者が実践することを可能にし及びそれら実施形態の実践の最良の形態を例示する情報を表す。添付図面の図を踏まえて以下の説明を読めば、当業者は、本開示の概念を理解し、ここで具体的には扱われていないそれら概念の応用を認識するであろう。それら概念及び応用は、本開示及び添付の特許請求の範囲のスコープ内に入るものと理解されるべきである。
【0032】
以下に説示する実施形態は、それら実施形態を当業者が実践することを可能にし及びそれら実施形態の実践の最良の形態を例示する情報を表す。添付図面の図を踏まえて以下の説明を読めば、当業者は、本開示の概念を理解し、ここで具体的には扱われていないそれら概念の応用を認識するであろう。それら概念及び応用は、本開示のスコープ内に入るものと理解されるべきである。
【0033】
無線ノード：ここで使用されるところによれば、“無線ノード”は、無線アクセスノードであるか又はワイヤレスデバイスであるかのいずれかである。
【0034】
無線アクセスノード：ここで使用されるところによれば、“無線アクセスノード”は、ワイヤレスに信号を送信し及び／又は受信するように動作する、セルラー通信ネットワークの無線アクセスネットワーク内の任意のノードである。無線アクセスノードのいくつかの例は、限定ではないものの、基地局（例えば、３ＧＰＰ（Third Generation Partnership Project）ＬＴＥ（Long Term Evolution）ネットワーク内の拡張又は進化型ノードＢ（ｅＮＢ））、高電力又はマクロ基地局、低電力基地局（例えば、マイクロ基地局、ピコ基地局若しくはホームｅＮＢなど）、及び中継ノードを含む。
【0035】
ワイヤレスデバイス：ここで使用されるところによれば、“ワイヤレスデバイス”は、無線アクセスノードへワイヤレスに信号を送信し及び／又は受信することによりセルラー通信ネットワークへのアクセスを有する（即ち、セルラー通信ネットワークによりサービスされる）任意のタイプのデバイスである。ワイヤレスデバイスのいくつかの例は、限定ではないものの、３ＧＰＰ ＬＴＥネットワーク内のユーザ機器デバイス（ＵＥ）及びマシンタイプ通信（ＭＴＣ）デバイスを含む。
【0036】
ネットワークノード：ここで使用されるところによれば、“ネットワークノード”は、セルラー通信ネットワーク／システムの無線アクセスネットワーク又はコアネットワークのいずれかの部分にある任意のノードである。
【0037】
ＬＢＴ（Listen-Before-Talk）：ここで使用されるところによれば、“ＬＢＴ”又は“ＬＢＴ方式”は、無線アクセスノード又はワイヤレスデバイスが未ライセンス周波数スペクトル内のチャネル上での送信前にそのチャネルをモニタリングしてそのチャネルがクリアであるかを判定する（例えば、ＣＣＡ（Clear Channel Assessment）を実行する）任意の方式である。
【0038】
ＬＢＴセル：ここで使用されるところによれば、“ＬＢＴセル”は、送信前にＬＢＴ方式が実行されなければならない、未ライセンス周波数スペクトル内のチャネル上で動作するセルである。
【0039】
ライセンス支援型アクセス（ＬＡＡ）セカンダリセル（ＳＣｅｌｌ）：ここで使用されるところによれば、“ＬＡＡ ＳＣｅｌｌ”は、あるタイプのＬＢＴセルである。具体的には、“ＬＡＡ ＳＣｅｌｌ”は、ライセンス済み周波数スペクトル内で動作する他のセル（即ち、プライマリセル（ＰＣｅｌｌ））からの支援を伴って未ライセンス周波数スペクトル内で動作する、ＬＴＥネットワーク内のＳＣｅｌｌである。
【0040】
スタンドアローンＬＢＴセル：ここで使用されるところによれば、“スタンドアローンＬＢＴセル”は、ライセンス済み周波数スペクトル内で動作する他のセルからの支援を伴わずに自ら動作するタイプのＬＢＴセル（例えば、ＬＴＥネットワーク内のセル）である。
【0041】
注：ここで与えられる説明は３ＧＰＰ ＬＴＥに焦点を当てており、そのため３ＧＰＰ ＬＴＥの専門用語が多くの場合使用される。しかしながら、ここで開示される概念は、３ＧＰＰ ＬＴＥには限定されない。
【0042】
なお、ここでの説明において、“セル”との用語への言及がなされる。但し、特に第５世代（５Ｇ）の概念に関して言うと、セルの代わりにビームが使用されてもよく、そのため、ここで説明される概念はセル及びビームの双方へ等しく適用可能であることに留意することが重要である。よって、いくつかの実施形態において、ここで説明される送信は、セルではなくビーム（例えば、未ライセンス周波数スペクトル内のビーム）上で実行されてもよい。
【0043】
本開示では、アップリンク（ＵＬ）関連のメディアアクセス制御（ＭＡＣ）プロトコルの観点、即ち、物理アップリンク共有チャネル（ＰＵＳＣＨ）上でデータを送信するために要する機能性と共に、物理アップリンク制御チャネル（ＰＵＣＣＨ）又はＰＵＳＣＨ上での、ハイブリッド自動再送要求（ＨＡＲＱ）確認応答／否定確認応答（ＡＣＫ／ＮＡＣＫ）フィードバック及びスケジューリング要求の送信が検討される。
【0044】
＜物理レイヤ上のＰＵＣＣＨの実現＞
本開示では、未ライセンススペクトル（ＬＴＥ－Ｕ）動作におけるスタンドアローンＬＴＥのためのＰＵＣＣＨの物理レイヤ設計が提供される。ショートＰＵＣＣＨ（ｓＰＵＣＣＨ）及びロングＰＵＣＣＨの設計という２つのオプションが、物理レイヤの視点から説明される。ＰＵＣＣＨ上でのＨＡＲＱフィードバック及びスケジューリング要求（ＳＲ）のＭＡＣプロトコル設計が以下に議論されるであろう。
本開示では、未ライセンススペクトル（ＬＴＥ－Ｕ）動作におけるスタンドアローンＬＴＥのためのＰＵＣＣＨの物理レイヤ設計が提供される。ショートＰＵＣＣＨ（ｓＰＵＣＣＨ）及びロングＰＵＣＣＨの設計という２つのオプションが、物理レイヤの視点から説明される。ＰＵＣＣＨ上でのＨＡＲＱフィードバック及びスケジューリング要求（ＳＲ）のＭＡＣプロトコル設計が以下に議論されるであろう。
【0045】
３ＧＰＰ ＬＴＥでは、ＨＡＲＱ－ＡＣＫ、ＳＲ及び周期的なチャネル状態情報（ＣＳＩ）を含むアップリンク制御情報（ＵＣＩ）をＰＵＣＣＨ上で送信することができる。未ライセンス帯域でのスタンドアローン動作については、ｅＮＢタイミング構成及びＨＡＲＱプロトコルに依存して、以下に説明するように、ＵＣＩ送信のために２つのＰＵＣＣＨフォーマットを考慮することができる。留意すべきこととして、スタンドアローンＬＴＥ－Ｕでは、各ＵＬサービングセルが対応するＤＬサービングセルについてのＨＡＲＱフィードバックを搬送することが有益である。これにより、１つのセルのチャネルステータスが全てのセルのＨＡＲＱ－ＡＣＫフィードバックを左右することが回避される。このアプローチは、典型的にＰＣｅｌｌのＰＵＣＣＨが全てのＳＣｅｌｌについてのＵＣＩを搬送するＬＴＥとは相違する。一方で、チャネル利用率及びＰＵＣＣＨフォーマット設計の点で、各スタンドアローンキャリアについて独立的なＰＵＣＣＨを有することが提案される。
【0046】
［ショートＰＵＣＣＨ（ｓＰＵＣＣＨ）］
ｓＰＵＣＣＨは、時間ドメインにおいて１～３個のＳＣ－ＦＤＭＡ（Single Carrier Frequency Division Multiple Access）／ＯＦＤＭ（Orthogonal Frequency Division Multiplexing）シンボルを占有し、インタレースによって帯域幅全体にわたる。ｓＰＵＣＣＨは、ＤＬの部分的なサブフレームの末尾において又は（少なくともＰＵＳＣＨが同じＵＥへスケジューリングされる場合）ＵＬサブフレームの一部として送信されることができる。ｓＰＵＣＣＨを送信する目的で、ＵＥにアグレッシブＬＢＴが適用されてよい。代替的に、規制要件によれば、ｓＰＵＣＣＨの時間長がデューティサイクルの５％を下回る場合にはＬＢＴを要しない。
ｓＰＵＣＣＨは、時間ドメインにおいて１～３個のＳＣ－ＦＤＭＡ（Single Carrier Frequency Division Multiple Access）／ＯＦＤＭ（Orthogonal Frequency Division Multiplexing）シンボルを占有し、インタレースによって帯域幅全体にわたる。ｓＰＵＣＣＨは、ＤＬの部分的なサブフレームの末尾において又は（少なくともＰＵＳＣＨが同じＵＥへスケジューリングされる場合）ＵＬサブフレームの一部として送信されることができる。ｓＰＵＣＣＨを送信する目的で、ＵＥにアグレッシブＬＢＴが適用されてよい。代替的に、規制要件によれば、ｓＰＵＣＣＨの時間長がデューティサイクルの５％を下回る場合にはＬＢＴを要しない。
【0047】
図４Ａは、ここで説明される主題の一実施形態に係る例示的なｓＰＵＣＣＨを描いている。図４Ａに例示した実施形態において、ＰＵＣＣＨは、時間において２つのＳＣ－ＦＤＭＡ／ＯＦＤＭシンボルを、周波数ドメインにおいて１つのインタレースを占有する。図中に例示したように、２つのオプションとして、復調リファレンス信号（ＤＭＲＳ）及びＰＵＣＣＨのためのデータシンボルを、周波数多重化し又は時間多重化することができる。複数のＰＵＣＣＨ ＵＥを、異なるインタレーシングパターンを割り当てることにより周波数ドメインで、及び／又は例えば単一のインタレース内で異なる直交カバーコード（ＯＣＣ）を適用することにより符号ドメインで多重化することができる。ｅＮＢシグナリングによって、ＵＥについて、シンボルの数、インタレーシングパターン及びＯＣＣ構成（もしあれば）を構成することができる。
【0048】
ＨＡＲＱフィードバック及び対応するプロセス識別子（ＩＤ）は、明示的に列挙されるか、又は例えばビットマップ（プロセスごとに１又は２ビット）として提供されるかのいずれかであり得る。設計を３ＧＰＰリリース１３（Ｒｅｌ－１３）キャリアアグリゲーション（ＣＡ）に合わせるために、ｓＰＵＣＣＨ上のＵＣＩは、８ビットのＣＲＣ（Cyclic Redundancy Check）を付加され、ＴＢＣＣ（Tail Biting Convolutional Code）を用いて符号化される。符号化されたシンボルは、周波数が先、時間が次という形で利用可能なリソースエレメント（ＲＥ）へマッピングされる。
【0049】
［ロングＰＵＣＣＨ］
ロングＰＵＣＣＨは、時間ドメインにおいてサブフレーム全体を占有し、インタレース
によって帯域幅全体にわたる。ロングＰＵＣＣＨは、ｅＮＢにより明示的にスケジューリングされることができ、ＵＬチャネルへのアクセスを得るためにＵＥにおいてＬＢＴを要する。ロングＰＵＣＣＨは、ＰＵＳＣＨ送信に適合し、同一の又は異なるＵＥからのＰＵＳＣＨと多重化されることができる。
ロングＰＵＣＣＨは、時間ドメインにおいてサブフレーム全体を占有し、インタレース
によって帯域幅全体にわたる。ロングＰＵＣＣＨは、ｅＮＢにより明示的にスケジューリングされることができ、ＵＬチャネルへのアクセスを得るためにＵＥにおいてＬＢＴを要する。ロングＰＵＣＣＨは、ＰＵＳＣＨ送信に適合し、同一の又は異なるＵＥからのＰＵＳＣＨと多重化されることができる。
【0050】
図４Ｂは、ここで説明される主題の一実施形態に係る例示的なロングＰＵＣＣＨを描いている。図４Ｂに例示した実施形態において、ＰＵＣＣＨは、１つのサブフレームにおいて１つのインタレースを占有する。周波数において帯域幅全体を占有する、スロットごとに１つのＤＭＲＳが存在し、これを異なるサイクリックシフトを適用することによりＰＵＳＣＨ ＤＭＲＳと多重化することができる。ｓＰＵＣＣＨと同様、複数のＰＵＣＣＨ ＵＥを、異なるインタレーシングパターンを割り当てることにより周波数ドメインで、及び／又は例えば単一のインタレース内で異なるＯＣＣを適用することにより符号ドメインで多重化することができる。同じサブフレーム内の残りのインタレースは、ＰＵＳＣＨ送信及び他のＵＥからのＰＵＣＣＨ／ＰＵＳＣＨ送信のために使用され得る。ｅＮＢシグナリングによって、ＵＥについて、インタレーシングパターン、サイクリックシフト（ＣＳ）及びＯＣＣ構成（もしあれば）を構成することができる。
【0051】
ｓＰＵＣＣＨと同様に、ＰＵＣＣＨ．１上で、ＨＡＲＱフィードバック及び対応するプロセスＩＤは、明示的に列挙されるか、又は例えばビットマップ（プロセスごとに１又は２ビット）として提供されるかのいずれかであり得る。ロングＰＵＣＣＨ上のＵＣＩは、８ビットのＣＲＣを付加され、ＴＢＣＣを用いて符号化される。符号化されたシンボルは、周波数が先、時間が次という形で利用可能なＲＥへマッピングされる。
【0052】
３ＧＰＰ ＬＴＥでは、ＰＵＣＣＨ上でのＵＣＩ送信は、ＨＡＲＱ－ＡＣＫ、ＳＲ及び周期的なＣＳＩを含む。スタンドアローンＬＴＥ－Ｕについては、周期的なＣＳＩをサポートすることは困難となるはずである。よって、非周期的なＣＳＩフィードバックが、より不可欠であって、ＵＬ共有チャネル（ＵＬ－ＳＣＨ）データの有無によらずＵＬグラントによりスケジューリングされるＰＵＳＣＨ上でサポートされるべきである。同じサブフレーム内の例えばＨＡＲＱ及びＳＲなど、１つよりも多くのＵＣＩタイプがＰＵＣＣＨ上で送信される場合には、それらは連結され及び共同的に符号化され、そして、以下に説明するように、ＤＬ ＨＡＲＱプロトコルに基づいてｅＮＢ構成に従ってｓＰＵＣＣＨフォーマットか又はロングＰＵＣＣＨフォーマットかのいずれかで送信される。
【0053】
＜アップリンクＬＢＴアルゴリズム＞
［Ｒｅｌ－１３ ＬＡＡ ＵＬ ＬＢＴ］
Ｒｅｌ－１３の期間中に、ＵＬ ＬＢＴのいくつかの観点が議論された。ＵＬ ＬＢＴのフレームワークに関して、その議論は、セルフスケジューリング及びクロスキャリアスケジューリングのシナリオに焦点を当てた。
［Ｒｅｌ－１３ ＬＡＡ ＵＬ ＬＢＴ］
Ｒｅｌ－１３の期間中に、ＵＬ ＬＢＴのいくつかの観点が議論された。ＵＬ ＬＢＴのフレームワークに関して、その議論は、セルフスケジューリング及びクロスキャリアスケジューリングのシナリオに焦点を当てた。
【0054】
認識されたこととして、ＵＬ ＬＢＴは、セルフスケジューリングを伴うＵＬ送信に追加的なＬＢＴのステップを課し、なぜならＵＬグラント自体がｅＮＢによるＤＬ ＬＢＴを要するからである。従って、Ｒｅｌ－１３のＬＡＡは、セルフスケジューリングのためのＵＬ ＬＢＴが（ＤＬの専用リファレンス信号（ＤＲＳ）と同様に）少なくとも２５μｓの単一のＣＣＡ時間長か、又は１ＣＣＡスロットが後に続く１６μｓの延期時間長を含む２５μｓの延期ピリオドを伴うランダムバックオフ方式かのいずれか、及び、Ｘ＝｛３，４，５，６，７｝から選択される最大競合ウィンドウサイズを使用すべきであることを推奨している。これらオプションは、他の未ライセンスＳＣｅｌｌによるＵＬのクロスキャリアスケジューリングにも適用可能である。
【0055】
ライセンス済みＰＣｅｌｌによるクロスキャリアスケジューリングに関与するケースの
ためのショートＵＬ ＬＢＴ手続は、さらなる研究のためにオープンなままである。審議中の他のオプションは、Ｗｉ－Ｆｉステーションにより使用されるものに類似する、本格的な（full-fledged）ランダムバックオフ手続である。
ためのショートＵＬ ＬＢＴ手続は、さらなる研究のためにオープンなままである。審議中の他のオプションは、Ｗｉ－Ｆｉステーションにより使用されるものに類似する、本格的な（full-fledged）ランダムバックオフ手続である。
【0056】
最後に、ＵＬ送信バーストがそれぞれのキャリア上でＤＬ送信バーストに続く（２つのバースト間に高々１６μｓのギャップを伴う）場合の、ＬＢＴ無しでのＵＬ送信のケースが、Ｒｅｌ－１４におけるさらなる研究のためにオープンで残された。
【0057】
［スタンドアローンＵＬ ＬＢＴアルゴリズム］
スタンドアローンのＵＬ ＬＢＴ設計がＲｅｌ－１４ ＬＡＡにおいて仕様化される有望なＵＬ ＬＡＡ ＬＢＴアルゴリズムと整合することは不可欠である。そのうえ、ＵＬチャネルアクセスは、ダウンリンクと比較した場合に優位である必要がある。これら観点が以下の提案につながる。このようにして、本開示は、さらなる研究のための基礎としてＲｅｌ－１３ ＬＡＡ ＵＬ ＬＢＴのオプションを保つことを提案し、及び、ＵＬ ＣＣＡエネルギー検出（ＣＣＡ－ＥＤ）閾値を少なくともＤＬ ＣＣＡ－ＥＤ閾値と同程度に高くすることを提案する。
スタンドアローンのＵＬ ＬＢＴ設計がＲｅｌ－１４ ＬＡＡにおいて仕様化される有望なＵＬ ＬＡＡ ＬＢＴアルゴリズムと整合することは不可欠である。そのうえ、ＵＬチャネルアクセスは、ダウンリンクと比較した場合に優位である必要がある。これら観点が以下の提案につながる。このようにして、本開示は、さらなる研究のための基礎としてＲｅｌ－１３ ＬＡＡ ＵＬ ＬＢＴのオプションを保つことを提案し、及び、ＵＬ ＣＣＡエネルギー検出（ＣＣＡ－ＥＤ）閾値を少なくともＤＬ ＣＣＡ－ＥＤ閾値と同程度に高くすることを提案する。
【0058】
［ＵＬグラント送信］
レガシーのＵＬグラント送信では、各ＵＬサブフレームは、４ｍｓ早く送信される専用グラントによりスケジューリングされる。これは、図５Ａに見られるように、単一の４ｍｓのＵＬバーストを指し示すためにＵＬグラントを伴う４つの連続するサブフレームが必要とされることから、高いシグナリング負荷をもたらす。
レガシーのＵＬグラント送信では、各ＵＬサブフレームは、４ｍｓ早く送信される専用グラントによりスケジューリングされる。これは、図５Ａに見られるように、単一の４ｍｓのＵＬバーストを指し示すためにＵＬグラントを伴う４つの連続するサブフレームが必要とされることから、高いシグナリング負荷をもたらす。
【0059】
図５Ａは、レガシーのＵＬグラント送信方法を用いるＵＬバーストのために要する高いシグナリングオーバヘッドを描いている。低負荷では、これは、そのサブフレームにおいてデータの無いＵＬグラントを単に送信するためにＤＬ ＬＢＴを実行することを必要とするはずであることをさらに示唆し、それが未ライセンスチャネルの非効率的な使用をもたらす。ＵＬグラント送信とＵＬ送信との間の４ｍｓの遅延は、短いＤＬバーストの直後にＵＬバーストを続けることを困難にもする。
【0060】
レガシーＵＬグラント送信の欠点は、ＵＬ ＬＡＡのポテンシャルを有意に低下させるが、簡易な改善でそれに対処することができ、それら改善とは、単一のＤＬサブフレームから複数のＵＬサブフレームをスケジューリングすること、及びＵＬグラント受信とＵＬサブフレームとの間の最小の遅延を低減することである。これらが次に順に扱われるであろう。
【0061】
マルチサブフレームスケジューリング：単一のＤＬサブフレームから複数のＵＬサブフレームをスケジューリングすることで、ＵＬ ＬＡＡについてのシグナリングオーバヘッド及び隣接セルへ引き起こす干渉が低減される。所与の時点でＵＬトラフィックのみを伴う低負荷の状況について、１ＤＬサブフレームの範囲内から４つのＵＬサブフレームをスケジューリングすることが可能であれば、グラント送信のオーバヘッドは２５％まで低減される。個々のサブフレームにおいて異なる構成を指し示すことができれば、オーバヘッドの低減はいくらかより小さくなり得る。変調符号化方式（ＭＳＣ）、インタレース、サウンディングリファレンス信号（ＳＲＳ）構成、及びＤＭＲＳ構成などを変化させることが望まれるかもしれない。この特徴は、時間分割複信（ＴＤＤ）では既にサポートされており、なぜなら２つのＤＬサブフレームに対し３つのＵＬサブフレームを伴うコンフィグレーション０が、単一のＤＬサブフレームから複数のＵＬサブフレームをスケジューリングすることをサポートするからである。１つのＤＬサブフレームでスケジューリングされるＵＬサブフレームの数が、例えば１２個にまでさらに増加される場合、シグナリングオーバヘッドをさらに例えば８．３３％にまで低減することができ、ＬＡＡ ＵＬ性能がさ
らに改善される。しかしながら、同一のＤＬサブフレームでスケジューリングされるＵＬサブフレームの最適な数は、トラフィックタイプ、トラフィック負荷及びＵＥバッファサイズといった多くの要因に依存する。従って、ｅＮＢは、理想的には、同じＤＬサブフレームでいくつのＵＬサブフレームがスケジューリングされるかを構成するための自由度を有するべきである。ＭＡＣプロトコルのインパクトは、以下で議論するように最小限である。このように、本開示の他の提案は、ＵＬについてマルチサブフレームスケジューリングをサポートすることである。
らに改善される。しかしながら、同一のＤＬサブフレームでスケジューリングされるＵＬサブフレームの最適な数は、トラフィックタイプ、トラフィック負荷及びＵＥバッファサイズといった多くの要因に依存する。従って、ｅＮＢは、理想的には、同じＤＬサブフレームでいくつのＵＬサブフレームがスケジューリングされるかを構成するための自由度を有するべきである。ＭＡＣプロトコルのインパクトは、以下で議論するように最小限である。このように、本開示の他の提案は、ＵＬについてマルチサブフレームスケジューリングをサポートすることである。
【0062】
低減されたＵＬグラント遅延。アップリンク性能をさらに改善するために、４ｍｓというレガシーの固定的なＵＬグラント遅延は低減されるべきである。所与の時点でＵＬトラフィックのみを伴う低負荷の状況を考慮すると、ＵＬグラントの多重化のみがさらなる最適化無しで適用される場合、図５Ｂに描いた状況に結局なり得る。
【0063】
図５Ｂは、本開示の一実施形態に係るＵＬグラント多重化の一例を描いている。ＵＬグラント送信のシグナリングオーバヘッドは低減されるが、ＵＬデータ送信のために以前のＵＬグラントサブフレームが使用される代わりに、それらは単にＵＬ送信が開始するまで空白に保たれる。よって、アップリンクスループットは限られたまま残る。
【0064】
図５に描いた状況を可能な限り回避するように、ｅＮＢスケジューリングが最適化され得る。とはいえ、ＬＢＴの失敗に起因して、多重化されたＵＬグラント送信を計画されたサブフレームにおいてなし得ない都度、この状況は発生するであろう。図５Ｂにおける課題を解決するための最も自然であり単純な方法は、アップリンクについてグラント遅延を低減することである。このように、本開示の他の提案は、ＵＬグラントと対応するＵＬ送信との間の遅延を、４ｍｓ未満にまで低減することである。
【0065】
＜ＰＵＳＣＨについてのアップリンクＨＡＲＱ＞
［提案１：非同期ＵＬ ＨＡＲＱの採用］
ＬＡＡ研究項目フェーズの３ＧＰＰ技術報告（ＴＲ）３６．８８９ Ｖ１３．０．０のセクション７．２．２．２において、特にＰＵＳＣＨについて「ＬＡＡ ＵＬのために非同期的なＨＡＲＱが推奨」されている。このことは、ＵＬの再送が初期の送信の１ラウンドトリップ時間（ＲＴＴ）（例えば、ｎ＋８）後にのみ生じるわけではなく、むしろ任意の時点で生じ得ることを意味する。これは、特にＬＢＴに起因して（再）送信がブロックされ先延ばしされる場合に有益であると考えられる。よって、３ＧＰＰ Ｒｅｌ－１４の機能性との適合性を維持する目的で、本開示は、（ＬＡＡ ＵＬについてＲｅｌ－１３研究項目（ＳＩ）において合意された通りの）非同期ＵＬ ＨＡＲＱを採用することを提案する。
［提案１：非同期ＵＬ ＨＡＲＱの採用］
ＬＡＡ研究項目フェーズの３ＧＰＰ技術報告（ＴＲ）３６．８８９ Ｖ１３．０．０のセクション７．２．２．２において、特にＰＵＳＣＨについて「ＬＡＡ ＵＬのために非同期的なＨＡＲＱが推奨」されている。このことは、ＵＬの再送が初期の送信の１ラウンドトリップ時間（ＲＴＴ）（例えば、ｎ＋８）後にのみ生じるわけではなく、むしろ任意の時点で生じ得ることを意味する。これは、特にＬＢＴに起因して（再）送信がブロックされ先延ばしされる場合に有益であると考えられる。よって、３ＧＰＰ Ｒｅｌ－１４の機能性との適合性を維持する目的で、本開示は、（ＬＡＡ ＵＬについてＲｅｌ－１３研究項目（ＳＩ）において合意された通りの）非同期ＵＬ ＨＡＲＱを採用することを提案する。
【0066】
［提案２：非適応的アップリンクＨＡＲＱをサポートせず］
３ＧＰＰ ＴＲ３６．８８９ Ｖ１３．０．０のセクション７．２．２．２において、「ＵＬ非同期ＨＡＲＱプロトコルでは、全ての送信又は再送を、物理ダウンリンク制御チャネル（ＰＤＣＣＨ）又は拡張ＰＤＣＣＨ（ｅＰＤＣＣＨ）を介してスケジューリングすべきである」こともまた合意された。言い換えると、非適応的なＨＡＲＱはもはやサポートされない。なぜなら、それは非同期ＨＡＲＱの概念には良好にフィットせず、ＤＬにおいてＡＣＫ／ＮＡＣＫを搬送するために信頼性の高いチャネルを要するはずだからである。ここで使用されるところによれば、“非適応的なＨＡＲＱ”との用語は、物理ＨＡＲＱインジケータチャネル（ＰＨＩＣＨ）上のＮＡＣＫが同一の周波数リソース上で同一のＭＣＳと共に初期の送信の１ＲＴＴ後のＨＡＲＱ再送をトリガするという動作モードをいう。ＰＨＩＣＨは、従来のようには使用され得ない：ＰＨＩＣＨ上のＡＣＫがＬＢＴによりブロックされる場合、ＵＥは、既存のＨＡＲＱパターン及びスケジューリング割り当てに従って非適応的な再送を実行するはずであった。よって、本開示は、非適応的なＵＬ Ｈ
ＡＲＱをサポートしないことを提案する。
３ＧＰＰ ＴＲ３６．８８９ Ｖ１３．０．０のセクション７．２．２．２において、「ＵＬ非同期ＨＡＲＱプロトコルでは、全ての送信又は再送を、物理ダウンリンク制御チャネル（ＰＤＣＣＨ）又は拡張ＰＤＣＣＨ（ｅＰＤＣＣＨ）を介してスケジューリングすべきである」こともまた合意された。言い換えると、非適応的なＨＡＲＱはもはやサポートされない。なぜなら、それは非同期ＨＡＲＱの概念には良好にフィットせず、ＤＬにおいてＡＣＫ／ＮＡＣＫを搬送するために信頼性の高いチャネルを要するはずだからである。ここで使用されるところによれば、“非適応的なＨＡＲＱ”との用語は、物理ＨＡＲＱインジケータチャネル（ＰＨＩＣＨ）上のＮＡＣＫが同一の周波数リソース上で同一のＭＣＳと共に初期の送信の１ＲＴＴ後のＨＡＲＱ再送をトリガするという動作モードをいう。ＰＨＩＣＨは、従来のようには使用され得ない：ＰＨＩＣＨ上のＡＣＫがＬＢＴによりブロックされる場合、ＵＥは、既存のＨＡＲＱパターン及びスケジューリング割り当てに従って非適応的な再送を実行するはずであった。よって、本開示は、非適応的なＵＬ Ｈ
ＡＲＱをサポートしないことを提案する。
【0067】
［提案３：ＵＬ ＨＡＲＱは成功したと仮定し、ステータスをＡＣＫへ設定］
非同期ＨＡＲＱを導入する場合、ＵＥは、よって、送信の行われた全てのＵＬ ＨＡＲＱプロセスが成功したものと仮定（ローカルのステータスをＡＣＫへ設定）すべきである。ＵＥは、ｅＮＢからの（ＮＤＩ（New Data Indicator）が切り替えられていない）ＵＬグラントの受信に応じてのみ、対応するＨＡＲＱプロセスについてＨＡＲＱ再送を実行する。プロセスインデックスは、ＵＬグラント内のＨＡＲＱプロセスインデックスフィールドにおいて指し示される。なお、ほとんどの送信試行はいずれにしろ成功し、よってフィードバック（ＰＨＩＣＨ）はそれ以上必要でないと見なすこともまた効率的である。よって、本開示は、ＵＬ ＨＡＲＱプロセスの送信に応じて、ＵＥがその送信が成功したものと仮定してローカルで維持されるステータスをＡＣＫへ設定することを提案する。ＵＥは、ＵＬグラントの受信に応じてのみ、対応するＵＬ ＨＡＲＱプロセスについてＨＡＲＱ再送を実行する。
非同期ＨＡＲＱを導入する場合、ＵＥは、よって、送信の行われた全てのＵＬ ＨＡＲＱプロセスが成功したものと仮定（ローカルのステータスをＡＣＫへ設定）すべきである。ＵＥは、ｅＮＢからの（ＮＤＩ（New Data Indicator）が切り替えられていない）ＵＬグラントの受信に応じてのみ、対応するＨＡＲＱプロセスについてＨＡＲＱ再送を実行する。プロセスインデックスは、ＵＬグラント内のＨＡＲＱプロセスインデックスフィールドにおいて指し示される。なお、ほとんどの送信試行はいずれにしろ成功し、よってフィードバック（ＰＨＩＣＨ）はそれ以上必要でないと見なすこともまた効率的である。よって、本開示は、ＵＬ ＨＡＲＱプロセスの送信に応じて、ＵＥがその送信が成功したものと仮定してローカルで維持されるステータスをＡＣＫへ設定することを提案する。ＵＥは、ＵＬグラントの受信に応じてのみ、対応するＵＬ ＨＡＲＱプロセスについてＨＡＲＱ再送を実行する。
【0068】
３ＧＰＰ ＴＲ３６．８８９ Ｖ１３．０．０は、ＵＬ ＨＡＲＱバッファをフラッシュする新たな手段を導入する必要性にも言及している。これまでのところ、これは、ＨＡＲＱプロセスごとのカウンタ（CURRENT_TX_NB）と共になされ、ＵＥはそれをＲＴＴごとに（即ち、プロセスが再送を行う機会を有する都度）１回インクリメントする。非同期ＨＡＲＱが導入されると、再送は別の時点でなされ得る。従って、３ＧＰＰでは、プロセスの初期の送信からのサブフレーム数を判定するタイマ／カウンタを使用し、タイマ／カウンタが構成済みの閾値を上回る際にプロセスをフラッシュすることがより適切であろうという議論がなされた。しかし、ＨＡＲＱプロセスをフラッシュすることが必要か否かは、例えば不連続受信（ＤＲＸ）がどのようにハンドリングされるかに依存する。
【0069】
３ＧＰＰによる研究では、ＤＲＸアクティブ時間を再定義する必要性もまた識別された。ＵＥは、ＨＡＲＱ再送について潜在的な来たるべきＵＬグラントを受信する目的で、どのサブフレームにおいてＰＤＣＣＨをモニタリングするものとされるかを判定する必要がある。具体的なＨＡＲＱプロセスのための再送はもはや特定のサブフレームに縛られないことから、ＵＬ再送のためのグラントは、原理上は、未だフラッシュされていない任意のプロセスについて任意のサブフレームに出現し得る。従って、簡易な解決策は、３ＧＰＰ ＴＳ３６．３２１ Ｖ１２．７．０における条件を、「仕掛かり中のＨＡＲＱ再送についてのアップリンクグラントが生起可能であり且つ対応するＨＡＲＱバッファ内にデータがある」から、「アップリンクＨＡＲＱバッファのいずれか内にデータがある」へ変更すること、及び、前の段落において概説したようにバッファをフラッシュすることであろう。しかしながら、このアプローチは、再送を要しない場合でさえも各ＵＬ送信の後にかなり長い時間にわたってＵＥを連続的にウェイクアップしたまま保つことになる。
【0070】
［提案４：ＵＥは有効なＵＬグラントを有するサブフレームにおいて“アップリンクＨＡＲＱフィードバックタイマ”を開始する］
非同期ＨＡＲＱの導入に起因して、幸運にも、ＵＥを連続的にウェイクアップしたまま保つことはもはや必要ではない。ｅＮＢは、（ＬＢＴが成功するものとして）任意のサブフレームにおいて任意のＵＬ ＨＡＲＱプロセスのための再送をスケジューリングすることを可能とされる。従って、提案されるのは、Ｒｅｌ－８よりＤＬ ＨＡＲＱについて使用されてきたＨＡＲＱ ＲＴＴタイマ（HARQ RTT Timer）及びＤＲＸ再送タイマ（DRX-RetransmissionTimer）と同様の原理を使用することである。相違点は、ここで“ＵＬ ＨＡＲＱフィードバックタイマ（UL HARQ Feedback Timer）”として言及されるタイマが、ＵＬグラントが有効になるサブフレームにおいて（送信が発生する場合に加えてＬＢＴの不成功によりブロックされた場合の双方において）開始することである。ＵＬ ＨＡＲＱフィードバックタイマは、再送のためのＵＬグラントが受信され得る最も早い時点
まで稼働する。よって、本開示は、有効なＵＬグラントを有するサブフレームにおいて、即ち、ＵＬ送信が発生する場合に加えてそれがＬＢＴによりブロックされる場合のいずれかにおいて、ＵＥがＵＬ ＨＡＲＱフィードバックタイマを開始することを提案する。
非同期ＨＡＲＱの導入に起因して、幸運にも、ＵＥを連続的にウェイクアップしたまま保つことはもはや必要ではない。ｅＮＢは、（ＬＢＴが成功するものとして）任意のサブフレームにおいて任意のＵＬ ＨＡＲＱプロセスのための再送をスケジューリングすることを可能とされる。従って、提案されるのは、Ｒｅｌ－８よりＤＬ ＨＡＲＱについて使用されてきたＨＡＲＱ ＲＴＴタイマ（HARQ RTT Timer）及びＤＲＸ再送タイマ（DRX-RetransmissionTimer）と同様の原理を使用することである。相違点は、ここで“ＵＬ ＨＡＲＱフィードバックタイマ（UL HARQ Feedback Timer）”として言及されるタイマが、ＵＬグラントが有効になるサブフレームにおいて（送信が発生する場合に加えてＬＢＴの不成功によりブロックされた場合の双方において）開始することである。ＵＬ ＨＡＲＱフィードバックタイマは、再送のためのＵＬグラントが受信され得る最も早い時点
まで稼働する。よって、本開示は、有効なＵＬグラントを有するサブフレームにおいて、即ち、ＵＬ送信が発生する場合に加えてそれがＬＢＴによりブロックされる場合のいずれかにおいて、ＵＥがＵＬ ＨＡＲＱフィードバックタイマを開始することを提案する。
【0071】
［提案５：ＵＬ ＨＡＲＱフィードバックタイマがＤＲＸ再送タイマをトリガする］
本開示は、ＵＬ ＨＡＲＱフィードバックタイマの満了に応じて、ＵＥが対応するＤＲＸ再送タイマを開始し、上記ＤＲＸ再送タイマが稼動している限りアクティブ時間（Active Time）のままでいることを提案する。
本開示は、ＵＬ ＨＡＲＱフィードバックタイマの満了に応じて、ＵＥが対応するＤＲＸ再送タイマを開始し、上記ＤＲＸ再送タイマが稼動している限りアクティブ時間（Active Time）のままでいることを提案する。
【0072】
［提案６：ＨＡＲＱバッファのフラッシュがＵＬ ＨＡＲＱフィードバックタイマを停止する］
本開示は、ＵＥがＵＬ ＨＡＲＱフィードバックタイマを対応するＨＡＲＱバッファのフラッシュに応じて停止することをさらに提案する。
本開示は、ＵＥがＵＬ ＨＡＲＱフィードバックタイマを対応するＨＡＲＱバッファのフラッシュに応じて停止することをさらに提案する。
【0073】
［提案７：ＵＬ ＨＡＲＱプロセスごとに１つのＵＬ ＨＡＲＱ ＲＴＴタイマ及び１つのＤＲＸ再送タイマ］
本開示は、１つのＵＬ ＨＡＲＱ ＲＴＴタイマ及び１つのＤＲＸ再送タイマが各ＵＬ ＨＡＲＱプロセスに関連付けられることをも提案する。
本開示は、１つのＵＬ ＨＡＲＱ ＲＴＴタイマ及び１つのＤＲＸ再送タイマが各ＵＬ ＨＡＲＱプロセスに関連付けられることをも提案する。
【0074】
但し、注記されることとして、提案４～７が合意可能であれば、ＵＬ ＨＡＲＱバッファをフラッシュする強い必要性は存在せず、よって、本開示は、さしあたりそうした手段を導入することを提案しない。代替的に、本開示は、提案４～７が採用される状況ではＵＬ ＨＡＲＱバッファのフラッシュ（flushing）を行わなくてよいことを提案する。
【0075】
ＬＡＡ研究項目のスコープにおいて、ｅＮＢが単一のＤＬサブフレームにおいて複数のＰＵＳＣＨ送信についてのＵＬグラントを送信し得るようなマルチサブフレームスケジューリングをサポートすることも議論された。この拡張は、トラフィックがＵＬに偏る都度リソース利用率及びスループットを最大化するために、有益であると考えられる。現在のところ、Ｌ１とＭＡＣとの間のインタラクションは、Ｌ１がグラント及び割り当てのタイミングをケアする手法でモデル化されている。ＤＣＩが（例えば、ＴＤＤについて）２つのＵＬグラントを含む場合、Ｌ１は、２つの適切なサブフレームにおいてそれらをＭＡＣへ提供する。同じモデル化が適用されるものとすると、マルチサブフレームＵＬスケジューリングは、ＭＡＣの仕様には何らの追加的なインパクトも有するものと予期されない。なお、提案４～７において提案したＵＬ ＨＡＲＱフィードバックタイマは、これらＵＬプロセスのいずれかのための再送が生じ得る最も早い時にＵＥがウェイクアップすることを保証する。
【0076】
＜ＤＬ ＨＡＲＱのためのＵＬフィードバック＞
ＤＬ ＨＡＲＱプロトコルは、３ＧＰＰ Ｒｅｌ－８より既に非同期的であり、よって、ＬＡＡによる使用のために準備が整っており、ＨＡＲＱフィードバック（ＡＣＫ／ＮＡＣＫ）をライセンス済みのＰＣｅｌｌのＰＵＣＣＨ上で高い信頼性で送信することができる。しかしながら、スタンドアローン動作について（例えば、スタンドアローンＬＡＡセルについて）（及び、デュアルコネクティビティを伴うＬＡＡについて）、アップリンク制御情報（ＵＣＩ）は、未ライセンススペクトル上で送信される。今日では、規制上のルールは、制御情報の送信が時間のうちの５％を超えてメディアを占有しない場合には、（ユーザプレーンデータ向けではない）制御情報についてＬＢＴを省略することを許容する。このルールに基づいてＰＵＣＣＨを設計することは、プロトコルの視点からは魅力的であるはずだが、結果として生じる衝突がシステム性能にネガティブなインパクトを与えかねない。そのうえ、この５％ルールを修正し又は否定する試みが無いとも言い切れない。従って、ＵＣＩなどの制御シグナリングへＬＢＴを適用することを検討することが提案さ
れる。
ＤＬ ＨＡＲＱプロトコルは、３ＧＰＰ Ｒｅｌ－８より既に非同期的であり、よって、ＬＡＡによる使用のために準備が整っており、ＨＡＲＱフィードバック（ＡＣＫ／ＮＡＣＫ）をライセンス済みのＰＣｅｌｌのＰＵＣＣＨ上で高い信頼性で送信することができる。しかしながら、スタンドアローン動作について（例えば、スタンドアローンＬＡＡセルについて）（及び、デュアルコネクティビティを伴うＬＡＡについて）、アップリンク制御情報（ＵＣＩ）は、未ライセンススペクトル上で送信される。今日では、規制上のルールは、制御情報の送信が時間のうちの５％を超えてメディアを占有しない場合には、（ユーザプレーンデータ向けではない）制御情報についてＬＢＴを省略することを許容する。このルールに基づいてＰＵＣＣＨを設計することは、プロトコルの視点からは魅力的であるはずだが、結果として生じる衝突がシステム性能にネガティブなインパクトを与えかねない。そのうえ、この５％ルールを修正し又は否定する試みが無いとも言い切れない。従って、ＵＣＩなどの制御シグナリングへＬＢＴを適用することを検討することが提案さ
れる。
【0077】
［提案８：ＵＣＩがＤＬ ＨＡＲＱプロセスを識別する］
今日では、ＬＴＥのＤＬ ＨＡＲＱの設計は、ＤＬ ＨＡＲＱプロセスと対応するＨＡＲＱフィードバックとの間の固定的なタイミング関係に専ら依拠する。ＬＢＴに起因して、ＤＬ送信とＨＡＲＱフィードバックとの間の時間は変化することになり、従って、ＵＬにおいて送信されるＨＡＲＱフィードバック内にＨＡＲＱプロセスＩＤを含めることは必須であると考えられる。
今日では、ＬＴＥのＤＬ ＨＡＲＱの設計は、ＤＬ ＨＡＲＱプロセスと対応するＨＡＲＱフィードバックとの間の固定的なタイミング関係に専ら依拠する。ＬＢＴに起因して、ＤＬ送信とＨＡＲＱフィードバックとの間の時間は変化することになり、従って、ＵＬにおいて送信されるＨＡＲＱフィードバック内にＨＡＲＱプロセスＩＤを含めることは必須であると考えられる。
【0078】
ある種のバンドリングがＲＴＴを増加させることから、（サブフレームｎ＋４以内の）即座のフィードバックが概して好ましい。しかしながら、それは、ｅＮＢ及びＵＥが送信方向を（ＤＬからＵＬへ、ＵＬからＤＬへ）より高い頻度で切り替えることをも要し、それがオーバヘッドを増加させる。いずれにしろ、ＨＡＲＱフィードバック内にＨＡＲＱプロセスＩＤを含めることを必要とする場合、複数のＤＬプロセスについてのＨＡＲＱフィードバックを単一のＵＬメッセージへバンドリングすることは容易に可能である。ＨＡＲＱフィードバック及び対応するプロセスＩＤは、明示的に列挙されるか、又は例えばビットマップ（プロセスごとに又はトランスポートブロックごとに１ビット）として提供されるかのいずれかであり得る。よって、本開示は、ＵＣＩが明示的にか又はビットマップとしてかのいずれかでＤＬ ＨＡＲＱプロセス識別子を収容することを提案する。
【0079】
［提案９：ｅＮＢはＵＥがＵＣＩ内にＨＡＲＱフィードバックをバンドリングするか及びいくつバンドリングするかを制御する］
プロセスごとの即座のフィードバックはＩＰ（Internet Protocol）レイヤ上で観測されるレイテンシを低減する一方で、フィードバックのバンドリングはスペクトル効率を改善する。これら“モード”のいずれが好ましいかは、例えばシステム負荷及び具体的なＵＥのキューに依存する。従って、ｅＮＢは、モード間の切り替えを行う手段を有するべきであり、即ち、ＨＡＲＱフィードバックを頻繁に要求するか、又は複数のプロセスについてのフィードバックをＵＥにバンドリングさせるかである。
プロセスごとの即座のフィードバックはＩＰ（Internet Protocol）レイヤ上で観測されるレイテンシを低減する一方で、フィードバックのバンドリングはスペクトル効率を改善する。これら“モード”のいずれが好ましいかは、例えばシステム負荷及び具体的なＵＥのキューに依存する。従って、ｅＮＢは、モード間の切り替えを行う手段を有するべきであり、即ち、ＨＡＲＱフィードバックを頻繁に要求するか、又は複数のプロセスについてのフィードバックをＵＥにバンドリングさせるかである。
【0080】
［提案１０：各ＵＬサービングセルが対応するＤＬサービングセルについてのＨＡＲＱフィードバックを搬送する］
“物理レイヤ上のＰＵＣＣＨの実現”との見出しを付した上のセクションにおいて議論したように、各ＵＬサービングセルが対応するＤＬサービングセルについてのＨＡＲＱフィードバックを搬送することが提案される。ＬＴＥではこれとは異なり、典型的には、ＰＣｅｌｌのＰＵＣＣＨが全てのＳＣｅｌｌについてのＵＣＩを搬送する。但し、チャネル利用率及びＰＵＣＣＨフォーマット設計の点で、ＬＴＥの未ライセンスのスタンドアローンではそれを別々に保つことが提案される。
“物理レイヤ上のＰＵＣＣＨの実現”との見出しを付した上のセクションにおいて議論したように、各ＵＬサービングセルが対応するＤＬサービングセルについてのＨＡＲＱフィードバックを搬送することが提案される。ＬＴＥではこれとは異なり、典型的には、ＰＣｅｌｌのＰＵＣＣＨが全てのＳＣｅｌｌについてのＵＣＩを搬送する。但し、チャネル利用率及びＰＵＣＣＨフォーマット設計の点で、ＬＴＥの未ライセンスのスタンドアローンではそれを別々に保つことが提案される。
【0081】
この要求は、ＤＬ割り当ての一部として明示的であるか、又はＵＣＩを送信するために適切なリソースの利用可能性に基づいてＵＥがそれを決定できるかのいずれかであり得る。その詳細は可変であって、ＰＵＣＣＨ設計にも依存してよく、それが以下で議論される。
【0082】
ダウンリンクＨＡＲＱプロセスについてのＡＣＫ／ＮＡＣＫフィードバックの提供にここで焦点が当てられているが、その上で、専用スケジューリング要求（Ｄ－ＳＲ）及び／又はＣＳＩもまた送信される必要がある。
【0083】
［提案１１：有効なＵＬグラントを伴うＵＥは仕掛かり中のＨＡＲＱ（及び恐らくは他のＵＣＩ）をＰＵＳＣＨへ多重化する］
原理上、同じＵＥからＰＵＳＣＨと同じサブフレームにおいて、他のＵＥからＰＵＳＣ
Ｈと同じサブフレームにおいて、同じＵＥ向けの物理ダウンリンク共有チャネル（ＰＤＳＣＨ）と同じサブフレームにおいて、他のＵＥ向けのＰＤＳＣＨと同じサブフレームにおいて、又は、（ＵＥがＵＬグラントを受信せずＰＤＳＣＨも検出しなかった）空のサブフレームにおいて、ＨＡＲＱフィードバック（ＵＣＩ）を送信することは可能であるべきである。
原理上、同じＵＥからＰＵＳＣＨと同じサブフレームにおいて、他のＵＥからＰＵＳＣ
Ｈと同じサブフレームにおいて、同じＵＥ向けの物理ダウンリンク共有チャネル（ＰＤＳＣＨ）と同じサブフレームにおいて、他のＵＥ向けのＰＤＳＣＨと同じサブフレームにおいて、又は、（ＵＥがＵＬグラントを受信せずＰＤＳＣＨも検出しなかった）空のサブフレームにおいて、ＨＡＲＱフィードバック（ＵＣＩ）を送信することは可能であるべきである。
【0084】
ＵＥが有効なＰＵＳＣＨグラントを有する場合、ＵＣＩ情報（何らかのものが利用可能な場合）を、追加的なリソースエレメントを使用するよりもむしろ、それらＰＵＳＣＨリソースへマッピングすることが望ましい。ＬＴＥでのように、ＰＵＳＣＨへのこのマッピングは、ＰＵＣＣＨのために追加的なリソースエレメントを割り当てることと比較して、より良好なキュービックメトリックなど、好適な送信特性を提供する。
【0085】
図６は、ＰＵＳＣＨ内のＵＣＩの一例を描いており、ここで説明される主題の一実施形態に従って、ＵＥは、連続する４つのサブフレーム内のＤＬデータ（ＰＤＳＣＨ）と共に後続する４つのサブフレームについて有効なＵＬグラントを受信している。ＨＡＲＱフィードバックを（例えば、最後のＰＵＳＣＨサブフレームへ）バンドリングすることは可能である一方で、できる限り早期にＨＡＲＱフィードバックを送信することが好ましい。また、ＵＥがいずれにしろ割り当て済みのＵＬリソースを有することから、以下に示すマッピングが好ましいと見られる。よって、本開示は、有効なＵＬグラントを伴うＵＥが仕掛かり中のＨＡＲＱ及び恐らくは他のＵＣＩをＰＵＳＣＨへ多重化し得ることを提案する。
【0086】
［提案１２：有効なＵＬグラントを伴わないＵＥは仕掛かり中のＨＡＲＱフィードバックをショートＬＢＴ成功に応じて（ロング）ＰＵＣＣＨ上で送信する］
図７は、ここで説明される主題の他の実施形態に係るＰＵＳＣＨ内のＵＣＩの一例を描いている。図７は図６のケースと同様のケースを描いているが、図７に示した実施形態では、最初の４つのサブフレームにおいてＰＤＳＣＨを受信したＵＥからのＵＣＩは、後続の４つのサブフレームの全ての利用可能なシンボルにまたがる（ロング）ＰＵＣＣＨへマッピングされ、一方でＰＵＳＣＨリソースは他のＵＥへ割り当てられるものと想定される。
図７は、ここで説明される主題の他の実施形態に係るＰＵＳＣＨ内のＵＣＩの一例を描いている。図７は図６のケースと同様のケースを描いているが、図７に示した実施形態では、最初の４つのサブフレームにおいてＰＤＳＣＨを受信したＵＥからのＵＣＩは、後続の４つのサブフレームの全ての利用可能なシンボルにまたがる（ロング）ＰＵＣＣＨへマッピングされ、一方でＰＵＳＣＨリソースは他のＵＥへ割り当てられるものと想定される。
【0087】
ＰＵＳＣＨ送信リソースは明示的にグラントされるのに対し、ＵＥは、ＰＵＣＣＨリソースを、ＬＴＥにおいて定義されているものと同様のマッピングによりＤＬグラントから暗黙的に導出するものと想定される。ＰＵＣＣＨ送信を実行する前に、ＵＥは、ＬＢＴを実行しなければならない。Ｒｅｌ－１３研究項目においてＰＵＳＣＨについて議論されたように、先行するＰＤＳＣＨ送信が通常のＬＢＴの対象であったことから、短いＬＢＴだけを実行することが可能であると考えられる。言い換えると、ＰＵＣＣＨはスケジューリングされたＰＵＳＣＨと同じＬＢＴパラメータを使用し、それが単一のサブフレームにおいて複数の送信を多重化することを可能にする。
【0088】
図７の例では、ＵＥは、後続のＤＬサブフレームに先立ってｅＮＢがＤＬ ＬＢＴを実行できるように、４番目のＰＵＣＣＨ送信を短縮しなければならない。これは、サブフレーム８のためのＵＬリソースのスケジューリングに応じて、ｅＮＢが後続のサブフレーム９がＵＬサブフレームになるのか又はＤＬサブフレームになるのかを決定することも必要とすることを示唆する。ＤＬサブフレームが次に来るものとされる場合、先行するＵＬサブフレームはより早く終了する必要がある。この制約は望ましくないと考えられる一方で、それはＲｅｌ－１３において確立されたベースラインに従う。ｅＮＢは、サブフレームの短縮を指し示すためにＬＡＡ Ｒｅｌ－１３において導入されたＰＤＣＣＨブロードキャストシグナリングを使用することができる。代替的に、その情報をＤＬ割り当ての一部として提供することができる。
【0089】
［提案１３：ＵＬ ＬＢＴのスキップ］
図８は、ここで説明される主題の他の実施形態に係る、隣接するサブフレームにおいて相異なるＵＥが自身のＰＵＣＣＨフィードバックを提供する場合に追加的なＬＢＴフェーズが必要とされる例を示している。ＤＬからＵＬへ及びＵＬからＤＬへの遷移時のＬＢＴに加えて、相異なるＵＥが自身のＰＵＣＣＨフィードバックを隣接するサブフレームにおいて提供する場合、追加的なＬＢＴフェーズが必要とされる。これが、図８においてハイライトされており、第１のＵＥは最初の２つのサブフレームにおいてＰＤＳＣＨを受信し、第２のＵＥは３番目及び４番目のサブフレームにおいてＰＤＳＣＨを受信する。ｅＮＢは、ＤＬ送信を立て続けに実行し得るものの、第２のＵＥは自身のＰＵＣＣＨ送信を実行する前にチャネルが開いているかをセンシングする必要がある。
図８は、ここで説明される主題の他の実施形態に係る、隣接するサブフレームにおいて相異なるＵＥが自身のＰＵＣＣＨフィードバックを提供する場合に追加的なＬＢＴフェーズが必要とされる例を示している。ＤＬからＵＬへ及びＵＬからＤＬへの遷移時のＬＢＴに加えて、相異なるＵＥが自身のＰＵＣＣＨフィードバックを隣接するサブフレームにおいて提供する場合、追加的なＬＢＴフェーズが必要とされる。これが、図８においてハイライトされており、第１のＵＥは最初の２つのサブフレームにおいてＰＤＳＣＨを受信し、第２のＵＥは３番目及び４番目のサブフレームにおいてＰＤＳＣＨを受信する。ｅＮＢは、ＤＬ送信を立て続けに実行し得るものの、第２のＵＥは自身のＰＵＣＣＨ送信を実行する前にチャネルが開いているかをセンシングする必要がある。
【0090】
図７の例と図８の例とを比較すると、ＵＥがＵＬサブフレームの冒頭でＬＢＴを実行すべきかを自ら判定することができないことが明らかとなる。先行するサブフレームをＵＬ送信のために使用した場合であっても、他のＵＥが後続のサブフレームにおいてＬＢＴを実行する必要があるか否かに依存して、そのサブフレームに先立って別のＬＢＴを行わなければならないかもしれない。従って、ｅＮＢが明示的にＵＬグラント（ＰＵＳＣＨ向け）において及びＤＬ割り当て（ＰＵＣＣＨ向け）においてＵＥが対応するＵＬサブフレームについてＬＢＴをスキップしてよいかを指し示すことが提案される。エラーケースを回避する目的で、ＵＥは、先行するサブフレームにおいてＵＬ送信を実行していなかった場合、スケジューリングされるＵＬサブフレームにおいて（ショート）ＬＢＴを実行すべきである。このミスマッチは、先行するサブフレームにおけるＵＥによるＬＢＴに起因して、又はＵＬグラント若しくはＤＬ割り当ての逸失に起因して発生し得るはずである。よって、本開示は、次の条件の双方が満たされる場合にＵＥが自身のＵＬ ＬＢＴをスキップし得ることを提案する：１）ＵＥが先行するサブフレームにおいてＵＬ送信（ＰＵＣＣＨ又はＰＵＳＣＨ）を実行した；及び、２）ｅＮＢが明示的にＵＬグラント又はＤＬ割り当てにおいてＬＢＴのスキップを許可した。
【0091】
図７及び図８の例において、ＵＥが自身のＰＵＣＣＨ送信が他のＵＥのＰＵＳＣＨ送信と同時に起こるかを知らない（知らなくてよい）こともまた指摘するに値する。言い換えると、上の提案２及び５は、ＰＵＣＣＨを送信するＵＥの視点から等価である。
【0092】
［提案１４：ＵＥは先行するサブフレームの末尾ではなくＵＬサブフレームの冒頭においてＵＬ ＬＢＴを実行する］
Ｒｅｌ－１３ ＬＡＡにおいて、ｅＮＢがＤＬサブフレームの開始に先立ってＤＬ ＬＢＴを実行すること、及びＤＬバーストの最後のＰＤＳＣＨサブフレームを短縮して後続のＬＢＴのための余地を空けることが決定された。同様に、ＵＥの最後のＵＬ送信（ＰＵＳＣＨ又はＰＵＣＣＨ）を短縮することを考えることができるであろう。すると、ＵＥもまた、そのＵＬサブフレームに先立ってＵＬ ＬＢＴを実行すべきである。しかしながら、このアプローチは、有意な欠点を有する：ｅＮＢが後続のサブフレームもまたＵＬサブフレームとなるのか（上の議論参照）を決定するのみならず、それが同一のＵＥへ割り当てられるのか又は他のＵＥへ割り当てられるのかをも決定することを要する。そうであれば、現時点のサブフレームがそれらサブフレーム全体にわたることができ、そうでなければ、現時点のサブフレームは短縮されなければならない。そうした“先を見ること（look-ahead）”は、重い処理であり、スケジューリング遅延を増加させる。次に、ｅＮＢがＰＵＣＣＨを送信しようとする自身のＵＥのうちの１つに対してＬＢＴを勝ち得るチャンスを有することが望ましいはずである。これら理由のために、本開示は、先行するサブフレームの末尾よりもむしろＵＬサブフレームの冒頭においてＵＬ ＬＢＴを実行することを提案する。
Ｒｅｌ－１３ ＬＡＡにおいて、ｅＮＢがＤＬサブフレームの開始に先立ってＤＬ ＬＢＴを実行すること、及びＤＬバーストの最後のＰＤＳＣＨサブフレームを短縮して後続のＬＢＴのための余地を空けることが決定された。同様に、ＵＥの最後のＵＬ送信（ＰＵＳＣＨ又はＰＵＣＣＨ）を短縮することを考えることができるであろう。すると、ＵＥもまた、そのＵＬサブフレームに先立ってＵＬ ＬＢＴを実行すべきである。しかしながら、このアプローチは、有意な欠点を有する：ｅＮＢが後続のサブフレームもまたＵＬサブフレームとなるのか（上の議論参照）を決定するのみならず、それが同一のＵＥへ割り当てられるのか又は他のＵＥへ割り当てられるのかをも決定することを要する。そうであれば、現時点のサブフレームがそれらサブフレーム全体にわたることができ、そうでなければ、現時点のサブフレームは短縮されなければならない。そうした“先を見ること（look-ahead）”は、重い処理であり、スケジューリング遅延を増加させる。次に、ｅＮＢがＰＵＣＣＨを送信しようとする自身のＵＥのうちの１つに対してＬＢＴを勝ち得るチャンスを有することが望ましいはずである。これら理由のために、本開示は、先行するサブフレームの末尾よりもむしろＵＬサブフレームの冒頭においてＵＬ ＬＢＴを実行することを提案する。
【0093】
［提案１５：ｅＮＢが短縮ＤＬサブフレームを指し示す場合、ＵＥは仕掛かり中のＨＡ
ＲＱフィードバック（及び恐らくは他のＵＣＩ）をｓＰＵＣＣＨ上で送信する］
本開示においてこれまでに、フィードバックバンドリングの概念が紹介された。図７の例では、ＵＥは自身のＨＡＲＱフィードバックをできる限り早く（即ち、ｎ＋４）提供しており、これはレイテンシの点で望ましい。いずれにしろサブフレームが他のＵＥのＰＵＳＣＨ送信のために使用される場合、即座のＨＡＲＱフィードバックに起因する追加的なオーバヘッドは無視できるほどである。しかしながら、ｅＮＢが中間的なサブフレームを必要としない場合、それらを空白のまま残し及びＵＥに単一のＰＵＣＣＨ送信内にＨＡＲＱフィードバックをバンドリングさせることが望ましいであろう。
ＲＱフィードバック（及び恐らくは他のＵＣＩ）をｓＰＵＣＣＨ上で送信する］
本開示においてこれまでに、フィードバックバンドリングの概念が紹介された。図７の例では、ＵＥは自身のＨＡＲＱフィードバックをできる限り早く（即ち、ｎ＋４）提供しており、これはレイテンシの点で望ましい。いずれにしろサブフレームが他のＵＥのＰＵＳＣＨ送信のために使用される場合、即座のＨＡＲＱフィードバックに起因する追加的なオーバヘッドは無視できるほどである。しかしながら、ｅＮＢが中間的なサブフレームを必要としない場合、それらを空白のまま残し及びＵＥに単一のＰＵＣＣＨ送信内にＨＡＲＱフィードバックをバンドリングさせることが望ましいであろう。
【0094】
図９は、ここで説明される手段の一実施形態に係るバンドリングされるＰＵＣＣＨ送信を例示している。バンドリングは特殊ケースであると考えられることから、ｅＮＢがＤＬ割り当てにおいてＵＥへＨＡＲＱフィードバックを先延ばしすることを命令することが提案される。図９の例では、最初の３つのダウンリンクサブフレームにおいてその標識が提供されており、よって、ＵＥはサブフレーム５、６及び７におけるＰＵＣＣＨを省略する。サブフレームの冒頭において、ＵＥは、（ショート）ＬＢＴを実行し、４つ全てのＤＬ ＨＡＲＱプロセスについて仕掛かり中のＨＡＲＱフィードバックを送信する。
【0095】
今日、ユーザトラフィックはＤＬに偏重している。よって、ｅＮＢがＵＬサブフレームよりも多くのＤＬサブフレームをスケジューリングしようとする機会が多いであろう。ＰＵＣＣＨのために複数のサブフレームの全体を費やすことは、望ましくないオーバヘッドを生み出すはずである。従って、これまでにここで説明したロングＰＵＣＣＨに加えて、ショートＰＵＣＣＨを提供することが提案される。このｓＰＵＣＣＨは、図１０に示したように、短縮されるＤＬサブフレームの末尾に現れ得る。
【0096】
図１０は、ここでの主題の一実施形態に係る、短縮されたＤＬサブフレームの末尾にｓＰＵＣＣＨが位置する例を示している。サブフレーム１、２、３及び５、６、７は、ＵＥにそのＨＡＲＱフィードバックを先延ばしすることを命令する。サブフレーム４及び８における割り当てはこの標識を有さず、結果として、ＵＥはサブフレーム８において（サブフレーム１～４についてのＨＡＲＱフィードバックを反映する）ＵＣＩの送信を、サブフレーム１２において（サブフレーム５～８についてのＨＡＲＱフィードバックを反映する）ＵＣＩの送信を試行する。ＵＥは、これらサブフレームが空白であることを見出した場合、又はそれらサブフレームのいずれかについてＰＵＳＣＨグラントを受信した場合、以前の段落において説明したようにＵＣＩフィードバックを提供したであろう。しかし、この例では、ｅＮＢは、これらサブフレームを主にＤＬデータ転送のために使用することを決定した。サブフレーム７及び１１では、ｅＮＢは、ＰＤＣＣＨブロードキャストシグナリングを介して全てのＵＥへ、サブフレーム８及び１２が短縮されることになることを通知する。仕掛かり中のＨＡＲＱフィードバックを有するＵＥは、よって、そのフィードバックをｓＰＵＣＣＨ上で送信することになる。
【0097】
よって、本開示は、ｅＮＢが短縮ＤＬサブフレームを指し示す場合に、ＵＥがｓＰＵＣＣＨ上で仕掛かり中のＨＡＲＱフィードバック（及び恐らくは他のＵＣＩ）を送信し得ることを提案する。
【0098】
［提案１６：ＵＥは、ｓＰＵＣＣＨの送信に先立ってＬＢＴを実行しなくてよい］
ＵＣＩは純粋に制御シグナリングであること、及びそれがｅＮＢによるＤＬ送信のすぐ後に続くことから、ＵＥは、その送信に先立っていかなるＬＢＴをも実行しない。当然ながら、ｅＮＢがそのＤＬバーストの冒頭でＬＢＴを実行しなければならない。
ＵＣＩは純粋に制御シグナリングであること、及びそれがｅＮＢによるＤＬ送信のすぐ後に続くことから、ＵＥは、その送信に先立っていかなるＬＢＴをも実行しない。当然ながら、ｅＮＢがそのＤＬバーストの冒頭でＬＢＴを実行しなければならない。
【0099】
［提案１７：ＵＥは、受信されるＤＬ割り当てと共に無線リソース制御（ＲＲＣ）構成に基づいて、ｓＰＵＣＣＨリソースを判定する（ＰＵＣＣＨと同様）］
ｓＰＵＣＣＨに続くサブフレームがＰＵＳＣＨのためにスケジューリングされる場合、それらＵＥは、そのＵＬサブフレームの冒頭において（ショート）ＬＢＴを実行することになる。ｅＮＢは、ｓＰＵＣＣＨの後に続けてＰＤＳＣＨ送信を意図している場合、短いギャップの後にそれを行い得る。これは、ｓＰＵＣＣＨの末尾において起きるべきである。上で言及したように、ｅＮＢは、それによりチャネルを取り戻すことになり、ＵＥが後続のサブフレームにおいて通常のＰＵＣＣＨを送信することを防止し得る。
ｓＰＵＣＣＨに続くサブフレームがＰＵＳＣＨのためにスケジューリングされる場合、それらＵＥは、そのＵＬサブフレームの冒頭において（ショート）ＬＢＴを実行することになる。ｅＮＢは、ｓＰＵＣＣＨの後に続けてＰＤＳＣＨ送信を意図している場合、短いギャップの後にそれを行い得る。これは、ｓＰＵＣＣＨの末尾において起きるべきである。上で言及したように、ｅＮＢは、それによりチャネルを取り戻すことになり、ＵＥが後続のサブフレームにおいて通常のＰＵＣＣＨを送信することを防止し得る。
【0100】
ＰＵＣＣＨと同様、ＵＥは、受信されるＤＬ割り当てと共にＲＲＣ構成に基づいて、ｓＰＵＣＣＨリソースを判定する。
【0101】
＜Ｄ－ＳＲ＞
［提案１８：ネットワークは、ＲＲＣシグナリングを用いてＤ－ＳＲリソースと共にＵＥを構成し得る］
ＬＴＥでは、ｅＮＢは、典型的には、ＰＵＣＣＨ上のＤ－ＳＲリソースと共にＲＲＣ接続済みのＵＥを構成する。その周期性（例えば、１０、２０、４０サブフレーム）及び実際の時間／周波数リソースは、ＲＲＣを介して準静的に構成される。ＵＥの空のＰＤＣＰ（Packet Data Convergence Protocol）キューへ上位レイヤからデータ（ＩＰパケット）が到着すると、バッファステータスレポート（ＢＳＲ）がトリガされる。ＵＥは、ＢＳＲを送信するための有効なＵＬグラントを有しない場合、次のＤ－ＳＲ機会においてＰＵＣＣＨを用いてＤ－ＳＲを送信する。同じ原理が、ＬＴＥの未ライセンススタンドアローンにも適用され得るであろう。但し、ＵＥは、ＰＵＣＣＨ上のＤ－ＳＲの送信に先立ってＬＢＴを実行するものと想定され得る。
［提案１８：ネットワークは、ＲＲＣシグナリングを用いてＤ－ＳＲリソースと共にＵＥを構成し得る］
ＬＴＥでは、ｅＮＢは、典型的には、ＰＵＣＣＨ上のＤ－ＳＲリソースと共にＲＲＣ接続済みのＵＥを構成する。その周期性（例えば、１０、２０、４０サブフレーム）及び実際の時間／周波数リソースは、ＲＲＣを介して準静的に構成される。ＵＥの空のＰＤＣＰ（Packet Data Convergence Protocol）キューへ上位レイヤからデータ（ＩＰパケット）が到着すると、バッファステータスレポート（ＢＳＲ）がトリガされる。ＵＥは、ＢＳＲを送信するための有効なＵＬグラントを有しない場合、次のＤ－ＳＲ機会においてＰＵＣＣＨを用いてＤ－ＳＲを送信する。同じ原理が、ＬＴＥの未ライセンススタンドアローンにも適用され得るであろう。但し、ＵＥは、ＰＵＣＣＨ上のＤ－ＳＲの送信に先立ってＬＢＴを実行するものと想定され得る。
【0102】
［提案１９：ＵＥは、ＬＢＴ成功後にＰＵＣＣＨ上のそれら機会においてＤ－ＳＲを送信し得る］
図１１は、ここで説明される主題の一実施形態に係る４サブフレームごとのＤ－ＳＲ機会と共にＵＥが構成される例を描いている。ｅＮＢと接続しているＵＥのどれもデータをアクティブに送信し又は受信していない時には、ｅＮＢは、ＤＬ送信を最小化し（ＤＲＳのみ）、ほとんどのサブフレームは空白となる。この例では、ＵＥは、図示した３番目のＤ－ＳＲ機会においてＤ－ＳＲの送信を試行し、そのサブフレームの冒頭での成功裏のＬＢＴの後にそれを行うことに成功する。
図１１は、ここで説明される主題の一実施形態に係る４サブフレームごとのＤ－ＳＲ機会と共にＵＥが構成される例を描いている。ｅＮＢと接続しているＵＥのどれもデータをアクティブに送信し又は受信していない時には、ｅＮＢは、ＤＬ送信を最小化し（ＤＲＳのみ）、ほとんどのサブフレームは空白となる。この例では、ＵＥは、図示した３番目のＤ－ＳＲ機会においてＤ－ＳＲの送信を試行し、そのサブフレームの冒頭での成功裏のＬＢＴの後にそれを行うことに成功する。
【0103】
［提案２０：サブフレームが短縮ＤＬサブフレームであることをｅＮＢがアナウンスした場合に、ＵＥはｓＰＵＣＣＨ上でそれら機会においてＤ－ＳＲを送信し得る］
一旦チャネルがＵＬ又はＤＬデータ送信により占有されると、Ｄ－ＳＲに先立つＵＥによるＬＢＴは、進行中のＰＤＳＣＨ／ＰＵＳＣＨデータバーストに起因して失敗する可能性が高い。しかしながら、一見すると問題のように見えるのは、実際には望ましい特性である：ｅＮＢは、自身のＵＥよりもアグレッシブな（Ｗｉ－Ｆｉに対しては依然としてフェアな）ＬＢＴ構成を用いることにより、データが利用可能になるとすぐに、チャネルを捕捉し及び効率的にＰＤＳＣＨ／ＰＵＳＣＨをスケジューリングすることができる。ＵＥがｅＮＢへ利用可能なデータについて通知できることを保証するために、ｅＮＢは、ＵＥのＤ－ＳＲ機会のうちの少なくともいくつかを短縮ＤＬサブフレーム（shortened DL subframes）として宣言するか、又はそれらを空白のまま残すべきである。図１１のシーケンスの後半部分に示したように、ＵＥは、Ｄ－ＳＲ（及びＨＡＲＱフィードバック）を送信するためにそれら機会を使用するであろう。
一旦チャネルがＵＬ又はＤＬデータ送信により占有されると、Ｄ－ＳＲに先立つＵＥによるＬＢＴは、進行中のＰＤＳＣＨ／ＰＵＳＣＨデータバーストに起因して失敗する可能性が高い。しかしながら、一見すると問題のように見えるのは、実際には望ましい特性である：ｅＮＢは、自身のＵＥよりもアグレッシブな（Ｗｉ－Ｆｉに対しては依然としてフェアな）ＬＢＴ構成を用いることにより、データが利用可能になるとすぐに、チャネルを捕捉し及び効率的にＰＤＳＣＨ／ＰＵＳＣＨをスケジューリングすることができる。ＵＥがｅＮＢへ利用可能なデータについて通知できることを保証するために、ｅＮＢは、ＵＥのＤ－ＳＲ機会のうちの少なくともいくつかを短縮ＤＬサブフレーム（shortened DL subframes）として宣言するか、又はそれらを空白のまま残すべきである。図１１のシーケンスの後半部分に示したように、ＵＥは、Ｄ－ＳＲ（及びＨＡＲＱフィードバック）を送信するためにそれら機会を使用するであろう。
【0104】
ＵＥのＰＵＳＣＨリソースへＨＡＲＱフィードバックを多重化する必要性が存在する一方で、Ｄ－ＳＲについてはそれをする必要がない。その理由は、有効なＵＬグラントを有するＵＥがＰＵＳＣＨ上で送信されるＭＡＣ ＰＤＵ（Protocol Data Unit）の内部に（より詳細な）バッファステータスレポートを含めることになるからである。
【0105】
＜ＣＳＩ＞
ＨＡＲＱフィードバック及びＤ－ＳＲ以外では、ＰＵＣＣＨはＣＳＩをも搬送する。ＬＴＥでは、それはＰＵＣＣＨへ及びＰＵＳＣＨへマッピングされ得る。
ＨＡＲＱフィードバック及びＤ－ＳＲ以外では、ＰＵＣＣＨはＣＳＩをも搬送する。ＬＴＥでは、それはＰＵＣＣＨへ及びＰＵＳＣＨへマッピングされ得る。
【0106】
［提案２１：ベースラインとして、非周期的なＣＳＩフィードバックのみがサポートされる。それはｅＮＢにより提供されるＵＬグラントに従ってＰＵＳＣＨへマッピングされる］
“物理レイヤ上のＰＵＣＣＨの実現”との見出しを付した上のセクションにおいて議論したように、非周期的なＣＳＩレポーティングは重要であると考えられる。ＬＴＥと同様に、非周期的なＣＳＩは、（ＵＬユーザデータの有無によらず）ＰＵＳＣＨへマッピングされる。従って、未ライセンススタンドアローンＬＴＥについて、この原理に従うことが提案される。
“物理レイヤ上のＰＵＣＣＨの実現”との見出しを付した上のセクションにおいて議論したように、非周期的なＣＳＩレポーティングは重要であると考えられる。ＬＴＥと同様に、非周期的なＣＳＩは、（ＵＬユーザデータの有無によらず）ＰＵＳＣＨへマッピングされる。従って、未ライセンススタンドアローンＬＴＥについて、この原理に従うことが提案される。
【0107】
図１２Ａ及び図１２Ｂは、本開示の実施形態が実装され得るセルラー通信ネットワークの例を示している。図１２Ａ及び図１２Ｂに示した例示的な実施形態は、セルラー通信ネットワーク１０（ここでは通信システムともいう）において実装される。図１２Ａの例では、セルラー通信ネットワーク１０は、基地局１２（例えば、ＬＴＥの専門用語におけるｅＮＢ）を含み、基地局１２は、ライセンス済み周波数スペクトル内のキャリアｆ１上で動作するセル１４、及び未ライセンス周波数スペクトル（例えば、５ギガヘルツ（ＧＨｚ）周波数スペクトル）内のキャリアｆ２上で動作するセル１６へサービスする。１つの例示的なＬＡＡ方式によれば、セル１４は、ワイヤレスデバイス１８（例えば、ＬＴＥ ＵＥ）のＰＣｅｌｌとして構成され、セル１６は、ＬＡＡのためのＣＡ方式に従ってワイヤレスデバイス１８のＳＣｅｌｌとして構成される。そのため、ワイヤレスデバイス１８を基準とすると、セル１４はワイヤレスデバイス１８のＰＣｅｌｌ１４として言及され、セル１６はワイヤレスデバイス１８のＳＣｅｌｌ１６として、より正確にはＬＡＡ ＳＣｅｌｌ１６として言及される。
【0108】
図１２Ｂでは、セル１４及び１６は、別個の基地局１２－１及び１２－２によってそれぞれサービスされる。この点において、セル１６は、スタンドアローンＬＡＡセル、又はワイヤレスデバイス１８に関してデュアルコネクティビティ方式に従って利用されるＬＡＡセルであり得る（基地局１２－１及び１２－２は、理想的でないバックホールリンクを介して接続される）。基地局１２－１及び１２－２は、コアネットワーク２０（例えば、ＥＰＣ（Evolved Packet Core））へ通信可能に接続され、いくつかの実施形態において、基地局－基地局インタフェース（例えば、ＬＴＥにおけるＸ２インタフェース）を介するか又はコアネットワーク２０を介するかのいずれかで互いに通信し得る。
【0109】
図１３は、本開示のいくつかの実施形態に係る、上の提案３を実装するための基地局１２－１（又は基地局１２－２）及びワイヤレスデバイス１８の動作を例示している。図示したように、非同期ＨＡＲＱを利用する場合、ワイヤレスデバイス１８は、ＬＡＡセル上の具体的なＵＬ ＨＡＲＱプロセスについてＵＬ送信信号を送信する（ステップ１００）。ワイヤレスデバイス１８は、そのＵＬ送信が成功したものと仮定し、そのため、ＵＬ ＨＡＲＱプロセスについてローカルで維持されるステータスをＡＣＫへ設定する（ステップ１０２）。ワイヤレスデバイス１８は、ＵＬ ＨＡＲＱプロセスに対応する基地局１２－１（又は１２－２）からの（ＮＤＩの切り替えられていない）後続のＵＬグラントを受信してもしなくてもよい（ステップ１０４）。いくつかの実施形態では、ＵＬグラント内のＨＡＲＱプロセスインデックスフィールドにおいて、ＵＬ ＨＡＲＱプロセスインデックスが指し示される。ワイヤレスデバイス１８は、ＵＬ ＨＡＲＱプロセスについての対応するＵＬグラントの受信に応じて、当該ＨＡＲＱプロセスのためのＨＡＲＱ再送を実行するのみである（ステップ１０６）。
【0110】
図１４は、本開示のいくつかの実施形態に係る、上の提案４～７を実装するためのワイヤレスデバイス１８の動作を例示するフローチャートである。図示したように、ワイヤレスデバイス１８は、ワイヤレスデバイス１８があるサブフレームにおいてＬＡＡセル上の有効なＵＬグラントを有するかを判定する（ステップ２００）。有効なＵＬグラントを有しない場合、ワイヤレスデバイス１８は、ＬＡＡセル上の有効なＵＬグラントのモニタリングを継続する。ワイヤレスデバイス１８は、そのサブフレームにおいてＬＡＡセル上の有効なＵＬグラントを有する場合、対応するＨＡＲＱプロセスについてＵＬ ＨＡＲＱフィードバックタイマを開始する（ステップ２０２）。次いで、ワイヤレスデバイス１８は、そのＨＡＲＱプロセスについてアップリンクＨＡＲＱフィードバックタイマの満了をモニタリングする（ステップ２０４）。一旦ＵＬ ＨＡＲＱフィードバックタイマが満了すると、この例では、ワイヤレスデバイス１８は、対応するＤＲＸ再送タイマを開始し、ＤＲＸ再送タイマが稼動している限りＤＲＸアクティブ時間のままでいる（ステップ２０６及び２０８）。なお、図１４はＵＬ ＨＡＲＱフィードバックタイマ及びＤＲＸ再送タイマの双方を利用しているものの、代替的にプロセスは２つのタイマのうちの一方のみを使用してもよく、例えばＵＬ ＨＡＲＱフィードバックタイマのみを使用してもよい（そのケースでは、ＵＬ ＨＡＲＱフィードバックタイマの満了に応じていかなる所望のアクションが行われてもよく、そのアクションはＤＲＸ再送タイマの開始に限られない）。
【0111】
図１５は、本開示のいくつかの実施形態に係る、上の提案８又は９を実装するための基地局１２－１（又は基地局１２－２）及びワイヤレスデバイス１８の動作を例示している。図示したように、いくつかの実施形態において、基地局１２－１（又は基地局１２－２）は、ＵＣＩについてワイヤレスデバイス１８によりＨＡＲＱフィードバックのバンドリングが実行されるべきかを制御するためのフィードバック制御情報をワイヤレスデバイス１８へ送信する（ステップ３００）。フィードバック制御情報は、ＵＣＩにおいていくつのＨＡＲＱフィードバックをワイヤレスデバイス１８がバンドリングすべきかをも指し示してよい。破線により示されているように、ステップ３００はオプション的である。基地局１２－１（又は基地局１２－２）は、１つ以上のＤＬ ＨＡＲＱプロセスについて、ＬＡＡ上でワイヤレスデバイス１８へ１つ以上のＤＬ送信信号を送信する（ステップ３０２）。ある時点において、ワイヤレスデバイス１８は、１つ以上のＤＬ ＨＡＲＱプロセスのＤＬ ＨＡＲＱプロセスＩＤを、例えば明示的に又はビットマップとして収容する（（バンドリングされる）ＨＡＲＱフィードバックを含む）ＵＣＩを送信する（ステップ３０４）。
【0112】
図１６は、本開示のいくつかの実施形態に係る、上の提案１１を実装するためのワイヤレスデバイス１８の動作を例示するフローチャートである。図示したように、ワイヤレスデバイス１８は、あるサブフレームにおいてＬＡＡセル上でワイヤレスデバイス１８が有効なＵＬグラントを有するかを判定する（ステップ４００）。ワイヤレスデバイス１８が有効なＵＬグラントを有しない場合、この例では処理が終了する。ワイヤレスデバイス１８は、そのサブフレームにおいてＬＡＡセル上で有効なＵＬグラントを有する場合、仕掛かり中のＨＡＲＱフィードバック（及び恐らくは他のＵＣＩ）をＰＵＳＣＨ上へ多重化する（ステップ４０２）。
【0113】
図１７は、本開示のいくつかの実施形態に係る、上の提案１２を実装するためのワイヤレスデバイス１８の動作を例示するフローチャートである。図示したように、ワイヤレスデバイス１８は、あるサブフレームにおいてＬＡＡセル上でワイヤレスデバイス１８が有効なＵＬグラントを有するかを判定する（ステップ５００）。ワイヤレスデバイス１８が有効なＵＬグラントを有する場合、この例では処理が終了する。ワイヤレスデバイス１８は、そのサブフレームにおいてＬＡＡセル上で有効なＵＬグラントを有しない場合、仕掛かり中のＨＡＲＱフィードバックを、成功裏のショートＬＢＴの後に（ロング）ＰＵＣＣ
Ｈ上で送信する（ステップ５０２）。
Ｈ上で送信する（ステップ５０２）。
【0114】
なお、図１６及び図１７の処理は、ワイヤレスデバイス１８が、有効なＵＬグラントが存在する場合には仕掛かり中のＨＡＲＱフィードバック（及び恐らくは他のＵＣＩ）をＰＵＳＣＨ上へ多重化する一方、有効なＵＬグラントが存在しない場合には仕掛かり中のＨＡＲＱフィードバックをショートＬＢＴ成功後に（ロング）ＰＵＣＣＨ上で送信するという形で、併せて利用されてもよい。
【0115】
図１８は、本開示のいくつかの実施形態に係る、上の提案１３を実装するための基地局１２－１（又は基地局１２－２）及びワイヤレスデバイス１８の動作を例示している。図示したように、いくつかの実施形態において、基地局１２－１（又は基地局１２－２）は、ＬＡＡセルについてのＵＬグラント又はＤＬ割り当てをワイヤレスデバイス１８へ送信する（ステップ６００）。ワイヤレスデバイス１８は、（１）ワイヤレスデバイス１８が先行するサブフレームにおいてＵＬ送信（ＰＵＣＣＨ又はＰＵＳＣＨ）を実行した、且つ（２）基地局１２－１（又は基地局１２－２）がＵＬグラント（ＰＵＳＣＨ向け）又はＤＬ割り当て（ＰＵＣＣＨ向け）においてＬＡＡセルについてＬＢＴのスキップを明示的に許可した、の双方の場合にＬＡＡセルについてＵＬ ＬＢＴをスキップする（ステップ６０２）。双方の条件が真であるものとすると、ワイヤレスデバイス１８は、ＬＢＴをスキップして、ＬＡＡセル上でＵＬ送信を実行する（ステップ６０４）。
【0116】
図１９は、本開示のいくつかの実施形態に係る、上の提案１５～１７のうちのいくつか又は全てを実装するための基地局１２－１（又は基地局１２－２）及びワイヤレスデバイス１８の動作を例示している。図示したように、基地局１２－１（又は基地局１２－２）は、ＬＡＡセル上のサブフレームについてのＤＬ割り当てと、そのサブフレームが短縮ＤＬサブフレームであるという標識とを、ワイヤレスデバイス１８へ送信する（ステップ７００）。（破線の矢印で示されているように）オプションとして、ワイヤレスデバイス１８は、例えば受信されるＤＬ割り当てと共にＲＲＣ構成に基づいて、ＨＡＲＱフィードバックについて利用すべきｓＰＵＣＣＨリソースを判定する（ステップ７０２）。ワイヤレスデバイス１８は、短縮ＤＬサブフレームの標識の受信後に、ｓＰＵＣＣＨ上で（例えば、判定したｓＰＵＣＣＨリソースを用いて）、仕掛かり中のＨＡＲＱフィードバック（及び恐らくは他のＵＣＩ）を送信する（ステップ７０４）。
【0117】
図２０は、本開示のいくつかの実施形態に係る、上の提案１８～２０のうちのいくつか又は全てを実装するための基地局１２－１（又は基地局１２－２）及びワイヤレスデバイス１８の動作を例示している。図示したように、基地局１２－１（又は基地局１２－２）は、例えばＲＲＣシグナリングを用いて、ワイヤレスデバイス１８をＤ－ＳＲリソースと共に構成する（ステップ８００）。ワイヤレスデバイス１８は、構成されたＤ－ＳＲリソースを利用する（ステップ８０２）。より具体的には、ワイヤレスデバイス１８は、ＬＢＴ成功後に、ＰＵＣＣＨ上のそれら機会においてＤ－ＳＲを送信してもよく、及び／又は、基地局１２－１（又は１２－２）がそのサブフレームを短縮ＤＬサブフレームであるとアナウンスした場合にｓＰＵＣＣＨ上のそれら機会においてＤ－ＳＲを送信してもよい。
【0118】
図２１は、本開示のいくつかの実施形態に係る基地局１２の概略図である。なお、この議論は、基地局１２－１及び１２－２に等しく適用可能である。基地局１２は、ＬＴＥ基地局（例えば、ｅＮＢ若しくはＰＣｅｌｌ基地局）、又はワイヤレスデバイス１８（ＬＴＥでは、ＵＥであり得る）とワイヤレスに通信可能な他のタイプの基地局（例えば、未ライセンススペクトルで動作するＳＣｅｌｌ無線局）であり得る。基地局１２は、送受信機２２、１つ以上のプロセッサ２４（例えば、１つ以上のＣＰＵ（Central Processing Units）、１つ以上のＡＳＩＣ（Application Specific Integrated Circuits）及び／又は１つ以上のＦＰＧＡ（Field Programmable Gate Arrays）など）、メモリ２６並
びにネットワークインタフェース２８を含む。１つ以上の送信機及び１つ以上の受信機を含み得る送受信機２２は、基地局１２がワイヤレス信号を送受信することを可能にする。プロセッサ２４は、例えば送受信機２２を介してワイヤレスに受信される信号に基づいて、メモリ２６内に記憶される命令を実行することができる。具体的には、いくつかの実施形態において、ここで説明した基地局１２の機能性は、メモリ２６内に記憶されるソフトウェアで実装され、プロセッサ２４により実行される。ネットワークインタフェース２８は、ワイヤレスリンクからの信号の送受信など、基地局１２がコアネットワークとインタラクションすることを可能にする。基地局１２は、１つ以上のワイヤレスデバイス１８とワイヤレスに通信することができる。
びにネットワークインタフェース２８を含む。１つ以上の送信機及び１つ以上の受信機を含み得る送受信機２２は、基地局１２がワイヤレス信号を送受信することを可能にする。プロセッサ２４は、例えば送受信機２２を介してワイヤレスに受信される信号に基づいて、メモリ２６内に記憶される命令を実行することができる。具体的には、いくつかの実施形態において、ここで説明した基地局１２の機能性は、メモリ２６内に記憶されるソフトウェアで実装され、プロセッサ２４により実行される。ネットワークインタフェース２８は、ワイヤレスリンクからの信号の送受信など、基地局１２がコアネットワークとインタラクションすることを可能にする。基地局１２は、１つ以上のワイヤレスデバイス１８とワイヤレスに通信することができる。
【0119】
いくつかの実施形態において、少なくとも１つのプロセッサ２４により実行された場合に、当該少なくとも１つのプロセッサ２４に、ここで説明した実施形態のいずれか１つに係る基地局１２（又は基地局１２－１若しくは１２－２）の機能性を遂行させる命令、を含むコンピュータプログラムが提供される。いくつかの実施形態において、上述したコンピュータプログラムプロダクトを収容する担体が提供される。その担体は、電子信号、光信号、無線信号又はコンピュータ読取可能な記憶媒体（例えば、メモリ２６などの、非一時的なコンピュータ読取可能な媒体）のうちの１つである。
【0120】
図２２は、本開示のいくつかの他の実施形態に係る基地局１２を例示している。なお、この議論は、基地局１２－１及び１２－２に等しく適用可能である。基地局１２は、各々がソフトウェアで実装される１つ以上のモジュール３０を含む。それらモジュール３０は、ここで説明した実施形態のいずれかに係る基地局１２の機能性を提供するように動作する。
【0121】
図２３は、本開示のいくつかの実施形態に係るワイヤレスデバイス１８の概略図である。ワイヤレスデバイス１８は、ライセンス済みスペクトル（例えば、ここで説明した例示的な実施形態ではライセンス済みＬＴＥスペクトル）、未ライセンススペクトル又はその双方からのリソースを用いて、ワイヤレス信号を送受信するように構成される。ワイヤレスデバイス１８は、１つ以上の送信機及び１つ以上の受信機を含む送受信機３２、１つ以上のプロセッサ３４（例えば、１つ以上のＣＰＵ、１つ以上のＡＳＩＣ及び／又は１つ以上のＦＰＧＡなど）並びにメモリ３６を含む。送受信機３２は、ワイヤレスデバイス１８がワイヤレス信号を送受信することを可能にする。プロセッサ３４は、例えば送受信機３２を介してワイヤレスに受信される信号に基づいて、メモリ３６内に記憶される命令を実行することができる。具体的には、いくつかの実施形態において、ここで説明したワイヤレスデバイス１８の機能性は、メモリ３６内に記憶されるソフトウェアで実装され、プロセッサ３４により実行される。
【0122】
いくつかの実施形態において、少なくとも１つのプロセッサ３４により実行された場合に、当該少なくとも１つのプロセッサ３４に、ここで説明した実施形態のいずれか１つに係るワイヤレスデバイス１８の機能性を遂行させる命令、を含むコンピュータプログラムが提供される。いくつかの実施形態において、上述したコンピュータプログラムプロダクトを収容する担体が提供される。その担体は、電子信号、光信号、無線信号又はコンピュータ読取可能な記憶媒体（例えば、メモリ３６などの、非一時的なコンピュータ読取可能な媒体）のうちの１つである。
【0123】
図２４は、本開示のいくつかの他の実施形態に係るワイヤレスデバイス１８を例示している。ワイヤレスデバイス１８は、各々がソフトウェアで実装される１つ以上のモジュール３８を含む。それらモジュール３８は、ここで説明した実施形態のいずれかに係るワイヤレスデバイス１８の機能性を提供するように動作する。
【0124】
図２５は、本開示のいくつかの実施形態に係る、プライマリサービングセル（ＰＳＣ）及びセカンダリサービングセル（ＳＳＣ）におけるワイヤレスデバイスの動作を例示している。図２５に例示した実施形態において、プライマリサービングセル１２－１及びＳＳＣ１２－２を有するネットワークにおいて動作しているワイヤレスデバイス１８は、ＰＳＣ１２－１からＤＬ送信を受信する（ステップ９００）。ＰＳＣからのＤＬ送信の受信への応答として、ワイヤレスデバイス１８は、ＰＳＣへＨＡＲＱフィードバックを提供する（ステップ９０２）。ワイヤレスデバイス１８は、ＳＳＣ１２－２からＤＬ送信を受信し（ステップ９０４）、ＰＳＣの代わりにＳＳＣへＨＡＲＱフィードバックを提供することにより応答する（ステップ９０６）。
【0125】
図２６は、本開示のいくつかの実施形態に従って、ＵＬサブフレームの直前のサブフレームの末尾でのＬＢＴ動作（網掛け部分）の実行に対し、ＵＬサブフレームの冒頭でのＬＢＴ動作の実行を例示している。
【0126】
本開示を通じて以下の頭字語が使用されているかもしれない。
・ μｓ 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
・ μｓ 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
【0127】
当業者は、本開示の実施形態に対する改善及び修正を認識するであろう。全てのそうした改善及び修正は、ここで開示した概念及び後続の特許請求の範囲のスコープの範囲内であるものと見なされる。
【図1A】
【図1B】
【図1C】
【図2】
【図3】
【図4A】
【図4B】
【図5A】
【図5B】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12A】
【図12B】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】