企业官网建设流程全解析

简介：移动通信从4G到5G，核心变化之一在于控制面协议栈的重构。RRC状态机由原有的两种状态扩展出RRC_INACTIVE，NG-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 Core，eLTE需要改造以兼容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和UPF，gNB之间通过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里我认为最值的部分之一。

注意37.340和37.324不在38系列里，这是很多人会查漏的地方。MR-DC（Multi-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条，我整理成了一张表，后面每一章都会反复引用到这里面的某一项：

这张表建议你打印出来贴在工位上。我见过不少同事把快照放在桌面，排查信令时先对着它判断“这个流程是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到RRCSetupComplete

RRC连接建立过程在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-TMSI；establishmentCause由NAS指示，T300定时器在消息交给底层时启动，之后UE继续做测量和小区重选，直到收到RRCSetup才停止。

如果T300超时或期间发生了小区重选，UE会重置MAC、重建RLC、通知NAS层RRC连接建立失败。这里要注意一个区别：4G时代重选导致建立失败时，终端动作给它一个“先重选，后上报NAS failure”的流程；5G大同小异，但NR引入了s-nssai-List的上报，意味着建立阶段就要和切片关联，这在4G里没有。

如果收到的是RRCReject，UE要停止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与Release：Inactive态的恢复路径

RRCResume是NR相对LTE最大的流程级变化。UE发起RRCResumeRequest的触发条件有三个：高层或AS层触发状态转换、NG-RAN paging、RNA更新。流程方面：启动T319定时器；按SIB1指示，在MSG3中携带FullResumeID（40bit或72bit）或truncatedResumeID（24bit或56bit）；恢复存储的RRC配置和安全相关上下文，使用当前KgNB密钥；先恢复SRB1，为SRB1执行AS完保和加密。

收到RRCResume后，UE恢复SRB2和DRB，进入连接态。异常处理有两类：T319超时或完保失败则回到idle；T319运行期间发生小区重选，通知NAS层resume失败。网络侧的响应逻辑也值得记：网络侧有UE上下文就直接恢复进入连接态；没上下文就做连接建立；如果网络拥塞，回RRCReject后启动T302，UE回到inactive，若是NAS触发的request则通知NAS failure，若是RRC层触发的request，UE还会再尝试一次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 SI：MIB和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到Flow：5G QoS框架的映射逻辑

5G的QoS粒度变了。LTE是EPS Bearer承载级，一个UE可以有多个默认/专用承载，每个承载对应一个QCI；5G改成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里有清晰定义，这里直接给一张表：

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或对时延敏感的DRB，AM模式用于对可靠性要求高的数据业务。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个连续OOS（out-of-sync）后启动T310，T310运行期间收到N311个连续IS（in-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 DCCH（SRB3）来的，整条都按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重建或回idle，SCG RLF则不同——它触发UE向MN上报SCGFailureInformation，由MN决定是释放SCG、重配SCG还是保持SCG不激活。PPT里明确写了“上报SCG RLF给LTE MN（EN-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侧一直回失败。

抓完日志按这个顺序看：

1. 先确认UE上报的MeasReport里是NR频点还是LTE邻区，B1事件的关键参数是b1-ThresholdNR和reportConfig里的measId。如果上报的NR小区信号正常，但MeasurementReport后没有触发SgNB Addition Request，问题在MN侧的门限判断或SgNB候选选择策略。

2. 如果SgNB Addition Request发出了但Response里带失败cause，优先看cause是radioNetwork层的“radio resources not available”还是transport层的“transport resource unavailable”。前者查gNB的NR小区PRB占用、SgNB准入开关；后者查Xn接口的传输链路。

3. 如果SgNB Addition成功但UE侧RRCReconfiguration执行失败，在终端日志里看是哪个IE解析失败，常见的是NR测量对象里的频点或BWP配置和SgNB实际下发不一致。

4. 如果RRCReconfiguration完成，但SCG承载一直起不来，回头查SCG的RLC配置、逻辑信道和PDCP duplication状态，看是否因duplication开启消耗两倍空口资源导致实际调度失败。

这套顺序的基础，就是PPT里那张“控制面：UE状态、RRC连接、移动性管理、EN-DC双连接”的目录框架。你理解了信令流程之间的依赖关系，拿到新日志时才不会一头扎进消息海。从那以后我每次分析EN-DC或RRC信令日志，都强制先列一遍“UE状态→RRC流程→接口消息→失败原因”的链路再动手，不再凭经验跳过中间步骤。希望这份5G信令的基础拆解，能帮你在转5G的路上少走几回弯路。

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