1. 传输信道在5G无线接入技术里的位置1.1 传输块是MAC层和物理层之间的“快递包裹”做5G无线接入技术的人早晚会碰到一个绕不过去的名字传输信道处理。我最早跟它打交道是在一次外场吞吐率优化上。用户明明在近点信号强度报表拉出来一片绿下行速率却死活上不去翻基站侧调度统计才发现调制方式一直停在16QAM也就是64QAM以上的高阶调制根本没参与工作。那会儿我还没系统啃过协议栈只知道照着网管指标查覆盖查干扰绕了一圈才发现核心问题其实是物理层对传输块的处理链路上。后来静下心把3GPP 38.212、38.214翻透配合MATLAB仿真和网管话统一条条对才算把这条链路彻底跑通。先说清楚传输信道是什么。从协议栈看MAC层负责逻辑信道的调度和复用它会把多个逻辑信道的MAC SDU拼装成一个或者几个传输块Transport BlockTB然后整个交付给物理层。物理层拿到这个传输块之后所做的全部工作——加CRC、分段、信道编码、速率匹配、加扰、调制、层映射、预编码、资源映射直到生成OFDM符号——统称传输信道处理。你可以把传输块理解成MAC层打包好的“快递包裹”物理层的工作就是给包裹里每一件货物做防震处理、贴上标签、安排装车路线最后通过物理信道这个“车队”发出去。传输信道不是物理实体它是一个承载业务的逻辑通道真正在空中接口上跑的是物理信道。NR里有几条典型的映射关系下行共享信道DL-SCH承载用户业务和部分系统消息映射到PDSCH上行共享信道UL-SCH映射到PUSCH广播信道BCH映射到PBCH寻呼信道PCH和DL-SCH共用物理资源寻呼消息最终也通过PDSCH发出去。随机接入信道RACH是个特殊存在PRACH上发送的前导码不做常规传输信道编码它靠序列相关性完成检测和定时估计所以随机接入过程经常从传输信道处理的主链路里单拎出来看。搞懂这个定位再看后续的编码调制流程你就不会迷路。因为传输信道处理的本质就是把MAC层给的“数据包”变成物理层能发射的“波形”中间每一步都是在跟无线信道的不可靠性做对抗。1.2 处理链路要解决的三个核心问题传输信道处理是整个无线接入技术中最接近信息论极限的部分它的设计目标说白了就三个可靠性、效率、灵活性。这三个词听起来抽象但在实际工程里每一个都对应着具体的算法选择和参数配置。可靠性要求数据在经历衰落、干扰、噪声之后还能被正确还原。于是物理层在编码之前先给传输块加CRC做检错再用LDPC码做纠错冗余版本的设计又让HARQ重传能充分利用每一次发射的信息。没有这些保护无线信道里随便一个深衰落就可能让整个传输块废掉高层重传的代价远高于物理层这几轮处理。效率则要求用尽可能少的无线资源传尽可能多的有效信息。这直接体现在调制阶数选择上信道条件好就上256QAM一个符号能扛8个比特信道条件差就退到QPSK一个符号只能扛2个比特。再往深处说LDPC编码、速率匹配中的比特选择、层映射里对多天线空间的利用全部都是为了让频谱效率贴着香农极限走。实际链路仿真做多了你会发现LDPC在长码块下的性能距离香农限往往只有零点几个dB这在十年前是不可想象的。灵活性则是NR相对LTE一个非常大的进步。5G要同时服务eMBB、URLLC、mMTC这三类差异极大的业务传输块大小可以从几百比特到上百万比特变化。一套处理流程必须能自适应这种跨度所以NR才会有BG1和BG2两组LDPC基图速率匹配也要支持从1/3到接近1的宽范围码率。后面我会详细展开这里先记住一个结论传输信道处理不是一条流水线走到底而是每一级都有可调参数整套系统围绕“感知信道状态、动态调整处理策略”来运转。2. 下行和上行传输信道处理流程怎么走2.1 下行链路从DCI调度到PDSCH发射了解整条链路最直接的方式是把下行处理流程从头到尾走一遍。基站MAC调度器决定了某个时隙给哪个UE发多少数据、用什么MCS、分配哪些资源块这些信息通过DCI下发给终端同时MAC层把相应大小的传输块交给物理层。物理层拿到传输块后处理顺序是这样的第一步对传输块加CRC。传输块级CRC用CRC24A长度24比特后面码块分段时还要对每个码块额外加CRC24B。加CRC的目的不是帮助纠错而是让接收端在译码之后能快速判断这块数据到底对不对如果不对就触发HARQ重传。第二步码块分段。NR规定的LDPC最大码块长度有限制BG1对应的最大信息长度是8448比特BG2是3840比特。传输块超过这个限制就必须切成多个码块每个码块独立编码、独立译码。分段还有个细节要保证所有码块大小相近同时让段数尽量少避免过多填充比特浪费资源。第三步信道编码。每个码块用LDPC编码器加冗余BG1还是BG2的选择依据是传输块大小和编码码率原则是“大块高码率用BG1小块低码率用BG2”。编码输出的系统比特和校验比特一起送进速率匹配模块。第四步速率匹配。这一步解决的是“编码后的比特数跟实际可用资源不匹配”的矛盾。物理层根据调度的资源块数和调制阶数算出能承载的比特数然后从循环缓冲器里按冗余版本选择出一段比特。冗余版本有0、1、2、3四种第一次传输用RV0重传用其它版本接收端可以把多次传输的软比特合并起来提高译码成功率。第五步加扰和调制。加扰用伪随机序列对码字做异或主要作用是让干扰随机化同时区分用户和小区。调制则是把比特流映射成复数星座点QPSK、16QAM、64QAM、256QAM按MCS表选择。第六步层映射和预编码。层映射把调制符号分配到多个传输层上层数对应空间复用的数据流数最大8层。预编码则是把各层信号映射到天线端口上波束成形、空分复用都靠这一步实现。第七步资源映射和OFDM生成。物理层把调制好的符号填入资源网格放在分配给PDSCH的RE位置上再和DMRS、PTRS一起做IFFT变换加循环前缀最终生成时域信号发射出去。整个流程看下来每一步都有明确的输入输出一个传输块从到达物理层到变成空口波形中间任何一个环节出错都会表现在BLER、吞吐率这些指标上。这也是为什么排查无线性能问题不能只看覆盖和干扰还得懂这条处理链路。2.2 上行链路多一个变的是DFT-s-OFDM与功率控制上行的传输信道处理跟下行大体对称但差异点非常关键。UL-SCH的编码处理顺序跟DL-SCH基本一致同样有CRC、分段、LDPC、速率匹配、加扰、调制最大的区别出现在层映射之后。上行有两种波形可选CP-OFDM和DFT-s-OFDM。CP-OFDM跟下行一致子载波彼此正交频谱效率高但峰均比高DFT-s-OFDM在IFFT之前先做一次离散傅里叶变换等效成单载波传输峰均比明显更低能减轻终端功放的负担。终端功耗是非常现实的约束所以DFT-s-OFDM在小功率终端和远点场景下特别实用。选择哪种波形由网络侧配置通常信道条件好、终端功率充足时倾向CP-OFDM追求吞吐率信道差或者终端功率受限时切到DFT-s-OFDM保证覆盖。上行处理还有个独特问题上行控制信息和共享数据的复用。HARQ-ACK、CSI、SR这些UCI信息需要跟UL-SCH数据一起在PUSCH上传输。物理层要先确定UCI占用的资源数量按顺序把UCI映射到指定RE上再围绕UCI位置分配数据符号。这个过程写进规范极其琐碎但实操中只要记住一个原则控制信息必须放在信道质量最好的位置而且数据要避让控制信息防止控制符号被数据比特盖掉。功率控制也是上行传输信道处理绕不开的部分。PUSCH的发射功率直接影响接收端解调信噪比进而决定MCS和BLER表现。开环功控根据路损估算设定基础功率闭环功控通过TPC命令做动态调整。现场最容易踩的坑是功控参数配置不当导致终端满功率发射出现互调干扰或者在近点不发功控命令导致发射功率过高拉高邻区底噪。这类问题在网管指标上看就是PUSCH的MCS上不去但RSRP很好处理思路往往要回到传输信道处理链路里的调制选择这一环去查。3. 核心环节拆解LDPC编码与速率匹配3.1 5G为什么淘汰Turbo码选了LDPC5G的eMBB场景要求单用户峰值速率达到Gbps级这对信道编码是一个极大的考验。LTE时代广泛使用的Turbo码在码长较长、码率较高时已经逼近香农限但Turbo码的迭代译码结构天然不利于并行化译码时延随码块长度增长得很快很难在超高吞吐场景下同时满足性能和时延要求。更麻烦的是Turbo码在极低误码率区域存在错误地板效应这对要求高可靠性的场景不够友好。LDPC码其实是比Turbo码更古老的编码方案1960年Gallager就提出来了但受限于当时计算机的译码能力被埋没了三十多年直到1996年MacKay和Neal重新发掘才翻红。LDPC的校验矩阵是稀疏的可以用置信传播算法并行迭代译码硬件实现天然适合大规模并行吞吐可以做到几十Gbps甚至更高。再加上LDPC在高码率段性能非常优秀没有明显错误地板正好匹配eMBB业务“大块数据、高速率”的特征。所以3GPP在RAN1的多次讨论之后最终定下的方案是LDPC和Polar分工业务信道DL-SCH、UL-SCH用LDPC控制信道PUCCH、PDCCH和广播信道PBCH用Polar码。当时这个决定在很多老工程师看来有些“感情上难以接受”毕竟Turbo码陪了3G、4G两代积累了大量工程实现经验。但从技术路线选择的角度看这个组合是当时对五种候选编码方案做综合评估后最合理的结果。现在回过头看RAN1在2016年那次关于信道编码的马拉松式讨论基本奠定了5G物理层的底层骨架。3.2 基图选择BG1和BG2到底怎么定LDPC编码在NR里落地为两组基图BG1和BG2。基图可以理解为LDPC校验矩阵的“骨架模板”实际编码时根据信息比特长度做相应的扩展和打孔不需要每次重新构造大型矩阵。BG1的信息列数是22最大支持的信息长度达到8448比特支持的最低码率约1/3最高能到8/9。它的设计目标是中大传输块、中等偏上码率用在eMBB业务里最合适。BG2的信息列数是10最大信息长度3840比特支持的最低码率可以低到1/5最高约2/3。它的设计目标是短块、低码率场景典型是URLLC这类小包高可靠业务。选BG1还是BG2协议给出的选择算法取决于两个因素编码码率R和传输块大小A。简单说当A大于某个门限或者码率超过一定值时用BG1否则用BG2。但实际工程不是把公式背下来就行你要理解背后的原因。BG2的基图行数少、校验位冗余更多适合在低信噪比下靠重编码增益保命BG1列数多系统比特密度高适合高码率下保持频谱效率。仿真里经常能看到这样的现象同样一个1000比特的传输块码率0.7时用BG1性能好码率0.2时BG2反而更稳。这正是分组设计的价值。3.3 速率匹配与HARQ的配合逻辑速率匹配是传输信道处理里最容易被低估的模块我见过不少新手死磕LDPC编码本身却对速率匹配一笔带过。实际上速率匹配决定了每个HARQ进程每次传输到底发哪些比特直接影响重传合并的增益。NR的LDPC速率匹配基于循环缓冲器。LDPC编码器输出的比特写入循环缓冲器速率匹配做的就是从中截取一段长度等于物理资源可承载比特数的序列。截取的起始位置由冗余版本决定RV0、RV1、RV2、RV3分别从循环缓冲的不同偏移处开始。这样设计的目的是让四次传输尽量覆盖到不同的校验比特区域接收端把多次传输的软比特按位置对齐后合并等效于一次更低码率的发射这种机制叫增量冗余合并。举个生活化的例子。你寄一个包裹第一次发快递丢了两箱货补发的时候不会把整个包裹重新寄一遍而是只补发缺失的那两箱以及跟它们相关的“校验信息”这样收件人拼在一起就能凑齐。HARQ的重传就是只补发新冗余版本不重复发已经收到的部分软合并让每次重传都在增加信息量而不是做简单的重复劳动。实际工程里还有一个隐藏参数Nref。UE的HARQ软缓存大小有限不是所有编码比特都能无限制地存下来。Nref按UE能力、载波数和层数计算决定了循环缓冲有效长度如果超出就需要打孔截断。这个参数配置错误或者计算不对会造成软合并增益下降表现在指标上是重传率正常但增益吞吐率明显低于预期。调这类问题最有效的办法是拿同一份日志在仿真器里回放比对理论BLER曲线。4. 调制、层映射与资源映射的实操要点4.1 CQI/MCS驱动的调制阶数选择传输信道处理链路的末端是调制映射这一步把比特变成星座点看似简单却是吞吐率波动最直观的来源。调制阶数不是随便定的它由调度器根据UE上报的CQI和基站侧的外环调整共同决定。终端测量参考信号的信干噪比映射成CQI上报给基站。基站用CQI选择MCSMCS表里同时定义了调制阶数和目标码率。以38.214里的MCS表为例MCS 0到9大多落在QPSKMCS 10到16是16QAMMCS 17到27是64QAMMCS 28以上才到256QAM。你要注意256QAM虽然一个符号能传8比特但它的星座点密度极高对SNR的要求一般要到28甚至30dB以上。也就是说不是信道好就能无脑上256QAM还要看EVM、干扰底噪这些实际条件。外环调整OL-AQM是我一直觉得现场工程师必须懂的机制。它的思想很简单当一段时间内传输块解调失败、触发HARQ重传时说明当前MCS定的太乐观就适当调低CQI对应的MCS反之如果长时间不重传就试探性调高。这个机制能把“瞬时信道估计偏乐观”带来的系统性误差拉回来。排查速率问题时如果看到调制方式分布长期偏高但重传率也高多半是外环参数收敛不够或者在信道快速变化场景下CQI上报延迟太大。在网管话统里看调制方式占比是个很有效的诊断手段。正常近点用户应该有大量256QAM传输如果近点采样点的调制方式统计里256QAM占比很低不要急着调天线先查DMRS的信道估计质量、CSI上报是否被PUSCH上的UCI资源挤占再回头怀疑物理层处理链路本身。4.2 层映射与预编码多天线系统的分合之道层映射做的事是把一个传输块的调制符号“摊”到多个数据流上。比如基站配置秩2传输一个传输块有1440个调制符号就平均分到两层每层720个符号。空间复用的本质就是用多个并行空间信道同时传数据理论上层数翻倍吞吐率就翻倍前提是天线间相关性足够低。预编码紧随其后解决的问题是“这些层上的信号怎么分配到物理天线端口上”。下行通常基于码本预编码终端反馈PMI指示基站从预编码矩阵集合里挑一个合适的矩阵上行的非码本预编码则是终端基于SRS探测结果自选预编码向量再通过DCI里的SRI字段通知基站。这套机制跟波束管理配合是NR大规模天线系统性能的根基。实操中容易忽略的是层数和端口的映射关系。层数并不等同于天线端口数预编码矩阵把N层信号映射到M个天线端口M通常大于等于N。如果只盯着层数去评估下行速率却忽略了CSI-RS端口配置是否跟实际天线数匹配可能会得到“层数正常但速率上不去”的假象。真到了现场用DMRS端口数和调制方式的联合统计来还原实际传输配置比单纯看RRC层配置更接近真相。4.3 RE映射与OFDM信号生成最后一公里的细节调制符号成形之后还要填进资源网格才能变成OFDM时域信号。资源网格的最小单位是RE一个RE对应一个子载波上的一个OFDM符号。PDSCH的RE映射要避开DMRS、PTRS、控制资源集和SSB预留资源。具体的填充顺序是先频域后时域从分配给该UE的RB集合中频率最低的子载波开始逐个子载波填填完当前符号所有子载波再跳到下一个OFDM符号继续。这个顺序看似简单一旦理解反了解映射时符号位置全部错乱。DMRS的位置对系统性能影响很大。额定的DMRS配置类型和额外位置由RRC参数指定前置DMRS总是占据每个时隙的第三个或者第四个OFDM符号额外DMRS在高频段或者高速场景下自动补充用来增强信道估计的时域跟踪能力。工程上经常有人试图通过增加DMRS密度来提升信道估计质量但代价是数据RE被挤占净吞吐率反而下降。这是个典型的“按倒葫芦浮起瓢”的问题要根据信道时变特性去做权衡。最后一步是OFDM调制。一个符号周期内的频域数据送入IFFT变成时域样点再在开头加循环前缀。NR的子载波间隔是15kHz乘2的幂次15/30/60kHz用于低频120kHz用于毫米波子载波间隔越大符号越短抗多普勒能力越强但循环前缀开销也越大。给终端配置numerology的时候既要看频段也要看业务的时延和移动性需求。在链路仿真里这一级也是最容易出现“波形正确但性能对不上”的地方EVM的计算必须严格对齐实际发射的时域信号。5. 传输信道处理中的典型问题与排查实录5.1 下行速率上不去先查调制方式分布再看HARQ重传我在开头提到近点速率卡住的问题这里展开说说完整的排查思路。遇到下行速率异常第一步看PDSCH调制方式分布第二步看HARQ重传率第三步看MCS分布和分配RB数。这三张统计表同时拉开链路哪一环出问题基本就现形了。如果调制方式长期停在16QAM但重传率很低说明信道质量并不差大概率是CQI上报偏低或者外环调整把MCS压住了。这种问题优先检查CSI-RS功率配置和CSI上报周期功率配低了会让终端低估信道质量上报周期太长会让基站用陈旧的信道估计调度。如果调制方式分布显示高阶调制占比很高但重传率也高说明基站过高估计了信道质量通常是干扰突变或者EVM恶化查邻区干扰和发射链路。还有一种常见情况是16QAM和64QAM来回跳重传率正常、MCS平均不高。这类往往是信道快速衰落造成的AMC跟不上信道变化。处理手段是适当降低CQI上报周期或者调整外环收敛速度。真正走到“怀疑传输信道处理本身有问题”的时候已经是把覆盖、干扰、参数都排干净之后的事了这时候才值得去拉仿真回放LDPC译码软信息。5.2 LDPC译码失败率偏高迭代次数与SNR估计LDPC译码失败率上不来先看一个大数平均迭代次数。LDPC译码本身是一个迭代逼近过程通常迭代到满足校验方程或者达到最大迭代次数就停止。如果平均迭代次数长期接近最大值说明输入的软信息质量很差信道估计、干扰抑制或者LLR计算里一定存在某一个问题。有一次我做端到端仿真发现特定SNR点下BLER怎么都降不下来反复检查编码和速率匹配都没问题最后定位到信道估计模块。原因是导频符号上叠加的噪声没有被滤波干净导致解调输出的LLR整体偏小LDPC译码器的置信传播输入不足。解决方法是调整信道估计的时频窗参数同时检查LLR scaling是否匹配调制阶数。这类问题在现场更容易出现在高密度组网下邻区干扰让DMRS污染严重信道估计出来的相位和幅度全部偏掉。如果在基站侧看是特定终端长期BLER偏高而其他终端正常优先怀疑这个终端的DMRS端口是否有波束失配或者天线通道校准问题。再配合检查这个终端的TA调整值定时偏差过大会让频域信道估计产生线性相位误差同样是LLR质量恶化的典型原因。5.3 仿真与实测对不上OFDM峰均比与功放回退做物理层算法的人最头疼的就是“仿真好得不得了外场差得不像话”。这种差异很大程度来自OFDM的峰均比问题。OFDM时域信号是多个子载波叠加的结果峰均比天然偏高发射机功放在线性区工作有限必须回退功率来避免信号削顶失真。回退幅度越大实际发射功率越低覆盖和信噪比同时受损。这个问题在DFT-s-OFDM上会好很多因为单载波特性的峰均比更低这也是为什么功率受限的上行终端更依赖它。下行用的CP-OFDM虽然频谱效率高但对功放设计要求苛刻。外场实际配置里基站的功放回退余量跟载波带宽、RB占用率、调制阶数都有关系256QAM对EVM的要求通常是接近3%或者更严格功放非线性稍微露出一点星座点就糊成一团误码率立刻飙升。排查实测发射链路的EVM问题时光看星座图还不够要分别测频域EVM和时域包络特性。常见的非线性失真会在高阶调制下暴露得非常明显64QAM以下的星座点可能仍然清晰换到256QAM立刻发散。所以现场有一个经验开通256QAM之前先把小区的EVM测试做了如果预留余量不足就别急着开高阶调制否则指标验收会很难看。5.4 基站侧指标排查从网管话统反推处理链路状态对做组网运维和竞赛项目的人来说掌握“从网管指标反推传输信道处理链路状态”是一项硬技能。现在的商用网管系统基本都能输出小区级和用户级的PDSCH/PUSCH BLER、MCS分布、调制方式占比、HARQ重传率、PUSCH发射功率余量等统计这些数据本质上是物理层处理链路的“体检报告”。有一次我配合查一个5G站点的低速率问题网管上看到PUSCH的MCS长期低于平均值但上行RSRP和SINR都正常。仔细翻话统发现该小区的PUSCH功率余量统计里有大量低余量样本说明终端已经被逼到满功率发射信道质量好也弥补不了功率不足。进一步查功控参数发现目标SINR配置偏高闭环功控一直在向上抬终端功率最终触发限幅。这类问题的关键在于理解链路每一级参数之间的耦合关系。最近几年运营商内部和高校组织的5G组网与运维大赛、创新应用方案竞赛很多题目就是给一段网管数据让你定位物理层问题。这类题目表面考的是指标解读实际考的是对传输信道处理整个流水线的理解深度。能把MCS、调制、重传、功控这些散落的指标串成一条“发射链路诊断路径”你就拿到了这类竞赛的钥匙。我建议在校学生和刚入行的工程师多去啃一下38.214的调度与MCS相关章节再用网管话统数据做几次实站案例分析进步速度会非常快。6. 工具与仿真建议把处理链路“眼见为实”6.1 MATLAB 5G Toolbox和Vienna仿真器的使用心得理解传输信道处理最快的方式不是背规范而是动手仿真一条完整的收发链路。MATLAB的5G Toolbox把38.212里的编码流程封装得非常清晰nrDLSCH、nrLDPCEncode、nrRateMatchLDPC、nrLayerMap、nrOFDMModulate这些函数一一对应处理链路上的每一环拿来对照协议学效率很高。Vienna 5G NR Simulator也是一套适合学术研究的系统级仿真平台特别适合看多用户调度和链路级性能的联合表现。我自己的习惯是先跑一个最简单的“随机比特进随机比特出”的闭环生成传输块、做CRC和分段、LDPC编码、速率匹配、加扰调制、过AWGN信道、解调解扰、速率恢复、LDPC译码、CRC校验最后画BLER曲线。这套链路跑通了你对编码增益、速率匹配的比特选择、调制阶数的敏感性就会有非常直观的体感。特别推荐把某个中间环节故意调错看看BLER会怎么恶化这种“破坏性实验”比按部就班的仿真更能锻炼排查能力。6.2 一套可复用的链路调试流程最后分享一个我调物理层链路时反复使用的工作流。第一步固定环境变量MCS、RB数、层数、信道模型全部固定下来不要一开始就做自适应调度仿真变量太多没法定位。第二步分模块打点在编码输出、速率匹配输出、调制输出、信道估计输出、LLR输入这几个关键节点做数据落盘随时可以拉出来对比期望值。第三步按理论曲线校准AWGN信道下把仿真BLER曲线跟理论极限对比偏差大于1dB就要回头查每一级的处理是否有损失。这套流程最大的价值是把“传输信道处理”从黑盒变成白盒。很多刚接触5G物理层的人容易犯一个错误上来就跑全链路自适应仿真看到吞吐率曲线不对却说不清是哪一环出了问题。先分模块验证、再全链路联调虽然前期慢一点但排错效率会高出几个数量级。我带的实习生用这套流程基本两周就能从零开始跑通一个带HARQ的PDSCH仿真链路比对着规范硬啃快得多。做物理层的人最该有的心态是承认每条链路都是几代工程师反复打磨的结果但同时又不能把它当黑盒崇拜。把每一级处理都拆开、看懂、亲手调过一遍你才算真正吃透了5G无线接入技术里的传输信道处理。