JP2019517753A

JP2019517753A - 共有通信媒体上でのアップリンク手順

Info

Publication number: JP2019517753A
Application number: JP2018563675A
Authority: JP
Inventors: アルムガム・チェンダマライ・カンナン; チラグ・スレシュバイ・パテル; タオ・ルオ; タマー・アデル・カドゥス
Original assignee: クアルコム，インコーポレイテッド
Priority date: 2016-06-10
Filing date: 2017-06-12
Publication date: 2019-06-24
Anticipated expiration: 2037-06-12
Also published as: BR112018074879A2; US10477526B2; TWI732883B; AU2017278292A1; CN109314981A; JP7088848B2; AU2017278292B2; KR20190017775A; KR102503604B1; EP3469845A1; WO2017214612A1; CN109314981B; US20170359815A1; TW201806418A

Abstract

本開示は、一般に、共有通信媒体上でのアップリンク手順に関する。一態様では、アクセス端末は、共有通信媒体上でアクセスポイントからのダウンリンクサブフレームを受信し、ダウンリンクサブフレームを受信したことに応答して、複数のUCIチャネルのうちの第1のUCIチャネルの第1のアップリンクサブフレーム上で、ダウンリンクサブフレームについてのアップリンク制御情報(UCI)を送信する。

Description

関連出願の相互参照
本特許出願は、それぞれ本出願の譲受人に譲渡され、それぞれその全体が参照により本明細書に明確に組み込まれる、2016年6月10日に出願された「ACKNOWLEDGMENT PROCEDURES ON A SHARED COMMUNICATION MEDIUM」と題する米国仮出願第62/348,715号、2016年6月13日に出願された「ACKNOWLEDGMENT PROCEDURES ON A SHARED COMMUNICATION MEDIUM」と題する米国仮出願第62/349,599号、および2016年6月15日に出願された「ACKNOWLEDGMENT PROCEDURES ON A SHARED COMMUNICATION MEDIUM」と題する米国仮出願第62/350,698号の利益を主張する。

本開示の態様は、一般に電気通信に関し、より詳細には、共有通信媒体などの上でのアップリンク手順に関する。

ワイヤレス通信システムは、音声、データ、マルチメディアなどの様々なタイプの通信コンテンツを提供するために広く展開されている。典型的なワイヤレス通信システムは、利用可能なシステムリソース(たとえば、帯域幅、送信電力など)を共有することによって複数のユーザとの通信をサポートすることが可能な多元接続システムである。そのような多元接続システムの例は、符号分割多元接続(CDMA)システム、時分割多元接続(TDMA)システム、周波数分割多元接続(FDMA)システム、直交周波数分割多元接続(OFDMA)システムなどを含む。これらのシステムは、第3世代パートナーシッププロジェクト(3GPP)によって提供されるロングタームエボリューション(LTE)、第3世代パートナーシッププロジェクト2(3GPP2)によって提供されるウルトラモバイルブロードバンド(UMB)およびエボリューションデータオプティマイズド(EV-DO)、米国電気電子技術者協会(IEEE)によって提供される802.11などの仕様に準拠して展開されることが多い。

セルラーネットワークでは、「マクロセル」アクセスポイントは、ある地理的エリアにわたって多数のユーザに接続性およびカバレージを提供する。その地理的領域にわたって良好なカバレージを提供するために、マクロネットワーク展開が慎重に計画され、設計され、実装される。住宅およびオフィスビル用などの、屋内のカバレージまたは他の特定の地理的カバレージを改善するために、最近では、通常は低電力アクセスポイントである追加の「スモールセル」が、従来のマクロネットワークを補完するために展開され始めている。スモールセルアクセスポイントは、漸次的な容量の増大、より豊かなユーザ体験などを提供することもできる。

LTE動作などのスモールセルアクセスポイントセルラーネットワーク動作は、ワイヤレスローカルエリアネットワーク(WLAN)技術によって使用されるUnlicensed National Information Infrastructure(U-NII)帯域などの無認可周波数スペクトルへと拡張されている。スモールセルアクセスポイントLTE動作のこの拡張は、スペクトル効率を、したがって、LTEシステムの容量を向上させるように設計される。しかしながら、これは、通常は同じ無認可帯域を利用する他の無線アクセス技術(RAT)、特に、一般に「Wi-Fi」と呼ばれるIEEE802.11x WLAN技術の動作を侵害する場合もある。

以下は、本明細書で開示する1つまたは複数の態様に関する簡略化された概要を提示する。したがって、以下の概要は、すべての企図される態様に関する広範な概観と見なされるべきではなく、また、以下の概要は、すべての企図される態様に関する主要もしくは重要な要素を識別するか、または任意の特定の態様に関連付けられた範囲を定めるものと見なされるべきでもない。したがって、以下の概要は、以下で提示する詳細な説明に先立って、本明細書で開示する機構に関する1つまたは複数の態様に関するいくつかの概念を簡略化された形で提示するという唯一の目的を有する。

本開示は、一般に、共有通信媒体上でのアップリンク手順に関する。一態様では、共有通信媒体上で通信する方法は、アクセス端末において、共有通信媒体上でアクセスポイントからのダウンリンクサブフレームを受信するステップと、ダウンリンクサブフレームを受信したことに応答して、アクセス端末によって、複数のUCIチャネルのうちの第1のUCIチャネルの第1のアップリンクサブフレーム上で、ダウンリンクサブフレームについてのアップリンク制御情報(UCI)を送信するステップとを含む。

一態様では、共有通信媒体上で通信するための装置は、共有通信媒体上でアクセスポイントからのダウンリンクサブフレームを受信するように構成された、アクセス端末のトランシーバと、ダウンリンクサブフレームの受信に応答して、トランシーバに、複数のUCIチャネルのうちの第1のUCIチャネルの第1のアップリンクサブフレーム上で、ダウンリンクサブフレームについてのアップリンク制御情報(UCI)を送信させるように構成された、アクセス端末の少なくとも1つのプロセッサとを含む。

一態様では、共有通信媒体上で通信するための装置は、共有通信媒体上でアクセスポイントからのダウンリンクサブフレームを受信するように構成された、アクセス端末の通信手段と、ダウンリンクサブフレームの受信に応答して、通信手段に、複数のUCIチャネルのうちの第1のUCIチャネルの第1のアップリンクサブフレーム上で、ダウンリンクサブフレームについてのアップリンク制御情報(UCI)を送信させるように構成された、アクセス端末の処理手段とを含む。

一態様では、共有通信媒体上で通信するためのコンピュータ実行可能命令を記憶する非一時的コンピュータ可読媒体は、アクセス端末に、共有通信媒体上でアクセスポイントからのダウンリンクサブフレームを受信させるための少なくとも1つの命令と、ダウンリンクサブフレームの受信に応答して、アクセス端末に、複数のUCIチャネルのうちの第1のUCIチャネルの第1のアップリンクサブフレーム上で、ダウンリンクサブフレームについてのアップリンク制御情報(UCI)を送信させるための少なくとも1つの命令とを備えるコンピュータ実行可能命令を含む。

本明細書で開示する態様に関連付けられた他の目的および利点は、添付の図面および詳細な説明に基づいて、当業者に明らかとなろう。

添付の図面は、本開示の様々な態様の説明を助けるために提示され、態様の例示のためにのみ提供されており、態様を限定するためのものではない。

本開示の少なくとも1つの態様による例示的なワイヤレスネットワーク環境を示すシステムレベル図である。本開示の少なくとも1つの態様による例示的なフレーム構造を示す図である。本開示の少なくとも1つの態様によるアップリンク制御情報(UCI)ペイロード協調の一例を示すタイミング図である。本開示の少なくとも1つの態様による、アクセス端末が複数のUCIチャネル上でUCIペイロードにおいて確認応答を送信する例示的なハイブリッド自動再送要求(HARQ)タイミング図である。本開示の少なくとも1つの態様による、UCIチャネルにわたる確認応答反復に起因するエラーイベントが生じる例示的なHARQタイミング図である。本開示の少なくとも1つの態様による、いくつかのチャネル上での送信に関するタイミング考慮事項を示す例示的なHARQタイミング図である。本開示の少なくとも1つの態様による、アクセス端末にわたる例示的な多重化方式を示すリソースマップである。本開示の少なくとも1つの態様による、本明細書で説明する技法による通信の例示的な方法を示す流れ図である。本開示の少なくとも1つの態様による、アクセスポイントおよびアクセス端末の例示的な構成要素をより詳細に示すデバイスレベル図である。本開示の少なくとも1つの態様による、一連の相互に関係する機能モジュールとして表される例示的な装置を示す図である。

本開示は、一般に、共有通信媒体上でのアップリンク手順に関する。アクセス端末は、共有通信媒体上でのアクセスポイントとの通信をサポートするために、様々なアップリンク動作を実行する必要があり得る。たとえば、アクセス端末は、肯定応答メッセージまたは否定応答メッセージ(ACK/NACK)、チャネル品質インジケータ(CQI)、スケジューリング要求(SR)、バッファステータス報告(BSR)などの様々なアップリンク制御情報(UCI)をアクセスポイントに送信し得る。アクセス端末は、物理アップリンク制御チャネル(PUCCH)または物理アップリンク共有チャネル(PUSCH)などを介して、所与のアップリンクサブフレームの間にUCIペイロードにおいてこれらの「UCI送信」を送信する。PUCCHおよびPUSCHは、ショートPUCCH(sPUCCH)、拡張PUCCH(ePUCCH)、および/または拡張PUSCH(ePUSCH)にさらに分類され得る。これらの「UCIチャネル」の各々は、異なるサイズのUCIペイロードをサポートし、異なるリッスンビフォアトーク(LBT)要件を有し、および/または異なるタイムライン(すなわち、アクセス端末がダウンリンク上でアクセスポイントからUCIチャネルへのアクセスの許可を受信する時間と、アクセス端末がアップリンク上でACKをアクセスポイントに送る時間との間の関係)を有することができる。加えて、所与のアクセス端末に固有の情報は、許可ベースのアップリンク送信において提供され得るが、ブロードキャスト専用の情報は、グループトリガを介してシグナリングされ得る。

UCIペイロードのアップリンク送信は、「プライマリ」RATシステムおよび1つまたは複数の「競合」RATシステムが通信媒体を共有するワイヤレスネットワーク環境において複数の課題に直面する。たとえば、通信媒体が共有されるという性質により、競合RATシステムからのアクセス端末における干渉は、LBT失敗を引き起こす場合がある。競合RATシステムからのアクセスポイントにおける干渉は、復号失敗を引き起こす場合がある。これらの問題に対処するために、アクセス端末は、同じダウンリンクサブフレームを複数回ACK/NACKすることができる。この冗長性は、複数のUCIチャネル上で利用可能な許可またはリソースに応じて、それらのチャネルにわたってACK/NACKを送信することによってさらに高められ得る。しかしながら、この冗長性は、エラーイベント(たとえば、反復)を管理することをより困難にする場合がある。したがって、UCIペイロードならびにそれに関連付けられた送信リソースを協調させるために、様々な技法が本明細書で提供される。

たとえば、一態様では、アクセス端末は、共有通信媒体上でアクセスポイントからのダウンリンクサブフレームを受信し、ダウンリンクサブフレームを受信したことに応答して、複数のUCIチャネルのうちの第1のUCIチャネルの第1のアップリンクサブフレーム上で、ダウンリンクサブフレームについてのUCIを送信する。一態様では、第1のUCIチャネルは、UCIを送信するための複数のUCIチャネルのうちの第1の利用可能なUCIチャネルであってもよく、アクセス端末は、複数のUCIチャネルのうちの別のチャネル上でUCIの送信を反復しないことがある。別の態様では、アクセス端末は、複数のUCIチャネルのうちの他のUCIチャネルの利用可能性にかかわらず、第1のUCIチャネル上ですべての受信されたダウンリンクフレームについてのすべてのUCIを送信するように構成され得る。また別の態様では、アクセス端末は、ダウンリンクサブフレームを受信したことに応答して、複数のUCIチャネルのうちの第2のUCIチャネルの第2のアップリンクサブフレーム上でUCIを送信してもよく、UCIは、構成された持続時間の満了前にのみ、第2のUCIチャネルの第2のアップリンクサブフレーム上で送信される。また別の態様では、アクセス端末は、複数のUCIチャネルの特性に基づいて、アクセスポイントからの入力なしに第1のUCIチャネルを選択し得る。

本開示のこれらの態様および他の態様は、例示の目的で提供される様々な例を対象とする以下の説明および関連する図面において提供される。本開示の範囲から逸脱することなく、代替の態様が考案され得る。加えて、より関連性のある詳細を不明瞭にしないように、本開示のよく知られている態様は詳細に説明されないことがあり、または省略されることがある。

以下で説明する情報および信号は、様々な異なる技術および技法のいずれかを使用して表され得ることを当業者は諒解されよう。たとえば、以下の説明全体にわたって参照され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、およびチップは、部分的に特定の適用例、部分的に所望の設計、部分的に対応する技術などに応じて、電圧、電流、電磁波、磁場もしくは磁性粒子、光場もしくは光学粒子、またはそれらの任意の組合せによって表され得る。

さらに、多くの態様について、たとえば、コンピューティングデバイスの要素によって実行されるべきアクションのシーケンスに関して説明する。本明細書で説明する様々なアクションは、特定の回路(たとえば、特定用途向け集積回路(ASIC))によって、1つまたは複数のプロセッサによって実行されるプログラム命令によって、または両方の組合せによって実行され得ることが認識されよう。加えて、本明細書で説明する態様の各々について、任意のそのような態様の対応する形態は、たとえば、説明するアクションを実行する「ように構成された論理」として実装される場合がある。

図1は、例として「プライマリ」無線アクセス技術(RAT)システム100および「競合」RATシステム150を含むものとして示される、例示的なワイヤレスネットワーク環境を示すシステムレベル図である。各システムは、様々なタイプの通信(たとえば、音声、データ、マルチメディアサービス、関連する制御シグナリングなど)に関連する情報を含む、概してワイヤレスリンクを介して受信および/または送信することが可能な異なるワイヤレスノードから構成される場合がある。プライマリRATシステム100は、ワイヤレスリンク130を介して互いと通信しているアクセスポイント110およびアクセス端末120を含むものとして示されている。競合RATシステム150は、別個のワイヤレスリンク132を介して互いと通信している2つの競合ノード152を含むものとして示されており、同様に、1つまたは複数のアクセスポイント、アクセス端末、または他のタイプのワイヤレスノードを含み得る。一例として、プライマリRATシステム100のアクセスポイント110およびアクセス端末120は、ロングタームエボリューション(LTE)技術に従ってワイヤレスリンク130を介して通信し得るが、競合RATシステム150の競合ノード152は、Wi-Fi技術に従ってワイヤレスリンク132を介して通信し得る。各システムは地理的領域全体にわたって分散された任意の数のワイヤレスノードをサポートすることができ、図示したエンティティは例示の目的で示されているにすぎないことが諒解されよう。

別段に記載されていない限り、「アクセス端末」および「アクセスポイント」という用語は、任意の特定のRATに固有であるか、または任意の特定のRATに限定されるものではない。一般に、アクセス端末は、ユーザが通信ネットワークを介して通信することを可能にする任意のワイヤレス通信デバイス(たとえば、モバイルフォン、ルータ、タブレットコンピュータ、ラップトップコンピュータ、パーソナルコンピュータ、サーバ、エンターテインメントデバイス、モノのインターネット(IOT)/あらゆるモノのインターネット(IOE)対応デバイス、車載通信デバイスなど)であってもよく、異なるRAT環境では、ユーザデバイス(UD)、移動局(MS)、加入者局(STA)、ユーザ機器(UE)などと代替的に呼ばれることがある。同様に、アクセスポイントは、アクセスポイントが展開されるネットワークに応じて、アクセス端末と通信する際に1つまたは複数のRATに従って動作することができ、基地局(BS)、ネットワークノード、ノードB、発展型ノードB(eNB)などと代替的に呼ばれることがある。そのようなアクセスポイントは、たとえば、スモールセルアクセスポイントに対応し得る。「スモールセル」は一般に、フェムトセル、ピコセル、マイクロセル、ワイヤレスローカルエリアネットワーク(WLAN)アクセスポイント、他の小カバレージエリアアクセスポイントなどを含み得るか、またはさもなければそのように呼ばれることがある、低電力アクセスポイントの種類を指す。近隣内の数ブロックまたは地方環境における数平方マイルをカバーし得るマクロセルカバレージを補完するためにスモールセルが展開され、それにより、改善されたシグナリング、漸次的な容量の増大、より豊かなユーザ体験などをもたらし得る。

図1に戻ると、プライマリRATシステム100によって使用されるワイヤレスリンク130および競合RATシステム150によって使用されるワイヤレスリンク132は、共有通信媒体140を介して動作することができる。このタイプの通信媒体は、1つまたは複数の周波数、時間、および/または空間通信リソース(たとえば、1つまたは複数のキャリアにわたる1つまたは複数のチャネルを含む)から構成され得る。一例として、通信媒体140は、無認可周波数帯域の少なくとも一部分に対応し得る。異なる認可周波数帯域が(たとえば、米国の連邦通信委員会(FCC)などの政府機関によって)特定の通信のために確保されているが、いくつかのシステム、特にスモールセルアクセスポイントを用いるシステムは、Wi-Fiを含むWLAN技術によって使用されるUnlicensed National Information Infrastructure(U-NII)帯域などの無認可周波数帯域、およびCitizens Broadband Radio Service(CBRS)帯域へと動作を拡張している。

いくつかの事例では、共有スペクトル帯域は、軽度認可された(lightly licensed)スペクトル、および/または、異なるRATの通信の間でのある程度の協調もしくは、たとえば、インカンベントRATなどの特定のRATの通信に与えられるある程度の選好があり得るスペクトルを指す場合がある。他の事例では、共有スペクトル帯域は、一般に、軽度認可されたスペクトル/協調されたスペクトルを含み得る、異なるRATが同じRFスペクトル帯域内で共存もしくは動作するスペクトル、または、代替的に、異なるRATが様々なチャネル競合技法を使用してチャネル媒体へのアクセスを求めて自由に競合し得る純粋な無認可スペクトルを指す場合がある。本開示で説明する態様は、様々な共有または無認可スペクトル様式に適用可能であり得る。

通信媒体140の共有使用により、ワイヤレスリンク130とワイヤレスリンク132との間にリンク間干渉の可能性がある。さらに、いくつかのRATおよびいくつかの管轄は、通信媒体140へのアクセスのために、競合またはLBTを必要とする場合がある。一例として、各デバイスが、それ自体の送信のために通信媒体を占有する(場合によっては確保する)前に、共有通信媒体上に他のトラフィックがないことを検知する媒体を介して検証する、クリアチャネルアセスメント(CCA)プロトコルが使用され得る。いくつかの設計では、CCAプロトコルは、それぞれ、RAT内トラフィックおよびRAT間トラフィックに通信媒体を譲るための、別個のCCAプリアンブル検出(CCA-PD:CCA Preamble Detection)機構およびCCAエネルギー検出(CCA-ED:CCA Energy Detection)機構を含み得る。欧州電気通信標準化機構(ETSI)は、たとえば、無認可周波数帯域などの特定の通信媒体上のRATに関係なく、すべてのデバイスに対して競合を義務付けている。

以下でより詳細に説明するように、アクセスポイント110および/またはアクセス端末120は、上記で手短に説明した共有通信媒体上でのアップリンク手順を提供するかまたはさもなければサポートするように、本明細書の教示に従って様々に構成され得る。たとえば、アクセスポイント110はハイブリッド自動再送要求(HARQ)マネージャ112を含んでもよく、アクセス端末120はHARQマネージャ122を含んでもよい。一態様では、HARQマネージャ112および/またはHARQマネージャ122は、本明細書でさらに説明するように、確認応答情報の送信および受信を管理するように、異なる方法で構成され得る。

図2は、通信媒体140への競合ベースアクセスを容易にするために、プライマリRATシステム100のために実装され得る例示的なフレーム構造を示す。

図示したフレーム構造は、システムフレーム番号(SFN)ヌメロロジー(SFN N、N+1、N+2など)に従って番号付けされ、参照用にやはり番号付けされ得る(たとえば、SF0、SF1など)それぞれのサブフレーム(SF)に分割され得る、一連の無線フレーム(RF)を含む。各それぞれのサブフレームは、スロットにさらに分割される場合があり、スロットは、(図2に示されていない)シンボル期間(SP)にさらに分割される場合がある。一例として、LTEフレーム構造は、それぞれ10個のサブフレームから構成される、番号付けされた1024個の無線フレームに分割されるシステムフレームを含み、これらの無線フレームは、一緒になってSFNサイクルを構成する(たとえば、1msのサブフレームを有する10msの無線フレームについて10.24秒続く)。各サブフレームは2つのスロットを含むことができ、各スロットは6つまたは7つのシンボル期間を含むことができる。フレーム構造の使用は、他のアドホックシグナリング技法よりも自然で効率的な協調をデバイス間にもたらし得る。

図2の例示的なフレーム構造は、各サブフレームが異なる時間にダウンリンク(D)サブフレーム、アップリンク(U)サブフレーム、またはスペシャル(S)サブフレームとして様々に動作し得るという点で、時分割複信(TDD)フレーム構造である。一般に、ダウンリンクサブフレームは、アクセスポイント110からアクセス端末120にダウンリンク情報を送信するために確保され、アップリンクサブフレームは、アクセス端末120からアクセスポイント110にアップリンク情報を送信するために確保され、スペシャルサブフレームは、ガード期間によって分離されたダウンリンク部分およびアップリンク部分を含み得る。ダウンリンクサブフレーム、アップリンクサブフレーム、およびスペシャルサブフレームの異なる配置は、異なるTDD構成と呼ばれることがある。異なるトラフィックシナリオに適応するために、いくつかのTDD構成はより多くのダウンリンクサブフレームを有してもよく、いくつかはより多くのアップリンクサブフレームを有してもよい。

いくつかの設計では、図2のフレーム構造は、各サブフレームのロケーションが絶対時間に対してあらかじめ決定され得るという点で「固定」であり得るが、通信媒体140にアクセスするための競合手順により、任意の所与の場合にプライマリRATシグナリングによって占有されることもあり、占有されないこともある。たとえば、アクセスポイント110またはアクセス端末120が所与のサブフレームに対する競合に勝つことができなかった場合、そのサブフレームは無音化され得る。しかしながら、他の設計では、図2のフレーム構造は、各サブフレームのロケーションが通信媒体140へのアクセスが確保されるポイントに対して動的に決定され得るという点で「浮動」であり得る。たとえば、アクセスポイント110またはアクセス端末120が競合に勝つことができるまで、絶対時間に対して所与のフレーム(たとえば、SFN N)の開始が遅延されてもよい。

以下でより詳細に説明するように、アクセス端末120は、通信媒体140上でのアクセスポイント110との通信をサポートするために、様々なアップリンク動作を実行する必要があり得る。たとえば、アクセス端末120は、自律的にまたは要求時に、ACK/NACK、CQI、SR、BSRなどの様々なUCIをアクセスポイント110に送信し得る。したがって、UCIペイロードならびにそれに関連付けられた送信リソースを協調させるために、様々な技法が本明細書で提供される。

図3は、本開示の少なくとも1つの態様によるUCIペイロード協調の一例を示すタイミング図である。この例では、アクセス端末120は、PUCCHまたはPUSCHなどを介して、所与のアップリンクサブフレーム300の間に、1つまたは複数のビットから構成されたUCIペイロード302を送信する。上述のように、PUCCHおよびPUSCHは、sPUCCH、ePUCCH、および/またはePUSCHにさらに分類され得る。いくつかの事例では、sPUCCHは、14個未満のシンボルを占有するアップリンク制御チャネルであり得る。sPUCCHは、たとえば、スペシャルサブフレームのアップリンク部分に含まれ得る。上記で説明したように、UCIペイロード302は、ACK/NACK、CQI、SR、BSRなどを搬送するように様々に構成され得る。UCIペイロード302におけるACK/NACK、CQI、SR、BSRなどの送信は、本明細書では「UCI送信」と呼ばれることがある。

上述のように、アクセスポイント110および/またはアクセス端末120は、それぞれ、HARQマネージャ112およびHARQマネージャ122を含み得る。HARQマネージャ122は、任意のACK/NACK、CQI、SR、BSRなどを含むUCIペイロード302をHARQマネージャ112に送信するか、またはその送信を引き起こすように構成され得る。このHARQフィードバックは、sPUCCH、ePUCCH、および/またはePUSCHなどの1つまたは複数の異なるチャネル上で送信され得る。

sPUCCH上でのフィードバック(たとえば、UCIペイロード302におけるACK/NACK、CQI、SR、BSRなど)は、トリガベースであり得る。具体的には、フィードバックは、ユーザのグループに、場合によってはアクセスポイント110によってサービスされるすべてのユーザにも共通の物理ダウンリンク制御チャネル(PDCCH)によってトリガされ得る。ePUCCH上でのフィードバックは、sPUCCHの場合と同様にトリガベース、またはアップリンク許可ベースのいずれかであり得る。ePUSCH上でのフィードバックは、アップリンク許可ベースであり得る。

上述のように、sPUCCH、ePUCCH、およびePUSCH(本明細書では「UCIチャネル」と呼ばれる)の各々は、異なるサイズのペイロード(たとえば、UCIペイロード302)をサポートし得る。たとえば、sPUCCHは約10〜30ビットのペイロードをサポートし得るが、ePUCCHは約75〜100ビットのペイロードをサポートし得る。加えて、各UCIチャネルは、異なるLBT要件を有し得る。たとえば、16μsのダウンリンク送信内では、sPUCCHはLBTなしでACK/NACKを搬送し得る。さらに、各UCIチャネルは、異なるタイムライン(すなわち、アクセス端末120がダウンリンク上でアクセスポイント110からUCIチャネルへのアクセスの許可を受信する時間と、アクセス端末120がアップリンク上でACKをアクセスポイント110に送る時間との間の関係)を有することができる。加えて、所与のアクセス端末、たとえば、アクセス端末120に固有の情報は、許可ベースのアップリンク送信において提供され得るが、ブロードキャスト専用の情報は、グループトリガを介してシグナリングされ得る。

UCIペイロード302のアップリンク送信は、図1に示す「プライマリ」RATシステム100および「競合」RATシステム150を有する例示的なワイヤレスネットワーク環境において複数の課題に直面する。たとえば、図1の通信媒体140が共有されるという性質により、競合RATシステム150(および/または別の競合RATシステム)からのアクセス端末120における干渉は、LBT失敗を引き起こす場合がある。競合RATシステム150(および/または別の競合RATシステム)からのアクセスポイント110における干渉は、復号失敗を引き起こす場合がある。

この問題に対処するために、アクセス端末120は、同じダウンリンクサブフレームを複数回ACK/NACKすることができる。同じダウンリンクサブフレームについて確認応答するというこの冗長性は、複数のUCIチャネル上で利用可能な許可またはリソースに応じて、それらのチャネルにわたって(UCIペイロード302において)ACK/NACKを送信することによってさらに高められ得る。

図4は、本開示の少なくとも1つの態様による、アクセス端末(たとえば、アクセス端末120)が複数のUCIチャネル上でUCIペイロード302においてACK/NACK(すなわち、UCI)を送信する例示的なHARQタイミング図400を示す。HARQタイミング図400は、5つのダウンリンク(D)サブフレーム(SF0〜SF4)、1つのスペシャル(S)サブフレーム(SF5)、および4つのアップリンク(U)サブフレーム(SF6〜SF9)の例示的なパターンを示す。しかしながら、諒解されるように、実装形態に応じて、5つより多いまたはより少ないダウンリンクサブフレームと、4つより多いまたはより少ないアップリンクサブフレームとがあり得る。

HARQタイミング図400では、アクセス端末120は、アクセスポイント110の送信機会(TxOP)内で数えると、スケジュールされたダウンリンクサブフレームの少なくともX個のサブフレーム後である最も早いアップリンクサブフレームにおけるsPUCCH上のUCIペイロード(たとえば、UCIペイロード302)において、スケジュールされたダウンリンクサブフレームのACK/NACKを送信しようと試みる。レガシーLTEの時間差が維持される場合、Xは4つのサブフレームとなることに留意されたい。したがって、図4の例では、HARQプロセスH0は、ダウンリンクサブフレームSF1においてスケジュールされるか、または受信される(動作402)。4つのサブフレーム後であるスペシャルサブフレームSF5において、アクセス端末120は、sPUCCH上でHARQプロセスH0について確認応答する(動作404)。

加えて、ある程度の冗長性を与えるために、ダウンリンクサブフレームSF4において、アクセス端末120は、アップリンクサブフレームSF8のePUCCHに対するアクセス許可を受信する(動作406)。したがって、アップリンクサブフレームSF8において、アクセス端末120は、ePUCCH上のUCIペイロード(たとえば、UCIペイロード302)において、ダウンリンクサブフレームSF1において受信されたHARQプロセスH0のACK/NACKを送信する(動作408)。

この冗長性は、エラーイベント(たとえば、反復)を管理することをより困難にする場合がある。図5は、本開示の少なくとも1つの態様による、UCIチャネルにわたるACK/NACK反復に起因するエラーイベントが生じる例示的なHARQタイミング図500を示す。HARQタイミング図500は、5つのダウンリンク(D)サブフレーム(SF0〜SF4)、1つのスペシャル(S)サブフレーム(SF5)、および4つのアップリンク(U)サブフレーム(SF6〜SF9)の例示的なパターンを有する第1のアクセスポイント送信機会(TxOP N)と、2つのダウンリンク(D)サブフレーム(SF0〜SF1)、1つのスペシャル(S)サブフレーム(SF2)、および3つのアップリンク(U)サブフレーム(SF3〜SF5)の例示的なパターンを有する第2のアクセスポイント送信機会(TxOP N+1)とを示す。しかしながら、諒解されるように、実装形態に応じて、それぞれ、5つおよび2つより多いまたはより少ないダウンリンクサブフレームと、4つおよび3つより多いまたはより少ないアップリンクサブフレームとがあり得る。

HARQタイミング図400と同様に、HARQタイミング図500では、アクセス端末(たとえば、アクセス端末120)は、スケジュールされたダウンリンクサブフレームの少なくともX個(たとえば、LTEでは4つ)のサブフレーム後である最も早いアップリンクサブフレームにおけるsPUCCH上のUCIペイロード(たとえば、UCIペイロード302)において、スケジュールされたダウンリンクサブフレームのACK/NACKを送信しようと試みる。したがって、図5の例では、HARQプロセスH0は、TxOP NのダウンリンクサブフレームSF1においてスケジュールされるか、または受信される(動作502)。4つのサブフレーム後であるスペシャルサブフレームSF5において、アクセス端末120は、sPUCCH上でHARQプロセスH0について確認応答する(動作504)。

TxOP N+1のダウンリンクサブフレームSF0において、アクセスポイント(たとえば、アクセスポイント110)は再度、HARQプロセスH0へのアクセスをスケジュールするか、または許可する(動作506)。しかしながら、図5の例では、(たとえば、共有通信媒体における他のデバイスからの干渉により)この許可が失われる。TxOP N+1のダウンリンクサブフレームSF1において、アクセス端末120は、TxOP N+1のアップリンクサブフレームSF5のePUCCHに対するアクセス許可を受信する(動作508)。図4の場合のように、アクセス端末120は、前に受信されたまたはスケジュールされたHARQプロセスH0を(冗長的に)について確認応答するために、この許可を使用し得る。

スケジュールされた最後のHARQプロセスH0はTxOP N+1のダウンリンクサブフレームSF0にあったので、アクセスポイント110は、TxOP N+1のアップリンクサブフレームSF5において受信された任意のACK/NACKはTxOP N+1のダウンリンクサブフレームSF0における許可のためのものであると予想する。しかしながら、TxOP N+1のダウンリンクサブフレームSF0における許可は失われたので、TxOP NのダウンリンクサブフレームSF1におけるHARQプロセスH0のための許可が、HARQプロセスH0のためにアクセス端末120が受信した最後の許可である。したがって、TxOP N+1のアップリンクサブフレームSF5において、アクセス端末120は、エラーであるTxOP N+1のダウンリンクサブフレームSF0において受信されたHARQプロセスH0の代わりに、TxOP NのダウンリンクサブフレームSF1において受信されたHARQプロセスH0をACK/NACKすることになる(動作510)。

これらのタイプのエラーに対処するためのいくつかの方法がある。第1の解決策は、最初に現れるUCIチャネル(すなわち、sPUCCH、ePUCCH、またはePUSCH)上でUCI送信(たとえば、UCIペイロード302におけるACK/NACK、CQI、SR、BSRなど)を送信することである。この解決策では、アクセス端末120は、sPUCCH、ePUCCH、またはePUSCHの最初の機会にUCIを送信する。送信されると、アクセス端末120は、その他のUCIチャネル上でUCIの送信を反復しない。特定のHARQプロセス(たとえば、HARQプロセスH0)は、任意のUCI送信の後にHARQバッファにおいてNACKに設定される。この解決策の利点は、複数のUCIチャネル上で同じUCIを送信することから生じるエラーイベントを排除することである。

別の解決策は、事前構成されたUCIチャネル上でUCI送信を送信することである。この解決策では、各アクセス端末120は、固定のUCIチャネル上で、そのUCIチャネルがsPUCCHであるか、ePUCCHであるか、またはePUSCHであるかにかかわらず、UCIを送信するように事前構成され得る。たとえば、アクセス端末120は、sPUCCH、ePUCCH、またはePUSCHのうちの最初に利用可能なものを選び、次いで、そのチャネル上でUCI送信を送信し続けるように構成され得る。この解決策の利点は、sPUCCH、ePUCCH、およびePUSCHの限定されたチャネルリソースがアクセス端末120の間で区分されることを可能にすることである。

この半静的な構成を受信していないアクセス端末120の場合、UCI送信のために取っておかれたいくつかの追加のリソースがあってもよく、または(ePUSCH機構は許可ベースなので)ePUSCH機構が使用されてもよい。特定のHARQプロセス(たとえば、HARQプロセスH0)は、任意のUCI送信の後にHARQバッファにおいてNACKに設定される。

第3の解決策は、時間制約下でUCI冗長性を可能にすることである。この解決策では、アクセス端末120は、ある固定の持続時間内に複数のUCIチャネル上で所与のHARQプロセスについてUCI送信を反復することが許可される。そのような固定の時間制約は、図5に関して上記で説明したエラーイベントの回避を容易にする。たとえば、時間制約下では、アクセス端末120は、時間制約が満了しているので、TxOP NのダウンリンクサブフレームSF1において受信されたHARQプロセスH0のための許可についてTxOP N+1のアップリンクサブフレームSF5におけるePUCCH上で確認応答しないであろう。時間制約解決策の利点は、反復およびエラーイベントの回避を可能にすることによって、増大したLBTダイバーシティを導入することである。

時間制約の一例として、同じTxOP内で、アクセス端末120は、利用可能時点でのsPUCCH、ePUSCH、および/またはePUCCH上で所与のHARQプロセスについてUCI送信を反復し得る。現在のTxOPが終了すると、所与のHARQプロセスについてのUCI送信のさらなる反復は許可されない。したがって、UCIチャネルのうちのいずれかを通してすでに確認応答されたHARQプロセスは、HARQバッファにおいてNACKに設定される。アクセスポイント110は、この時間制約を使用するようにアクセス端末120を構成し得る。

時間制約の別の例として、ある時間「T」ms内で、アクセス端末120は、利用可能時点でのsPUCCH、ePUSCH、および/またはePUCCH上でUCI送信を反復し得る。事前構成された持続期間が終了すると、所与のHARQプロセスについてのUCI送信のさらなる反復は許可されない。したがって、UCIチャネルのうちのいずれかを通してすでに確認応答されたHARQプロセスは、HARQバッファにおいてNACKに設定される。時間Tmsは、アクセスポイント110によって構成され得る。

また別の解決策は、アクセス端末120が、アクセスポイント110によるブラインド検出と結合されるべきUCIチャネルを自律的に選択することを可能にすることである。より具体的には、アクセス端末120は、チャネル、干渉、およびリンクバジェット条件に応じて、UCIチャネルのうちのいずれかの上でHARQフィードバック、すなわち、UCI送信を送信し得る。たとえば、UCIペイロード(たとえば、UCIペイロード302)が小さい場合、アクセス端末120は、(約10〜30ビットのペイロードをサポートし得る)sPUCCHを使用することを選んでもよく、そうでない場合、(約75〜100ビットのペイロードをサポートし得る)ePUCCHを使用することを選んでもよい。別の例として、アクセス端末120が(無線周波数(RF)測定値に基づいて決定されたように)セルエッジにある場合、アクセス端末120は、ePUCCHを使用することを選んでもよく、そうでない場合、sPUCCHを使用することを選んでもよい。この解決策の利点は、オーバーヘッドを最小限に抑え、アクセス端末120がUCI送信のための適切な手段を選ぶことを可能にすることである。

エラーイベントを回避するため、または少なくとも最小限に抑えるために、アクセス端末120による自律的なUCIチャネル選択が上記で説明した他の解決策と組み合わせられてもよいことに留意されたい。たとえば、各アクセス端末120が固定のUCIチャネル上でUCIを送信するように事前構成され得る第2の解決策では、アクセス端末120はUCIチャネルを自律的に選択し得る。同様に、アクセス端末120がある固定の持続時間内に複数のUCIチャネル上で所与のHARQプロセスについてUCI送信を反復することが許可される第3の解決策では、アクセス端末120は、時間制約内でUCIを送信するためのUCIチャネルを自律的に選択し得る。

関連する解決策は、同じサブフレームの間のePUCCHおよびePUSCH上でのアクセス端末120による同時送信が許可されないということである。代わりに、ePUSCH上で許可が利用可能である場合、ePUCCHは自動的にスキップされ、コンテンツはePUSCH上に多重化される。

一態様では、上記で説明したアクセス端末120の構成は、HARQマネージャ122によって制御され得るおよび/またはHARQマネージャ122内に存在し得る。一態様では、これらの構成は、HARQマネージャ112によって制御されるおよび/またはHARQマネージャ112内に存在する情報に基づいて、アクセスポイント110からHARQマネージャ122において受信され得る。

ePUCCH上での送信に関するタイミング考慮事項がある。具体的には、ePUCCHおよびsPUCCHは、異なるHARQタイムラインを有し得る。たとえば、sPUCCH上でのUCI送信は、図4に示すように、スペシャル(S)サブフレーム上で行われ得る。対照的に、ePUCCHでのUCI送信は、やはり図4に示すように、アップリンク(U)サブフレーム上で行われるようにトリガされる。

図6は、本開示の少なくとも1つの態様による、ePUCCHおよびsPUCCH上での送信に関するタイミング考慮事項を示す例示的なHARQタイミング図600である。HARQタイミング図600は、5つのダウンリンク(D)サブフレーム(SF0〜SF4)、1つのスペシャル(S)サブフレーム(SF5)、および3つのアップリンク(U)サブフレーム(SF6〜SF8)の例示的なパターンを示す。しかしながら、諒解されるように、実装形態に応じて、5つより多いまたはより少ないダウンリンクサブフレームと、3つより多いまたはより少ないアップリンクサブフレームとがあり得る。

図6に示すように、HARQプロセスH0およびH4は、ダウンリンクサブフレームSF0〜SF4においてスケジュールされる(動作602)。ダウンリンクサブフレームSF4において、アクセス端末120は、sPUCCHおよびePUCCH上でUCI送信を送信するための許可、またはトリガを受信する(動作604)。図4に示すタイムラインと同様に、アクセス端末120は、スペシャルサブフレームムSF5におけるsPUCCH上で最初の2つのダウンリンクサブフレームSF0およびSF1について確認応答し得る(動作606)。

しかしながら、ダウンリンクサブフレームSF4において受信されたトリガは、アップリンクバーストの最初のサブフレーム(すなわち、アップリンクサブフレームSF5)についてePUCCHのためのUCI送信をスケジュールすることができ、このことにより、後のサブフレーム上でのスペシャルLBTギャップの必要がなくなる。この場合、アップリンクサブフレームSF5におけるUCI送信は、ダウンリンクサブフレームSF0〜SF2について確認応答し得る(動作608)(ただし、アクセス端末120は、レガシーLTEの場合のように、ダウンリンクサブフレームの少なくとも4つのサブフレーム後にダウンリンクサブフレームについて確認応答する)。代替的に、ダウンリンクサブフレームSF4において受信されたトリガは、アップリンクバーストの最後のサブフレーム(すなわち、アップリンクサブフレームSF8)についてePUCCHのためのUCI送信をスケジュールすることができ、このことは、TxOP N〜N+4タイムライン内に追加のサブフレームを組み込むことによって、同じTxOP内のより多くのサブフレームについて確認応答されることを可能にする。この場合、アップリンクサブフレームSF8におけるUCI送信は、ダウンリンクサブフレームSF0〜SF4について確認応答し得る(動作610)(ただし、ここでも、アクセス端末120は、レガシーLTEの場合のように、ダウンリンクサブフレームの少なくとも4つのサブフレーム後にダウンリンクサブフレームについて確認応答する)。

本開示の別の考慮事項は、UCIチャネル上でのリソース割振りである。UCI送信のための「リソース」は、インターレースインデックスと多重化インデックスの組合せとして定義される。たとえば、sPUCCHの10個のインターレースが利用可能であり、各インターレースが2つまでのアクセス端末120の多重化を可能にすることができる場合、このことは20個のsPUCCHリソースを生み出す。多重化インデックスは、巡回シフトインデックスまたはウォルシュコード/直交カバーコード(OCC:Orthogonal Cover Code)インデックスを指す場合がある。

図7は、本開示の少なくとも1つの態様による、アクセス端末にわたる例示的なsPUCCH多重化方式を示すリソースマップである。一般に、sPUCCHは、異なるインターレースを異なるアクセス端末に割り振ることによって周波数分割多重化され得る。図示の例では、第1のインターレース(インターレース#1)は第1のアクセス端末(たとえば、アクセス端末120)に割り振られてもよく、第2のインターレース(インターレース#2)は第2のアクセス端末に割り振られてもよい。さらに、所与のインターレース内で、符号分割多重化によって複数のアクセス端末が受け入れられ得る。符号分割多重化は、時間領域において、周波数領域において、または(図示のように)両方において達成され得る。時間領域において、シンボル期間にわたってウォルシュコードが使用され得る。用いられるウォルシュコードの長さは、sPUCCHの長さ(たとえば、図示の例では2(2)の長さ、ただし、N=4およびP=2)に依存し得る。周波数領域において、所与のリソースブロック(RB:Resource Block)内のリソース要素(RE:Resource Element)にわたってウォルシュコードが使用され得る。

所与のアクセス端末のためのsPUCCH/ePUCCHが複数のインターレースを占める場合、以下の2つの方法のうちの1つでsPUCCH/ePUCCHペイロードが形成され得る。(a)すべての割り振られたインターレースにわたってsPUCCH/ePUCCHペイロードが全体として生成された後に符号化およびリソースマッピングが続き得るか、または(b)インターレースへのHARQプロセスのマッピングに基づいて、sPUCCH/ePUCCHペイロードが準備され得る。たとえば、HARQプロセスのサブセットがあるインターレースにマッピングされてもよく、HARQプロセスの別のサブセットが異なるインターレースにマッピングされてもよい。アクセス端末120は、そのsPUCCH/ePUCCH送信のために単一のインターレースが割り振られるか複数のインターレースが割り振られるかに基づいて、どのHARQプロセスについて確認応答されるべきかを決定し得る。この割振りは、許可ベースのePUCCH送信の場合には許可において示され得るか、またはトリガベースのsPUCCH送信もしくはePUCCH送信の場合には半静的に定義されたマッピング規則において示され得るかのいずれかである。

上述のように、ePUSCHはアップリンク許可ベースであり、したがって、リソース割振りは許可において指定される。同様に、ePUCCHがアップリンク許可ベースであるとき、リソース割振りは許可において指定される。しかしながら、トリガベースのePUCCHおよびsPUCCHの場合、リソース割振りは代替方法において指定される必要がある。

次回のTxOP内のePUCCH送信の正確なロケーションは、複数の可能性のうちの1つにおいて生じ得る。ePUCCHは、TxOP内の次回のアップリンクバーストの最初のサブフレーム上、TxOP内の次回のアップリンクバーストの最後のサブフレーム上、または次回の周期的なアップリンクアンカーサブフレーム上(アンカーサブフレームは、時間内に特定のロケーションにおいて生じるように事前定義される)のいずれかで生じ得る。このことは、C-PDCCHを使用して複数のアクセス端末に、またはアップリンク許可を使用してアクセス端末のサブセットに示され得る。一態様では、この指示は、以下の4つの状態のうちの1つを示す2ビットパターンを使用して行われ得る。(1)ePUCCHなし、(2)アップリンクバーストの最初のサブフレーム上のePUCCH、(3)アップリンクバーストの最後のサブフレーム上のePUCCH、または(4)周期的なアップリンクアンカーサブフレーム上のePUCCH。

アクセスポイントスケジューリング機構は、次回の周期的なアップリンクアンカーサブフレームを考慮し、この構成と一致するように他のアップリンク送信を構成しなければならない。たとえば、アクセスポイントスケジューリング機構は、アンカーサブフレームの前および後でサブフレームを占める(サブフレーム単位で測定された)アップリンク許可の長さおよび隣接するサブフレームのLBT構成を、周期的なアップリンクアンカーサブフレームのロケーションと一致するようにスケジュールしなければならない。

トリガベースであるsPUCCHおよびePUCCHの場合、ペイロードサイズは、SRがHARQフィードバックおよび/またはチャネル状態情報(CSI)フィードバックとともに生じるかどうかに応じて可変であってもよい。このことは、アクセス端末120によって送信されたペイロードのブラインド検出を実行することによって、アクセスポイント110によって自律的に決定され得る。

LTEでは、PDCCHの開始制御チャネル要素(CCE:Control Channel Element)、PUCCHシフト、およびRB割振りに応じて導出されたPUCCHリソースを識別するためにPUCCHリソースインデックステーブルが使用される。

PUCCH上でのリソース割振りの問題は、各UCI手段(たとえば、UCIペイロード302)が複数のダウンリンクサブフレームに対する確認応答(ACKまたはNACK)を搬送することができるので、対応するダウンリンク許可に基づくマッピングが曖昧である場合があるということである。たとえば、特定のサブフレーム(たとえば、第1のダウンリンクサブフレーム)のダウンリンク許可またはsPUCCHをトリガしたダウンリンク許可などの(LTEで使用する)ダウンリンク許可の開始CCEについて、いくつかの選択肢がある。しかしながら、アクセス端末120は許可のうちのいくつかを失う場合があるが、それでも曖昧さなしでPUCCHリソースを識別することができなければならないので、特定のサブフレームのダウンリンク許可を使用することはうまくいかない場合がある。sPUCCHをトリガしたダウンリンク許可を使用することは、それがグループトリガであるので、実行可能ではない。

この問題に対する解決策は、PUCCHリソースをアクセス端末120に半静的に割り振ることである。

別の解決策は、物理ダウンリンク共有チャネル(PDSCH)をスケジュールするすべてのダウンリンク許可においてPUCCHリソースを動的に割り振ることである。この解決策は、トリガベースのePUCCHまたはsPUCCHに適用可能となろう。具体的には、アクセスポイント110は、以下のうちのいずれかを行い得る。
(i)ダウンリンク許可においてsPUCCHリソースおよびePUCCHリソースを示す、
(ii)sPUCCHリソースおよびePUCCHリソースを半静的に示す、
(iii)ダウンリンク許可においてsPUCCHリソースを示し、ePUCCHリソースを半静的に示す、または
(iv)ダウンリンク許可においてePUCCHリソースを示し、sPUCCHリソースを半静的に示す。

別の解決策は、HARQプロセスのサブセットを各UCIチャネル、すなわち、sPUCCH、ePUCCH、およびPUSCHに半静的に割り当てることである。この解決策は、各物理チャネルによって搬送されるUCIのペイロードサイズを最小限に抑え、それにより、信頼性を高める。この解決策はまた、HARQプロセスのサブセットがUCIチャネルの間でそのように選ばれた場合、複数のチャネル上での同じHARQプロセスについての確認応答を回避する、または少なくとも最小限に抑えることができる。

たとえば、アクセスポイント110は、比較的速いHARQターンアラウンド時間を有するUCIチャネルにマッピングされ、たとえばsPUCCHなどのトリガされたUCIチャネルによって早期に確認応答される可能性が高い(ただし、他のUCIチャネル上で反復される場合もある)、より優先度の高いHARQプロセスのサブセットをスケジュールすることができる。他のHARQプロセス(より優先度の低いHARQプロセス)は、より遅いHARQターンアラウンド時間を有するUCIチャネルを使用してもよい。

別の例として、アクセスポイント110は、他のUCIチャネル上で反復される場合もある、トリガベースのUCIチャネル(たとえば、sPUCCH)に割り当てられたHARQプロセスをスケジュールすることができる。HARQプロセスが一定の時間内に確認応答されない場合、アクセスポイント110は、追加のHARQプロセス上のアクセス端末120を、他のUCIチャネルによって確認応答されるようにスケジュールすることができる。

代替的に、アクセス端末120は、確認応答されるべきHARQプロセスの数の半静的な構成に基づいて、sPUCCH/ePUCCHのペイロードサイズおよびPUSCHチャネル上のUCIを選ぶことができる。

一態様では、アクセスポイント110はまた、アクセスポイント110がsPUCCH/ePUCCHを使用して確認応答されるべき特定のダウンリンク送信を排除することを望む場合、「空のリソース」を示すことが許可され得る。このことは、アクセスポイント110がより良いリソース管理を実行することを可能にする。

sPUCCHは、ダウンリンクサブフレームに対応するUCI送信(たとえば、ACK/NACK)をN〜N+4タイムラインを満たす同じTxOP(T)において搬送し、保留中のUCI送信は、次のTxOP(T+1)において送信されることに留意されたい。解決策は、アクセス端末120が新しいダウンリンク許可を、したがって、TxOP(T+1)の新しいsPUCCHリソースを受信し得るということである。この場合、アクセス端末120は、前のTxOPからの保留中のUCI送信を送信するために、TxOP(T+1)の新しいリソースを使用する。

しかしながら、生じ得る問題は、保留中のTxOPからのsPUCCHが、他のアクセス端末120が利用可能ではないリソースを消費し得るということである。解決策は、アクセスポイント110が、アクセス端末120によって使用されている現在のリソースを解放するために、代替のsPUCCHリソースまたは空のリソースのいずれかを有する新しいsPUCCHリソースを備える空のダウンリンク許可を発行することである。

別の解決策は、保留中のUCI送信を搬送するsPUCCHが「タイムアウト」期間を有するように構成されることである。そのようなタイムアウト期間は、たとえば、TxOPまたは絶対時間(たとえば、ミリ秒)で測定され得る。タイムアウト期間は、静的もしくは半静的に構成されるか、または動的に示され得る。

サウンディング基準信号(SRS:Sounding Reference Signal)送信は、アクセス端末120に固有のアップリンク許可または複数のアクセス端末に共通のPDCCHトリガのいずれかによって構成され得る。SRSはePUSCHとともに生じ得るか、またはSRSはsPUCCHリソースとともに送信され得る。SRS送信の変形態ごとの送信ロケーションが異なっていてもよく、各々のLBT構成が異なっていてもよい。アップリンク許可によってトリガされるSRSの場合、アクセス端末120によるSRS送信のトリガリングを示す1つまたは複数の専用ビットがあってもよい。これらのビットは、PUSCHとともにとは対照的に、SRSがsPUCCHリソース上で送信されることを示すように拡張されてもよい。このことは、アクセスポイント110が、空のPUSCH許可を伴う場合に異なるように解釈されるように「オーバーロードされた」SRSトリガリングビットとともに空のPUSCH許可を提供することによって、達成され得る。たとえば、SRSトリガが空のPUSCH許可を伴う場合、アクセス端末120は、これがsPUCCHリソース上のSRSであると決定し、それに応じて、sPUCCHリソース上のSRSと一致するその送信およびLBTを実行することができる。

アップリンク制御情報は、PUSCHを介して送信されるように構成され得る。アップリンク制御情報は、1つまたは複数のコンポーネントキャリアに対するHARQ ACK/NACK、CSI、SRなどのうちの1つまたは複数を含み得る。集合的に、すべての構成されたコンポーネントキャリアを含むUCIペイロード(たとえば、UCIペイロード302)は、PUSCH上のかなりのオーバーヘッドである場合があり、PUSCH送信に使用される変調およびコーディング方式(MCS)を制限する場合がある。マルチサブフレーム許可では、PUSCHを介したUCI送信は1つまたは複数のサブフレームを介して行われてもよく、このことは曖昧なしでアクセス端末120に示されなければならない。これらの問題は、以下の手法を使用して解決され得る。

一態様では、アクセスポイント110は、マルチサブフレーム許可内の1つまたは複数のビットを使用して、UCIがPUSCHと多重化されることになる1つまたは複数のサブフレームをアクセス端末120に示すことができる。具体的には、アクセスポイント110は、アクセス端末120によってHARQ ACK/NACKフィードバックがPUSCHと多重化されることになる1つもしくは複数のサブフレーム、および/または、アクセス端末120によってCSI/SRフィードバックがPUSCHと多重化されることになる1つもしくは複数のサブフレームをアクセス端末120に示すことができる。許可内のビットは、ビットマップを介して、または、PUSCHを介したUCIの多重化がない可能性とともに最初のサブフレーム、最後のサブフレーム、または周期的なアンカーサブフレームのうちの1つを示すためにビットのサブセットを使用することによって、PUSCH/UCI多重化のための正確なサブフレームを示し得る。

PUSCH性能に対するUCIペイロードの影響を制限するために、UCIは、以下の方法のうちの1つで複数のサブフレームにわたって分散され得る。第1に、UCIは、HARQ ACK/NACKを1つまたは複数のサブフレームの第1のセットの上でPUSCHと多重化し、サブフレームの第1のセットと重複してもよく重複しなくてもよい1つまたは複数のサブフレームの第2のセットの上でCSIと多重化することによって、複数のサブフレームにわたって分散され得る。HARQ ACK/NACKを搬送するサブフレームのロケーションは、アップリンク許可において明示的に指定されてもよく、またはCSIもしくは他のUCIを搬送するサブフレームとの暗黙的な関係によって推測されてもよい。

第2に、UCIは、サブフレームの第1のセットの上のコンポーネントキャリアのあるサブセットのHARQ ACK/NACKおよび/またはCSIと、サブフレームの第2のセットの上のコンポーネントキャリアの異なるサブセットのHARQ ACK/NACKおよび/またはCSIとなどを多重化することによって、複数のサブフレームにわたって分散され得る。コンポーネントキャリアのサブセットについてのUCIを搬送するサブフレームのロケーションは、半静的に事前構成されるか、またはアップリンク許可を介して動的に示されるかのいずれかであり得る。

第3に、UCIは、1つまたは複数のサブフレームのあるセットの上の1つまたは複数のコンポーネントキャリアにまたがるHARQプロセスのサブセットのHARQ ACK/NACKと、1つまたは複数のサブフレームの別のセットの上のHARQプロセスの異なるサブセットのHARQ ACK/NACKとなどを多重化することによって、複数のサブフレームにわたって分散され得る。HARQプロセスのサブセットについてのHARQ ACK/NACKを搬送するサブフレームのロケーションは、半静的に事前構成されるか、またはアップリンク許可を介して動的に示されるかのいずれかであり得る。

加えて、サブフレーム上で搬送されるべきUCIのペイロードサイズがあるしきい値よりも大きい場合、その特定のサブフレーム上のPUSCHのMCSを制限することが好ましい場合がある。しかしながら、マルチサブフレーム許可では、PUSCHのMCSはすべてのサブフレームについて示されない場合があり、代わりに、指示は、許可内のすべてのサブフレームにわたる共通のMCSに対応する場合がある。そのような場合、アクセスポイント110は、UCIペイロード(たとえば、UCIペイロード302)に応じて、アクセス端末120によって使用されるべき代替のMCSを事前構成し得る。代替のMCSは、UCIペイロードサイズに応じた絶対的なMCSとして、または許可において示されたMCSに対するMCSの差分としてのいずれかで指定され得る。

一態様では、上記で説明したリソース割振りに必要な構成は、アクセス端末120上のHARQマネージャ122によって制御され得るおよび/またはHARQマネージャ122内に存在し得る。一態様では、これらの構成は、HARQマネージャ112によって制御されるおよび/またはHARQマネージャ112内に存在する情報に基づいて、アクセスポイント110からHARQマネージャ122において受信され得る。

図8は、上記で説明した技法による、共有通信媒体140などの共有通信媒体上で通信する例示的な方法800を示す流れ図である。方法800は、たとえば、アクセス端末120によって実行され得る。一例として、通信媒体は、LTE技術デバイスとWi-Fi技術デバイスとの間で共有される無認可無線周波数帯域上の1つまたは複数の時間リソース、周波数リソース、または空間リソースを含み得る。

802において、アクセス端末120は、共有通信媒体140上でアクセスポイント110からのダウンリンクサブフレームを受信する。

804において、802においてダウンリンクサブフレームを受信したことに応答して、アクセス端末120は、複数のUCIチャネルのうちの第1のUCIチャネルの第1のアップリンクサブフレーム上で、ダウンリンクサブフレームについてのUCIを送信する。一態様では、第1のUCIチャネルは、上記で説明したように、複数のUCIチャネルのうちの第1の利用可能なUCIチャネルであり得る。その場合、アクセス端末120は、複数のUCIチャネルのうちの別のチャネル上でUCIの送信を反復しない。

一態様では、アクセス端末120は、複数のUCIチャネルのうちの他のUCIチャネルの利用可能性にかかわらず、第1のUCIチャネル上ですべての受信されたダウンリンクフレームについてのすべてのUCIを送信するように構成され得る。

一態様では、方法800は、アクセス端末120が、ダウンリンクサブフレームを受信したことに応答して、複数のUCIチャネルのうちの第2のUCIチャネルの第2のアップリンクサブフレーム上でUCIを送信するステップをさらに含み得る。その場合、UCIは、構成された持続時間の満了前にのみ、第2のUCIチャネルの第2のアップリンクサブフレーム上で送信され得る。加えて、アクセス端末120は、構成された持続時間の満了後に、複数のUCIチャネルのうちの別のチャネル上でUCIの送信を反復しない。構成された持続時間は、アクセスポイント110によって構成され得る。

一態様では、アクセス端末120は、複数のUCIチャネルの特性に基づいて、アクセスポイント110からの入力なしに第1のUCIチャネルを選択し得る。その場合、複数のUCIチャネルの特性は、複数のUCIチャネルのペイロード能力、複数のUCIチャネル上の干渉、複数のUCIチャネルのリンクバジェット条件、またはそれらの任意の組合せを含み得る。

一態様では、UCIはUCIペイロードに含まれてもよく、UCIペイロードは複数のダウンリンクサブフレームについてのUCIを含んでもよい。一態様では、第1のUCIチャネル上のアップリンクリソースは、アクセス端末120に半静的に割り振られ得る。代替的に、第1のUCIチャネル上のアップリンクリソースは、ダウンリンクサブフレームにおいて動的に割り振られ得る。その場合、アップリンクリソースの動的割振りは、ダウンリンクサブフレームにおいて第1の許可ベースのアップリンクリソースおよび第2の許可ベースのアップリンクリソースを示すか、第1の許可ベースのアップリンクリソースおよび第2の許可ベースのアップリンクリソースを半静的に示すか、ダウンリンクサブフレームにおいて第1の許可ベースのアップリンクリソースを示し、第2の許可ベースのアップリンクリソースを半静的に示すか、またはダウンリンクサブフレームにおいて第2の許可ベースのアップリンクリソースを示し、第1の許可ベースのアップリンクリソースを半静的に示す。

一般性のために、アクセスポイント110およびアクセス端末120は、図1には、それぞれHARQマネージャ112およびHARQマネージャ122を含むものとして、関連する部分のみが示されている。しかしながら、アクセスポイント110およびアクセス端末120は、本明細書で説明する確認応答シグナリング技法を提供するかまたはさもなければサポートするように様々な方法で構成され得ることが諒解されよう。

図9は、プライマリRATシステム100のアクセスポイント110およびアクセス端末120の例示的な構成要素をより詳細に示すデバイスレベル図である。図示のように、アクセスポイント110およびアクセス端末120はそれぞれ、一般に、少なくとも1つの指定されたRATを介して他のワイヤレスノードと通信するための(通信デバイス930および950によって表される)ワイヤレス通信デバイスを含み得る。通信デバイス930および950は、指定されたRAT(たとえば、メッセージ、指示、情報、パイロットなど)に従って信号を送信および符号化するために、また逆に、信号を受信および復号するために様々に構成され得る。

通信デバイス930および950は、それぞれ、たとえば、それぞれのプライマリRATトランシーバ932および952、ならびに、いくつかの設計では、(任意選択の)コロケートされたセカンダリRATトランシーバ934および954(たとえば、競合RATシステム150によって用いられるRATに対応する)などの1つまたは複数のトランシーバを含み得る。本明細書で使用する「トランシーバ」は、送信機回路、受信機回路、またはそれらの組合せを含み得るが、すべての設計において送信機能と受信機能の両方を提供する必要はない。たとえば、いくつかの設計では、完全な通信を提供することが必要ではないとき、コストを低減するために低機能受信機回路(たとえば、低レベルのスニッフィングのみを提供する無線チップまたは同様の回路)が用いられ得る。さらに、本明細書で使用する「コロケートされた」(たとえば、無線機、アクセスポイント、トランシーバなど)という用語は、様々な配置のうちの1つを指す場合がある。たとえば、同じハウジング内にある構成要素、同じプロセッサによってホストされる構成要素、互いの規定された距離内にある構成要素、および/またはインターフェースが任意の要求される構成要素間通信(たとえば、メッセージング)のレイテンシ要件を満たす場合にインターフェース(たとえば、イーサネット(登録商標)スイッチ)を介して接続される構成要素である。

アクセスポイント110およびアクセス端末120はまた、それぞれ、一般に、それらのそれぞれの通信デバイス930および950の動作を制御する(たとえば、指示する、変更する、有効化する、無効化するなど)ための(通信コントローラ940および960によって表される)通信コントローラを含み得る。通信コントローラ940および960は、それぞれ、1つまたは複数のプロセッサ942および962と、プロセッサ942および962に結合された1つまたは複数のメモリ944および964とを含み得る。メモリ944および964は、オンボードキャッシュメモリとして、別個の構成要素、組合せなどとしてのいずれかで、データ、命令、またはそれらの組合せを記憶するように構成され得る。プロセッサ942および962ならびにメモリ944および964は、スタンドアロン通信構成要素であってもよく、またはアクセスポイント110およびアクセス端末120のそれぞれのホストシステム機能の一部であってもよい。

HARQマネージャ112およびHARQマネージャ122は、異なる方法で実装され得ることが諒解されよう。いくつかの設計では、それらに関連付けられた機能の一部または全部は、少なくとも1つのプロセッサ(たとえば、プロセッサ942のうちの1つもしくは複数および/またはプロセッサ962のうちの1つもしくは複数)と、少なくとも1つのメモリ(たとえば、メモリ944のうちの1つもしくは複数および/またはメモリ964のうちの1つもしくは複数)とによって、またはさもなければそれらの指示の下で実装され得る。他の設計では、それらに関連付けられた機能の一部または全部は、一連の相互に関係する機能モジュールとして実装され得る。

図10は、一連の相互に関係する機能モジュールとして表されるHARQマネージャ112およびHARQマネージャ122を実装するための例示的なアクセス端末装置を示す。図示の例では、装置1000は、受信するためのモジュール1002と、送信するためのモジュール1004とを含む。受信するためのモジュール1002は、共有通信媒体上でアクセスポイントからのダウンリンクサブフレームを受信するように構成され得る。送信するためのモジュール1004は、ダウンリンクサブフレームを受信したことに応答して、複数のUCIチャネルのうちの第1のUCIチャネルの第1のアップリンクサブフレーム上で、ダウンリンクサブフレームについてのアップリンク制御情報(UCI)を送信するように構成され得る。

図10のモジュールの機能は、本明細書の教示と一致する様々な方法で実装され得る。いくつかの設計では、これらのモジュールの機能は、1つまたは複数の電気構成要素として実装され得る。いくつかの設計では、これらのモジュールの機能は、1つまたは複数のプロセッサ構成要素を含む処理システムとして実装され得る。いくつかの設計では、これらのモジュールの機能は、たとえば、1つまたは複数の集積回路(たとえば、ASIC)の少なくとも一部分を使用して実装され得る。本明細書で説明するように、集積回路は、プロセッサ、ソフトウェア、他の関連する構成要素、またはそれらの何らかの組合せを含み得る。したがって、異なるモジュールの機能は、たとえば、集積回路の異なるサブセットとして、ソフトウェアモジュールのセットの異なるサブセットとして、またはそれらの組合せとして実装され得る。また、(たとえば、集積回路のおよび/またはソフトウェアモジュールのセットの)所与のサブセットは、2つ以上のモジュールの機能の少なくとも一部分を提供し得ることが諒解されよう。

加えて、図10によって表される構成要素および機能、ならびに本明細書で説明する他の構成要素および機能は、任意の適切な手段を使用して実装され得る。そのような手段はまた、少なくとも部分的に、本明細書で教示するような対応する構造を使用して実装され得る。たとえば、図10の「ためのモジュール」構成要素に関連して上記で説明した構成要素は、同様に指定された「ための手段」機能にも対応し得る。したがって、いくつかの態様では、そのような手段のうちの1つまたは複数は、プロセッサ構成要素、集積回路、または、アルゴリズムとしてを含め、本明細書で教示するような他の適切な構造のうちの1つまたは複数を使用して実装され得る。当業者は、本開示では、上記で説明したプロセスにおいて、ならびに擬似コードによって表され得るアクションのシーケンスにおいて表されるアルゴリズムを認識されよう。たとえば、図10によって表される構成要素および機能は、LOAD演算、COMPARE演算、RETURN演算、IF-THEN-ELSEループなどを実行するためのコードを含み得る。

「第1の」、「第2の」などの呼称を使用する本明細書の要素へのいかなる参照も、それらの要素の量または順序を全般的に限定するものではないことを理解されたい。むしろ、これらの呼称は、本明細書では、2つ以上の要素または要素の事例を区別する好都合な方法として使用され得る。したがって、第1の要素および第2の要素への参照は、そこで2つの要素のみが用いられ得ること、または何らかの形で第1の要素が第2の要素に先行しなければならないことを意味しない。また、別段に記載されていない限り、要素のセットは1つまたは複数の要素を備え得る。加えて、本明細書または特許請求の範囲で使用する「A、B、またはCのうちの少なくとも1つ」または「A、B、またはCのうちの1つまたは複数」または「A、B、およびCからなるグループのうちの少なくとも1つ」という形の用語は、「AまたはBまたはCまたはこれらの要素の任意の組合せ」を意味する。たとえば、この用語は、A、またはB、またはC、またはAおよびB、またはAおよびC、またはAおよびBおよびC、または2A、または2B、または2Cなどを含み得る。

上記の記述および説明に鑑みて、本明細書で開示する態様に関して説明する様々な例示的な論理ブロック、モジュール、回路、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、または両方の組合せとして実装され得ることを当業者は諒解されよう。ハードウェアとソフトウェアのこの互換性を明確に示すために、様々な例示的な構成要素、ブロック、モジュール、回路、およびステップについて、上記では概してそれらの機能に関して説明した。そのような機能がハードウェアとして実装されるか、ソフトウェアとして実装されるかは、特定の適用例および全体的なシステムに課される設計制約に依存する。当業者は、説明した機能を特定の適用例ごとに様々な方法で実装し得るが、そのような実装決定は、本開示の範囲からの逸脱を引き起こすものと解釈されるべきではない。

したがって、たとえば、装置または装置の任意の構成要素は、本明細書で教示するような機能を提供するように構成される(または動作可能にされる、または適合される)場合があることが諒解されよう。このことは、たとえば、機能を提供するように装置もしくは構成要素を製造(たとえば、作製)することによって、機能を提供するように装置もしくは構成要素をプログラミングすることによって、または何らかの他の適切な実装技法を使用することによって達成され得る。一例として、集積回路は、必要な機能を提供するように作製され得る。別の例として、集積回路は、必要な機能をサポートするように作製され、次いで、必要な機能を提供するように(たとえば、プログラミングを介して)構成され得る。また別の例として、プロセッサ回路は、必要な機能を提供するためにコードを実行し得る。

さらに、本明細書で開示する態様に関して説明する方法、シーケンス、および/またはアルゴリズムは、直接ハードウェアにおいて、プロセッサによって実行されるソフトウェアモジュールにおいて、またはこの2つの組合せにおいて具現化され得る。ソフトウェアモジュールは、ランダムアクセスメモリ(RAM)、フラッシュメモリ、読取り専用メモリ(ROM)、消去可能プログラマブル読取り専用メモリ(EPROM)、電気的消去可能プログラマブル読取り専用メモリ(EEPROM)、レジスタ、ハードディスク、リムーバブルディスク、CD-ROM、または当技術分野で知られている一時的もしくは非一時的な任意の他の形態の記憶媒体内に存在する場合がある。例示的な記憶媒体は、プロセッサが記憶媒体から情報を読み取り、記憶媒体に情報を書き込むことができるように、プロセッサに結合される。代替として、記憶媒体は、プロセッサ(たとえば、キャッシュメモリ)と一体であってもよい。

したがって、たとえば、本開示のいくつかの態様は、通信のための方法を具現化する一時的または非一時的コンピュータ可読媒体を含むことができることも諒解されよう。

上記の開示は様々な例示的な態様を示すが、添付の特許請求の範囲によって定義される範囲から逸脱することなく、図示した例に対して様々な変更および修正を加えてもよいことに留意されたい。本開示は、具体的に図示した例のみに限定されるものではない。たとえば、別段に記載されていない限り、本明細書で説明する本開示の態様による方法クレームの機能、ステップ、および/またはアクションは、任意の特定の順序で実行される必要はない。さらに、いくつかの態様は、単数形で説明または特許請求される場合があるが、単数形への限定が明示的に述べられていない限り、複数形が企図される。

100 「プライマリ」無線アクセス技術(RAT)システム、プライマリRATシステム、「プライマリ」RATシステム
110 アクセスポイント
112 ハイブリッド自動再送要求(HARQ)マネージャ、HARQマネージャ
120 アクセス端末
122 HARQマネージャ
130、132 ワイヤレスリンク
140 共有通信媒体、通信媒体
150 「競合」RATシステム、競合RATシステム
152 競合ノード
300 アップリンクサブフレーム
302 UCIペイロード
400、500、600 HARQタイミング図
402、404、406、408、502、504、506、508、510、602、604、606、608、610 動作
800 方法
930、950 通信デバイス
932、952 プライマリRATトランシーバ
934、954 セカンダリRATトランシーバ
940、960 通信コントローラ
942、962 プロセッサ
944、964 メモリ
1000 装置
1002 受信するためのモジュール
1004 送信するためのモジュール

Claims

共有通信媒体上で通信する方法であって、
アクセス端末において、前記共有通信媒体上でアクセスポイントからのダウンリンクサブフレームを受信するステップと、
前記ダウンリンクサブフレームを受信したことに応答して、前記アクセス端末によって、複数のUCIチャネルのうちの第1のUCIチャネルの第1のアップリンクサブフレーム上で、前記ダウンリンクサブフレームについてのアップリンク制御情報(UCI)を送信するステップと
を含む方法。
前記第1のUCIチャネルが、前記複数のUCIチャネルのうちの第1の利用可能なUCIチャネルである、請求項1に記載の方法。
前記アクセス端末が、前記複数のUCIチャネルのうちの別のチャネル上で前記UCIの送信を反復しない、請求項2に記載の方法。
前記アクセス端末が、前記複数のUCIチャネルのうちの他のUCIチャネルの利用可能性にかかわらず、前記第1のUCIチャネル上ですべての受信されたダウンリンクフレームについてのすべてのUCIを送信するように構成される、請求項1に記載の方法。
前記ダウンリンクサブフレームを受信したことに応答して、前記アクセス端末によって、前記複数のUCIチャネルのうちの第2のUCIチャネルの第2のアップリンクサブフレーム上で前記UCIを送信するステップをさらに含み、
前記UCIが、構成された持続時間の満了前にのみ、前記第2のUCIチャネルの前記第2のアップリンクサブフレーム上で送信される、
請求項1に記載の方法。
前記アクセス端末が、前記構成された持続時間の満了後に、前記複数のUCIチャネルのうちの別のチャネル上で前記UCIの送信を反復しない、請求項5に記載の方法。
前記構成された持続時間が、前記アクセスポイントによって構成される、請求項5に記載の方法。
前記アクセス端末が、前記複数のUCIチャネルの特性に基づいて、前記アクセスポイントからの入力なしに前記第1のUCIチャネルを選択する、請求項1に記載の方法。
前記複数のUCIチャネルの前記特性が、前記複数のUCIチャネルのペイロード能力、前記複数のUCIチャネル上の干渉、前記複数のUCIチャネルのリンクバジェット条件、またはそれらの任意の組合せを含む、請求項8に記載の方法。
前記UCIがUCIペイロードに含まれ、前記UCIペイロードが複数のダウンリンクサブフレームについてのUCIを含む、請求項1に記載の方法。
前記第1のUCIチャネル上のアップリンクリソースが、前記アクセス端末に半静的に割り振られる、請求項10に記載の方法。
前記第1のUCIチャネル上のアップリンクリソースが、前記ダウンリンクサブフレームにおいて動的に割り振られる、請求項10に記載の方法。
前記アップリンクリソースの前記動的割振りが、
前記ダウンリンクサブフレームにおいて第1の許可ベースのアップリンクリソースおよび第2の許可ベースのアップリンクリソースを示すか、
前記第1の許可ベースのアップリンクリソースおよび前記第2の許可ベースのアップリンクリソースを半静的に示すか、
前記ダウンリンクサブフレームにおいて前記第1の許可ベースのアップリンクリソースを示し、前記第2の許可ベースのアップリンクリソースを半静的に示すか、または
前記ダウンリンクサブフレームにおいて前記第2の許可ベースのアップリンクリソースを示し、前記第1の許可ベースのアップリンクリソースを半静的に示す、
請求項12に記載の方法。
共有通信媒体上で通信するための装置であって、
前記共有通信媒体上でアクセスポイントからのダウンリンクサブフレームを受信するように構成された、アクセス端末のトランシーバと、
前記トランシーバに、前記ダウンリンクサブフレームの受信に応答して、複数のUCIチャネルのうちの第1のUCIチャネルの第1のアップリンクサブフレーム上で、前記ダウンリンクサブフレームについてのアップリンク制御情報(UCI)を送信させるように構成された、前記アクセス端末の少なくとも1つのプロセッサと
を備える装置。
前記第1のUCIチャネルが、前記複数のUCIチャネルのうちの第1の利用可能なUCIチャネルである、請求項14に記載の装置。
前記アクセス端末が、前記複数のUCIチャネルのうちの別のチャネル上で前記UCIの送信を反復しない、請求項15に記載の装置。
前記アクセス端末が、前記複数のUCIチャネルのうちの他のUCIチャネルの利用可能性にかかわらず、前記第1のUCIチャネル上ですべての受信されたダウンリンクフレームについてのすべてのUCIを送信するように構成される、請求項14に記載の装置。
前記少なくとも1つのプロセッサが、
前記トランシーバに、前記ダウンリンクサブフレームの受信に応答して、前記複数のUCIチャネルのうちの第2のUCIチャネルの第2のアップリンクサブフレーム上で前記UCIを送信させるようにさらに構成され、
前記UCIが、構成された持続時間の満了前にのみ、前記第2のUCIチャネルの前記第2のアップリンクサブフレーム上で送信される、
請求項14に記載の装置。
前記アクセス端末が、前記構成された持続時間の満了後に、前記複数のUCIチャネルのうちの別のチャネル上で前記UCIの送信を反復しない、請求項18に記載の装置。
前記構成された持続時間が、前記アクセスポイントによって構成される、請求項18に記載の装置。
前記アクセス端末が、前記複数のUCIチャネルの特性に基づいて、前記アクセスポイントからの入力なしに前記第1のUCIチャネルを選択する、請求項14に記載の装置。
前記複数のUCIチャネルの前記特性が、前記複数のUCIチャネルのペイロード能力、前記複数のUCIチャネル上の干渉、前記複数のUCIチャネルのリンクバジェット条件、またはそれらの任意の組合せを含む、請求項21に記載の装置。
前記UCIがUCIペイロードに含まれ、前記UCIペイロードが複数のダウンリンクサブフレームについてのUCIを含む、請求項14に記載の装置。
前記第1のUCIチャネル上のアップリンクリソースが、前記アクセス端末に半静的に割り振られる、請求項23に記載の装置。
前記第1のUCIチャネル上のアップリンクリソースが、前記ダウンリンクサブフレームにおいて動的に割り振られる、請求項23に記載の装置。
前記アップリンクリソースの前記動的割振りが、
前記ダウンリンクサブフレームにおいて第1の許可ベースのアップリンクリソースおよび第2の許可ベースのアップリンクリソースを示すか、
前記第1の許可ベースのアップリンクリソースおよび前記第2の許可ベースのアップリンクリソースを半静的に示すか、
前記ダウンリンクサブフレームにおいて前記第1の許可ベースのアップリンクリソースを示し、前記第2の許可ベースのアップリンクリソースを半静的に示すか、または
前記ダウンリンクサブフレームにおいて前記第2の許可ベースのアップリンクリソースを示し、前記第1の許可ベースのアップリンクリソースを半静的に示す、
請求項25に記載の装置。
共有通信媒体上で通信するための装置であって、
前記共有通信媒体上でアクセスポイントからのダウンリンクサブフレームを受信するように構成された、アクセス端末の通信手段と、
前記通信手段に、前記ダウンリンクサブフレームの受信に応答して、複数のUCIチャネルのうちの第1のUCIチャネルの第1のアップリンクサブフレーム上で、前記ダウンリンクサブフレームについてのアップリンク制御情報(UCI)を送信させるように構成された、前記アクセス端末の処理手段と
を備える装置。
共有通信媒体上で通信するためのコンピュータ実行可能命令を記憶した非一時的コンピュータ可読記録媒体であって、前記コンピュータ実行可能命令が、
アクセス端末に、前記共有通信媒体上でアクセスポイントからのダウンリンクサブフレームを受信させるための少なくとも1つの命令と、
前記アクセス端末に、前記ダウンリンクサブフレームの受信に応答して、複数のUCIチャネルのうちの第1のUCIチャネルの第1のアップリンクサブフレーム上で、前記ダウンリンクサブフレームについてのアップリンク制御情報(UCI)を送信させるための少なくとも1つの命令と
を備える、非一時的コンピュータ可読記録媒体。