NR里面的上行控制信息(Uplink Control Information，UCI)可承载在PUCCH和PUSCH上，这一点与LTE类似，不过在标准版本R15里，并没有将UCI如何和UL-SCH复用到PUSCH上给出详细定义，这个内容将会在R16版本里定义。
UCI信息包含三种信息，这三种信息可单独传输或者混合传输，根据具体的需要场景。
第一种信息是Hybrid-ARQ确认信息，反馈收到DL-SCH传输块情况，ACK或者NAK。
第二种信息是信息状态信息（Channel-state information ，CSI），用于指示下行链路的信道质量，以便进行下行链路的调度，包含多天线和波束赋形方案。
第三种信息是上行的调度请求（Scheduling requests，SR），表示终端需要申请上行资源用于UL-SCH传输。
这种三种信息可混合传输的场景如下：
PUCCH有5种传输格式（format），不同的format决定了不同的比特数和占用的OFDM符号长度，而不同的format，资源复用情况也是不一样的，如下表所示。
Format0和format 2称为短PUCCH，占用1~2个OFDM符号，大多数场景下一个slot的最后两个symbol。发送的比特等于小于2位时，UE复用整个PRB资源，根据基序列选择来区分UE。发送的比特大于2位时，UE不复用整个PRB，在频域上复用UCI和DMRS。
Format1、Format 3、format 4是长PUCCH，占用4~14个OFDM符号时长，比特数大于2位。长PUCCH占用更长的时间周期，在于覆盖范围的不同，当1到2个符号的周期接收到的能量，不足于提供可靠保证的接收时，那就需要更长的周期来发送，这时就用到长PUCCH。
这5种格式的不同，除了占用符号和复用方式的不同，还体现在循环移位（Cyclic Shift，CS），起始符号（Starting Symbol），正交序列（OCC）等不同，如下表所示，这些参数会在后文各种Format 的处理流程公式中出现。这些包罗万象的通信技术的应用，包括时分，频分，扩频，跳频等等，其实目的只有一个，如何让UE更好、更高效、更可靠的接收UCI数据。
如何确定一个PUCCH的时频资源，可以由下图直观的显示。无非就是占用几个RB资源，起始RB在哪里；占用几个OFDM符号，起始OFDM符号在哪里，这几个参数确定以后，就可以知道PUCCH在时频资源上的位置。
PUCCH在时频资源位置上数据的产生，总的来说，不管是何种Format，都要先生成基序列，涉及到跳频序列组(u)和***(v)的确定，循环移位值(cs)。不同的Format，生成的CS过程不一样，这个值最终会影响到基序列的相位旋转值，体现为采用发送的数据比特，对基序列进行调相。而对于某些format，则有可能采用发送比特的调制符号对基序列进行再次调制，然后再用正交序列进行扩频调制，搞这么复杂，无非是为了确保让上行控制信号能够可靠的被基站接收到。我们来看看具体的过程。
首先来看基带序列的产生，采用的序列是ZC序列，分为长度大于36和小于36两种情况。最终我们看到，生成的基带序列重点有3个参数确定，u,v,a(影响相位)。
跳频组号和跳频序号的生成和LTE类似，受到跳频ID或者小区ID值的影响，这些高层参数由RRC配置。每个时隙值产生的跳频参数都不一样。
相位参数a，由PUCCH所在的时隙位置、OFDM符号位置以及高层配置的移位参数确定。
再来看看具体的PUCCH format是如何进行调制的。
PUCCH format 0承载的比特为HARQ（hybrid-ARQ，即ACK/NAK）和SR调度请求，它的调制发送过程挺简单，将生成的基带序列，先频域再时域的顺序，逐一映射到分配的时频RB上。接收端通过检测序列的相关峰值，可确定实际的发送数据，原因在于高层调度的循环位移参数（上图中format 0所示表），会使得生成的基带序列相位发生偏移，在接收端表现为接收到的序列相关峰值移位。只要在一定的窗口内搜索峰值，即可解调出携带的UCI信息。
PUCCH format 0发送处理过程和实际的星座映射调制如下所示。
PUCCH format 1某种程度上来说承载的比特数和功能与format 0一样，只不过用长PUCCH来发送，数据先经过BPSK调制，映射为调制符号，然后再与基带序列相乘，再经过正交序列的扩频，得到时频资源位置的调制序列，这个序列还不是真正映射到时频资源位置上的序列，在做时频资源映射之前，需要乘以一个功率因子。
下图是PUCCH format 1处理的流程示例，调制数据的扩频长度为4，RS参考序列的扩频因子为5，对于采用跳频模式，资源的映射会在不同的时间位置跳到不同的频域位置。
PUCCHformat 2是短PUCCH，发送的比特数大于2比特，用于HARQ反馈和CSI报告，或者是比较大数据的HARQ反馈。调度请求SR同样可以编码发送。如果发送的数据量太多，往往会把CSI抛弃，其它两个要重要得多。发送大数据量（大于11位）的比特首先经过CRC校验，如果数据量小则不用CRC，然后进行信道编码，当比特数小于等于11位时，采用的信道编码是ReedMuller编码，当比特数大于11位时，采用Polar编码，编完码后还要进行速率匹配。然后序列经过由小区ID或者PUSCH的加扰ID与RNTI初始化生成的扰码序列加扰后，再进行QPSK调制，之后再映射到时频资源。通常PUCCH format 2在一个slot的最后symbol位置发送，但也可能在一个slot的其它位置发送。
PUCCH format 3是长PUCCH，可看做是PUCCHformat 2场景下，采用更多的OFDM符号来发送数据。其发送处理过程与PUCCH format 2类似，不同之处在于多了一个DFT变换，降低OFDM信号的峰均比，增加功率使用效率。另外，可以在时间上进行跳频。
PUCCH format 4发送处理过程和format3类似，不同之处在于，在相同的时频资源上，复用了多个UE的调制数据，复用的方法是采用正交的wash码对发送数据扩频，然后再映射到具体的时频资源上。在接收端，UE可以根据自己的正交扩频码，从时频资源上恢复自己的数据。
以上，大体的描述了PUCCH各个Format 的处理流程和异同。我们看到，在处理过程中，涉及到了大量的高层参数，那么，这些参数从何而来呢？或者说UE在上报UCI时，它需要知道的高层参数如何获取呢？可简单用下图来描述。一个是由系统广播消息SIB1里携带的PUCCH-ConfigCommon参数查表获得，另外一个是通过RRC信令pucch_Config告知，这里不做更多的展开描述。
喜欢文章可关注公众号，获得部分代码：
声明：文中图片来源于文中部分图片来源于http://www.sharetechnote.com/，《下一代无线接入技术》