尧图网站建设 
简介移动通信从4G到5G核心变化之一在于控制面协议栈的重构。RRC状态机由原有的两种状态扩展出RRC_INACTIVENG-RAN架构引入gNB-CU/DU分离及E1、Xn、F1等新接口信令流程和承载逻辑也随之复杂化。理解这些基础概念是掌握5G空口协议、接口规范与UE行为的关键。无论是协议开发、基站/终端测试还是网络优化中的信令排障都需要从RRC建立、重配、恢复、重建等核心流程切入结合QoS Flow到DRB的映射、PDCP split与duplication增强以及EN-DC双连接下的SRB3路径选择构建一张可对照使用的5G信令全景图。本文基于5G信令基础讲解系统梳理控制面状态机、用户面承载映射及常见踩坑案例帮助工程师快速从LTE视角切换到NR视角提升日志分析与故障定位效率。1. 5G信令讲解从4G到5G控制面变化这份资源到底解决什么问题很多人从LTE转5G第一道坎不在物理层的波束、毫米波或多天线而在RRC信令——RRC_INACTIVE、SRB3、RNAU、SUL、On-demand SI这些概念在4G里根本没有对应物却直接决定了UE状态机怎么跳、连接建立流程怎么走、双连接信令在哪条路径上传输。这份《5G基础信令基础讲解》PPT就是一套偏培训向的协议底稿先从5G相比4G的新特性切到NG-RAN架构再把控制面UE状态、RRC建立/重配/重建/恢复/释放/RLF、统一接入控制、系统信息、寻呼、移动性管理、SUL、EN-DC和用户面新QoS机制、PDCP split与duplication、精简RLC、MAC完整串了一遍。适合协议开发、基站或终端侧测试、以及想补5G信令底子的网优工程师。读完之后你能把“5G新增了什么”变成一张能对照使用的信令流程地图而不是记住一堆孤立名词。2. NG-RAN架构与协议规范底稿36系列和38系列怎么对照着看2.1 NG-RAN架构eLTE和NR如何接入5GC先看架构。PPT里有一句很关键的话eLTE与NR都可接入5G CoreeLTE需要改造以兼容5G Core。这句话决定了你看信令时的大前提——5G接入网不是只有gNB一种节点还有一个ng-eNB也就是eLTE形态用LTE空口接入5G核心网。所以5G接入网的全称叫NG-RAN而不是NR-RAN它是“NG-RAN节点”的集合gNB和ng-eNB都在里面。gNB走NR空口ng-eNB走LTE空口但两者都通过NG接口连到AMF和UPFgNB之间通过Xn接口互联gNB内部再按CU/DU分离拆成gNB-CU和gNB-DU走F1接口。这个架构和LTE最大的差别是LTE的eNB直连EPC一个S1接口就搞定5G的NG-RAN把控制面、用户面拆得更开接口数量成倍增加。你去查信令时如果分不清NG、Xn、F1各自承载什么很容易在日志里对不上号。举例来说EN-DC下SgNB添加流程走的是Xn接口上的SgNB Addition而RRC信令可能从SN侧通过SRB3直接发给UE也可能经MN的SRB1转发两条路径在记录文件里长得完全不一样。再强调一个容易忽略的点gNB的CU/DU分离后gNB-CU又按控制面和用户面拆成gNB-CU-CP和gNB-CU-UP两者之间走E1接口。E1-AP的规范号是38.463很多人第一次看到它时以为是笔误其实它是CU-CP和CU-UP之间的应用层协议。排查用户面问题时你会频繁遇到它。2.2 协议规范地图38系列各规范的位置很多从4G转过来的人第一反应是去翻38.300这没错但38.300只是NR整体白皮书级别的内容。真正干活时你需要的是下面这张对照表这也是这份PPT里我认为最值的部分之一。规范号内容对应4G规范38.300NR整体36.30038.401NG-RAN整体架构36.40138.321NR MAC36.32138.322NR RLC36.32238.323NR PDCP36.32338.331NR RRC36.33138.410/38.413NG接口整体与NG-AP36.410/36.41338.420/38.423Xn接口整体与Xn-AP36.420/36.42338.470/38.473F1接口整体与F1-AP无直接对应38.463E1-AP无直接对应37.340MR-DC多连接无直接对应37.324SDAP无直接对应注意37.340和37.324不在38系列里这是很多人会查漏的地方。MR-DCMulti-RAT Dual Connectivity由37.340专门定义EN-DC、NR-DC都归它管里面包含了MCG、SCG、Split Bearer的完整信令流程SDAP协议独立放在37.324里因为它是5G QoS Flow到DRB映射的入口层LTE里没有对应物。你如果按38系列的编号去找双连接或SDAP的内容大概率会扑空。另外一份值得收藏的对照关系在更高层23.501是5G系统总体架构及功能23.502是5G系统基本流程它们对应LTE时代的23.401。排查跨层信令问题时比如RRC建立失败背后是不是注册流程的问题就需要在RRC层和NAS层之间来回跳这两份规范是必查的。RAN侧的人经常只看空口和NG接口忽略了NAS流程对RRC建立原因的驱动逻辑。2.3 高层特性对照从On-demand SI到eLTE的11项变化PPT把5G相比4G的高层变化总结成了11条我整理成了一张表后面每一章都会反复引用到这里面的某一项特性含义涉及协议层On-demand SI按需获取系统信息不再全部广播RRCInactive state新增RRC_INACTIVE状态RRCSUL补充上行载波MAC/RRCBWP灵活带宽可配置多个部分带宽MACSRB3、Split bearer新承载类型RRC/PDCPDuplicationPDCP冗余传输PDCPLTE-NR DC跨制式双连接RRC/XnRNAU基于RAN area的位置更新RRCFlow vs Bearer新QoS框架SDAP/RRCBeam管理基于波束的链路和移动性管理L1/RRCeLTELTE空口接入5GCNG/RRC这张表建议你打印出来贴在工位上。我见过不少同事把快照放在桌面排查信令时先对着它判断“这个流程是4G没有新增的还是4G改造的”能省很多时间。比如BWP涉及MAC调度的频域资源切换但触发BWP切换的信令却经常由RRC Reconfiguration带下来这属于跨层配合只看MAC必然漏。3. 控制面核心UE状态机与RRC建立、重配、恢复、重建的五步拆解3.1 UE状态机RRC_INACTIVE引入的逻辑PPT里的状态转换表值得仔细看。LTE R8只有RRC_IDLE和RRC_CONNECTED两个状态NB-IoT R13引入了连接挂起/恢复NR R15正式把RRC_INACTIVE定义为标准状态。Inactive态的三个设计特点直接决定了它的用法Uu连接断开但NG连接保持UE、gNB、AMF都保留UE上下文可以做到10ms级别回到连接态RAN notification area由NG-RAN控制可以是cell list、RNA list或TA list的组合RAN-initiated paging允许gNB在RNA范围内直接发起寻呼不需要经过核心网。很多人把Inactive误当成“半idle”这个理解要纠正。Inactive状态下UE不做小区选择重选之外的移动性但核心网侧的会话和承载上下文都还在基站侧的UE上下文也在。正因为上下文保留RRCResume流程才能以短消息的形式快速恢复SRB2和DRB。你去看PPT里状态机表格有一行是“5GC控制的寻呼区域”在idle为是、inactive为否“NG-RAN控制的寻呼区域”在inactive为是这个对比很直白。还有一个值得注意的边界eLTE与NR的Inactive之间不能直接状态转换需要先回到idle。这条看似不起眼却会在异系统移动性场景里坑人。UE从NR的Inactive态移动到一个eLTE小区不能直接发RRCResumeRequest给eLTE必须先走idle再重新发起连接。具体踩坑记录我放在第5章。3.2 RRC连接建立从RRCSetupRequest到RRCSetupCompleteRRC连接建立过程在5G里分了三条触发路径UE主动发起的连接建立、resume请求找不到上下文时的fallback到建立、reestablish请求找不到上下文时的fallback到建立。PPT特别强调了一个细节如果网络侧收的是resumeRequest或reestablishRequest但未能取得或验证UE上下文网络会回RRCSetup而不是成功恢复UE收到RRCSetup后要删掉存储的AS上下文和I-RNTI并告知NAS层fallback到连接建立。RRCSetupRequest消息本身不长但字段含义要比LTE更细致。UE id用40bit随机数或者UE注册TA区时网络分配的5G-S-TMSIestablishmentCause由NAS指示T300定时器在消息交给底层时启动之后UE继续做测量和小区重选直到收到RRCSetup才停止。消息关键字段作用RRCSetupRequestue-Identity5G-S-TMSI或40bit随机数、establishmentCause网络侧识别UE身份和接入原因RRCSetupSRB1配置、小区组配置建立信令承载RRCSetupCompleteselectedPLMN-Identity、registeredPlmnList、s-nssai-ListUE上报所选PLMN、切片列表和NAS消息如果T300超时或期间发生了小区重选UE会重置MAC、重建RLC、通知NAS层RRC连接建立失败。这里要注意一个区别4G时代重选导致建立失败时终端动作给它一个“先重选后上报NAS failure”的流程5G大同小异但NR引入了s-nssai-List的上报意味着建立阶段就要和切片关联这在4G里没有。如果收到的是RRCRejectUE要停止T300/T319重置MAC并释放MAC配置启动T302并设成waitTime期间禁止掉所有请求然后通知NAS层RRC连接建立failure。有一个设计细节PPT特别强调Rel-15版本的RRCReject不支持完保也不能携带重定向信息这是防伪基站的设计。这个细节直接否决了某些“用RRCReject做负载均衡”的老思路。3.3 RRC重配与重建参数、定时器和触发条件RRCReconfiguration是RRC连接期间最常用的消息用途覆盖五个方面建立/修改/释放RB建立/修改/释放测量配置添加/修改/释放SCell和cell group触发同步重配置比如切换、BWP切换的随机接入传输NAS专用信息。在EN-DC架构下NR辅节点可以建立SRB3由辅节点直接向UE下发测量配置并接收测量上报不再全部经MN转发。这意味着你看到一条RRCReconfiguration先要判断它是MN下发的还是SN通过SRB3下发的判断错了后续的measId和SCG配置分析就会跑偏。重建过程是另一个容易翻车的地方。只有激活了AS安全的UE才可以发起重建如果没激活AS安全UE直接回idle。发起重建时启动T311做小区选择选中一个suitable cell后停止T311、启动T301恢复SRB1承载和安全。网络侧如果确认有上下文且校验通过回复RRCReestablishment如果没上下文回RRCSetup如果网络拥塞干脆让T301超时回到idle不需要额外的reject消息。NR里没有针对重建的RRCReject这和LTE有差异排查时如果习惯性去找“重建拒绝原因值”往往找不到。重建失败的原因要分两层看。物理层上行失步导致的RLF、MAC层随机接入失败达到最大次数、RLC重传达到上限这三类都会触发RLF而RLF后是否走重建取决于AS安全是否激活。我见过有人把“RRC重建请求”当“切换失败重试”来定位用了大量时间查切换参数实际是T311定时器或小区选择策略的问题。3.4 RRC Resume与ReleaseInactive态的恢复路径RRCResume是NR相对LTE最大的流程级变化。UE发起RRCResumeRequest的触发条件有三个高层或AS层触发状态转换、NG-RAN paging、RNA更新。流程方面启动T319定时器按SIB1指示在MSG3中携带FullResumeID40bit或72bit或truncatedResumeID24bit或56bit恢复存储的RRC配置和安全相关上下文使用当前KgNB密钥先恢复SRB1为SRB1执行AS完保和加密。收到RRCResume后UE恢复SRB2和DRB进入连接态。异常处理有两类T319超时或完保失败则回到idleT319运行期间发生小区重选通知NAS层resume失败。网络侧的响应逻辑也值得记网络侧有UE上下文就直接恢复进入连接态没上下文就做连接建立如果网络拥塞回RRCReject后启动T302UE回到inactive若是NAS触发的request则通知NAS failure若是RRC层触发的requestUE还会再尝试一次resumeRequest。RRCRelease则是连接释放的出口可以携带专用频率优先级和T320、频点重定向也可以携带suspendConfig让UE进入inactive。suspendConfig的内容包括resumeIdentity、nextHopChainingCount、ran-PagingCycle和ran-NotificationAreaInfo。这里有个容易看漏的机制为了规避release消息接收失败导致网络与UE状态不匹配NR引入了DataInactivityTimer连接态下如果没有数据活动且timer超时UE自己会回idle。这个timer在网络侧和UE侧都要配置只配一端会出状态不一致。3.5 系统信息、寻呼与统一接入控制On-demand与RAN paging的落地系统信息处理机制是5G改动最早、影响面最大的一个。LTE是把MIB加SIB1到SIB21全量广播NR改成On-demand SIMIB和SIB1保留周期性广播其余系统信息分两部分一部分按需由UE先发请求再由网络下发另一部分是网络按需配置可以改变调度。SIB1本身在NR里承担了更多职责除了小区接入参数和频段配置还指示MSG3的格式、resumeID的截断长度、统一接入控制的参数。寻呼方面要分清两个层级。5GC发起的寻呼基于TA list在RRC_IDLE下生效NG-RAN发起的寻呼基于RNA在RRC_INACTIVE下生效。定位不连续接收DRX周期要从这两个层面分别看核心网寻呼周期和RAN寻呼周期可能配的不一样IoT或语音场景尤其要检查。统一接入控制是另一处需要重新学习的设计。LTE时代的ACB、ABO、EAB、SSAC是多套独立机制NR把它们统一成一套基于access category和access identity的框架。终端根据建立原因映射到对应接入类别再查广播里的控制参数判断是否被bar。这带来的一个实际变化是RRCSetupRequest里的establishmentCause不再只是给网络看它直接参与了UE侧的接入控制判断。你在日志里看到一个establishmentCause为mt-Access的请求被本地拒绝不一定网络有问题先查SIB1里的接入控制配置。4. 用户面增强QoS Flow映射、PDCP split与SRB承载边界4.1 从Bearer到Flow5G QoS框架的映射逻辑5G的QoS粒度变了。LTE是EPS Bearer承载级一个UE可以有多个默认/专用承载每个承载对应一个QCI5G改成QoS Flow一个PDU会话里可以承载多个QoS Flow每个Flow映射到一个或多个DRB。PPT里单独列出37.324 SDAP规范就是为了强调这个映射层的存在。SDAP负责在RRC配置的映射规则下把QoS Flow的数据包映射到对应的DRB上支持配置是否需要SDAP包头。实际看信令时对应关系是这样的RRCReconfiguration里的PDU session setup列表会携带QoS Flow到DRB的映射关系qos-FlowMappingIndication而SDAP的配置也在同一个消息里下发。你用wireshark解析NAS消息里的QoS Flow标识QFI和RRC消息里的DRB ID要把这两张表对应起来。网络规划时常见做法是把QoS Flow按优先级归并到不同DRB比如VoNR的QFI单独走一个DRB普通eMBB数据走另一个这样空口调度才能差异化。如果PDU会话里的某个QoS Flow没有映射到任何DRB终端不会为它建立承载数据直接丢弃。这个机制和LTE“一个承载对应一个QCI不建承载就没业务”的思路差别很大——5G可能一个DRB里跑多个Flow一个Flow也可能因为映射规则而等待被重组。4.2 PDCP split与duplication两种不同维度的增强PDCP split和duplication是NR用户面里最容易混淆的两个概念。split bearer是指一个DRB的PDCP实体放在MN侧或SN侧RLC实体分别放在两个节点数据分流后从两条路径同时传提升吞吐或利用SCG资源duplication则是在PDCP层把相同的数据包复制成两份经两条不同路径传输接收侧做重复检测去重。一个是“拆开传”一个是“重复传”前者为了吞吐后者为了可靠性。在EN-DC下split bearer的终端侧行为是每个路径有独立的RLC实体和逻辑信道但PDCP实体是同一个。PDCP层的重排序窗口和重复检测逻辑要处理来自两条路径的数据。这就是为什么PPT里提到用户面PDCP的split需要特别设计——它不只是加一个RLC通道还要改造PDCP的序列号和重排序管理。Duplication的配置在RRCReconfiguration里由pdcp-Duplication字段控制可以按DRB粒度开或关。实际网络里duplication会成倍消耗空口资源不是默认开启的功能。URLLC场景、高可靠低时延要求明确时才会配置而且很多时候会配合专用逻辑信道优先级来保证两条路径不被其他业务抢占。你如果看到一个普通eMBB用户开了duplication配置先怀疑是不是配置回退或者模板复用出了问题。4.3 SRB0到SRB3信令承载的划分与边界SRB的划分在PPT里有清晰定义这里直接给一张表承载传输内容逻辑信道备注SRB0RRC消息CCCH用于RRCSetupRequest等初始消息不配置完保SRB1RRC消息、可承载NAS消息DCCHRRC连接期间主承载SRB2NAS消息DCCH优先级低于SRB1一般在安全激活后建立SRB3EN-DC时承载RRC消息DCCH由SN直接下发不经MN转发SRB3是5G新增的用在EN-DC和NR-DC场景。它能直接承载RRC重配和测量配置减少信令绕行MN的时延。但SRB3不是所有双连接场景都用MN和SN之间有一个srb3的分开关。排查双连接信令时如果看到SRB3上没有信令但SCG配置正常这不一定有问题可能是网络把SCG的测量配置都走SRB1转发了。SRB0和SRB1的边界也值得注意。RRCSetupRequest、RRCReestablishmentRequest、RRCSystemInfoRequest这些消息走CCCH建立了SRB1之后RRC消息就都走DCCH了。RRCSetup本身也是对SRB0上的请求消息的响应所以它暂时还在CCCH上传输。区分消息在哪条逻辑信道上对分析L2丢包、MAC复用方式都很有用。4.4 RLC与MAC的精简NR下的调解PPT用了“精简的RLC”这个说法。NR RLC保留了LTE的TM/UM/AM三种模式但移除了级联功能也不再处理PDCP之上的重组逻辑。TM模式用于SRB0和部分广播场景UM模式用于VoNR或对时延敏感的DRBAM模式用于对可靠性要求高的数据业务。RLC层的重要职责是ARQ重传和状态报告但它只在AM模式下启用。MAC层在NR里的角色比LTE更复杂。BWP的概念落地在MAC调度的频域资源配置上逻辑信道优先级、HARQ、调度请求、随机接入都要和BWP关联起来。MAC头在NR里采用了更灵活的格式支持subheader标识LCID和长度这也是信令日志里解析MAC层时常见的工作量集中点。如果你在做L2协议栈测试MAC到RLC的复用解复用流程、BWP切换时的HARQ flush行为是相对容易出现实现差异的地方。5. 信令避坑指南定时器误读、状态转换限制和协议版本翻车点5.1 RRCReject后终端反复接入排查却指向无线环境现象UE发起RRCSetupRequest后收到RRCReject随后触发T302但waitTime到期后UE再次发起请求又被拒反复循环现场截图看起来像“终端一直拉不到网”。原因RRCReject在Rel-15不支持完保不能携带重定向信息这是防伪基站的刻意设计。很多人拿着LTE的经验指望用带重定向的RRCReject做负载均衡或引导终端到另一个频点这在NR Rel-15上行不通。同时T302的waitTime配置过短会放大这种反复尝试的现象。解决先确认RRCReject里的waitTime实际值检查T302是否按预期配置不要再想通过RRCReject带重定向来“救”接入失败的用户改成用系统消息里的统一接入控制参数做准入控制。排查时把RRCReject消息里的waitTime和SIB1的接入控制参数一并拉出来看。常见做法是让开发环境里把waitTime调大到秒级观察终端退避行为再逐步缩小验证。5.2 eLTE与NR的Inactive之间状态转换以为可以直接resume现象终端在NR小区进入RRC_INACTIVE后移动到eLTE覆盖区UE一直不发RRCResumeRequest而是重新走完整的RRCSetup流程测试脚本预期“异系统resume”落空。原因eLTE与NR的Inactive之间不能直接状态转换需要先回到idle。这个限制在PPT的状态机部分有明确标注但很多人只看“LTE/5GC与NR/5GC间状态转换”的图忽略了eLTE与NR的Inactive互相转换那一栏写的是“需要回到idle”。解决设计异系统移动性测试用例时不要期待跨制式resume。跨制式进入后按idle行为设计PLMN选择、小区重选、然后新建RRC连接。如果业务上有快速恢复诉求网络侧可以考虑通过配置让UE在eLTE覆盖区不进入Inactive或缩短DataInactivityTimer让UE尽早回idle从而避免“inactive后重选才走完整建立流程”的较长时延。5.3 N310/T310/N311三个参数串在一起RLF定位失真现象RLF发生后协议栈日志显示T310根本没启动或者T310启动后异常快速超时定位人员对“为什么RLF判据没生效”百思不解。原因RLF判据不是“一个定时器超时”而是一组接力逻辑N310个连续OOSout-of-sync后启动T310T310运行期间收到N311个连续ISin-sync则停止T310若T310持续超时才触发RLF过程。配置时把N310、N311、T310三个值独立配调大N310会推迟T310启动调大N311会让T310更容易被停止三者必须配套调整。解决排查RLF先列三连表N310、T310、N311分别取值多少再对照日志确认“连续OOS计数达到N310的时刻”和“T310启动时刻”是否一致。我一般在问题复现时同时抓L1的IS/OOS指示和MAC的统计计数确保物理层上报和RRC状态机对齐而不是只看RRC层的RLF上报时间点。MCG RLF和SCG RLF的判据也要分开看SCG侧是PSCell的T310超时、SCG MAC随机接入失败、SCG RLC最大重传次数三者任一即可触发但上报对象是MN不是本地重建。5.4 协议版本用错38.331当成LTE的RRC来查现象在EN-DC流程里查某个测量配置字段wireshark解析出来的字段名与预期参数对不上翻遍38.331也没找到最后发现那是SRB3上由SN下发的消息用的是NR RRC规范没错但字段在另一个IE树里。原因5G引入了双连接后MN和SN各有一套RRC配置SN的配置经MN转发时是内嵌在MN的RRCReconfiguration里的一个NR IE比如nr-Config或secondaryCellGroup。直接按顺序解析外层RRC消息会把内嵌的NR RRC IE当成普通字段跳过。同样SRB3上的消息完全由SN生成只遵循38.331不经过36.331处理。解决解析EN-DC日志时先判断消息是从哪条逻辑信道下来的从MCG DCCH来的外层按36.331内嵌NR配置按38.331从SCG DCCHSRB3来的整条都按38.331。实操上wireshark需要同时加载36.331和38.331的解析器并且靠RLC的channel type判断走哪个分支。开发环境里常见做法是在基站侧日志同时打印MN和SN的RRC编解码结果用grep把内嵌IE单独dump出来对比。5.5 SCG RLF被当成MCG RLF误触发重建流程现象EN-DC下SCG发生RLF终端没有发起RRC重建测试人员认为终端行为异常反复抓log发现SCG RLF后UE只是向MN上报了SCGFailureInformation并没有发起RRCReestablishmentRequest。原因MCG RLF触发RRC重建或回idleSCG RLF则不同——它触发UE向MN上报SCGFailureInformation由MN决定是释放SCG、重配SCG还是保持SCG不激活。PPT里明确写了“上报SCG RLF给LTE MNEN-DC或NR MN(NR-NR-DC)”SCG RLF不会直接导致RRC重建。把SCG RLF当MCG RLF处理去查T311和T301参数方向就错了。解决收到SCG RLF后先从SCGFailureInformation消息里解析失败类型t310-Expired、randomAccessProblem、rlc-MaxNumRetx再看MN下发的RRCReconfiguration是重配SCG还是释放SCG。如果是rlc-MaxNumRetx需要同步检查SCG的RLC配置和逻辑信道优先级是否合理常见原因是SCG的SRB3或Split bearer的LCP被饿死。在真实外场里SCG的RLC重传超限往往和NR侧上行覆盖差、PUCCH功率不够相关不能只盯配置改。6. 信令日志验证从RRCSetupRequest到EN-DC失败的一步步定位6.1 抓包基础用tshark快速过滤RRC与NGAP消息分析信令日志时我习惯先用命令行做第一轮过滤不急着开图形界面刷几千条消息。如果你手里的pcap来自空口或基站侧镜像用tshark可以这样# 过滤RRC建立相关消息和NGAP消息输出时间、消息类型关键字段 tshark -r 5g_trace.pcap -Y rrc.setup_request || rrc.setup || rrc.setup_complete || ngap \ -T fields -e frame.time -e rrc.establishment_cause -e rrc.ue_identity \ -e ngap.procedure_code -e ngap.criticality参数含义-r指定读取的pcap文件-Y是显示过滤表达式只保留RRC建立三条消息和NGAP协议-T fields结合-e输出自定义字段列这里选了时间、establishmentCause、UE Identity、NGAP过程码。实际项目里如果同时存在EN-DC还要加lte_rrc的过滤条件比如lte_rrc.rrcSetupRequest || lte_rrc.rrcConnectionSetup。这样过滤出来的消息列表第一眼就能判断UE接入是正常流程、resume fallback还是重建失败。如果RRCSetupRequest后面紧跟的是RRCReject而不是RRCSetup那问题大概率在网络侧准入控制优先查T302、waitTime和接入控制参数。6.2 一个EN-DC添加失败的定位路径从SgNB Addition看原因这里我用一个实际踩过的案例说明怎么把PPT里的知识用到日志里。场景是UE已经在LTE小区建立RRC连接基站侧开启了EN-DC测量UE上报B1事件后MN发起SgNB Addition但SgNB侧一直回失败。抓完日志按这个顺序看先确认UE上报的MeasReport里是NR频点还是LTE邻区B1事件的关键参数是b1-ThresholdNR和reportConfig里的measId。如果上报的NR小区信号正常但MeasurementReport后没有触发SgNB Addition Request问题在MN侧的门限判断或SgNB候选选择策略。如果SgNB Addition Request发出了但Response里带失败cause优先看cause是radioNetwork层的“radio resources not available”还是transport层的“transport resource unavailable”。前者查gNB的NR小区PRB占用、SgNB准入开关后者查Xn接口的传输链路。如果SgNB Addition成功但UE侧RRCReconfiguration执行失败在终端日志里看是哪个IE解析失败常见的是NR测量对象里的频点或BWP配置和SgNB实际下发不一致。如果RRCReconfiguration完成但SCG承载一直起不来回头查SCG的RLC配置、逻辑信道和PDCP duplication状态看是否因duplication开启消耗两倍空口资源导致实际调度失败。这套顺序的基础就是PPT里那张“控制面UE状态、RRC连接、移动性管理、EN-DC双连接”的目录框架。你理解了信令流程之间的依赖关系拿到新日志时才不会一头扎进消息海。从那以后我每次分析EN-DC或RRC信令日志都强制先列一遍“UE状态→RRC流程→接口消息→失败原因”的链路再动手不再凭经验跳过中间步骤。希望这份5G信令的基础拆解能帮你在转5G的路上少走几回弯路。本文还有配套的精品资源点击获取 5G信令详解：从RRC状态机到NG-RAN架构，控制面与用户面全拆解
简介移动通信从4G到5G核心变化之一在于控制面协议栈的重构。RRC状态机由原有的两种状态扩展出RRC_INACTIVENG-RAN架构引入gNB-CU/DU分离及E1、Xn、F1等新接口信令流程和承载逻辑也随之复杂化。理解这些基础概念是掌握5G空口协议、接口规范与UE行为的关键。无论是协议开发、基站/终端测试还是网络优化中的信令排障都需要从RRC建立、重配、恢复、重建等核心流程切入结合QoS Flow到DRB的映射、PDCP split与duplication增强以及EN-DC双连接下的SRB3路径选择构建一张可对照使用的5G信令全景图。本文基于5G信令基础讲解系统梳理控制面状态机、用户面承载映射及常见踩坑案例帮助工程师快速从LTE视角切换到NR视角提升日志分析与故障定位效率。1. 5G信令讲解从4G到5G控制面变化这份资源到底解决什么问题很多人从LTE转5G第一道坎不在物理层的波束、毫米波或多天线而在RRC信令——RRC_INACTIVE、SRB3、RNAU、SUL、On-demand SI这些概念在4G里根本没有对应物却直接决定了UE状态机怎么跳、连接建立流程怎么走、双连接信令在哪条路径上传输。这份《5G基础信令基础讲解》PPT就是一套偏培训向的协议底稿先从5G相比4G的新特性切到NG-RAN架构再把控制面UE状态、RRC建立/重配/重建/恢复/释放/RLF、统一接入控制、系统信息、寻呼、移动性管理、SUL、EN-DC和用户面新QoS机制、PDCP split与duplication、精简RLC、MAC完整串了一遍。适合协议开发、基站或终端侧测试、以及想补5G信令底子的网优工程师。读完之后你能把“5G新增了什么”变成一张能对照使用的信令流程地图而不是记住一堆孤立名词。2. NG-RAN架构与协议规范底稿36系列和38系列怎么对照着看2.1 NG-RAN架构eLTE和NR如何接入5GC先看架构。PPT里有一句很关键的话eLTE与NR都可接入5G CoreeLTE需要改造以兼容5G Core。这句话决定了你看信令时的大前提——5G接入网不是只有gNB一种节点还有一个ng-eNB也就是eLTE形态用LTE空口接入5G核心网。所以5G接入网的全称叫NG-RAN而不是NR-RAN它是“NG-RAN节点”的集合gNB和ng-eNB都在里面。gNB走NR空口ng-eNB走LTE空口但两者都通过NG接口连到AMF和UPFgNB之间通过Xn接口互联gNB内部再按CU/DU分离拆成gNB-CU和gNB-DU走F1接口。这个架构和LTE最大的差别是LTE的eNB直连EPC一个S1接口就搞定5G的NG-RAN把控制面、用户面拆得更开接口数量成倍增加。你去查信令时如果分不清NG、Xn、F1各自承载什么很容易在日志里对不上号。举例来说EN-DC下SgNB添加流程走的是Xn接口上的SgNB Addition而RRC信令可能从SN侧通过SRB3直接发给UE也可能经MN的SRB1转发两条路径在记录文件里长得完全不一样。再强调一个容易忽略的点gNB的CU/DU分离后gNB-CU又按控制面和用户面拆成gNB-CU-CP和gNB-CU-UP两者之间走E1接口。E1-AP的规范号是38.463很多人第一次看到它时以为是笔误其实它是CU-CP和CU-UP之间的应用层协议。排查用户面问题时你会频繁遇到它。2.2 协议规范地图38系列各规范的位置很多从4G转过来的人第一反应是去翻38.300这没错但38.300只是NR整体白皮书级别的内容。真正干活时你需要的是下面这张对照表这也是这份PPT里我认为最值的部分之一。规范号内容对应4G规范38.300NR整体36.30038.401NG-RAN整体架构36.40138.321NR MAC36.32138.322NR RLC36.32238.323NR PDCP36.32338.331NR RRC36.33138.410/38.413NG接口整体与NG-AP36.410/36.41338.420/38.423Xn接口整体与Xn-AP36.420/36.42338.470/38.473F1接口整体与F1-AP无直接对应38.463E1-AP无直接对应37.340MR-DC多连接无直接对应37.324SDAP无直接对应注意37.340和37.324不在38系列里这是很多人会查漏的地方。MR-DCMulti-RAT Dual Connectivity由37.340专门定义EN-DC、NR-DC都归它管里面包含了MCG、SCG、Split Bearer的完整信令流程SDAP协议独立放在37.324里因为它是5G QoS Flow到DRB映射的入口层LTE里没有对应物。你如果按38系列的编号去找双连接或SDAP的内容大概率会扑空。另外一份值得收藏的对照关系在更高层23.501是5G系统总体架构及功能23.502是5G系统基本流程它们对应LTE时代的23.401。排查跨层信令问题时比如RRC建立失败背后是不是注册流程的问题就需要在RRC层和NAS层之间来回跳这两份规范是必查的。RAN侧的人经常只看空口和NG接口忽略了NAS流程对RRC建立原因的驱动逻辑。2.3 高层特性对照从On-demand SI到eLTE的11项变化PPT把5G相比4G的高层变化总结成了11条我整理成了一张表后面每一章都会反复引用到这里面的某一项特性含义涉及协议层On-demand SI按需获取系统信息不再全部广播RRCInactive state新增RRC_INACTIVE状态RRCSUL补充上行载波MAC/RRCBWP灵活带宽可配置多个部分带宽MACSRB3、Split bearer新承载类型RRC/PDCPDuplicationPDCP冗余传输PDCPLTE-NR DC跨制式双连接RRC/XnRNAU基于RAN area的位置更新RRCFlow vs Bearer新QoS框架SDAP/RRCBeam管理基于波束的链路和移动性管理L1/RRCeLTELTE空口接入5GCNG/RRC这张表建议你打印出来贴在工位上。我见过不少同事把快照放在桌面排查信令时先对着它判断“这个流程是4G没有新增的还是4G改造的”能省很多时间。比如BWP涉及MAC调度的频域资源切换但触发BWP切换的信令却经常由RRC Reconfiguration带下来这属于跨层配合只看MAC必然漏。3. 控制面核心UE状态机与RRC建立、重配、恢复、重建的五步拆解3.1 UE状态机RRC_INACTIVE引入的逻辑PPT里的状态转换表值得仔细看。LTE R8只有RRC_IDLE和RRC_CONNECTED两个状态NB-IoT R13引入了连接挂起/恢复NR R15正式把RRC_INACTIVE定义为标准状态。Inactive态的三个设计特点直接决定了它的用法Uu连接断开但NG连接保持UE、gNB、AMF都保留UE上下文可以做到10ms级别回到连接态RAN notification area由NG-RAN控制可以是cell list、RNA list或TA list的组合RAN-initiated paging允许gNB在RNA范围内直接发起寻呼不需要经过核心网。很多人把Inactive误当成“半idle”这个理解要纠正。Inactive状态下UE不做小区选择重选之外的移动性但核心网侧的会话和承载上下文都还在基站侧的UE上下文也在。正因为上下文保留RRCResume流程才能以短消息的形式快速恢复SRB2和DRB。你去看PPT里状态机表格有一行是“5GC控制的寻呼区域”在idle为是、inactive为否“NG-RAN控制的寻呼区域”在inactive为是这个对比很直白。还有一个值得注意的边界eLTE与NR的Inactive之间不能直接状态转换需要先回到idle。这条看似不起眼却会在异系统移动性场景里坑人。UE从NR的Inactive态移动到一个eLTE小区不能直接发RRCResumeRequest给eLTE必须先走idle再重新发起连接。具体踩坑记录我放在第5章。3.2 RRC连接建立从RRCSetupRequest到RRCSetupCompleteRRC连接建立过程在5G里分了三条触发路径UE主动发起的连接建立、resume请求找不到上下文时的fallback到建立、reestablish请求找不到上下文时的fallback到建立。PPT特别强调了一个细节如果网络侧收的是resumeRequest或reestablishRequest但未能取得或验证UE上下文网络会回RRCSetup而不是成功恢复UE收到RRCSetup后要删掉存储的AS上下文和I-RNTI并告知NAS层fallback到连接建立。RRCSetupRequest消息本身不长但字段含义要比LTE更细致。UE id用40bit随机数或者UE注册TA区时网络分配的5G-S-TMSIestablishmentCause由NAS指示T300定时器在消息交给底层时启动之后UE继续做测量和小区重选直到收到RRCSetup才停止。消息关键字段作用RRCSetupRequestue-Identity5G-S-TMSI或40bit随机数、establishmentCause网络侧识别UE身份和接入原因RRCSetupSRB1配置、小区组配置建立信令承载RRCSetupCompleteselectedPLMN-Identity、registeredPlmnList、s-nssai-ListUE上报所选PLMN、切片列表和NAS消息如果T300超时或期间发生了小区重选UE会重置MAC、重建RLC、通知NAS层RRC连接建立失败。这里要注意一个区别4G时代重选导致建立失败时终端动作给它一个“先重选后上报NAS failure”的流程5G大同小异但NR引入了s-nssai-List的上报意味着建立阶段就要和切片关联这在4G里没有。如果收到的是RRCRejectUE要停止T300/T319重置MAC并释放MAC配置启动T302并设成waitTime期间禁止掉所有请求然后通知NAS层RRC连接建立failure。有一个设计细节PPT特别强调Rel-15版本的RRCReject不支持完保也不能携带重定向信息这是防伪基站的设计。这个细节直接否决了某些“用RRCReject做负载均衡”的老思路。3.3 RRC重配与重建参数、定时器和触发条件RRCReconfiguration是RRC连接期间最常用的消息用途覆盖五个方面建立/修改/释放RB建立/修改/释放测量配置添加/修改/释放SCell和cell group触发同步重配置比如切换、BWP切换的随机接入传输NAS专用信息。在EN-DC架构下NR辅节点可以建立SRB3由辅节点直接向UE下发测量配置并接收测量上报不再全部经MN转发。这意味着你看到一条RRCReconfiguration先要判断它是MN下发的还是SN通过SRB3下发的判断错了后续的measId和SCG配置分析就会跑偏。重建过程是另一个容易翻车的地方。只有激活了AS安全的UE才可以发起重建如果没激活AS安全UE直接回idle。发起重建时启动T311做小区选择选中一个suitable cell后停止T311、启动T301恢复SRB1承载和安全。网络侧如果确认有上下文且校验通过回复RRCReestablishment如果没上下文回RRCSetup如果网络拥塞干脆让T301超时回到idle不需要额外的reject消息。NR里没有针对重建的RRCReject这和LTE有差异排查时如果习惯性去找“重建拒绝原因值”往往找不到。重建失败的原因要分两层看。物理层上行失步导致的RLF、MAC层随机接入失败达到最大次数、RLC重传达到上限这三类都会触发RLF而RLF后是否走重建取决于AS安全是否激活。我见过有人把“RRC重建请求”当“切换失败重试”来定位用了大量时间查切换参数实际是T311定时器或小区选择策略的问题。3.4 RRC Resume与ReleaseInactive态的恢复路径RRCResume是NR相对LTE最大的流程级变化。UE发起RRCResumeRequest的触发条件有三个高层或AS层触发状态转换、NG-RAN paging、RNA更新。流程方面启动T319定时器按SIB1指示在MSG3中携带FullResumeID40bit或72bit或truncatedResumeID24bit或56bit恢复存储的RRC配置和安全相关上下文使用当前KgNB密钥先恢复SRB1为SRB1执行AS完保和加密。收到RRCResume后UE恢复SRB2和DRB进入连接态。异常处理有两类T319超时或完保失败则回到idleT319运行期间发生小区重选通知NAS层resume失败。网络侧的响应逻辑也值得记网络侧有UE上下文就直接恢复进入连接态没上下文就做连接建立如果网络拥塞回RRCReject后启动T302UE回到inactive若是NAS触发的request则通知NAS failure若是RRC层触发的requestUE还会再尝试一次resumeRequest。RRCRelease则是连接释放的出口可以携带专用频率优先级和T320、频点重定向也可以携带suspendConfig让UE进入inactive。suspendConfig的内容包括resumeIdentity、nextHopChainingCount、ran-PagingCycle和ran-NotificationAreaInfo。这里有个容易看漏的机制为了规避release消息接收失败导致网络与UE状态不匹配NR引入了DataInactivityTimer连接态下如果没有数据活动且timer超时UE自己会回idle。这个timer在网络侧和UE侧都要配置只配一端会出状态不一致。3.5 系统信息、寻呼与统一接入控制On-demand与RAN paging的落地系统信息处理机制是5G改动最早、影响面最大的一个。LTE是把MIB加SIB1到SIB21全量广播NR改成On-demand SIMIB和SIB1保留周期性广播其余系统信息分两部分一部分按需由UE先发请求再由网络下发另一部分是网络按需配置可以改变调度。SIB1本身在NR里承担了更多职责除了小区接入参数和频段配置还指示MSG3的格式、resumeID的截断长度、统一接入控制的参数。寻呼方面要分清两个层级。5GC发起的寻呼基于TA list在RRC_IDLE下生效NG-RAN发起的寻呼基于RNA在RRC_INACTIVE下生效。定位不连续接收DRX周期要从这两个层面分别看核心网寻呼周期和RAN寻呼周期可能配的不一样IoT或语音场景尤其要检查。统一接入控制是另一处需要重新学习的设计。LTE时代的ACB、ABO、EAB、SSAC是多套独立机制NR把它们统一成一套基于access category和access identity的框架。终端根据建立原因映射到对应接入类别再查广播里的控制参数判断是否被bar。这带来的一个实际变化是RRCSetupRequest里的establishmentCause不再只是给网络看它直接参与了UE侧的接入控制判断。你在日志里看到一个establishmentCause为mt-Access的请求被本地拒绝不一定网络有问题先查SIB1里的接入控制配置。4. 用户面增强QoS Flow映射、PDCP split与SRB承载边界4.1 从Bearer到Flow5G QoS框架的映射逻辑5G的QoS粒度变了。LTE是EPS Bearer承载级一个UE可以有多个默认/专用承载每个承载对应一个QCI5G改成QoS Flow一个PDU会话里可以承载多个QoS Flow每个Flow映射到一个或多个DRB。PPT里单独列出37.324 SDAP规范就是为了强调这个映射层的存在。SDAP负责在RRC配置的映射规则下把QoS Flow的数据包映射到对应的DRB上支持配置是否需要SDAP包头。实际看信令时对应关系是这样的RRCReconfiguration里的PDU session setup列表会携带QoS Flow到DRB的映射关系qos-FlowMappingIndication而SDAP的配置也在同一个消息里下发。你用wireshark解析NAS消息里的QoS Flow标识QFI和RRC消息里的DRB ID要把这两张表对应起来。网络规划时常见做法是把QoS Flow按优先级归并到不同DRB比如VoNR的QFI单独走一个DRB普通eMBB数据走另一个这样空口调度才能差异化。如果PDU会话里的某个QoS Flow没有映射到任何DRB终端不会为它建立承载数据直接丢弃。这个机制和LTE“一个承载对应一个QCI不建承载就没业务”的思路差别很大——5G可能一个DRB里跑多个Flow一个Flow也可能因为映射规则而等待被重组。4.2 PDCP split与duplication两种不同维度的增强PDCP split和duplication是NR用户面里最容易混淆的两个概念。split bearer是指一个DRB的PDCP实体放在MN侧或SN侧RLC实体分别放在两个节点数据分流后从两条路径同时传提升吞吐或利用SCG资源duplication则是在PDCP层把相同的数据包复制成两份经两条不同路径传输接收侧做重复检测去重。一个是“拆开传”一个是“重复传”前者为了吞吐后者为了可靠性。在EN-DC下split bearer的终端侧行为是每个路径有独立的RLC实体和逻辑信道但PDCP实体是同一个。PDCP层的重排序窗口和重复检测逻辑要处理来自两条路径的数据。这就是为什么PPT里提到用户面PDCP的split需要特别设计——它不只是加一个RLC通道还要改造PDCP的序列号和重排序管理。Duplication的配置在RRCReconfiguration里由pdcp-Duplication字段控制可以按DRB粒度开或关。实际网络里duplication会成倍消耗空口资源不是默认开启的功能。URLLC场景、高可靠低时延要求明确时才会配置而且很多时候会配合专用逻辑信道优先级来保证两条路径不被其他业务抢占。你如果看到一个普通eMBB用户开了duplication配置先怀疑是不是配置回退或者模板复用出了问题。4.3 SRB0到SRB3信令承载的划分与边界SRB的划分在PPT里有清晰定义这里直接给一张表承载传输内容逻辑信道备注SRB0RRC消息CCCH用于RRCSetupRequest等初始消息不配置完保SRB1RRC消息、可承载NAS消息DCCHRRC连接期间主承载SRB2NAS消息DCCH优先级低于SRB1一般在安全激活后建立SRB3EN-DC时承载RRC消息DCCH由SN直接下发不经MN转发SRB3是5G新增的用在EN-DC和NR-DC场景。它能直接承载RRC重配和测量配置减少信令绕行MN的时延。但SRB3不是所有双连接场景都用MN和SN之间有一个srb3的分开关。排查双连接信令时如果看到SRB3上没有信令但SCG配置正常这不一定有问题可能是网络把SCG的测量配置都走SRB1转发了。SRB0和SRB1的边界也值得注意。RRCSetupRequest、RRCReestablishmentRequest、RRCSystemInfoRequest这些消息走CCCH建立了SRB1之后RRC消息就都走DCCH了。RRCSetup本身也是对SRB0上的请求消息的响应所以它暂时还在CCCH上传输。区分消息在哪条逻辑信道上对分析L2丢包、MAC复用方式都很有用。4.4 RLC与MAC的精简NR下的调解PPT用了“精简的RLC”这个说法。NR RLC保留了LTE的TM/UM/AM三种模式但移除了级联功能也不再处理PDCP之上的重组逻辑。TM模式用于SRB0和部分广播场景UM模式用于VoNR或对时延敏感的DRBAM模式用于对可靠性要求高的数据业务。RLC层的重要职责是ARQ重传和状态报告但它只在AM模式下启用。MAC层在NR里的角色比LTE更复杂。BWP的概念落地在MAC调度的频域资源配置上逻辑信道优先级、HARQ、调度请求、随机接入都要和BWP关联起来。MAC头在NR里采用了更灵活的格式支持subheader标识LCID和长度这也是信令日志里解析MAC层时常见的工作量集中点。如果你在做L2协议栈测试MAC到RLC的复用解复用流程、BWP切换时的HARQ flush行为是相对容易出现实现差异的地方。5. 信令避坑指南定时器误读、状态转换限制和协议版本翻车点5.1 RRCReject后终端反复接入排查却指向无线环境现象UE发起RRCSetupRequest后收到RRCReject随后触发T302但waitTime到期后UE再次发起请求又被拒反复循环现场截图看起来像“终端一直拉不到网”。原因RRCReject在Rel-15不支持完保不能携带重定向信息这是防伪基站的刻意设计。很多人拿着LTE的经验指望用带重定向的RRCReject做负载均衡或引导终端到另一个频点这在NR Rel-15上行不通。同时T302的waitTime配置过短会放大这种反复尝试的现象。解决先确认RRCReject里的waitTime实际值检查T302是否按预期配置不要再想通过RRCReject带重定向来“救”接入失败的用户改成用系统消息里的统一接入控制参数做准入控制。排查时把RRCReject消息里的waitTime和SIB1的接入控制参数一并拉出来看。常见做法是让开发环境里把waitTime调大到秒级观察终端退避行为再逐步缩小验证。5.2 eLTE与NR的Inactive之间状态转换以为可以直接resume现象终端在NR小区进入RRC_INACTIVE后移动到eLTE覆盖区UE一直不发RRCResumeRequest而是重新走完整的RRCSetup流程测试脚本预期“异系统resume”落空。原因eLTE与NR的Inactive之间不能直接状态转换需要先回到idle。这个限制在PPT的状态机部分有明确标注但很多人只看“LTE/5GC与NR/5GC间状态转换”的图忽略了eLTE与NR的Inactive互相转换那一栏写的是“需要回到idle”。解决设计异系统移动性测试用例时不要期待跨制式resume。跨制式进入后按idle行为设计PLMN选择、小区重选、然后新建RRC连接。如果业务上有快速恢复诉求网络侧可以考虑通过配置让UE在eLTE覆盖区不进入Inactive或缩短DataInactivityTimer让UE尽早回idle从而避免“inactive后重选才走完整建立流程”的较长时延。5.3 N310/T310/N311三个参数串在一起RLF定位失真现象RLF发生后协议栈日志显示T310根本没启动或者T310启动后异常快速超时定位人员对“为什么RLF判据没生效”百思不解。原因RLF判据不是“一个定时器超时”而是一组接力逻辑N310个连续OOSout-of-sync后启动T310T310运行期间收到N311个连续ISin-sync则停止T310若T310持续超时才触发RLF过程。配置时把N310、N311、T310三个值独立配调大N310会推迟T310启动调大N311会让T310更容易被停止三者必须配套调整。解决排查RLF先列三连表N310、T310、N311分别取值多少再对照日志确认“连续OOS计数达到N310的时刻”和“T310启动时刻”是否一致。我一般在问题复现时同时抓L1的IS/OOS指示和MAC的统计计数确保物理层上报和RRC状态机对齐而不是只看RRC层的RLF上报时间点。MCG RLF和SCG RLF的判据也要分开看SCG侧是PSCell的T310超时、SCG MAC随机接入失败、SCG RLC最大重传次数三者任一即可触发但上报对象是MN不是本地重建。5.4 协议版本用错38.331当成LTE的RRC来查现象在EN-DC流程里查某个测量配置字段wireshark解析出来的字段名与预期参数对不上翻遍38.331也没找到最后发现那是SRB3上由SN下发的消息用的是NR RRC规范没错但字段在另一个IE树里。原因5G引入了双连接后MN和SN各有一套RRC配置SN的配置经MN转发时是内嵌在MN的RRCReconfiguration里的一个NR IE比如nr-Config或secondaryCellGroup。直接按顺序解析外层RRC消息会把内嵌的NR RRC IE当成普通字段跳过。同样SRB3上的消息完全由SN生成只遵循38.331不经过36.331处理。解决解析EN-DC日志时先判断消息是从哪条逻辑信道下来的从MCG DCCH来的外层按36.331内嵌NR配置按38.331从SCG DCCHSRB3来的整条都按38.331。实操上wireshark需要同时加载36.331和38.331的解析器并且靠RLC的channel type判断走哪个分支。开发环境里常见做法是在基站侧日志同时打印MN和SN的RRC编解码结果用grep把内嵌IE单独dump出来对比。5.5 SCG RLF被当成MCG RLF误触发重建流程现象EN-DC下SCG发生RLF终端没有发起RRC重建测试人员认为终端行为异常反复抓log发现SCG RLF后UE只是向MN上报了SCGFailureInformation并没有发起RRCReestablishmentRequest。原因MCG RLF触发RRC重建或回idleSCG RLF则不同——它触发UE向MN上报SCGFailureInformation由MN决定是释放SCG、重配SCG还是保持SCG不激活。PPT里明确写了“上报SCG RLF给LTE MNEN-DC或NR MN(NR-NR-DC)”SCG RLF不会直接导致RRC重建。把SCG RLF当MCG RLF处理去查T311和T301参数方向就错了。解决收到SCG RLF后先从SCGFailureInformation消息里解析失败类型t310-Expired、randomAccessProblem、rlc-MaxNumRetx再看MN下发的RRCReconfiguration是重配SCG还是释放SCG。如果是rlc-MaxNumRetx需要同步检查SCG的RLC配置和逻辑信道优先级是否合理常见原因是SCG的SRB3或Split bearer的LCP被饿死。在真实外场里SCG的RLC重传超限往往和NR侧上行覆盖差、PUCCH功率不够相关不能只盯配置改。6. 信令日志验证从RRCSetupRequest到EN-DC失败的一步步定位6.1 抓包基础用tshark快速过滤RRC与NGAP消息分析信令日志时我习惯先用命令行做第一轮过滤不急着开图形界面刷几千条消息。如果你手里的pcap来自空口或基站侧镜像用tshark可以这样# 过滤RRC建立相关消息和NGAP消息输出时间、消息类型关键字段 tshark -r 5g_trace.pcap -Y rrc.setup_request || rrc.setup || rrc.setup_complete || ngap \ -T fields -e frame.time -e rrc.establishment_cause -e rrc.ue_identity \ -e ngap.procedure_code -e ngap.criticality参数含义-r指定读取的pcap文件-Y是显示过滤表达式只保留RRC建立三条消息和NGAP协议-T fields结合-e输出自定义字段列这里选了时间、establishmentCause、UE Identity、NGAP过程码。实际项目里如果同时存在EN-DC还要加lte_rrc的过滤条件比如lte_rrc.rrcSetupRequest || lte_rrc.rrcConnectionSetup。这样过滤出来的消息列表第一眼就能判断UE接入是正常流程、resume fallback还是重建失败。如果RRCSetupRequest后面紧跟的是RRCReject而不是RRCSetup那问题大概率在网络侧准入控制优先查T302、waitTime和接入控制参数。6.2 一个EN-DC添加失败的定位路径从SgNB Addition看原因这里我用一个实际踩过的案例说明怎么把PPT里的知识用到日志里。场景是UE已经在LTE小区建立RRC连接基站侧开启了EN-DC测量UE上报B1事件后MN发起SgNB Addition但SgNB侧一直回失败。抓完日志按这个顺序看先确认UE上报的MeasReport里是NR频点还是LTE邻区B1事件的关键参数是b1-ThresholdNR和reportConfig里的measId。如果上报的NR小区信号正常但MeasurementReport后没有触发SgNB Addition Request问题在MN侧的门限判断或SgNB候选选择策略。如果SgNB Addition Request发出了但Response里带失败cause优先看cause是radioNetwork层的“radio resources not available”还是transport层的“transport resource unavailable”。前者查gNB的NR小区PRB占用、SgNB准入开关后者查Xn接口的传输链路。如果SgNB Addition成功但UE侧RRCReconfiguration执行失败在终端日志里看是哪个IE解析失败常见的是NR测量对象里的频点或BWP配置和SgNB实际下发不一致。如果RRCReconfiguration完成但SCG承载一直起不来回头查SCG的RLC配置、逻辑信道和PDCP duplication状态看是否因duplication开启消耗两倍空口资源导致实际调度失败。这套顺序的基础就是PPT里那张“控制面UE状态、RRC连接、移动性管理、EN-DC双连接”的目录框架。你理解了信令流程之间的依赖关系拿到新日志时才不会一头扎进消息海。从那以后我每次分析EN-DC或RRC信令日志都强制先列一遍“UE状态→RRC流程→接口消息→失败原因”的链路再动手不再凭经验跳过中间步骤。希望这份5G信令的基础拆解能帮你在转5G的路上少走几回弯路。本文还有配套的精品资源点击获取