5G上行载波聚合原理与华为gNodeB部署调优实战

简介：针对华为5G上行载波聚合（上行CA）功能的部署与优化，这份文档提供了从原理到现网验证的完整技术指引。面向通信网络工程师、无线优化人员和5G运维人员，内容覆盖上行2CC功能开启的前提条件、TDD+TDD、TDD+FDD及SUL等频段组合的参数配置流程，包括帧偏置核查、异频频点关系设置、CA频点集配置和上行CA开关启用。文档特别整理了终端能力要求与支持机型，并以苏州、南京、南通等地实际试点数据展示上行流量与PRB利用率变化，便于评估热点区域容量提升效果。资源为单个docx文档，压缩包大小6.07MB，内容结构清晰，包含网管命令和实测数据，适合现场对照实施。目前已有128人学习下载，可作为5G网络容量优化的实用参考。

1. 5G上行载波聚合：华为设备多频段组合部署的第一道选择题

做 5G 优化的人都知道，下行速率靠频谱带宽堆出来，上行速率却卡在终端发射功率和频段资源上。上行载波聚合（Uplink CA）就是把多个上行载波绑在一起用，让 UE 同时在一个锚点频段和一个补充频段上发数据，上行峰值能从单载波的几十 Mbps 直接跳到 200 Mbps 以上。华为设备的 FR1 内上行 CA 在现网里已经不是实验室功能，而是实打实的商用特性。但开启它不是敲几条命令那么简单：频段组合选错、PUCCH 格式冲突、功率回退超标，任何一个环节翻车都会让速率不升反降。这篇笔记写给做无线优化和基站侧调测的同行，从原理到 MML 命令再到实测判读，把华为设备上行 CA 的部署流程和踩过的坑一次讲透。

2. 上行 CA 原理与华为设备能力边界：哪些组合值得开、哪些是坑

2.1 上行 CA 的两种基本形态：FR1 内 CA 和 TDD+FDD 互补

上行 CA 在 5G NR 里分成两大类：FR1 内 CA 和 FR1+FR2 跨频段 CA。现网华为设备上最常用的是前者，具体又分为 TDD+TDD 和 TDD+FDD 两种组合。TDD+TDD 组合典型如 n78+n79，两个频段都是时分双工，时隙配比一致，调度器相对好做；TDD+FDD 组合如 n78+n1，FDD 频段作为补充上行（SUL 或普通辅载波），可以用 FDD 的持续上行能力弥补 TDD 上行时隙不足的问题。

从 UE 角度看，上行 CA 开启后，终端要在两个频段上同时维持发射链路，这意味着射频前端要支持双发射（Dual Tx）。很多早期的 5G 终端只支持单发射，即便基站侧开了 CA，UE 能力上报里没有对应 band combination，调度器也不会真正把辅载波调度起来。所以部署前第一件事不是配参数，而是确认现网终端的 UE 能力。华为设备在小区级开关之外，还有 UE 能力相关的门限检查，终端不支持就是空转。

2.2 华为设备的上行 CA 功能框架：从 NRUCell 到 ULCarrierAggr

华为 gNodeB 的上行 CA 配置涉及几个关键对象：主载波小区（PCell）、辅载波小区（SCell）、上行 CA 策略组和频段组合表。开局时要在 LST NRDUCELLCA 里确认小区级 CA 开关状态，在 MOD NRDUCELLCA 里打开上行 CA 使能开关。然后通过 ADD NRUCELLSCELL 把辅载波小区绑定到主载波上，这一步要指定 SCell 的频点、带宽和 PCI 等基础信息。

我一般会建议先查一遍现网版本对上行 CA 的支持矩阵，不同版本的华为 L2T 脚本字段名会有差异。比如在某个 21 年以后的版本里，NRDUCELLCA 的 UlCaSwitch 参数从枚举型改成了位图型，旧脚本直接 COPY 过来会报参数类型不匹配。这类问题很隐蔽，出错日志不会说"参数不对"，而是报"配置冲突"或者"对象不存在"。

2.3 频段组合的选择逻辑：优先 FDD 辅载波还是 TDD 辅载波

选择频段组合时，要综合考虑三件事：频谱资源占用、终端支持率和干扰协调复杂度。FDD 频段做辅载波的好处是上行时隙不受 TDD 帧结构限制，尤其是 n1/n3 这类低频段，覆盖好，UE 在远点也能发；坏处是 FDD 频段通常带宽只有 10-20 MHz，对速率贡献有限，而且和 LTE 共享频谱时还要留出保护带。

TDD 频段做辅载波则相反，n79 有 100 MHz 带宽，速率提升明显，但 TDD 上行时隙占比一般只有 30%-40%，如果主载波和辅载波时隙配比不一致，调度器要处理跨载波的时隙对齐，复杂度直接上升。华为设备里有个参数叫 UlCaSchedMode，控制跨载波调度策略，默认是独立调度，如果发现辅载波利用率上不去，可以尝试切到联合调度模式，但这会增加 PDCCH 开销，需要实测权衡。

2.4 参数规划前的容量评估：不要只看峰值速率

上行 CA 的收益除了峰值速率，更重要的是小区边缘吞吐量和时延稳定性。单载波时边缘 UE 的发射功率全部压在一个载波上，功率受限导致 MCS 阶数上不去；上行 CA 开启后，数据分流到两个载波，每个载波上的功率谱密度降低，反而能提升边缘用户的调制阶数。华为设备里有个参数叫 UlCaPwrSplitMode，控制两个载波间的功率分配策略，推荐先用水位线模式（WaterFilling），让调度器按信道质量动态分配功率。

做容量评估时要关注的指标不是上下行峰值速率，而是上行 PRB 利用率和误块率（BLER）。上行 CA 开启后，如果调度器把数据都堆在主载波上，辅载波的 PRB 利用率长期低于 30%，说明参数没调到位。我见过一个现场，上行 CA 开了快两周，上行速率只涨了 12%，查后台发现辅载波利用率只有 8%——原因是辅载波的小区级开关开了，但 UE 级别的 CA 能力门限被误配成了"仅限 5G 极简终端"，现网八成终端都被过滤掉了。

3. 华为 gNodeB 上行 CA 配置实战：从 MML 命令到参数核对

3.1 开局准备：检查版本、License 和 UE 能力

实操的第一步是核对设备和版本信息。通过 LST LICENSE 确认上行 CA 功能 License 已加载，没有 License 的情况下即便配置下发成功，功能也不会生效，而且网管日志里只会有一条 FFA 告警，很容易被当成噪音忽略。版本方面，查一下 VERSION 里的产品版本号，对照华为的版本说明书确认支持的上行 CA 频段组合列表。不同版本支持的 band combination 数量差很多，比如某个早期版本只支持 n78+n1，后续版本才加了 n78+n79 和 n1+n28。

UE 能力的核验有两种方式：一是通过信令跟踪看 UE 能力上报里的 CA 相关字段，二是直接在后台用 DSP UE 查询终端的支持频段。现场如果有一批测试终端，建议先确认这些终端的组合支持情况，再决定要不要在测试区域只开某个特定组合。华为设备还支持按 UE 能力过滤 CA 小区组，参数在 NRDUCELLCA 的 CaUeCapFilter 里，默认是不过滤，但考虑到老终端在 CA 模式下可能出现异频测量性能下降，我一般会建议现网开启"仅 CA 能力 UE"过滤。

3.2 MML 配置流程：核心命令与参数含义

华为设备的无线侧配置都是通过 MML（人机语言）完成的。先查现网配置，再逐条修改，最后激活。以下是一套典型的上行 CA 配置流程（基于常见版本的命令格式，字段名以实际版本为准）：

// 1. 查询小区 CA 配置现状 LST NRDUCELLCA:; // 2. 打开主载波小区的上行 CA 开关 MOD NRDUCELLCA: LOCELL=1, ULCaSwitch=ON, UlCaSchedMode=JOINT_SCHED;

第一条命令用于基线核查，确认要修改的小区位置和 ID；第二条命令打开上行 CA 总开关。UlCaSchedMode 建议先设成 JOINT_SCHED 让调度器跨载波联合调度，观察辅载波利用率后再决定是否改回独立调度。如果版本的字段枚举值和这里不一致，可以用 LST NRDUCELLCA 的输出反查。

接着是添加辅载波小区和绑定关系。注意，辅载波小区可以是逻辑小区，也可以是物理小区，这里以逻辑小区绑定为例：

// 3. 添加辅载波逻辑小区，n1 频点 2110MHz，带宽 20M ADD NRUCELLSCELL: LOCELL=1, SCELLID=101, SCELLTYPE=LOGIC, EARFCN=100, BAND=1, BW=20M;

ADD NRUCELLSCELL 里的 SCELLID 是辅载波的逻辑 ID，EARFCN 是频点号，BAND 是频段编号，BW 是带宽。这里有一个很关键的点：SCELLID 不能和现网已有的物理小区 ID 冲突，否则会在后续做小区建立时出现 PCI 混淆。我遇到过一个人把 SCELLID 配成了现网某个宏站的 PCI，结果告警刷了一整页。

3.3 上行 CA 策略组与测量配置

辅载波绑定完成之后，还要配置 CA 策略组和测量事件。华为设备的上行 CA 策略通过添加策略组并绑定小区实现：

// 4. 创建上行 CA 策略组，设置辅载波添加门限和去激活门限 ADD NRCASTRATEGYGRP: STRATEGYID=1, COMMITTEDPRB=80, MAXUERES=200; // 5. 将策略组绑定到小区和频段组合 SET NRCELLCASTRATEGY: LOCELL=1, STRATEGYID=1, BANDCOMBN="N78_N1";

COMMITTEDPRB 是 CA 用户可用的 PRB 预约数，设太小辅载波分配不到资源，设太大又会影响非 CA 用户的体验。MAXUERES 是 CA 策略组可承载的最大用户数，这个参数决定了一个小区里同时能做上行 CA 的 UE 上限。BANDCOMBN 里填的就是前面说的频段组合标识，华为设备的命名规则是"N78_N1"这种下划线拼接格式，个别版本会写成"N78+N1"，配置前用 LST NRCASTRATEGYGRP 的输出格式做对照。

测量配置方面，上行 CA 的辅载波添加依赖异频测量。需要在测量对象里添加辅载波所在频点，并设置 A4 事件门限：

// 6. 配置异频测量对象和 A4 事件，门限 -110dBm ADD NRMEASOBJ: MEASOBJID=1, EARFCN=100, MEASBAND=20M; ADD NREVENTA4: MEASOBJID=1, A4THRESHOLD_RSRP=-110;

A4 门限的意思是当主载波 RSRP 低于该门限时触发异频测量，用于判断是否满足添加辅载波的条件。这个门限的取值直接决定了上行 CA 的生效范围：设成 -105 以下，边缘用户基本用不上 CA；设成 -95 以上，近点用户会频繁添加辅载波，但远点用户的辅载波 SINR 太差，反而拖累整体速率。我一般建议先用 -100 起步，再根据实测的辅载波 BLER 回退。

3.4 配置核查与激活：三步确认法

配置下发后不能急着测速率，按三步做核查。第一步用 LST NRDUCELLCA 确认所有小区的 ULCaSwitch 状态都是 ON，第二步用 LST NRUCELLSCELL 核对辅载波绑定关系，第三步用 DSP NRDUCELL 看小区状态是否为激活态。辅载波小区如果处于未激活态，上行 CA 不会生效，但网管上不会有告警，只有话统里能看到 SCell 建立成功率极低。

激活操作要谨慎，辅载波小区激活会触发一次小区中断，现网操作建议在凌晨进行：

// 7. 激活辅载波小区 ACT NRUCELLSCELL: SCELLID=101;

激活后立即用 DSP NRUCELLSCELL 看辅载波状态，正常情况下应该显示 NORMAL。如果显示 BLOCKED 或 OFF-LINE，先从传输链路和 RRU 通道状态查起，不要急着改参数。

4. 性能验证：上行速率提升的实测方法与指标判读

4.1 测试方案设计：从定点到拉网的分层验证

上行 CA 的性能验证分三个层次：近点定点测试、中远点定点测试和拉网路测。近点（RSRP 在 -70 dBm 以上）测的是上行 CA 的峰值能力，关注是否达到理论速率；中远点（RSRP 在 -95 到 -85 dBm）测的是功率回退下 CA 是否还能增益；拉网路测则验证 CA 添加和释放的稳定性，关注频繁切换场景下的掉链问题。

定点测试的工具组合我常用的是路测软件加华为的 U2020 信令跟踪。第一轮测试先看基站侧的上行调度情况，用 DSP 命令查两个载波的 PRB 利用率，如果两个载波利用率都超过 50%，说明调度器分配合理；如果辅载波利用率低于 20%，停掉测试，先看辅载波是否真的有数据流量，再查 UE 能力和测量报告。

4.2 速率测试的关键参数与上行 MCS 判读

用终端做速率测试时，要按不同场景设置 TCP 线程数。单线程测出的上行速率受 TCP 窗口限制，一般达不到峰值；多线程（8-16 线程）才能让 RLC 层和 PDCP 层的队列被充分填充。速率测试应该持续至少 60 秒，前 10 秒的速率是 TCP 拥塞窗口爬坡阶段，直接取平均值会把结果拉低。

速率之外一定要看上行 MCS 阶数。上行 CA 开启后，如果两个载波的 MCS 阶数差异超过 4 个等级，说明功率分配不均衡——信号好的载波拿到的功率不够，信号差的载波又分到太多功率。华为后台的 Uplink MCS 统计按载波分别输出，对比主辅载波的 MCS 分布就能定位问题。实际操作中，我习惯先看 PHR（功率余量报告），上行 CA 场景下 PHR 分为 Type1 和 Type2，Type2 反映两个载波联合的功率余量，如果 Type2 PHR 长期为 0，说明终端功率受限，这时候应该调整 UlCaPwrSplitMode。

拿一张常见参数表做对比：

4.3 话统指标与信令判读：区分是配置问题还是无线环境问题

话统层面重点看三类指标：SCell 建立成功率、上行 CA 用户占比和辅载波上行业务量占比。SCell 建立成功率低于 95% 时，先在信令跟踪里找建立失败原因，常见的 failure cause 是"Radio Network Layer Failure"和"UE No Response"，前者多为参数或传输问题，后者多为空口丢包。

信令判读要看三个关键消息：RRC reconfiguration 里是否携带 SCell 配置、Measurement Report 里异频测量结果是否达到 A4 门限、以及 UE 的 RRC Complete 里是否回带 SCell 配置确认。一个很容易误判的场景是：Measurement Report 里测到了辅载波频点且 RSRP 达标，但 UE 一直不报支持 CA 的 band combination，导致 gNodeB 不下发 SCell 配置。这种情况在终端侧看是"手机支持 5G"，但实际支持的组合只有 n78+n1，没有 n78+n79，而基站侧配的是 n78+n79，两边对不上，速率当然上不去。

4.4 性能验证的验收标准

上行 CA 的验收不能只盯峰值速率，要同时满足以下四条才建议正式商用：近点上行吞吐率较单载波提升至少 60%；中远点（RSRP -90 dBm 附近）提升至少 30%；SCell 建立成功率不低于 98%；上行 CA 用户占比不低于激活用户数的 30%。第四条很关键，如果 CA 用户占比太低，说明门限或能力过滤把大部分用户挡在 CA 之外，即便峰值速率看着漂亮，整网平均体验也没提升。

验证过程中如果发现速率提升不达预期，优先检查的不是 CA 参数，而是主载波本身的调度时隙占比。有的场景把上行 CA 开在 TDD 频段上，主载波上行时隙只有 30%，辅载波也是 TDD，两个载波加起来的上行时隙还是 30%，只是每个时隙里能用更多 PRB，速率提升自然远低于 FDD 辅载波的场景。所以验收前先算清楚两个频段的时隙配比叠加后的理论增益，而不是拍脑袋定一个 100% 的提升目标。

5. 避坑指南：上行 CA 开启后的常见问题与排查路径

5.1 辅载波明明配了，但利用率始终是 0

现象：后台配置全部下发成功，辅载波小区状态正常，但话统里辅载波的 PRB 利用率连续数小时为 0，上行平均速率没有变化。

原因：UE 的测量报告里没有上报辅载波频点的测量结果，或者上报了但 gNodeB 判定不满足 SCell 添加条件。排查后发现是异频测量gap 配置冲突——主载波当前配置的异频测量 gap 周期是 40ms，但辅载波频点需要 80ms 的 gap，测量始终无法完成。

解决：修改 gap 配置，把异频测量的 gap 周期调整为满足两个频段测量的更小值；或者关闭异频测量的周期限制，让 UE 持续测量辅载波频点。在华为设备上通过 MOD NRMEASOBJ 的 GapPara 字段调整，建议在凌晨操作，因为修改会触发测量配置重发，可能短暂影响在线用户的切换。

5.2 上行 CA 开启后，边缘用户 BLER 飙升

现象：近点用户的速率提升符合预期，但远端用户（RSRP 低于 -100 dBm）的上行 BLER 从 5% 涨到 15%，重传率翻倍。

原因：辅载波添加门限设得太宽，远端 UE 的两个载波上行 SINR 都很差，但调度器强制在两个载波上同时调度，功率被拆分后每个载波的有效 SINR 进一步下降，导致 BLER 飙升。

解决：收紧 A4 门限或依赖辅载波去激活机制。把 A4 门限从 -105 改成 -100，让远端用户不要触发 SCell 添加；同时检查辅载波去激活门限（A2 事件），确保信道恶化时 UE 能及时释放辅载波。另外，UlCaPwrSplitMode 从 WaterFilling 改成静态功率比模式，避免调度器在边缘场景过度拆功率。

5.3 配置命令返回"参数冲突"，但命令格式检查过没问题

现象：MOD NRDUCELLCA 执行后返回"参数与现网配置冲突"，命令回滚，修改不生效。

原因：现网存在跨小区的 CA 策略绑定冲突——同一个辅载波小区已经被绑定到另一个主载波小区，或者该辅载波被配置为 Carrier Aggregation 之外的其他角色。

解决：用 LST NRUCELLSCELL 查所有绑定了该辅载波的小区列表，确认没有重复绑定；再用 DSP NRUCELLSCELL 查辅载波当前的承载角色。如果辅载波同时被 LTE 侧配置为共享小区，需要先在 LTE 侧释放资源。实际操作中这条报错经常让人怀疑是版本 bug，但绝大多数情况是前后台数据不一致，重启 U2020 客户端再查一次往往就能看到真实状态。

5.4 测试终端速率只能跑一个载波的量级

现象：测试终端显示已连接两个频段，但上行速率始终在单载波水平，后台看两个载波都有调度，但调度 RB 数不对等。

原因：终端的能力上报里，上行 CA 的最大 MIMO 层数是 1 层，但基站侧配置了 2 层上行 MIMO，导致 UE 在每个载波上只能发 1 层，调度器按 2 层做功率分配，功率资源浪费在空余层上。

解决：在基站侧把辅载波的上行 MIMO 模式配置为和 UE 能力匹配的 1 层模式，或者找支持 2 层上行 MIMO 的终端做测试。这个问题比较隐蔽，因为无线侧告警不会出现，只有对比单载波和双载波的 TBS（传输块大小）才能发现每载波吞吐只有预期的一半。

5.5 凌晨配置后，早高峰出现 PUCCH 冲突告警

现象：上行 CA 开启后第二天早高峰，网管出现 PUCCH 资源冲突告警，部分用户的 PUCCH 解调失败，导致上行调度请求丢失。

原因：上行 CA 新增的辅载波也需要 PUCCH 资源，但配置时没有为辅载波单独分配 PUCCH 格式 1 和格式 2 的资源，默认配置和主载波复用，在用户多的时候发生碰撞。

解决：在 ADD NRUCELLSCELL 或后续的 MOD 命令里显式配置辅载波的 PUCCH 资源参数，包括 PUCCH 格式 1 的起始 PRB 和循环移位个数。配置后观察 PUCCH 冲突告警是否清除，同时确认辅载波的 ACK/NACK 反馈是否正常。

6. 进阶技巧：TDD+FDD 上行 CA 联动的调优习惯

TDD+FDD 组合是上行 CA 里最能出效果也最考验调优功力的场景。以 n78+n1 为例，n1 的 FDD 上行带宽只有 20 MHz，但它是全时隙上行，一个子帧里每个时隙都能发数据；n78 有 100 MHz 带宽，但上行时隙占比只有 30%。两者叠加后，上行速率不是简单相加，而是要按"有效上行 PRB 数"重新算——n78 的 100 MHz 在 30% 上行时隙下等效于 30 MHz 全上行，n1 的 20 MHz 等效于 20 MHz 全上行，合计等效 50 MHz，这才是理论增益的基准。

调优的关键在于两个频段的上行调度优先级和时隙对齐。华为设备里有个参数叫 UlCaTddFddOffset，控制 TDD 主载波和 FDD 辅载波的上行调度时刻偏移量，默认是 0，即完全对齐。但在 TDD 小区上行时隙和 FDD 小区上行子帧边界存在偏移时，不对齐反而能错开调度高峰，降低 PDCCH 冲突概率。我一般会在不同偏移量下各测一轮速率和 BLER，选一个综合表现最好的值。

另一个容易被忽视的点是，FDD 辅载波在覆盖上通常好于 TDD 主载波，此时与其让 UE 在远点做 CA，不如考虑把上行数据全部调度到 FDD 频段上——在华为设备里通过配置辅载波上行优先调度的策略实现。这个策略在特定场景下的效果比 CA 更明显，但会占满 FDD 上行资源，影响后续其他载波的扩容。

从那以后，我每次做上行 CA 的参数调整，都强制自己走一遍"版本核对、UE 能力抽查、频段组合算增益、话统验证利用率"的流程，不再拿着命令模板直接套。尤其是在升版本之后，先看版本说明书确认字段没变，再动现网。这种习惯救过我不少次，希望帮到你。

本文还有配套的精品资源，点击获取