前阵子跟团队跑了一趟5G-A上行载波聚合的外场验证，当时最深的感受是：上行速率这个曾经常年被忽视的指标，如今反而成了体验竞争的胜负手。直播、视频上传、车载回传、移动FWA这些业务一上来，用户对上行的吞吐量和时延要求几乎翻了一倍。而5G-Advanced里最直接的解法之一，就是把下行早就玩得很熟的载波聚合搬到上行，也就是UL CA。不过单纯叠加载波只是第一层，真正让项目有意思的是在UL CA基础上引入AI融合，把双载波调度的功率分配、MCS选择、SCell激活这些事交给模型去预判。
这篇文章既讲原理，也讲量化，还讲落地。我会把UL CA的底层逻辑拆开，说明它和SUL的区别，然后给出AI融合的几个技术切入点和模型设计思路，再放一组我们在外场实际采到的对照数据，最后整理成一套可以直接抄作业的配置步骤和排查手册。适合正在做5G-A优化、上行体验保障、AI辅助无线调度相关的工程师或项目负责人参考。
1. 5G-A上行载波聚合（UL CA）到底在解决什么问题
1.1 为什么上行成了5G-A时代的瓶颈
无线通信的上下行从来就不是对称的。下行有大带宽、Massive MIMO、多流传输，基站侧想怎么堆算力都行；但上行完全反过来，终端那边又是功率限制又是天线数量限制，还有散热和体积一堆约束。在5G早期，大部分业务都是以下载为主，上行有个几十兆速率也够用。但你看看现在的业务形态：主播随手开个高清直播、执法记录仪连续回传、AGV小车把高清摄像头画面往后端送、普通用户频繁发原图和视频，上行的压力被真正释放出来了。
核心瓶颈来自三个维度。
第一是终端发射功率。手机上行发射功率一般被限制在23dBm左右，带宽越大，功率谱密度就越低，覆盖越差。第二是终端天线数量。下行可以做到4收、8收，但上行发射链路通常只有1路或者2路，空间复用和波束成形的收益极其有限。第三是调制能力。终端上行支持的最高调制阶数和码率，决定了一个载波上能堆多高，一旦单载波资源全部占满，速率就到天花板了。
这种情况下，UL CA的意义就很直白：把一个载波的上行能力翻成两个。终端同时使用两个上行载波发送业务，基站侧同时接收，资源翻倍，速率上限也接近翻倍。这跟下行的载波聚合在逻辑上是同构的，但上行有完全不同的限制条件，比如终端总功率怎么分配、两个载波干扰怎么控制、PHR怎么上报，所以在工程实现上要麻烦得多。
1.2 UL CA与SUL、下行CA的边界
很多人会把UL CA和SUL搞混，实际它们是两个完全不同的东西。SUL（补充上行），指的是额外配置一个上行载波，比如高频TDD小区再配一个低频的上行载波，专门用来改善弱场覆盖，它通常没有对应的下行。而UL CA是把同一个或不同频段的两个上行载波聚合起来一起承载业务，两者在覆盖增强、速率提升的路径上是不同的。
从频谱形态上，UL CA可以分三种：带内连续，两个载波在同一个频段且挨在一起，实现最方便；带内非连续，同频段但中间有间隔，对滤波要求更高；带间，完全不同的频段组合，比如一个3.5GHz加上一个2.1GHz，分集增益更明显，但终端射频链路和互调干扰是最头疼的。
打个比方。下行CA就像家里装了两根光纤宽带，速度直接叠加；UL CA像你把两个水龙头同时打开接水，但水管总容积有限，怎么分配水流量需要精细控制；SUL则像是你备了一个大水箱，平时用不上，关键时刻能救急，但总水量并没有变多。
搞清楚这些区别很关键，因为后面做配置时，SUL和UL CA会涉及完全不同的参数逻辑，如果混在一起处理，很容易出现“配置了半天，上行速率一点没涨”的尴尬情况。
2. AI与UL CA融合：技术切入点与模型设计
2.1 AI到底能在UL CA里做什么
UL CA从硬件到标准都已经是现成的，但单纯把两个载波叠加起来的实际收益，往往会低于理论值。主要原因是双载波带来的调度自由度太大了：两个载波各自的信道质量在变，终端的总功率有限，每个载波的PHR上报有时间差，业务突发性又很强，传统基于规则的调度器根本处理不过来。这就给了AI发挥的空间。
我梳理下来，AI融合至少有四个切口是值得做的。
第一是上行信道预测和MCS匹配。传统的AMC（自适应调制编码）是看瞬时SRS测量和CQI上报，这在信道快速变化时天然滞后。AI拿过去几个时刻的SRS-SINR、PHR、MCS序列做预测，可以提前半拍估计未来信道的质量，把MCS选得更准。在双载波场景，问题就更复杂，两个载波的信道相关性和功率分配互相牵扯，AI可以输出两个载波的联合MCS，而不是各选各的。
第二是功率控制。UL CA下终端同时向两个载波发射，总功率池子是固定的。A载波信道好，B载波信道差，功率全压给B反而浪费，不如把功率向A倾斜。传统功控大多按载波独立控制，根本没做联动优化。AI可以根据两个载波的路损差、PHR、BLER历史，给出一个每载波功率偏置，这个优化空间在弱场尤其明显。
第三是SCell的激活和去激活决策。SCell的激活和去激活在实际网络中往往是半静态的，由MAC CE触发，但业务是突发的。如果AI能够用BSR、队列长度、历史上传规律做预测，提前几秒判断“用户马上要有大包上行”，就可以主动激活SCell，业务到达时两个载波已经就绪，时延一下子就压下去了。
第四是基站的接收波束预测。这个工程复杂度更高，但收益也很可观。基站侧的多天线可以用AI预测上行信号的到达角变化，减少扫描式波束管理的开销，相当于把上行接收也变“聪明”了。
需要说明的是，AI在这里做的是增强和辅助，不是替代。调度器的基本功能、功控闭环、外环调整都必须保留，AI只是在旁边给出“建议”，决策仲裁还是要留给传统机制去兜底。这个边界划分，直接决定了工程落地的风险等级。
2.2 模型特征、训练数据与推理部署
AI模型要做到能落地，特征选择比模型结构更重要。我们把可用的特征分成几个维度，整理如下。
| 特征维度 | 具体特征 | 说明 |
|---|---|---|
| 信道质量 | 每个载波的SRS-SINR、RSRP、RSRQ | 最能反映当前信道状态的直接输入 |
| 功率状态 | 每个载波的PHR上报值、功率余量趋势 | 判断终端还有多少功率可分配 |
| 调度历史 | 历史MCS、调制阶数、BLER、重传次数 | 用于评估链路自适应的收敛状态 |
| 业务状态 | BSR缓存体积、包大小分布、历史间隔 | 判断业务模型的突发性 |
| 移动性 | TA值变化、速度估计、邻区切换次数 | 影响信道预测的稳定性 |
| 配置信息 | SCell状态、带宽、频段、TAG归属 | 作为静态上下文特征输入 |
标签设计上有一个特别容易踩的坑：不要直接用上调度的MCS当作标签。因为上调度的MCS本来就是功控和外环调整的结果，可能偏保守或者偏激进，带上了历史策略的偏差。我们自己采标签，用的是“按照实际PUSCH解码的CRC结果反推：给定当时的信道和功率，这个MCS到底能不能传好”，也就是把成功解码的更高MCS能力作为正样本。这样模型学习到的是“信道能力”，而不是“历史策略”。
训练数据来源有三块：现网PM统计的聚合数据、MR测量数据、路测打点的逐帧数据。前两块数据量大但粒度粗，第三块粒度细但规模小，最好放在一起联合训练，因为路测数据能提供PM统计里看不到的“失败样本”，比如弱场下BLER飙高的具体场景，这些样本对模型纠偏很重要。
推理部署的位置，我们放在了基站DU内部，作为调度器旁边的一个智能建议模块。推理时延预算是这里最硬的约束，上行调度通常一个调度周期就几毫秒，模型推理如果超过这个预算，整个方案就废了。所以模型结构我建议优先考虑轻量方案：LightGBM、XGBoost这类树模型，或者1D卷积、TCN这类小规模时序模型，而不是一上来就上大Transformer。实测下来，树模型在几毫秒内可以轻松完成推理，而且特征工程做好之后精度完全够用。
模型上线后，回退机制必须有。我们的做法是：AI的输出如果不是一个“合法值”（比如预测MCS超出了当前支持的调制表），或者置信度低于阈值，调度器直接使用传统的规则计算结果。这个兜底逻辑看似简单，但现场出问题时候它帮助你保住整个项目的口碑。
3. 性能增益量化分析：从指标设计到实测结论
3.1 评估口径与测试场景怎么定
做性能量化最怕的就是“口径不统一”，外场每个人拿一根尺子，最后数据根本没法比。我们自己定了一套指标强制统一的评估口径，包含了速率、时延、可靠性、资源效率四个类别。
| 指标类别 | 核心指标 | 统计方式 |
|---|---|---|
| 速率类 | 平均PDCP吞吐量、峰值吞吐量、5%分位吞吐量 | 5%分位用来代表边缘用户的体验 |
| 时延类 | 上行包平均时延、P99时延、调度等待时延 | 从数据到达空口到完成首传的耗时 |
| 可靠性类 | MAC BLER、RLC重传率、HARQ初传成功率 | 反映链路自适应是否匹配信道 |
| 资源效率类 | PRB利用率、每比特功耗、功控余量比例 | 全面评估网络和终端的代价 |
测试场景也必须有统一设计。我们选了几个典型的组合：静止LOS场景，用于测峰值速率上限；静止弱场场景，RSRP压到-110dBm左右，用来测边缘增益；30km/h移动场景，用来测信道快变的适应性；高干扰场景，在邻区加载干扰源，测抗干扰能力；小包频繁场景，用来测时延和调度效率。
统计方法上，每组场景至少跑五轮，每轮持续两三分钟，取中位数和均值一起看。只看均值很容易被一两秒的突发拉高，单看中位数又容易漏掉尾部时延。两个口径一起报，才算是一个合格的量化分析。
3.2 实测增益到底有多少：三组对照数据
以下数字来自我们某个外场验证项目的抽样结果，不同站点不同终端组合会有差异，但比例关系有很强参考意义。测试终端支持两路上行发射链路，单载波和双载波在同一位置跑，AI开和关通过参数开关控制。
| 测试场景 | 单载波基线 | UL CA | UL CA + AI |
|---|---|---|---|
| 密集LOS大包上传 | 约750 Mbps | 约1.35 Gbps | 约1.39 Gbps |
| 弱场（RSRP -110dBm） | 约18 Mbps | 约31 Mbps | 约38 Mbps |
| 30km/h移动场景 | 约95 Mbps | 约152 Mbps | 约172 Mbps |
| 小包频繁随机发送 | P99时延约48ms | P99时延约30ms | P99时延约25ms |
数据里有一个明显规律：UL CA的增益主要来自“资源变多”，在大带宽LOS场景下接近1.8倍，但达不到理论2倍，原因就是PHR上报存在时延，功控在双载波并发时功率分配不够精确，加上两个载波的无线实际条件不是完全一致，总有浪费。AI的额外增益在LOS场景微乎其微，但在弱场和移动场景非常显著，弱场的吞吐提升约22%，移动场景约13%。这其实很好理解，信道越不稳定，传统AMC的滞后性越明显，AI的预测价值就越大。
小包频繁场景最值得关注。这个场景下吞吐量反而不是重点，用户感知主要来自时延。UL CA把可用资源变多了，调度等待时延明显下降，AI进一步通过预激活SCell，把业务到达后的首次调度时延又压下去一截，P99从48ms降到25ms，这个感知提升对直播互动类业务是决定性的。
3.3 AI融合增益的量化逻辑
有些人看到数据会问：这个增益到底是AI给的，还是双载波本身给的？这确实是外场测试最容易扯皮的地方。
我们把增益拆解成三个贡献源：带宽翻倍带来的峰值增益，频率分集带来的边缘增益，AI链路自适应带来的匹配增益。前两个不靠AI也能拿到，第三个是AI独有。要验证AI确实起了作用，必须做控制变量：同一位置、同一网络版本、同一终端，只切换AI开关。而且至少要跑多轮，因为无线信道本身在变化，一轮数据的波动很可能淹没真实的增益。
还有一个更严谨的做法：统计上算置信区间。如果CA+AI相对CA的增益均值是13%，但置信区间的下界接近0，那就说明这个增益在统计上不显著，不能写进汇报里。我们会在外场数据后处理时做一个简单的配对t检验，跑完数据十几分钟就能出结论，这个习惯强烈建议保留。
从实际经验看，AI增益的“含金量”也不全在吞吐量上，更多体现在对特殊场景的兜底：比如高速移动时传统AMC掉速、弱场时BLER飙升，AI在这些边缘场景把体验波动压住了，这个价值远高于在LOS场景把峰值从1.35Gbps提到1.39Gbps。
4. 实践指南与关键参数配置
4.1 终端与网络侧的能力预检
UL CA不是配置几条参数就完事，开始之前先做能力预检。终端方面，不仅要看它宣称支持上行CA，还要落实到具体频段组合、发射链路数量、最大功率等级。很多终端支持下行CA，但上行发射链路只有一路，或者只支持UL CA中的载波切换（UL Tx Switching），上行业务时两个载波是时分轮流发的，不是真正同时收发，这个差异直接决定你配置策略。如果是Tx Switching方案，实际上并不能获得双载波的带宽叠加，只能获得频选增益。
网络侧，只有基站版本支持双载波上行调度还不够，还要看RRU/AAU的上行通道能不能同时处理两个频段的PUSCH，基带板的算力是否有余量。有一次我们在一个老旧站点做测试，SCell配置后始终无法激活，排查半天才定位到是基带板的上行资源已经跑到上限，根本不是参数问题。
预检还要包括频点干扰排查。两个上行载波的频率间隔如果产生互调产物，正好落在另一个载波接收频带内，就算终端能力和参数都正常，上行也会出现莫名其妙的底噪抬升。所以正式测试前，先把该区域的频谱底扫一遍。
4.2 网络侧UL CA配置的关键步骤
配置流程我们总结了一套标准动作，照着做可以少踩很多坑。
第一步，开通SCell并完成小区参数配置。这一步包括频点、带宽、物理小区标识和TAG归属。对于带间UL CA，除非是同一个TAG，否则需要配置不同的时间提前量，忘记配TAG会导致上行信号对不齐，解调失败率极高。
第二步，配置SCell的上行业务资源。PUSCH的DMRS、SRS资源都要跟上，如果SCell只是配了下行，上行业务根本调度不到。这里要特别确认“调度器是否支持上行自调度”。我们踩过一次，SCell配好了，下行也能收，就是上行不涨速率，最后查出来是基站的调度器只开了下行方向的跨载波调度，上行方向没开。
第三步，PHR配置。UL CA场景必须打开multiplePHR，让终端针对每个激活的上行载波分别上报功率余量，同时把PHR的定时器和禁止定时器配到一个合理的值。定得太长，功率余量信息陈旧，AI和调度器拿不到有效特征；定得太短，终端频繁上报，浪费上行开销。我们推荐的定时器大概在160ms到320ms之间。
第四步，功率控制参数。这里最容易被忽略的是pathlossReferenceLinking。对于带间UL CA，SCell如果还在用PCell的DL pathloss做参考，功率补偿会严重失真，尤其是在SCell频段完全不同的情况下。必须按场景选择让SCell参考自己的SSB或CSI-RS做pathloss计算，才能保证功控是有效的。P0和alpha建议两个载波分开配置，弱场场景可以把信道条件好的载波P0适当抬高，信道差的载波降一点，让终端自然把剩余功率优先分配到更有收益的载波上。
第五步，SCell激活和AI接入。如果不上AI，就靠MAC CE半静态激活；如果上AI，需要把AI给出的“是否激活SCell”建议接入到调度器侧的逻辑里，可以先用旁路模式看一段时间，确认AI建议和实际业务走势对得上，再切换成生效模式。
第六步，验证。配置后再跑一轮基础测试，重点看PHR有没有双载波各自上报、两个载波的MCS分布是否正常、BLER是否在合理范围。确认基础UL CA已经稳定，再叠加AI开关进行切换对比。
4.3 AI模块落地的工程化注意事项
AI从仿真到外场，有四个环节最容易翻车。
第一个是特征分布漂移。仿真数据跟外场数据最大的差异是“干净”程度，外场的干扰、多径、频偏都在实时变化，模型在仿真里跑得很漂亮，一上外场推理就出现特征不在训练分布里的情况。解决方法是上线前先采集一段时间外场的真实数据做校准，哪怕只是对特征做一次简单的均值和方差对齐，也能避免大部分漂移问题。
第二个是推理时延预算。处理器的算力是固定的，模型结构一旦太大，推理时延就超预算。我们内部有个硬性要求，模型推理端到端不超过2ms，如果超了就切更小的模型，或者做INT8量化，宁可精度少一个点，也要保证实时性。
第三个是仲裁逻辑。AI输出的是一个建议，跟传统调度器的外环内环怎么融合，需要非常清晰的仲裁。我们的做法是在外环调整完成之后，把AI的输出作为一个偏置加进去，同时限定偏置的幅度范围，保证AI最大也只能让MCS上下浮动两档，绝对不会因为单次预测误差把MCS拉得太激进导致BLER崩掉。
第四个是模型更新。现网的传播环境会随季节、站点改造、业务模型变化而漂移，模型不能训完就一劳永逸。我们把模型上线后的KPI监控做成周维度，每个月做一次离线回放，用这周的数据重新评估旧模型和新候选模型谁更优，再决定要不要灰度换版本。
5. 外场与现网常见问题排查技巧实录
5.1 UL CA配置不生效的典型场景
我们把现场踩过的坑列成一张速查表，排在第一位的就是“终端能力不支持”。终端上报的能力里根本没有UL CA组合，你配置再多参数也是白搭，系统日志里会显示SCell配置完成但终端拒绝。这类问题在工单流程上要提前走完，让终端厂商确认具体支持矩阵。
第二个是SCell配置了但始终不激活。市面上有些同时支持上下行CA的设备，但SCell激活只在下行方向生效，上行没有把SCell“激活”到可用状态。这种问题需要看MAC CE激活命令是否覆盖到上行调度器，必要时直接打开上行自调度。
第三个是激活后SCell很快被释放。多半是SCell的无线链路质量监测不合格，终端持续上报SCell失步，网络侧就自动去激活了。解决办法是先检查SCell的测量量配置（比如RSRP门限），看看是不是门限配得太激进，导致SCell稍微波动就被踢出去。
第四个也是一个隐藏比较深的坑：双载波PHR上报异常。multiplePHR没开时，终端只报一个载波的PHR，调度器以为另一个载波也有功率余量，结果频繁调度，PUSCH却大量丢包。配置multiplePHR之后，两个载波各自的PHR才清晰可见。
5.2 上行速率不升反降的排查思路
这种情况我们遇到过好几次，而且每次原因都不一样，必须按顺序排查。
第一步，先看BLER。如果BLER高，那就是MCS选得太激进，要么是外环没收敛，要么是AI建议不当。先关掉AI或重新收敛外环，看BLER是否回落。
第二步，看PHR。如果两个载波的PHR都长期为0，说明终端已经功率受限。双载波并发时每个载波分到的功率反而不如单载波集中功率，这种场景下UL CA可能本来就是负收益，尤其是弱场。这种情况下可以考虑AI功控策略把信道差的载波降功率甚至建议临时去激活。
第三步，看PRB分配。如果SCell的PRB分配很少，说明调度器没有真正把业务分布到辅载波上，要查是不是跨载波调度配置有问题，或者是SCell的CQI上报被漏配。
第四步，查干扰。如果SCell的SINR明显低于预期，且BLER不高但速率低，大概率是带外杂散或者互调干扰。通过扫频仪看SCell的底噪是不是被抬高了，如果是，就要考虑换频点或者加滤波器。
第五步，别忽视SRS配置。SCell上的SRS不配或者周期配置过长，基站拿不到足够的上行信道估计，MCS选择会偏向保守，这时候速率低但BLER不高，很容易被误判成干扰问题。
5.3 AI模型上线后的KPI看护
AI模型上线不是终点，看护比训练更重要。我们设置了一套KPI看护项，每天自动汇总：AI建议采纳率、回退率、MCS均值、BLER均值、上行吞吐量日报、SCell平均激活时长。任何一个指标连续三天异常跳变，直接触发告警。
回退率要重点关注。如果AI建议被仲裁逻辑大量拒绝，说明模型在现网特征分布下输出大量非法值，基本可以判定模型漂移，需要启动模型回退和重新训练。AI建议采纳率低本身不一定代表模型差，但它是“模型与现场不匹配”的最早信号。
还有一个建议：模型更新后，不要马上全网生效，先在一两个站点灰度跑一周，对比新旧模型的BLER和边缘吞吐，确认没有劣化再推全。我们吃过一次亏，新模型在全网的BLER平均降了0.5%，但某个弱场簇却出现明显MCS回落，幸好灰度期提前发现了。
最后分享一个“从数据侧查问题”的经验：每次外场测试，无论是基础UL CA还是AI开关验证，都把PHR、MCS、BLER、PRB分配这些底层日志完整保存下来。因为这类问题往往不是当场能定位的，晚上回去对着日志回放，很多现象一下子就通了。这套日志既是定位问题的证据，也是下一次AI模型迭代的训练素材，一举两得。
跟这个项目半年多，我最大的体会是：UL CA本身不复杂，难点从来不在信令和参数，而在“并发”这两个字。一旦两路载波同时在收发，功率怎么分、MCS怎么选、干扰怎么压，每个问题都从单变量变成了多变量。而AI最适合的恰恰就是这种多变量、动态、规则难穷举的场景。别把AI理解成一个补丁，它更像给调度器装了一个能看前面几米的预判器，在信道还没恶化前就把参数调好了。如果你也在做UL CA相关的验证，建议哪怕暂不引入AI，也先把PHR和PUSCH资源分配日志存全面，这些数据以后既是分析问题的依据，也是AI模型训练的家底。这是我一路踩坑换来的建议。
