目录

1.长、短PUCCH格式的引入

高可靠性

高灵活性

高效率

2.短PUCCH结构设计

1符号PUCCH设计

2符号PUCCH设计

3.长PUCCH结构设计

3.PUCCH资源分配

4.PUCCH与其他上行信道冲突解决


1.长、短PUCCH格式的引入

NR采用灵活的资源分配方式,包括:

  • 灵活的ACK/NACK反馈
  • 灵活的额TDD上下行配置
  • 灵活的时频域物理资源分配等

另外NR系统中支持多种业务类型,不同业务类型的时延要求、不同的可靠性要求。因此,NR PUCCH设计需要满足如下要求

高可靠性

在 FR1(频率范围1,即小于6GHz)频谱上,NR PUCCH的覆盖应与LTE PUCCH的相同。LTE PUCCH格式1、格式1a、格式1b在频域上占用一个PRB,在时域上占用14个OFDM符号,码域上使用CAZAC序列。由于LTE PUCCH自身具有较高的可靠性,NR PUCCH需要较多的时域符号以实现与其类似的覆盖。

在FR2(频率范围2,即大于6GHz)频谱上,NR系统设计不需要受限于LTE的覆盖要求。但由于FR2自身的传输特性(较大的传播/穿透损耗,较大的相位噪声、较低的功率谱密度等),NR PUCCH也需要使用较多符号以提供足够的覆盖。

高灵活性

当信道条件较好,上行覆盖不受限时,使用较少的时域资源传输PUCCH

  • 一方面可以降低PUCCH占用的物理资源数量
  • 另一方面能够充分利用系统中时域资源碎片,从而提高系统效率
  • 另外,对URLLC业务,传输信道的时长也不能太长,否则讲将无法满足其短时延的性能需求。

高效率

在LTE系统中,ACK/NACK复用传输只用于TDD系统或FDD载波聚合系统。从系统的角度来看,多个PDSCH对应的ACK/NACK信息通过一个PUCCH复用传输,上行传输效率较高。在NR系统中,由于引入了灵活的ACK/NACK反馈时延,对TDD载波和FDD载波ACK/NACK复用传输的情况都会出现。进一步得,对不同上行时隙,其承载的有效ACK/NACK负载差异可能很大。根据实际的负载调整PUCCH的传输时长,在保证其覆盖的前提下,也有利于提高洗头膏效率。

NR系统为了兼顾高可靠性、高灵活性、高效率,在RAN1#86bis会议上确定支持两种PUCCH类型,即长PUCCH和短PUCCH。

2.短PUCCH结构设计

针对短PUCCH设计首先需要确定的是其支持的时域长度。2017 年1月RAN1#AH_NR会议中讨论了两种方案:只支持1符号长度和支持多于1符号的长度。若短PUCCH只支持1符号长度,则存在的主要问题是短PUCCH与长PUCCH的覆盖差异较大,影响系统效率。后经讨论确定NR短PUCCH的时域长度可以配置为1符号或2符号。时域长度确定之后,3GPP RAN1#88次会议上,提出了如下短PUCCH结构设计方案。

方案1

RS(参考信号)与UCI(上行控制信息)在每个时域符号内通过FDM方式复用。

方案2

RS与UCI通过TDM方式复用

方案3

RS与UCI在一个时域符号内通过FDM方式复用,而其他时域符号上只映射UCI

方案4

对于小负载情况,使用序列传输方式,不使用RS

方案5

对于小负载情况,使用序列传输方式且使用RS。

方案6:RS与UCI通过pre-DFT方式复用
最为灵活可用于1符号或2符号PUCCH。通过调整频域资源分配可承载较多比特的UCI信息,且可实现不同的编码速率,但该方案仅适用于CP-OFDM波形,PAPR较高 方案2、3可以认为是对方案1的扩展,但都受限应用于2符号PUCCH。方案2、3采用前置RS的目的是降低解调时延,但是由于2符号PUCCH自身时长很短,因此采用前置RS带来的时延增益并不明显。由于方案2、3的信道结构无法适用于单符号PUCCH,若采用方案2、3会导致标准复杂,即需要针对不同的PUCCH时长定义不同的结构。 方案4、5使用序列,好处在于PAPR低且可提供多用户间的复用能力,但缺点为承载的UCI容量受限。
方案2能在相同RS开销下实现单载波传输 方案3可以降低RS开销。
从检测性能来看,针对不同的场景,方案1与方案4可分别得到最优检测性能,而方案1与方案6的性能基本相当,但方案6的实现较为复杂。

方案6:RS与UCI通过pre-DFT方式复用,如图所示

随着讨论的推进,针对短PUCCH结构的讨论逐步分化为1符号PUCCH设计,2符号PUCCH设计。最早达成的结论是

1符号PUCCH设计

承载2bit以上UCI的1符号PUCCH 承载1-2bit UCI的1符号PUCCH
采用方案1的结构(3GPP RAN1#88bis次会议上) 在RAN1#90次会议上采用方案4的结构
并在随后的RAN1会议上确定RS开销为1/3,占用的PRB数量可配置。 使用12长ZC序列。
PUCCH格式2 PUCCH格式0

2符号PUCCH设计

2符号PUCCH设计,考虑了如下两种设计原则。

方法1:2符号PUCCH由两个1符号PUCCH组成,两个符号传输相同的UCI

  • 方法1-1:UCI信息在两个符号上重复传输。
  • 方法1-2:UCI信息经编码后分布于两个符号上传输

方法2:两个符号上分别传输不同的UCI(等效于独立传输两个1符号PUCCH,时延敏感UCI(如ACK/NACK)通过第二个符号传输,以获得更长的UCI准备时间。

方法2等效于独立传输两个1符号PUCCH,因此 没必要单独定义成为一个PUCCH格式。

承载2bit以上UCI的1符号PUCCH 承载1-2bit UCI的1符号PUCCH
每个符号上的RS结构与1符号PUCCH相同,但UCI信息编码后映射到两个符号上传输(RAN1#AH3) 最终RAN1#89次会议确定使用方法1-1,即在两符号上分别传输12长ZC序列且承载相同的UCI信息。
并在随后的RAN1会议上确定RS开销为1/3,占用的PRB数量可配置。
PUCCH格式2 PUCCH格式0

在3GPP协议中,承载1-2比特UCI的短PUCCH称为PUCCH格式0,承载2比特以上UCI的短PUCCH称为PUCCH格式2.PUCCH格式0使用12位长序列的不同循环移位表征ACK或NACK信息,如下表所示。

                            1bit ACK/NACK信息与PUCCH格式0循环移位映射关系

HARQ-ACK Value

0NACK

1ACK

Sequence cyclic shift序列循环移位

                             2bit ACK/NACK信息与PUCCH格式0循环移位映射关系

HARQ-ACK Value

{0, 0}

{0, 1}

{1, 1}

{1, 0}

Sequence cyclic shift

                        

PUCCH格式2频域上可使用1~16个PRB

PUCCH格式2结构示意图

3.长PUCCH结构设计

NR支持长PUCCH的目的:保证上行控制信道有较好的覆盖。

因此,3GPP 在讨论长PUCCH设计的最初阶段就定下了一个原则,即要求长PUCCH具有低PAPR/CM。同时,为了在时域上积累更多的能量,长PUCCH还可以在多个时隙上重复传输,而NR短PUCCH是不支持多时隙传输的,另外,为了承载不同的UCI负载,以及满足不同的覆盖需求,在一个时隙内,若长PUCCH支持多种时域长度,则能够有效地提高上行频谱效率,如下图所示。经讨论,RAN1#88bis次会议确定长PUCCH的时域长度为4~14个符号。在进行具体的PUCCH结构设计时,需要考虑PUCCH的结构具有可伸缩性,避免引入过多的PUCCH格式,即一种PUCCH格式可以应用于不同的时域符号长度。

为了满足长PUCCH低PAPR的设计原则,两种直观的设计如下所述。

  • 使用类似LTE PUCCH格式1a,格式1b的结构,即频域上使用ZC序列,在时域上OCC序列,RS与UCI映射到不同的时域符号上。
  • 使用类似LTE PUSCH结构,RS与UCI映射到不同的时域符号上,采用DFT-S-OFDM波形

第一种结构使用序列,因此只能适用于负载比较小的情况,但检测性能好,且支持多用户复用,对于1~2比特 UCI负载场景来说是最优的信道结构。

第二种结构结合信道编码,可承载较大量UCI信息。如前所述,PUCCH设计的需求是大覆盖和大容量,但是从一个终端的角度来看,这两项需求又不一定需要同时满足。

  • 对于UCI负载中等但上行功率受限的场景,合理的做法是降低频域资源数量,使用更多的时域资源。此时若能够支持多用户复用,则更有利于提高系统效率。
  • 对于UCI负载较大的场景,则势必需要使用更多的物理资源(时域、频域)传输UCI。

NR系统最终支持3中长PUCCH格式,即PUCCH格式1、格式3、格式4,分别适用于上述三种应用场景,如下表

时域符号数量 UCI负载 频域资源块数量 多用户复用能力
PUCCH格式1 4~14 1~2bit 1个PRB

频域12长ZC序列;

时域OCC扩频,扩频系数为2~7

PUCCH格式3 2bit以上 1~16个PRB,数量满足2、3、5幂次方的乘积 不支持
PUCCH格式4 2bit以上 1个PRB 频域OCC扩频,扩频系数为2或4

信道结构设计的另外一个主要问题为RS图案。对于PUCCH格式1,在标准化讨论过程中出现过如下两种方案。

  • 方案1:类似于LTE PUCCH格式1、格式1a,格式1b,RS占用PUCCH中间连续多个符号
  • 方案2:RS与UCI间隔分布

PUCCH格式1RS图案示意图

RS开销相同的时候,低速场景方案1和方案2的性能基本相同。但是高速场景中,方案2的性能要优于方案1.因此,NR PUCCH格式1采用RS与UCI间隔分布的图案,且RS占用偶数位符号上(符号索引从0开始),即前置RS,有利于降低译码时延。

PUCCH格式1的跳频图案中两个跳频部分包括的时域符号尽量均匀。PUCCH时域长度为奇数时,第二跳频部分比第一个跳频部分多一个时域符号。

2017年6月的RAN1#AH2会议中,对于PUCCH格式3、格式4提出如下两种RS图案方案

方案1:每个跳频部分中包括1列RS,RS位于每个跳频部分的中间

方案2:每个跳频部分中包括1列或2列RS。

虽然RS越多,信道估计准确度越高,但是相应的传输UCI的物理资源数量也会减少,导致UCI的编码速率上升。要想得到最优的检测性能,需要综合考虑信道条件,PUCCH时域长度和UCI负载。经多次讨论后,NR系统确定基站可通过高层配置上行信道(适用于PUSCH和PUCCH)是否使用额外RS(Addiction DM-RS)。未配置额外RS时,PUCCH格式3、格式4每个跳频部分中包括一列RS。配置额外RS时,若每个跳频部分包括的时域符号数量不大于5,则包括1列RS,若每个跳频部分包括的时域符号数量大于或等于5,则包括3列RS。

3.PUCCH资源分配

LTE系统在未引入载波聚合之前,传输动态调度PDSCH对应的ACK/NACK信息的PUCCH格式1a、格式1b的资源,是根据调度PDSCH的DCI占用的CCE计算得到的。引入载波聚合之后,传输动态调度PDSCH对应的ACK/NACK信息的PUCCH格式3、格式4、格式5的资源则采用了半静态配置加DCI动态指示的方式分配。在NR设计较早阶段就确定了沿用LTE的工作机制指示传输ACK/NACK信息的PUCCH,即首先由高层信令配置PUCCH资源集,然后由DCI指示资源集中的一个PUCCH。

在标准化讨论过程中,关于如何配置PUCCH资源集合提出了如下方案。

方案1:配置K个PUCCH资源集合,每个资源集合用来承载的UCI比特范围不同。每个集合中可以包括相同或不同的PUCCH格式。根据待传输的UCI比特数从K个资源集合中确定一个资源集合。然后根据DCI的指示从该集合中确定一个PUCCH资源。

方案2:针对每种PUCCH格式配置1个或多个PUCCH资源集合。

方案2-1:每种PUCCH格式配置多个资源集 方案2-2:多个资源集分为两组,第一组用于承载1~2bit UCI,第二组用于承载2bit以上UCI。 方案2-3:每种PUCCH格式配置一个资源集。 方案2-4:配置两个PUCCH资源集,分别包括短PUCCH和长PUCCH
方案1的好处在于,由于资源集中同时包括短PUCCH和长PUCCH。因此可以实现长短PUCCH格式的动态切换。半静态配置的长、短PUCCH资源数量可以不均匀,这给基站配置提供了更多灵活性 首先,通过MAC CE指示每一组内的一个资源集,得到两个资源集,其次,根据待传输UCI比特数确定一个资源集。最后根据DCI从资源集中确定一个PUCCH资源。 对短PUCCH,重用LTE PUCCH格式1a、格式1b根据DCI占用的资源隐式确定PUCCH资源的方法。 设置短PUCCH资源集承载的UCI比特上限(如100bit),根据待传输UCI比特数从两个资源集中选择一个

以DCI中包括3bit PUCCH的指示信息为例

方案1 方案2-1
一个PUCCH集合中包括8个PUCCH资源,基站可任意配置其中长PUCCH和短PUCCH的数量。 首先DCI中需要1bit指示使用长PUCCH还是短PUCCH,然后剩余的2bit指示一个集合内的资源,即长PUCCH和短PUCCH集合都分别包含4个PUCCH资源。
可针对不同的UCI负载区间分别配置资源集,能够配置总量更多的资源,给调度带来更大的灵活性
经过讨论后,NR PUCCH资源分配采用方案1.通过高层信令可配置最多4个PUCCH资源集合,其中资源集合0用于承载1-2bit UCI,资源集合1,2对应的负载范围通过高层信令配置,而资源3的最大负载为1706 bit,该数值来自Polar编码的限制。

另外,由公司提出在实际系统中大量的UE需要同时反馈1bit或2 bit的ACK/NACK信息,若DCI中PUCCH指示信息域为2bit,即每个终端只能有4个备选的PUCCH资源传输1bit或2 bit的ACK/NACK,则系统中资源冲突问题会比较严重。因此,建议考虑在DCI指示基础上,使用隐式的资源指示方法,扩展备选PUCCH资源数量。可选方案包括:

  • 方案1:根据CCE索引确定PUCCH资源
  • 方案2:根据RBG索引确定PUCCH资源
  • 方案3:根据TPC隐式确定PUCCH资源
  • 方案4:根据CORESET或Search Space隐式确定PUCCH资源
  • 方案3:拓展DCI中的PUCCH指示信息bit数,不引入隐式确定PUCCH资源

经讨论和融合,RAN1#92次会议确定DCI使用3比特指示PUCCH资源。对PUCCH集合0(承载1-2比特UCI),高层信令可配置最多32个PUCCH资源。当PUCCH资源数量大于8时,则根据CCE索引和DCI中的3bit指示信息联合确定一个PUCCH资源,具体方法如下式

对于PUCCH集合1、集合2、集合3(承载2比特以上UCI),高层信令可配置最多8个PUCCH资源。终端根据DCI中的3比特指示信息确定可使用的PUCCH资源,而不使用隐式资源确定方法。 

4.PUCCH与其他上行信道冲突解决

在LTE系统中,为了保证上行单载波特性,当一个子帧中同时需要传输多个信道时,UCI将复用在一个物理信道中传输。另外,由于LTE系统中物理信道在时域上总是占满一个TTI中全部可用资源传输,发生重叠的信道在时域上是对齐的。因此当PUCCH与其他上行信道发生时域冲突时,只要确定一个大容量信道传输上行信息即可,例如使用PUCCH格式2a、格式2b、格式3、格式4、格式5复用传输CSI和ACK/NACK,或使用PUSCH复用传输UCI和上行数据。

类似的,R15/R16 NR系统在一个载波内也不能同时传输多个上行信道。在标准化讨论过程中,很快对重叠信道起始符号相同的情况达成结论,即通过一个信道复用传输所有的UCI信息。当重叠信道的起始符号不相同时,UCI复用传输将会涉及一个全新的问题,即将多个信道中复用于一个信道中进行传输是否能满足各信道对应的处理时延要求。图5-54和图5-55给出了两个重叠信道对于的处理时延问题的事例。

图5-54中,PDSCH的结束位置到承载对应ACK/NACK的PUCCH的起始位置之间的时间差应满足PDSCH处理时延要求(的取值与终端能力有关,具体参见TS 36.214中5.3节),但是PDSCH的结束位置到PUSCH起始位置之间的时间间隔不满足PDSCH处理时延要求。此时若要求将PDSCH对应的ACK/NACK复用于PUSCH内进行传输,则终端实际上无法传输有效ACK/NACK信息。

图5-55中,承载UL Grant的PDCCH的结束位置于其调度的PUSCH的起始位置之间的时间差应满足PUSCH准备时延的取值与终端能力有关,具体参见TS 36.214中6.4节),但是指示SPS资源释放的DCI所在PDCCH的结束位置到PUSCH起始位置之间的时间间隔不满足

此时若要求将SPS资源释放DCI对应的ACK/NACK复用于PUSCH内进行传输,则超出了终端的处理能力。

为了解决上述处理时延问题,同时最大限度地降低对终端的影响,3GPP RAN1#92bis会议达成工作假设,当重叠的上行信道满足如下时延要求,则将UCI复用于一个物理信道中进行传输,如图5-56所示。

  • 从所有重叠信道中起始时间最早的上行信道到重叠上行信道对应的所有PDSCH中,最后一个PDSCH的结束位置的时间间隔不小于第一数值。考虑到UCI复用传输相比UCI独立传输需要额外的基带处理过程,经讨论确定第一数值在正常的PDSCH处理时延()的基础上多加一个符号
  • 从所有重叠的上行信道中起始时间最早的上行信道到重叠上行信道对应的所有PDCCH的结束位置的时间间隔不小于第二数值。类似于第一数值的定义,第二数值是在正常的PUSCH准备时间()的基础上多加一个符号。

若多个重叠上行信道不满足上述时延要求,则终端行为不做定义,即隐含约束基站在做调度时,若上述时延无法得到满足,那么基站一个放弃时间在后的调度。

上述复用传输工作机制确定后,另外一个需要讨论的问题时如何确定重叠信道集合。重叠信道集合的确定将直接影响参与复用传输的UCI数量及最终使用的复用传输方式。以图5-57为例,终端在一个时隙中有4个待发送信道,其中信道4与信道1不重叠,但信道1与信道2和信道3都重叠。在确定与信道1重叠的信道过程中,若不包括信道4,则可能会引起二次信道重叠。例如,确定信道1、信道2、信道3中承载的信息通过信道3中承载的信道通过信道3复用传输,则跟踪4再次碰撞。

为了避免上述情况发生,RAN1 #93次会议通过了如下重叠PUCCH集合Q确定方法。

  • 确定PUCCH A:所有重叠PUCCH中起始时间最早的PUCCH。若存在多个起始相同的PUCCH,则选择其中时长最长的。若多个PUCCH起始时间、时长都相同,则任选其一作为PUCCH A。
  • 与PUCCH A重叠的PUCCH纳入集合Q
  • 与集合Q中任意PUCCH重叠的PUCCH纳入集合Q
  • 根据集合Q中所有的UCI确定一个复用传输信道PUCCH B。
  • 确定PUCCH B是否与其他PUCCH重叠。若是,则重复执行前几点内容。

集合Q确定后,根据所有UCI确定一个复用传输所有UCI的PUCCH。若该PUCCH与任一PUSCH重叠,则UCI将通过PUSCH复用传输;否则,UCI通过PUCCH复用传输。

PUCCH(1)上行控制信道(PUCCH)设计相关推荐

  1. [4G5G专题-71]:物理层 - 4G LTE 物理混合自动重传指示信道PHICH与物理上行控制信道PUCCH与UCI

    目录 第1章 概述 1.1 上行物理控制格式指示信道PHICH概述 1.2 物理上行控制信道PUCCH 1.3 UCI(Uplink Control Information) 1.4 PUCCH和PH ...

  2. 5G NR上行控制信道PUCCH

    一.PUCCH概述 PUCCH用于承载上行控制信息,相比LTE,NR PUCCH支持5种不同的格式,按照时域上所占用的符号数量可以分为短格式和长格式两种,如下表所示,短格式占用1-2个符号,可以承载1 ...

  3. PUCCH(2)格式与DTX检测(源于5G上行控制信道增强技术研究)

    目录 上行时隙结构与物理资源 PUCCH格式与流程 PUCCH简介 PUCCH格式 PUCCH format 0 PUCCH format 1 PUCCH format 2 PUCCH format ...

  4. 上行物理信道 PUCCH和DMRS for PUCCH

    Overview 与LTE类似,NR中PUCCH也支持多个格式,NR中PUCCH支持如下表所示的PUCCH格式. Sequence and cyclic shift hopping PUCCH for ...

  5. 5G的上行物理信道和上行物理信号(与4G对比)

    哈喽同学们~这篇文章我们来学习5G的上行物理信道和上行物理信号.在学习LTE物理信道的时候,我们已经知道物理信道是物理层用于传输信息的通道,可以分为上行信道和下行信道.在生活中通常基站处于较高位置,挂 ...

  6. 上行物理信道 PUSCH

    与LTE相比,上行物理信道有以下三类: 物理上行共享信道,PUSCH 物理上行控制信道,PUCCH 物理随机接入信道,PRACH NR的上行物理信号有以下几种: 解调参考信号,DM-RS 相位追踪参考 ...

  7. 能量时域空间物理_5G新在哪儿(11)-下行公共物理控制信道

    本系列文章为人民邮电报"5G新在哪儿"专栏文章 在4/5G移动通信系统中,物理层公共控制信道是全新的系统框架设计理念,主要肩负了物理层控制消息的交互传输,同时物理层公共控制信道也是 ...

  8. LTE上行物理层传输机制(3)-上行物理信道和参考信号的位置

    1.上行传输机制 与下行类似,当UE需要给eNB传递信息时,也是通过物理信道和参考信号发送的.上行物理信道包括PRACH随机接入信道.PUCCH控制信道.PUSCH共享信道,上行参考信号包括解调参考信 ...

  9. GSM的逻辑信道-控制信道-专用控制信道(DCCH

    基本概念 专用控制信道(DCCH:Dedicated Control CHannel):是一种"点对点"的双向控制信道,其用途是在呼叫接续阶段和在通信进行当中,在移动台和基站之间传 ...

  10. [4G5G专题-69]:物理层 - 4G LTE物理上行共享信道PUSCH与物理下行共享信道PDSCH与辅助信息块SIB

    第1章 物理下行共享信道PDSCH概述 1.1 PDSCH概述 PDSCH: physical Downink Shared Channel, 物理下行共享信道. PDSCH是LTE物理下行信道中的一 ...

最新文章

  1. 给每个函数写一个记录日志的功能.
  2. 线程中应该注意的问题
  3. python测试开发自学教程-2019第一期《python测试开发》课程,10月13号开学
  4. Springboot .properties或.yml配置文件读取pom.xml文件值
  5. TCP、UDP、IP 协议分析
  6. 深入async/await知多少
  7. 前端学习(2982):实现商品功能列表
  8. vba与python相比2019_重大改变!Python 或将取代 VBA 成为 Excel 官方脚本语言
  9. docker 容器之间通信_四、Docker 网络原理、分类及容器互联配置
  10. Python异常捕获及自定义异常类
  11. idft重建图像 matlab_利用 MATLAB 编程,打开一幅图像,对其进行 DFT 变换,并置其不同区域内的系数为零,进行 IDFT ,观察其输出效果。_学小易找答案...
  12. NOIP2011 选择客栈(洛谷P1311)
  13. Fedora 10安装amarok中文乱码解决办法
  14. movcms能安装PHP吗,LzCMS-博客版 手动安装方法
  15. 每月读书 2012-06
  16. java虚拟机之内存模型
  17. SHFileOperation的用法
  18. echarts地图数据与世界地图中英文转换
  19. rstp 小米网络摄像头_小蚁摄像头实时同步视频到群晖 nas(2)—— 使用 rtsp 协议同步...
  20. Spark宽窄依赖详解

热门文章

  1. 数学建模——时间序列预测(股价预测)
  2. 2018金山WPS实习面试
  3. 【直流无刷马达的调速方法
  4. 利用条形码生成器在Word 2013中轻松制作条形码的方法
  5. sql server导入备份文件
  6. 生成sis文件的诀窍
  7. mysql替换后的zzigu_MySQL导入数据报错Got a packet bigger than‘max_allowed_packet’bytes错误的解决方法...
  8. c语言 lis的nlogn算法,LCS (nlogn)
  9. Phusion Passenger
  10. 中国车牌号的分类说明识别及含义