企业官网建设流程全解析

5G的物理层控制信号，是我这几年做L1/L2协议和优化时觉得最值得反复琢磨的一块。4G时代PDCCH盲检就把不少人折腾得够呛，到5G NR这里，控制信号干脆拆成了下行控制信道、上行控制信道加一套参考信号体系，每个都牵一发动全身。这篇文章是系列第八篇，我想把物理层控制信号这张图完整梳理一遍：它们到底在调什么资源、用什么信道承载、终端怎么找到指令、参考信号为什么也算控制信号的一部分。不管是做协议栈开发、物理层算法，还是搞网优参数优化，这篇文章都值得边看边对照协议翻一翻。

1. 5G物理层控制信号的全局逻辑：为什么控制面比数据面更值得抠细节

1.1 控制信号要回答的三个问题

无线通信里，数据面解决的是"用户的语音、视频、文件怎么传"，控制面解决的是"这些东西该用什么资源传、传给谁、什么时候传"。5G物理层控制信号，本质上是基站与终端之间在物理层完成的一套"指令系统"，它要回答三个问题：

• 下行：基站告诉终端，接下来某个时频位置上的数据是发给你的，用的是什么调制编码方式、什么波束方向。
• 上行：终端告诉基站，我这边收到了什么、有没有解码成功、缓存里有没有要发的数据、信道质量怎么样。
• 参考：双方先测信道，才知道信号在哪儿、该用什么预编码和波束，这些测量本身就是通过一系列参考信号完成的。

这三个问题分别对应PDCCH（物理下行控制信道）、PUCCH（物理上行控制信道）以及DMRS、CSI-RS、SRS等参考信号。很多人一提到控制信号就只想到PDCCH，其实参考信号才是更隐蔽却更影响性能的部分。

1.2 三大组成：控制信道、上行反馈、参考信号一起构成控制面

把5G NR物理层控制信号拆开看，大概可以分成这么几块：

这里SSB和PBCH虽然更多被归入同步与广播，但它们在物理层控制里也顶着半边天——终端最开始入网，靠的就是SSB里的PSS/SSS完成同步，再从PBCH读出必要的最小系统信息。可以说控制信号是终端从开机到进入连接态每一步都离不开的东西。

1.3 控制信号设计对系统的杠杆效应

控制信号在系统里占的资源不多，但影响力极大。PDCCH如果盲检失败，整个调度的数据全部作废，重传、时延、吞吐全部遭殃；PUCCH如果误检，HARQ反馈错误会引发大量无用重传；CSI-RS/SRS测出来的信道不准，后面的MIMO预编码和波束管理就是空中楼阁。

我经常和同事说一句话：数据信道出问题是丢一两个TB，控制信道出问题是丢一整批调度机会。这也是为什么5G标准在控制信号设计上花了极大的篇幅——从CORESET、搜索空间到各种DCI format，再到PUCCH五种格式的适配，每一处都是在"可靠、低时延、低开销"之间找平衡点。

2. 下行控制链路的资源棋盘：CORESET、搜索空间和DCI协同编排

2.1 CORESET与REG bundle：PDCCH的物理底座

PDCCH所占的时频资源，在NR里叫CORESET（Control Resource Set，控制资源集）。它和黄道十二宫一样，看起来是个简单的框，但终端要靠它定位所有控制信息。

一个CORESET在频域上可以是1到270个RB的灵活带宽，时域上持续1到3个OFDM符号。这一点比LTE的PDCCH灵活太多——LTE的PDCCH几乎占满整个系统带宽的前几个符号，资源浪费不说，还把系统带宽绑死了。NR用CORESET把控制区域"局部化"和"配置化"，带宽大场景下可以只在一部分BWP上配置控制信道，带宽小的物联网终端也能跑得动。

PDCCH物理资源的基本单位是REG（Resource Element Group，资源元素组），一个REG在频域上占1个RB、时域上占1个OFDM符号，包含12个RE。每6个REG构成一个CCE（Control Channel Element，控制信道元素），这6个REG在频域上必然连续，时域上根据CORESET的符号数可以灵活分布。

REG和CCE之间还有一个REG bundle的概念，它决定了预编码粒度和交织方式。在REG bundle大小为6的时候，一个CCE的所有REG共用一套预编码，这样终端用DMRS解调时复杂度最低；bundle大小为2或3时，交织更细，可以把不同终端的控制信息打散到频率各处，对抗频选衰落的能力更强，代价是解调参考信号密度也要跟着提高。这块选型说不上绝对好坏，得看覆盖场景。

2.2 搜索空间决定"终端去哪里找指令"

CORESET确定了控制信道所在的资源池，但一个资源池里并不是所有位置都放满了指令。终端在每个时隙里要去猜"我的DCI到底在下行控制区域里的哪个位置"，这个动作叫盲检，也就是盲检测。

为了不让终端漫无目的地乱找，协议设计了搜索空间（Search Space）。每个搜索空间会绑定一个CORESET，并规定：

• 终端需要监视的时隙周期和偏移；
• 一个时隙内的起始符号；
• 要盲检的聚合等级候选集合（Aggregation Level）；
• 每个聚合等级对应多少个PDCCH候选位置。

公共搜索空间（CSS）里放的是寻呼、随机接入响应、系统消息相关的DCI，所有终端都可能要看；UE特定搜索空间（USS）里放的是针对单个终端的数据调度信息。优化的时候经常能发现，USS配置过少，很多终端挤在同一个候选中撞车，导致DCI漏检率升高；配置过多，终端盲检次数暴涨，功耗跟着上去。

2.3 聚合等级与CCE的换算细节

聚合等级（Aggregation Level，AL）是PDCCH盲检里最直观的一个参数，它就表示一个PDCCH占用了多少个CCE。AL=1占1个CCE，AL=2占2个，AL=4占4个，AL=8占8个，NR还引进了AL=16用于覆盖极差场景，不过一般在普通宏站上用不太到。

实际计算的时候要记住一个换算关系：

• 1个CCE = 6个REG = 72个RE；
• 在30kHz子载波间隔、100MHz带宽下，一个符号约273个RB，一个CORESET如果配2个符号，最多能容纳的REG数就很可观了；
• 搜索空间里每个AL对应的候选数N通常是配置出来的，比如AL=4配4个候选，AL=8配2个候选，AL=16配1个候选。

另一个容易忽略的东西是PDCCH候选的起始位置计算，公式里会带一个与RNTI和时隙号相关的随机因子Y。为什么要加这个Y？为了打散不同小区、不同终端之间的候选碰撞——如果所有终端固定从同一个CCE位置开始盲检，小区间干扰会非常集中。YT的引入本质上是一种干扰随机化手段，和LTE里的小区特定频移逻辑是一个思路，只是实现方式更细了。

2.4 DCI format怎么匹配不同业务

DCI（Downlink Control Information，下行控制信息）是PDCCH里真正承载的指令内容。NR的DCI format比LTE多了很多，主要分成调度类和一个特殊的回退类：

• DCI format 0_0/1_0：回退格式，适用于随机接入、重传、系统消息等兼容性要求高的场景，字段少，解析最稳。
• DCI format 0_1/1_1：常规数据调度格式，支持各种MIMO层数、多天线面板、非连续资源分配等高级特性。
• DCI format 2_0/2_1：分别用于时隙格式指示（SLIV、SFI）和预emption指示，也就是告诉终端哪些资源被抢占、哪些符号要用于上行/下行/灵活。
• DCI format 2_3：用于上行功率控制命令的集中下发。

实际工程里，URLLC业务会偏好更短周期的搜索空间和AL较低、候选较多的PDCCH配置，保证低时延下也能快速找到调度指令；而覆盖边缘的终端则往往把AL提到8甚至16，牺牲一些CCE资源换取解码可靠性。这些选择在协议里都是开放项，最终还得靠无线环境说话。

3. 上行控制信道没那么简单：PUCCH格式与UCI承载设计

3.1 UCI的三类成员：HARQ-ACK、SR、CSI

谈PDCCH是基站往终端下达指令，谈PUCCH就是终端往基站回话了。终端回话的内容在物理层统一叫UCI（Uplink Control Information），里面主要有三类：

• HARQ-ACK：下行数据块对错与否的反馈，一个比特可能是ACK也可能是NACK，准确率直接决定下行重传效率。
• SR（Scheduling Request）：终端告诉基站"我有上行数据要发了，给我分配点资源"。
• CSI（Channel State Information）：包括CQI、PMI、RI、CRI等，反映下行信道质量，基站据此选择调制方式、预编码矩阵和波束方向。

这三类信息的量级差别很大。HARQ-ACK可能就2到几十个比特，SR一般1个比特，CSI少则几个比特多则上百个比特。不同量级的UCI，承载方式完全不同，这就是为什么PUCCH设计了五种格式。

3.2 五种PUCCH格式的适用边界

NR的PUCCH格式从0到4，每一种都不是随便定的，背后是比特容量、覆盖能力、复用能力三个指标的权衡。我整理了一个对照表，方便大家查：

格式0有个很有意思的特点：它本身不携带任何调制比特，信息是靠"在哪个时频资源上发了什么序列"来表达的，所以占用的资源极小，但容量也极低。很多刚接触NR的人不理解为什么一个SR还要专门搞一种格式，看到格式0才明白——SR本来就是一个比特的事，用序列选择可以做到零有效载荷发送。

格式2是短PUCCH，主要服务CSI上报；格式3和格式4是长PUCCH，靠DFT-S-OFDM把覆盖做上去。现场优化里最容易犯的错，就是把长格式和短格式配混了，比如让一个覆盖边缘的终端用短格式上报大量CSI，结果基站侧解调门限根本达不到。

3.3 PUCCH资源配置和CSI复用中容易被忽略的问题

PUCCH有很多配置文件，每个UE有一个PUCCH配置集，里面定义了多组PUCCH资源，基站通过DCI指示终端用哪一组。这里有一个细节：HARQ-ACK、SR和CSI在上报时间撞到一起时，需要做复用或者丢弃。

举一个实际例子：终端在一个时隙里同时要反馈HARQ-ACK和周期CSI，但两者的PUCCH资源重叠了，协议规定HARQ-ACK优先级更高，CSI可以延迟上报或者降精度处理。优化时如果把CSI的周期和HARQ-ACK时隙配得比较冲突，就会发现CSI漏报、错报比例升高，进而影响下行MCS选择和吞吐量。

另外，PUCCH干扰协调是个隐形坑。相邻小区的PUCCH如果分配在同一个RB集上，干扰特征会非常明显——上行ACK误检率升高，伴随大量无谓的下行重传。实际操作中，我会优先把不同站的PUCCH频域起点错开，并且尽量让PUCCH集中在一个相对窄的频段内，便于干扰优化。这一点在现网里经常比调发射功率更管用。

4. 参考信号是控制信号的隐形标尺

4.1 DMRS与PTRS：跟着数据走的解调锚点

参考信号在多数人印象里是"测量用的"，这话只说对了一半。NR里有两类参考信号是跟着数据走的，它们是解调的前提：

• DMRS（Demodulation Reference Signal，解调参考信号）：和PDSCH/PUSCH放在一起，终端利用它估计信道冲激响应，才能对数据符号做信道均衡和解调。没有DMRS，数据符号就是一堆完全未知的符号。
• PTRS（Phase Tracking Reference Signal，相位跟踪参考信号）：主要用于高载频、高阶调制场景。它解决的问题是相位噪声——高频段下振荡器的相位抖动会破坏子载波间正交性，PTRS让接收端能跟踪残余载波相位偏移并补偿。

DMRS有一个关键参数叫type，type1每RB最多4个DMRS端口，type2最多6个。多用户MIMO里，端口数直接决定能同时调度的用户数，所以type2虽然开销更大，但在高负载小区里经常被优先选用。

PTRS的密度不是一成不变的，调制阶数越高、传输带宽越大，PTRS密度越高。系统里如果发现高频段64QAM以上解调性能差、星座图乱转，先查一下PTRS配密是不是被降了档，这个坑我在优化项目里踩过不止一次。

4.2 CSI-RS与SRS的分工：信道测量向左，上行探测向右

CSI-RS（Channel State Information Reference Signal，信道状态信息参考信号）是下行测量参考，用于终端测量信道并上报CQI、PMI、RI等CSID。它的体系非常灵活：可以用来做波束管理（beam management）、做信道测量，还可以做干扰测量（CSI-IM）。对于一个做MIMO预编码的系统来说，CSI-RS就是"眼睛"。

SRS（Sounding Reference Signal，探测参考信号）是上行测量参考，基站侧通过接收SRS感知上行信道。在TDD系统里，上下行信道具有互易性，基站可以从SRS估计下行信道。这就带来一个很实用的思路：在TDD站点，SRS的覆盖质量直接影响下行MIMO预编码精度，很多性能和SRS功率、周期配置有强耦合。

我在说明一点：CSI-RS和SRS不直接传用户的业务比特，但它们决定了后面所有数据的传输方式。如果说PDCCH是发指令的人，参考信号就是给指令做提前量测绘的测量员。控制信号的范畴一定要把参考信号算进去，否则做优化时少了半条腿。

4.3 波束管理：控制信号与MIMO的深度耦合

5G尤其是毫米波场景下，波束管理几乎是控制信号的大半壁江山。波束管理分为几个阶段：初始波束获取、下行波束测量、波束失效恢复。

• 初始波束获取：终端读取SSB，SSB本身就是要扫描多个波束方向发送的，终端上报最优SSB索引，基站完成初始波束选择。
• 下行波束测量：基站配置CSI-RS资源，按不同波束发送，终端测量并上报CRI/SINR，基站再细化波束方向。
• 波束失效恢复：终端检测到当前服务波束质量恶化，通过专用PRACH资源触发波束恢复请求。

波束管理反馈走的正是UCI里的CSI，而下发的波束切换指令则在DCI里携带。这条链路把PDCCH、PUCCH、CSI-RS、SRS全部串起来了，所以做5G控制信号优化时，绝对不能只看单一信道，要上下游一起看。

5. 从高层参数到现场参数：控制信号调优里的那些坑

5.1 高层配置如何落地成物理层行为

控制信号不是只存在于物理层。RRC层配置PDCCH-Config、PUCCH-Config、CSI-ReportConfig等结构，最终层层映射到物理层具体行为。最开始做协议栈对接时，我最头疼的就是各种配置信元之间的联动关系。

举个例子，RRC里配置了多个BWP（带宽部分），每个BWP下都有自己的PDCCH-Config。一个终端从初始带宽切到活跃带宽后，它的CORESET和搜索空间完全变了，如果配置不当，下行控制链路直接断掉。更隐蔽的是，PDCCH-Config里的搜索空间配置要引用CORESET ID，CORESET ID又和频域资源、时域参数绑定，一处改错，终端可能变了配置就再也找不到任何DCI。

实操建议：改任何控制信道参数之前，先把配置树从头到尾捋一遍，尤其是BWP切换、公共搜索空间和UE特定搜索空间之间的覆盖关系。我见过不少"终端掉线率高"的案例，查到最后只是某个CORESET时域符号数配错了。

5.2 盲检开销和覆盖两端怎么平衡

PDCCH盲检是有成本的。每多一个候选，终端就要多解调一次，功耗上升、解码时间变长。NR协议规定了每个时隙下行控制信道最多盲检次数，超出部分需要UE能力协商支持。因此在设计搜索空间时，需要在覆盖和复杂度之间做取舍。

典型思路是：

• 对于覆盖边缘、信道条件差的终端：提高聚合等级，但减少候选数量，确保少数几次盲检里有足够的能量把DCI解出来。
• 对于小区中心的终端：保持较低聚合等级，候选多一些，让调度更灵活。
• 对URLLC业务：缩短搜索空间周期，让终端更频繁地寻找DCI，把调度时延压下去。

这个平衡没有标准答案，但可以看指标：如果PDCCH BLER偏高但终端功耗也高，大概率是聚合等级选得不够极端或者候选分布不合理；如果PDCCH BLER正常但下行吞吐有明显时隙空洞，可能是搜索空间周期太长。

5.3 一个典型优化案例的完整链路

之前在某个模拟项目里，遇到一个信号"下行速率上不去、HARQ重传率偏高"的问题。一开始大家认为是PDSCH MCS选得太激进了，我把目光转向控制信号链路后，发现问题出在PUCCH的HARQ-ACK上报上。

排查过程是这样的：终端上报的是格式1的PUCCH，被配在了一个段时间域符号数只有4个的短配置上。信号质量中等偏弱时，这个PUCCH的解调成功率明显下降，于是下行收到大量NACK，基站以为所有数据都传错了，不断重传，速率自然上不去。

处理办法是把该小区的PUCCH格式1符号数从4个提到7个，并调整了时隙内起始位置，避开邻区干扰高发的符号。改完之后PUCCH的误报率明显回落，下行重传率接近正常水平，平均吞吐提升了大概15%。这个案例说明，控制信道的覆盖问题经常不是调功率能解决的，得从格式、符号数和干扰协调入手。

6. 容易被误读的细节：时频重叠、多TRP与终端兼容

6.1 资源冲突与速率匹配规则

物理层控制信号的资源经常和数据信道在时频上撞车。PDCCH占的REG，PDSCH理论上是不能用的，但NR存在速率匹配（rate matching）机制：PDSCH可以绕开某些预留资源，把它们当作不可用位置提前在编码里打孔。

典型的预留资源包括CORESET占用的RB、CSI-RS占用的RE、以及为未来灵活调度预留的RB集合。终端在解PDSCH时必须知道哪些RE被预留了，否则解码必然失败。

现场偶尔会出现所谓"资源重叠导致解调质量差"的怪问题，多半就是速率匹配配置没对齐——基站侧认为PDSCH绕开了某个预留区，终端侧却不知道这个预留区的存在。排查这类问题时，我会重点核对RRC里的rateMatchPattern和PDCCH-Config中的CORESET频域资源是否一致。

6.2 多TRP场景下的控制信号增强

多TRP（Transmission Reception Point，收发点）是NR增强覆盖和提升可靠性的一个重要手段。在控制面，多TRP意味着一个PDCCH可以由两个TRP同时下发，终端把两部分解调结果合并，或者接收两套不同的DCI做冗余调度。

这里有个反直觉的细节：多TRP并不是只要资源翻倍就必然更好。两套下发的DCI如果内容一样，终端可以合并增益，但盲检开销也会翻倍；如果配置不当，两个TRP的信号在下行形成自干扰，反而把可靠性拉低。实际部署时，多TRP场景的控制信道设计需要结合传输点之间的时延差、频偏差做针对性对齐。

我自己在实验室测试多TRP候选集合并时，发现TRP间时间差超过一定门限后，合并增益会快速下降。这不是单纯加大发射功率能解决的，而是要精调资源映射和候选位置。

6.3 不同终端版本的兼容性负担

5G终端能力差异非常大。早期版本的终端不支持某些新引入的CSI-RS配置，也不支持PDCCH的某些重复传输模式。网侧RRC配置时必须上报UE能力，再用能力协商限制实际下发的控制信道参数。

做平台对接时，经常遇到的场景是：同一个小区里，新终端能用的CORESET配置，老终端用不了。这时候要么统一降配，大家都用兼容性最好的配置；要么做版本差异化配置，让不同能力终端落在不同搜索空间里。主流做法是后者，但配置复杂度会增加不少，也更容易在切换时出问题——终端换到另一个小区后，若配置能力不同，控制链路连接失败的情况时有发生。

从这个角度看，控制信号优化的核心不只是性能指标，还有兼容性。任何一个参数的修改，都要在改动前后做多终端版本的回归验证，不然一个看似无关的配置改动可能把一批旧终端的控制链路全打断了。

说到底，5G的物理层控制信号不是几个孤立信道，而是一套从配置生成、资源映射到盲检、测量反馈的完整闭环。纸上明白协议是第一步，真正拍板调参的底气，还是要在实际设备和场景里一点点磨出来。