特許 7569367 端末、基地局、通信方法及び集積回路

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-10-08

(45)【発行日】2024-10-17

(54)【発明の名称】端末、基地局、通信方法及び集積回路

(51)【国際特許分類】

   H04W 72/1268 20230101AFI20241009BHJP

   H04W 16/14 20090101ALI20241009BHJP

   H04W 72/115 20230101ALI20241009BHJP

   H04W 28/04 20090101ALI20241009BHJP

【ＦＩ】

H04W72/1268

H04W16/14

H04W72/115

H04W28/04 110

【請求項の数】 20

(21)【出願番号】P 2022500239

(86)(22)【出願日】2020-12-02

(86)【国際出願番号】 JP2020044902

(87)【国際公開番号】W WO2021161627

(87)【国際公開日】2021-08-19

【審査請求日】2023-09-07

(31)【優先権主張番号】P 2020022297

(32)【優先日】2020-02-13

(33)【優先権主張国・地域又は機関】JP

(73)【特許権者】

【識別番号】514136668

【氏名又は名称】パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ

【氏名又は名称原語表記】Ｐａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ

(74)【代理人】

【識別番号】110002952

【氏名又は名称】弁理士法人鷲田国際特許事務所

(72)【発明者】

【氏名】布目 知也

(72)【発明者】

【氏名】山本 哲矢

(72)【発明者】

【氏名】鈴木 秀俊

(72)【発明者】

【氏名】クゥァン クゥァン

(72)【発明者】

【氏名】堀内 綾子

(72)【発明者】

【氏名】小川 佳彦

【審査官】望月 章俊

(56)【参考文献】

【文献】Intel Corporation，Enhancements to configured grants for NR-unlicensed[online]，3GPP TSG RAN WG1 #96b R1-1904288，フランス，Internet<URL:https://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_96b/Docs/R1-1904288.zip>，2019年03月30日，[検索日 2024.07.30]

【文献】Sony，Channel access for NR unlicensed operations[online]，3GPP TSG RAN WG1 #97 R1-1906834，フランス，Internet<URL:https://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_97/Docs/R1-1906834.zip>，2019年05月03日，[検索日 2024.07.30]

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｗ４／００－Ｈ０４Ｗ９９／００

Ｈ０４Ｂ７／２４－Ｈ０４Ｂ７／２６

３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１－４

ＳＡ ＷＧ１－４

ＣＴ ＷＧ１、４

(57)【特許請求の範囲】

【請求項1】

免許不要帯のConfigured grantに関するパラメータを受信する受信回路と、
前記パラメータに基づいて、上り制御情報に含まれる情報又は前記上り制御情報に含まれない情報を決定する制御回路と、
を具備する端末。

【請求項2】

前記制御回路は、再送制御に関する情報を含む前記上り制御情報を送信する第１のモード、及び、前記再送制御に関する情報の少なくとも一部を含まない前記上り制御情報を送信する第２のモードのうち何れかを設定する、
請求項１に記載の端末。

【請求項3】

前記パラメータは、前記第１のモード及び前記第２のモードの何れかを示す、
請求項２に記載の端末。

【請求項4】

前記受信回路は、前記パラメータを含む上位レイヤ信号を受信する、
請求項１に記載の端末。

【請求項5】

前記制御回路は、前記パラメータに基づいて、前記上り制御情報がConfigured grant上り制御情報を含むか否かを決定する、
請求項１に記載の端末。

【請求項6】

前記Configured grant上り制御情報は、HARQプロセス番号、New Data Indicator（NDI）、及び、redundancy version（RV）を含む、
請求項５に記載の端末。

【請求項7】

前記上り制御情報が前記Configured grant上り制御情報を含む場合は再送タイマが設定され、前記上り制御情報が前記Configured grant上り制御情報を含まない場合は前記再送タイマが設定されていない、
請求項５に記載の端末。

【請求項8】

前記パラメータは、さらに、前記端末がConfigured grantの物理上り共通チャネル（CG- PUSCH）のための下りフィードバック情報を受信するか否かを指示する、
請求項１に記載の端末。

【請求項9】

端末は、
免許不要帯のConfigured grantに関するパラメータを受信し、
前記パラメータに基づいて、上り制御情報に含まれる情報又は前記上り制御情報に含まれない情報を決定する、
通信方法。

【請求項10】

免許不要帯のConfigured grantに関するパラメータを受信する処理と、
前記パラメータに基づいて、上り制御情報に含まれる情報又は前記上り制御情報に含まれない情報を決定する処理と、を制御する、
集積回路。

【請求項11】

免許不要帯のConfigured grantに関するパラメータを送信する送信回路と、
上り制御情報に含まれる情報を受信し、前記上り制御情報に含まれる情報又は前記上り制御情報に含まれない情報は前記パラメータに基づいて決定される、受信回路と、
を具備する基地局。

【請求項12】

前記情報は、再送制御に関する情報を含む前記上り制御情報を送信する第１のモード、及び、前記再送制御に関する情報の少なくとも一部を含まない前記上り制御情報を送信する第２のモードのうち何れかである、
請求項１１に記載の基地局。

【請求項13】

前記パラメータは、前記第１のモード及び前記第２のモードの何れかを示す、
請求項１２に記載の基地局。

【請求項14】

前記送信回路は、前記パラメータを含む上位レイヤ信号を送信する、
請求項１１に記載の基地局。

【請求項15】

前記パラメータに基づいて、前記上り制御情報がConfigured grant上り制御情報を含むか否かが決定される、
請求項１１に記載の基地局。

【請求項16】

前記Configured grant上り制御情報は、HARQプロセス番号、New Data Indicator（NDI）、及び、redundancy version（RV）を含む、
請求項１５に記載の基地局。

【請求項17】

前記上り制御情報が前記Configured grant上り制御情報を含む場合は再送タイマが設定され、前記上り制御情報が前記Configured grant上り制御情報を含まない場合は再送タイマが設定されていない、
請求項１５に記載の基地局。

【請求項18】

前記パラメータは、さらに、端末がConfigured grantの物理上り共通チャネル（CG- PUSCH）のための下りフィードバック情報を受信するか否かを指示する、
請求項１１に記載の基地局。

【請求項19】

基地局は、
免許不要帯のConfigured grantに関するパラメータを送信し、
上り制御情報に含まれる情報を受信し、前記上り制御情報に含まれる情報又は前記上り制御情報に含まれないは前記パラメータに基づいて決定される、
通信方法。

【請求項20】

免許不要帯のConfigured grantに関するパラメータを送信する処理と、
上り制御情報に含まれる情報を受信し、前記上り制御情報に含まれる情報又は前記上り制御情報に含まれない情報は前記パラメータに基づいて決定される、処理と、を制御する、
集積回路。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、端末及び通信方法に関する。

【背景技術】

【0002】

3rd Generation Partnership Project（3GPP）では、第5世代移動通信システム（5G：5th Generation mobile communication systems）の機能拡張として、Release 16 NR（New Radio access technology）の物理レイヤの仕様策定が完了した。NRでは、モバイルブロードバンドの高度化（eMBB: enhanced Mobile Broadband）の基本的な要求条件である高速及び大容量と合わせ、超高信頼低遅延通信（URLLC: Ultra Reliable and Low Latency Communication）を実現する機能をサポートしている（例えば、非特許文献１－４を参照）。

【先行技術文献】

【非特許文献】

【0003】

【文献】3GPP TS 38.211 V16.0.0, "NR; Physical channels and modulation (Release 16)," December 2019

【文献】3GPP TS 38.212 V16.0.0, "NR; Multiplexing and channel coding (Release 16)," December 2019

【文献】3GPP TS 38.213 V16.0.0, "NR; Physical layer procedure for control (Release 16)," December 2019

【文献】3GPP TS 38.214 V16.0.0, "NR; Physical layer procedures for data (Release 16)," December 2019

【発明の概要】

【0004】

しかしながら、免許不要帯域における上り制御情報（例えば、UCI：Uplink Control Information）の送信方法について十分に検討されていない。

【0005】

本開示の非限定的な実施例は、免許不要帯域における上り制御情報の送信効率を向上できる端末及び通信方法の提供に資する。

【0006】

本開示の一実施例に係る端末は、免許不要帯に関するパラメータを受信する受信回路と、前記パラメータに基づいて、上り制御情報に含める情報を決定する制御回路と、を具備する。

【0007】

なお、これらの包括的または具体的な態様は、システム、装置、方法、集積回路、コンピュータプログラム、または、記録媒体で実現されてもよく、システム、装置、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。

【0008】

本開示の一実施例によれば、免許不要帯域における上り制御情報の送信効率を向上できる。

【0009】

本開示の一実施例における更なる利点および効果は、明細書および図面から明らかにされる。かかる利点および／または効果は、いくつかの実施形態並びに明細書および図面に記載された特徴によってそれぞれ提供されるが、１つまたはそれ以上の同一の特徴を得るために必ずしも全てが提供される必要はない。

【図面の簡単な説明】

【0010】

【図1】Frame Based Equipment（FBE）の一例を示す図

【図2】端末の一部の構成を示すブロック図

【図3】基地局の構成を示すブロック図

【図4】端末の構成を示すブロック図

【図5】基地局及び端末の動作例を示すシーケンス図

【図6】3GPP NRシステムの例示的なアーキテクチャの図

【図7】ＮＧ－ＲＡＮと５ＧＣとの間の機能分離を示す概略図

【図8】Radio Resource Control（RRC）接続のセットアップ／再設定の手順のシーケンス図

【図9】大容量・高速通信（eMBB：enhanced Mobile BroadBand）、多数同時接続マシンタイプ通信（mMTC：massive Machine Type Communications）、および高信頼・超低遅延通信（URLLC：Ultra Reliable and Low Latency Communications）の利用シナリオを示す概略図

【図10】非ローミングシナリオのための例示的な５Ｇシステムアーキテクチャを示すブロック図

【発明を実施するための形態】

【0011】

以下、本開示の実施の形態について図面を参照して詳細に説明する。

【0012】

［アンライセンス周波数帯］
Release 16 NRでは、例えば、アンライセンス周波数帯（又は、免許不要帯域とも呼ぶ）において、NRの無線アクセス方式に基づいた通信を行うNR-Unlicensed（又は、NR-Uとも呼ぶ）が導入されている。

【0013】

アンライセンス周波数帯では、例えば、各装置は、送信前に、他のシステム又は端末等が無線チャネルを使用しているか否かを確認するキャリアセンス（例えば、Listen Before Talk（LBT）とも呼ぶ）を行う。NR-Uでは、例えば、LBTの結果に応じて送信可能か否かが決定されるので、端末（又は、user equipment（UE）とも呼ぶ）において一連の下りリンクデータ（例えば、downlink burst（DL burst））の送信開始を検出する手順が検討されている。例えば、Release 16 NRでは、PDCCHに基づくDL burstの検出が検討されている。

【0014】

また、Release 17 NRでは、アンライセンス周波数帯において、例えば、超高信頼低遅延（URLLC: Ultra Reliable and Low Latency Communications）サービスを運用するための拡張を行うことが検討されている。アンライセンス周波数帯では、例えば、他のシステム等からの干渉が入り得る。例えば、他のシステム等からの干渉によりLBT failure（又は、LBT失敗とも呼ばれる）が発生すると、送信までの待ち時間が生じ、遅延が増加し得る。

【0015】

そこで、他のシステム等からの干渉が基本的に入らない環境（例えば、「Controlled environment」と呼ぶ）においてURLLCサービスを運用することが検討されている。

【0016】

［Configured grant送信］
Release 15 NRにおいてサポートされるConfigured grant送信（例えば、ライセンス周波数帯におけるConfigured grant送信）について説明する。

【0017】

上りリンクデータのConfigured grant送信には、例えば、「Configured grant type 1送信」と「Configured grant type 2送信」とがある。

【0018】

Configured grant type 1送信では、例えば、符号化・変調方式（MCS：Modulation and Coding Scheme）、無線リソース割り当て（例えば、時間リソース又は周波数リソースの割り当て）、送信タイミング、及び、Hybrid Automatic Repeat Request（HARQ）プロセス数といった情報（例えば、Configured grant設定情報と呼ぶ）が、端末固有の上位レイヤ信号によって端末に設定（換言すると、通知又は指示）されてよい。端末は、例えば、上りリンクデータ（例えば、PUSCH：Physical Uplink Shared Channel）が発生した場合、基地局（例えば、gNBとも呼ばれる）から下り制御チャネル（例えば、PDCCH：Physical Downlink Control Channel）によるUL grant（例えば、動的な上りリンクデータのスケジューリング情報）無しに、予め設定されたMCS及び無線リソースといったConfigured grant設定情報に基づいて、上りリンクデータを送信してよい。

【0019】

なお、上位レイヤ信号は、例えば、Radio Resource Control（RRC）信号、higher layer signaling又はhigher layer parameterと呼ばれることもある。

【0020】

また、Configured grant type 2送信では、例えば、基地局からのPDCCHによって、Configured grant送信がActivation又はReleaseされる。Configured grant type 2送信では、例えば、送信タイミング及びHARQプロセス数といった情報は、Configure grant type 1送信と同様に端末固有の上位レイヤ信号によって設定されてよい。その一方で、Configured grant type 2送信では、MCS及び無線リソース割当情報といった情報は、Activation用下りリンク制御情報（DCI：Downlink Control Information）によって設定されてよい。端末は、例えば、上りリンクデータが発生した場合、上位レイヤ信号及びActivation用DCIによって設定された、MCS及び無線リソースといったConfigured grant設定情報を半永久的（換言すると、静的、又は、半静的）に用いて（換言すると、UL grant無しに）、上りリンクデータ（例えば、PUSCH）を送信してよい。

【0021】

また、Release 15 NRでは、例えば、Configured grant送信の再送制御には、UL grantが用いられる。例えば、UL grantによって、再送用の上りリンクデータのMCS及び無線リソース割当情報が制御される。

【0022】

また、Configured grant送信において使用されるHARQプロセス番号（又は、HARQ process ID）は、非限定的な一例として、PUSCHを送信するスロット番号（換言すると、PUSCHの送信タイミング）から一意に決定されてよい。例えば、Configured grant送信において送信されるPUSCHは、初回送信される信号と同様の扱いでもよく、Redundancy Version（RV）は0でよい。

【0023】

［アンライセンス周波数帯におけるConfigured grant送信］
NR-U（アンライセンス周波数帯におけるNR）におけるConfigured grant送信では、例えば、HARQプロセス番号、New Data Indicator（NDI）、及び、RVといったPUSCHの復号に用いられるパラメータ（例えば、再送制御に関するパラメータ）の一部は、Configured grant送信用の上り制御情報（例えば、CG-UCI：Configured grant Uplink Control Informationと呼ぶ）によって端末から基地局へ通知されてよい。

【0024】

CG-UCIは、例えば、PUSCH（又は、CG-PUSCHと呼ぶこともある）に割り当てられた無線リソースの一部を使用して、PUSCHと同じ送信タイミング（例えば、同じスロット）において送信されてよい。換言すると、CG-UCIは、CG-PUSCHと多重されてよい。

【0025】

ここで、NR-Uにおいて、CG-UCIを用いてHARQプロセス番号を明示的に通知する理由は、次のとおりである。例えば、NR-Uでは、LBTの結果によってはPUSCHが送信されるとは限らない。このため、例えば、ライセンス周波数帯のようにPUSCHの送信タイミングに紐づけてHARQプロセス番号を決定する方法では、当該PUSCHが実際に送信されるか否かによってHARQプロセスを柔軟に利用できない可能性がある。よって、HARQプロセス番号は、例えば、CG-PUSCHとともに送信されるCG-UCIを用いて通知され得る。

【0026】

また、NR-Uでは、例えば、NACKの受信又はタイマ満了により、UL grantの指示無しで端末がConfigured grant用に設定された無線リソースを用いて再送する動作がサポートされる。そこで、例えば、初回送信又は再送の状態を示す情報（例えば、NDI：New Data Indicator）、及び、再送時のPUSCHに適用するRVがCG-UCIによって送信されてよい。

【0027】

NR-Uでは、例えば、CG-PUSCHに対するHARQ-ACKフィードバックは、DFI（Downlink Feedback Indicator）と呼ばれる情報により、gNBからUEへ明示的に通知されてよい。CG-PUSCHに対して、例えば、CG-UCIによってHARQプロセス番号が通知される。このため、例えば、gNBがCG-UCIの受信に失敗すると、gNB側においてどのHARQプロセスのデータが送信されたかを特定できず、HARQプロセスを指定してPUSCHの再送を指示できない場合があり得る。そこで、gNBは、例えば、全てのHARQプロセスに対するHARQ-ACKフィードバック情報を通知（換言すると、フィードバック）してよい。また、gNBは、例えば、複数のPUSCHに対するHARQ-ACKフィードバック情報をまとめて端末へフィードバックすることにより、LBTによるオーバヘッドを低減し、再送制御の効率を向上できる。

【0028】

なお、DFIによる再送制御において、再送用のPUSCHのMCS及び無線リソース割当は初回送信時と同じでもよい。また、DFIは、例えば、PDCCHにおいて送信されてよい。また、DFIには、例えば、HARQ-ACKの他に送信電力制御（TPC：Transmission Power Control）コマンドといった他のパラメータが含まれてよい。

【0029】

［Frame based equipment（FBE）］
FBEは、NR-Uにおけるチャネルアクセス方式の１つである。FBEは、例えば、semi-static channel occupancyとも呼ばれる。図１は、FBEの一例を示す図である。

【0030】

FBEにおいて、gNBは、例えば、Fixed frame period（FFP）と呼ばれる周期の先頭においてCategory 2のLBT（例えば、キャリアセンスを実施する期間が固定のLBT）を行うことにより、チャネル占有時間（例えば、COT：Cannel occupancy time）を取得してよい。UEは、gNBのCOT内において、Category 2のLBT、又は、Category 1のLBT（例えば、キャリアセンスを実施しないLBT）を行うことにより、COTを取得してよい。

【0031】

また、他のチャネルアクセス方式であるLoad based equipment（LBE）（図示せず）では、例えば、UEは、任意のタイミングにおいてCOTの取得を試みることが可能である。その一方で、LBEでは、FBEにおけるCategory 2のLBTと比較して長いLBT期間をとり得るCategory 4のLBT（例えば、キャリアセンスを実施する期間がランダムのLBT）を行う場合があり得る。

【0032】

このように、FBEでは、LBEと比較して、UEが短いLBT期間においてCOTを取得可能である。その一方で、FBEでは、例えば、図１に示すように、gNB及びUEの両方とも送信不可（換言すると、COTを取得不可）の期間（例えば、Idle periodとも呼ばれる）を設けることが検討されている。

【0033】

以上、FBEについて説明した。

【0034】

しかしながら、アンライセンス周波数帯において、上りリンク信号（例えば、上り制御情報又は上りリンクデータ）の信頼性を維持又は向上する送信方法について十分に議論されていない。また、アンライセンス周波数帯では、例えば、CG-PUSCHの一部にCG-UCIが含まれ得るため、ライセンス周波数帯と比較して、CG-PUSCHの送信において使用されるリソース量が増加し得る。

【0035】

そこで、本開示の一実施例では、アンライセンス周波数帯において、上りリンク信号の信頼性を維持又は向上し、かつ、上りリンク信号の送信効率を向上する方法について説明する。

【0036】

（実施の形態１）
［通信システムの概要］
本開示の一態様に係る通信システムは、例えば、図３に示す基地局１００（例えば、gNB）、及び、図２及び図４に示す端末２００（例えば、UE）及びを備えてよい。

【0037】

図２は本開示の一態様に係る端末２００の一部の構成例を示すブロック図である。図３に示す端末２００において、受信部２０１は、免許不要帯（例えば、アンライセンス周波数帯）に関するパラメータを受信する。送信制御部２０４は、パラメータに基づいて、上り制御情報（例えば、CG-UCI）に含める情報を決定する。

【0038】

［基地局の構成］
図３は、本開示の一態様に係る基地局１００の構成例を示すブロック図である。図３において、基地局１００は、受信部１０１と、分離部１０２と、制御情報復調・復号部１０３と、データ復調・復号部１０４と、スケジューリング部１０５と、制御情報保持部１０６と、データ・制御情報生成部１０７と、符号化・変調部１０８と、送信部１０９と、を有する。

【0039】

受信部１０１は、端末２００から送信された信号を、アンテナを介して受信し、受信信号に対してダウンコンバート又はＡ／Ｄ変換等の受信処理を行い、受信処理後の受信信号を分離部１０２へ出力する。

【0040】

分離部１０２は、例えば、スケジューリング部１０５から入力される情報（例えば、CG-UCI設定情報）に基づいて、受信部１０１から入力される受信信号を、制御情報部分とデータ部分とに分離する。分離部１０２は、例えば、制御情報部分を制御情報復調・復号部１０３へ出力し、データ部分をデータ復調・復号部１０４へ出力する。なお、制御情報には、例えば、CG-UCIが含まれてよい。また、例えば、受信信号には、制御情報が含まれない場合もある。

【0041】

制御情報復調・復号部１０３は、例えば、分離部１０２から入力される受信信号（例えば、制御情報部分）を復調及び復号し、復号結果（例えば、CG-UCI）をデータ復調・復号部１０４へ出力する。なお、制御情報復調・復号部１０３は、例えば、受信信号にCG-UCIが含まれない場合、データ復調・復号部１０４への信号の出力を行わなくてよい。

【0042】

データ復調・復号部１０４は、例えば、制御情報復調・復号部１０３から入力されるCG-UCI、及び、スケジューリング部１０５から入力されるスケジューリング情報に基づいて、分離部１０２から入力されるデータ部分を復調及び復号し、復号結果をスケジューリング部１０５へ出力する。

【0043】

スケジューリング部１０５は、例えば、制御情報保持部１０６から入力される制御情報（例えば、Configured grant設定情報）に基づいて、CG-UCIに含めるパラメータ及びサイズ（例えば、ビット数）を決定する。スケジューリング部１０５は、例えば、決定した情報（例えば、CG-UCI設定情報と呼ぶ）を分離部１０２及びデータ復調・復号部１０４へ出力する。

【0044】

また、スケジューリング部１０５は、例えば、データ復調・復号部１０４から入力されるデータ復号結果に基づいて、明示的なHARQ-ACK情報による再送制御を行う場合には、データ・制御情報生成部１０７に対して、HARQ-ACKフィードバック情報の生成を指示する。また、スケジューリング部１０５は、シグナリング情報を送信する場合には、データ・制御情報生成部１０７に対して、シグナリング情報の生成を指示する。また、スケジューリング部１０５は、例えば、データ・制御情報生成部１０７に対して、データ又は制御情報の生成を指示してよい。

【0045】

制御情報保持部１０６は、例えば、各端末２００に対するConfigured grant設定情報（例えば、MCS、及び、無線リソース割当情報）等を保持する。制御情報保持部１０６は、例えば、保持した情報を必要に応じて、基地局１００の各構成部（例えば、スケジューリング部１０５）に出力してよい。

【0046】

データ・制御情報生成部１０７は、例えば、スケジューリング部１０５からの指示に従って、データ又は制御情報を生成し、生成したデータ又は制御情報を含む信号を符号化・変調部１０８に出力する。例えば、データ・制御情報生成部１０７は、スケジューリング部１０５から入力されるHARQ-ACKフィードバック情報、又は、シグナリング情報の生成指示に基づいて、制御情報を生成してよい。

【0047】

符号化・変調部１０８は、例えば、データ・制御情報生成部１０７から入力される信号を符号化及び変調し、変調後の信号（シンボル系列）を送信部１０９に出力する。

【0048】

送信部１０９は、符号化・変調部１０８から入力される信号に対してＤ／Ａ変換、アップコンバート又は増幅等の送信処理を行い、送信処理により得られた無線信号をアンテナから端末２００へ送信する。

【0049】

［端末の構成］
図４は、本開示の一態様に係る端末２００の構成例を示すブロック図である。図４において、端末２００は、受信部２０１と、復調・復号部２０２と、制御情報保持部２０３と、送信制御部２０４と、データ生成部２０５と、制御情報生成部２０６と、符号化・変調・多重部２０７と、送信部２０８と、を有する。

【0050】

受信部２０１は、例えば、アンテナを介して受信した受信信号に対してダウンコンバート又はＡ／Ｄ変換等の受信処理を行い、受信信号を復調・復号部２０２に出力する。

【0051】

復調・復号部２０２は、例えば、受信部２０１から入力される受信信号に含まれるデータ又は制御情報を復調及び復号し、復号結果を送信制御部２０４へ出力する。制御情報には、例えば、HARQ-ACKフィードバック情報が含まれてよい。また、例えば、復調・復号部２０２は、復号結果に含まれるシグナリング情報を制御情報保持部２０３へ出力する。

【0052】

制御情報保持部２０３は、例えば、復調・復号部２０２から入力されるシグナリング情報（例えば、Configured grant設定情報）を保持し、保持した情報を、必要に応じて、各構成部（例えば、送信制御部２０４）に出力する。

【0053】

送信制御部２０４は、例えば、復調・復号部２０２から入力される制御情報又はデータの復号結果、及び、制御情報保持部２０３から入力されるConfigured grant設定情報に基づいて、CG-UCIに含めるパラメータ又はサイズ（例えば、ビット数）を決定する。送信制御部２０４は、例えば、決定した情報に基づいて、制御情報生成部２０６に対して、制御情報（例えば、CG-UCI）の生成を指示する。また、送信制御部２０４は、例えば、データ生成部２０５に対して、データ（例えば、CG-PUSCH）の生成を指示する。

【0054】

データ生成部２０５は、例えば、送信制御部２０４から入力されるデータ生成指示に基づいて、送信データ（例えば、CG-PUSCH）を生成し、符号化・変調・多重部２０７に出力する。

【0055】

制御情報生成部２０６は、例えば、送信制御部２０４から入力される制御情報生成指示に基づいて、制御情報（例えば、CG-UCI）を生成し、符号化・変調・多重部２０７に出力する。

【0056】

符号化・変調・多重部２０７は、例えば、データ生成部２０５から入力される送信データ、及び、制御情報生成部２０６から入力される制御情報を符号化及び変調する。また、符号化・変調・多重部２０７は、例えば、データと制御情報とを多重し、送信部２０８へ出力する。

【0057】

送信部２０８は、例えば、符号化・変調・多重部２０７から入力される信号に対してＤ／Ａ変換、アップコンバート又は増幅等の送信処理を行い、送信処理により得られた無線信号をアンテナから基地局１００へ送信する。

【0058】

［基地局１００及び端末２００の動作］
以上の構成を有する基地局１００及び端末２００における動作例について説明する。

【0059】

図５は基地局１００及び端末２００の動作例を示すシーケンス図である。

【0060】

基地局１００は、例えば、端末２００に対するConfigured grant設定を決定する（ＳＴ１０１）。Configured grant設定には、例えば、MCS、無線リソース割り当て、送信タイミング、HARQプロセスに関する情報が含まれてよい。

【0061】

基地局１００は、端末２００に対して、制御情報を送信する（ＳＴ１０２）。制御情報には、例えば、Configured grant設定情報が含まれてよい。

【0062】

基地局１００は、例えば、Configured grant設定情報に基づいて、端末２００に対するCG-UCIの設定を決定する（ＳＴ１０３）。また、端末２００は、例えば、基地局１００から送信されるConfigured grant設定情報に基づいて、CG-UCIの設定を決定する（ＳＴ１０４）。例えば、基地局１００及び端末２００は、アンライセンス周波数帯に関するパラメータ（例えば、Configured grant設定情報又はアンライセンス周波数帯に関する情報）に基づいて、CG-UCIに含める情報（例えば、CG-UCIパラメータとも呼ばれる）を決定してよい。換言すると、基地局１００及び端末２００は、CG-UCIに含まれない情報を決定してもよい。例えば、基地局１００及び端末２００は、CG-UCIに含まれる情報の制御において、CG-UCIのサイズを決定してもよい。例えば、CG-UCI設定には、CG-UCIパラメータに関するモード（一例は後述する）の設定が含まれてよい。

【0063】

端末２００は、例えば、CG-UCI設定に基づいて、CG-UCIを生成し（ＳＴ１０５）、生成したCG-UCIを基地局１００へ送信する（ＳＴ１０６）。

【0064】

基地局１００は、例えば、端末２００のCG-UCI設定に基づいて、端末２００から受信した受信信号から、CG-UCIを分離する（ＳＴ１０７）。

【0065】

［CG-UCIパラメータの決定方法］
基地局１００（例えば、スケジューリング部１０５）、及び、端末２００（例えば、送信制御部２０４）におけるCG-UCIパラメータの決定方法（例えば、図５におけるＳＴ１０３及びＳＴ１０４の処理）の一例について説明する。

【0066】

アンライセンス周波数帯において、CG-UCIに含まれるCG-UCIパラメータは、例えば、モードに応じて決定されてよい。モードには、例えば、CG-UCIのビット数を削減する「削減モード」、及び、CG-UCIのビット数を削減しない「非削減モード」がある。モードの決定方法の例については後述する。

【0067】

なお、「ビット数」は、例えば、「ビットサイズ」（bit size）あるいは「ビット長」（bit length）に相互に読み替えられてもよい。また、「モード」は、例えば、「方法」（method）あるいは「タイプ」（type）に相互に読み替えられてもよい。

【0068】

CG-UCIの削減モードでは、例えば、CG-UCIパラメータの少なくとも一部が削減される。削減されるパラメータには、例えば、以下のパラメータ（例えば、HARQプロセス番号又は再送用パラメータ）があり得る。

【0069】

以下、削減モードにおいてHARQプロセス番号に関する情報がCG-UCIに含まれない場合について説明する。

【0070】

削減モードでは、例えば、CG-UCIには、HARQプロセス番号に関する情報が含まれなくてよい。

【0071】

その一方で、削減モードでは、HARQプロセス番号は、例えば、CG-PUSCHの送信タイミングに基づいて決定（換言すると、計算）されてよい。HARQプロセス番号の計算方法には、例えば、以下の方法がある。

【0072】

＜HARQプロセス番号の計算方法１＞
HARQプロセス番号は、例えば、CG-PUSCHが送信されるシステムフレーム番号（例えば、SFN：System frame number）及びsymbol番号に基づいて計算されてよい。換言すると、計算方法１では、ライセンス周波数帯（例えば、licensed band）と同様の方法によってHARQプロセス番号が決定されてよい。

【0073】

＜HARQプロセス番号の計算方法２＞
HARQプロセス番号は、例えば、gNB COT内の相対的なタイミングに基づいて計算されてよい。

【0074】

例えば、HARQプロセス番号は、gNB COTの先頭（又は、COT内の或るタイミング）に基づいて、以下の決定方法によって決定されてよい。

【0075】

決定方法１：
決定方法１では、例えば、複数のCOT間において、同じパターンのHARQプロセス番号が設定されてよい。

【0076】

例えば、HARQプロセス番号（HARQ Process ID）は、以下の式に従って定義されてよい。
HARQ Process ID = [floor(CURRENT_symbol/periodicity)] modulo nrofHARQ-Processes

【0077】

ここで、CURRENT_symbolは、COTの先頭シンボルからのシンボル数を示し、periodicityはConfigured grantの送信周期を示し、nrofHARQ-Processesは、Configured grantに割り当てられたHARQプロセス数を示す。また、関数floor(x)は、x以下の最大の整数を返す床関数を表す。

【0078】

決定方法２：
決定方法２では、例えば、複数のCOT間において、異なるパターンのHARQプロセス番号が設定されてよい。

【0079】

例えば、HARQプロセス番号（HARQ Process ID）は、以下の式に従って定義されてよい。
HARQ Process ID = [floor(CURRENT_symbol/periodicity)+n] modulo nrofHARQ-Processes

【0080】

ここで、nはCOT毎にgNBからUEに通知される値を示す。また、CURRENT_symbol、periodicity、nrofHARQ-Processesは、決定方法１と同様である。

【0081】

例えば、決定方法１は、決定方法２のようなCOT毎にHARQプロセス番号の異なるパターンを適用するためのシグナリング又はパターンの変更方法を予め決定するといった、基地局１００（例えば、gNB）と端末２００（例えば、UE）との間の認識を共有するための処理が無くてよい。そのため、決定方法１では、決定方法２と比較して、例えば、処理をよりシンプルにできる点、又は、gNBとUEとの間の認識ずれが起こりにくいという利点がある。

【0082】

その一方で、決定方法２は、例えば、COT長がより短い場合、periodicityがより長い場合、又は、Configured grantに割り当てられたHARQプロセス数がより多い場合といった、１つのCOT内においてConfigured grantに割り当てられた全てのHARQプロセスが割り当てられない場合でも、他のCOTにおいて別のHARQプロセスを使用可能になる。そのため、決定方法２では、決定方法１と比較して、例えば、より多くのHARQプロセスが使用可能であるという利点がある。

【0083】

なお、決定方法１及び決定方法２の何れの方法を適用するかについては、例えば、COT長（例えば、最大COT長）、periodicity、又は、Configured grantのHARQプロセス数の少なくとも一つに応じて決定されてもよい。例えば、HARQプロセス数が閾値以下の場合には決定方法１が適用され、HARQプロセス数が閾値より多い場合には決定方法２が適用されてもよい。これにより、例えば、最大COT長、periodicity、又は、HARQプロセス数に応じた決定方法が選択可能になる。なお、閾値は、例えば、最大COT長といったパラメータに基づいて決定、又は通知されてよい。

【0084】

以上、HARQプロセス番号の計算方法２について説明した。

【0085】

このように、削減モードにおいて、HARQプロセス番号の削減により、CG-UCIのビット数を低減でき、非削減モードと比較して、例えば、同じサイズのリソースを使用する場合に、CG-UCIの信頼性を向上できる。

【0086】

以上、削減モードにおいてHARQプロセス番号に関する情報がCG-UCIに含まれない場合について説明した。

【0087】

その一方で、非削減モードでは、HARQプロセス番号は、例えば、端末２００が決定し、CG-UCIによって基地局１００へ通知される。このため、例えば、LBT failureが発生し、端末２００においてConfigured grantリソース（以下、CGリソースと呼ぶ）でのPUSCH送信が不可の場合もあり得る環境において、HARQプロセス番号の端末２００による決定及びCG-UCIによる通知によって、HARQプロセスを有効に使用できる。

【0088】

次に、削減モードにおいて、NDI及びRVといった再送用パラメータがCG-UCIに含まれない場合について説明する。

【0089】

削減モードでは、例えば、CG-UCIには、NDI及びRVといった再送用パラメータが含まれなくてよい。

【0090】

また、削減モードでは、例えば、HARQ-ACKフィードバック情報（例えば、DFI）又は再送用タイマを用いたCGリソース上における再送はサポートされず、UL grantによる再送がサポートされてよい。例えば、URLLCでは高い信頼性で送信することにより、他のサービスタイプと比較して、再送の発生確率が低い場合がある。また、LBT failureが起こりにくい環境では、HARQ-ACKフィードバックが阻害されることが少ない。このような場合においては、DFIにより複数HARQプロセスに対してまとめてHARQ-ACKフィードバックを行ったり、再送用タイマを使用して再送を制御したりする必要性は低い。そのため、例えば、URLLCサービスが適用される場合、又は、LBT failureが起こりにくい環境では、削減モードにおいて、CG-UCIに再送用パラメータが含まれず、DFI又は再送用タイマを用いたCGリソース上における再送がサポートされなくてもよい。

【0091】

CGリソース上の再送をサポートしない場合、CGリソースにおける送信は、再送ではなく、初回送信となる。初回送信時には、例えば、NDIはトグルしており（toggled）、RV=0とみなしてよい。これにより、NDI及びRVといった再送用パラメータは無くてよい。

【0092】

よって、削減モードにおいて、再送用パラメータの削減により、CG-UCIのビット数を低減でき、非削減モードと比較して、例えば、同じサイズのリソースを使用する場合に、CG-UCIの信頼性を向上できる。また、例えば、再送のためのDFIが無くてよいので、下りリンクにおける制御情報のオーバヘッドを削減できる。

【0093】

以上、削減モードにおいて再送用パラメータに関する情報がCG-UCIに含まれない場合について説明した。

【0094】

その一方で、非削減モードでは、例えば、DFI又は再送用タイマを用いたCGリソース上の再送がサポートされてよい。非削減モードでは、例えば、NDI及びRVといった再送用パラメータは、端末２００が決定し、CG-UCIによって基地局１００へ通知される。これにより、非削減モードでは、例えば、LBT failureが発生し得る環境において、CGリソースを用いた再送制御を行うことができるので、再送機会の増加といった再送制御の効率を向上できる。

【0095】

このように、削減モードでは、CG-UCIのビット数の削減により、例えば、CG-UCIのビット数を削減しない場合と比較して、少ないリソースで信頼性の高いCG-UCI（例えば、CG-UCIを送信する場合）及びCG-PUSCHの送受信を実現できる。また、非削減モードでは、例えば、他のシステムからの干渉等によるLBT failureが発生し得る場合に、HARQプロセスの使用効率を向上した再送制御を実現できる。そのため、例えば、削減モード及び非削減モードの切替により、PUSCHリソースの低減により信頼性を高める制御と、LBT failureに対する耐性を高める制御とを使い分けられる。よって、例えば、基地局１００及び端末２００は、基地局１００と端末２００との間の無線伝搬環境（又は状況）に応じて、CG-UCIを制御できる。

【0096】

なお、例えば、削減モードでは、上述したHARQプロセス番号及び再送用パラメータの少なくとも一つを削減してよい。または、削減モードにおいて、CG-UCIに含まれる全てのCGパラメータを削減してもよい。この場合、端末２００は、CG-UCIを送信しなくてよいので、CG-UCIに関する送受信処理を行わなくてよい。

【0097】

また、ここでは、削減モードにおいて、HARQプロセス番号及び再送用パラメータの少なくとも一つを削減する場合について説明したが、削減するパラメータは、HARQプロセス番号及び再送用パラメータと異なるパラメータでもよい。例えば、HARQプロセス番号及び再送用パラメータと異なるパラメータの削減により、CG-UCIの符号化率を低減できるため、上述したように、CG-UCIの信頼性を向上できる。

【0098】

また、削減モードにおいて、パラメータそのものを削除する場合に限定されず、例えば、パラメータのビット数を低減してもよい。例えば、非削減モードにおいてRVのビット数を2 bitに設定するのに対して、削減モードではRVのビット数を1 bitに設定してもよい。これにより、例えば、再送の発生確率が低く、2パターンのRV（例えば、RV=0, 3など）を使用すればよい場合に、CG-UCIによるRVの通知を残しつつ、CG-UCIのビット数を削減できる。

【0099】

以上、CG-UCIパラメータの決定方法について説明した。

【0100】

次に、モードの決定方法の一例について説明する。

【0101】

例えば、端末２００は、アンライセンス周波数帯に関するパラメータに基づいて、モード（換言すると、CG-UCIに含める情報、又は、CG-UCIに含めない情報）を決定してよい。アンライセンス周波数帯に関するパラメータには、例えば、アンライセンス周波数帯において端末２００に設定又は通知されるパラメータでもよく、アンライセンス周波数帯における端末２００の無線伝搬環境に関するパラメータでもよい。

【0102】

＜決定方法１＞
決定方法１では、モードは、例えば、上位レイヤ信号（例えば、RRC信号）といったSemi-static（準静的）なシグナリングによって明示的に設定されてよい。

【0103】

例えば、Semi-staticなシグナリングに、削減モード及び非削減モードの何れか一方を通知するパラメータが追加されてよい。

【0104】

また、Semi-staticなシグナリングには、例えば、Cell specificシグナリング及びUE specificシグナリングがある。

【0105】

Cell specificシグナリング：
例えば、URLLCサービスは、Controlled environmentにおいて運用されることが想定される。

【0106】

また、Controlled environmentであるか否かは局所的なエリアによって変化しないことが想定され得る。例えば、Controlled environmentであるか否かはセル単位で決定されることが想定され得る。よって、例えば、モードは、Controlled environmentであるか否かに基づいてセル単位で決定されてよい。

【0107】

そのため、Cell-specificシグナリングによるモードの通知により、例えば、セル内の端末２００に対して共通の処理を適用でき、基地局１００（例えば、gNB）の制御及び処理を簡易化できる。

【0108】

UE specificシグナリング：
例えば、LBT failureが複数のUEのうち一部のUEにおいて発生する場合、又は、URLLCサービスが複数のUEのうち一部のUEに適用される場合には、UE specificシグナリングによるモードの通知が有効である。

【0109】

このUE specificシグナリングによるモード設定は、例えば、Configured grant設定（例えば、Configured grant configurationとも呼ばれる）に紐づけてもよい。例えば、Configured grant設定毎にモードが設定されてもよい。例えば、基地局１００（gNB）と端末２００（UE）との間で、端末２００（例えば、UE）毎又はConfigured grant設定毎のモードの認識を合わせることで、CG-UCI及びDFIの送受信は可能である。よって、例えば、異なるモードがセル内に混在して設定されてもよい。

【0110】

このように、UE specificシグナリングによるモードの通知により、例えば、PUSCHリソースを低減する処理（換言すると、削減モード）、及び、LBT failureの発生を想定した処理（換言すると、非削減モード）のうち、UE毎又はConfigured grant設定毎に適したモードの設定が可能である。

【0111】

以上、Cell specificシグナリング及びUE specificシグナリングについて説明した。

【0112】

このように、決定方法１では、モードは明示的に通知されるので、例えば、基地局１００と端末２００との間の無線状況に応じて、基地局１００は、PUSCHリソースを低減する処理（例えば、削減モード）、及び、LBT failureの発生を想定した処理（例えば、非削減モード）の何れか一方を適切に設定できる。

【0113】

なお、決定方法１では、モードが明示的に通知される場合について説明したが、これに限定されない。例えば、基地局１００は、Controlled environmentであるか否かを示すシグナリングを端末２００へ通知し、端末２００は、そのシグナリングに紐づけてモードを設定（例えば、変更）してもよい。例えば、Configured environment（例えば、他システムからの干渉が無い環境）の場合、削減モードが設定され、Configured environmentではない環境（例えば、他システムからの干渉が有り得る環境）の場合、非削減モードが設定されてよい。例えば、Controlled environmentであるか否かを示すシグナリングがモード設定とは異なる他の処理にも使用される場合には、Controlled environmentであるか否かを示すシグナリングは共通化でき、シグナリングのオーバヘッドを低減できる。

【0114】

＜決定方法２＞
決定方法２では、モードは、例えば、動的なシグナリングによって設定されてよい。動的なシグナリングには、例えば、Configured grant type 2における、activationまたはreactivationに用いるPDCCHがある。

【0115】

以下、決定方法２における通知方法について説明する。

【0116】

通知方法１：
モードは、例えば、PDCCHに含まれるパラメータによって明示的に通知されてよい。例えば、PDCCHに、1 bitのパラメータが追加されてよい。基地局１００は、例えば、削減モード及び非削減モードの何れか一方を示す1 bitのパラメータを端末２００へ通知してよい。

【0117】

通知方法２：
モードは、例えば、DCI formatに紐づけられてよい。例えば、端末２００は、DCI formatに基づいて、削減モード及び非削減モードの何れか一方を設定してよい。

【0118】

例えば、DCI format 0_2と削減モードとが紐づけられ、DCI format 0_0及び0_1と非削減モードとが紐づけられてよい。例えば、DCI format 0_2は、URLLCサービスに対して使用されることが想定される。また、URLLCサービスは、例えば、LBT failureが起こりにくい環境（例えば、Controlled environmentのように他システムからの干渉が無い環境）における運用が想定される。このため、DCI format 0_2が使用された場合には、LBT failureが起こりにくい環境であると想定され、削減モードが設定されてよい。

【0119】

また、通知方法２では、通知方法１と比較して、PDCCHにおいて追加のパラメータが無くてよいため、シグナリングのオーバヘッドを低減できる。その一方で、通知方法１は、DCI formatに依らず、削減モードと非削減モードとを切替可能である点で有効である。

【0120】

このように、決定方法２では、例えば、PDCCHによってモードを変更できるため、決定方法１のようにsemi-staticなシグナリングを用いる方法と比較して、モードのより動的な変更が可能となる。

【0121】

＜決定方法３＞
決定方法３では、モードは、例えば、Configured grantのpriority（換言すると、優先度に関するパラメータ）に基づいて設定（換言すると、変更）されてよい。

【0122】

例えば、Configured grantにおいて、Configured grant設定毎に、priorityは、semi-staticに設定され得る。例えば、Release 16 NRでは、priorityには、High又はLowが設定される。また、priority（例えば、High又はLow）は、例えば、上位レイヤ信号（一例として、configuredGrantConfigにおけるpriority（例えば、High又はLow））によって端末２００に設定されてよい。

【0123】

priorityがHighの場合には、例えば、URLLCサービスの適用が想定され得る。また、上述したように、URLLCサービスは、例えば、LBT failureが起こりにくい環境（例えば、Controlled environmentのように他システムからの干渉が無い環境）における運用が想定される。そこで、例えば、端末２００は、priorityがHighの場合には削減モードを設定し、priorityがLowの場合には非削減モードを設定してよい。

【0124】

決定方法３によれば、追加のシグナリング無しでモードの切り替えが可能であるため、シグナリングのオーバヘッドを低減できる。

【0125】

＜決定方法４＞
決定方法４では、モードは、例えば、チャネルアクセス方式（例えば、FBE又はLBE）に関するパラメータに基づいて設定（換言すると、変更）されてよい。

【0126】

チャネルアクセス方式は、例えば、上位レイヤ信号（一例として、ChannelAccessMode-r16（例えば、semi-static又はdynamic））によって端末２００に設定されてよい。

【0127】

例えば、FBEモードでは、干渉となり得るシステムが存在すると効率的に動作できない場合があり得る。また、FBEモードでは、例えば、送信開始のタイミングが予め決められているため、他のシステムからの干渉が無い場合でも、端末２００は送信開始のタイミングまで送信を待機する可能性がある。このため、FBEモードでの動作時には、干渉となる他のシステムが存在しないと見なしてよいケースがあると想定することが可能である。

【0128】

その一方で、LBEモードは、例えば、FBEモードと比較すると、他のシステム等と共存しやすい。このため、LBEモードでの動作時には、例えば、他のシステムからの干渉を想定し得る。

【0129】

そこで、例えば、端末２００は、FBEモードが設定された場合には削減モードを設定し、LBEモードが設定された場合には非削減モードを設定してよい。

【0130】

決定方法３によれば、追加のシグナリング無しでモードの切り替えが可能であるため、シグナリングのオーバヘッドを低減できる。

【0131】

＜決定方法５＞
決定方法５では、モードは、例えば、MCSに関するパラメータに基づいて設定（換言すると、変更）されてよい。MCSに関するパラメータは、例えば、MCS table又はMCS indexでもよい。

【0132】

以下、決定方法５におけるモード決定の例について説明する。

【0133】

方法１：
モードは、例えば、GC-PUSCHのMCS tableに基づいて決定されてよい。

【0134】

PUSCH送信では、例えば、基地局１００（例えば、gNB）が送信に使用するMCS indexを端末２００（例えば、UE）が選択し、指示することにより、通信品質に応じた変調方式及び符号化率を選択可能にしている。その一方で、NRでは、例えば、URLLCのように他のサービスと比較して非常に高い信頼性が求められるユースケースも想定されている。そのため、NRでは、例えば、１つのMCS tableによって複数のユースケースをサポートするのではなく、ユースケース又は送信データに対応するサービスに応じて、複数のMCS tableの中から、使用されるMCS tableを変更可能に規定されている。

【0135】

なお、使用されるMCS tableは、例えば、RRC signaling、DCI format、又は、Radio Network Temporary Identifier（RNTI）によって端末２００へ設定（換言すると、通知）されてよい。

【0136】

端末２００は、例えば、高信頼性用のMCS table（換言すると、通常のMCS tableより低い符号化率をサポートしているMCS table）を使用する場合には削減モードを設定し、通常のMCS tableを使用する場合には非削減モードを設定してよい。

【0137】

これは、高信頼性用のMCS tableの使用時には、URLLCサービスのデータを送受信する場合が想定され、LBT failureが発生しにくい環境と想定されるためである。

【0138】

これにより、追加のシグナリング無しでモードの切り替えが可能であるため、シグナリングのオーバヘッドを低減できる。

【0139】

方法２：
モードは、例えば、GC-PUSCHのMCS indexに基づいて決定されてよい。

【0140】

なお、使用されるMCS indexは、例えば、RRC signaling、又は、PDCCHによって端末２００へ設定（換言すると、通知）されてよい。

【0141】

変調方式及び符号化率は、例えば、MCS indexに応じて決定される。例えば、MCS indexが低いほど、信頼性の高い変調方式及び符号化率の組み合わせが設定され得る。例えば、閾値より低いMCS indexを使用する場合と、URLLCサービスのデータを送受信する動作（例えば、削減モード）とを紐づけることにより、例えば、閾値より低いMCS indexが使用される場合には、LBT failureが発生しにくい環境と見なすことが可能である。

【0142】

そこで、端末２００は、例えば、MCS indexが低い場合（例えば、閾値以下の場合）に削減モードを設定し、MCS indexが高い場合（例えば、閾値より大きい場合）に非削減モードを設定してよい。

【0143】

なお、閾値は、例えば、シグナリングによって端末２００へ通知（換言すると、設定）されてよく、規格において規定されてもよい。また、閾値は、例えば、MCS table毎に設定されてもよい。

【0144】

これにより、追加のシグナリング無しでモードの切り替えが可能であるため、シグナリングのオーバヘッドを低減できる。

【0145】

なお、一例として、MCS indexと閾値との比較について説明したが、端末２００は、例えば、MCS indexに対応する符号化率と閾値との比較に基づいて、モードを設定してもよい。

【0146】

また、上述した方法１及び方法２を組み合わせてもよい。例えば、高信頼性用のMCS tableを使用する場合でも、より高いMCS indexでは、符号化率は高くなり得るため、これらの方法を組み合わせることにより、より細かい制御が可能となる。

【0147】

以上、決定方法１～決定方法５について説明した。

【0148】

本実施の形態では、端末２００は、アンライセンス周波数帯に関するパラメータに基づいて、CG-UCI（例えば、端末２００に設定されたリソース割り当てに関する上り制御情報）に含まれる情報を制御する。

【0149】

この制御により、例えば、CG-UCIのサイズ（例えば、ビット数）は、基地局１００と端末２００との間の無線伝搬環境に応じて異なり得る。例えば、削減モードにより、CG-UCIのサイズを低減しつつ、CG-UCIの信頼性を向上できる。その一方で、非削減モード（例えば、CG-UCIサイズの維持）により、LBT failureを想定した制御により、CG-UCIの信頼性を維持できる。よって、本実施の形態によれば、アンライセンス周波数帯（換言すると、免許不要帯域）において、上りリンク信号の信頼性を維持又は向上し、かつ、上りリンク信号の送信効率を向上できる。

【0150】

以上、本開示の一実施例について説明した。

【0151】

（他の実施の形態）
上述した実施の形態において、削減モードを適用する場合、例えば、パラメータ削減の代わりに、別のパラメータ（例えば、URLLC用のパラメータでもよい）を含めてもよい。換言すると、或るパラメータの削減分のビットが、別のパラメータに割り当てられてよい。例えば、別のパラメータとして、異なるUE又は異なるConfigured grant設定において同じリソース（例えば、時間領域、周波数領域、及び、DMRS設定の少なくとも一つ）を使用する場合に、ｇNBにおいて受信する際に分離しやすくするための情報が含まれてよい。この情報は、例えば、UE ID、又は、Configured grant設定IDでもよい。別のパラメータの追加により、例えば、基地局１００は、異なるUE又は異なるConfigured grant設定において同じリソースを使用する場合に、信号の分離精度を向上できるため、信頼性を向上できる。

【0152】

また、上述した実施の形態において、非削減モード時に、CG-UCIに、追加のパラメータを更に含めてもよい。追加のパラメータとして、例えば、上述したようなUE ID又はConfigured grant設定IDが含まれてもよい。例えば、CG-UCIに対して十分なリソースが存在する場合には、非削減モードの選択により、追加のパラメータによって、例えば、基地局１００は、異なるUE又は異なるConfigured grant設定において同じリソースを使用する場合に、信号の分離精度を向上できるため、信頼性を向上できる。

【0153】

また、上述した実施の形態において、CG-UCIのビット数の削減に限らず、例えば、高信頼性が求められる場合の処理方法と、高信頼性が求められない場合の処理方法とで、上述したモードの決定方法を切り替えてもよい。

【0154】

また、上述した実施の形態では、例えば、基地局１００から端末２００へ通知される、モードを明示的に示す情報、Configured grantのpriority、チャネルアクセス方式、又は、MCS index（又は、MCS table）といったパラメータに基づいて、モードが設定される場合について説明した。しかし、モードの設定に使用されるパラメータは、これらに限定されず、例えば、URLLCサービスにおいて設定され得る他のパラメータでもよく、LBT failure（換言すると、他のシステムからの干渉）の発生が想定される環境（又は、想定されない環境）において設定され得る他のパラメータでもよい。

【0155】

また、上記実施の形態において、上りデータチャネルは、PUSCHに限らず、他の名称の制御チャネルでもよい。

【0156】

また、上記の実施の形態それぞれは組み合わせて適用してもよい。

【0157】

＜５Ｇ ＮＲのシステムアーキテクチャおよびプロトコルスタック＞
３ＧＰＰは、１００ＧＨｚまでの周波数範囲で動作する新無線アクセス技術（ＮＲ）の開発を含む第５世代携帯電話技術（単に「５Ｇ」ともいう）の次のリリースに向けて作業を続けている。５Ｇ規格の初版は２０１７年の終わりに完成しており、これにより、５Ｇ ＮＲの規格に準拠した端末（例えば、スマートフォン）の試作および商用展開に移ることが可能である。

【0158】

例えば、システムアーキテクチャは、全体としては、ｇＮＢを備えるＮＧ－ＲＡＮ（Next Generation - Radio Access Network）を想定する。ｇＮＢは、ＮＧ無線アクセスのユーザプレーン（ＳＤＡＰ／ＰＤＣＰ／ＲＬＣ／ＭＡＣ／ＰＨＹ）および制御プレーン（ＲＲＣ）のプロトコルのＵＥ側の終端を提供する。ｇＮＢは、Ｘｎインタフェースによって互いに接続されている。また、ｇＮＢは、Next Generation（ＮＧ）インタフェースによってＮＧＣ（Next Generation Core）に、より具体的には、ＮＧ－ＣインタフェースによってＡＭＦ（Access and Mobility Management Function）（例えば、ＡＭＦを行う特定のコアエンティティ）に、また、ＮＧ－ＵインタフェースによってＵＰＦ（User Plane Function）（例えば、ＵＰＦを行う特定のコアエンティティ）に接続されている。ＮＧ－ＲＡＮアーキテクチャを図６に示す（例えば、3GPP TS 38.300 v15.6.0, section 4参照）。

【0159】

ＮＲのユーザプレーンのプロトコルスタック（例えば、3GPP TS 38.300, section 4.4.1参照）は、ｇＮＢにおいてネットワーク側で終端されるＰＤＣＰ（Packet Data Convergence Protocol（TS 38.300の第６．４節参照））サブレイヤ、ＲＬＣ（Radio Link Control（TS 38.300の第６．３節参照））サブレイヤ、およびＭＡＣ（Medium Access Control（TS 38.300の第６．２節参照））サブレイヤを含む。また、新たなアクセス層（ＡＳ：Access Stratum）のサブレイヤ（ＳＤＡＰ：Service Data Adaptation Protocol）がＰＤＣＰの上に導入されている（例えば、3GPP TS 38.300の第６．５節参照）。また、制御プレーンのプロトコルスタックがＮＲのために定義されている（例えば、TS 38.300, section 4.4.2参照）。レイヤ２の機能の概要がTS 38.300の第６節に記載されている。ＰＤＣＰサブレイヤ、ＲＬＣサブレイヤ、およびＭＡＣサブレイヤの機能は、それぞれ、TS 38.300の第６．４節、第６．３節、および第６．２節に列挙されている。ＲＲＣレイヤの機能は、TS 38.300の第７節に列挙されている。

【0160】

例えば、Medium-Access-Controlレイヤは、論理チャネル（logical channel）の多重化と、様々なニューメロロジーを扱うことを含むスケジューリングおよびスケジューリング関連の諸機能と、を扱う。

【0161】

例えば、物理レイヤ（ＰＨＹ）は、符号化、ＰＨＹ ＨＡＲＱ処理、変調、マルチアンテナ処理、および適切な物理的時間－周波数リソースへの信号のマッピングの役割を担う。また、物理レイヤは、物理チャネルへのトランスポートチャネルのマッピングを扱う。物理レイヤは、ＭＡＣレイヤにトランスポートチャネルの形でサービスを提供する。物理チャネルは、特定のトランスポートチャネルの送信に使用される時間周波数リソースのセットに対応し、各トランスポートチャネルは、対応する物理チャネルにマッピングされる。例えば、物理チャネルには、上り物理チャネルとして、ＰＲＡＣＨ（Physical Random Access Channel）、ＰＵＳＣＨ（Physical Uplink Shared Channel)、ＰＵＣＣＨ(Physical Uplink Control Channel)があり、下り物理チャネルとして、ＰＤＳＣＨ（Physical Downlink Shared Channel)、ＰＤＣＣＨ（Physical Downlink Control Channel)、ＰＢＣＨ(Physical Broadcast Channel) がある。

【0162】

ＮＲのユースケース／展開シナリオには、データレート、レイテンシ、およびカバレッジの点で多様な要件を有するenhanced mobile broadband（ｅＭＢＢ）、ultra-reliable low-latency communications（ＵＲＬＬＣ）、massive machine type communication（ｍＭＴＣ）が含まれ得る。例えば、ｅＭＢＢは、ＩＭＴ－Ａｄｖａｎｃｅｄが提供するデータレートの３倍程度のピークデータレート（下りリンクにおいて２０Ｇｂｐｓおよび上りリンクにおいて１０Ｇｂｐｓ）および実効（user-experienced）データレートをサポートすることが期待されている。一方、ＵＲＬＬＣの場合、より厳しい要件が超低レイテンシ（ユーザプレーンのレイテンシについてＵＬおよびＤＬのそれぞれで０．５ｍｓ）および高信頼性（１ｍｓ内において１－１０－５）について課されている。最後に、ｍＭＴＣでは、好ましくは高い接続密度（都市環境において装置１，０００，０００台／ｋｍ２）、悪環境における広いカバレッジ、および低価格の装置のための極めて寿命の長い電池（１５年）が求められうる。

【0163】

そのため、１つのユースケースに適したＯＦＤＭのニューメロロジー（例えば、サブキャリア間隔、ＯＦＤＭシンボル長、サイクリックプレフィックス（ＣＰ：Cyclic Prefix）長、スケジューリング区間毎のシンボル数）が他のユースケースには有効でない場合がある。例えば、低レイテンシのサービスでは、好ましくは、ｍＭＴＣのサービスよりもシンボル長が短いこと（したがって、サブキャリア間隔が大きいこと）および／またはスケジューリング区間（ＴＴＩともいう）毎のシンボル数が少ないことが求められうる。さらに、チャネルの遅延スプレッドが大きい展開シナリオでは、好ましくは、遅延スプレッドが短いシナリオよりもＣＰ長が長いことが求められうる。サブキャリア間隔は、同様のＣＰオーバヘッドが維持されるように状況に応じて最適化されてもよい。ＮＲがサポートするサブキャリア間隔の値は、１つ以上であってよい。これに対応して、現在、１５ｋＨｚ、３０ｋＨｚ、６０ｋＨｚ…のサブキャリア間隔が考えられている。シンボル長Ｔｕおよびサブキャリア間隔Δｆは、式Δｆ＝１／Ｔｕによって直接関係づけられている。ＬＴＥシステムと同様に、用語「リソースエレメント」を、１つのＯＦＤＭ／ＳＣ－ＦＤＭＡシンボルの長さに対する１つのサブキャリアから構成される最小のリソース単位を意味するように使用することができる。

【0164】

新無線システム５Ｇ－ＮＲでは、各ニューメロロジーおよび各キャリアについて、サブキャリアおよびＯＦＤＭシンボルのリソースグリッドが上りリンクおよび下りリンクのそれぞれに定義される。リソースグリッドの各エレメントは、リソースエレメントと呼ばれ、周波数領域の周波数インデックスおよび時間領域のシンボル位置に基づいて特定される（3GPP TS 38.211 v15.6.0参照）。

【0165】

＜５Ｇ ＮＲにおけるＮＧ－ＲＡＮと５ＧＣとの間の機能分離＞
図７は、ＮＧ－ＲＡＮと５ＧＣとの間の機能分離を示す。ＮＧ－ＲＡＮの論理ノードは、ｇＮＢまたはｎｇ－ｅＮＢである。５ＧＣは、論理ノードＡＭＦ、ＵＰＦ、およびＳＭＦを有する。

【0166】

例えば、ｇＮＢおよびｎｇ－ｅＮＢは、以下の主な機能をホストする：
－ 無線ベアラ制御（Radio Bearer Control）、無線アドミッション制御（Radio Admission Control）、接続モビリティ制御（Connection Mobility Control）、上りリンクおよび下りリンクの両方におけるリソースのＵＥへの動的割当（スケジューリング）等の無線リソース管理（Radio Resource Management）の機能；
－ データのＩＰヘッダ圧縮、暗号化、および完全性保護；
－ ＵＥが提供する情報からＡＭＦへのルーティングを決定することができない場合のＵＥのアタッチ時のＡＭＦの選択；
－ ＵＰＦに向けたユーザプレーンデータのルーティング；
－ ＡＭＦに向けた制御プレーン情報のルーティング；
－ 接続のセットアップおよび解除；
－ ページングメッセージのスケジューリングおよび送信；
－ システム報知情報（ＡＭＦまたは運用管理保守機能（ＯＡＭ：Operation, Admission, Maintenance）が発信源）のスケジューリングおよび送信；
－ モビリティおよびスケジューリングのための測定および測定報告の設定；
－ 上りリンクにおけるトランスポートレベルのパケットマーキング；
－ セッション管理；
－ ネットワークスライシングのサポート；
－ ＱｏＳフローの管理およびデータ無線ベアラに対するマッピング；
－ ＲＲＣ＿ＩＮＡＣＴＩＶＥ状態のＵＥのサポート；
－ ＮＡＳメッセージの配信機能；
－ 無線アクセスネットワークの共有；
－ デュアルコネクティビティ；
－ ＮＲとＥ－ＵＴＲＡとの緊密な連携。

【0167】

Access and Mobility Management Function（ＡＭＦ）は、以下の主な機能をホストする：
－ Non-Access Stratum（ＮＡＳ）シグナリングを終端させる機能；
－ ＮＡＳシグナリングのセキュリティ；
－ Access Stratum（ＡＳ）のセキュリティ制御；
－ ３ＧＰＰのアクセスネットワーク間でのモビリティのためのコアネットワーク（CN：Core Network）ノード間シグナリング；
－ アイドルモードのＵＥへの到達可能性（ページングの再送信の制御および実行を含む）；
－ 登録エリアの管理；
－ システム内モビリティおよびシステム間モビリティのサポート；
－ アクセス認証；
－ ローミング権限のチェックを含むアクセス承認；
－ モビリティ管理制御（加入およびポリシー）；
－ ネットワークスライシングのサポート；
－ Session Management Function（ＳＭＦ）の選択。

【0168】

さらに、User Plane Function（ＵＰＦ）は、以下の主な機能をホストする：
－ ｉｎｔｒａ－ＲＡＴモビリティ／ｉｎｔｅｒ－ＲＡＴモビリティ（適用可能な場合）のためのアンカーポイント；
－ データネットワークとの相互接続のための外部ＰＤＵ(Protocol Data Unit)セッションポイント；
－ パケットのルーティングおよび転送；
－ パケット検査およびユーザプレーン部分のポリシールールの強制（Policy rule enforcement）；
－ トラフィック使用量の報告；
－ データネットワークへのトラフィックフローのルーティングをサポートするための上りリンククラス分類（uplink classifier）；
－ マルチホームＰＤＵセッション（multi-homed PDU session）をサポートするための分岐点(Branching Point)；
－ ユーザプレーンに対するＱｏＳ処理（例えば、パケットフィルタリング、ゲーティング（gating）、ＵＬ／ＤＬレート制御（UL/DL rate enforcement）；
－ 上りリンクトラフィックの検証（ＳＤＦのＱｏＳフローに対するマッピング）；
－ 下りリンクパケットのバッファリングおよび下りリンクデータ通知のトリガ機能。

【0169】

最後に、Session Management Function（ＳＭＦ）は、以下の主な機能をホストする：
－ セッション管理；
－ ＵＥに対するＩＰアドレスの割当および管理；
－ ＵＰＦの選択および制御；
－ 適切な宛先にトラフィックをルーティングするためのUser Plane Function（ＵＰＦ）におけるトラフィックステアリング（traffic steering）の設定機能；
－ 制御部分のポリシーの強制およびＱｏＳ；
－ 下りリンクデータの通知。

【0170】

＜ＲＲＣ接続のセットアップおよび再設定の手順＞
図８は、ＮＡＳ部分の、ＵＥがRRC_IDLEからRRC_CONNECTEDに移行する際のＵＥ、ｇＮＢ、およびＡＭＦ（５ＧＣエンティティ）の間のやり取りのいくつかを示す（TS 38.300 v15.6.0参照）。

【0171】

ＲＲＣは、ＵＥおよびｇＮＢの設定に使用される上位レイヤのシグナリング（プロトコル）である。この移行により、ＡＭＦは、ＵＥコンテキストデータ（これは、例えば、ＰＤＵセッションコンテキスト、セキュリティキー、ＵＥ無線性能（UE Radio Capability）、ＵＥセキュリティ性能（UE Security Capabilities）等を含む）を用意し、初期コンテキストセットアップ要求（INITIAL CONTEXT SETUP REQUEST）とともにｇＮＢに送る。そして、ｇＮＢは、ＵＥと一緒に、ＡＳセキュリティをアクティブにする。これは、ｇＮＢがＵＥにSecurityModeCommandメッセージを送信し、ＵＥがSecurityModeCompleteメッセージでｇＮＢに応答することによって行われる。その後、ｇＮＢは、ＵＥにRRCReconfigurationメッセージを送信し、これに対するＵＥからのRRCReconfigurationCompleteをｇＮＢが受信することによって、Signaling Radio Bearer 2（ＳＲＢ２）およびData Radio Bearer（ＤＲＢ）をセットアップするための再設定を行う。シグナリングのみの接続については、ＳＲＢ２およびＤＲＢがセットアップされないため、RRCReconfigurationに関するステップは省かれる。最後に、ｇＮＢは、初期コンテキストセットアップ応答（INITIAL CONTEXT SETUP RESPONSE）でセットアップ手順が完了したことをＡＭＦに通知する。

【0172】

したがって、本開示では、ｇＮｏｄｅＢとのNext Generation（ＮＧ）接続を動作時に確立する制御回路と、ｇＮｏｄｅＢとユーザ機器（ＵＥ：User Equipment）との間のシグナリング無線ベアラがセットアップされるように動作時にＮＧ接続を介してｇＮｏｄｅＢに初期コンテキストセットアップメッセージを送信する送信部と、を備える、5th Generation Core（５ＧＣ）のエンティティ（例えば、ＡＭＦ、ＳＭＦ等）が提供される。具体的には、ｇＮｏｄｅＢは、リソース割当設定情報要素(IE: Information Element)を含むRadio Resource Control（ＲＲＣ）シグナリングを、シグナリング無線ベアラを介してＵＥに送信する。そして、ＵＥは、リソース割当設定に基づき上りリンクにおける送信または下りリンクにおける受信を行う。

【0173】

＜２０２０年以降のＩＭＴの利用シナリオ＞
図９は、５Ｇ ＮＲのためのユースケースのいくつかを示す。3rd generation partnership project new radio（３ＧＰＰ ＮＲ）では、多種多様なサービスおよびアプリケーションをサポートすることがＩＭＴ－２０２０によって構想されていた３つのユースケースが検討されている。大容量・高速通信（ｅＭＢＢ：enhanced mobile-broadband）のための第一段階の仕様の策定が終了している。現在および将来の作業には、ｅＭＢＢのサポートを拡充していくことに加えて、高信頼・超低遅延通信（ＵＲＬＬＣ：ultra-reliable and low-latency communications）および多数同時接続マシンタイプ通信（ｍＭＴＣ：massive machine-type communicationsのための標準化が含まれる。図９は、２０２０年以降のＩＭＴの構想上の利用シナリオのいくつかの例を示す（例えばＩＴＵ－Ｒ Ｍ．２０８３ 図２参照）。

【0174】

ＵＲＬＬＣのユースケースには、スループット、レイテンシ（遅延）、および可用性のような性能についての厳格な要件がある。ＵＲＬＬＣのユースケースは、工業生産プロセスまたは製造プロセスのワイヤレス制御、遠隔医療手術、スマートグリッドにおける送配電の自動化、交通安全等の今後のこれらのアプリケーションを実現するための要素技術の１つとして構想されている。ＵＲＬＬＣの超高信頼性は、TR 38.913によって設定された要件を満たす技術を特定することによってサポートされる。リリース１５におけるＮＲ ＵＲＬＬＣでは、重要な要件として、目標とするユーザプレーンのレイテンシがＵＬ（上りリンク）で０．５ｍｓ、ＤＬ（下りリンク）で０．５ｍｓであることが含まれている。一度のパケット送信に対する全般的なＵＲＬＬＣの要件は、ユーザプレーンのレイテンシが１ｍｓの場合、３２バイトのパケットサイズに対してブロック誤り率（ＢＬＥＲ：block error rate）が１Ｅ－５であることである。

【0175】

物理レイヤの観点では、信頼性は、多くの採り得る方法で向上可能である。現在の信頼性向上の余地としては、ＵＲＬＬＣ用の別個のＣＱＩ表、よりコンパクトなＤＣＩフォーマット、ＰＤＣＣＨの繰り返し等を定義することが含まれる。しかしながら、この余地は、ＮＲが（ＮＲ ＵＲＬＬＣの重要要件に関し）より安定しかつより開発されるにつれて、超高信頼性の実現のために広がりうる。リリース１５におけるＮＲ ＵＲＬＬＣの具体的なユースケースには、拡張現実／仮想現実（ＡＲ／ＶＲ）、ｅ－ヘルス、ｅ－セイフティ、およびミッションクリティカルなアプリケーションが含まれる。

【0176】

また、ＮＲ ＵＲＬＬＣが目標とする技術強化は、レイテンシの改善および信頼性の向上を目指している。レイテンシの改善のための技術強化には、設定可能なニューメロロジー、フレキシブルなマッピングによる非スロットベースのスケジューリング、グラントフリーの（設定されたグラントの）上りリンク、データチャネルにおけるスロットレベルでの繰り返し、および下りリンクでのプリエンプション（Pre-emption）が含まれる。プリエンプションとは、リソースが既に割り当てられた送信が停止され、当該既に割り当てられたリソースが、後から要求されたより低いレイテンシ／より高い優先度の要件の他の送信に使用されることを意味する。したがって、既に許可されていた送信は、後の送信によって差し替えられる。プリエンプションは、具体的なサービスタイプと無関係に適用可能である。例えば、サービスタイプＡ（ＵＲＬＬＣ）の送信が、サービスタイプＢ（ｅＭＢＢ等）の送信によって差し替えられてもよい。信頼性向上についての技術強化には、１Ｅ－５の目標ＢＬＥＲのための専用のＣＱＩ／ＭＣＳ表が含まれる。

【0177】

ｍＭＴＣ（massive machine type communication）のユースケースの特徴は、典型的には遅延の影響を受けにくい比較的少量のデータを送信する接続装置の数が極めて多いことである。装置には、低価格であること、および電池寿命が非常に長いことが要求される。ＮＲの観点からは、非常に狭い帯域幅部分を利用することが、ＵＥから見て電力が節約されかつ電池の長寿命化を可能にする１つの解決法である。

【0178】

上述のように、ＮＲにおける信頼性向上のスコープはより広くなることが予測される。あらゆるケースにとっての重要要件の１つであって、例えばＵＲＬＬＣおよびｍＭＴＣについての重要要件が高信頼性または超高信頼性である。いくつかのメカニズムが信頼性を無線の観点およびネットワークの観点から向上させることができる。概して、信頼性の向上に役立つ可能性がある２つ～３つの重要な領域が存在する。これらの領域には、コンパクトな制御チャネル情報、データチャネル/制御チャネルの繰り返し、および周波数領域、時間領域、および／または空間領域に関するダイバーシティがある。これらの領域は、特定の通信シナリオにかかわらず一般に信頼性向上に適用可能である。

【0179】

ＮＲ ＵＲＬＬＣに関し、ファクトリーオートメーション、運送業、および電力の分配のような、要件がより厳しいさらなるユースケースが想定されている。厳しい要件とは、高い信頼性（１０－６レベルまでの信頼性）、高い可用性、２５６バイトまでのパケットサイズ、数μｓ程度までの時刻同期（time synchronization）（ユースケースに応じて、値を、周波数範囲および０．５ｍｓ～１ｍｓ程度の短いレイテンシ（例えば、目標とするユーザプレーンでの０．５ｍｓのレイテンシ）に応じて１μｓまたは数μｓとすることができる）である。

【0180】

さらに、ＮＲ ＵＲＬＬＣについては、物理レイヤの観点からいくつかの技術強化が有り得る。これらの技術強化には、コンパクトなＤＣＩに関するＰＤＣＣＨ（Physical Downlink Control Channel）の強化、ＰＤＣＣＨの繰り返し、ＰＤＣＣＨのモニタリングの増加がある。また、ＵＣＩ（Uplink Control Information）の強化は、ｅｎｈａｎｃｅｄ ＨＡＲＱ（Hybrid Automatic Repeat Request）およびＣＳＩフィードバックの強化に関係する。また、ミニスロットレベルのホッピングに関係するＰＵＳＣＨの強化、および再送信／繰り返しの強化が有り得る。用語「ミニスロット」は、スロットより少数のシンボルを含むTransmission Time Interval（ＴＴＩ）を指す（スロットは、１４個のシンボルを備える）。

【0181】

＜ＱｏＳ制御＞
５ＧのＱｏＳ（Quality of Service）モデルは、ＱｏＳフローに基づいており、保証されたフロービットレートが求められるＱｏＳフロー（GBR：Guaranteed Bit Rate ＱｏＳフロー）、および、保証されたフロービットレートが求められないＱｏＳフロー（非ＧＢＲ ＱｏＳフロー）をいずれもサポートする。したがって、ＮＡＳレベルでは、ＱｏＳフローは、ＰＤＵセッションにおける最も微細な粒度のＱｏＳの区分である。ＱｏＳフローは、ＮＧ－Ｕインタフェースを介してカプセル化ヘッダ（encapsulation header）において搬送されるＱｏＳフローＩＤ（ＱＦＩ：QoS Flow ID）によってＰＤＵセッション内で特定される。

【0182】

各ＵＥについて、５ＧＣは、１つ以上のＰＤＵセッションを確立する。各ＵＥについて、ＰＤＵセッションに合わせて、ＮＧ－ＲＡＮは、例えば図８を参照して上に示したように少なくとも１つのData Radio Bearers（ＤＲＢ）を確立する。また、そのＰＤＵセッションのＱｏＳフローに対する追加のＤＲＢが後から設定可能である（いつ設定するかはＮＧ－ＲＡＮ次第である）。ＮＧ－ＲＡＮは、様々なＰＤＵセッションに属するパケットを様々なＤＲＢにマッピングする。ＵＥおよび５ＧＣにおけるＮＡＳレベルパケットフィルタが、ＵＬパケットおよびＤＬパケットとＱｏＳフローとを関連付けるのに対し、ＵＥおよびＮＧ－ＲＡＮにおけるＡＳレベルマッピングルールは、ＵＬ ＱｏＳフローおよびＤＬ ＱｏＳフローとＤＲＢとを関連付ける。

【0183】

図１０は、５Ｇ ＮＲの非ローミング参照アーキテクチャ（non-roaming reference architecture）を示す（TS 23.501 v16.1.0, section 4.23参照）。Application Function（ＡＦ）（例えば、図９に例示した、５Ｇのサービスをホストする外部アプリケーションサーバ）は、サービスを提供するために３ＧＰＰコアネットワークとやり取りを行う。例えば、トラフィックのルーティングに影響を与えるアプリケーションをサポートするために、Network Exposure Function（ＮＥＦ）にアクセスすること、またはポリシー制御（例えば、ＱｏＳ制御）のためにポリシーフレームワークとやり取りすること（Policy Control Function（ＰＣＦ）参照）である。オペレーターによる配備に基づいて、オペレーターによって信頼されていると考えられるApplication Functionは、関連するNetwork Functionと直接やり取りすることができる。Network Functionに直接アクセスすることがオペレーターから許可されていないApplication Functionは、ＮＥＦを介することにより外部に対する解放フレームワークを使用して関連するNetwork Functionとやり取りする。

【0184】

図１０は、５Ｇアーキテクチャのさらなる機能単位、すなわち、Network Slice Selection Function（ＮＳＳＦ）、Network Repository Function（ＮＲＦ）、Unified Data Management（ＵＤＭ）、Authentication Server Function（ＡＵＳＦ）、Access and Mobility Management Function（ＡＭＦ）、Session Management Function（ＳＭＦ）、およびData Network（ＤＮ、例えば、オペレーターによるサービス、インターネットアクセス、またはサードパーティーによるサービス）をさらに示す。コアネットワークの機能およびアプリケーションサービスの全部または一部がクラウドコンピューティング環境において展開されかつ動作してもよい。

【0185】

したがって、本開示では、ＱｏＳ要件に応じたｇＮｏｄｅＢとＵＥとの間の無線ベアラを含むＰＤＵセッションを確立するために、動作時に、ＵＲＬＬＣサービス、ｅＭＭＢサービス、およびｍＭＴＣサービスの少なくとも１つに対するＱｏＳ要件を含む要求を５ＧＣの機能（例えば、ＮＥＦ、ＡＭＦ、ＳＭＦ、ＰＣＦ、ＵＰＦ等）の少なくとも１つに送信する送信部と、動作時に、確立されたＰＤＵセッションを使用してサービスを行う制御回路と、を備える、アプリケーションサーバ（例えば、５ＧアーキテクチャのＡＦ）が提供される。

【0186】

本開示はソフトウェア、ハードウェア、又は、ハードウェアと連携したソフトウェアで実現することが可能である。上記実施の形態の説明に用いた各機能ブロックは、部分的に又は全体的に、集積回路であるＬＳＩとして実現され、上記実施の形態で説明した各プロセスは、部分的に又は全体的に、一つのＬＳＩ又はＬＳＩの組み合わせによって制御されてもよい。ＬＳＩは個々のチップから構成されてもよいし、機能ブロックの一部または全てを含むように一つのチップから構成されてもよい。ＬＳＩはデータの入力と出力を備えてもよい。ＬＳＩは、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。

【0187】

集積回路化の手法はＬＳＩに限るものではなく、専用回路、汎用プロセッサ又は専用プロセッサで実現してもよい。また、ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。本開示は、デジタル処理又はアナログ処理として実現されてもよい。

【0188】

さらには、半導体技術の進歩または派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。

【0189】

本開示は、通信機能を持つあらゆる種類の装置、デバイス、システム（通信装置と総称）において実施可能である。通信装置は無線送受信機（トランシーバー）と処理／制御回路を含んでもよい。無線送受信機は受信部と送信部、またはそれらを機能として、含んでもよい。無線送受信機（送信部、受信部）は、ＲＦ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ）モジュールと１または複数のアンテナを含んでもよい。ＲＦモジュールは、増幅器、ＲＦ変調器／復調器、またはそれらに類するものを含んでもよい。通信装置の、非限定的な例としては、電話機（携帯電話、スマートフォン等）、タブレット、パーソナル・コンピューター（ＰＣ）（ラップトップ、デスクトップ、ノートブック等）、カメラ（デジタル・スチル／ビデオ・カメラ等）、デジタル・プレーヤー（デジタル・オーディオ／ビデオ・プレーヤー等）、着用可能なデバイス（ウェアラブル・カメラ、スマートウオッチ、トラッキングデバイス等）、ゲーム・コンソール、デジタル・ブック・リーダー、テレヘルス・テレメディシン（遠隔ヘルスケア・メディシン処方）デバイス、通信機能付きの乗り物又は移動輸送機関（自動車、飛行機、船等）、及び上述の各種装置の組み合わせがあげられる。

【0190】

通信装置は、持ち運び可能又は移動可能なものに限定されず、持ち運びできない又は固定されている、あらゆる種類の装置、デバイス、システム、例えば、スマート・ホーム・デバイス（家電機器、照明機器、スマートメーター又は計測機器、コントロール・パネル等）、自動販売機、その他ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）ネットワーク上に存在し得るあらゆる「モノ（Things）」をも含む。

【0191】

通信には、セルラーシステム、無線ＬＡＮシステム、通信衛星システム等によるデータ通信に加え、これらの組み合わせによるデータ通信も含まれる。

【0192】

また、通信装置には、本開示に記載される通信機能を実行する通信デバイスに接続又は連結される、コントローラやセンサー等のデバイスも含まれる。例えば、通信装置の通信機能を実行する通信デバイスが使用する制御信号やデータ信号を生成するような、コントローラやセンサーが含まれる。

【0193】

また、通信装置には、上記の非限定的な各種装置と通信を行う、あるいはこれら各種装置を制御する、インフラストラクチャ設備、例えば、基地局、アクセスポイント、その他あらゆる装置、デバイス、システムが含まれる。

【0194】

本開示の一実施例に係る端末は、免許不要帯に関するパラメータを受信する受信回路と、前記パラメータに基づいて、上り制御情報に含める情報を決定する制御回路と、を具備する。

【0195】

本開示の一実施例において、前記制御回路は、再送制御に関する情報を含む前記上り制御情報を送信する第１のモード、及び、前記再送制御に関する情報の少なくとも一部を含まない前記上り制御情報を送信する第２のモードのうち何れかを設定する。

【0196】

本開示の一実施例において、前記パラメータは、前記第１のモード及び前記第２のモードの何れかを示す。

【0197】

本開示の一実施例において、前記受信回路は、前記パラメータを含む準静的な制御信号を受信する。

【0198】

本開示の一実施例において、前記受信回路は、前記パラメータを含む動的な制御信号を受信する。

【0199】

本開示の一実施例において、前記パラメータは、前記端末に設定されたリソース割り当ての設定における優先度に関するパラメータである。

【0200】

本開示の一実施例において、前記パラメータは、チャネルアクセス方式に関するパラメータである。

【0201】

本開示の一実施例において、前記パラメータは、符号化変調方式に関するパラメータである。

【0202】

本開示の一実施例において、前記パラメータは、controlled environmentであるか否かを示すパラメータである。

【0203】

本開示の一実施例に係る通信方法において、端末は、免許不要帯に関するパラメータを受信し、前記パラメータに基づいて、上り制御情報に含める情報を決定する。

【0204】

２０２０年２月１３日出願の特願２０２０－０２２２９７の日本出願に含まれる明細書、図面および要約書の開示内容は、すべて本願に援用される。

【産業上の利用可能性】

【0205】

本開示の一実施例は、無線通信システムに有用である。

【符号の説明】

【0206】

１００ 基地局
１０１，２０１ 受信部
１０２ 分離部
１０３ 制御情報復調・復号部
１０４ データ復調・復号部
１０５ スケジューリング部
１０６，２０３ 制御情報保持部
１０７ データ・制御情報生成部
１０８ 符号化・変調部
１０９，２０８ 送信部
２００ 端末
２０２ 復調・復号部
２０４ 送信制御部
２０５ データ生成部
２０６ 制御情報生成部
２０７ 符号化・変調・多重部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】