5G NSA接入信令流程详解：从RRC连接到SCG添加的完整链路与优化实践

简介这份PDF文档聚焦5G NSA非独立组网接入信令流程面向5G网络优化、核心网与无线侧工程师及通信专业学习者帮助读者理清终端从LTE平滑过渡到NR双连接的关键信令交互与资源分配逻辑。资源为1个PDF文件压缩包约1.26MB内容以图文信令流程与参数说明为主便于对照空口消息逐条研读。文档系统梳理了NSA双连接概述、辅站添加总流程、UE初始Attach流程、RRC建立过程、5G接入测量过程及UE能力查询等模块重点解析测量事件B1上报、SgNB Addition Request与Acknowledge、RRC连接重配置、随机接入同步以及SCG Split Bearer用户面路径更新等环节并给出Measobjectlist、Reportconfiglist、Measidlist等测量配置的对应关系。目前已有1222人学习适合需要深入理解NSA接入信令细节、排查双连接建立问题的读者参考。1. 5G NSA接入信令流程从RRC连接到核心网注册的完整链路NSA组网下终端开机后第一件事不是直接连5G而是先锚定4G。这个反直觉的结论是很多刚接触5G信令的工程师踩过的第一个坑——以为NSA就是“4G5G同时连”实际上终端必须先通过LTE的RRC连接建立、Attach流程完成EPC注册再通过LTE侧下发的NR测量配置去搜索5G小区最后用B1事件触发辅节点添加。整个过程涉及RRC、S1-MME、X2-C、NG-C等多条信令链路任何一环超时都会导致“有5G图标但速率上不去”的玄学问题。这篇内容面向需要排查NSA接入失败、优化接入时延的无线侧和核心网侧工程师把从RRC连接请求到SCG添加完成的信令序列拆开给出可复现的抓包过滤方法和参数检查清单。5G NSA接入信令流程改进篇的核心价值在于把“终端为什么不上报B1事件”“辅节点添加为什么被拒”这类问题定位到具体信令节点而不是靠重启基站碰运气。2. NSA接入的信令分层与关键节点谁在什么时候发了什么2.1 从RRC到NG-CNSA接入涉及的四条信令链路NSA接入不是单一协议栈能讲清楚的。终端侧走的是LTE Uu口的RRC基站侧要同时处理LTE的S1-MME和NR的X2-C或NG-C取决于架构选项。常见做法是把整个接入过程按链路拆成四段来看第一段是LTE Uu口终端从RRC_IDLE态发起RRCConnectionRequest携带的establishmentCause通常是mo-Signalling或mo-Data。基站回RRCConnectionSetup终端回RRCConnectionSetupComplete这条消息里会带NAS层的Attach Request。第二段是S1-MME口eNB把Attach Request封装在Initial UE Message里发给MMEMME走鉴权、安全模式、位置更新最后回Initial Context Setup Request。第三段是X2-C口eNB通过X2口向gNB发送SgNB Addition Request携带UE的NR测量结果和SCG配置建议。第四段是NR Uu口终端收到RRCConnectionReconfiguration带mobilityControlInfo和SCG配置后在NR侧发起随机接入成功后回RRCConnectionReconfigurationComplete。这四段链路里X2-C的SgNB Addition Request是最容易出问题的地方。很多现场反馈“LTE附着成功但5G一直不添加”抓包一看eNB根本没发Addition Request原因是B1事件的测量配置没下发或者终端没上报。这里的关键参数是measConfig里的a3-Offset和b1-ThresholdNR前者管LTE内部切换后者管NR小区触发。注意NSA架构下NR侧没有独立的RRC_IDLE态终端在NR侧只做随机接入和RRC连接重配不发起NAS流程。所有NAS信令都走LTE锚点。2.2 抓包过滤与信令序列还原用Wireshark看X2-C和S1-MME现场排查最直接的手段是抓包。如果能在eNB和gNB之间的X2口镜像流量或者从核心网侧抓S1-MME用Wireshark过滤出关键信令序列比看计数器快得多。下面是一组常用的过滤表达式和对应的信令节点# 抓S1-MME口上的Initial UE Message和Initial Context Setup tshark -i eth0 -f sctp port 36412 -Y s1ap.procedureCode 12 || s1ap.procedureCode 10 # 抓X2-C口上的SgNB Addition Request和Acknowledge tshark -i eth1 -f sctp port 36422 -Y x2ap.procedureCode 27 || x2ap.procedureCode 28 # 抓LTE Uu口的RRCConnectionReconfiguration需要空口采集设备 tshark -i radio0 -Y lte-rrc.rrcConnectionReconfiguration_element -V第一行命令里s1ap.procedureCode 12对应InitialContextSetup 10对应InitialUEMessage。这两个是LTE附着和上下文建立的核心。第二行里x2ap.procedureCode 27是SgNBAdditionRequest 28是SgNBAdditionRequestAcknowledge。如果只看到27没看到28说明gNB侧拒绝了添加要去查gNB的准入控制和资源状态。第三行需要空口采集设备普通网卡抓不到Uu口但可以用高通QXDM或者基站侧的空口监测工具替代。参数说明sctp port 36412是S1-MME的标准端口36422是X2-C的标准端口。如果现场用了非标端口需要先确认基站配置。过滤表达式里的procedureCode是S1AP和X2AP协议里的过程码不同厂商的设备可能用私有扩展但标准过程码是一致的。2.3 B1事件与A3事件的参数差异为什么终端不上报NR测量B1事件和A3事件是NSA接入里最容易混淆的两个测量事件。A3事件用于LTE同频或异频切换触发条件是邻区比服务小区好一个偏移量。B1事件用于异系统测量触发条件是NR邻区质量高于一个绝对门限。NSA接入依赖的是B1事件不是A3。常见配置里eNB通过RRCConnectionReconfiguration下发measConfig里面包含measObjectNR和reportConfigNR。reportConfigNR里的事件类型是eventB1关键参数有参数名典型值作用b1-ThresholdNR-105 dBmNR小区RSRP高于此值才触发上报timeToTrigger320 ms满足门限后持续多久才上报hysteresis2 dB防乒乓的迟滞triggerQuantityrsrp用RSRP还是RSRQ触发maxReportCells8最多上报几个NR小区如果b1-ThresholdNR设得太高比如-90 dBm而现场NR覆盖又弱终端永远不会上报B1。如果timeToTrigger设得太长比如1280 ms接入时延会明显增加。我一般会先把b1-ThresholdNR降到-110 dBmtimeToTrigger改成160 ms确认能上报后再逐步收紧。另一个坑是measObjectNR里的carrierFreq和subcarrierSpacing。如果这两个配错了终端根本搜不到NR小区。carrierFreq要填NR的绝对频点号ARFCNsubcarrierSpacing要跟实际配置一致15 kHz或30 kHz。现场见过把subcarrierSpacing写成15 kHz但实际是30 kHz的终端扫不到SSB自然不上报。3. 用QXDM和基站侧日志复现一次完整的NSA接入3.1 终端侧QXDM抓包配置与关键日志项终端侧最常用的工具是高通QXDM配合QCAT看信令。配置步骤如下第一步连接终端在QXDM里选择对应的端口通常是DIAG口。第二步加载配置文件勾选LTE RRC、NR RRC、NAS、S1AP如果终端侧能抓到等模块。第三步开始记录然后让终端从飞行模式切回正常模式触发一次完整接入。第四步停止记录用QCAT打开isf文件过滤出信令消息。关键日志项包括LTE RRCRRCConnectionRequest、RRCConnectionSetup、RRCConnectionSetupComplete、RRCConnectionReconfiguration、RRCConnectionReconfigurationCompleteNR RRCRRCConnectionReconfigurationNR侧、RRCConnectionReconfigurationCompleteNR侧NASAttachRequest、AttachAccept、AuthenticationRequest、SecurityModeCommand在QCAT里可以用“Find”功能搜索“SgNB”或“B1”快速定位到辅节点添加相关的消息。如果看到RRCConnectionReconfiguration里带了nr-SecondaryCellGroupConfig说明eNB已经下发了SCG配置终端接下来应该在NR侧发起随机接入。# 用pyshark解析QXDM导出的pcap提取NSA接入关键信令 import pyshark def parse_nsa_access(pcap_file): cap pyshark.FileCapture(pcap_file, display_filterlte-rrc || nr-rrc) events [] for pkt in cap: if hasattr(pkt, lte_rrc): if rrcConnectionSetupComplete in str(pkt.lte_rrc): events.append((LTE, RRCSetupComplete, pkt.sniff_time)) if rrcConnectionReconfiguration in str(pkt.lte_rrc): events.append((LTE, RRCReconfig, pkt.sniff_time)) if hasattr(pkt, nr_rrc): if rrcConnectionReconfigurationComplete in str(pkt.nr_rrc): events.append((NR, RRCReconfigComplete, pkt.sniff_time)) cap.close() return events # 输出时间线计算各阶段时延 events parse_nsa_access(nsa_access.pcap) for i in range(1, len(events)): delta events[i][2] - events[i-1][2] print(f{events[i-1][1]} - {events[i][1]}: {delta.total_seconds()*1000:.1f} ms)这段代码的逻辑是用pyshark加载pcap文件过滤出LTE RRC和NR RRC消息提取关键信令节点的时间戳然后计算相邻节点之间的时延。参数说明display_filter里的lte-rrc和nr-rrc是Wireshark的协议过滤器pyshark会自动调用tshark解析。sniff_time是抓包时间戳单位是秒转成毫秒后可以直观看到哪一段耗时最长。如果LTE RRCSetupComplete到RRCReconfig之间的时延超过200 ms通常是S1-MME或X2-C的传输问题。3.2 基站侧日志的采集点与时间对齐基站侧日志比终端侧更全但时间对齐是个麻烦事。eNB和gNB的日志时间戳可能不同步差几百毫秒很常见。我一般会先在核心网侧抓S1-MME以InitialUEMessage的时间为基准再去对齐eNB和gNB的日志。eNB侧要看的日志点RRC连接建立、S1接口的InitialUEMessage发送、X2接口的SgNBAdditionRequest发送。gNB侧要看的日志点X2接口的SgNBAdditionRequest接收、准入控制结果、SgNBAdditionRequestAcknowledge发送。如果gNB侧日志显示“admission control reject”原因可能是PRB资源不足、UE能力不匹配、或者SCG配置不支持。时间对齐的常见做法是在eNB和gNB上同时开启NTP确保时间戳误差在10 ms以内。如果做不到就用信令里的UE ID比如eNB UE S1AP ID和gNB UE X2AP ID来关联同一终端。X2AP的SgNBAdditionRequest里会带eNB UE X2AP IDgNB回的Acknowledge里带gNB UE X2AP ID这两个ID可以串起整个流程。3.3 接入时延的分解与优化目标一次完整的NSA接入从RRCConnectionRequest到NR侧RRCReconfigurationComplete典型时延在300到500 ms之间。分解下来LTE RRC连接建立50-80 msS1-MME Attach和鉴权100-150 msB1测量上报取决于timeToTrigger通常80-160 msX2-C SgNB Addition20-50 msNR随机接入40-80 ms优化目标是把总时延压到250 ms以内。最有效的三个手段第一把timeToTrigger从320 ms降到160 msB1上报能快80 ms左右。第二把S1-MME的鉴权流程和X2-C的Addition Request并行化有些厂商支持在Initial Context Setup完成前就发Addition Request但这需要核心网配合。第三优化NR侧的随机接入配置把SSB周期从20 ms改成10 ms随机接入时延能降10-20 ms。提示不要盲目追求低时延。timeToTrigger降得太低会导致B1误报终端频繁尝试添加辅节点但实际NR质量不够反而增加接入失败率。建议先观察一周的B1上报成功率再决定是否收紧。4. NSA接入信令流程的避坑与排查五个现场血泪经验4.1 坑一终端显示5G图标但SgNB Addition Request从未发出现象终端状态栏显示5G但测速只有LTE水平QXDM里看不到SgNB Addition Request。原因eNB没有下发B1测量配置或者下发了但终端没有上报。常见根因是measConfig里的measObjectNR配置错误比如carrierFreq填了LTE的频点而不是NR的ARFCN。解决在QXDM里检查RRCConnectionReconfiguration消息确认measObjectNR里的carrierFreq和subcarrierSpacing。用基站侧命令查询NR小区的实际频点对比配置是否一致。如果carrierFreq错了终端根本不会去搜NR小区。4.2 坑二B1事件上报了但gNB拒绝添加现象QXDM里能看到MeasurementReporteventB1但X2-C口没有SgNBAdditionRequestAcknowledge或者Acknowledge里带了reject原因。原因gNB准入控制失败。常见根因是PRB资源不足、UE能力不支持NR双连接、或者SCG配置里的band组合不支持。解决查gNB的准入控制日志看reject的具体原因。如果是PRB不足检查gNB的负载和调度策略。如果是UE能力问题查终端上报的UE Capability里有没有支持EN-DC的band组合。如果是band组合不支持需要调整SCG的band配置或者升级终端固件。4.3 坑三NR随机接入失败导致SCG添加超时现象终端收到了RRCConnectionReconfiguration带SCG配置但在NR侧随机接入失败最终SCG添加超时eNB回SgNBAdditionRequestReject。原因NR侧的随机接入配置和终端不匹配。常见根因是preamble格式、SSB周期、或者RACH资源配错了。解决检查NR小区的SSB配置和RACH配置。用QXDM看NR侧的随机接入尝试确认终端发的preamble和gNB期望的是否一致。如果SSB周期是20 ms但终端按10 ms去搜会错过SSB导致随机接入失败。把SSB周期和RACH配置对齐后问题通常能解决。4.4 坑四S1-MME和X2-C的UE ID映射错误现象核心网侧看到InitialUEMessage里的eNB UE S1AP ID和X2-C里的eNB UE X2AP ID对不上导致后续的SCG修改或释放流程失败。原因eNB在分配UE ID时S1AP和X2AP用了不同的池或者分配逻辑有bug。解决查eNB的UE ID分配日志确认S1AP和X2AP的ID是否来自同一个UE上下文。如果厂商实现是分开的需要在X2AP消息里显式携带S1AP的UE ID做关联。这个坑在跨厂商组网时特别常见建议在对接测试阶段就验证UE ID的一致性。4.5 坑五NSA接入成功后速率不达标现象SCG添加成功终端显示5G但下行速率只有200 Mbps远低于NR理论峰值。原因常见根因是NR侧的MCS等级低、PDCCH聚合等级高、或者SCG的承载配置不合理。解决查NR侧的调度日志看MCS和RB分配。如果MCS一直很低检查SINR和CQI上报。如果PDCCH聚合等级高说明信道质量差需要优化NR覆盖。另外检查SCG bearer的split比例如果LTE锚点承载了大部分数据NR侧自然跑不满。调整split比例让NR侧承担更多数据。5. 用B1事件参数微调把NSA接入时延压到200毫秒以内B1事件的参数微调是NSA接入优化里性价比最高的手段。不需要改硬件不需要升级核心网只调几个RRC参数就能看到明显效果。我一般会按这个顺序来第一步把b1-ThresholdNR从-105 dBm降到-110 dBmtimeToTrigger从320 ms降到160 ms。这一步通常能省80-120 ms。但要注意降得太狠会导致B1误报终端在NR质量不够时就尝试添加反而增加失败率。建议先观察一周的B1上报成功率如果成功率低于95%就把门限回调5 dB。第二步把hysteresis从2 dB降到1 dB。迟滞越小B1触发越快但乒乓风险增加。在NR覆盖稳定的场景下1 dB是安全的。如果现场NR覆盖波动大保持2 dB。第三步把maxReportCells从8降到4。上报的NR小区少了测量报告的消息长度短了空口传输时间能省几毫秒。但前提是前4个小区里一定有可用的否则会漏掉最优小区。第四步检查measObjectNR里的subcarrierSpacing和carrierFreq。这两个参数错了前面三步全白做。我习惯用基站侧命令查NR小区的实际配置然后逐字对比RRC消息里的值。# 用scapy构造RRCConnectionReconfiguration里的measConfig仅用于仿真验证 from scapy.layers.lte_rrc import MeasConfig, ReportConfigNR, MeasObjectNR def build_b1_config(threshold-110, ttt160, hysteresis1): meas_obj MeasObjectNR( carrierFreq504990, # NR ARFCN subcarrierSpacing30 # kHz ) report_cfg ReportConfigNR( eventeventB1, b1_ThresholdNRthreshold, timeToTriggerttt, hysteresishysteresis, triggerQuantityrsrp, maxReportCells4 ) return MeasConfig(measObjectNRmeas_obj, reportConfigNRreport_cfg) # 生成配置并打印关键参数 cfg build_b1_config() print(fB1 threshold: {cfg.reportConfigNR.b1_ThresholdNR} dBm) print(fTime to trigger: {cfg.reportConfigNR.timeToTrigger} ms) print(fHysteresis: {cfg.reportConfigNR.hysteresis} dB)这段代码用scapy的LTE RRC层构造了一个measConfig参数是上面提到的优化值。carrierFreq504990对应3.5 GHz频段的NR ARFCNsubcarrierSpacing30 kHz是n78频段的典型配置。实际部署时这些值要从基站侧查询后填入不能照抄。代码的作用是验证参数组合是否合法以及生成配置片段供基站脚本调用。微调之后用QXDM抓一次完整接入看LTE RRCSetupComplete到NR RRCReconfigurationComplete的时延。如果降到200 ms以内说明参数生效了。如果没降检查X2-C的传输时延和gNB的准入控制时间。我见过X2-C传输时延占了80 ms的案例原因是eNB和gNB之间的传输网络走了太多跳这种只能靠网络改造解决调参数没用。最后一个习惯每次调完B1参数至少观察24小时的接入成功率和切换成功率。NSA接入和LTE切换是联动的B1参数改激进了LTE侧的A3事件可能受影响。我一般会在调参后第二天看KPI如果接入成功率掉了0.5个百分点以上就回退到上一组参数。这个后悔药比事后写故障报告强。希望帮到你。本文还有配套的精品资源点击获取