1. 从标题拆解：上行链路物理层到底在解决什么问题
1.1 为什么上行比下行更值得单独拎出来讲
很多人第一次接触5G物理层，注意力天然会被下行吸引——基站发、手机收，速率数字好看，演示也直观。但真正在工程一线待过的人都知道，上行链路才是那个“事多、坑深、资源紧”的方向。原因不复杂：手机侧发射功率受限、天线数量少、电池要省电、射频前端成本卡得死，而基站侧接收到的信号还要穿过人体、建筑、车辆等各种遮挡。换句话说，下行是“有钱人家过日子”，上行是“精打细算过日子”。
这一章标题叫“上行链路物理层处理”，核心就是回答一个问题：终端要把一串比特送到基站，中间到底经历了哪些处理步骤，每一步为什么必须存在，参数怎么定，坑在哪里。它涉及的不只是协议栈某一层，而是从传输信道到物理信道的映射、调制、加扰、层映射、变换预编码、资源映射、参考信号插入这一整条链。适合谁看？做基带算法、物理层仿真、协议栈开发、测试仪表、以及需要理解5G空口细节的系统工程师。哪怕你只做上层业务，搞清楚上行物理层的约束，也能明白为什么某些场景下上行就是上不去。
1.2 上行物理层处理的整体链路鸟瞰
先把全景图在脑子里立起来。终端侧要发数据，大致会经过这么一条路径：传输块（TB）→ CRC添加 → 码块分割与CRC → 信道编码 → 速率匹配 → 加扰 → 调制 → 层映射 → 变换预编码 → 预编码 → 资源粒子映射 → OFDM符号生成 → 射频发射。基站侧则基本反向操作，外加信道估计、均衡、解调、解扰、解码。
这里面有几个点特别容易混淆，我先把它们点出来，后面再展开：
- 加扰和调制谁先谁后：先加扰再调制，加扰是在比特域做的，调制是把比特映射成星座点。
- 变换预编码是不是必须的：不是。它只在特定波形配置下启用，用来降低峰均比，这是上行区别于下行的关键特征之一。
- 层映射和预编码在上行意味着什么：上行多天线发射时，层映射决定码字到层的分配，预编码决定层到天线端口的映射。终端天线少，所以这里的自由度远小于下行。
提示：如果你做仿真，先把这条链路按顺序画在纸上，每经过一个模块就标注“输入是什么、输出是什么、关键参数有哪些”。这个习惯能帮你省掉大量调试时间。
2. 核心模块逐个拆：每一步到底在干什么
2.1 CRC添加与码块分割：错误检测的第一道闸门
传输块从MAC层下来，第一件事是加CRC。CRC的作用是让接收端判断这个块有没有传错，它不纠错，只检错。上行用的CRC长度有几种，具体选哪种跟传输块大小和信道类型有关。加完CRC之后，如果传输块太大，还要做码块分割——因为信道编码器对单个码块的长度有上限，不能无限长。
分割的时候每个码块还要再加一次CRC，这叫码块级CRC。为什么要加两次？因为大块数据分割后，如果只靠外层CRC，一旦出错你只知道“整块错了”，不知道是哪个码块错，重传就得全传。有了码块级CRC，接收端能定位到具体哪个码块出问题，配合HARQ可以更精细地处理。
实操中容易踩的坑：码块分割的边界处理。如果传输块大小刚好卡在分割阈值附近，填充比特的插入位置和数量会影响后续速率匹配。我见过有人仿真时速率匹配输出长度对不上，查了半天发现是分割时填充比特算错了。建议在代码里把分割前后的比特数打印出来核对。
2.2 信道编码：LDPC与Polar的分工
5G上行信道编码主要用两类：LDPC码用于数据信道，Polar码用于控制信道。这个分工不是随便定的。LDPC在中高码率下性能好、译码吞吐高，适合大数据块；Polar在短块和低码率下更接近容量限，适合控制信息这种小块。
LDPC编码的核心参数是基图（Base Graph）选择和扩展因子Z。基图有两张，BG1适合大块高码率，BG2适合小块低码率。选哪张取决于传输块大小和码率。扩展因子Z决定了实际校验矩阵的大小，它必须满足一组离散取值。这里有个计算过程：给定传输块大小和可用资源，先算目标码率，再根据码率和大小时选基图，然后确定Z，最后做编码。
注意：LDPC编码后的比特数不等于传输块比特数，中间有速率匹配来调整。很多人第一次做链路级仿真时，直接拿编码输出去调制，结果资源映射对不上，就是因为漏了速率匹配。
Polar码这边，上行控制信息用它。Polar的构造涉及信道极化、信息位选择、冻结位设置。信息位选哪些位置，直接决定译码性能。常见做法是用密度进化或高斯近似来算每个极化子信道的可靠度，选最可靠的放信息位。这块在标准里有对应的序列，实现时查表即可，但理解原理对调试有帮助。
2.3 速率匹配：把比特数“裁剪”到资源能装下的量
速率匹配做的事，说白了就是把编码后的比特流调整到实际物理资源能承载的比特数。它通过打孔（丢弃一些比特）和重复（重复一些比特）来实现。上行数据信道的速率匹配还要考虑HARQ冗余版本，不同冗余版本对应不同的打孔重复图案，这样多次重传可以互相补充。
这里的关键参数是可用资源粒子数。你要先知道分配了多少PRB、多少OFDM符号、解调参考信号占了多少资源，才能算出能放多少比特。计算顺序不能乱：先算RE总数，减去参考信号开销，再根据调制阶数和层数算出总比特容量，最后和编码输出比特数比对，决定打孔还是重复。
我个人的经验是：速率匹配是整条链路里最容易出off-by-one错误的地方。因为涉及大量边界判断，比如最后一个符号怎么处理、参考信号位置怎么跳过。建议写单元测试，用几组标准里的测试向量去验证，比肉眼查代码靠谱得多。
2.4 加扰：让干扰随机化的隐形推手
加扰是在比特域做的，把比特流和一个伪随机序列做异或。目的有三个：一是让相邻小区的信号干扰随机化，避免持续碰撞；二是避免长连0或长连1，有利于接收端时钟恢复；三是让信号统计特性更接近白噪声。
加扰序列的初始化跟小区标识、无线网络临时标识、码字编号等有关。接收端要做解扰，必须知道同样的初始化参数。这里容易忽略的是：不同信道的加扰初始化方式不一样，数据信道和控制信道用的参数组合不同。实现时如果初始化错了，解出来全是乱的，但CRC又可能碰巧通过（概率极低），排查起来很头疼。
2.5 调制：把比特搬上星座图
上行调制方式从低阶到高阶有QPSK、16QAM、64QAM、256QAM。阶数越高，每符号携带比特越多，但对信噪比要求也越高。上行因为终端功率受限，通常不会一上来就用高阶调制，而是根据信道质量动态调整。
调制的过程就是查表：把比特组映射到星座点。星座图有归一化因子，保证平均功率一致。这里有个细节：不同调制方式的归一化方式不同，做仿真时如果功率归一化错了，误码率曲线会整体偏移。我一般会在调制后算一下平均符号功率，确认是1再往下走。
2.6 层映射与变换预编码：上行特有的那道工序
层映射是把码字映射到层。上行通常单码字，层数取决于终端发射天线数和信道秩。变换预编码是上行的一个特色，它本质是一个DFT操作，把时域信号变换到频域，目的是降低峰均比。峰均比低意味着终端功放可以工作在更高效的区域，省电、成本低。
但变换预编码不是所有场景都开。是否启用跟波形配置有关。启用时，整个处理链叫DFT-s-OFDM；不启用时就是CP-OFDM。这个选择直接影响资源映射和参考信号设计。实操中要特别注意：变换预编码的尺寸必须和分配的资源块数匹配，尺寸选错会导致输出符号数不对。
2.7 预编码与资源映射：最后把符号放到该放的位置
预编码把层映射到天线端口。上行终端天线少，预编码矩阵的选择相对有限。资源映射则是把预编码后的符号放到具体的RE上，要避开参考信号占用的位置，还要处理不同符号间的映射顺序。
资源映射的规则是“先频域后时域”还是反过来，标准里有明确规定。映射顺序错了，接收端解出来就是错的。我建议在实现时把映射图案可视化出来，看一眼就知道对不对。
3. 实操过程：从零搭一条上行物理层链路
3.1 参数集与资源格子的确定
动手之前先定参数集。5G支持多种子载波间隔，上行常用的有15kHz、30kHz、60kHz。子载波间隔决定了符号长度、时隙长度、每时隙符号数。选哪个取决于频段和部署场景：低频段常用15/30kHz，高频段用60kHz甚至更大。
定完参数集，接着确定资源格子。一个时隙内有多少个OFDM符号，每个符号有多少个子载波，哪些RE分给数据，哪些分给参考信号，哪些留给控制信道。这一步的输出是一张资源地图，后面所有处理都围绕它展开。
提示：建议把资源地图用二维数组表示，数据RE标1，参考信号RE标2，保护带标0。调试时直接打印这个数组，比看协议文本直观一百倍。
3.2 传输块到比特流的完整生成
假设给定了传输块大小、码率、调制方式、层数、分配PRB数，现在要生成最终发射的比特流。步骤是：
- 生成随机传输块比特。
- 加CRC。
- 判断是否需要码块分割，需要则分割并加码块CRC。
- LDPC编码，选基图和扩展因子。
- 速率匹配，按冗余版本打孔重复。
- 加扰。
- 调制。
- 层映射。
- 变换预编码（如启用）。
- 预编码。
- 资源映射。
每一步的输出比特数或符号数都要核对。我习惯在每步后打印长度，和理论值比对。理论值的计算要结合协议里的公式，比如速率匹配输出长度等于资源能承载的比特数。
3.3 接收端反向处理与信道估计
接收端先做信道估计，用解调参考信号算出每个RE的信道响应。然后做均衡，把接收符号除以信道估计，补偿信道影响。接着解资源映射、解预编码、解变换预编码、解层映射、解调、解扰、解速率匹配、LDPC译码、解CRC。
信道估计的质量直接决定整条链路的性能。参考信号的密度和图案是标准定好的，但估计算法可以自己选。常见的有最小二乘、最小均方误差、线性插值等。低信噪比下，插值和滤波能明显改善性能。
3.4 关键参数的计算示例
举个具体例子。假设子载波间隔30kHz，分配20个PRB，调制64QAM，单层，一个时隙14个符号，其中2个符号用于解调参考信号。计算可用RE数：
- 总RE数 = 20 PRB × 12子载波 × 14符号 = 3360
- 参考信号开销：假设每PRB每参考符号有若干RE，具体按标准图案算，这里假设占去约1/7
- 可用数据RE约 3360 × 6/7 ≈ 2880
- 每RE承载6比特（64QAM），单层，总比特容量 ≈ 2880 × 6 = 17280
这个数就是速率匹配要凑的目标。如果编码输出比特多于它，打孔；少于它，重复。实际计算要严格按协议公式，这里只是演示思路。
4. 常见问题与排查技巧实录
4.1 速率匹配后长度对不上
这是最高频的问题。排查顺序：先确认资源格子算对没有，再确认参考信号开销扣对没有，然后确认调制阶数和层数用对没有，最后检查打孔重复的边界处理。九成以上的长度错误出在资源格子计算，尤其是参考信号位置和符号数。
4.2 解调后误码率异常高
如果信噪比正常但误码率居高不下，先查加扰初始化。加扰错了，解出来就是随机比特。再查调制归一化，功率不对会导致星座点偏移。还查信道估计，估计不准均衡就白做。我遇到过信道估计插值方向搞反的，频域插值做成了时域，结果惨不忍睹。
4.3 变换预编码启用后性能反而变差
变换预编码本意是降低峰均比，但如果尺寸和资源不匹配，或者接收端解变换预编码时尺寸搞错，性能会崩。确认收发两端用的变换尺寸一致，并且和分配PRB数对应。
4.4 常见问题速查表
| 现象 | 可能原因 | 排查方向 |
|---|---|---|
| 速率匹配输出长度错 | 资源格子算错 | 核对PRB数、符号数、参考信号开销 |
| 解调误码率高 | 加扰初始化错 | 核对小区标识、临时标识、码字编号 |
| 星座图整体偏移 | 功率归一化错 | 检查调制归一化因子 |
| 变换预编码后异常 | 尺寸不匹配 | 核对变换尺寸与PRB数 |
| CRC通过但数据错 | 极低概率碰撞 | 检查是否有未初始化变量 |
注意：调试时不要一上来就怀疑算法，先怀疑参数和边界。物理层代码里，参数错误导致的bug远多于算法本身的问题。
5. 工具选型与仿真环境搭建的一些经验
做上行物理层，工具选型直接影响效率。MATLAB适合算法验证和链路级仿真，工具箱里有现成的5G模块，但自己实现一遍收获更大。Python适合快速原型和数据处理，配合NumPy和SciPy能搭出可用的仿真链。C/C++适合最终实现和性能敏感场景，但开发周期长。
我的建议是：先用MATLAB或Python把链路跑通，验证算法和参数，再把关键模块用C重写。仿真时一定要有标准测试向量做对照，否则你不知道自己错在哪。测试向量可以从协议附带的电子表格里生成，或者用公开的参考实现交叉验证。
环境搭建上，版本管理很重要。物理层代码改动频繁，没有版本管理，改着改着就回不去了。另外，日志要打够，每个模块的输入输出长度、关键参数值都记下来，出问题时能快速定位。
6. 影响范围：上行物理层处理牵动了哪些上下游
上行物理层不是孤立的。它的参数选择会影响MAC层的调度决策，因为调度器要知道上行能承载多少比特才能分配资源。它的处理时延会影响HARQ时序，因为终端从收到调度信息到发出数据的时间是有限的。它的峰均比特性会影响射频前端设计，因为功放要按峰均比留余量。
再往远看，上行物理层的效率直接决定用户体验。上行速率上不去，视频通话卡、文件传得慢、物联网设备上报延迟大。所以这一章的内容，表面是信号处理，实际是整张网络上行能力的根基。
我个人在实际操作中的体会是：上行物理层的难点不在单个模块，而在模块之间的接口和参数传递。每个模块单独看都不复杂，但串起来之后，一个参数错了，后面全错。所以调试时要有全局观，从资源格子出发，一步步往下推，每步都验证，才能稳。
