知財求人 - 知財ポータルサイト「IP Force」
特表2022-540257無線通信システムにおける物理上りリンク共有チャネル（ＰＵＳＣＨ）繰り返し送信を処理するための方法及び装置
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2022-09-14
(54)【発明の名称】無線通信システムにおける物理上りリンク共有チャネル（ＰＵＳＣＨ）繰り返し送信を処理するための方法及び装置
(51)【国際特許分類】
H04W 72/12 20090101AFI20220907BHJP
H04W 72/04 20090101ALI20220907BHJP
【ＦＩ】
H04W72/12 150
H04W72/04 137
H04W72/04 136
【審査請求】有
【予備審査請求】未請求
(21)【出願番号】P 2022502129
(86)(22)【出願日】2020-07-15
(85)【翻訳文提出日】2022-01-12
(86)【国際出願番号】 CN2020102147
(87)【国際公開番号】W WO2021008558
(87)【国際公開日】2021-01-21
(31)【優先権主張番号】62/875,335
(32)【優先日】2019-07-17
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．３ＧＰＰ
２．ＷＣＤＭＡ
(71)【出願人】
【識別番号】518446879
【氏名又は名称】鴻穎創新有限公司
【氏名又は名称原語表記】ＦＧ ＩＮＮＯＶＡＴＩＯＮ ＣＯＭＰＡＮＹ ＬＩＭＩＴＥＤ
【住所又は居所原語表記】Ｆｌａｔ ２６２３，２６／Ｆ Ｔｕｅｎ Ｍｕｎ Ｃｅｎｔｒａｌ Ｓｑｕａｒｅ，２２ Ｈｏｉ Ｗｉｎｇ Ｒｏａｄ，Ｔｕｅｎ Ｍｕｎ，Ｎｅｗ Ｔｅｒｒｉｔｏｒｉｅｓ，Ｔｈｅ Ｈｏｎｇ Ｋｏｎｇ Ｓｐｅｃｉａｌ Ａｄｍｉｎｉｓｔｒａｔｉｖｅ Ｒｅｇｉｏｎ ｏｆ ｔｈｅ Ｐｅｏｐｌｅ’ｓ Ｒｅｐｕｂｌｉｃ ｏｆ Ｃｈｉｎａ
(74)【代理人】
【識別番号】110000338
【氏名又は名称】特許業務法人ＨＡＲＡＫＥＮＺＯ ＷＯＲＬＤ ＰＡＴＥＮＴ ＆ ＴＲＡＤＥＭＡＲＫ
(72)【発明者】
【氏名】ウェイ，チャホン
(72)【発明者】
【氏名】チン，ホンリー
(72)【発明者】
【氏名】リン，ワンチェン
(72)【発明者】
【氏名】チョウ，チェミン
【テーマコード（参考）】
5K067
【Ｆターム（参考）】
5K067DD34
5K067EE02
5K067EE10
5K067HH22
(57)【要約】
ユーザ機器（ＵＥ）によって実行される方法は、提供される。本方法は、第１の値を用いて設定された第１のパラメータと、少なくとも１つの第２の値を用いて設定された第２のパラメータと、を含む無線リソース制御（ＲＲＣ）設定を受信するＵＥを含む。第１の値及び少なくとも１つの第２の値の各々は、ＰＵＳＣＨの繰り返しの数を示す。本方法は、物理下りリンク制御チャネル（ＰＤＣＣＨ）の下りリンク制御情報（ＤＣＩ）を受信し、物理上りリンク共有チャネル（ＰＵＳＣＨ）送信をスケジューリングし、ＤＣＩに従って、ＰＵＳＣＨ送信のためのＰＵＳＣＨの繰り返しの数を決定するために、第１のパラメータ及び第２のパラメータの内の１つを選択し、第１のパラメータが選択されたとき、ＰＵＳＣＨ送信のためのＰＵＳＣＨの繰り返しの数を、第１の値に決定し、第２のパラメータが選択されたとき、ＰＵＳＣＨ送信のためのＰＵＳＣＨの繰り返しの数を、ＤＣＩによって示された少なくとも１つの第２の値の内の１つに決定し、ＰＵＳＣＨの繰り返しの数に基づいて、ＰＵＳＣＨ送信を複数回、実行することを更に含む。
【特許請求の範囲】
【請求項1】
無線通信システムにおける繰り返し送信を処理するためにユーザ機器（ＵＥ：User Equipment）によって実行される方法であって、前記方法は、物理上りリンク共有チャネル（ＰＵＳＣＨ：Physical Uplink Shared Channel）の繰り返し送信数を示す、第１の値を用いて設定された第１のパラメータ、及び、ＰＵＳＣＨの繰り返し送信数を示す少なくとも１つの第２の値を用いて設定された第２のパラメータを含む無線リソース制御（ＲＲＣ：Radio Resource Control）設定を受信する工程、
ＰＵＳＣＨ送信をスケジューリングする物理下りリンク制御チャネル（ＰＤＣＣＨ：Physical Downlink Control Channel）で下りリンク制御情報（ＤＣＩ：Downlink Control Information）を受信する工程、
前記ＤＣＩに従って、前記ＰＵＳＣＨ送信のためのＰＵＳＣＨの繰り返しの数を決定するために、前記第１のパラメータ及び前記第２のパラメータの内の１つを選択する工程、
前記第１のパラメータが選択されたとき、前記ＰＵＳＣＨ送信のための前記ＰＵＳＣＨの繰り返しの数を前記第１の値に決定する工程、
前記第２のパラメータが選択されたとき、前記ＰＵＳＣＨ送信のための前記ＰＵＳＣＨの繰り返しの数を、前記ＤＣＩによって示された前記少なくとも１つの第２の値の内の１つに決定する工程、及び
前記ＰＵＳＣＨ送信のための前記ＰＵＳＣＨの繰り返しの数に基づいて、前記ＰＵＳＣＨ送信を複数回、実行する工程、
を含む、方法。
【請求項2】
前記ＤＣＩが、前記第２のパラメータに関連付けられたＤＣＩフォーマットを有し、前記少なくとも１つの第２の値の内の１つを示すインデックスを含むとき、前記ＰＵＳＣＨ送信のための前記ＰＵＳＣＨの繰り返しの数を決定するために前記第２のパラメータを選択する工程、を更に含む、請求項１に記載の方法。
【請求項3】
前記第２のパラメータは、前記インデックスと、前記ＰＵＳＣＨ送信の開始シンボルを示す第３の値、及び、前記ＰＵＳＣＨ送信の連続シンボルの数を示す第４の値を含む値のセットと、の間の関連付けを定義する、請求項２に記載の方法。
【請求項4】
前記第１のパラメータ及び前記第２のパラメータは、帯域幅部分（ＢＷＰ：Bandwidth Part）に基づいて設定される、請求項１に記載の方法。
【請求項5】
無線通信システムにおける繰り返し送信を処理するためのユーザ機器（ＵＥ：User Equipment）であって、前記ＵＥは、コンピュータ実行可能命令が実装された１つ又は複数の非一時的コンピュータ読み取り可能媒体、及び
前記１つ又は複数の非一時的コンピュータ読み取り可能媒体に結合され、前記コンピュータ実行可能命令を実行するように構成された少なくとも１つのプロセッサを含み、
前記少なくとも１つのプロセッサは、前記コンピュータ実行可能命令を実行することにより、
物理上りリンク共有チャネル（ＰＵＳＣＨ：Physical Uplink Shared Channel）の繰り返し送信数を示す第１の値を用いて設定された第１のパラメータ、及び、ＰＵＳＣＨの繰り返し送信数を示す少なくとも１つの第２の値を用いて設定された第２のパラメータを備える無線リソース制御（ＲＲＣ：Radio Resource Control）設定を受信し、
ＰＵＳＣＨ送信をスケジューリングする物理下りリンク制御チャネル（ＰＤＣＣＨ：Physical Downlink Control Channel）で下りリンク制御情報（ＤＣＩ：Downlink Control Information）を受信し、
前記ＤＣＩに従って、前記ＰＵＳＣＨ送信のためのＰＵＳＣＨの繰り返しの数を決定するために、前記第１のパラメータ及び前記第２のパラメータの内の１つを選択し、
前記第１のパラメータが選択されたとき、前記ＰＵＳＣＨ送信のための前記ＰＵＳＣＨの繰り返しの数を前記第１の値に決定し、
前記第２のパラメータが選択されたとき、前記ＰＵＳＣＨ送信のための前記ＰＵＳＣＨの繰り返しの数を、前記ＤＣＩによって示された前記少なくとも１つの第２の値の内の１つに決定し、及び
前記ＰＵＳＣＨ送信のための前記ＰＵＳＣＨの繰り返しの数に基づいて、前記ＰＵＳＣＨ送信を複数回、実行する、
ように構成されている、ＵＥ。
【請求項6】
前記少なくとも１つのプロセッサは、前記コンピュータ実行可能命令を実行することにより、前記ＤＣＩが、前記第２のパラメータに関連付けられたＤＣＩフォーマットを有し、及び前記少なくとも１つの第２の値の内の１つを示しているインデックスを備えるとき、前記ＰＵＳＣＨ送信のための前記ＰＵＳＣＨの繰り返しの数を決定するために前記第２のパラメータを選択する、
ように更に構成される、請求項５に記載の方法。
【請求項7】
前記第２のパラメータは、前記インデックスと、前記ＰＵＳＣＨ送信の開始シンボルを示す第３の値、及び、前記ＰＵＳＣＨ送信の連続シンボルの数を示す第４の値を含む値のセットと、の間の関連付けを定義する、請求項６に記載の方法。
【請求項8】
前記第１のパラメータ及び前記第２のパラメータは、帯域幅部分（ＢＷＰ：Bandwidth Part）に基づいて設定される、請求項５に記載の方法。
【発明の詳細な説明】
【発明の詳細な説明】
【0001】
〔関連出願の相互参照〕
本開示は２０１９年７月１７日に出願された仮米国特許出願第６２／８７５，３３５号（「‘３３５仮出願」）の利益及び優先権を主張し、“Operation among Enhanced Repetition of PUSCH Transmission.”と題され、上記の全ての出願の内容は、全ての目的のために参照により本明細書に完全に組み込まれる。
本開示は２０１９年７月１７日に出願された仮米国特許出願第６２／８７５，３３５号（「‘３３５仮出願」）の利益及び優先権を主張し、“Operation among Enhanced Repetition of PUSCH Transmission.”と題され、上記の全ての出願の内容は、全ての目的のために参照により本明細書に完全に組み込まれる。
【0002】
〔分野〕
本開示は一般に、無線通信に関し、より詳細には、無線通信システムにおける物理上りリンク（ＵＬ：Uplink）共有チャネル（ＰＵＳＣＨ：Physical Uplink Shared Channel）繰り返し送信を処理するための方法及び装置に関する。
本開示は一般に、無線通信に関し、より詳細には、無線通信システムにおける物理上りリンク（ＵＬ：Uplink）共有チャネル（ＰＵＳＣＨ：Physical Uplink Shared Channel）繰り返し送信を処理するための方法及び装置に関する。
【0003】
〔背景〕
接続されたデバイスの数の大幅な増加及びユーザ／ネットワークトラフィック量の急速な増加に伴って、データ速度、遅延、信頼性、及びモビリティを改善することによって、第５世代（５Ｇ：fifth generation）新しい無線（ＮＲ：New Radio）といった次世代無線通信システムのための無線通信の異なる態様を改善するために、様々な努力がなされてきた。
接続されたデバイスの数の大幅な増加及びユーザ／ネットワークトラフィック量の急速な増加に伴って、データ速度、遅延、信頼性、及びモビリティを改善することによって、第５世代（５Ｇ：fifth generation）新しい無線（ＮＲ：New Radio）といった次世代無線通信システムのための無線通信の異なる態様を改善するために、様々な努力がなされてきた。
【0004】
５Ｇ ＮＲシステムは、拡張モバイルブロードバンド（ｅＭＢＢ：enhanced Mobile Broadband）、大規模マシンタイプ通信（ｍＭＴＣ：massive Machine－Type Communication）、及び超信頼性及び低遅延通信（ＵＲＬＬＣ：Ultra-Reliable and Low-Latency Communication）といった様々なユースケースに対応して、ネットワークサービス及びタイプを最適化するための柔軟性及び構成可能性を提供するように設計される。
【0005】
しかしながら、無線アクセスの需要が増加し続けるにつれて、次世代無線通信システムのための無線通信の更なる改善が必要とされている。
【0006】
〔概要〕
本開示は、無線通信システムにおけるＰＵＳＣＨ繰り返し送信を処理するための方法及び装置を対象とする。
本開示は、無線通信システムにおけるＰＵＳＣＨ繰り返し送信を処理するための方法及び装置を対象とする。
【0007】
本開示の態様によれば、無線通信システムにおける繰り返し送信を処理するためにユーザ機器（ＵＥ）によって実行される方法が提供される。本方法は、第１の値を用いて設定された第１のパラメータ、及び、少なくとも１つの第２の値を用いて設定された第２のパラメータを含む無線リソース制御（ＲＲＣ）設定を受信するＵＥを含む。第１の値及び少なくとも１つの第２の値の各々は、物理上りリンク共有チャネル（ＰＵＳＣＨ）の繰り返しの数を示す。本方法は、ＵＥがＰＵＳＣＨ送信をスケジューリングする物理下りリンク制御チャネル（ＰＤＣＣＨ）で下りリンク制御情報（ＤＣＩ）を受信する工程、ＤＣＩに従って、ＰＵＳＣＨ送信のためのＰＵＳＣＨの繰り返しの数を決定するために、第１のパラメータ及び第２のパラメータの内の１つを選択する工程、第１のパラメータが選択されたとき、ＰＵＳＣＨ送信のための繰り返しの数として第１の値を適用する工程、第２のパラメータが選択されたとき、ＰＵＳＣＨ送信のためのＰＵＳＣＨの繰り返しの数として、ＤＣＩによって示される少なくとも１つの第２の値の内の１つを適用する工程、ＰＵＳＣＨ送信を複数回、実行する工程を更に含む。回数は、ＰＵＳＣＨ送信のためのＰＵＳＣＨの繰り返しの数によって決定される。
【0008】
本開示の別の態様によれば、無線通信システムにおける繰り返し送信を処理するためのＵＥが提供される。ＵＥは、実装されたコンピュータ実行可能命令を有する１つ又は複数の非一時的コンピュータ読み取り可能媒体、及び１つ又は複数の非一時的コンピュータ読み取り可能媒体に結合された少なくとも１つのプロセッサを含む。少なくとも１つのプロセッサは、コンピュータ実行可能命令を実行することにより、第１の値を用いて設定された第１のパラメータ、及び、少なくとも１つの第２の値を用いて設定された第２のパラメータを含むＲＲＣ設定を受信するように構成される。第１の値及び少なくとも１つの第２の値の各々は、ＰＵＳＣＨの繰り返しの数を示す。少なくとも１つのプロセッサは更に、ＰＵＳＣＨ送信をスケジューリングするＰＤＣＣＨでＤＣＩを受信するために、コンピュータ実行可能命令を実行し、ＤＣＩに従って、第１のパラメータ及び第２のパラメータの内の１つを選択し、ＰＵＳＣＨ送信のためのＰＵＳＣＨの繰り返しの数を決定し、第１のパラメータが選択されたとき、ＰＵＳＣＨ送信のためのＰＵＳＣＨの繰り返しの数を第１の値として適用し、第２のパラメータが選択されたとき、ＰＵＳＣＨ送信のためのＰＵＳＣＨの繰り返しの数としてＤＣＩによって示される少なくとも１つの第２の値の１つを適用し、及びＰＵＳＣＨ送信を複数回、実行するように構成される。回数は、ＰＵＳＣＨ送信のためのＰＵＳＣＨの繰り返しの数によって決定される。
【0009】
〔図面の簡単な説明〕
本開示の態様は、添付の図面と共に読まれるとき、以下の詳細な説明から最も良く理解される。様々な特徴は、一定の縮尺で描かれておらず、様々な特徴の寸法は、議論を明確にするために任意に増減されてもよい。
本開示の態様は、添付の図面と共に読まれるとき、以下の詳細な説明から最も良く理解される。様々な特徴は、一定の縮尺で描かれておらず、様々な特徴の寸法は、議論を明確にするために任意に増減されてもよい。
【0010】
図１は、本開示の一実装形態による、ＰＤＣＣＨによってスケジュールされたＰＵＳＣＨ送信を示す図である。
【0011】
図２は、本開示の別の実装形態による、ＰＤＣＣＨによってスケジュールされたＰＵＳＣＨ送信を示す図である。
【0012】
図３は、本開示の一実装形態による、非スロットベースの繰り返しスキームが適用されるとき、下りリンク（ＤＬ：downlink）シンボル又はスロット境界をクロスするＰＵＳＣＨ繰り返し送信を示す図である。
【0013】
図４は、本開示の一実装形態による、非スロットベースの繰り返しスキームが適用されるとき、ＤＬシンボルをクロスするＰＵＳＣＨ繰り返し送信を示す図である。
【0014】
図５は、本開示の一実装形態による、スロット当たりのシンボル数よりも大きいＳ＋Ｌの値を有するＵＬグラントに関連するＰＵＳＣＨ送信を示す図である。
【0015】
図６は、本開示の一実装形態による、非スロットベースの繰り返しスキームが適用されるとき、フレキシブルシンボルをクロスするＰＵＳＣＨ繰り返し送信を示す図である。
【0016】
図７は、本開示の一実装形態による、動的インディケーションモードと非動的インディケーションモードとの間で切り替わるユーザ機器（ＵＥ：user equipment）を示す図である。
【0017】
図８は、本開示の一実装形態による、ＵＥによって実行される手順のフローチャートを示す。
【0018】
図９は、本開示の一実装形態による、ＵＥによって実行される手順のフローチャートを示す。
【0019】
図１０は、本開示の様々な態様による、無線通信のためのノードのブロック図を示す。
【0020】
〔詳細な説明〕
以下の説明は、本開示における一例としての実装形態に関連する特定の情報を含む。本開示における図面及びそれらの添付の詳細な説明は、単に例としての実装形態を対象としている。しかし、本開示は、これらの例としての実装形態のみに限定されるものではない。本開示の他の変形例及び実装形態は、当業者には想起されるであろう。特に断らない限り、複数の図中の同様の又は対応する要素は、同様の又は対応する参照番号によって示され得る。更に、本開示における図面及び図示は、ほとんどの場合、一定の縮尺ではなく、実際の相対的な寸法に対応することを意図していない。
以下の説明は、本開示における一例としての実装形態に関連する特定の情報を含む。本開示における図面及びそれらの添付の詳細な説明は、単に例としての実装形態を対象としている。しかし、本開示は、これらの例としての実装形態のみに限定されるものではない。本開示の他の変形例及び実装形態は、当業者には想起されるであろう。特に断らない限り、複数の図中の同様の又は対応する要素は、同様の又は対応する参照番号によって示され得る。更に、本開示における図面及び図示は、ほとんどの場合、一定の縮尺ではなく、実際の相対的な寸法に対応することを意図していない。
【0021】
以下の説明は、本開示における例としての実装形態に関連する特定の情報を含む。本開示における図面及びそれらの添付の詳細な説明は、単に例としての実装形態を対象としている。しかし、本開示は、これらの例としての実装形態のみに限定されるものではない。本開示の他の変形例及び実装形態は、当業者には想起されるであろう。特に断らない限り、複数の図中の同様の又は対応する要素は、同様の又は対応する参照番号によって示され得る。更に、本開示における図面及び図示は、ほとんどの場合、一定の縮尺ではなく、実際の相対的な寸法に対応することを意図していない。
【0022】
一貫性の目的及び理解を容易にするために、同様の特徴は、例としての図において同じ数字によって識別され得る（ただし、いくつかの例において、図示されていない）。しかしながら、異なる実装形態における特徴は、他の点で異なっていてもよく、従って、図面に示されるものに狭く限定されるものではない。
【0023】
「１つの実装形態」、「一実装形態」、「例としての実装形態」、「様々な実装形態」、「いくつかの実装形態」、「本出願のいくつかの実装形態」などへの言及は、そのように記載された本出願の実装形態（単数または複数）が特定の特徴、構造、または特性を含み得ることを示し得るが、本出願のすべての可能な実装形態が特定の特徴、構造、または特性を必ずしも含むわけではない。さらに、語句「１つの実装形態において」、「一例としての実装形態において」、又は「一実装形態」の繰り返しの使用は必ずしも、同じ実装形態を指すわけではないが、同じ実装形態を指す場合もある。さらに、「本出願」に接続する「実装形態」のような語句の任意の使用は、本出願のすべての実装形態が特定の特徴、構造、または特性を含んでいなければならないことを特徴とすることを意味せず、また、代わりに、「本出願の少なくともいくつかの実装形態」が、特定の特徴、構造または特性を含むことを意味することを理解されたい。用語「接続した（coupled）」は介在する構成要素を介して直接的または間接的であるかにかかわらず、接続されることと定義されるが、物理的な接続に必ずしも限定されない。「備える（comprise）」という単語は、使用される場合、「含む(include)、が限定するわけではない、」を意味するが、このように記載された組合せ、群、系列および均等物におけるオープンエンド包括またはメンバーシップを具体的に示す。
【0024】
本明細書中の用語「及び／又は」は、関連するオブジェクトを記述するための関連した関係のみであり、３つの関係が存在し得ることを表し、例えば、Ａ及び／又はＢは以下を表すことができる。Ａは単独で存在し、Ａ及びＢは同時に存在し、Ｂは単独で存在する。更に、本明細書中で使用される文字「／」は、前者及び後者の関連する物体が「又は」関係にあることを一般的に表す。
【0025】
更に、説明及び非限定の目的のために、機能エンティティ、技法、プロトコル、規格などの具体的な詳細が、説明される技術の理解を実現するために記載される。他の例において、不必要な詳細で説明を不明瞭にしないように、周知の方法、技術、システム、アーキテクチャなどの詳細な説明は、省略される。
【0026】
当業者は、本開示に記載されている任意のネットワーク機能（複数種類可）又はアルゴリズム（複数種類可）が、ハードウェア、ソフトウェア、又はソフトウェアとハードウェアの組み合わせによって実装されてもよいことを直ちに理解するだろう。説明される機能は、ソフトウェア、ハードウェア、ファームウェア、又はそれらの任意の組み合わせであり得るモジュールに対応し得る。ソフトウェアの実装形態は、メモリ又は他の種類の記憶装置などのコンピュータ読み取り可能媒体に記憶されたコンピュータ実行可能命令を備えてもよい。例えば、通信処理能力を有する１つ又は複数のマイクロプロセッサ又は汎用コンピュータを、対応する実行可能命令を用いてプログラムし、記述されたネットワーク機能（複数種類可）又はアルゴリズム（複数種類可）を実行することができる。マイクロプロセッサ又は汎用コンピュータは、特定用途向け集積回路（ＡＳＩＣ）、プログラマブルロジックアレイ、及び／又は１つ又は複数のデジタル信号プロセッサ（ＤＳＰ）を使用して形成することができる。本明細書に記載されている例としての実装形態のいくつかは、コンピュータハードウェア上にインストールされ実行されるソフトウェアを指向しているが、それにもかかわらず、ファームウェアとして、又はハードウェアとして、又はハードウェアとソフトウェアの組合せとして実装される代替の実施例は、本開示の範囲内に十分にある。
【0027】
コンピュータ読み取り可能媒体は、ランダムアクセスメモリ（ＲＡＭ：Random Access Memory）、読み取り専用メモリ（ＲＯＭ：Read Only Memory）、消去可能プログラマブル読み取り専用メモリ（ＥＰＲＯＭ：Erasable Programmable Read-Only Memory）、電気的消去可能プログラマブル読み取り専用メモリ（ＥＥＰＲＯＭ：Electrically Erasable Programmable Read-Only Memory）、フラッシュメモリ、コンパクトディスク読み取り専用メモリ（ＣＤ－ＲＯＭ：Compact Disc Read-Only Memory）、磁気カセット、磁気テープ、磁気ディスク記憶装置、又はコンピュータ読み取り可能命令を記憶可能な他の任意の同等の媒体を含むが、これらに限定されない。
【0028】
無線通信ネットワークアーキテクチャ（例えばロングタームエボリューション（ＬＴＥ：Long Term Evolution）システム、ＬＴＥ－Ａｄｖａｎｃｅｄ（ＬＴＥ－Ａ）システム、ＬＴＥ－Ａｄｖａｎｃｅｄ Ｐｒｏシステム、又は５Ｇ 新無線（ＮＲ）無線アクセスネットワーク（ＲＡＮ））は、通常、少なくとも１つの基地局、少なくとも１つのユーザ機器（ＵＥ）、及びネットワークへの接続を提供する１つ又は複数のオプションのネットワーク要素を含む。ＵＥは、１つ又は複数の基地局によって確立されたＲＡＮを介して、ネットワーク（例えばコアネットワーク（ＣＮ）、エボルブドパケットコア（ＥＰＣ：Evolved Packet Core）ネットワーク、エボルブドユニバーサルテレストリアル無線アクセスネットワーク（Ｅ－ＵＴＲＡＮ：Evolved Universal Terrestrial Radio Access network）、５Ｇコア（５ＧＣ）、又はインターネット）と通信する。
【0029】
なお、本出願において、ＵＥとしては移動局、携帯端末又は携帯機器、ユーザ通信無線端末が挙げられるが、これらに限定されない。例えばＵＥは、携帯無線機器であってもよく、携帯電話、タブレット、ウェアラブルデバイス、センサ、車両、又は無線通信能力を有する携帯情報端末（ＰＤＡ）を含むが、これらに限定されない。上記ＵＥは、無線アクセスネットワークにおける１つ又は複数のセルに、エアーインターフェース上で、信号を送受信するよう構成されている。
【0030】
ＢＳは、ＵＭＴＳにおけるノードＢ（ＮＢ：ｎｏｄｅ Ｂ）、ＬＴＥ又はＬＴＥ－Ａにおける進化型ノードＢ（ｅＮＢ：evolved node B）、ＵＭＴＳにおける無線ネットワークコントローラ（ＲＮＣ：Radio Network Controller）、ＧＳＭ／ＧＥＲＡＮにおける基地局コントローラ（ＢＳＣ：Base Station Controller）、５ＧＣに関連するＥ－ＵＴＲＡ（Ｅ－ＵＴＲＡ：Evolved Universal Terrestrial Radio Access）ＢＳにおけるｎｇ－ｅＮＢ、５Ｇ－ＲＡＮにおける次世代ノードＢ（ｇＮＢ：generation Node B）、及びセル内の無線通信を制御し、無線リソースを管理することができる任意の他の装置を含むことができるが、これらに限定されない。基地局は、ネットワークへの無線インターフェースによって、１つ又は複数のＵＥにサービスを提供するように接続し得る。
【0031】
ＢＳは、以下の無線アクセス技術（ＲＡＴｓ：Radio Access Technologies）の内の少なくとも１つに従った通信サービスを提供するように構成されてよい。マイクロ波アクセスのためのワールドワイド相互運用（ＷｉＭＡＸ：Worldwide Interoperability for Microwave Access）、モバイル通信のためのグローバルシステム（ＧＳＭ：Global System for Mobile、しばしば２Ｇとして呼ばれる）、ＧＳＭ ＥＤＧＥ無線アクセスネットワーク（ＧＥＲＡＮ：GSM EDGE Radio Access Network）、汎用パケット無線サービス（ＧＲＰＳ：General Packet Radio Service）、基本広帯域コード分割多元アクセス（Ｗ－ＣＤＭＡ：Wideband-Code Division Multiple Access）に基づいたユニバーサルモバイル通信システム（ＵＭＴＳ：Universal Mobile Telecommunication System、しばしば３Ｇとして呼ばれる）、高速パケットアクセス（ＨＳＰＡ：High-Speed Packet Access）、ＬＴＥ、ＬＴＥ－Ａ、ｅＬＴＥ（進化型ＬＴＥ、例えば５ＧＣに接続したＬＴＥ）、ＮＲ（しばしば５Ｇとして呼ばれる）、及び／又はＬＴＥ－Ａ Ｐｒｏ。しかしながら本出願の範囲は、上記のプロトコルに限定されるべきではない。
【0032】
ＢＳは、ＲＡＮに含まれる複数のセルを使用して、特定の地理的エリアに無線カバレッジを提供するように動作可能であってもよい。ＢＳは、セルのオペレーションをサポートする。各セルは、その無線カバレッジ内の少なくとも１つのＵＥにサービスを提供するように動作可能でありうる。より具体的には、各セル（しばしばサービングセルと称される）は、その無線カバレッジ内の１つ又は複数のＵＥにサービスを提供しうる。例えば、各セルは、下りリンクおよび随意的な上りリンク（ＵＬ：uplink）リソースを、下りリンクおよび随意的なＵＬパケット送信のために、その無線カバレッジ内の少なくとも１つのＵＥにスケジュールする。ＢＳは、複数のセルを介して無線通信システム内の１つ又は複数のＵＥと通信しうる。セルは、近接サービス（ＰｒｏＳｅ：Proximity Service）をサポートするために、ＳＬリソースを割り当てることができる。各セルは、他のセルとオーバーラップしたカバレッジエリアを有しうる。ＭＲ－ＤＣの場合、ＭＣＧの、又はＳＣＧのプライマリセルは、スペシャルセル（ＳｐＣｅｌｌ：Special Cell）と呼ばれることがある。ＰＣｅｌｌは、ＭＣＧのＳｐＣｅｌｌを指してよい。ＰＳＣｅｌｌは、ＳＣＧのＳｐＣｅｌｌを指してもよい。ＭＣＧは、ＳｐＣｅｌｌと、任意で１つ又は複数のセカンダリセル（ＳＣｅｌｌｓ：Secondary Cells）を含み、ＭＮに関連付けられたサービングセルのグループを含んでよい。ＳＣＧは、ＳｐＣｅｌｌ及び任意で１つ又は複数のＳＣｅｌｌｓを含んでいる、ＳＮと関連付けられたサービングセルのグループを意味する。
【0033】
上述したように、ＮＲのためのフレーム構造は、高信頼性、高データ速度、及び低遅延性の要件を満たしながら、拡張モバイルブロードバンド（ｅＭＢＢ：Enhanced Mobile Broadband）、大容量マシンタイプ通信（ｍＭＴＣ：Massive Machine Type Communication）、超高信頼性及び低遅延性通信（ＵＲＬＬＣ：Ultra-Reliable and Low-Latency Communication）といった様々な次世代（例えば５Ｇ）通信要件に対応するための柔軟な構成をサポートすることである。３ＧＰＰにおいて合意された直交周波数分割多重（ＯＦＤＭ：Orthogonal Frequency-Division Multiplexing）技術は、ＮＲ波形のための基準として提供してよい。適応サブキャリア間隔、チャネル帯域幅、及びサイクリックプレフィックス（ＣＰ：Cyclic Prefix）といったスケーラブルなＯＦＤＭニューメロロジーは、使用されてもよい。更に、ＮＲには（１）低密度パリティ検査（ＬＤＰＣ：Low-Density Parity-Check）符号及び（２）ポーラ符号の２つの符号化方法が判断される。符号化スキームの適用は、チャネル条件及び／又はサービスアプリケーションに基づいて構成されてもよい。
【0034】
更に、単一のＮＲフレームの送信時間間隔において、下りリンク（ＤＬ：downlink）送信データ、ガード期間、及び上りリンク（ＵＬ：Uplink）送信データは、少なくとも含まれるべきであり、ＤＬ送信データ、ガード期間、及びガード期間のそれぞれの部分において、ＵＬ送信データはまた、例えばＮＲのネットワークダイナミクスに基づいて設定可能であるべきであることも判断される。更に、サイドリンクリソースは、ＰｒｏＳｅサービスをサポートするために、ＮＲフレーム内に提供されてもよい。
【0035】
３ＧＰＰリリース１６（Ｒｅｌ－１６）ＮＲ無線通信システムにおいて、ＵＥは、時間領域においてＰＤＣＣＨを周期的に、不連続的に、又は連続的に監視し、ＰＤＣＣＨを介してｇＮＢによってスケジューリングされる可能な動的ＵＬグラント（スケジューリング）を発見するように設定され得る。例えば、ＵＬグラントは、ＵＥ固有の無線ネットワーク一時識別子（ＲＮＴＩ：Radio Network Temporary Identifier）（例えばＣｅｌｌ－ＲＮＴＩ（Ｃ－ＲＮＴＩ））によってスクランブルされた巡回冗長検査（ＣＲＣ）ビットを持つ（ＵＥ固有の）ＤＣＩ上で受信できる。ＤＣＩは、ブラインド復号化を介してＰＤＣＣＨ上でＵＥによって発見され得る。ＤＣＩは、物理上りリンク共有チャネル（ＰＵＳＣＨ：Physical Uplink Shared Channel）のＵＬグラントを示すことができる。例えば、ＤＣＩは、ＰＵＳＣＨの時間及び周波数位置を示すことができる。ＵＬグラントが取得されると、ＵＥは、ＵＬグラントを利用することによって、ＰＵＳＣＨ上で対応するＵＬデータ送信（又は「ＰＵＳＣＨ送信」）を実行することができる。例えば、ＰＵＳＣＨ送信は、ＵＥにおいてトランスポートブロック（ＴＢ：Tansport Block）を送信することを含むことができる。用語「ＰＵＳＣＨ送信／繰り返し」及び用語「ＴＢ送信／繰り返し」は、本発明のいくつかの実装形態において交換可能であることに留意されたい。
【0036】
いくつかの実装形態において、ＰＵＳＣＨ送信は、ＤＣＩ中のＵＬグラントを介してＢＳ（例えば、ｇＮＢ）によって動的にスケジュールされ得るか、又はタイプ１又はタイプ２の設定されたグラントによってスケジュールされ得る。
【0037】
図１は、本開示の一実装形態による、ＰＤＣＣＨによってスケジュールされたＰＵＳＣＨ送信を示す図である。なお、各サブフレーム（例えば、サブフレームｎ及びサブフレームｎ＋１）は図１に示されている例としての実装形態において、２つのスロット（例えばスロット０及びスロット１）を含むが、各サブフレームは、本開示の他の実装形態において、任意の数のスロットを含んでもよい。例えば、各サブフレーム内のスロット数は、数学の設定に基づいて決定されてもよい。その上、各スロットには、一定数の記号が含まれていてもよい。
【0038】
図１に示すように、ＰＤＣＣＨ１０２によってスケジュールされたＰＵＳＣＨ１０４の時間位置及び継続時間を決定するために、３つのパラメータＫ２、Ｓ及びＬを使用することができる。例えばパラメータＫ２は、ＰＵＳＣＨリソース割当てを示すＤＣＩを搬送するＰＤＣＣＨ（例えばＰＤＣＣＨ１０２）を含んでいるスロット（例えばスロット０）と、ＤＣＩ（例えばＰＵＳＣＨ１０４）によって割当てられたＰＵＳＣＨリソースを含んでいるスロット（例えばスロット１）との間のスロットオフセットを決定するために使用されてもよい。パラメータＳは、Ｋ２によって示されるスロット（例えばスロット１）内のスケジュールされたＰＵＳＣＨ（例えばＰＵＳＣＨ１０４）の開始記号のインデックスであってもよい。パラメータＬは、示されたスロット（例えばスロット１）内のスケジュールされたＰＵＳＣＨ（例えばＰＵＳＣＨ１０４）の連続する記号の数であり得る。
【0039】
いくつかの実装形態において、ＢＳからの各動的グラントのためのＫ２、Ｓ、及びＬの値は、ＤＣＩに含まれる帯域幅部（ＢＷＰ：Bandwidth Part）及び／又はインデックス（例えば時間領域リソース割当て）のニューメロロジーのための設定に基づいて、ＵＥによって導出されてもよい。
【0040】
図２は、本開示の別の実装形態による、ＰＤＣＣＨによってスケジュールされたＰＵＳＣＨを示す図である。図２に示すように、各サブフレーム内に２つのスロット（例えばスロット０、スロット１）があり、各スロットは、１４のシンボル（例えばシンボル０からシンボル１３）を含む。図２に示す例としての実装形態において、パラメータＫ２、Ｓ及びＬはそれぞれ「１」、「３」及び「５」として設定される。したがって、ＰＵＳＣＨ上でＢＳによってスケジュールされたＵＬリソースは、スロット１のシンボル３から開始し、スロット１のシンボル７で終了することができる。
【0041】
ＮＲ無線通信システムにおいて、データ伝送の信頼性を高めるために、ＰＵＳＣＨの繰り返しスキームを使用することができる。ＰＵＳＣＨの繰り返しスキームは、ＵＥがＰＵＳＣＨ送信を繰り返し的に実行することを含むことができ、ここで、ＵＥがＰＵＳＣＨ送信を実行する数は、ＰＵＳＣＨの繰り返しの数と呼ばれることができる。フレーズ「ＰＵＳＣＨの繰り返しの数」、「公称のＰＵＳＣＨの繰り返しの数」、「繰り返しの数」、「公称の繰り返しの数」、「ＰＵＳＣＨ繰り返し送信の数」、「ＰＵＳＣＨ送信の公称の繰り返しの数」、及び「ＰＵＳＣＨ送信の数」は、本開示のいくつかの実装形態において交換可能であり得ることに留意されたい。
【0042】
いくつかの実装形態において、ＵＲＬＬＣの要件を満たすために、ＰＵＳＣＨの繰り返しスキームは、いくつかの連続するスロット内でＵＥによって繰り返し的にＰＵＳＣＨ送信を実行するように実装され得、各スロットにおける繰り返しされたＰＵＳＣＨ送信（又は「ＰＵＳＣＨの繰り返し」）の各々は、（例えば、Ｓ及びＬの同じ値に対応する）同じシンボル割り振りを有することができる。この種のＰＵＳＣＨの繰り返しスキームは、スロットベースの繰り返しスキームと呼ばれてもよい。
【0043】
いくつかの実装形態において、改善されたＰＵＳＣＨの繰り返しスキームは、提供される。スロットベースの繰り返しスキームと比較して、改善されたＰＵＳＣＨの繰り返しスキームは、各２つの隣接するＰＵＳＣＨの繰り返しの間の時間間隔を低減することができ、ＰＵＳＣＨの繰り返しの間の送信遅延拡散に必要とされる全体的な送信時間を低減する。例えば、拡張されたＰＵＳＣＨの繰り返しスキームは、スロット内で１つ又は複数の繰り返しされたＰＵＳＣＨ送信（又は「ＰＵＳＣＨの繰り返し」）を実行することを可能にする。その上、ＰＵＳＣＨの繰り返しの数は、各動的スケジューリングの動的変更をサポートすることが期待され得る。改善されたＰＵＳＣＨの繰り返しスキームは、非スロットベースの繰り返しスキームと呼ばれてもよい。
【0044】
いくつかの実装形態において、ＢＳがＰＵＳＣＨ送信を実行するためにＵＥをスケジュールするとき、ＢＳは、スロットベースの繰り返しスキーム又は非スロットベースの繰り返しスキームを用いて、ＰＵＳＣＨ送信を実行するようにＵＥに動的に命令することができる。
【0045】
いくつかの実装形態において、非スロットベースの繰り返しスキームは、以下にリストされた動作（例えば動作（ａ）から（ｆ））を含むことができる。しかしながら、リストされた動作は、例示の目的のためだけに示されており、本開示の範囲を限定することを意味しないことに留意されたい。例えば、以下にリストされる動作の内の１つ又は複数は、本開示のいくつかの実装形態において、非スロットベースの繰り返しスキームに含まれないことがある。
【0046】
動作（ａ）～（ｆ）は、以下を含むことができる：
（ａ）ＢＳ（例えばｇＮＢ）は、ＰＵＳＣＨ送信をスケジュールするＰＤＣＣＨを含むスロットと、スケジュールされたＰＵＳＣＨ送信を含むスロット（Ｋ２）との間のスロットオフセットをＵＥに示すことができる；
（ｂ）ＢＳは、ＰＵＳＣＨ送信（Ｓ）の開始シンボルをＵＥに示すことができる；
（ｃ）ＢＳは、現在のＰＵＳＣＨ送信（Ｌ）の長さをＵＥに示すことができ、ＰＵＳＣＨ送信の長さは、シンボルの数によって表すことができる；
（ｄ）ＢＳは、（例えば、このＰＵＳＣＨ送信がＵＥによって、どのくらい繰り返されるべき）現在のＰＵＳＣＨ送信のための（公称の）繰り返しの数をＵＥに示すことができる；
（ｅ）ＵＥは、ＢＳによってスケジュールされた現在のＰＵＳＣＨ送信（又は第１のＰＵＳＣＨの繰り返し）の終了直後に、第１の来るべきＵＬシンボルから繰り返しされたＰＵＳＣＨ送信（又は第２のＰＵＳＣＨの繰り返し）の実行を開始することができる；及び
（ｆ）各ＰＵＳＣＨの繰り返しは、以前のＰＵＳＣＨの繰り返しの終了後の第１の来るべきＵＬシンボルから開始することができる。
（ａ）ＢＳ（例えばｇＮＢ）は、ＰＵＳＣＨ送信をスケジュールするＰＤＣＣＨを含むスロットと、スケジュールされたＰＵＳＣＨ送信を含むスロット（Ｋ２）との間のスロットオフセットをＵＥに示すことができる；
（ｂ）ＢＳは、ＰＵＳＣＨ送信（Ｓ）の開始シンボルをＵＥに示すことができる；
（ｃ）ＢＳは、現在のＰＵＳＣＨ送信（Ｌ）の長さをＵＥに示すことができ、ＰＵＳＣＨ送信の長さは、シンボルの数によって表すことができる；
（ｄ）ＢＳは、（例えば、このＰＵＳＣＨ送信がＵＥによって、どのくらい繰り返されるべき）現在のＰＵＳＣＨ送信のための（公称の）繰り返しの数をＵＥに示すことができる；
（ｅ）ＵＥは、ＢＳによってスケジュールされた現在のＰＵＳＣＨ送信（又は第１のＰＵＳＣＨの繰り返し）の終了直後に、第１の来るべきＵＬシンボルから繰り返しされたＰＵＳＣＨ送信（又は第２のＰＵＳＣＨの繰り返し）の実行を開始することができる；及び
（ｆ）各ＰＵＳＣＨの繰り返しは、以前のＰＵＳＣＨの繰り返しの終了後の第１の来るべきＵＬシンボルから開始することができる。
【0047】
一般に、各ＰＵＳＣＨの繰り返しは、Ｌ個の連続するシンボルを占有することができる。しかしながら、ＰＵＳＣＨの繰り返し（又はＰＵＳＣＨ送信）に対応するＬ個の連続するシンボルオケーションがＤＬシンボル又はスロット境界をクロスした場合、ＰＵＳＣＨの繰り返しは、物理（ＰＨＹ：Physical）層の観点から、２つ以上の実際のＰＵＳＣＨ送信に分割され得る。
【0048】
図３は、本開示の一実装形態による、非スロットベースの繰り返しスキームが適用されるとき、ＤＬシンボル又はスロット境界をクロスするＰＵＳＣＨ送信（又は「ＰＵＳＣＨの繰り返し」）の繰り返しを示す図である。図３を参照して示された非スロットベースの繰り返しスキームは、例示の目的のためだけのものであり、本開示の範囲を限定することを意図しないことに留意されたい。
【0049】
図３に示すように、各スロット（例えばスロット０及びスロット１）は、１４個のシンボル（例えばシンボル０～シンボル１３）を含んでもよい。文字「Ｕ」で示される各シンボルは、ＵＬシンボルであり、文字「Ｄ」で示される各シンボルは、ＤＬシンボルである。図３に示す実装形態において、ＢＳ（例えばｇＮＢ）によって設定されるＳ、Ｌ、及びＰＵＳＣＨの繰り返しの数の値は、それぞれ３、４、及び３である。
【0050】
ＢＳ（例えばｇＮＢ）によってＵＥに設定／シグナリングされるＰＵＳＣＨの繰り返しの数は、公称の繰り返しの数と呼ばれ得、公称の繰り返しの数は、ＰＨＹレイヤの観点からＵＥによって実行される実際のＰＵＳＣＨ送信の数とは異なり得ることに留意されたい。図３に示すように、Ｓ及びＬの値がそれぞれ３及び４であるため、ＵＥは、ＰＵＳＣＨ送信３０２上でＢＳによってスケジュールされたＵＬリソースがスロット０内のシンボル３からシンボル６にかかることができることを知ることができる。その上、公称の繰り返しの数が実装形態において３であるため、ＵＥは、来るべきＵＬシンボルにおいて、ＰＵＳＣＨ送信３０２（第１の（公称の）ＰＵＳＣＨの繰り返し）を２回以上繰り返しする必要があり得る。上述したように、Ｌの値は、４であり、したがって、各公称の繰り返しは、４つのＵＬシンボルを含むことができる。しかしながら、スロット０のシンボル９がＤＬシンボルであるため、第２の（公称の）ＰＵＳＣＨの繰り返しは、第２の実際のＰＵＳＣＨの繰り返し送信（又は「実際のＰＵＳＣＨの繰り返し」）に分割され得る。図３に示すように、実際のＰＵＳＣＨの繰り返し３０４は、スロット０のシンボル７からシンボル８にかかることができ、実際のＰＵＳＣＨの繰り返し３０６は、スロット０のシンボル１０からシンボル１１にかかることができる。２つの実際のＰＵＳＣＨの繰り返し３０４及び３０６は、合計で４つのシンボルを占有することができ、したがって、それらは、第２の（公称の）ＰＵＳＣＨの繰り返しに等しくてよい。同様に、第３の（公称の）ＰＵＳＣＨの繰り返しは、スロット０とスロット１との間のスロット境界をカバーするため、第３の（公称の）ＰＵＳＣＨの繰り返しを２つの実際のＰＵＳＣＨの繰り返し３０８及び３１０に分割することができ、実際のＰＵＳＣＨの繰り返し３０８は、スロット０のシンボル１２からシンボル１３にかかることができ、実際のＰＵＳＣＨの繰り返し３１０は、スロット１のシンボル０からシンボル１にかかることができる。したがって、図３に示す実装形態において、実際のＰＵＳＣＨの繰り返しの数（例えば５）は、公称のＰＵＳＣＨの繰り返しの数（例えば３）よりも大きくてもよい。
【0051】
いくつかの実装形態において、Ｌの値は、ＰＵＳＣＨ送信のために割振られたＵＬシンボルの総数を表すことができる。したがって、１つのＰＵＳＣＨ／ＴＢ繰り返しに必要なＵＬシンボルの総数は、Ｌの値に制限され得る。
【0052】
図４は、本開示の実装形態による、非スロットベースの繰り返しスキームが適用されるとき、ＤＬシンボルをクロスするＰＵＳＣＨ繰り返し送信を示す図である。図４に示す実装形態において、ＤＣＩは、ＰＵＳＣＨ送信のために、Ｓの値が３であり、Ｌの値が４であり、公称の繰り返しの数が２であることを示すフィールド／インデックスを含むことができる。この場合において、ＰＵＳＣＨ上のＢＳ（例えば、ｇＮＢ）によってスケジューリングされるＵＬリソースは、スロット０のシンボル３から始まることができる。その上、Ｌの値が４として設定され、スロット０のシンボル５がＤＬシンボルであるため、ＵＥは、ＰＵＳＣＨの初期送信を、２つの実際のＰＵＳＣＨ送信、すなわち、スロット０のシンボル３からシンボル４にかかる第１の実際のＰＵＳＣＨ送信４０２と、スロット０のシンボル６からシンボル７にかかる第２の実際のＰＵＳＣＨ送信４０４とに分割する必要があり得る。したがって、ＰＵＳＣＨの最初の送信（又は「第１の公称の繰り返し」）のためのＵＬシンボルの総占有は、依然として４である。
【0053】
いくつかの実装形態において、ＵＥは、繰り返しリストを用いて設定されてもよく、ＤＣＩに含まれるフィールド／インデックスは、繰り返しリストの行／エントリインデックスであってもよい（例えばＴＤＲＡインデックス）。いくつかの実装形態において、繰り返しリストは、時間領域リソース割振り（ＴＤＲＡ：Time Domain Resource Allocation）表に含まれてよい。繰り返しリストの一例を表１に示す。
【0054】
【表1】
【0055】
表１に示すように、繰り返しリストは、複数のエントリ（又は行）を含んでよい。繰り返しリスト内の各エントリは、行インデックスによってインデックス付けされ、パラメータＫ２、Ｓ、Ｌ及びＲといった、ＰＵＳＣＨ送信を設定するためのパラメータのセットを含むことができ、ここで、繰り返しリスト内のパラメータＲの各値は、ＰＵＳＣＨの繰り返しの特定の数を表すことができ、パラメータＫ２、Ｓ及びＬの定義は、図１及び図２を参照して説明される。
【0056】
いくつかの実装形態において、ＢＳは、固有のシグナリング（例えば、ＤＣＩ）を介して使用するために、繰り返しリスト内のエントリをＵＥに示すことができる。ＵＥは、繰り返しリストの示されたエントリ内の値に基づいて、ＰＵＳＣＨ送信のためのリソースロケーション及び／又はＰＵＳＣＨの繰り返しの数を決定することができる。例えば、表１によれば、ＢＳが「０」の行インデックスを含んでいるＤＣＩをＵＥに送信した場合、ＵＥは、ＤＣＩによってスケジュールされたＰＵＳＣＨ送信を実行するとき、繰り返しリストの最初のエントリ／行が適用されるべきであることを知ることができる。表１に示すように、繰り返しリストの最初のエントリ／行のＫ２、Ｓ、Ｌ、及びＲの値は、それぞれ「１」、「３」、「４」、及び「２」である。このような場合において、図４に示すように、ＤＣＩに対応するＰＵＳＣＨ送信のためのＰＵＳＣＨの繰り返しの数は、２である。
【0057】
表１における実装形態は、例示の目的のためだけに示されており、本開示の範囲を限定することを意味しないことに留意されたい。例えば、繰り返しリストは、パラメータＲ及び／又は他のパラメータ／インデックスの任意の組合せを含むことができる。別の例において、繰り返しリストは、パラメータＲの値（又は「Ｒ値」）のみを含むことができる。
【0058】
いくつかの実装形態において、（例えば１つ又は複数のＲ値を含んでいる）繰り返しリスト及びＴＤＲＡ表は、別々の表であってもよく、ここで、繰り返し表内の各Ｒ値は、ＴＤＲＡ表に含まれるパラメータのセット（例えばＳ、Ｌ、及び／又はＫ２）と関連付けられてもよい。例えば、繰り返しリストは、いくつかのＲ値、例えば「２」、「３」及び「４」を含むことができ、Ｒ値「２」がＴＤＲＡ表の第１の行／エントリに含まれるパラメータＫ２、Ｓ及びＬ（例えばそれぞれ「１」、「３」及び「４」）のセットに関連付けられ、Ｒ値「３」がＴＤＲＡ表の第２の行／エントリに含まれるパラメータＫ２、Ｓ及びＬ（例えばそれぞれ「１」、「４」及び「６」）のセットに関連付けられ、Ｒ値「４」がＴＤＲＡ表の第３の行／エントリに含まれるパラメータＫ２、Ｓ及びＬ（例えばそれぞれ「２」、「２」及び「４」）のセットに関連付けられてもよい。このケースにおいて、ＴＤＲＡ表は、Ｒ値を含まなくてもよい。その上、ＵＥがＴＤＲＡ表の行／エントリを示すＴＤＲＡフィールドを含むＤＣＩを受信した場合、ＴＤＲＡ表の示された行／エントリに含まれるパラメータのセット、並びにＴＤＲＡ表の示された行／エントリに関連する（繰り返しリスト内の）Ｒ値は、ＰＵＳＣＨの繰り返しスキームのためのＵＥによって適用され得る。例えば、ＴＤＲＡ表の第１の行／エントリがＤＣＩのＴＤＲＡフィールドによって示される場合、ＰＵＳＣＨ送信のためにＰＵＳＣＨの繰り返しスキームを適用するとき、ＵＥは、Ｋ２、Ｓ、Ｌ及びＲの値がそれぞれ”１”、”３”、”４”及び”２”であると決定してもよい。
【0059】
〔状況Ａ：非スロットベースの繰り返しスキーム下での間欠受信（ＤＲＸ）動作〕
いくつかの実装形態において、ＭＡＣエンティティの特定の無線ネットワーク一時識別子（ＲＮＴＩ：Radio Network Temporary Identifier）に対応するＰＤＣＣＨ監視活動を制御するＤＲＸ手順を実行するために、ＵＥの媒体アクセス制御（ＭＡＣ：Medium Access Control）エンティティは、ｇＮＢによって（例えばＲＲＣ層を介して）設定されてよい。特定のＲＮＴＩは、Ｃｅｌｌ－ＲＮＴＩ（Ｃ－ＲＮＴＩ）、設定されたスケジューリングＲＮＴＩ（ＣＳ－ＲＮＴＩ）、割り込みＲＮＴＩ（ＩＮＴ－ＲＮＴＩ）、スロットフォーマットインディケーションＲＮＴＩ（ＳＦＩ－ＲＮＴＩ）、半持続チャネル状態情報ＲＮＴＩ（ＳＰ－ＣＳＩ－ＲＮＴＩ）、送信電力ＰＵＣＣＨ－ＲＮＴＩ（ＴＰＣ－ＰＵＣＣＨ－ＲＮＴＩ）、ＴＰＣ－ＰＵＳＣＨ－ＲＮＴＩ、又は送信電力サウンディング参照信号ＲＮＴＩ（ＴＰＣ－ＳＲＳ－ＲＮＴＩ）であってもよい。ＵＥがＲＲＣ接続状態（ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ）にあるとき、ＵＥがＤＲＸ関数を用いて設定されている場合、ＵＥのＭＡＣエンティティは、ＤＲＸ手順の間に時間領域内で間欠的にＰＤＣＣＨを監視することがある。例えば、ＭＡＣエンティティは、データ伝送が発生しない場合であっても、ＢＳからの設定及び実際のトラフィックパターンに従って、制御チャネルを周期的に監視することができる。換言すると、データ通信が発生しなくても、ＵＥは、事前に設定された時間内（例えばアクティブ時間）にＰＤＣＣＨを監視することができる。しかしながら、データ送信がアクティブ時間の間に発生した場合、ＵＥは、データ送信を完了するためにアクティブ状態のままでよい。アクティブ時間の間、ＵＥは、可能なデータ送信／受信インディケーションのためにＰＤＣＣＨを監視することができる。ＤＲＸ手順の間、ＵＥは、ＵＥのＭＡＣ層にいくつかのタイマを維持することによって、ＰＤＣＣＨ監視動作を処理することができる。タイマは、例えば、オン持続時間タイマ、ＤＲＸ非アクティビティタイマ、ＵＬ再送タイマ、ＤＬ再送タイマ、ＵＬ往復時間（ＲＴＴ：Round Trip Time）タイマ、及びＤＬ ＲＴＴタイマを含むことができる。
いくつかの実装形態において、ＭＡＣエンティティの特定の無線ネットワーク一時識別子（ＲＮＴＩ：Radio Network Temporary Identifier）に対応するＰＤＣＣＨ監視活動を制御するＤＲＸ手順を実行するために、ＵＥの媒体アクセス制御（ＭＡＣ：Medium Access Control）エンティティは、ｇＮＢによって（例えばＲＲＣ層を介して）設定されてよい。特定のＲＮＴＩは、Ｃｅｌｌ－ＲＮＴＩ（Ｃ－ＲＮＴＩ）、設定されたスケジューリングＲＮＴＩ（ＣＳ－ＲＮＴＩ）、割り込みＲＮＴＩ（ＩＮＴ－ＲＮＴＩ）、スロットフォーマットインディケーションＲＮＴＩ（ＳＦＩ－ＲＮＴＩ）、半持続チャネル状態情報ＲＮＴＩ（ＳＰ－ＣＳＩ－ＲＮＴＩ）、送信電力ＰＵＣＣＨ－ＲＮＴＩ（ＴＰＣ－ＰＵＣＣＨ－ＲＮＴＩ）、ＴＰＣ－ＰＵＳＣＨ－ＲＮＴＩ、又は送信電力サウンディング参照信号ＲＮＴＩ（ＴＰＣ－ＳＲＳ－ＲＮＴＩ）であってもよい。ＵＥがＲＲＣ接続状態（ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ）にあるとき、ＵＥがＤＲＸ関数を用いて設定されている場合、ＵＥのＭＡＣエンティティは、ＤＲＸ手順の間に時間領域内で間欠的にＰＤＣＣＨを監視することがある。例えば、ＭＡＣエンティティは、データ伝送が発生しない場合であっても、ＢＳからの設定及び実際のトラフィックパターンに従って、制御チャネルを周期的に監視することができる。換言すると、データ通信が発生しなくても、ＵＥは、事前に設定された時間内（例えばアクティブ時間）にＰＤＣＣＨを監視することができる。しかしながら、データ送信がアクティブ時間の間に発生した場合、ＵＥは、データ送信を完了するためにアクティブ状態のままでよい。アクティブ時間の間、ＵＥは、可能なデータ送信／受信インディケーションのためにＰＤＣＣＨを監視することができる。ＤＲＸ手順の間、ＵＥは、ＵＥのＭＡＣ層にいくつかのタイマを維持することによって、ＰＤＣＣＨ監視動作を処理することができる。タイマは、例えば、オン持続時間タイマ、ＤＲＸ非アクティビティタイマ、ＵＬ再送タイマ、ＤＬ再送タイマ、ＵＬ往復時間（ＲＴＴ：Round Trip Time）タイマ、及びＤＬ ＲＴＴタイマを含むことができる。
【0060】
いくつかの実装形態において、オン持続時間タイマ、ＤＲＸ非アクティビティタイマ、ＵＬ再送タイマ、ＤＬ再送タイマ、ＵＬ ＲＴＴタイマ、及びＤＬ ＲＴＴタイマの長さはそれぞれ、パラメータｄｒｘ－ｏｎＤｕｒａｔｉｏｎＴｉｍｅｒ、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒ、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＵＬ、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＤＬ、ｄｒｘ－ＨＡＲＱ－ＲＴＴ－ＴｉｍｅｒＵＬ、及びｄｒｘ－ＨＡＲＱ－ＲＴＴ－ＴｉｍｅｒＤＬを介して、ＢＳ（例えばｇＮＢ）によって事前設定され得る。
【0061】
いくつかの実装形態において、ｄｒｘ－ｏｎＤｕｒａｔｉｏｎＴｉｍｅｒ、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒ、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＵＬ、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＤＬ、ｄｒｘ－ＨＡＲＱ－ＲＴＴ－ＴｉｍｅｒＵＬ、及びｄｒｘ－ＨＡＲＱ－ＲＴＴ－ＴｉｍｅｒＤＬといったパラメータは、ＵＥ固有のＤＬ ＲＲＣメッセージを介してＢＳによって設定され得る。
【0062】
ＵＥがアクティブタイムにあり、監視されるＰＤＣＣＨがＵＬ送信を示すとき、ＵＬ ＲＴＴタイマは、対応するハイブリッド自動再送要求（ＨＡＲＱ：Hybrid Automatic Repeat Request）処理のために開始され得る。ＵＬ ＲＴＴタイマは、ＵＬ ＨＡＲＱプロセスベース毎のＭＡＣエンティティによって維持され得る。ＵＬ ＲＴＴタイマは、ＭＡＣエンティティによって予想されるＵＬ ＨＡＲＱ再送信グラントの前の最小持続時間を計算するために使用され得る。ＵＬ ＲＴＴタイマの長さは、ｇＮＢ処理時間／容量に関連し得る。しかしながら、現行の通信システムにおいて、ＵＥ（例えばＵＥのＭＡＣエンティティ）が対応するＰＵＳＣＨ送信のための非スロットベースの繰り返しスキーマ下でＵＬ ＲＴＴタイマをどのように処理するかは依然として未定義である（例えばＵＬ ＲＴＴタイマのスタートタイミングは未定義である）。その上、対応するＭＡＣ挙動は、依然として未定義のため、ＤＲＸ関数によってもたらされる省電力の利得は、ｇＮＢとＵＥとの間の不適切な同期のために失われ得る。
【0063】
上述したように、ＢＳは、ＤＣＩを介してＰＵＳＣＨ上のＵＬリソースをＵＥに示すことができる。例えば、ＤＣＩは、ＰＵＳＣＨ送信の時間位置及び持続時間を示すＴＤＲＡフィールド／インデックス（例えば表１に示されるように、ＴＤＲＡ表の行／エントリインデックス）を含むことができる。ＤＣＩを受信することに応答して、ＵＥは、ＵＬリソースを利用することによって、対応するＰＵＳＣＨ送信を実行することができる。ＵＥがＰＵＳＣＨの繰り返しスキームを実行するように設定される場合、ＴＤＲＡフィールド（例えば示されたシンボル及び／又はスロット）によって示されたＵＬリソースの時間領域は、ＰＵＳＣＨ送信の第１の公称の繰り返しのためのＵＬリソースとして使用され得る。以下のケース１、２、３において、ＰＵＳＣＨの繰り返しスキームによるＤＲＸの多様なＲＴＴタイマ動作は、提供される。
【0064】
〔ケース１〕
いくつかの実装形態において、Ｓ＋Ｌの値は、スロット内のシンボルの総数よりも大きくてよい。各スロットが１４個のシンボルを含むと仮定すると、ＵＲＬＬＣサービスに対する低い遅延の要件を達成するために、１４より大きいＳ＋Ｌの値を有するＵＬグラントは、適用され得る。
いくつかの実装形態において、Ｓ＋Ｌの値は、スロット内のシンボルの総数よりも大きくてよい。各スロットが１４個のシンボルを含むと仮定すると、ＵＲＬＬＣサービスに対する低い遅延の要件を達成するために、１４より大きいＳ＋Ｌの値を有するＵＬグラントは、適用され得る。
【0065】
図５は、本開示の一実装形態による、Ｓ＋Ｌが１スロット当たりのシンボル数（例えば１４シンボル）より大きいＵＬグラントに対応するＰＵＳＣＨ送信を示す図である。
【0066】
ＵＥは、ｇＮＢからＤＣＩを受信することができる。ＤＣＩは、ＰＵＳＣＨ送信のためのＵＬリソースを示すＴＤＲＡフィールドを含むことができる。いくつかの実装形態において、ＴＤＲＡフィールドは、ＴＤＲＡ表に含まれる行インデックスであってよい（例えば表１を参照）。いくつかの実装形態において、ＴＤＲＡフィールドは、ＴＤＲＡ表に含まれる行／エントリを示す行／エントリを示す行／エントリインデックスであってもよいが、（例えば、除去されている表１「行インデックス」の列の場合において）ＴＤＲＡ表に含まれなくてもよい。この条件において、ＴＤＲＡ表は、行インデックスを除いて、Ｓ、Ｌ、Ｋ２及び／又はＲといったパラメータを含むことができる。ＵＥは、ＴＤＲＡ表のどの行／エントリが事前に設定されたマッピングルールに従ってＤＣＩのＴＤＲＡフィールドによって示されるかを知ることができる。例えば、ＴＤＲＡフィールドの値が「１」のとき、ＵＥは、ＴＤＲＡ表の最初の行／エントリに含まれるパラメータ（例えば、Ｓ、Ｌ、Ｋ２及び／又はＲ）が選択されることを知ることができ、ＴＤＲＡフィールドの値が「２」の場合、ＵＥは、ＴＤＲＡ表の２番目の行／エントリに含まれるパラメータ（例えばＳ、Ｌ、Ｋ２及び／又はＲ）などが選択されることを知ることができる。図５に示す実装形態において、ＴＤＲＡフィールドによってアドレス指定されるＳ及びＬの値は、それぞれ１２及び４である。図５に示されるように、ＰＵＳＣＨ上でｇＮＢによってスケジュールされるＵＬリソースは、スロット０のシンボル１２から、４つの連続するＵＬシンボルを占有するスロット１のシンボル１にかかることができる。ＵＬグラントに対応するＰＵＳＣＨ送信（又は「第１の公称の繰り返し」）は、スロット０とスロット１との間のスロット境界をクロスすることに留意されたい。したがって、第１の公称の繰り返しは、２つの実際のＰＵＳＣＨ送信５０２及び５０４に分割され得る。その上、公称の繰り返しの数がインジケータを介してｇＮＢによって２として設定されるため、第２の公称のＰＵＳＣＨ送信５０６は、非スロットベースの繰り返しスキーム下で、スロット１のシンボル２からスロット１のシンボル５にかかることができる。
【0067】
ＵＥがＤＲＸ関数（例えばＵＥがＤＲＸ手順を実行している）を用いて設定されるとき、ＵＥがＵＬグラントを受信した場合、ＵＬ ＲＴＴタイマは、ＵＥのＭＡＣエンティティによって開始され得る。上述したように、ＵＬ ＲＴＴタイマの開始タイミングは、対応するＰＵＳＣＨ送信の「第１の繰り返し」の終了直後の第１のシンボル内にあってよい。ＵＬグラントの観点から、ＰＵＳＣＨ送信の第１の繰り返しは、第１の公称のＰＵＳＣＨ送信（例えば図５のスロット０のシンボル１２からスロット１のシンボル１へのＰＵＳＣＨ送信）であってよい。しかしながら、実際の送信の観点から、ＰＵＳＣＨ送信の第１の繰り返しは、第１の実際のＰＵＳＣＨ送信（例えば実際のＰＵＳＣＨ送信５０２）であってよい。したがって、ＵＬ ＲＴＴタイマの動作は、ＰＵＳＣＨ送信の「第１の繰り返し」の異なる定義のために影響を受けることがある。
【0068】
〔ＵＬグラントの観点から：〕対応するＰＵＳＣＨ送信の第１の繰り返しのためのＵＬリソースは、ｇＮＢによって動的にグラントされ得る。図５に示すように、ＴＤＲＡによって示されるＵＬリソース（Ｌの値は４である）は、スロット０のシンボル１２からスロット１のシンボル１まで開始することができる。ＵＬグラントの観点から、ＵＬ ＲＴＴタイマの開始タイミングは、対応するＰＵＳＣＨ送信の第１の繰り返しのために許可されたＵＬリソースの終了後の第１のシンボルにあってよい。すなわち、ＵＬグラントの観点から、ＵＬ ＲＴＴタイマは、（例えば図５に示されるＡｌｔ．ａ）スロット１のシンボル２で開始することができる。
【0069】
〔実際の送信の観点から：〕図５に示されるように、ＰＵＳＣＨ送信の第１の公称の繰り返しは、スロット０とスロット１との間のスロット境界に起因して、２つの実際のＰＵＳＣＨの繰り返しに分割される。第１の実際のＰＵＳＣＨの繰り返し５０２は、スロット０のシンボル１２からスロット０のシンボル１３にかかることができる。第２の実際のＰＵＳＣＨの繰り返し５０４は、スロット１のシンボル０からスロット１のシンボル１にかかることができる。実際のＰＵＳＣＨ送信の観点から、ＵＬ ＲＴＴタイマの開始タイミングは、第１の実際のＰＵＳＣＨの繰り返し終了直後の第１のシンボルにあってもよい。すなわち、ＵＬ ＲＴＴタイマは、（例えば図５に示されるＡｌｔ．ｂ）スロット１のシンボル０で開始することができる。
【0070】
対応するテキストプロポーザル（ＴＰ）の例を表２、３、４に示す。
【0071】
【表2】
【0072】
【表3】
【0073】
【表4】
【0074】
いくつかの実装形態において、動的ＵＬグラントに対応するＰＵＳＣＨ送信が少なくとも１つのＤＬシンボル及び／又はフレキシブルシンボルをクロスし得る。これは、ＵＬ ＲＴＴタイマの動作にも影響を及ぼすことがある。
【0075】
図４を参照すると、ＤＣＩは、ＰＵＳＣＨ送信のためのＵＬリソースを示すＴＤＲＡフィールドを含むことができ、ＴＤＲＡフィールドによってアドレス指定されるＳ及びＬの値は、それぞれ３及び４である。その上、ｇＮＢからのインジケータによって、公称の繰り返しの数は２として設定される。ＰＵＳＣＨ上でｇＮＢによってスケジュールされたＵＬリソースは、スロット０のシンボル３で開始し、次の３つのＵＬシンボルを占有する（すなわち、合計で４つのＵＬシンボルを占有する）ことができる。図４に示すように、ＵＬグラントに対応する第１の公称の繰り返しは、ＤＬシンボル（すなわち、スロット０のシンボル５）とクロスするため、第１の公称の繰り返しは、２つの実際のＰＵＳＣＨの繰り返しに分割される。その上、第２の公称のＰＵＳＣＨ送信４０６は、スロット０のシンボル８からスロット１のシンボル１１にかかることができる。
【0076】
上述したように、ＵＬ ＲＴＴタイマがＰＵＳＣＨ送信の「第１の繰り返し」の終了直後の第１のシンボルで開始されるように設定される場合、「第１の繰り返し」の定義がＵＬグラントの観点及び実際の送信の観点とは異なることがあるため、ＵＬ ＲＴＴタイマの開始タイミングは異なることがある。例えば、ＵＬグラントの観点から、ＰＵＳＣＨ送信の第１の繰り返しは、第１の公称のＰＵＳＣＨ送信であってよい。実際の送信の観点から、ＰＵＳＣＨ送信の第１の繰り返しは、第１の実際のＰＵＳＣＨ送信であってよい。対応するタイマ動作の詳細は、図４を参照して以下に説明される。
【0077】
〔ＵＬ許可の観点から：〕対応するＰＵＳＣＨ送信の第１の公称の繰り返しのためのＵＬリソースは、ｇＮＢによって動的にグラントされ得る。図４に示されるように、ＴＤＲＡによって示されるＵＬリソース（ここで、Ｌの値は４として示される）は、スロット０のシンボル３、４、６、及び７を含み得る。ＵＬグラントの観点から、ＵＬ ＲＴＴタイマの開始タイミングは、対応するＰＵＳＣＨ送信の第１の公称の繰り返しのために許可されたＵＬリソースの終了の直後の第１のシンボルにあってよい。図４に示すように、一実装形態において、ＵＬ ＲＴＴタイマがスロット０のシンボル８から開始することができる（例えば図４において「Ａｌｔ．ａ」と示されているタイミング）。
【0078】
〔実際の送信の観点から：〕図４に示されるように、ＰＵＳＣＨ送信の第１の公称の繰り返しは、スロット０とスロット１との間のスロットの境界に起因して、２つの実際のＰＵＳＣＨの繰り返しに分割される。第１の実際のＰＵＳＣＨの繰り返し４０２は、スロット０のシンボル３からスロット０のシンボル４にかかることができる。第２の実際のＰＵＳＣＨの繰り返し４０４は、スロット０のシンボル６からスロット０のシンボル７にかかることができる。実際の送信の観点から、ＵＬ ＲＴＴタイマの開始タイミングは、第１の実際のＰＵＳＣＨの繰り返し終了直後の第１のシンボルにあってよい。図４に示すように、一実装形態において、ＵＬ ＲＴＴタイマがスロット０のシンボル５から開始することができる（例えば図４では「Ａｌｔ．ｂ」と示されているタイミング）。
【0079】
図６は、本開示の実装形態による、非スロットベースの繰り返しスキームが適用されるとき、フレキシブルシンボルをクロスするＰＵＳＣＨ繰り返し送信を示す図である。図６に示されるように、ＤＣＩによって示されるＰＵＳＣＨ送信６０２の動的スケジューリングは、（図６において「Ｆ」として示される）フレキシブルシンボルをクロスすることができる。フレキシブルシンボルは、ｓｆｉ－ＲＮＴＩを介して（３ＧＰＰ Ｔｅｃｈｎｉｃａｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎ（ＴＳ）３８．２１３で定義されているように）ＤＬシンボル又はＵＬシンボルとして動的に設定できる。ＤＣＩは、ＰＵＳＣＨ送信のためのＵＬリソースを示すＴＤＲＡフィールドを含むことができ、ＴＤＲＡフィールドによってアドレス指定されるＳ及びＬの値は、それぞれ３及び４である。その上、ＢＳからのインジケータによって、公称の繰り返しの数は、２として設定される。フレキシブルシンボルがＵＬシンボルとして使用される場合、第１の公称のＰＵＳＣＨ送信６０２は、スロット０のシンボル３からスロット０のシンボル６に及ぶことができ、第２の公称のＰＵＳＣＨ６０４は、スロット０のシンボル７からスロット０のシンボル１０にかかることができる。このケースにおいて、ＵＬ＿ＲＴＴタイマは、第１の公称のＰＵＳＣＨ送信６０２の終わりの直後の第１のシンボル（例えばスロット０のシンボル７）で開始することができる。フレキシブルシンボルがＤＬシンボルとして使用される場合、ＵＬ ＲＴＴタイマの動作は、（ＵＬグラントの観点又は実際の送信の観点のいずれかから）図４を参照して説明される場合と同じであり得る。
【0080】
〔状況Ｂ：ＰＵＳＣＨ繰り返し送信の数の動的インディケーション方法〕
いくつかの実装形態において、非スロットベース繰り返しスキームの下で、ｇＮＢが動的スケジューリング毎の公称の繰り返しの数をＵＥに動的に示すことができる（又は動的スケジューリングに基づいた公称の繰り返しの数をｇＮＢがＵＥに示すようにする）動的インディケーション（ＤＩ：Dynamic Indication）機能が提供されてもよい。その上、ＤＩ機能を有効又は無効にするために使用される有効／無効ＤＩ（ＥＤＤＩ：Enable/Disable DI）メカニズムも提供されてもよい。
いくつかの実装形態において、非スロットベース繰り返しスキームの下で、ｇＮＢが動的スケジューリング毎の公称の繰り返しの数をＵＥに動的に示すことができる（又は動的スケジューリングに基づいた公称の繰り返しの数をｇＮＢがＵＥに示すようにする）動的インディケーション（ＤＩ：Dynamic Indication）機能が提供されてもよい。その上、ＤＩ機能を有効又は無効にするために使用される有効／無効ＤＩ（ＥＤＤＩ：Enable/Disable DI）メカニズムも提供されてもよい。
【0081】
図７は、本開示の実装形態による、動的インディケーションモードと非動的インディケーションモードとの間のＵＥスイッチングを示す図である。図７に示すように、ＵＥは、動的インディケーションモード７０２又は非動的インディケーションモード７０４で動作することができる。ＤＬ機能がｇＮＢによって有効にされるとき、ＵＥは、動的インディケーションモード７０２で動作することができ、ＢＳ（例えばｇＮＢ）は、動的スケジューリング信号（例えばＤＣＩ及び／又はＭＡＣ ＣＥ信号）を介して、ＰＵＳＣＨ送信のための公称の繰り返しの数をＵＥに示すことができる。対照的に、ＤＬ機能が無効にされるとき、ＵＥは、非動的インディケーションモード７０４で動作することができ、ＰＵＳＣＨ送信のための公称の繰り返しの数は、ＲＲＣ信号を介してＢＳによって事前に定義されるか、又は事前に設定されることができる。ＵＥが動的インディケーションモード７０２で動作すべきか、又は非動的インディケーションモード７０４で動作すべきかは、ＥＤＤＩメカニズムによって制御され得る。ＵＥが動的インディケーションモード７０２又は非動的インディケーションモード７０４で動作するときのＵＥ挙動の例は、以下のケースにおいて説明される。
【0082】
〔ケース１：〕
いくつかの実装形態において、ＵＥが動的インディケーションモードにあるとき、公称の繰り返しの数は、ｇＮＢからのインジケータによって決定されてよい。例えばインジケータは、ＰＵＳＣＨ送信に対応するＵＬグラントをスケジューリングするＤＣＩに含まれるＤＣＩフィールドであってよい。ＵＬグラントに対応するＰＵＳＣＨ送信が、非スロットベースの繰り返しスキーム下で実行されるように設定される場合、公称の繰り返しの数は、ｇＮＢから受信されたインジケータ（例えばＤＣＩフィールド）によって決定される。受信されたインジケータに基づいて公称の繰り返しの数をどのようにＵＥが決定するかに関する動作の例は、以下のサブケース１．１～１．１２で提供される。
いくつかの実装形態において、ＵＥが動的インディケーションモードにあるとき、公称の繰り返しの数は、ｇＮＢからのインジケータによって決定されてよい。例えばインジケータは、ＰＵＳＣＨ送信に対応するＵＬグラントをスケジューリングするＤＣＩに含まれるＤＣＩフィールドであってよい。ＵＬグラントに対応するＰＵＳＣＨ送信が、非スロットベースの繰り返しスキーム下で実行されるように設定される場合、公称の繰り返しの数は、ｇＮＢから受信されたインジケータ（例えばＤＣＩフィールド）によって決定される。受信されたインジケータに基づいて公称の繰り返しの数をどのようにＵＥが決定するかに関する動作の例は、以下のサブケース１．１～１．１２で提供される。
【0083】
〔サブケース１．１：〕いくつかの実装形態において、インジケータは、ＤＣＩによってスケジュールされたＵＬグラントに対応するＰＵＳＣＨ送信の公称の繰り返しの数を明示的、又は暗黙的に示す値を表すＤＣＩフィールドのビットストリーム（コンテンツ）であってよい。
【0084】
〔サブケース１．２：〕いくつかの実装形態において、インジケータは、マッピング表の行インデックスを明示的、又は暗黙的に示す値を表すＤＣＩフィールドのビットストリーム（コンテンツ）であってよい。マッピング表は、（例えば３ＧＰＰ ＴＳにおいて）事前に定義されている、又はＤＬ ＲＲＣメッセージを介してｇＮＢによって事前に設定されていてもよい。マッピング表は、行インデックスと、ＤＣＩによってスケジュールされたＰＵＳＣＨ送信のための公称の繰り返しの数との間の関連付け／マッピングを定義することができる。
【0085】
〔サブケース１．３：〕いくつかの実装形態において、インジケータは、繰り返しリスト（例えばｐｕｓｃｈ－ＡｇｇｒｅｇａｔｉｏｎＦａｃｔｏｒ－ｕｒｌｌｃＬｉｓｔ）の要素インデックスを明示的、又は暗黙的にＤＣＩフィールドのビットストリーム（コンテンツ）が示す値であってよい。ｐｕｓｃｈ－ＡｇｇｒｅｇａｔｉｏｎＦａｃｔｏｒ－ｕｒｌｌｃＬｉｓｔは、（例えば３ＧＰＰ ＴＳにおいて）事前に定義されている、又は下りリンク（ＤＬ）ＲＲＣメッセージを介してｇＮＢによって事前に設定されていてよい。ｐｕｓｃｈ－ＡｇｇｒｅｇａｔｉｏｎＦａｃｔｏｒ－ｕｒｌｌｃＬｉｓｔは、ＤＣＩによってスケジュールされたＰＵＳＣＨ送信のための公称の繰り返しの特定数をそれぞれ示す１つ又は複数の値（例えば表１に示されるＲ値）を含むことができる。要素インデックスの値は、繰り返しリスト中の（Ｒ）値の内のどれがＰＵＳＣＨ送信のためにＵＥによって適用されるべきかを示し得る。例えば、要素インデックスの値が０の場合、ｐｕｓｃｈ－ＡｇｇｒｅｇａｔｉｏｎＦａｃｔｏｒ－ｕｒｌｌｃＬｉｓｔの最初の要素／行／エントリの値／パラメータは、ＵＥによって選択／適用されてよい。要素インデックスの値が１の場合、ｐｕｓｃｈ－ＡｇｇｒｅｇａｔｉｏｎＦａｃｔｏｒ－ｕｒｌｌｃＬｉｓｔの２番目の要素／行／エントリの値／パラメータがＵＥによって適用／選択されてよく、以下同様である。いくつかの実装形態において、繰り返しリスト（例えばｐｕｓｃｈ－ＡｇｇｒｅｇａｔｉｏｎＦａｃｔｏｒ－ｕｒｌｌｃＬｉｓｔ）は、ＵＥに基づく、サービングセルグループに基づく、サービングセルに基づく、ＵＬ ＢＷＰに基づく、及び設定されたグラント設定に基づく内の少なくとも１つ毎にＢＳによって設定され得る。
【0086】
〔サブケース１．４：〕いくつかの実装形態において、インジケータは、係数又はパラメータを明示的又は暗黙的に示す値を表すＤＣＩフィールドのビットストリーム（コンテンツ）であってよい。このケースにおいて、ＤＣＩによってスケジュールされたＵＬグラントに対応するＰＵＳＣＨ送信のための公称の繰り返しの数は、係数の値に、ＰＵＳＣＨアグリゲーションファクター（例えばｐｕｓｃｈ－ＡｇｇｒｅｇａｔｉｏｎＦａｃｔｏｒ）の値、又はＵＲＬＬＣ ＰＵＳＣＨアグリゲーションファクター（例えばｐｕｓｃｈ－ＡｇｇｒｅｇａｔｉｏｎＦａｃｔｏｒ－ｕｒｌｌｃ）の値を乗算した結果とすることができる（又はそれによって得られる）。ｐｕｓｃｈ－ＡｇｇｒｅｇａｔｉｏｎＦａｃｔｏｒは、３ＧＰＰ ＴＳ ３８．３３１において提供される既存のパラメータであってもよく、一方で、ｐｕｓｃｈ－ＡｇｇｒｅｇａｔｉｏｎＦａｃｔｏｒ－ｕｒｌｌｃは、公称の繰り返しの数をＵＥに示すようにｇＮＢによって設定された新しく導入されたパラメータであってもよい。いくつかの実装形態において、ｐｕｓｃｈ－ＡｇｇｒｅｇａｔｉｏｎＦａｃｔｏｒ－ｕｒｌｌｃは、ＤＬ ＲＲＣメッセージを介して、ｇＮＢによって送信されてよい。ｐｕｓｃｈ－ＡｇｇｒｅｇａｔｉｏｎＦａｃｔｏｒ－ｕｒｌｌｃは、ＵＥに基づく、サービングセルグループに基づく、サービングセルに基づく、ＵＬ ＢＷＰに基づく、及び設定されたグラント設定に基づく内の少なくとも１つ毎にｇＮＢによって設定されてよい。例えば、ＵＬ ＢＷＰに基づいてｇＮＢによってｐｕｓｃｈ－Ａｇｇｒｅｇａｔｉｏｎ Ｆａｃｔｏｒ－ｕｒｌｌｃが設定され、ｇＮＢがＵＬ ＢＷＰ上でＰＵＳＣＨをスケジューリングするケースにおいて、ＰＵＳＣＨ送信が非スロットベースの繰り返しスキームを適用すべきであることをｇＮＢが示す場合、ＵＥは、ＵＬ ＢＷＰ上のＰＵＳＣＨ送信のための公称の繰り返しの数を決定するために、ＵＬ ＢＷＰに対応するｐｕｓｃｈ－ＡｇｇｒｅｇａｔｉｏｎＦａｃｔｏｒ－ｕｒｌｌｃを適用することができる。
【0087】
〔サブケース１．５：〕サブケース１．５と１．４との主な違いは、ＤＣＩによってスケジュールされたＰＵＳＣＨ送信のための公称の繰り返しの数が係数の値とｐｕｓｃｈ－ＡｇｇｒｅｇａｔｉｏｎＦａｃｔｏｒの値（又はｐｕｓｃｈ－ＡｇｇｒｅｇａｔｉｏｎＦａｃｔｏｒ－ｕｒｌｌｃの値）とを加算した結果であり得る（又はそれによって得られ得る）ことである。
【0088】
〔サブケース１．６：〕サブケース１．６と１．４との主な違いは、ＤＣＩによってスケジュールされた対応するＰＵＳＣＨ送信のための公称の繰り返しの数が係数の値を係数の値及びｐｕｓｃｈ－ＡｇｇｒｅｇａｔｉｏｎＦａｃｔｏｒの値（又はｐｕｓｃｈ－ＡｇｇｒｅｇａｔｉｏｎＦａｃｔｏｒ－ｕｒｌｌｃの値）で割った結果であり得る（又はそれによって得られる）ことである。いくつかの他の実装形態において、ＰＵＳＣＨ送信のための公称の繰り返しの数は、ｐｕｓｃｈ－ＡｇｇｒｅｇａｔｉｏｎＦａｃｔｏｒの値（又はｐｕｓｃｈ－ＡｇｇｒｅｇａｔｉｏｎＦａｃｔｏｒ－ｕｒｌｌｃの値）を係数の値で割った結果であり得る（又はそれによって得られ得る）。
【0089】
〔サブケース１．７：〕いくつかの実装形態において、ＤＣＩが特定のサービングセルグループ／サービングセル／ＵＬ ＢＷＰ上でＰＵＳＣＨをスケジューリングするために使用される場合、インジケータは、ＤＣＩに含まれるＤＣＩフィールド（例えばゼロビットフィールド）であってよい。このケースにおいて、ＤＣＩフィールドは、特定のサービングセルグループ／サービングセル／ＵＬ ＢＷＰ上のＰＵＳＣＨ送信にのみに適用され得る。
【0090】
〔サブケース１．８：〕いくつかの実装形態において、インジケータ（例えばＤＣＩフィールド）がＵＥ固有のＲＮＴＩの特定のタイプによってスクランブルされたＣＲＣビットを有するＤＣＩにのみ存在してよい。別の実装形態において、インジケータ（例えばＤＣＩフィールド）は、インジケータが特定タイプの（ＵＥ固有の）ＲＮＴＩによってスクランブルされたＣＲＣビットを有するＤＣＩ内にあるときのみ、ＵＥによって適用され得る。
【0091】
〔サブケース１．９：〕いくつかの実装形態において、上述したサブケースで説明したマッピング表及びｐｕｓｃｈ－ＡｇｇｒｅｇａｔｉｏｎＦａｃｔｏｒ－ｕｒｌｌｃＬｉｓｔは、サービングセルグループ／サービングセル／ＵＬ ＢＷＰに基づいて設定され得る。このケースにおいて、サービングセルグループ／サービングセル／ＵＬ ＢＷＰ上のＰＵＳＣＨ送信の公称の繰り返しの数は、マッピング表、又はサービングセルグループ／サービングセル／ＵＬ ＢＷＰに対応するｐｕｓｃｈ－ＡｇｇｒｅｇａｔｉｏｎＦａｃｔｏｒ－ｕｒｌｌｃＬｉｓｔによって決定され得る。別の例において、サービングセルグループ／サービングセル／ＵＬ ＢＷＰ上で受信されたＤＣＩによってスケジュールされたＰＵＳＣＨ送信は、マッピング表又はサービングセルグループ／サービングセル／ＵＬ ＢＷＰのＡｇｇｒｅｇａｔｉｏｎＦａｃｔｏｒ－ｕｒｌｌｃＬｉｓｔを適用することができる。
【0092】
〔サブケース１．１０：〕いくつかの実装形態において、ＤＣＩに含まれるＤＣＩフィールドのビット数は、ＲＲＣ設定によって決定されてよい。例えば、ＤＣＩフィールドは、ｐｕｓｃｈ－ＡｇｇｒｅｇａｔｉｏｎＦａｃｔｏｒ－ｕｒｌｌｃＬｉｓｔに含まれる要素の個数によって決定されてもよい。例えば、ＤＣＩフィールドは、以下のように決定されてもよい。
【0093】
【数1】
【0094】
〔サブケース１．１１：〕いくつかの実装形態において、ＤＣＩフィールドがｇＮＢによって適用されるＣＳ－ＲＮＴＩによってスクランブルされたＣＲＣビットを有するＤＣＩ（のみ）に含まれ、（例えば３ＧＰＰ ＴＳ ３８．３３１内で提供される）設定されたグラントタイプＩＩ設定を有効にすることができる。
【0095】
〔サブケース１．１２：〕いくつかの実装形態において、ＤＣＩフィールドは、ｇＮＢによって適用される設定されたグラント設定（例えばＣｏｎｆｉｇｕｒｅｄＧｒａｎｔＣｏｎｆｉｇ ＩＥ）の情報要素（ＩＥ）（のみ）に含まれてよく、（例えば３ＧＰＰ ＴＳ ３８．３３１内で提供される）設定されたグラントタイプＩ設定を有効にする。
【0096】
〔ケース２：〕
いくつかの実装形態において、ＵＥが動的インディケーションモード７０２にあるとき、ｇＮＢは、（例えば図７のパスｂとして示される）固有のインディケーションを介して非動的インディケーションモード７０４に切り替えるようにＵＥに示すことができる。インディケーションの例は、以下のサブケースに記載される。
いくつかの実装形態において、ＵＥが動的インディケーションモード７０２にあるとき、ｇＮＢは、（例えば図７のパスｂとして示される）固有のインディケーションを介して非動的インディケーションモード７０４に切り替えるようにＵＥに示すことができる。インディケーションの例は、以下のサブケースに記載される。
【0097】
〔サブケース２．１：〕いくつかの実装形態において、ＢＳ（例えばｇＮＢ）は、ＤＣＩをＵＥに送信することによって、動的インディケーションモード７０２で動作すべきか、又は非動的インディケーションモード７０４で動作すべきかをＵＥに示し得る。いくつかの実装形態において、ＤＣＩは、特定のＤＣＩフォーマットを有することができる。例えば、特定のＤＣＩフォーマットを受信／検出した後、ＵＥは、動的インディケーションモード７０２で動作することができる。対照的に、別のＤＣＩフォーマットがＵＥによって受信／検出される場合、ＵＥは、非動的インディケーションモード７０４で動作することができる。
【0098】
〔サブケース２．２：〕いくつかの実装形態において、ＢＳ（例えばｇＮＢ）は、動的インディケーションモード７０２又は非動的インディケーションモード７０４で動作すべきかどうかをＵＥに示すために、ＤＣＩに含まれるＤＣＩフィールド（表示）を適用してよい。一実装形態において、ＤＣＩフィールドは、１ビットフィールドであってもよい。例えば、ＤＣＩフィールドのコンテンツが「０」である場合、ＵＥは、動的インディケーションモード７０２で動作することができる。対照的に、ＤＣＩフィールドのコンテンツが「１」である場合、ＵＥは、非動的インディケーションモード７０４で動作することができる。
【0099】
〔サブケース２．３：〕サブケース２．３とサブケース２．２との間の主な違いは、ＵＥが動的インディケーションモード７０２又は非動的インディケーションモード７０４で動作すべきかどうかが、シチュエーション２のケース１で導入されたＤＣＩフィールドの特定の値によって示され得ることである。例えば、ＤＣＩフィールドのコンテンツ／値がｇＮＢによって第１の値にセットされるとき、ＵＥは、（例えば図７のパスｂとして示されるように）非動的インディケーションモード７０４に切り替えることができ、ＤＣＩフィールドのコンテンツ／値がｇＮＢによって第２の値にセットされるとき、ＵＥは、（例えば図７のパスａとして示されるように）非動的インディケーションモード７０４から動的インディケーションモード７０２に切り替えることができる。
【0100】
〔サブケース２．４：〕いくつかの実装形態において、ｇＮＢは、ＵＥがＭＡＣ制御要素（ＣＥ）を介して、動的インディケーションモード７０２で動作すべきか、又は非動的インディケーションモード７０４で動作すべきかをＵＥに示し得る。例えば、ＭＡＣ ＣＥに含まれた１つ又は複数のフィールドは、各々のサービングセルグループ／サービングセル／ＢＷＰ／ＵＬ ＢＷＰ／ＰＵＳＣＨのための動的インディケーションモード７０２又は非動的インディケーションモード７０４で動作するかどうかをＵＥに示すために使用されることができる。いくつかの実装形態において、ＵＥは、デフォルトで動的インディケーションモード７０２又は非動的インディケーションモード７０４で動作して、各々のサービングセルグループ／サービングセル／ＵＬ ＢＷＰ上でＰＵＳＣＨ送信を実行することができる。例えば、サービングセルグループを用いて設定された後、及びサービングセルグループに対応するＭＡＣ ＣＥを受信する前、ＵＥは、デフォルトで、動的インディケーションモード７０２又は非動的インディケーションモード７０４のいずれかでサービングセルグループ上でＰＵＳＣＨ送信を実行することができる。例えば、サービングセルで設定された後、及びサービングセルに対応するＭＡＣ ＣＥを受信する前に、ＵＥは、デフォルトで、動的インディケーションモード７０２又は非動的インディケーションモード７０４のいずれかでサービングセルグループ上でＰＵＳＣＨ送信を実行することができる。例えば、ＵＬ ＢＷＰで設定された後、ＵＬ ＢＷＰに対応するＭＡＣ ＣＥを受信する前に、ＵＥは、デフォルトで動的インディケーションモード７０２又は非動的インディケーションモード７０４でＵＬ ＢＷＰでＰＵＳＣＨ送信を実行することができる。
【0101】
〔サブケース２．５：〕サブケース２．４とサブケース２．３との主な違いは、ｇＮＢが第１のＭＡＣ ＣＥを介して動的インディケーションモード７０２で動作するようにＵＥに示し、第２のＭＡＣ ＣＥを介して非動的インディケーションモード７０４で動作するようにＵＥに示すことができることである。第１／第２のＭＡＣ ＣＥに含まれる１つ又は複数のフィールドは、各々のサービングセルグループ／サービングセル／ＢＷＰ／ＵＬ ＢＷＰ／ＰＵＳＣＨのために動的インディケーションモード７０２又は非動的インディケーションモード７０４で動作すべきかどうかをＵＥに示すために使用され得る。
【0102】
〔サブケース２．６：〕いくつかの実装形態において、ｇＮＢは、特定のＲＮＴＩを介して動的インディケーションモード７０２又は非動的インディケーションモード７０４で動作すべきかどうかをＵＥに示し得る。特定のＲＮＴＩは、ＤＬ ＲＲＣメッセージを介して、サービングセルグループ／サービングセル／ＵＬ ＢＷＰに基づいてｇＮＢによって設定され得る。例えば、特定のＲＮＴＩによってスクランブルされたＣＲＣビットを有するＤＣＩを受信するとき、ＵＥは、特定のＲＮＴＩによってスクランブルされたＣＲＣビットを有するＤＣＩを再度受信するまで、動的インディケーションモード７０２でサービングセルグループ／サービングセル／ＵＬ ＢＷＰ上でＰＵＳＣＨ送信を行うことができる。いくつかの実装形態において、ＵＥは、デフォルトで動的インディケーションモード７０２又は非動的インディケーションモード７０４で動作して、各々のサービングセルグループ／サービングセル／ＵＬ ＢＷＰ上でＰＵＳＣＨ送信を実行することができる。例えば、サービングセルグループで設定された後、サービングセルグループに対応する特定のＲＮＴＩによってスクランブルされたＣＲＣビットを有するＤＣＩを受信する前に、ＵＥは、デフォルトで動的インディケーションモード７０２又は非動的インディケーションモード７０４のいずれかでサービングセルグループ上でＰＵＳＣＨ送信を実行することができる。例えば、サービングセルで設定され、アクティブ化された後、及びサービングセルに対応する固有のＲＮＴＩによってスクランブルされたＣＲＣビットを有するＤＣＩを受信する前に、ＵＥは、デフォルトで動的インディケーションモード７０２又は非動的インディケーションモード７０４のいずれかでサービングセル上でＰＵＳＣＨ送信を実行することができる。例えば、ＵＬ ＢＷＰで設定され、ＵＬ ＢＷＰをアクティブ化した後、及びＵＬ ＢＷＰに対応する固有のＲＮＴＩによってスクランブルされたＣＲＣビットを有するＤＣＩを受信する前に、ＵＥは、デフォルトで動的インディケーションモード７０２又は非動的インディケーションモード７０４のいずれかでサービングセル上でＰＵＳＣＨ送信を実行することができる。
【0103】
〔サブケース２．７：〕サブケース２．６とサブケース２．７との主な違いは、ｇＮＢは、特定のＲＮＴＩを介して動的インディケーションモード７０２で動作するようにＵＥに示し、別の特定のＲＮＴＩを介して非動的インディケーションモード７０４で動作するようにＵＥに示すことができることである。
【0104】
〔サブケース２．８：〕いくつかの実装形態において、サービングセルグループ／サービングセル／ＵＬ ＢＷＰのデフォルトモード（例えば動的インディケーションモード７０２又は非動的インディケーションモード７０４）は、ＤＬ ＲＲＣメッセージを介してｇＮＢによって設定され得る。例えば、対応するＭＡＣ ＣＥ又はＤＣＩを受信する前に、ＵＥは、サービングセルグループ／サービングセル／ＵＬ ＢＷＰ上でＰＵＳＣＨ送信をデフォルトモードで実行することができる。
【0105】
〔サブケース２．９：〕いくつかの実装形態において、ＵＥは、タイマを用いて設定されてよい。デフォルトモードとは別の動作モード（例えば動的インディケーションモード７０２又は非動的インディケーションモード７０４）にスイッチするようにＵＥに示すインディケーション（例えばＭＡＣ ＣＥ又はＤＣＩ又はＲＮＴＩ）を受信するとき、ＵＥは、タイマを開始することができる。タイマが満了するとき、ＵＥは、ｇＮＢから更なるインディケーションを受信することなく、動作モードからデフォルトモードに自動的にスイッチすることができる。いくつかの実装形態において、（特定の）ＵＬグラントを受信するとき、ＵＥは、タイマを再開することができる。いくつかの実装形態において、タイマは、サービングセルグループ／サービングセル／ＵＬ ＢＷＰに基づいて維持／設定され得る。タイマの長さは、ＤＬ ＲＲＣメッセージを介してｇＮＢによって事前に設定されてもよい。
【0106】
〔ケース３：〕
図８は、本開示の実装形態による、ＵＥによって実行される手順のフローチャートを示す。図８に示すように、動作８０２において、ＵＥは、動的インディケーションモードで動作することができる。動作８０４において、ＵＥは、非動的インディケーションモードにスイッチするためのインディケーションを受信することができる。動作８０６において、ＵＥは、インディケーションを受信することに応じて、特定の動作を実行することができる。具体的な動作の例は、以下のサブケースで説明される。
図８は、本開示の実装形態による、ＵＥによって実行される手順のフローチャートを示す。図８に示すように、動作８０２において、ＵＥは、動的インディケーションモードで動作することができる。動作８０４において、ＵＥは、非動的インディケーションモードにスイッチするためのインディケーションを受信することができる。動作８０６において、ＵＥは、インディケーションを受信することに応じて、特定の動作を実行することができる。具体的な動作の例は、以下のサブケースで説明される。
【0107】
〔サブケース３．１：〕いくつかの実装形態において、ＤＣＩは、動的インディケーションモードで動作することをＵＥに示す第１のＤＣＩフィールドを含むことができる。このケースにおいて、ＰＵＳＣＨ送信の公称の繰り返しの数は、（例えば現行の３ＧＰＰ ＴＳ ３８．２１２で提供される）既存のＤＣＩフィールドといった第２のＤＣＩフィールドによって示され得る。例えば、既存のＤＣＩフィールドが第２のＤＣＩフィールドとして使用される場合、既存のＤＣＩフィールドのコンテンツは、ＤＣＩによってスケジュールされたＵＬグラントに対応するＰＵＳＣＨ送信のための公称の繰り返しの数をＵＥに示すように変更されてもよい。その上、既存のＤＣＩフィールドが公称の繰り返しの数をＵＥにどのように示すかの詳細は、シチュエーションＢのケース１に記載される実装形態に基づいて実装されてもよい。一方で、第１のＤＣＩフィールドが非動的インディケーションモードで動作するようにＵＥに示す場合、第２のＤＣＩフィールドは、３ＧＰＰ ＴＳ ３８．２１２において定義される方法と同じままであってもよい。いくつかの実装形態において、第１及び第２のＤＣＩフィールドは、ＵＬグラントをスケジュールするＤＣＩに含まれ得る。このケースにおいて、ＵＥが非スロットベースの繰り返しスキームに基づいてＵＬグラントに対応するＰＵＳＣＨ送信を実行するように設定されている場合、ＰＵＳＣＨ送信のための公称の繰り返しの数は、ｇＮＢから受信された第１のＤＣＩフィールド及び第２のＤＣＩフィールドによって決定され得る。例えば、第１のＤＣＩフィールドは、（暗黙的に）ＰＵＳＣＨの繰り返しスキームに基づいてＰＵＳＣＨ送信が実行されるべきかどうかを示すことができ、第２のＤＣＩフィールドは、（例えばＴＤＲＡ表の行／エントリインデックスを介して）ＴＤＲＡ表の内の行／エントリを明示的に示すことができる。
【0108】
〔サブケース３．２：〕いくつかの実装形態において、非動的インディケーションモードで動作するとき、ＵＥは、ＰＵＳＣＨ送信を実行するためにスロットベース繰り返しスキームを適用するためにフォールバックすることがある。ＰＵＳＣＨ送信のためのＰＵＳＣＨの繰り返しの数は、例えば、３ＧＰＰ ＴＳ ３８．３３１の中で定義されるｐｕｓｃｈ－Ａｇｇｒｅｇａｔｉｏｎｆａｃｔｏｒによって設定されることがある。
【0109】
〔サブケース３．３：〕いくつかの実装形態において、非動的インディケーションモードで動作するとき、ＵＥは、ＰＵＳＣＨ送信を実行するために非スロットベースの繰り返しスキームを適用し得る。ＰＵＳＣＨ送信のための公称の繰り返しの数は、例えば、ｐｕｓｃｈ－Ａｇｇｒｅｇａｔｉｏｎｆａｃｔｏｒ－ｕｒｌｌｃによって設定される固定値であってもよい。
【0110】
〔ケース４：〕いくつかの実装形態において、公称の繰り返しの数は、ＴＤＲＡインデックス（例えばＴＤＲＡ表に含まれる行／エントリを示す行／エントリインデックス）によって暗黙的に示されてよい。ＵＥでの１つ又は複数の非スロットベース繰り返しスキーム特有のＴＤＲＡ表は、ｇＮＢによって事前に設定される、又は３ＧＰＰ ＴＳで事前に定義されることができる。例えば、表１に示すように、ＴＤＲＡ表の各々の行／エントリは、ＰＵＳＣＨ送信を設定するために、公称の繰り返しの特定の数（例えばＲ値）と、Ｋ２、Ｓ及びＬの少なくとも１つを含むパラメータの集合との間のマッピング／関連を定義することができる。いくつかの実装形態において、ＵＥで設定されたＴＤＲＡ表が相互に異なったサイクリックプレフィックス（ＣＰ：Cyclic Prefix）モード（例えば通常のＣＰ又は拡張ＣＰ）に適用される場合がある。ＴＤＲＡ値（例えばＴＤＲＡ表の行／エントリインデックス）が一旦受信されると、ＵＥは、Ｒ値と、対応するＴＤＲＡ表に従ってＰＵＳＣＨ送信に適用されるパラメータの集合（例えばＫ２、Ｌ及び／又はＳの値）とを決定することができる。いくつかの実装形態において、ＵＥは、非スロットベース繰り返しスキームのために設定された少なくとも１つの第１のＴＤＲＡ表と、スロットベース繰り返しスキームのために設定された少なくとも１つの第２のＴＤＲＡ表とで設定されてもよい。いくつかの他の実装形態において、ＵＥは、動的インディケーションモードのために設定された少なくとも１つの第１のＴＤＲＡ表と、非動的インディケーションモードのために設定された少なくとも１つの第２のＴＤＲＡ表とを用いて設定され得る。
【0111】
〔サブケース４．１：〕いくつかの他の実装形態において、ＴＤＲＡ表は、１つ又は複数のインジケータを含むことができ、それらのインジケータの各々は、ＰＵＳＣＨ送信のための公称の繰り返しの数を直接的に表さなくてもよい。その代りに、各インジケータは、公称の繰り返しの数に関連付けられてもよい（又は示されてもよい）。このケースにおいて、ＵＥは、インジケータに基づいて公称の繰り返しの数を決定することができる。例えば、ＵＥは、インジケータの値が「１」であるとき、公称の繰り返しの数が「２」であると判定し、インジケータの値が「２」であるとき、適切に予め定義された／予め設定されたマッピングルールに基づいて、公称の繰り返しの数が「４」であると判定することができる。
【0112】
〔ケース５：〕
いくつかの実装形態において、ｇＮＢは、特定のＵＬ ＢＷＰのためにパラメータｐｕｓｃｈ－ＡｇｇｒｅｇａｔｉｏｎＦａｃｔｏｒ－ｕｒｌｌｃを設定し、サービングセルのために別のパラメータｐｕｓｃｈ－ＡｇｇｒｅｇａｔｉｏｎＦａｃｔｏｒ－ｕｒｌｌｃを設定してよい。このケースにおいて、ＵＥは、特定のＵＬ ＢＷＰのために設定されたｐｕｓｃｈ－ＡｇｇｒｅｇａｔｉｏｎＦａｃｔｏｒ－ｕｒｌｌｃの値として公称の繰り返しの数を設定することによって、非スロットベースの繰り返しスキームに基づいて、（ｐｕｓｃｈ－ＡｇｇｒｅｇａｔｉｏｎＦａｃｔｏｒ－ｕｒｌｌｃで設定された）特定のＵＬ ＢＷＰ上のＰＵＳＣＨ送信が実行されるべきであることを知ることができる。対照的に、ＰＵＳＣＨ送信がｐｕｓｃｈ－ＡｇｇｒｅｇａｔｉｏｎＦａｃｔｏｒ－ｕｒｌｌｃを用いて設定されていないＵＬ ＢＷＰ上にある場合、ＵＥは、公称の繰り返しの数を、ＵＬ ＢＷＰのサービングセルのために設定されたｐｕｓｃｈ－ＡｇｇｒｅｇａｔｉｏｎＦａｃｔｏｒ－ｕｒｌｌｃの値として設定することによって、非スロットベースの繰り返しスキームの下でＰＵＳＣＨ送信を実行することができる。
いくつかの実装形態において、ｇＮＢは、特定のＵＬ ＢＷＰのためにパラメータｐｕｓｃｈ－ＡｇｇｒｅｇａｔｉｏｎＦａｃｔｏｒ－ｕｒｌｌｃを設定し、サービングセルのために別のパラメータｐｕｓｃｈ－ＡｇｇｒｅｇａｔｉｏｎＦａｃｔｏｒ－ｕｒｌｌｃを設定してよい。このケースにおいて、ＵＥは、特定のＵＬ ＢＷＰのために設定されたｐｕｓｃｈ－ＡｇｇｒｅｇａｔｉｏｎＦａｃｔｏｒ－ｕｒｌｌｃの値として公称の繰り返しの数を設定することによって、非スロットベースの繰り返しスキームに基づいて、（ｐｕｓｃｈ－ＡｇｇｒｅｇａｔｉｏｎＦａｃｔｏｒ－ｕｒｌｌｃで設定された）特定のＵＬ ＢＷＰ上のＰＵＳＣＨ送信が実行されるべきであることを知ることができる。対照的に、ＰＵＳＣＨ送信がｐｕｓｃｈ－ＡｇｇｒｅｇａｔｉｏｎＦａｃｔｏｒ－ｕｒｌｌｃを用いて設定されていないＵＬ ＢＷＰ上にある場合、ＵＥは、公称の繰り返しの数を、ＵＬ ＢＷＰのサービングセルのために設定されたｐｕｓｃｈ－ＡｇｇｒｅｇａｔｉｏｎＦａｃｔｏｒ－ｕｒｌｌｃの値として設定することによって、非スロットベースの繰り返しスキームの下でＰＵＳＣＨ送信を実行することができる。
【0113】
〔サブケース５．１：〕いくつかの実装形態において、ケース５と同様に、ｇＮＢは特定のサービングセルのためのパラメータｐｕｓｃｈ－ＡｇｇｒｅｇａｔｉｏｎＦａｃｔｏｒ－ｕｒｌｌｃを設定し、サービングセルグループのための別のパラメータｐｕｓｃｈ－ＡｇｇｒｅｇａｔｉｏｎＦａｃｔｏｒ－ｕｒｌｌｃを設定することができる。このケースにおいて、ＵＥは、特定のサービングセルのために設定されたｐｕｓｃｈ－ＡｇｇｒｅｇａｔｉｏｎＦａｃｔｏｒ－ｕｒｌｌｃの値として公称の繰り返しの数を設定することによって、非スロットベースの繰り返しスキームに基づいて、（ｐｕｓｃｈ－ＡｇｇｒｅｇａｔｉｏｎＦａｃｔｏｒ－ｕｒｌｌｃで設定された）サービングセル上のＰＵＳＣＨ送信が実行されるべきであることを知ることができる。対照的に、ＰＵＳＣＨ送信がｐｕｓｃｈ－ＡｇｇｒｅｇａｔｉｏｎＦａｃｔｏｒ－ｕｒｌｌｃで設定されていないサービングセル上にある場合、ＵＥは、サービングセルのサービングセルグループのために設定されたｐｕｓｃｈ－ＡｇｇｒｅｇａｔｉｏｎＦａｃｔｏｒ－ｕｒｌｌｃの値として、ＰＵＳＣＨ送信のための公称の繰り返しの数をセットすることによって、非スロットベースの繰り返しスキームの下でＰＵＳＣＨ送信を実行することができる。
【0114】
図９は、本開示の実装形態による、ＵＥによって実行される手順のフローチャートを示す。動作９０２、９０４、９０６、９０８、９１０、及び９１２は図９において独立したブロックとして表される別個の動作として描写されるが、これらの別個に描写された動作は必ずしも順序に依存するものとして解釈されるべきではないことに留意されたい。図９において動作が実行される順序は限定として解釈されることを意図しておらず、説明されたブロックの任意の数は方法又は代替の方法を実施するために任意の順序で組み合わされてもよい。さらに、動作９０２、９０４、９０６、９０８、９１０、及び９１２の内の１つ又は複数は、本開示のいくつかの実装形態において省略され得る。
【0115】
図９に示すように、動作９０２において、ＵＥは、第１の値を用いて設定された第１のパラメータと、少なくとも１つの第２の値を用いて設定された第２のパラメータとを含むＲＲＣ設定を受信することができる。第１の値及び第２の値の各々は、ＰＵＳＣＨの繰り返しの数をそれぞれ示す。いくつかの実装形態において、第１のパラメータと第２のパラメータは、ＲＲＣ設定における異なる情報要素（ＩＥ：Information Element）に対応してもよく、ここで第１のパラメータは、単一の第１の値に向けられてもよく、第２のパラメータは、１つ又は複数の第２の値（例えば表１に示されているＲ値）を含む繰り返しリストに向けられてもよい（又はそうであってもよい）。いくつかの実装形態において、第１のパラメータ及び第２のパラメータは、サービングセルグループ／サービングセル／ＢＷＰに基づいて設定され得る。
【0116】
動作９０４において、ＵＥは、ＰＵＳＣＨ送信をスケジューリングするＰＤＣＣＨ上でＤＣＩを受信することができる。
【0117】
動作９０６において、ＵＥは、ＤＣＩに従って、第１のパラメータ又は第２のパラメータを選択して、ＰＵＳＣＨ送信のためのＰＵＳＣＨの繰り返しの数を決定することができる。いくつかの実装形態において、受信されたＤＣＩのＤＣＩフィールド／ＤＣＩフォーマットに基づいて、ＵＥは、第１のパラメータ又は第２のパラメータを選択することができる。例えば、各々のＤＣＩフォーマットは、それ自身の対応するＤＣＩフィールドを有することができるため、ブラインドデコーディングを実行するとき、ＤＣＩがＤＣＩフィールドの集合を用いて正常にデコーディングされることができるか否かを検査することによって、ＵＥは、ＤＣＩのＤＣＩフォーマットを決定することができる。このケースにおいて、ＤＣＩが第２のパラメータに関連付けられたＤＣＩフォーマットを有し、第２の値の内の１つを示すインデックスを含むとき、ＵＥは、ＰＵＳＣＨ送信のためのＰＵＳＣＨの繰り返しの数を決定するために、第２のパラメータを選択してよい。いくつかの実装形態において、第２のパラメータ（例えば繰り返しリスト）がインデックス（例えば繰り返しリストの行／エントリインデックス）と、ＰＵＳＣＨ送信の開始シンボルを示す第３の値（例えばＳの値）と、ＰＵＳＣＨ送信の連続シンボルの数を示す第４の値（Ｌの値）との間の関連を定義することができる。
【0118】
動作９０８において、第１のパラメータが選択されるとき、ＵＥは、ＰＵＳＣＨ送信のためのＰＵＳＣＨの繰り返しの数を第１の値として決定することができる。例えば、第１のパラメータが第１の値”２”を用いて設定される場合、ＵＥは、ＰＵＳＣＨ送信のためのＰＵＳＣＨの繰り返しの数が２であると判定することができる。別の例において、第１の値がＰＵＳＣＨ送信のためのＰＵＳＣＨの繰り返しの数を直接的に表さないことができるが、ＰＵＳＣＨ送信のためのＰＵＳＣＨの繰り返しの数と予め設定された／予め定義されたマッピングリレーションシップを有することができる（例えば第１の値は、ＰＵＳＣＨ送信のためのＰＵＳＣＨの繰り返しの数のインデックスとして使用されることができる）。このケースにおいて、ＵＥは、第１の値と、予め設定された／予め定義されたマッピング関係とに基づいて、ＰＵＳＣＨ送信のためのＰＵＳＣＨの繰り返しの数を決定することができる。
【0119】
動作９１０において、第２のパラメータが選択されるとき、ＵＥは、ＤＣＩによって示される少なくとも１つの第２の値の内の１つとして、ＰＵＳＣＨ送信のためのＰＵＳＣＨの繰り返しの数を決定することができる。例えば、第２のパラメータが”２”、”３”及び”４”といった、いくつかの第２値で設定され、第２の値の内の１つ（例えば”３”）がＤＣＩによって（例えばＤＣＩに含まれるＤＣＩフィールドによって）示される場合、ＵＥは、ＰＵＳＣＨ送信のためのＰＵＳＣＨの繰り返しの数が３であると判定することができる。別の例において、第２の値がＰＵＳＣＨ送信のためのＰＵＳＣＨの繰り返しの数を直接表さないことができるが、ＰＵＳＣＨ送信のためのＰＵＳＣＨの繰り返しの数と予め設定された／予め定義されたマッピング関係を有することができる（例えば第２の値はＰＵＳＣＨ送信のためのＰＵＳＣＨの繰り返しの数のインデックスとして使用されることができる）。このケースにおいて、ＵＥは、第２の値と、所定の設定された／所定の定義されたマッピング関係とに基づいて、ＰＵＳＣＨ送信のためのＰＵＳＣＨの繰り返しの数を判定することができる。
【0120】
動作９１２において、ＵＥは、ＰＵＳＣＨ送信のためのＰＵＳＣＨの繰り返しの数（例えば、ＰＵＳＣＨ送信が実行される数は、ＰＵＳＣＨ送信のためのＰＵＳＣＨの繰り返しの数によって（又は等しい）判定されることができる）に基づいて、複数回、ＰＵＳＣＨ送信を実行することができる（例えばＵＥは、連続するＵＬシンボルの集合の間でＰＵＳＣＨ送信を繰り返しすることができる）。例えば、第２のパラメータが選択され、第２のパラメータに含まれる示された第２の値（例えば繰り返しリスト）が「４」である場合、ＵＥは、ＤＣＩによってスケジュールされたＰＵＳＣＨ送信のためのＰＵＳＣＨの繰り返しの数が４であると判定することができる（第２の値がＰＵＳＣＨ送信のためのＰＵＳＣＨの繰り返しの数を直接的に表す場合）。このケースにおいて、ＵＥは、スケジュールされたＰＵＳＣＨ／ＴＢの最初の送信を実行し、続いて、スケジュールされたＰＵＳＣＨ／ＴＢの最初の送信を３回繰り返すことができる。したがって、ＵＥによるＰＵＳＣＨ／ＴＢ送信を実行する総数は４（すなわち、１つの最初のＰＵＳＣＨ／ＴＢ送信（又は「第１のＰＵＳＣＨ／ＴＢ繰り返し」）＋３つの繰り返しされたＰＵＳＣＨ／ＴＢ送信（又は「第２、第３及び第４のＰＵＳＣＨ／ＴＢ繰り返し」）である。
【0121】
いくつかの実装形態において、１つ又は複数の特定の条件が満たされるとき、上述した各（サブ）ケースを適用することができる。例えば、具体的な条件は、以下を含むことができる：
（ａ）ＵＥは、特定のアクセスストラタム（ＡＳ：Access Stratum）レイヤ機能（例えばパケットデータコンバージェンスプロトコル（ＰＤＣＰ）ドュプリケーション機能）を用いて設定される；
（ｂ）ＵＥは、特定のＡＳレイヤ機能（例えばＰＤＣＰドュプリケーション機能）で設定され、特定のＡＳレイヤ機能がアクティブになる；及び
（ｃ）ＵＥは、２つ以上のｇＮＢ／ｅＮＢを有するＲＲＣ接続を用いて設定される。
（ａ）ＵＥは、特定のアクセスストラタム（ＡＳ：Access Stratum）レイヤ機能（例えばパケットデータコンバージェンスプロトコル（ＰＤＣＰ）ドュプリケーション機能）を用いて設定される；
（ｂ）ＵＥは、特定のＡＳレイヤ機能（例えばＰＤＣＰドュプリケーション機能）で設定され、特定のＡＳレイヤ機能がアクティブになる；及び
（ｃ）ＵＥは、２つ以上のｇＮＢ／ｅＮＢを有するＲＲＣ接続を用いて設定される。
【0122】
以下は、特定の用語の非限定的な説明を提供する。
【0123】
セル：いくつかの実装形態において、セル（例えばＰＣｅｌｌ又はＳＣｅｌｌ）は、地理的エリア内のＵＴＲＡＮアクセスポイントによってブロードキャストされてもよい、対応する識別情報を通してＵＥによって一意的に識別されてもよい無線ネットワークオブジェクトであってよい。セルは、周波数分割複信方式（ＦＤＤ：Frequency Division Duplex）又は時分割複信方式（ＴＤＤ：Time Division Duplex）モードで動作され得る。
【0124】
サービングセル：いくつかの実装形態において、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態で動作し、キャリアアグリゲーション（ＣＡ）／デュアルコネクティビティ（ＤＣ）を用いて設定されていないＵＥのために、ＵＥは、１つのサービングセル（例えばＰＣｅｌｌ）のみを用いて設定できる。ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態で動作し、ＣＡ／ＤＣを用いて設定されるＵＥのために、ＵＥは、ＳｐＣｅｌｌ及び１つ又は複数のＳＣｅｌｌを含んでいる複数のサービングセルを用いて設定され得る。
【0125】
ＣＡ：いくつかの実装形態において、ＣＡのケースにおいて、２つ以上のコンポーネントキャリア（ＣＣ）は、集約されてよい。ＵＥは、その能力に応じて、ＣＣの内の１つ又は複数で信号を同時に受信又は送信してよい。ＣＡは、連続及び非連続ＣＣの両方でサポートされ得る。ＣＡが適用されるとき、フレームタイミング及びシステムフレーム番号（ＳＦＮ：System Frame Number）は、集約されるセルにわたって整列され得る。いくつかの実装形態において、ＵＥのための設定されたＣＣの最大数は、ＤＬのために１６であり、ＵＬのために１６であり得る。ＣＡが設定されるとき、ＵＥは、ネットワークとのＲＲＣ接続を１つだけ有することができる。ＲＲＣ接続確立／再確立／ハンドオーバの間、１つのサービングセルは、非アクセスストラタム（ＮＡＳ：Non-Access Stratum）モビリティ情報を提供することができ、ＲＲＣ接続再確立／ハンドオーバにおいて、１つのサービングセルは、セキュリティ入力を提供することができ、サービングセルは、ＰＣｅｌｌと呼ばれることがある。ＵＥの能力によっては、ＳＣｅｌｌは、ＵＥのための１セットのサービスセルとしてＰＣｅｌｌと共に形成されるように設定されてよい。したがって、ＵＥのためのサービングセルの設定されたセットは常に、１つのＰＣｅｌｌ及び１つ又は複数のＳＣｅｌｌからなる。
【0126】
設定されたグラント：いくつかの実装形態において、設定されたグラントタイプ１のために、ＲＲＣエンティティは、（周期性を含んでいる）設定された上りリンクグラントを直接提供してよい。設定されたグラントタイプ２のために、ＲＲＣエンティティは、ＣＧのＰＵＳＣＨリソースの周期性を定義することができ、一方で、設定されたスケジューリングＲＮＴＩ（ＣＳ－ＲＮＴＩ）にアドレス指定されたＰＤＣＣＨは、設定された上りリンクグラントを信号化し、アクティブ化するか、又はそれを非アクティブ化することができる。すなわち、ＣＳ－ＲＮＴＩにアドレス指定されたＰＤＣＣＨは、設定された上りリンクグラントが無効化されるまで、ＲＲＣエンティティによって定義された周期性に従って、設定された上りリンクグラントを再利用できることを示してよい。設定された上りリンクグラントがアクティブであるとき、ＵＥがＰＤＣＣＨ上でそのＣ－ＲＮＴＩ／ＣＳ－ＲＮＴＩ／ＭＣＳ－Ｃ－ＲＮＴＩを発見することができない場合、設定された上りリンクグラントによるＵＬ送信が実行され得る。ＵＥがＰＤＣＣＨ上でそのＣ－ＲＮＴＩ／ＣＳ－ＲＮＴＩ／ＭＣＳ－Ｃ－ＲＮＴＩを受信した場合、ＰＤＣＣＨの割振りは、設定された上りリンクグラントをオーバーライドすることができる。いくつかの実装形態において、ＭＣＳ－Ｃ－ＲＮＴＩの使用は、（Ｃ－ＲＮＴＩ ＭＡＣ ＣＥを除いて）ＭＡＣ手順におけるＣ－ＲＮＴＩの使用と同等であり得る。
【0127】
ＨＡＲＱ：いくつかの実装形態において、レイヤ１（例えばＰＨＹレイヤ）の２つ以上のピアエンティティ間の送信を保証するために、ＨＡＲＱ処理は、使用されてよい。ＰＨＹレイヤがＤＬ／ＵＬ空間多重化のために設定されていない場合、単一のＨＡＲＱプロセスは、ＴＢをサポートしてよい。ＰＨＹ層がＤＬ／ＵＬ空間多重化のために設定されるとき、単一のＨＡＲＱプロセスは、１つ又は複数のＴＢをサポートしてよい。各サービングセルは、ＨＡＲＱエンティティに対応することができ、各ＨＡＲＱエンティティは、ＤＬ及びＵＬ ＨＡＲＱプロセスの並列処理をサポートしてよい。
【0128】
ＨＡＲＱ通知（ＨＡＲＱ－ＡＣＫ）：いくつかの実装形態において、ＨＡＲＱ－ＡＣＫは、１ビットインジケータを含んでよく、ＨＡＲＱ－ＡＣＫは、インジケータのビット値が”０”のとき、ネガティブ通知（ＮＡＣＫ）であってよく、インジケータのビット値が”１”のとき、ポジティブ通知（ＡＣＫ）であってよい。
【0129】
タイマ：いくつかの実装形態において、ＵＥのＭＡＣエンティティが上りリンク信号再送のトリガ及び上りリンク信号再送期間の制限といった、個々の目的のために１つ又は複数のタイマをセットアップすることができる。ＭＡＣエンティティによって維持されているタイマ（例えば、本出願の様々な実装形態に記載されているタイマ）が開始されるとき、タイマは、停止するか、又は満了するまで、実行を開始することができる。その上、タイマは、それが開始しないときには実行しなくてもよい。タイマは、それが実行されていないときに開始することができる。また、実行中にタイマが再始動することもある。いくつかの実装形態において、タイマは常に初期値から開始又は再開することができ、初期値は、下りリンクＲＲＣ信号を介してｇＮＢによって設定することができるが、これに限定されない。
【0130】
ＢＷＰ：いくつかの実装形態において、ＢＷＰは、セルの総セル帯域幅のサブセットとすることができる。１つ又は複数のＢＷＰをＵＥに設定し、設定されたＢＷＰのどれが現在アクティブなＢＷＰであるかをＵＥに通知することにより、帯域幅調整（ＢＡ：Bandwidth Adaptation）を実現できる。ＰＣｅｌｌ上のＢＡ機構を有効にするために、ｇＮＢは、１つ又は複数のＵＬ及びＤＬ ＢＷＰを用いてＵＥを設定することができる。ＣＡのケースにおいて、ＳＣｅｌｌ上のＢＡ機構を有効にするために、ｇＮＢは、少なくとも、１つ又は複数のＤＬ ＢＷＰを用いてＵＥを設定することができる（これは、ＵＬ ＢＷＰがＵＥに設定されないことがあることを意味する）。ＰＣｅｌｌのために、初期ＢＷＰは、初期アクセスのために使用されるＢＷＰであってよい。ＳＣｅｌｌのために、初期ＢＷＰは、ＳＣｅｌｌ起動プロセスの間、ＵＥが最初に動作するように設定されたＢＷＰであってもよい。いくつかの実装形態において、ＵＥはｆｉｒｓｔＡｃｔｉｖｅＵｐｌｉｎｋＢＷＰ ＩＥフィールドによってＦｉｒｓｔ－Ａｃｔｉｖｅ ＵＬ ＢＷＰを用いて設定されてもよい。Ｆｉｒｓｔ－Ａｃｔｉｖｅ ＵＬ ＢＷＰがＳｐＣｅｌｌのために設定される場合、ｆｉｒｓｔＡｃｔｉｖｅＵｐｌｉｎｋＢＷＰ ＩＥフィールドは、ＲＲＣ（再）設定が実行されるとき、アクティブ化されるＵＬ ＢＷＰのＩＤを含むことができる。フィールドが存在しない場合、ＲＲＣ（再）設定は、ＢＷＰスイッチをトリガすることができない。Ｆｉｒｓｔ－Ａｃｔｉｖｅ上りリンクＢＷＰがＳＣｅｌｌのために設定される場合、ｆｉｒｓｔＡｃｔｉｖｅＵｐｌｉｎｋＢＷＰ ＩＥフィールドは、ＳＣｅｌｌのＭＡＣ起動時に使用されるＵＬ ＢＷＰのＩＤを含むことができる。
【0131】
ＰＤＣＣＨ：いくつかの実装形態において、ｇＮＢは、１つ又は複数のＰＤＣＣＨ上のＣ－ＲＮＴＩ／ＭＣＳ－Ｃ－ＲＮＴＩ／ＣＳ－ＲＮＴＩを介してＵＥにリソースを動的に割り振ってよい。ＵＥは、ＤＬ受信が有効なとき（例えば設定されているとき、ＤＲＸによって管理されるアクティビティー）、考えられる割り当てを発見するために、常にＰＤＣＣＨを監視することができる。いくつかの実装形態において、ＣＡが設定されるとき、同じＣ－ＲＮＴＩは、全てのサービングセルに適用され得る。
【0132】
物理下りリンク共有チャネル（ＰＤＳＣＨ）／ＰＵＳＣＨ：いくつかの実装形態において、ＰＤＣＣＨは、ＰＤＳＣＨ上のＤＬ送信及びＰＵＳＣＨ上のＵＬ送信をスケジュールするために使用され得る。
【0133】
時間合わせタイマ：いくつかの実装形態において、ＲＲＣエンティティは、時間合わせタイマの初期値を設定してよい。時間合わせタイマ（例えばｔｉｍｅＡｌｉｇｎｍｅｎｔＴｉｍｅｒ）は、ＵＬ時間合わせの保守のために使用されてもよく、ここで、時間合わせタイマは、タイミングアドバンスグループ（ＴＡＧ：Timing Advance Group）に基づいて設定され、維持されてよい。時間合わせタイマは、ＭＡＣエンティティが関連するタグに属するサービングセルをＵＬ時間合わせされると見なす時間長を制御するために使用され得る。
【0134】
開始及び長さインジケータ（ＳＬＩＶ）：いくつかの実装形態において、ＳＬＩＶは、ＰＵＳＣＨ／ＰＤＳＣＨのための時間領域割振りのために使用され得る。ＳＬＩＶは、ＰＵＳＣＨ／ＰＤＳＣＨ割振りのための開始シンボル及び連続シンボルの数を定義することができる。
【0135】
ＴＢ：上位レイヤ（例えばＭＡＣレイヤ／エンティティ）からＰＨＹレイヤへのデータは、通常、ＴＢと呼ばれることがある。
【0136】
本開示で説明される用語、定義、及び略語は、既存の文書（Ｅｕｒｏｐｅａｎ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｔａｎｄａｒｄｓ Ｉｎｓｔｉｔｕｔｅ（ＥＴＳＩ）、Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｕｎｉｏｎ（ＩＴＵ）など）由来であってもよく、又は３ＧＰＰの専門家によって新たに作成されてもよいことに留意されたい。
【0137】
いくつかの実装形態において、参照信号（ＲＳ）ＩＤは、ｇＮＢに新しいビームを明示的又は暗黙的に示すために使用される任意の他のＩＤによって置き換えられ得る。
【0138】
いくつかの実装形態において、ＤＬ ＲＲＣメッセージは、ＲＲＣ再設定メッセージ（例えばＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎ）、ＲＲＣ再開メッセージ（例えばＲＲＣＲｅｓｕｍｅ）、ＲＲＣ再確立メッセージ（例えばＲＲＣＲｅｅｓｔａｂｌｉｓｈｍｅｎｔ）、ＲＲＣセットアップメッセージ（例えばＲＲＣＳｅｔｕｐ）、又は他のＤＬユニキャストＲＲＣメッセージであってよい。
【0139】
いくつかの実装形態において、ビームは、空間領域フィルタと見なされ得る。例えば、無線装置（例えばＵＥ）は、対応するアンテナ要素によって信号を送信する前に、信号の位相及び／又は振幅を調整することによって、アナログドメインにおいて空間フィルタを適用してもよい。別の例において、無線通信システムにおける多入力多出力（ＭＩＭＯ：Multi－Input Multi－Output）技術により、空間フィルタをデジタル領域で適用することができる。例えば、ＵＥは、特定の空間／デジタルドメインフィルタである特定のビームを使用することによってＰＵＳＣＨ送信を行うことができる。いくつかの実装形態において、ビームは、アンテナ、アンテナポート、アンテナ素子、アンテナのグループ、アンテナポートのグループ、又はアンテナ素子のグループによって表され得る（又はそれに対応し得る）。いくつかの実装形態において、ビームは、特定のＲＳリソースによって形成され得る（又は特定のＲＳリソースに関連付けられ得る）。ビームは、電磁（ＥＭ：Electromagnetic）波が放射される空間ドメインフィルタと同等であってもよい。
【0140】
いくつかの実装形態において、送信されたシグナリングは、シグナリングを含む（又はそれに対応する）ＭＡＣ ＣＥ／ＭＡＣプロトコルデータユニット（ＰＤＵ）／レイヤ１シグナリング／上位レイヤシグナリングが送信され始める、完全に送信される、又は既に送信のために対応するＨＡＲＱプロセス／バッファに配信されていることを意味する。いくつかの実装形態において、送信されたシグナリングは、特定のＭＡＣ ＰＤＵの対応するＨＡＲＱ－ＡＣＫフィードバックが受信されることを意味し、特定のＭＡＣ ＰＵＤは、シグナリングを含む（又はそれに対応する）ＭＡＣ ＣＥ／レイヤ１シグナリング／上位レイヤシグナリングを含むことができる。いくつかの実装形態において、送信されたシグナリングは、シグナリングに対応するＭＡＣ ＣＥ／ＭＡＣ ＰＤＵが構築される又は生成されることを意味する。
【0141】
いくつかの実装形態において、ＨＡＲＱ－ＡＣＫフィードバックは、ＰＤＣＣＨ上のｇＮＢからＵＥによって受信されたＤＣＩのＤＣＩフォーマット０＿０、０＿１又は他のＤＣＩフォーマットによって実装されてよい。いくつかの実装形態において、受信されたＤＣＩは、特定の値（例えば１）にセットされてよい新しいデータインジケータ（ＮＤＩ：New Data Indicator）を含んでよい。その上、ＤＣＩは、（ビーム障害回復要求（ＢＦＲＱ）ＭＡＣ ＣＥ）を搬送する）ＭＡＣ ＰＤＵのＨＡＲＱ処理によって適用される（又は、示される）ＨＡＲＱ処理ＩＤと同じＨＡＲＱ処理ＩＤを示すことができる。
【0142】
いくつかの実装形態において、ＰＤＣＣＨは、ｇＮＢによってＵＥに送信され、ＵＥはｇＮＢからＰＤＣＣＨを受信してよい。同様に、ＰＤＳＣＨは、ｇＮＢによってＵＥに送信されてよく、ＵＥは、ｇＮＢからＰＤＳＣＨを受信してよい。ＵＬ送信のために、ＰＵＳＣＨ／ＰＵＣＣＨは、ＵＥによってｇＮＢに送信されてよく、ＰＵＳＣＨ／物理上りリンク制御チャネル（ＰＵＣＣＨ）は、ｇＮＢによって受信されてよい。
【0143】
いくつかの実装形態において、ＰＤＳＣＨ／ＰＵＳＣＨ送信は、時間ドメイン内の複数のシンボルにかかることができ、ＰＤＳＣＨ／ＰＵＳＣＨ（送信）の持続時間は、ＰＤＳＣＨ／ＰＵＳＣＨ（送信）の最初のシンボルの始めから始まり、ＰＤＳＣＨ／ＰＵＳＣＨ（送信）の最後のシンボルの終わりで終わる時間間隔とすることができる。
【0144】
いくつかの実装形態において、用語「割り込み」、「停止」、「キャンセル」、及び「スキップ」は、交換可能であり得る。
【0145】
図１０は、本開示の様々な態様による、無線通信のためのノードを示すブロック図である。図１０に示すように、ノード１０００は、トランシーバ１００６と、プロセッサ１００８と、メモリ１００２と、１つ又は複数のプレゼンテーション部品１００４と、少なくとも１つのアンテナ１０１０とを含むことができる。ノード１０００はまた、ＲＦスペクトル帯域モジュールと、ＢＳ通信モジュールと、ネットワーク通信モジュールと、システム通信管理モジュールと、入出力（Ｉ／Ｏ）ポートと、Ｉ／Ｏ部品と、電源（図１０には明示的に示されていない）とを含むことができる。これらの部品の各々は、１つ又は複数のバス１０２４を介して、直接的又は間接的に互いに通信することができる。一実装形態において、ノード１０００が例えば、図１から図９を参照して本明細書で説明される様々な機能を実行するＵＥ又はＢＳであり得る。
【0146】
送信機１０１６（例えば送信／送信回路）及び受信機１０１８（例えば受信／受信回路）を有するトランシーバ１００６は、時間及び／又は周波数リソース分割情報を送信及び／又は受信するように構成され得る。いくつかの実装形態において、トランシーバ１００６が使用可能、使用不可能又は柔軟に使用可能なサブフレーム及びスロットフォーマットを含むが、これらに限定されない、異なる種類のサブフレーム及びスロットで送信するように構成してもよい。トランシーバ１００６は、データ及び制御チャンネルを受信するように構成され得る。
【0147】
ノード１０００は、様々なコンピュータ読み取り可能媒体を含んでもよい。コンピュータ読み取り可能媒体は、ノード１０００によってアクセスされ得る任意の利用可能な媒体であり得、揮発性及び不揮発性媒体、リムーバブル及び非リムーバブル媒体の両方を含む。限定ではなく、例として、コンピュータ読み取り可能媒体は、コンピュータ記憶媒体及び通信媒体を含み得る。コンピュータ記憶媒体は、コンピュータ読み取り可能命令、データ構造、プログラムモジュール、又は他のデータなどの情報を記憶するための任意の方法又は技術で実装される、揮発性及び不揮発性、リムーバブル及び非リムーバブル媒体の両方を含む。
コンピュータ記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ又は他のメモリ技術、ＣＤ－ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）又は他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置又は他の磁気記憶装置を含む。コンピュータ記憶媒体は、伝播データ信号を含まない。通信媒体は、典型的にはコンピュータ読み取り可能命令、データ構造、プログラムモジュール、又は他のデータを、搬送波又は他のトランスポート機構などの変調データ信号で具現化し、任意の情報配信媒体を含む。「変調されたデータ信号」という単語は、その特性のうちの１つ又は複数が信号内に符号化されるように設定又は変更された信号を意味する。限定ではなく、例として、通信媒体は、有線ネットワーク又は直接有線接続などの有線媒体と、音響、ＲＦ、赤外線、及び他
の無線媒体などの無線媒体と、を含む。上記のいずれかの組合せも、コンピュータ読み取り可能媒体の範囲内に含まれるべきである。
コンピュータ記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ又は他のメモリ技術、ＣＤ－ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）又は他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置又は他の磁気記憶装置を含む。コンピュータ記憶媒体は、伝播データ信号を含まない。通信媒体は、典型的にはコンピュータ読み取り可能命令、データ構造、プログラムモジュール、又は他のデータを、搬送波又は他のトランスポート機構などの変調データ信号で具現化し、任意の情報配信媒体を含む。「変調されたデータ信号」という単語は、その特性のうちの１つ又は複数が信号内に符号化されるように設定又は変更された信号を意味する。限定ではなく、例として、通信媒体は、有線ネットワーク又は直接有線接続などの有線媒体と、音響、ＲＦ、赤外線、及び他
の無線媒体などの無線媒体と、を含む。上記のいずれかの組合せも、コンピュータ読み取り可能媒体の範囲内に含まれるべきである。
【0148】
メモリ１００２は、揮発性及び／又は不揮発性メモリの形態のコンピュータ記憶媒体を含んでもよい。メモリ１００２は、取り外し可能、取り外し不能、又はそれらの組み合わせであってもよい。例としてのメモリは、ソリッドステートメモリ、ハードドライブ、光ディスクドライブなどが含まれる。図１０に示すように、メモリ１００２は、実行されるとき、プロセッサ１００８に、例えば図１から図９を参照して、本明細書に記載する様々な機能を実行させるように構成された、コンピュータ読み取り可能なコンピュータ実行可能命令１０１４（例えば、ソフトウェアコード）を記憶することができる。あるいは、命令１０１４は、プロセッサ１００８によって直接的に実行可能ではなく、本明細書に記載する様々な機能を実行するためにノード１０００（例えばコンパイルされ実行されるとき）を引き起こすように設定されてもよい。
【0149】
プロセッサ１００８（例えば処理回路を有する）は、インテリジェントハードウェアデバイス、例えば中央処理装置（ＣＰＵ）、マイクロコントローラ、ＡＳＩＣなどを含んでもよい。プロセッサ１００８は、メモリを含んでもよい。プロセッサ１００８は、メモリ１００２から受信したデータ１０１２及び命令１０１４、並びにトランシーバ１００６、ベースバンド通信モジュール、及び／又はネットワーク通信モジュールを介した情報を処理することができる。プロセッサ１００８はまた、コアネットワークへの送信のために、アンテナ１０１０を介してネットワーク通信モジュールに送信するためにトランシーバ１００６に送信される情報を処理することができる。
【0150】
１つ又は複数のプレゼンテーション部品１００４は、人又は他のデバイスにデータインディケーションを提示する。プレゼンテーション部品１００４の例は、表示デバイス、スピーカー、印刷部品、振動部品などを含んでもよい。
【0151】
上記の説明から、様々な技術が、これらの概念の範囲から逸脱することなく、本出願で説明される概念を実行するために使用され得ることが明らかである。さらに、概念は特定の実装形態を特に参照して説明されてきたが、当業者はそれらの概念の範囲から逸脱することなく、形態及び詳細において変更を行うことができることを認識するであろう。したがって、説明された実装形態は、すべての点において、例示的なものであり、限定的なものではないと考えられるべきである。また、本出願は、上述の特定の実装形態に限定されるものではなく、本開示の範囲から逸脱することなく、多くの再構成、修正、及び置換が可能であることを理解されたい。
【図面の簡単な説明】
【0152】
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【国際調査報告】