简介这份PPT围绕5G网络优化中的核心信令流程展开面向4G/5G互操作、NSA组网优化的网优工程师及通信专业学生重点讲解频谱资源分配、SSB对齐、UE接入流程、系统消息解读、UE能力识别、测量控制与辅小区添加等关键知识点。资源为单个PPTX演示文稿共1个文件压缩包约1.54MB结构紧凑适合移动学习与实战查阅。目前已有419人学习浏览内容来源于一线优化经验。PPT里嵌入中移2.6GHz频段配置实例对比60MHz与100MHz小区的Cell freq和SSB GSCN设置拆解LTE侧SIB1/SIB2关键字段对选网和ENDC策略的影响详细说明B1测量门限、A2/A3事件触发逻辑并针对辅小区添加失败后的RRC重建立原因如DRB3 RLC模式不一致、上行256QAM不兼容等给出排查要点同时涵盖EN-DC频段组合识别与测量上报的RSRP评估方法。适合希望从信令细节入手提升5G网络问题定位与参数配置能力的读者参考。1. 中移2.6G下NSA接入的5G信令流程一半问题出在LTE侧NSA组网下的5G信令流程前半段几乎全跑在LTE侧。终端先驻留LTE再通过LTE下发的B1测量、辅小区添加、A2删腿这些信令把NR“拉进来”或者“放出去”。做中移2.6G优化的人应该都有印象很多NR接入问题在后台看小区状态全部正常但外场就是加不上腿最后定位到的是LTE侧SIB配置、测量ID映射或者NR-SSB-FREQ对不上。更典型的是60M小区与100M小区共站同覆盖如果SSB栅格不统一终端上报的NR测量结果会和邻区表对不上加腿反反复复失败但网管上没有任何NR告警。这篇文章以中移2.6G NSA组网为例从2.6G频率配置和SSB对齐讲起把SIB解读、UE能力识别、B1测量、辅小区添加、A2删腿、SN变更和带SN的MN切换整条链路拆开并给出日常排障可复用的核查方法。适合做NR接入优化、外场信令分析、后台参数核查和投诉定位的从业人员。2. LTE侧系统消息与UE能力识别NSA第一步不是NR而是SIBNSA终端开机后先当LTE终端用读到的第一条关键信息来自LTE的系统消息之后才是UE能力上报和测量控制。这一章把SIB1、SIB2、RRC Setup Complete和两次UE能力识别串起来讲因为它们共同决定了终端“认不认这个网”“能不能被识别为ENDC终端”“会被路由到哪一张核心网”。2.1 SIB1与SIB2终端认网和显示5G图标的起点SIB1主要核查两项内容PLMN列表和频段信息。示例信令里站点支持46000和46007双PLMN频段为Band3。这里的PLMN列表不是看看就过它带有一个隐含的序号规则后续RRC连接建立完成消息里的selectedPLMN-Identity就是按这个序号引用PLMN的。优化时常见误区是只核对核心网侧配置的PLMN而忽略SIB1里plmn-IdentityList的排列顺序导致双PLMN场景下选网结果和预期不一致。SIB2的重点是additionalGroupInfo-R15字段。在LTE版本为3.70.20并开启endc策略、upperlayerIndication开关设置为yes时SIB2消息会携带该字段支持ENDC的手机解析后会显示5G图标。这里要特别注意一个边界这个字段只负责图标显示和网络能力的“上层指示”不保证NR加腿成功。外场“有5G图标但速率始终是LTE水平”的投诉多数情况下要先区分是图标指示条件与NR覆盖不一致还是后续B1测量和辅小区添加环节出了问题而不是一上来就动NR侧参数。2.2 RRC Connection Setup Complete的选网上报逻辑终端在RRC连接建立完成后通过RrcConnectionSetupComplete消息里的selectedPLMN-Identity字段上报自己的选网结果。示例信令中selectedPLMN-Identity2结合SIB1的顺序对应的是46007这张PLMN。基站收到这个序号后把后续的attach请求转发到对应的核心网完成选网路由。这条链路里有一个经常被忽略的核查点PLMN的“SIB1序号、终端上报序号、核心网路由表”三者必须对应。如果SIB1第一个PLMN是46000第二个是46007但核心网在配置PLMN ID时把46007放在了路由表前面实际attach就可能在核心网侧走错MME信令面表现为注册失败但无线侧一切正常。2.3 两次UE能力识别en-DC支持与频段组合UE能力识别在NSA接入中分两步。第一次识别发生在终端能力上报时携带en-DC-r15 supported字段基站据此判断终端是否支持ENDC能力。只有第一次识别通过基站才会发起第二次识别。第二次识别的关键看频段组合示例中上报的组合包括Band3N41、Band3N77、Band3N78、Band3N79几种。这里的核心关注点不是终端“支不支持5G”而是“支不支持当前站点使用的频段”。中移2.6G对应的是n41如果终端上报的组合里只有Band3n78这一类3.5G组合没有n41那么后续即使B1测量正常上报辅小区添加也会在能力协商阶段失败。外场核查时可以从网管或日志里过滤两段UE能力消息做对比脚本化处理更省时间。import re log open(ue_capability.log, encodingutf-8, errorsignore).read() plmn_list re.findall(rplmn-Identity\s*{[^}]*mcc\s(\d)[^}]*mnc\s(\d), log) selected re.findall(rselectedPLMN-Identity\s(\d), log) en_dc re.findall(ren-DC-r15\s(\w), log) nr_bands re.findall(rbandNR\s(n\d), log) print(PLMN列表:, plmn_list) print(选网序号:, selected) print(en-DC能力:, en_dc) print(NR频段组合:, nr_bands)这段脚本用来快速过滤UE能力日志中的关键字段。逻辑上先从纯文本日志里把plmn-Identity结构、selectedPLMN-Identity值、en-DC-r15关键字和bandNR关键字抽取出来再人工判断。实际使用时可以按网管导出的文件名做批量循环不必逐条翻消息。参数上需要关注的是en_dc结果是否为supported以及nr_bands里是否包含当前站点使用的n41。如果PLMN列表和selected序号对不上优先查SIB1的PLMN排列顺序如果en-DC能力正常但nr_bands没有目标频段问题大概率在终端能力或运营商对UE能力的策略限制不在无线参数。提示SA/NSA能力开关、双连接能力和频段组合这三类字段经常出现在同一条UE能力消息里日志过滤时不要只匹配“5G”关键字而是按en-DC-r15和bandNR同时过滤否则容易漏掉关键字段。3. B1测量配置与辅小区添加NSA接入的测量与RRC重配NSA接入过程中B1测量是发现NR小区的“眼睛”辅小区添加是真正把NR变成服务小区的动作。这一章从测量ID的映射关系讲起再落到辅小区添加CFG里需要盯住的字段最后给出配置失败时的六大原因排查表。这是日常优化工作中重复次数最多的一个环节。3.1 测量对象、事件报告与测量ID的映射关系LTE侧下发的B1测量控制里测量对象、事件报告、测量ID三个维度是一一绑定的。示例信令里给出了三组配置实际工作中也是先看这三组映射是否合理。测量ID测量对象报告配置用途MEASID1measOBJ1LTE 130020MHzreportID1同频A3LTE系统内同频切换MEASID2measOBJ1LTE 130020MHzreportID2异系统A2异系统测量触发类事件MEASID3measOBJ2SSB频点504750reportID3B1门限-140dBmNR发现与辅小区添加触发理解这张表要抓住三个点。第一1300是LTE的EARFCN绝对频点号对应Band3的20MHz载波504750是NR侧SSB的频域位置参数对应2.6G频段上的SSB栅格位置。第二A3用于LTE同频切换A2在这里是“发现当前LTE信号变差”的触发类事件B1才是真正测量NR的门限事件。第三门限-140dBm是B1事件的上报门限不代表NR占用门限。常见误用是优化人员把事件门限当接入门限调整结果导致大量终端在NR信号极弱时上报MR但辅小区添加后又立刻掉链路。事件门限只控制上报时机加腿质量由辅小区添加时的RSRP判决和小区偏置共同决定。3.2 辅小区添加CFGNR-SSB-FREQ和PCI必须优先核对终端满足B1事件后LTE侧下发辅小区添加重配置这就是常见的RRCConnectionReconfiguration过程。这条消息里内容很多但真正决定成败的核心字段集中在spCellConfigCommon消息里具体是NR-SSB-FREQ和PCI。与此同时还要看测量控制里是否有A3事件报告配置。如果重配置里的NR-SSB-FREQ和PCI与实际NR小区广播不一致或者与邻区关系表内的记录不一致终端会做配置合法性校验校验不通过就会直接进入重建流程。这里有一个重要的终端行为差异高通平台的终端在收到无法通过的辅助小区添加CFG后不回复RRCReconfigurationComplete消息而是直接发起RRC重建立请求原因为configuration failure海思平台终端则先回复RRCReconfigurationComplete消息然后再发起other原因的RRC重建立请求。这两个行为差异在实际排障中非常有用看到高通直接重建可以优先怀疑配置字段本身不合法看到海思先回Complete再重建则需要进一步核对配置是否“合法但不满足终端的物理层能力”。3.3 辅小区添加失败六大原因排查表从现网案例和终端兼容性测试来看辅小区添加后立即重建的原因集中在六个方向。这几个原因要么相互叠加要么被误判为NR侧覆盖问题建议按表逐项排查。失败原因核查点处理方向LTE与NR DRB3的RLC模式不一致AM/UM对比LTE侧和NR侧DRB3的rlc-Mode配置将两侧RLC模式统一为AM或UM高通终端不支持上行256QAM终端UE能力与基站上行调制阶数关闭上行256QAM或做终端版本验证高通终端不支持2.6G SRS端口轮发SRS资源轮发配置与终端能力关闭SRS端口轮发改用非轮发模式海思终端不支持SRS端口轮发SRS资源轮发配置与终端能力同上但需按终端批次单独验证NSA手机LTE与NR线性功率超过26dBm上行双连接功率共享和P-Max参数调整功率共享策略或降低最大发射功率NSA手机上行只支持单流终端能力与NR侧上行rank限制核查NR上行rank限制参数关掉rank2限制六个原因里DRB3的RLC模式不一致是配置层面最常见的问题核查时要把LTE侧PDCP/RLC配置和NR侧DRB3配置放在同一个界面里比对。SRS端口轮发问题在2.6G上比较突出高通和海思都出现过特定批次终端加腿后立刻重建的现象排障时先关闭SRS轮发做验证稳定后再考虑升级基带版本。256QAM和线性功率问题多见于手机终端外场复测时如果重建都集中在某几款终端上优先怀疑这两项。提示排查辅小区添加失败时先用网管导出“失败终端所在小区”的NR侧配置再和正常添加成功的小区做diff多数配置类失败在字段级差异里一眼就能看出来。4. A2删腿、带SN的MN切换与SN变更移动性信令链路NSA接入成功后才进入移动性阶段。这一阶段的核心信令链路围绕三个过程NR侧满足A2门限触发删腿、带SN信息的MN切换、SN变更。这三组信令互相嵌套出问题时表现又很接近需要从信令流程顺序来定位。4.1 NR满足A2门限触发删腿的完整链路当NR服务小区信号变差时NR侧触发A2事件随后的信令按固定顺序在LTE和NR之间传递。NR服务小区SS-RSRP低于门限A2事件-140dBm → NR侧通过MR-DC流程把A2事件上报由LTE侧透传 → LTE侧收到NR-A2事件对应的MR → LTE下发辅小区删除CFG消息中nr-Config-r15字段置为release → LTE重新下发NR的B1测量控制 → UE测量NR并上报满足B1事件的NR-MR → LTE收到MR后下发辅小区添加CFG重新加腿这条链路中最容易被忽略的是“删腿后重新下发B1测量”这一步。A2触发删腿不等于放弃NR测量LTE侧会立刻下发新的B1测量控制目的是在NR信号恢复时能快速加腿。如果A2门限和B1门限设置得过近终端在覆盖边缘会反复执行“删腿→B1上报→加腿→信号变差→再删腿”的乒乓过程信令负荷明显上升且容易伴随掉话。现场处理时建议参考路测的SS-RSRP分布让A2和B1之间保留足够滞回区间比如A2配置在-140dBmB1配置在-135dBm左右具体差值要结合站点间距离和切换带宽度来定。4.2 带SN的MN切换MR里携带NR信息是前提带SN的MN切换发生在LTE侧同频A3事件触发时。正常情况下A3事件MR只包含LTE邻区信息但开启带SN切换功能后MR里会同时携带NR小区信息示例信令中手机测量到新LTE小区PCI225、RSRP约等于-72dBm并在同一条MR里上报NR相关信息。LTE侧收到带SN信息的MN切换CFG后把NR的测量控制A2删腿/A3辅节点变更一并转到目标LTE小区实现SN随MN一起切换。这个功能要生效需要三个条件同时满足LTE侧开启带SN切换功能开关、同频A3事件打开最强邻区上报开关、ENDC状态下的A2/A3测量控制正常下发。三个开关缺一个过程就会退化为普通LTE切换终端切换到目标LTE小区后SN丢失还要重新走一遍B1测量和辅小区添加流程表现为切换后5G速率掉底然后回升。核查这类问题时可以用X2口抓包确认SN信息是否真的随切换透传tcpdump -i eth0 -s 0 -w x2_sn_ho.pcap sctp port 36422这段命令在核心网和基站之间的X2接口链路上抓X2AP消息输出的pcap文件用Wireshark打开后重点看Handover Request消息里是否携带了NR相关的IE字段。如果抓包里没有SN信息而空口信令里MR确实带了NR邻区说明基站侧“最强邻区上报”开关没生效如果MR里压根没带NR信息要先查LTE侧同频A3测量的最强邻区上报配置而不是去NR侧找原因。注意抓包端口按现网实际部署的X2 SCTP端口调整这里给出的是常见端口示例。4.3 SN变更NR侧A3事件经LTE透传SN变更走的是另一条路径。示例信令里手机上报的NR-A3事件显示当前服务辅小区PCI 108的SS-RSRP为72对应的接收电平约-84dBm相邻NR小区的SS-RSRP为75对应约-81dBm差值满足默认的SN变更A3门限于是触发辅小区变更流程。NR侧A3事件的MR先由NR透传给LTELTE收到后下发SN变更CFG再透传给NR侧的modem完成变更。SN变更排障中最常见的误用是把SN变更的A3门限和LTE系统内A3门限混在一起调。这两个A3事件一个在NR侧测量配置里一个在LTE侧测量配置里虽然都叫A3但参数对象完全不同。如果发现终端持续上报NR-A3 MR但网管上始终没有SN变更CFG优先检查NR侧测量配置里的A3门限、TTT和同频测量间隔而不是去动LTE侧的A3参数。TTT设置过大会导致SN变更迟迟不触发测量间隔配置过密则会挤占数据业务资源外场表现为“打电话正常、5G速率波动大”。5. 用信令日志字段比对法定位辅小区添加失败的配置源头辅小区添加失败这类问题的排查最容易走弯路的方向是从NR侧告警和小区状态开始查。实际上NSA机制下LTE下发的辅小区添加CFG就是“最后的判决书”终端用不用这条配置、校验通不通过行为差异非常明显。这一章给一个可复用的字段级比对法先把终端行为定级再做配置diff不碰NR侧告警也能定位到字段源头。5.1 终端行为先定级高通直接重建海思先确认再重建拿到一份辅小区添加失败的日志先看RRC重建的触发位置。高通关机直接发起RRC重建立原因值为configuration failure说明CFG消息里的某个字段没有通过终端的ASN.1合法性校验优先怀疑NR-SSB-FREQ、PCI、RLC模式这类基础字段。海思终端先回RRCReconfigurationComplete再发起other原因的重建说明消息本身合法但终端在执行过程中发现物理层或能力层条件不满足重点检查SRS端口轮发、256QAM、上行单流这一类依赖终端能力的配置。这一步做完至少能砍掉一半排查方向。5.2 用脚本对正常与失败CFG做字段diff找一台正常加腿成功的终端和一台失败终端各取一份辅小区添加CFG日志放到同一个目录里跑字段比对。import re def extract_cfg(path): text open(path, encodingutf-8, errorsignore).read() return { pci: re.findall(rphysCellId\s(\d), text), ssb_freq: re.findall(r(?:ssb-Freq|absFrequencySSB)\s(\d), text), rlc_mode: re.findall(rrlc-Mode\s(\w), text), srs_type: re.findall(r(?:srs-|soundingRS)\w*, text)[:5], } ok extract_cfg(add_ok.log) bad extract_cfg(add_fail.log) for key in ok: if ok[key] ! bad[key]: print(f{key}: OK{ok[key]} FAIL{bad[key]})脚本把两份日志里的PCI、SSB频点、RLC模式、SRS相关字段分别抽出来然后逐个比对不同的字段会被打印出来。这样做的价值在于与其在几百行RRC消息里人工翻差异不如让脚本先缩小范围。实际使用中常见的结果是PCI和ssb_freq不一致直接指向邻区表或NR小区配置rlc_mode不一致指向DRB3承载配置srs_type差异多半是终端版本与站点配置的兼容性冲突。需要注意脚本只是粗筛最终确认还要结合ASN.1解析后的完整字段但作为第一道过滤器足够高效。辅小区添加失败的排查从配置差异和终端行为入手找到字段差异的那一刻配置源头就浮出来了。本文还有配套的精品资源点击获取
NSA接入5G信令流程中LTE侧关键点解析与排障
简介这份PPT围绕5G网络优化中的核心信令流程展开面向4G/5G互操作、NSA组网优化的网优工程师及通信专业学生重点讲解频谱资源分配、SSB对齐、UE接入流程、系统消息解读、UE能力识别、测量控制与辅小区添加等关键知识点。资源为单个PPTX演示文稿共1个文件压缩包约1.54MB结构紧凑适合移动学习与实战查阅。目前已有419人学习浏览内容来源于一线优化经验。PPT里嵌入中移2.6GHz频段配置实例对比60MHz与100MHz小区的Cell freq和SSB GSCN设置拆解LTE侧SIB1/SIB2关键字段对选网和ENDC策略的影响详细说明B1测量门限、A2/A3事件触发逻辑并针对辅小区添加失败后的RRC重建立原因如DRB3 RLC模式不一致、上行256QAM不兼容等给出排查要点同时涵盖EN-DC频段组合识别与测量上报的RSRP评估方法。适合希望从信令细节入手提升5G网络问题定位与参数配置能力的读者参考。1. 中移2.6G下NSA接入的5G信令流程一半问题出在LTE侧NSA组网下的5G信令流程前半段几乎全跑在LTE侧。终端先驻留LTE再通过LTE下发的B1测量、辅小区添加、A2删腿这些信令把NR“拉进来”或者“放出去”。做中移2.6G优化的人应该都有印象很多NR接入问题在后台看小区状态全部正常但外场就是加不上腿最后定位到的是LTE侧SIB配置、测量ID映射或者NR-SSB-FREQ对不上。更典型的是60M小区与100M小区共站同覆盖如果SSB栅格不统一终端上报的NR测量结果会和邻区表对不上加腿反反复复失败但网管上没有任何NR告警。这篇文章以中移2.6G NSA组网为例从2.6G频率配置和SSB对齐讲起把SIB解读、UE能力识别、B1测量、辅小区添加、A2删腿、SN变更和带SN的MN切换整条链路拆开并给出日常排障可复用的核查方法。适合做NR接入优化、外场信令分析、后台参数核查和投诉定位的从业人员。2. LTE侧系统消息与UE能力识别NSA第一步不是NR而是SIBNSA终端开机后先当LTE终端用读到的第一条关键信息来自LTE的系统消息之后才是UE能力上报和测量控制。这一章把SIB1、SIB2、RRC Setup Complete和两次UE能力识别串起来讲因为它们共同决定了终端“认不认这个网”“能不能被识别为ENDC终端”“会被路由到哪一张核心网”。2.1 SIB1与SIB2终端认网和显示5G图标的起点SIB1主要核查两项内容PLMN列表和频段信息。示例信令里站点支持46000和46007双PLMN频段为Band3。这里的PLMN列表不是看看就过它带有一个隐含的序号规则后续RRC连接建立完成消息里的selectedPLMN-Identity就是按这个序号引用PLMN的。优化时常见误区是只核对核心网侧配置的PLMN而忽略SIB1里plmn-IdentityList的排列顺序导致双PLMN场景下选网结果和预期不一致。SIB2的重点是additionalGroupInfo-R15字段。在LTE版本为3.70.20并开启endc策略、upperlayerIndication开关设置为yes时SIB2消息会携带该字段支持ENDC的手机解析后会显示5G图标。这里要特别注意一个边界这个字段只负责图标显示和网络能力的“上层指示”不保证NR加腿成功。外场“有5G图标但速率始终是LTE水平”的投诉多数情况下要先区分是图标指示条件与NR覆盖不一致还是后续B1测量和辅小区添加环节出了问题而不是一上来就动NR侧参数。2.2 RRC Connection Setup Complete的选网上报逻辑终端在RRC连接建立完成后通过RrcConnectionSetupComplete消息里的selectedPLMN-Identity字段上报自己的选网结果。示例信令中selectedPLMN-Identity2结合SIB1的顺序对应的是46007这张PLMN。基站收到这个序号后把后续的attach请求转发到对应的核心网完成选网路由。这条链路里有一个经常被忽略的核查点PLMN的“SIB1序号、终端上报序号、核心网路由表”三者必须对应。如果SIB1第一个PLMN是46000第二个是46007但核心网在配置PLMN ID时把46007放在了路由表前面实际attach就可能在核心网侧走错MME信令面表现为注册失败但无线侧一切正常。2.3 两次UE能力识别en-DC支持与频段组合UE能力识别在NSA接入中分两步。第一次识别发生在终端能力上报时携带en-DC-r15 supported字段基站据此判断终端是否支持ENDC能力。只有第一次识别通过基站才会发起第二次识别。第二次识别的关键看频段组合示例中上报的组合包括Band3N41、Band3N77、Band3N78、Band3N79几种。这里的核心关注点不是终端“支不支持5G”而是“支不支持当前站点使用的频段”。中移2.6G对应的是n41如果终端上报的组合里只有Band3n78这一类3.5G组合没有n41那么后续即使B1测量正常上报辅小区添加也会在能力协商阶段失败。外场核查时可以从网管或日志里过滤两段UE能力消息做对比脚本化处理更省时间。import re log open(ue_capability.log, encodingutf-8, errorsignore).read() plmn_list re.findall(rplmn-Identity\s*{[^}]*mcc\s(\d)[^}]*mnc\s(\d), log) selected re.findall(rselectedPLMN-Identity\s(\d), log) en_dc re.findall(ren-DC-r15\s(\w), log) nr_bands re.findall(rbandNR\s(n\d), log) print(PLMN列表:, plmn_list) print(选网序号:, selected) print(en-DC能力:, en_dc) print(NR频段组合:, nr_bands)这段脚本用来快速过滤UE能力日志中的关键字段。逻辑上先从纯文本日志里把plmn-Identity结构、selectedPLMN-Identity值、en-DC-r15关键字和bandNR关键字抽取出来再人工判断。实际使用时可以按网管导出的文件名做批量循环不必逐条翻消息。参数上需要关注的是en_dc结果是否为supported以及nr_bands里是否包含当前站点使用的n41。如果PLMN列表和selected序号对不上优先查SIB1的PLMN排列顺序如果en-DC能力正常但nr_bands没有目标频段问题大概率在终端能力或运营商对UE能力的策略限制不在无线参数。提示SA/NSA能力开关、双连接能力和频段组合这三类字段经常出现在同一条UE能力消息里日志过滤时不要只匹配“5G”关键字而是按en-DC-r15和bandNR同时过滤否则容易漏掉关键字段。3. B1测量配置与辅小区添加NSA接入的测量与RRC重配NSA接入过程中B1测量是发现NR小区的“眼睛”辅小区添加是真正把NR变成服务小区的动作。这一章从测量ID的映射关系讲起再落到辅小区添加CFG里需要盯住的字段最后给出配置失败时的六大原因排查表。这是日常优化工作中重复次数最多的一个环节。3.1 测量对象、事件报告与测量ID的映射关系LTE侧下发的B1测量控制里测量对象、事件报告、测量ID三个维度是一一绑定的。示例信令里给出了三组配置实际工作中也是先看这三组映射是否合理。测量ID测量对象报告配置用途MEASID1measOBJ1LTE 130020MHzreportID1同频A3LTE系统内同频切换MEASID2measOBJ1LTE 130020MHzreportID2异系统A2异系统测量触发类事件MEASID3measOBJ2SSB频点504750reportID3B1门限-140dBmNR发现与辅小区添加触发理解这张表要抓住三个点。第一1300是LTE的EARFCN绝对频点号对应Band3的20MHz载波504750是NR侧SSB的频域位置参数对应2.6G频段上的SSB栅格位置。第二A3用于LTE同频切换A2在这里是“发现当前LTE信号变差”的触发类事件B1才是真正测量NR的门限事件。第三门限-140dBm是B1事件的上报门限不代表NR占用门限。常见误用是优化人员把事件门限当接入门限调整结果导致大量终端在NR信号极弱时上报MR但辅小区添加后又立刻掉链路。事件门限只控制上报时机加腿质量由辅小区添加时的RSRP判决和小区偏置共同决定。3.2 辅小区添加CFGNR-SSB-FREQ和PCI必须优先核对终端满足B1事件后LTE侧下发辅小区添加重配置这就是常见的RRCConnectionReconfiguration过程。这条消息里内容很多但真正决定成败的核心字段集中在spCellConfigCommon消息里具体是NR-SSB-FREQ和PCI。与此同时还要看测量控制里是否有A3事件报告配置。如果重配置里的NR-SSB-FREQ和PCI与实际NR小区广播不一致或者与邻区关系表内的记录不一致终端会做配置合法性校验校验不通过就会直接进入重建流程。这里有一个重要的终端行为差异高通平台的终端在收到无法通过的辅助小区添加CFG后不回复RRCReconfigurationComplete消息而是直接发起RRC重建立请求原因为configuration failure海思平台终端则先回复RRCReconfigurationComplete消息然后再发起other原因的RRC重建立请求。这两个行为差异在实际排障中非常有用看到高通直接重建可以优先怀疑配置字段本身不合法看到海思先回Complete再重建则需要进一步核对配置是否“合法但不满足终端的物理层能力”。3.3 辅小区添加失败六大原因排查表从现网案例和终端兼容性测试来看辅小区添加后立即重建的原因集中在六个方向。这几个原因要么相互叠加要么被误判为NR侧覆盖问题建议按表逐项排查。失败原因核查点处理方向LTE与NR DRB3的RLC模式不一致AM/UM对比LTE侧和NR侧DRB3的rlc-Mode配置将两侧RLC模式统一为AM或UM高通终端不支持上行256QAM终端UE能力与基站上行调制阶数关闭上行256QAM或做终端版本验证高通终端不支持2.6G SRS端口轮发SRS资源轮发配置与终端能力关闭SRS端口轮发改用非轮发模式海思终端不支持SRS端口轮发SRS资源轮发配置与终端能力同上但需按终端批次单独验证NSA手机LTE与NR线性功率超过26dBm上行双连接功率共享和P-Max参数调整功率共享策略或降低最大发射功率NSA手机上行只支持单流终端能力与NR侧上行rank限制核查NR上行rank限制参数关掉rank2限制六个原因里DRB3的RLC模式不一致是配置层面最常见的问题核查时要把LTE侧PDCP/RLC配置和NR侧DRB3配置放在同一个界面里比对。SRS端口轮发问题在2.6G上比较突出高通和海思都出现过特定批次终端加腿后立刻重建的现象排障时先关闭SRS轮发做验证稳定后再考虑升级基带版本。256QAM和线性功率问题多见于手机终端外场复测时如果重建都集中在某几款终端上优先怀疑这两项。提示排查辅小区添加失败时先用网管导出“失败终端所在小区”的NR侧配置再和正常添加成功的小区做diff多数配置类失败在字段级差异里一眼就能看出来。4. A2删腿、带SN的MN切换与SN变更移动性信令链路NSA接入成功后才进入移动性阶段。这一阶段的核心信令链路围绕三个过程NR侧满足A2门限触发删腿、带SN信息的MN切换、SN变更。这三组信令互相嵌套出问题时表现又很接近需要从信令流程顺序来定位。4.1 NR满足A2门限触发删腿的完整链路当NR服务小区信号变差时NR侧触发A2事件随后的信令按固定顺序在LTE和NR之间传递。NR服务小区SS-RSRP低于门限A2事件-140dBm → NR侧通过MR-DC流程把A2事件上报由LTE侧透传 → LTE侧收到NR-A2事件对应的MR → LTE下发辅小区删除CFG消息中nr-Config-r15字段置为release → LTE重新下发NR的B1测量控制 → UE测量NR并上报满足B1事件的NR-MR → LTE收到MR后下发辅小区添加CFG重新加腿这条链路中最容易被忽略的是“删腿后重新下发B1测量”这一步。A2触发删腿不等于放弃NR测量LTE侧会立刻下发新的B1测量控制目的是在NR信号恢复时能快速加腿。如果A2门限和B1门限设置得过近终端在覆盖边缘会反复执行“删腿→B1上报→加腿→信号变差→再删腿”的乒乓过程信令负荷明显上升且容易伴随掉话。现场处理时建议参考路测的SS-RSRP分布让A2和B1之间保留足够滞回区间比如A2配置在-140dBmB1配置在-135dBm左右具体差值要结合站点间距离和切换带宽度来定。4.2 带SN的MN切换MR里携带NR信息是前提带SN的MN切换发生在LTE侧同频A3事件触发时。正常情况下A3事件MR只包含LTE邻区信息但开启带SN切换功能后MR里会同时携带NR小区信息示例信令中手机测量到新LTE小区PCI225、RSRP约等于-72dBm并在同一条MR里上报NR相关信息。LTE侧收到带SN信息的MN切换CFG后把NR的测量控制A2删腿/A3辅节点变更一并转到目标LTE小区实现SN随MN一起切换。这个功能要生效需要三个条件同时满足LTE侧开启带SN切换功能开关、同频A3事件打开最强邻区上报开关、ENDC状态下的A2/A3测量控制正常下发。三个开关缺一个过程就会退化为普通LTE切换终端切换到目标LTE小区后SN丢失还要重新走一遍B1测量和辅小区添加流程表现为切换后5G速率掉底然后回升。核查这类问题时可以用X2口抓包确认SN信息是否真的随切换透传tcpdump -i eth0 -s 0 -w x2_sn_ho.pcap sctp port 36422这段命令在核心网和基站之间的X2接口链路上抓X2AP消息输出的pcap文件用Wireshark打开后重点看Handover Request消息里是否携带了NR相关的IE字段。如果抓包里没有SN信息而空口信令里MR确实带了NR邻区说明基站侧“最强邻区上报”开关没生效如果MR里压根没带NR信息要先查LTE侧同频A3测量的最强邻区上报配置而不是去NR侧找原因。注意抓包端口按现网实际部署的X2 SCTP端口调整这里给出的是常见端口示例。4.3 SN变更NR侧A3事件经LTE透传SN变更走的是另一条路径。示例信令里手机上报的NR-A3事件显示当前服务辅小区PCI 108的SS-RSRP为72对应的接收电平约-84dBm相邻NR小区的SS-RSRP为75对应约-81dBm差值满足默认的SN变更A3门限于是触发辅小区变更流程。NR侧A3事件的MR先由NR透传给LTELTE收到后下发SN变更CFG再透传给NR侧的modem完成变更。SN变更排障中最常见的误用是把SN变更的A3门限和LTE系统内A3门限混在一起调。这两个A3事件一个在NR侧测量配置里一个在LTE侧测量配置里虽然都叫A3但参数对象完全不同。如果发现终端持续上报NR-A3 MR但网管上始终没有SN变更CFG优先检查NR侧测量配置里的A3门限、TTT和同频测量间隔而不是去动LTE侧的A3参数。TTT设置过大会导致SN变更迟迟不触发测量间隔配置过密则会挤占数据业务资源外场表现为“打电话正常、5G速率波动大”。5. 用信令日志字段比对法定位辅小区添加失败的配置源头辅小区添加失败这类问题的排查最容易走弯路的方向是从NR侧告警和小区状态开始查。实际上NSA机制下LTE下发的辅小区添加CFG就是“最后的判决书”终端用不用这条配置、校验通不通过行为差异非常明显。这一章给一个可复用的字段级比对法先把终端行为定级再做配置diff不碰NR侧告警也能定位到字段源头。5.1 终端行为先定级高通直接重建海思先确认再重建拿到一份辅小区添加失败的日志先看RRC重建的触发位置。高通关机直接发起RRC重建立原因值为configuration failure说明CFG消息里的某个字段没有通过终端的ASN.1合法性校验优先怀疑NR-SSB-FREQ、PCI、RLC模式这类基础字段。海思终端先回RRCReconfigurationComplete再发起other原因的重建说明消息本身合法但终端在执行过程中发现物理层或能力层条件不满足重点检查SRS端口轮发、256QAM、上行单流这一类依赖终端能力的配置。这一步做完至少能砍掉一半排查方向。5.2 用脚本对正常与失败CFG做字段diff找一台正常加腿成功的终端和一台失败终端各取一份辅小区添加CFG日志放到同一个目录里跑字段比对。import re def extract_cfg(path): text open(path, encodingutf-8, errorsignore).read() return { pci: re.findall(rphysCellId\s(\d), text), ssb_freq: re.findall(r(?:ssb-Freq|absFrequencySSB)\s(\d), text), rlc_mode: re.findall(rrlc-Mode\s(\w), text), srs_type: re.findall(r(?:srs-|soundingRS)\w*, text)[:5], } ok extract_cfg(add_ok.log) bad extract_cfg(add_fail.log) for key in ok: if ok[key] ! bad[key]: print(f{key}: OK{ok[key]} FAIL{bad[key]})脚本把两份日志里的PCI、SSB频点、RLC模式、SRS相关字段分别抽出来然后逐个比对不同的字段会被打印出来。这样做的价值在于与其在几百行RRC消息里人工翻差异不如让脚本先缩小范围。实际使用中常见的结果是PCI和ssb_freq不一致直接指向邻区表或NR小区配置rlc_mode不一致指向DRB3承载配置srs_type差异多半是终端版本与站点配置的兼容性冲突。需要注意脚本只是粗筛最终确认还要结合ASN.1解析后的完整字段但作为第一道过滤器足够高效。辅小区添加失败的排查从配置差异和终端行为入手找到字段差异的那一刻配置源头就浮出来了。本文还有配套的精品资源点击获取