企业官网建设流程全解析

简介：这是一份聚焦5G非独立组网（NSA）接入信令流程的图解文档，面向网络优化工程师、基站测试人员以及通信专业学习者，用于理清终端在LTE与NR双连接场景下的接入信令交互路径。文档从演进分组核心网下的NSA双连接概述入手，系统拆解辅站添加总流程、UE初始附着、RRC建立过程、UE能力查询和接入测量等关键模块；在辅站添加场景中，逐步说明LTE初始接入、B1测量上报、RRC重配置、随机接入以及数据转发与用户面路径更新，帮助读者建立从测量触发到辅站同步的完整信令视图。压缩包为1个PDF文件，共1.26MB，内容精炼，逻辑分段清晰，适合作为日常外场分析或考前速查的参考资料。目前已有1223人学习下载，尤其适合需要快速掌握NSA信令流程并定位接入问题的工程人员。

1. 5G NSA接入信令：从看得懂到调得动的第一步

一份基础版的NSA接入信令流程图摆在眼前，RRC建立、B1测量上报、SgNB添加、RRC重配置，每个信令都能对上；可真到现场，SgNB添加成功率卡着不动、接入时延压不下来，却不知道该动哪个参数。5G NSA的信令流程从来不缺文档，缺的是讲清楚“原来这样、改成那样、为什么改”的改进逻辑。这份改进篇正是在标准NSA接入信令链路上砍时延、捡失败、加回退。适合刚接触LTE/NR双连接优化的网优工程师、核心网信令分析岗，以及做互操作测试的无线测试工程师，目标是看完能把改进点落成参数、能从日志里验证它生效。

2. 标准接入链路的四个关键信令和一张时延账本

2.1 NSA接入的总体信令架构：MN、SN各管哪一段

5G NSA组网（Option 3系列）里，UE同时连着LTE和NR两个网：LTE是主节点MN，管RRC连接、移动性决策和信令面；NR是辅节点SN，主要负责数据承载。用户面可以在MN和SN之间分流，但控制面始终走MN这条链路。换句话说，用户在5G上“接入成功”与否，决定权其实在LTE侧的RRC流程里，这也是NSA信令分析和SA完全不一样的地方——SA的信令全在NG接口上，NSA的大部分关键信令绕着LTE和Xn接口转。

改进篇的所有改动，都集中在“MN决定加SN、SN把无线配置交还MN、MN再下发给UE”这一段。理解了这个职责划分，后面看改进点就不容易乱：凡是涉及RRC重配的，主责在MN；凡是涉及资源预留的，主责在SN；凡是涉及两段时延的，都绕不开Xn接口。5G网络架构下的NSA接入，本质上是一次跨系统的协同，任何一端慢了，整条链路的接入时延都慢。

2.2 从B1测量到承载建立：标准时序与每段时延

标准NSA接入的基础信令流程，按工程上最常见的实现可以拆成七步：

1. UE已在LTE完成RRC连接建立和服务请求，MN通过RRC重配置给UE下发NR测量配置，事件通常用B1，也就是NR邻区质量高于绝对门限。
2. UE测到NR小区信号满足门限，上报B1测量报告，里面带着PCI、RSRP/RSRQ，以及NMR里的其他NR邻区信息。
3. MN在Xn接口向gNB发送SgNB Addition Request，请求gNB为UE准备一个PSCell。
4. gNB完成内部资源预留和算法判决后，回SgNB Addition Request Acknowledge，NR侧无线配置装在一个NR RRC容器里。
5. MN把NR配置封装进RRCConnectionReconfiguration下发给UE，LTE侧的字段和NR侧配置一起带上。
6. UE在目标NR小区发起随机接入（通常走免竞争随机接入），成功后回RRCConnectionReconfigurationComplete。
7. MN收到Complete后，向gNB发SgNB Reconfiguration Complete，NR数据面DRB开始传输。

这七步对应着四段时间：T1是B1上报到MN发出SgNB Addition Request的处理时延，T2是Xn接口的往返时延加gNB准备时延，T3是MN下发RRC重配到UE完成重配的时延，T4是NR侧随机接入和同步时延。总的NSA接入时延大致等于T1加T2加T3加T4，改进篇后来做的所有减法，都是在砍这四段里的可压部分。

关键信令的失败影响，工程上可以这样归类：

2.3 标准流程在现网暴露的三个瓶颈

标准流程在实验室里很干净，一上现网就暴露问题。第一个瓶颈是Xn往返太慢。SgNB Addition的Ack要等gNB内部调度、资源预留、算法判决，如果Xn传输链路质量一般，T2可能轻松超过上百毫秒，极端情况下直接超时。这个时候问题往往不在无线参数上，而在传输侧。

第二个瓶颈是测量配置过于保守。B1门限设得很低，UE在NR弱覆盖区也上报，gNB资源准备之后很快就删除，形成反复的SgNB添加和删除，信令消耗大，失败率也被拉高。很多工程师一开始都会下意识调高门限，但门限高了又容易漏报，这是后文避坑部分重点展开的地方。

第三个瓶颈是失败没有回退。SCG建立失败之后，一些实现会直接释放RRC连接，或者反复重发SgNB Addition Request，用户感知就是“明明连着LTE，5G图标却起不来”。标准流程里SCG失败后留给MN的处置空间很小，改进篇加的回退机制就是在这一段补窟窿。

3. 改进篇的四套改法：参数怎么定、开关怎么落

3.1 改法一：B1门限与TTT重标定，让测量上报更有价值

改进篇对测量配置最典型的改动，是让B1事件不要在NR覆盖刚过门限时马上触发，而是等信号稳定后一次到位。工程上的做法是重新标定三个参数：B1门限、迟滞和TTT（Time To Trigger）。其逻辑是减少无效上报，让MN收到的测量报告尽量对应“真正可用的NR覆盖”，而不是瞬时波动带来的假信号。

参数标定前，我一般先拉全网MR数据，统计NR小区参考信号的RSRP分布，取P10和P50作为门限调整依据。中心城区和郊区要分开标定，一条默认值打天下基本都会出问题。参考基线如下：

参数表里最容易被忽略的是TTT和门限的联动。门限抬高后，如果TTT还是0，UE在信号快速变化场景下会为了赶上报窗口反而错失最优小区；反过来，TTT调太高，车辆快速驶入NR覆盖区时又会迟迟不上报。快衰落场景和慢衰落场景要分别出参数方案，这是我做接入信令优化时最常强调的联动关系。

3.2 改法二：SgNB添加从“单小区”变成“候选列表”

标准流程里，B1上报后MN按最强小区生成一条SgNB Addition Request，只带一个目标PSCell。如果这个gNB内部资源不足，或者目标小区恰好遇到PCI混淆、上行干扰，这次添加只能失败，整套流程从头再来。改进篇的做法是把“单点押注”改成“候选列表”。

具体实现上，UE的NMR里通常不止一个NR邻区，MN把Top N个小区作为候选PSCell列表放进SgNB Addition Request，gNB收到请求后对列表里的多个小区做资源预留，首选小区资源不可用时直接激活次选小区。工程上常见的N值取2到3，超过3个对成功率提升不再明显，却会让Xn信令体明显变大，反而拖慢T2。

落地时要确认两件事：基站版本是否支持候选PSCell这个feature，以及gNB侧是否配置了对应的资源预留策略。很多项目改完没效果，查到最后是SN侧压根没开资源预留，MN发再多候选也没有用。

3.3 改法三：RRC重配合并下发和MN侧处理提速

标准流程里，MN要等收到SgNB Addition Ack才开始组装RRCConnectionReconfiguration，组装过程要把LTE侧的sCell信息、NR侧的rrmsi配置、RLC和MAC配置一层层封装。这个组装耗时往往被忽略，但在T3里占比不小。

改进方向有两个。一是把可提前计算的配置合并生成，减少MN侧的组装耗时，让RRC重配消息一次带齐字段，而不是分多个IE逐条填充；二是调整MN侧SgNB准备等待定时器。这个定时器控制MN等待gNB回Ack的最大时长，默认值常见在5秒左右，如果Xn质量好，收紧到3秒能明显减少失败样本的等待时间，用户感知就是“失败得快一点，重试得也快一点”。

需要提醒的是，定时器收紧不是越小越好。如果Xn链路本身有抖动，把定时器压得过低，会把本来能成功的添加变成超时失败。改这个参数之前，先看一眼Xn接口控制面的RTT统计，拿P99值作为设定依据。

3.4 改法四：SCG失败回退，给接入失败留一条后悔药

改进篇里最值得抄的一项改动是SCG失败回退机制。原来的流程里，SCG建立失败或者后续SCG承载失败，MN往往直接释放整个RRC连接，或者长时间等待重发，用户侧体验很差。回退机制的思路是：UE上报SCGFailureInformationNR给MN，MN收到后不释放连接，而是把受影响的SCG承载回退到MN承载上，也就是LTE侧的承载，用户继续有数据业务，后台再决定要不要重新添加SN。

这条改法在信令特征上很容易辨认：回退流程里，MN下发的是只包含LTE侧承载变更的RRC重配，且后续不会再出现SgNB Reconfiguration Complete消息。判断回退是否生效，就抓这两条。

但回退不是万能的，它只能解决无线侧失败，解决不了Xn链路中断。Xn传输断了，回退信令本身也送不到SN，这时候再强的回退机制也白搭。所以回退开关打开之前，先确认传输侧有监控手段。

4. 用网管信令跟踪验证改进：log特征对照与一条时延SQL

4.1 抓一次完整NSA接入：网管信令跟踪的操作步骤

改进参数上了网，第一步不是看KPI曲线，而是先抓一次真实的接入信令，确认改进点在log上真的能看出来。常见做法是在华为5G网管这类平台上开UE级信令跟踪，按IMSI过滤最干净，能排除同小区其他用户的信令干扰。操作步骤大致是这样：

1. 在网管打开信令跟踪功能，跟踪对象选IMSI或TAC，建议直接填测试终端的IMSI。
2. 测试终端在目标区域做飞行模式重启，或直接重新附着，复现一次完整NSA接入。
3. 跟踪结束后导出log，优先导出原始ASN.1消息或解码后的表格，按消息名过滤关键信令。
4. 把MN侧log和SN侧log按时间戳对齐，跨网元的时延对比必须保证两端时钟一致，时钟差会直接毁掉所有时延结论。
5. 按下一节的log特征对照表逐项核对，确认功能是否真的生效。

抓包时有个小细节：不要开干扰排除，DT测试时尽量让终端原地别动。终端一移动，log里会混入大量重传和测量更新，干扰对改进点的判断。

4.2 改进前后的信令特征对照表

改进是否生效，靠KPI只能看到结果，靠log才能看到过程。整理一份对照表，每次改完参数都按这个表核对，线上排查能省下大量时间：

对照表里最容易误判的是最后一行。回退生效的标志是SCGFailureInformationNR消息出现，并且后续RRC重配里不再包含NR配置字段；如果log里只有SCG失败上报，没有后续的重配下发，那说明回退流程在MN侧并没有走通。

4.3 一条SQL看SgNB添加时延和改进效果

信令log适合看单次流程，真正要评估改进对整个网络的效果，还得靠话单或性能库。下面这条SQL是从XDR信令话单里统计一次NSA接入的关键时延，字段名需要按你网管话单实际定义替换：

SELECT imsi, cell_id, MAX(CASE WHEN msg_type = 'SGNB_ADD_REQ' THEN msg_time END) AS t_req, MAX(CASE WHEN msg_type = 'SGNB_ADD_ACK' THEN msg_time END) AS t_ack, MAX(CASE WHEN msg_type = 'RRC_RECONF_COMPLETE' THEN msg_time END) AS t_rrc_done FROM xdr_signaling_log WHERE start_time >= '2025-01-01 00:00:00' AND start_time < '2025-01-02 00:00:00' GROUP BY imsi, cell_id HAVING t_req IS NOT NULL;

这段SQL的逻辑是：按IMSI和小区聚合，分别取出SgNB添加请求、添加应答、RRC重配完成三个关键时间点。t_ack减去t_req就是Xn接口准备时延，也就是前文的T2，如果改造后大部分样本这个差值还超过80毫秒，重点去查Xn传输和gNB资源预留速度。t_rrc_done减去t_ack是MN下发重配到UE完成重配的T3时延，这个值偏大通常和RRC消息大小、空口质量有关。

要注意的是，这条SQL默认log表里每个流程的消息时间已经按事件排列，如果有跨网元时间偏差，算出来的T2和T3都不准。跑SQL之前先把两边log的时间戳偏差量出来，这是经常被忽略的一步。

5. 落地避坑：五个现场最容易翻车的改动组合

5.1 坑一：B1门限抬高后，SgNB添加成功率反而下降

现象：调完B1门限，SgNB添加成功率没升，反而掉了一个百分点，切换和重选指标也一起变差。

原因：门限抬高让UE在信号快速变化的场景（比如楼宇拐角、高架下）错过上报窗口。UE等信号稳定了再上报，但此时UE已经驶入NR弱覆盖区，gNB的资源准备和实际无线条件对不上，添加自然失败。

解决：门限和TTT一定要配套调，不能只动一个。快衰落场景把TTT降到240毫秒左右，慢衰落场景保持在320到640毫秒。改完至少观察三天的MR分布曲线，不要当天就下结论，更不要拿一个站点的指标代表全网。

5.2 坑二：候选PSCell列表在现网UE身上直接重配失败

现象：版本开关开了、参数也配了，KPI没变好，反而RRC重配失败次数新增，失败小区集中在某个终端型号上。

原因：老版本终端的NR能力字段不支持多候选PSCell的RRC容器解析，收到不认识的新增IE后直接回重配失败。这是典型的“网络侧升级了，终端侧没跟上”。

解决：升级开关前先拉现网终端能力统计，看UE-EUTRA-Capability里的NR能力位。支持率低于阈值就保持单小区模式，等终端版本更新后再开；同时升级网管解码库，否则log里也看不到新字段。

5.3 坑三：定时器一收紧，Xn抖动路段出现假失败

现象：gNB侧所有信令都正常，MN侧却报SgNB添加超时，失败样本集中在某个传输质量差的区域。

原因：Xn控制面RTT本来就不稳定，收紧定时器相当于把偶发的传输抖动直接变成了无线侧失败。KPI上看是SgNB添加失败，根因却在传输。

解决：先测Xn链路RTT的P99值，以它作为定时器设置的依据，而不是看平均值。传输质量没有保证之前，定时器收紧等于把传输侧故障转嫁成无线KPI问题，这种教训在组网与运维场景里很常见。

5.4 坑四：log里看不到新字段，就判定功能没生效

现象：改进上线一周，网管抓包log里还是看不到候选PSCell字段，有人直接判定功能没生效。

原因：大部分情况不是真没生效，而是网管解码库版本太老，ASN.1里新增的IE没被解出来。基站侧feature开关和网管显示开关有时候是两级控制，网管没开显示同样看不到。

解决：先查基站版本feature开关，再查解码插件版本，最后用原始ASN.1人工解析一条消息确认。别把一个解码问题当成KPI问题去处理，先分清楚是“没做”还是“没显示”。

5.5 坑五：把SCG失败回退误判成切换失败

现象：切换失败率突然飙高，优化团队查了半天切换参数，发现方向完全错了。

原因：SCG失败回退流程里，MN下发的是带LTE承载变更的RRC重配，统计上很容易被归到切换失败类别。实际信令是由SCGFailureInformationNR触发的，和切换没有关系。

解决：用信令类型区分。只要出现SCGFailureInformationNR，且后续RRC重配里不再带NR配置，就是SCG回退而不是切换失败。KPI分类规则先理清楚，再谈后续优化，否则指标治理就是在空转。

6. 闭环：从投诉工单到接入信令的一次回溯

6.1 一次投诉工单的倒推验证

接到“5G没有图标、网速上不去”的投诉，别急着把参数改回去，先倒推三步。第一步，用IMSI拉当天的信令跟踪，看SgNB添加是没触发、触发了没成功、还是成功了很快就释放，三种情况对应的整改方向完全不同。第二步，把该小区的改进参数核对一遍，B1门限有没有改歪、候选小区功能开关在gNB和网管两端是否一致，线上最常见的脱节点就在这两处。第三步，用当天话单统计接入时延分布，重点看T2和T3，T2波动大先查Xn传输，再去怀疑无线参数；T3偏大再看RRC重配消息大小和空口质量。

这三步走完，大部分投诉都能归到无线覆盖、参数标定、传输抖动这三类问题之一。我个人的习惯是，每次改完参数不看KPI曲线，先翻信令log确认改进特征真的存在；线上很多玄学问题，其实是验证方法先入为主，漏掉了关键证据。希望帮到你。

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