企业官网建设流程全解析

简介：《中国移动5G-A无线融合新架构白皮书-2024.pdf》是中国移动联合产业合作伙伴在2024年“5G-A技术创新及数智应用发展论坛”上发布的官方技术文档，面向通信行业从业者、网络架构研究人员及5G-A技术学习者。白皮书围绕5G-A无线架构演进的驱动力展开，涵盖政策指引、低空经济与车联网等新业务驱动以及通信、感知、智能化技术融合牵引，并系统剖析网络层面海量资产兼容、业务层面灵活不确定、运营层面投资回报三大挑战。核心章节提出“平滑演进、通专异构、弹性扩容”的架构设计理念，详细阐述CCU、BBU、AAU+等新硬件平台与自组自愈、弹性可伸缩的新组网架构，同时给出前向兼容的系统融合方案、通专异构资源动态共享方案等关键技术路径。资源包为1个PDF文件，大小约2.06MB，结构完整、目录清晰，便于按章节检索研读。目前已有831人学习下载，适合需要把握5G-A无线网络演进方向、理解通感算智融合架构与关键技术选型的读者参考。

1. 5G-A 无线融合新架构到底融了什么：从一份白皮书看运营商的真实意图

5G-A 这个词从 2024 年开始频繁出现在各类技术峰会和运营商集采公告里，但很多人对它的理解还停留在“5G 的加强版”这种模糊认知上。中国移动这份《5G-A 无线融合新架构白皮书-2024》真正值得关注的地方，不是它列了多少项技术指标，而是它第一次系统性地把“无线融合”从一个技术方向上升到了网络架构层面。换句话说，以前我们谈 5G-A，谈的是速率、时延、连接数这些单点能力；这份白皮书谈的是这些能力怎么在同一个无线接入网里被统一调度、统一编排、统一管理。如果你是在做无线侧规划、核心网对接、或者行业专网落地的工程师，这份文档基本决定了他未来两到三年在做的项目该往哪个方向靠。它解决的核心问题是：当 eMBB、uRLLC、mMTC 三类场景在同一张网上并存时，无线资源怎么分、架构怎么搭、运维怎么管。适合谁读？无线规划工程师、核心网对接人员、行业专网集成商，以及想搞清楚运营商 5G-A 到底要干什么的设备商技术人员。

2. 无线融合新架构的技术底座：从协议栈到资源调度的重构逻辑

2.1 为什么传统 RAN 架构撑不住 5G-A 的三类场景并存

传统 5G RAN 的设计逻辑是“一套协议栈服务一类主要场景”。eMBB 基站把大部分时频资源分配给下行大带宽，uRLLC 基站靠预留资源块和短调度周期来压时延，mMTC 基站则用更长的调度周期和更宽松的同步要求来省电。这套思路在单场景专网里没问题，但 5G-A 的目标是在同一套物理设备上同时支撑三类场景，甚至要在同一个小区里动态切换。问题就出在协议栈的刚性上：RLC 层的重传机制、MAC 层的调度器参数、PHY 层的帧结构，都是按场景预设好的，改一个参数往往牵动整条链路。

白皮书里提到的“融合新架构”，核心动作是把协议栈做成分层可配置的。具体来说，RLC 层引入可变的 ARQ 窗口和重传阈值，MAC 层调度器支持多套参数集并行运行，PHY 层则通过参数集 numerology 的动态切换来适配不同场景。这听起来像是软件定义无线电的老思路，但难点在于：这些配置不能靠人工逐站调整，必须由网络级的管理面统一下发。所以架构上多了一个“无线融合编排层”，它向上对接核心网的切片管理，向下把切片 SLA 翻译成具体的 RAN 参数集。

我一般会把这个编排层理解成一个“翻译器”：核心网说“这个切片需要 1ms 时延”，编排层把它翻译成“调度周期 0.5ms、MCS 表偏保守、HARQ 重传不超过 1 次”。这个翻译过程是自动的，但翻译规则需要人工预设。白皮书里没有给出完整的规则表，但从它列出的参数维度来看，至少包括调度周期、MCS 偏置、HARQ 最大重传次数、SR 周期、BFR 触发门限这几类。

2.2 融合架构的三个关键接口与参数映射

要把这套架构落地，必须搞清楚三个接口：N2/N3 接口的切片标识映射、RAN 内部的编排层与 CU/DU 之间的参数下发接口、以及 DU 与 RU 之间的前传接口。前两个是白皮书重点讲的，第三个更多依赖设备商实现。

先看 N2/N3 接口。核心网通过 N2 把切片 ID 和对应的 QoS 参数发给 RAN，RAN 侧需要把这个切片 ID 映射到本地的“无线配置模板”。这个映射关系不是一对一的，因为同一个切片在不同小区可能对应不同的无线参数。白皮书建议的做法是：在编排层维护一张“切片-小区-参数集”的三维表，每个小区根据自身的负载和干扰情况，从参数集里选一套当前最优的。

下面是一个简化的参数映射表结构，我用 Python 字典模拟一下编排层的配置逻辑：

# 切片-小区-参数集映射示例 # 每个切片在每个小区下可以有多套候选参数集，按优先级排序 slice_config = { "eMBB_slice_01": { "cell_001": [ { "priority": 1, "scheduling_period_ms": 1.0, # 调度周期 "mcs_offset": 2, # MCS偏置，正值偏保守 "harq_max_retx": 3, # HARQ最大重传次数 "sr_period_ms": 10, # 调度请求周期 "bfr_threshold": -105 # 波束失败恢复门限(dBm) }, { "priority": 2, "scheduling_period_ms": 0.5, "mcs_offset": 0, "harq_max_retx": 2, "sr_period_ms": 5, "bfr_threshold": -100 } ], "cell_002": [ { "priority": 1, "scheduling_period_ms": 0.5, "mcs_offset": 1, "harq_max_retx": 2, "sr_period_ms": 5, "bfr_threshold": -102 } ] }, "uRLLC_slice_01": { "cell_001": [ { "priority": 1, "scheduling_period_ms": 0.25, # 更短调度周期压时延 "mcs_offset": 3, # 更保守的MCS，减少误码 "harq_max_retx": 1, # 只允许1次重传 "sr_period_ms": 2, "bfr_threshold": -95 } ] } }

这段配置的逻辑是：编排层根据切片 ID 和小区 ID 查到候选参数集列表，然后按优先级选第一套下发。参数说明如下：scheduling_period_ms决定 MAC 调度器多久跑一次，uRLLC 切片设到 0.25ms 是为了把调度等待时间压到最低；mcs_offset是给 MCS 选择加一个偏置，正值表示选更保守的调制编码策略，牺牲速率换可靠性；harq_max_retx限制重传次数，uRLLC 只允许 1 次是为了避免重传带来的额外时延；sr_period_ms是调度请求周期，越短越能快速拿到上行资源；bfr_threshold是波束失败恢复的触发门限，值越低越容易触发恢复流程。

实际部署时，这套配置不会这么简单。白皮书里提到，编排层需要根据实时负载动态调整优先级。比如 eMBB 小区在忙时可以把 uRLLC 切片的参数集降级，把资源让给 eMBB，但前提是 uRLLC 切片的 SLA 还有余量。这个动态调整的算法白皮书没有展开，但给出了一个原则：优先保障 uRLLC 的时延和可靠性，eMBB 的速率可以弹性伸缩。

2.3 从白皮书到现网：融合架构的落地步骤

如果你要在现网里验证这套融合架构，我一般会按下面几步走。第一步是确认设备商支持程度。不是所有 5G 基站都支持多参数集并行，需要确认 CU/DU 的软件版本是否开放了编排层接口。第二步是搭一个最小验证环境：一个 CU、两个 DU、三个小区，分别配置 eMBB、uRLLC、mMTC 三类切片。第三步是灌流量测试，用 iperf 打 eMBB 下行，用 ping 测 uRLLC 时延，用大量 IoT 模组模拟 mMTC 连接。

具体命令层面，核心网侧可以用以下命令查看切片映射状态：

# 查看AMF上注册的切片信息 kubectl exec -it amf-0 -- amfcli slice list # 查看SMF上会话对应的切片QoS kubectl exec -it smf-0 -- smfcli session list --slice-id eMBB_slice_01 # 在RAN编排层查看当前下发的参数集 kubectl exec -it ran-orchestrator-0 -- rancli config show --cell cell_001

这些命令的输出需要和核心网侧的切片 SLA 做比对。如果发现 uRLLC 切片的实际时延超过 1ms，先查编排层下发的scheduling_period_ms是不是被动态调整成了 0.5ms 以上，再查 DU 侧的实际调度日志。

提示：现网验证时不要一上来就开三类切片全跑，先跑 uRLLC 单切片，确认时延达标后再加 eMBB，最后加 mMTC。每加一类切片，观察一轮 KPI，确认没有互相干扰再继续。

3. 融合架构下的资源调度：参数怎么设、冲突怎么解

3.1 三类切片共存时的资源分配策略

融合架构最核心的难点不是协议栈改造，而是资源分配。eMBB 要带宽，uRLLC 要时延，mMTC 要连接数，三者的需求在时频资源上是直接冲突的。白皮书给出的思路是“分级预留 + 动态抢占”。分级预留是指给 uRLLC 预留固定的时频资源块，这部分资源不参与 eMBB 的调度；动态抢占是指当 uRLLC 流量突发时，可以临时抢占 eMBB 已分配但未使用的资源。

预留比例怎么定？白皮书没有给具体数字，但从它列出的仿真结果来看，uRLLC 预留资源占总资源的 10% 到 15% 时，能在保证 1ms 时延的前提下，让 eMBB 的速率损失控制在 5% 以内。如果预留超过 20%，eMBB 的速率损失会超过 15%，就不划算了。

动态抢占的触发条件需要仔细设。我一般会设三个门限：uRLLC 队列深度超过阈值、uRLLC 包等待时间超过阈值、eMBB 资源利用率低于阈值。三个条件同时满足才触发抢占，避免频繁抢占导致 eMBB 体验抖动。

下面是一个简化的抢占判断逻辑：

def should_preempt(urllc_queue_depth, urllc_wait_time_ms, embb_utilization): """ 判断是否触发uRLLC对eMBB的资源抢占 参数： urllc_queue_depth: uRLLC队列中待调度包数量 urllc_wait_time_ms: uRLLC包最长等待时间(ms) embb_utilization: eMBB当前资源利用率(0-1) 返回： True表示触发抢占，False表示不触发 """ URLLC_QUEUE_THRESHOLD = 5 # 队列深度门限 URLLC_WAIT_THRESHOLD_MS = 0.5 # 等待时间门限 EMBB_UTIL_THRESHOLD = 0.7 # eMBB利用率门限 if (urllc_queue_depth > URLLC_QUEUE_THRESHOLD and urllc_wait_time_ms > URLLC_WAIT_THRESHOLD_MS and embb_utilization < EMBB_UTIL_THRESHOLD): return True return False

参数说明：URLLC_QUEUE_THRESHOLD设 5 是因为 uRLLC 包通常很小，队列里超过 5 个包就说明调度跟不上了；URLLC_WAIT_THRESHOLD_MS设 0.5ms 是因为 uRLLC 的时延预算通常是 1ms，留一半给传输和处理；EMBB_UTIL_THRESHOLD设 0.7 是为了确保 eMBB 有足够的空闲资源可以被抢占，如果 eMBB 自己利用率都超过 70%，抢了会出问题。

3.2 调度器参数调优的实操方法

调度器参数调优不能靠猜，得有数据支撑。我一般会先跑一轮基线测试，把三类切片在默认参数下的 KPI 拉出来，然后针对不达标的指标逐个调参。调参的顺序是：先调调度周期，再调 MCS 偏置，最后调 HARQ 重传次数。因为调度周期对时延的影响最直接，MCS 偏置影响的是误码率和速率，HARQ 重传次数影响的是可靠性和时延的平衡。

具体操作上，可以在 DU 侧开一个调试口，实时打印调度器的决策日志。下面是一个日志过滤命令：

# 在DU侧实时查看uRLLC切片的调度决策 kubectl exec -it du-0 -- tail -f /var/log/ran/scheduler.log | grep -E "slice=uRLLC|preempt|scheduling_period" # 统计过去5分钟内uRLLC切片的平均调度等待时间 kubectl exec -it du-0 -- cat /var/log/ran/scheduler.log | grep "slice=uRLLC" | awk '{sum+=$NF; count++} END {print sum/count}'

如果发现平均调度等待时间超过 0.3ms，先把scheduling_period_ms从 0.5 降到 0.25，再观察一轮。如果时延达标了但 eMBB 速率掉得厉害，把mcs_offset从 3 降到 1，让 uRLLC 用更激进的 MCS，减少资源占用。

注意：调scheduling_period_ms时不要低于 0.125ms，因为 DU 的处理能力有下限，再低会导致调度器过载，反而增加时延。

3.3 融合架构下的移动性管理

融合架构对移动性管理的影响经常被忽略。传统切换流程里，UE 从源小区切到目标小区时，目标小区只需要分配一套资源。但在融合架构下，目标小区需要同时分配三类切片的资源，而且切换过程中 uRLLC 切片的时延不能断。白皮书里提到的做法是“预切换准备”：源小区在触发切换前，先把 UE 的切片上下文通过 Xn 接口发给目标小区，目标小区提前把三类切片的资源预留好，等切换命令一下发，uRLLC 资源立即生效。

这个流程对 Xn 接口的时延要求很高。如果 Xn 传输时延超过 2ms，预切换准备就来不及，uRLLC 切片在切换期间会出现断流。我一般会在现网里先测 Xn 时延，如果超过 1.5ms，就得考虑把 CU 下沉或者用更近的 DU 做锚点。

4. 避坑与排查：融合架构落地时最容易翻车的五个地方

4.1 切片 ID 映射错位导致 uRLLC 流量走了 eMBB 参数集

现象：uRLLC 切片的时延始终在 5ms 以上，查调度日志发现 uRLLC 的包被调度到了 eMBB 的参数集上。原因：核心网 N2 接口下发的切片 ID 和 RAN 编排层配置的切片 ID 不一致，通常是核心网侧用了标准切片 ID（如 SST=1），而 RAN 侧配了自定义 ID。解决：在编排层加一个切片 ID 映射表，把核心网的标准 ID 映射到本地 ID，映射关系在 AMF 和编排层同时配置。

4.2 预留资源过多导致 eMBB 速率断崖式下跌

现象：uRLLC 预留资源设了 20%，eMBB 下行速率从 800Mbps 掉到 500Mbps。原因：预留资源是硬预留，即使 uRLLC 没有流量，eMBB 也不能用。解决：把硬预留改成“软预留 + 动态抢占”，预留比例降到 10%，同时开启抢占门限。如果 uRLLC 流量确实大，再考虑增加预留，但不要超过 15%。

4.3 HARQ 重传次数设得太低导致 uRLLC 可靠性不达标

现象：uRLLC 切片时延达标了，但丢包率超过 0.1%。原因：harq_max_retx设成了 1，第一次传输失败后没有重传机会，直接丢包。解决：把harq_max_retx调到 2 或 3，同时把mcs_offset调大，让第一次传输的误码率降低。如果时延因此超标，再考虑用更短的调度周期来补偿。

4.4 编排层与 DU 之间的参数下发延迟导致配置不生效

现象：在编排层改了参数集，但 DU 侧的实际调度行为没变。原因：编排层和 DU 之间的接口是异步的，参数下发后需要 DU 确认，如果 DU 负载高，确认会延迟。解决：在编排层加一个配置版本号，每次下发带版本号，DU 侧收到后先比对版本号，如果比本地新才应用。同时监控下发确认的时延，超过 500ms 就告警。

4.5 移动性场景下 uRLLC 切片断流

现象：UE 在切换过程中，uRLLC 业务出现 10ms 以上的断流。原因：目标小区没有提前预留 uRLLC 资源，切换命令下发后才开始分配，分配过程耗时。解决：开启预切换准备，源小区提前通过 Xn 接口把切片上下文发给目标小区。如果 Xn 时延太大，考虑把 CU 下沉到更靠近 DU 的位置。

5. 从白皮书到现网验证：一套可复现的融合架构测试方法

5.1 最小验证环境的搭建清单

要验证融合架构，不需要一上来就搞全网。我一般会搭一个最小环境：1 个 CU（可以跑在虚拟机里）、2 个 DU（最好用真实设备）、3 个小区（可以是一台 RRU 拉三个逻辑小区）。核心网侧用开源 5GC 或者运营商提供的测试核心网。测试终端方面，eMBB 用一台支持 5G 的 CPE，uRLLC 用一台工业网关，mMTC 用 20 个以上的 NB-IoT 模组。

环境搭好后，先确认 CU 和 DU 之间的 F1 接口正常，再确认 DU 和 RU 之间的前传接口正常。然后依次配置三类切片的参数集，每配一类就测一轮 KPI。

5.2 三类切片的 KPI 采集与比对方法

KPI 采集要分三层：核心网侧看切片 SLA 达标率，RAN 侧看调度器的调度成功率和时延，终端侧看实际业务体验。三层数据要能对上，如果核心网说达标了但终端体验差，说明 RAN 侧的参数集没配对。

下面是一个 KPI 比对表的示例结构：

采集方法：下行速率用 iperf3 打流，上行速率用 iperf3 反向打流，时延用 ping 或者专用时延测试仪，调度成功率从 DU 日志里统计，切换中断时间用终端侧的业务连续性日志。

5.3 参数调优的迭代节奏

调优不是一次性的，得按迭代来。我一般会按“调参-测试-分析-再调参”的循环走，每轮只调一个参数，调完测 30 分钟，看 KPI 变化趋势。如果调一个参数导致另一个 KPI 恶化，说明这两个参数是耦合的，需要一起调。

比如scheduling_period_ms和mcs_offset就是耦合的：调度周期缩短会降低时延，但也会增加调度开销，导致 MCS 选择更保守，速率下降。这时候需要同时调：把调度周期降到 0.25ms，同时把 MCS 偏置从 3 降到 1，让速率回来。

提示：每轮调参后至少观察 30 分钟，因为融合架构的动态调整机制需要时间收敛。不要调完 5 分钟就下结论。

5.4 一个具体的调优案例

我在一个测试环境里遇到过 uRLLC 时延达标但 eMBB 速率掉 30% 的情况。排查发现是 uRLLC 的预留资源设了 15%，而且抢占门限设得太低，eMBB 一有流量就被抢。调整方案：预留降到 10%，抢占门限从“eMBB 利用率低于 0.7”改成“低于 0.5”，同时把 uRLLC 的mcs_offset从 3 降到 2，减少 uRLLC 的资源占用。调整后 eMBB 速率恢复到只掉 8%，uRLLC 时延仍然在 1ms 以内。

这个案例说明，融合架构的调优不是单目标优化，而是多目标平衡。白皮书里给的参数范围是参考，实际值要根据现网负载和业务模型来定。我自己的习惯是：先保 uRLLC 的时延和可靠性，再尽量给 eMBB 留资源，mMTC 只要连接数达标就行，速率和时延都可以放宽。这套优先级顺序在大多数场景下都适用，但如果你的业务模型里 eMBB 是主要收入来源，那就得反过来，先保 eMBB 速率，uRLLC 的时延预算可以适当放宽到 2ms。希望帮到你。

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