5G NSA接入信令改进实战：压时延、防风暴、快接入

简介：一份面向5G网络工程师、通信协议测试及移动通信学习者的专业文档，系统讲解5G NSA非独立组网接入信令流程。内容从NSA双连接概述入手，说明终端如何同时连接LTE与NR基站实现数据分流，随后围绕辅站添加总流程逐步拆解LTE初始接入、NR测量控制下发、B1测量上报、SgNB Addition请求与响应、RRC连接重配、终端同步与随机接入等关键环节，并专门解析RRC建立过程、三次UE能力查询以及5G接入测量参数细节。资源为单个PDF文件，大小1.26MB，目前已有1223人学习下载。文档中直接给出了关键信令名称、测量对象与上报配置的关联方式，以及数据转发和用户面路径更新的实现思路，适合需要理解5G接入信令交互、开展网络优化或准备通信认证考试的读者作为技术参考资料。

1. 5G NSA接入信令流程改进：从“能接入”到“快接入”的那几百毫秒

拉网测试最磨人的一幕：NSA手机明明已经显示了“5G”图标，但你打开速率测试页面，总要等上一两秒才见流量跑起来。这时很多人怀疑空口速率不够，其实问题往往出在信令面——从LTE锚点站发起NR小区测量，到SgNB（辅站）添加成功，这中间的信令交互是串行的，每一跳都在等回执。5G NSA接入信令流程改进的核心，就是把这段“能接入但接得慢”的过程压短：省掉冗余的测量配置，合并重叠的RRC重配，把SCG承载建立从排队改成并行。这篇文章不是写给入门读者的科普，而是给正在做NSA组网优化、信令分析、以及终端协议栈联调的人看的实战记录：先立住标准流程的骨架，再讲改进方案怎么落地、参数怎么调，最后是抓包验证和踩坑复盘。

2. 先立骨架：NSA双连接接入信令在改什么，哪些信令点值得动刀子

2.1 节点、接口与角色分工：谁在发信令，谁在等回执

NSA（非独立组网）和SA最大的区别，是控制面锚定在LTE网络上，NR不单独练摊。终端在LTE小区完成RRC连接建立和附着之后，再通过双连接的方式“挂”一个NR小区当辅站。这时候网络架构里的角色分成三拨：LTE eNB是Master Node（MN），NR gNB是Secondary Node（SN），核心网走的是EPC而不是5G Core。放在Option 3x组网下，用户面数据可以从SN直通核心网，但控制面信令全部由MN转发——这就决定了NSA接入流程的咽喉在MN侧的调度和转发效率。

接口上需要同时盯住三条链路。Uu口是MN和SN分别和终端之间的空口，信令承载RRC消息；X2/Xn口连接MN和SN，跑SgNB Addition Request这类辅站管理信令；S1口连接MN到MME，处理终端上下文和承载相关流程。我见过不少刚转NSA优化的人只盯空口日志，结果SCG添加时延卡在X2传输上，空口再优化也没有用。要改接入信令流程，先把这四条消息路径在脑子里立起来：终端→MN（RRC）、MN→SN（X2AP/XnAP）、终端→SN（NR随机接入）、MN→MME（S1AP）。

2.2 标准接入流程的三个串行热点：从测量上报到SCG承载建立

标准NSA接入流程可以压缩成一条时间线：终端先在LTE驻留并完成RRC连接，MN下发A2测量，A2事件在LTE信号低于门限时触发，MN再下发B1测量去搜索NR邻区；终端上报B1测量结果后，MN发起SgNB Addition Request给候选gNB，SN准备资源并回复Acknowledge；MN生成携带NR小区配置的RRCConnectionReconfiguration下发给终端；终端在NR小区发起随机接入，回RRCConnectionReconfigurationComplete；最后网络侧完成SCG承载建立和用户面切换。

如果只看这条时间线，会发现三个地方存在“排队等待”。第一个热点是A2和B1两条测量配置是分开下发的——终端先报A2，MN再费一趟信令下发B1测量配置，终端还要再测量一遍NR邻区，这一来一回就是几十毫秒的空闲等待。第二个热点是SN资源准备和MN侧RRC重配消息生成是严格串行的——MN必须等SN回复Acknowledge才能拼RRC消息，SN如果忙，终端就干等着。第三个热点是随机接入和重配完成之间的交互——终端在NR发起随机接入后，必须等网络侧把SCG承载激活完成，整个流程才算落地。这三处串行热点，正是改进篇要动刀子的位置。

2.3 改进的二层含义：压时延、降信令开销，还是抗高并发抖动

“改进”这两个字在NSA接入信令流程里通常有两层含义。第一层是压缩单用户的接入时延，把上述三个串行热点的等待时间压下去，比如把A2和B1测量配置合并一次下发，把SN资源准备和RRC消息生成改成并行；第二层是控制高并发场景下的信令开销——NSA组网里一个LTE小区往往带多个NR小区，如果每个终端都在同一时间段触发A2→B1→SgNB添加，MN侧X2口和SN侧资源准入会瞬间被打满，信令风暴比空口拥塞更致命。

所以，改进并不是推翻标准协议重新发明流程，而是在3GPP定的信令框架里做时序和参数的“外科手术”。改之前要先回答一个问题：当前系统到底慢在哪一段。是空口测量慢，还是X2来回慢，还是SN资源准备慢？不看数据就调参数，属于瞎猜。下一章我会把最常见的三个改进方向拆开讲：怎么合并测量配置、怎么把SgNB添加改并发、怎么给准入控制加保险。

3. 落地改进：并发化、测量门限与准入控制的联动调参

3.1 把SCG添加从串行改成并发：一张信令时序对照

我最早做的改进，是把B1测量配置提前合并到A2测量配置里一起下发。标准做法里终端必须等A2上报后才会收到B1测量配置，等于一次测量流程拆成两轮RRC信令。改进后，MN在首次下发A2测量时就把B1测量对象和上报条件一起配好，终端测完A2直接接着测NR，省掉一整趟RRC配置往返。这个改动纯靠网管侧的测量配置下发逻辑就能完成，不需要动终端协议栈。

第二步是处理SgNB资源准备和RRC重配生成的串行关系。先看一张时序对照，理解改动前后的差异。

改并发不是无脑并行。常见做法是让MN预先组装好RRCConnectionReconfiguration的公共部分，SN侧资源准备完成的同时，MN本地流程也推进到等SN配置片段的关口。SN的Acknowledge一到，MN只做字段拼接和序列号填充，省掉原本“收到Acknowledge才开始组装整条RRC消息”的串行等待。这里要说清楚边界：SN配置片段没到，RRC消息不能发，时序上只是把MN侧的准备工作提前，真正卡SN响应时间的逻辑没有消失。

3.2 A2/B1测量门限与TTT：十个参数里先调这四个

测量配置合并是“结构手术”，而决定改进效果的真正玄学在测量门限和上报时机上。NSA场景下最容易影响的参数是A2门限、B1门限、迟滞（hysteresis）和触发时间（TTT）。这四个参数互相牵制，调错了典型后果是“5G图标亮了但数据不跑”或者“终端在LTE和NR之间反复横跳”。

下面这组参数值以我调过的宏站组网为基准，不同厂家略有差异，但量级可作为起始参考。

调参请按三步走。第一步，A2门限参考LTE弱覆盖的实际分布来设——NR覆盖重叠区域大，A2可以放宽到-108~-112 dBm，让终端尽早启动NR测量；第二步，B1门限比A2高5~10 dB，保证终端只在NR信号确实可用时才发起SgNB添加，不建议A2和B1设成同一数值；第三步，TTT先取320 ms跑一周，如果SCG添加成功率没问题但时延偏长，再逐级降到160 ms，同时观察乒乓切换率。记住TTT不是想调多小就多小，我后面会在避坑章节专门讲。

3.3 防信令雪崩：准入控制与资源预留跟上

并发化和门限放宽的直接后果是SCG添加请求密度变大。一个LTE锚点小区下挂了十几个NR小区，门限一放宽，忙时可能同时涌入几十个SgNB Addition Request。SN侧资源准备是实时计算的，请求一多，响应时间会指数级恶化，最终结果比不改还慢。所以做接入信令改进，必须同步做两件配套：SN侧准入控制和MN侧请求限流。

SN侧常见做法是启用基于负载的SCG准入：候选gNB在收到SgNB Addition Request时，先查自身的PRB利用率和现网用户数，超过阈值直接拒绝或延迟响应。阈值一般取75%~85%的PRB利用率，留出裕量给已接入用户的调度。MN侧则要加“SgNB添加请求速率限制”，按每小区每秒的请求数做令牌桶控制，防止瞬时洪峰把X2接口打满。这两个联动是改进能安全上线的前提——先保住系统稳定，再去追求那几十毫秒的收益。

4. 用抓包和日志把改进点“钉”在时间轴上：三板斧

4.1 抓哪几个接口：Uu、X2/Xn、S1/NG各看什么

信令改进无法靠网管指标凭空判断，必须看到原始信令交互。NSA场景下抓包位置有三个：Uu口的空口日志（在终端侧采集，能看到RRC测量配置、测量上报、RRCConnectionReconfiguration和重配完成）；X2/Xn口（在MN和SN之间的传输链路镜像，能看到SgNB Addition Request/Response的每一跳时延）；S1口（看MME相关流程，排查核心网侧是否有额外等待）。靠单接口抓包永远只能看到一半真相——空口日志显示重配下发慢，但慢在X2还是慢在SN资源准备，必须对照X2口时间戳才能定位。

我一般会同时开两路采集：一路在终端侧记录空口RRC消息，一路在MN侧镜像X2/Xn链路。两路时间戳通过NTP或GNSS对齐，误差控制在毫秒级。如果两路时间对不齐，后面计算时延瀑布就没有意义。

4.2 拉一条“时延瀑布”：从B1上报到RRC重配完成的四段耗时

采集到原始信令后，下一步是把各段事件的时间戳拉成一条“时延瀑布”。这里给一个用于解析CSV格式信令日志的小脚本，事件类型可以按你的抓包工具导出格式调整：

import csv import sys from collections import defaultdict # 输入格式：time,event,ue_id # event 取值示例：b1_report, sgNB_add_req, sgNB_add_ack, rrc_reconfig, rrc_reconfig_complete durations = defaultdict(lambda: {"b1": None, "add_req": None, "add_ack": None, "reconfig": None, "complete": None}) with open(sys.argv[1], newline="", encoding="utf-8") as f: for row in csv.DictReader(f): t = float(row["time"]) ev = row["event"].strip() ue = row["ue_id"].strip() d = durations[ue] if ev in d: d[ev] = t for ue, d in sorted(durations.items()): if None in (d["b1"], d["add_req"], d["add_ack"], d["reconfig"], d["complete"]): continue # 事件不完整，跳过 t_report_to_add = d["add_req"] - d["b1"] # 测量上报到MN发起SgNB添加 t_sn_prepare = d["add_ack"] - d["add_req"] # SN侧资源准备耗时 t_air = d["complete"] - d["reconfig"] # 空口下发到终端回执 t_scg_total = d["complete"] - d["b1"] # 总SCG添加时延 print(f"UE {ue}: report->add {t_report_to_add*1000:.0f}ms | SN prepare {t_sn_prepare*1000:.0f}ms | air {t_air*1000:.0f}ms | total {t_scg_total*1000:.0f}ms")

脚本逻辑很简单：按UE ID把五类事件的时间戳归组，分别相减得到四段耗时。参数说明：事件名必须和导出的CSV列值完全一致，不一致的情况建议先unique一把event列再映射；time列单位是秒，脚本内乘1000换成毫秒输出；如果某UE事件缺失，脚本会跳过，避免用残缺数据算出畸形结果。实际使用时，建议至少统计三五十个UE的样本，取P50和P90，不要拿单条数据下结论。

4.3 改进前后必须留档的对比基线

没有基线就没有改进。上改动之前，先用上面的脚本把现网或测试环境的SCG添加时延分布跑出来，至少记录三个指标：SCG添加时延（从B1上报到RRC重配完成）、SgNB添加成功率（SgNB Addition Request收到Acknowledge的比例）、RRC重配失败率（下发RRCConnectionReconfiguration后未收到Complete的比例）。这三个数据连同日期、版本、参数配置一并留档。

改进上线后，用同一套脚本、同一个时段窗口、同一批终端型号复测。对比时注意剔除偶然性：凌晨值班时测出来的“改良数据”说服不了任何人。后面第6章我会细讲怎么回归验证。

5. 避坑：NSA接入信令改进最容易翻车的5个现场

5.1 “并发化之后PDCP重配丢包了”：时序错位引发的乱序

现象：SCG添加成功后，下行数据出现明显乱序甚至重复，TCP吞吐上不去。原因：并发化把RRC重配生成提前了，但SN侧用户面承载激活没有同步完成，PDCP层序号的分配在两个节点之间出现错位。解决：在MN侧设定“用户面切换等待SCG承载确认”的强制时序，PDCP重配消息必须等SN返回SCG承载激活成功后才能发出；如果确实需要并发，给SN侧开启PDCP序号预分配，让MN和SN在RRC重配前就知道彼此的起始序号。

5.2 “测量事件配了但就是不上报”：被DRX周期吞掉的B1

现象：日志里下发了B1测量配置，终端始终不上报NR测量结果，SCG添加一直不触发。原因：终端处于DRX（非连续接收）长周期，测量上报机会被DRX周期拉长到几百毫秒甚至秒级；TTT配置过长会进一步推迟上报。解决：核查终端的DRX配置，把相关DRX周期从320 ms降到80~160 ms；TTT先保持320 ms，确认上报稳定后再逐级下调。这里最容易让人误判为门限问题，实际是测量机会的“节流”。

5.3 “并发SCG添加把MME和SN打爆了”：没限流的改进等于自杀

现象：门限放宽加并发化上线后，忙时SgNB添加请求暴增，SN侧CPU飙升，MME信令面出现排队，部分UE接入直接失败。原因：只改了接入流程，没有增加准入控制和请求限流。解决：SN侧启用基于PRB利用率的SCG准入，阈值设在75%~85%；MN侧对SgNB添加请求做令牌桶限流，按每小区每秒10~20次的量级控制。改进不是让请求“更快地一起到”，而是让请求“更快地有序到”。

5.4 “RRC重建后SCG一直挂起，手机变单连接”：重建流程漏了SN恢复

现象：终端在NR侧RLF后触发RRC重建，重建成功但SCG一直没有恢复，业务长期走LTE，5G空口资源白白浪费。原因：MN侧重建流程只恢复了LTE RRC连接，没有触发SN侧的恢复或重新添加流程。解决：在MN的RRC重建处理逻辑里增加SCG状态判断：重建完成后如果终端能力仍支持双连接，立即触发SN Modification或走一次轻量SgNB添加，把SCG带回active状态。这个问题在改进后更容易发生，因为并发化让SCG建立更积极，反而加深了重建后恢复不及时的落差。

5.5 “5G图标亮了又灭，乒乓到怀疑人生”：A2门限调得太激进

现象：终端在NR和LTE之间频繁切换，RSRP一抖动就触发释放NR，回到LTE没过两秒又发起SCG添加。原因：A2门限设得过高，LTE信号稍有波动就判定“该去NR了”，而B1门限与A2门限间隔太近，形成乒乓。解决：保留LTE锚点余量，A2门限宜低不宜高（-110 dBm以下），B1门限比A2高5~10 dB，同时把TTT设置到320 ms做缓冲。真正可靠的做法是用A2和B1联合判定：A2触发NR测量，但SCG添加必须等B1持续满足TTT后才发起。

6. 验证一套改进是否真生效：三个指标与一套回归

6.1 三个必须死磕的指标

验证改进效果，少盯着“平均值好看”的假象，盯三个硬指标：SCG添加时延（B1上报到RRC重配完成的P50与P90）、信令开销（每用户SCG相关信令消息条数，改进后应明显下降）、SCG添加成功率与RRC重配失败率（改进后不能恶化）。加一个辅助指标：乒乓切换率，看每用户每小时在LTE/NR间的往返次数。这四个指标一起看，才能确定“快”是真的快，而不是拿稳定性换的。

6.2 怎么回归才不算“运气好”

回归要设对照组：同一批终端型号、同一时段、同一组小区，改进前和改进后各跑三轮，每轮至少50个接入样本，取P50和P90做对比。场景上要覆盖三种边界：RSRP在门限附近的边缘场景（最容易抖动翻车）、干扰偏高SNR较低的场景（影响随机接入成功率）、高并发场景（每小区同时发起接入的用户数跑到峰值）。改进方案如果只在实验室一次测试里好看，拿到这三类场景大概率会露馅。

我自己的习惯是先把基线脚本做成自动化，每次参数改动后自动出报告，改完参数隔天再看一眼数据。以前我吃过亏：把TTT从320 ms直接压到40 ms，实验室测着接入时延漂亮得很，结果边缘场上一片乒乓，用户投诉“5G网老断”。从那以后我给自己立了个规矩：任何信令参数的改动，先跑基线，再改一半，观察一个完整忙闲循环后才继续动。这个行业里参数优化没有“一次到位”，只有“一步步靠近”。希望这些流程、参数和踩坑记录，能帮你在NSA接入信令改进这条路上少走几步弯路。

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