简介面向5G SA室分网络优化与维护工程师这份实战案例以A小区QoS Flow建立成功率异常为切入点按照问题发现、根因定位、参数调整、效果验证的完整思路逐步记录了从指标劣化、告警排查、信令跟踪到协调研发定位问题的全过程。该小区成功率最低跌至56.32%每日失败次数高达4275次根因锁定为部分终端不支持1T传输模式导致CSI相关参数配置不匹配。通过启用CSI-RS、调整CSI报告数量等参数优化成功率回升至99.89%失败次数降至42次/天。资源为单个docx文档约85KB内容包含现象描述、问题分析、信令跟踪要点、参数调整前后指标对比、全区12个同类站点整改方法及后续预防建议。已有502人学习下载可直接用于同类室分接入异常排查对提升接通率和用户感知具有很高参考价值。1. 从56.32%说起SA室分QoS Flow建立成功率为何单点塌陷最近监控5G SA指标时A小区的QoS Flow建立成功率被标红只有56.32%无线接通率跟着掉到55.87%。但旁边几个分项指标几乎全绿SA_RRC连接建立成功率99.51%SA_NG接口UE相关逻辑信令连接建立成功率99.71%。接入流程没问题业务建立却大面积失败问题藏在中间那一段。再拉失败counter4275次/天的失败全部落在“分5QI的QoS Flow建立失败次数其它原因”。原因值是“其它”说明常规统计层面没有细分到可定位的环节靠指标逐层下钻是钻不到底的。实际处理中发现这是SA室分单通道错层覆盖场景下CSI-RS上报配置与终端能力不匹配导致的。部分终端只支持1T传输而小区配置的上报量却要求反馈PMIUE卡在RRC重配环节QoS Flow自然建不起来。这篇文章把这个案例的定位过程、参数修改、全区核查方法一次讲透适合做5G优化和室分维护的工程师参考。2. 信令跟踪与UE能力确认cri-RI-PMI-CQI为何卡住了1T终端2.1 常规核查无告警、配置基线正常问题定位第一步不是动参数而是把硬件、传输、基础配置的变量清干净。先查A小区站点状态无告警、无驻波、传输链路正常。然后翻开设计图纸这个站点是双通道错层覆盖两个通道分别覆盖不同楼层或区域并不是同一个小区做双流MIMO。这种场景下基站侧应该按单通道室分基线配置核查结果也确实如此没有发现配置异常。这里有个容易出错的点很多人看到“双通道”就默认按双流MIMO核查但错层覆盖的“双通道”是覆盖叠加关系不是空间复用关系。如果按双流参数去核查CSI-RS和PMI上报反而会把问题掩盖住以为配置没问题。常规核查汇总如下表核查项检查内容结果站点状态告警、驻波、光模块正常传输链路NG接口、S1接口状态正常覆盖设计双通道错层覆盖单通道逻辑小区配置频点、带宽、PCI、功率正常基线配置室分单通道基线未发现异常常规项全部通过说明问题不在射频、传输和基本小区参数。真正需要留意的是基线配置里的CSI部分。很多优化工程师查配置时只看PCI、频点、带宽、功率CSI-RS上报模式这种参数容易被跳过去。而QoS Flow建立阶段终端要按网络下发的测量配置完成CSI上报如果配置超出了终端能力重配流程就会中断。2.2 信令跟踪重配消息发出后没有Complete既然Counter原因值无法定位只能用信令跟踪。在网管侧对A小区做用户级信令跟踪抓取QoS Flow建立失败时间段内的RRC信令。多次跟踪结果非常一致基站下发RRC Connection Reconfiguration携带CSI-ReportConfig配置但一直等不到UE回RRC Connection Reconfiguration Complete。从消息里能看到两个关键信息CSI配置中的ROW1上报量是cri-RI-PMI-CQI。这里补一下背景。cri-RI-PMI-CQI这种上报模式UE要上报CRICSI-RS资源指示、RI秩指示、PMI预编码矩阵指示和CQI。PMI的物理意义是告诉基站“用哪个预编码向量或矩阵来发数据”这要求终端有多天线端口做预编码选择。如果UE只支持单天线传输1T或者小区当前就是单通道逻辑PMI反馈无从谈起UE就会卡在配置生效这一步。信令表现就是重配没有完成紧接着QoS Flow建立失败。我写了一段脚本从信令日志里批量提取这些字段方便看失败规律# 解析信令跟踪日志筛选CSI配置与重配完成情况 import re def scan_reconfig_log(log_path): # 匹配RRC重配消息中的CSI row和reportQuantity字段 pattern re.compile( rRRCConnectionReconfiguration.*? rrow[: ](\d).*? rreportQuantity[: ]([a-zA-Z\-]), re.S ) with open(log_path, r, encodingutf-8) as f: content f.read() for match in pattern.finditer(content): row match.group(1) report_qty match.group(2) # 如果上报量含PMI且后面没有Complete标注为可疑 suspicious PMI in report_qty.upper() and \ content.find(RRCConnectionReconfigurationComplete, match.end()) -1 if suspicious: print(frow{row}, reportQuantity{report_qty} - 重配未完成)这段脚本用正则从日志里抓row和reportQuantity再根据后面有没有Complete判断是否失败。实际网管导出的日志格式比这复杂正则表达式要根据厂商格式调整但筛选逻辑是一样的。A小区的失败记录里几乎所有可疑条目都是row1且reportQuantity带PMI这已经指向参数与终端能力的兼容问题。2.3 研发确认1T终端不适用PMI上报模式拿着信令截图和参数列表找研发确认结论很直接部分终端只支持1T传输不支持带PMI的上报模式。若小区配置cri-RI-PMI-CQI需要传输模式在2T及以上如果实测终端是1T应把上报量改为cri-RI-CQI这个模式支持1T。这也解释了为什么失败终端的UE能力几乎一致都是那类只支持单天线传输的终端。CSI上报模式是否包含PMI对传输模式的要求适用场景cri-RI-CQI否支持1T单通道室分、错层覆盖cri-RI-PMI-CQI是2T及以上双流MIMO、宏站多天线这个问题的官方Counter原因值之所以是“其它”是因为统计层面只知道建立失败不知道失败发生在重配阶段。5QI粒度没有细化到CSI上报这个环节必须靠信令把失败环节定位到RRC层才能对上参数问题。我见过有人把这种指标波动归到同频干扰加了一圈外部干扰排查反而耽误时间。关键判断点是RRC建立成功率、NG口信令成功率都正常只有QoS Flow建立失败说明UE已经完成初始接入倒在了业务承载建立阶段这个阶段最容易被忽略的就是CSI测量配置和UE能力的握手。3. 参数落地CSI-RS行数与上报量的具体操作3.1 关键参数表与修改逻辑确认根因后参数修改方案很清晰核心是把上报模式从cri-RI-PMI-CQI降级到cri-RI-CQI同时调整CSI-RS的行数配置。下表是本次实际修改的参数参数名按网管配置项展开参数名修改前修改后作用说明CQIMeasureCfg csiRsEnableTRUETRUE保持CSI-RS测量开启CQIMeasureCfg csiRow12CSI-RS资源映射行数适配单通道室分CQIMeasureCfg csirsPortAntMap全0映射全0映射单端口映射不变CQIMeasureCfg reportQuantitycriricqpmicriricqi上报量去掉PMI只保留CRIRICQIAprdPmiMeasureCfg csiRsEnableTRUEFALSE关闭PMI测量配置逐条解释。csiRow是CSI-RS的时频图案参数不同行号对应不同的资源映射密度。A小区原来是1改成2之后1T终端也能按这个pattern完成CSI-RS测量。reportQuantity是关键从criricqpmi改成criricqi后UE不再被要求反馈PMI1T终端就不会在重配阶段卡住。AprdPmiMeasureCfg的csiRsEnable改成FALSE是为了把PMI测量链路整个关掉避免基站侧继续按多端口方式调度。需要注意csirsPortAntMap这次没动仍然是全0映射因为室分单通道逻辑下CSI-RS端口就是单端口改成多端口反而和物理通道对不上。实际修改时要保证三个参数作为一个组合下发不能只改一个。比如只把reportQuantity改成criricqi但保留csiRow1部分终端仍然可能在CSI测量资源上拿不到稳定结果失败次数会下降但不彻底。3.2 用网管命令完成修改的示例现网调整走网管MML命令。不同设备商的命令字不一样但参数结构类似下面这个示例是我在项目里常用的写法# 修改CQI测量配置保持CSI-RS开启csiRow改为2上报量改为CRI-RI-CQI MOD NRCELLCQIMESCFG: NrCellId1, CsiRsEnableTRUE, CsiRow2, ReportQuantityCRI-RI-CQI; # 关闭PMI测量配置 MOD NRCELLPMIMEASCFG: NrCellId1, CsiRsEnableFALSE;第一条命令把CSI-RS行数和上报量一次改到位第二条命令关闭PMI测量。执行前先查询当前配置把修改前的参数值记录下来。命令执行后通常立即下发不需要重启小区重配置流程会在下一个接入请求时触发。设备商差异较大具体命令以现场网管手册为准但参数名和值的对应关系是一致的。我在执行时会额外做一步把修改前后的参数值截图存到工单附件里方便后续回溯。这类参数改动虽然可以热生效但如果改错终端侧行为会影响整个小区的用户体验所以操作前要把“当前值”和“目标值”写清楚再提交。3.3 参数生效后的验证思路参数修改后的验证不能等日报要在网管监控界面实时看Counter。A小区修改时间是5月11日当天失败次数从4275次降到1031次说明大部分1T终端已经能正常完成重配。当天QoS Flow建立成功率只回到96.92%还在缓慢恢复这是剩余终端和存量会话的滞后效应不是参数没有生效。如果改动后失败次数没有变化反过来检查三件事参数是否真的下发到了目标小区有没有被其他策略覆盖终端版本是否确认支持cri-RI-CQI上报以及旁边是否有同频干扰抬高了底噪。参数兼容问题修完后失败次数下降曲线是非常陡峭的如果依然是几百上千次往往还有第二层原因不要只盯一个参数。4. 指标恢复与全区核查从单小区整改到12个站点批量处理4.1 调整前后指标对比直接看A小区调整前后四天的指标变化能很直观地理解参数效果日期无线接通率(%)SA_RRC连接建立成功率(%)SA_QoSFlow建立成功率(%)NG口信令成功率(%)其它原因失败次数5月10日55.8899.5156.3299.714,2755月11日96.5199.6596.9299.921,0315月12日99.4699.5799.89100395月13日99.6299.7499.89100425月10日是问题基线QoS Flow建立成功率56.32%失败次数4275。5月11日改参数当天无线接通率回到96.51%QoSFlow建立成功率96.92%。5月12日、13日基本收敛到99.89%失败次数降到40次上下。这说明修改csiRow和reportQuantity后1T终端的重配流程被打通网络侧不再因为等不到PMI上报而超时释放。注意无线接通率和QoS Flow建立成功率是强关联的。无线接通率本身就是以QoS Flow建立成功为关键事件计算的指标所以QoS Flow恢复后接通率也被拉回到正常区间。之前看到55.88%实际上是QoS Flow失败拖累的结果不是随机接入出了问题。4.2 批量核查条件与SQL脚本A小区的问题解决了但要防的是全区存在同类配置。室分站点数量多一个个点开网管看不现实。我采用的办法是把全网站点配置导出到数据库用一条SQL把“单通道错层室分 csiRow1 reportQuantity含PMI”的小区筛出来-- 筛选疑似存在1T终端兼容问题的室分小区 SELECT s.site_name, c.cell_id, c.csi_row, c.report_quantity FROM site s JOIN cell_config c ON s.site_id c.site_id WHERE s.site_type 室分 AND s.cover_mode LIKE %错层% AND c.csi_row 1 AND UPPER(c.report_quantity) LIKE %PMI%;这里site_type限定室内分布cover_mode用错层匹配避免误伤双流区域。csi_row1加上report_quantity含PMI正好对应A小区的原始问题配置。筛选结果里再结合现网站点是否按单通道基线配置就能确定候选清单。筛选条件不要只用其中一个必须site_type和cover_mode同时过滤否则会捞出一堆宏站的小区人工复核工作量很大。配置导出这一步不同厂商的网管支持程度不同。能直接查数据库的走SQL不能走SQL的就把全网配置批量导出为XML再用脚本解析。SQL里的LIKE %PMI%不能漏掉大小写过滤我在条件里加了UPPER否则部分厂商配置里存的是小写会漏数据。4.3 整改结果与经验固化按这个逻辑核查全区共发现12个同类室分站点覆盖场景一致都是单通道错层覆盖且CSI配置含PMI。逐个做信令跟踪确认后按A小区的参数模板统一整改。整改完成后这12个站点的QoS Flow建立成功率和无线接通率全部恢复正常。这个数据说明室分建设期按“双通道”字面配置CSI参数的现象不是孤例错层覆盖下必须有明确的单通道参数基线。做完这一步我把核查逻辑和参数模板整理成了脚本和表格每次新建室分站开通前都比对一次确保建设期就把csiRow和上报量配成单通道版本。同时把这次处理的参数、信令特征、指标对比表一起归档到室分优化手册里作为后续同类问题的标准参考。5. 把问题变成手册QoS Flow建立成功率异常的快速判定技巧5.1 监控触发条件与预判在网管指标中心把QoS Flow建立成功率监控阈值设为98%。当指标低于阈值且失败Counter里“其它原因”占比超过80%时直接进入这类问题的排查路径。“其它原因”占比高是参数兼容问题的典型特征。如果失败原因分布在“无线层问题”、“传输问题”上则优先查覆盖和传输不要被这个案例带偏。5.2 现场三步验证法第一看配置检查csiRow是否为1、reportQuantity是否含PMI。第二看信令跟踪失败用户重点看RRC重配置消息的CSI字段以及是否收到RRC Connection Reconfiguration Complete。第三看终端能力统计失败UE的能力字段确认是否为1T终端。三步走完就能确定是否走本案例的整改方案。如果第三步统计出来的终端五花八门有1T也有2T那就要再排查其他因素不能一概而论。5.3 参数模板归档与配置源头控制把修改前后的参数表、信令特征、指标对比连同12个站点的整改记录一起固化到日常优化手册里。在网管配置模板里把室分单通道小区的csiRow默认值改为2、reportQuantity默认改为cri-RI-CQI新建站开通时直接套用从配置源头把这类失败挡在建设期。本文还有配套的精品资源点击获取 5G室分QoS Flow建立成功率低？CSI-RS上报参数与终端能力匹配优化实战
简介面向5G SA室分网络优化与维护工程师这份实战案例以A小区QoS Flow建立成功率异常为切入点按照问题发现、根因定位、参数调整、效果验证的完整思路逐步记录了从指标劣化、告警排查、信令跟踪到协调研发定位问题的全过程。该小区成功率最低跌至56.32%每日失败次数高达4275次根因锁定为部分终端不支持1T传输模式导致CSI相关参数配置不匹配。通过启用CSI-RS、调整CSI报告数量等参数优化成功率回升至99.89%失败次数降至42次/天。资源为单个docx文档约85KB内容包含现象描述、问题分析、信令跟踪要点、参数调整前后指标对比、全区12个同类站点整改方法及后续预防建议。已有502人学习下载可直接用于同类室分接入异常排查对提升接通率和用户感知具有很高参考价值。1. 从56.32%说起SA室分QoS Flow建立成功率为何单点塌陷最近监控5G SA指标时A小区的QoS Flow建立成功率被标红只有56.32%无线接通率跟着掉到55.87%。但旁边几个分项指标几乎全绿SA_RRC连接建立成功率99.51%SA_NG接口UE相关逻辑信令连接建立成功率99.71%。接入流程没问题业务建立却大面积失败问题藏在中间那一段。再拉失败counter4275次/天的失败全部落在“分5QI的QoS Flow建立失败次数其它原因”。原因值是“其它”说明常规统计层面没有细分到可定位的环节靠指标逐层下钻是钻不到底的。实际处理中发现这是SA室分单通道错层覆盖场景下CSI-RS上报配置与终端能力不匹配导致的。部分终端只支持1T传输而小区配置的上报量却要求反馈PMIUE卡在RRC重配环节QoS Flow自然建不起来。这篇文章把这个案例的定位过程、参数修改、全区核查方法一次讲透适合做5G优化和室分维护的工程师参考。2. 信令跟踪与UE能力确认cri-RI-PMI-CQI为何卡住了1T终端2.1 常规核查无告警、配置基线正常问题定位第一步不是动参数而是把硬件、传输、基础配置的变量清干净。先查A小区站点状态无告警、无驻波、传输链路正常。然后翻开设计图纸这个站点是双通道错层覆盖两个通道分别覆盖不同楼层或区域并不是同一个小区做双流MIMO。这种场景下基站侧应该按单通道室分基线配置核查结果也确实如此没有发现配置异常。这里有个容易出错的点很多人看到“双通道”就默认按双流MIMO核查但错层覆盖的“双通道”是覆盖叠加关系不是空间复用关系。如果按双流参数去核查CSI-RS和PMI上报反而会把问题掩盖住以为配置没问题。常规核查汇总如下表核查项检查内容结果站点状态告警、驻波、光模块正常传输链路NG接口、S1接口状态正常覆盖设计双通道错层覆盖单通道逻辑小区配置频点、带宽、PCI、功率正常基线配置室分单通道基线未发现异常常规项全部通过说明问题不在射频、传输和基本小区参数。真正需要留意的是基线配置里的CSI部分。很多优化工程师查配置时只看PCI、频点、带宽、功率CSI-RS上报模式这种参数容易被跳过去。而QoS Flow建立阶段终端要按网络下发的测量配置完成CSI上报如果配置超出了终端能力重配流程就会中断。2.2 信令跟踪重配消息发出后没有Complete既然Counter原因值无法定位只能用信令跟踪。在网管侧对A小区做用户级信令跟踪抓取QoS Flow建立失败时间段内的RRC信令。多次跟踪结果非常一致基站下发RRC Connection Reconfiguration携带CSI-ReportConfig配置但一直等不到UE回RRC Connection Reconfiguration Complete。从消息里能看到两个关键信息CSI配置中的ROW1上报量是cri-RI-PMI-CQI。这里补一下背景。cri-RI-PMI-CQI这种上报模式UE要上报CRICSI-RS资源指示、RI秩指示、PMI预编码矩阵指示和CQI。PMI的物理意义是告诉基站“用哪个预编码向量或矩阵来发数据”这要求终端有多天线端口做预编码选择。如果UE只支持单天线传输1T或者小区当前就是单通道逻辑PMI反馈无从谈起UE就会卡在配置生效这一步。信令表现就是重配没有完成紧接着QoS Flow建立失败。我写了一段脚本从信令日志里批量提取这些字段方便看失败规律# 解析信令跟踪日志筛选CSI配置与重配完成情况 import re def scan_reconfig_log(log_path): # 匹配RRC重配消息中的CSI row和reportQuantity字段 pattern re.compile( rRRCConnectionReconfiguration.*? rrow[: ](\d).*? rreportQuantity[: ]([a-zA-Z\-]), re.S ) with open(log_path, r, encodingutf-8) as f: content f.read() for match in pattern.finditer(content): row match.group(1) report_qty match.group(2) # 如果上报量含PMI且后面没有Complete标注为可疑 suspicious PMI in report_qty.upper() and \ content.find(RRCConnectionReconfigurationComplete, match.end()) -1 if suspicious: print(frow{row}, reportQuantity{report_qty} - 重配未完成)这段脚本用正则从日志里抓row和reportQuantity再根据后面有没有Complete判断是否失败。实际网管导出的日志格式比这复杂正则表达式要根据厂商格式调整但筛选逻辑是一样的。A小区的失败记录里几乎所有可疑条目都是row1且reportQuantity带PMI这已经指向参数与终端能力的兼容问题。2.3 研发确认1T终端不适用PMI上报模式拿着信令截图和参数列表找研发确认结论很直接部分终端只支持1T传输不支持带PMI的上报模式。若小区配置cri-RI-PMI-CQI需要传输模式在2T及以上如果实测终端是1T应把上报量改为cri-RI-CQI这个模式支持1T。这也解释了为什么失败终端的UE能力几乎一致都是那类只支持单天线传输的终端。CSI上报模式是否包含PMI对传输模式的要求适用场景cri-RI-CQI否支持1T单通道室分、错层覆盖cri-RI-PMI-CQI是2T及以上双流MIMO、宏站多天线这个问题的官方Counter原因值之所以是“其它”是因为统计层面只知道建立失败不知道失败发生在重配阶段。5QI粒度没有细化到CSI上报这个环节必须靠信令把失败环节定位到RRC层才能对上参数问题。我见过有人把这种指标波动归到同频干扰加了一圈外部干扰排查反而耽误时间。关键判断点是RRC建立成功率、NG口信令成功率都正常只有QoS Flow建立失败说明UE已经完成初始接入倒在了业务承载建立阶段这个阶段最容易被忽略的就是CSI测量配置和UE能力的握手。3. 参数落地CSI-RS行数与上报量的具体操作3.1 关键参数表与修改逻辑确认根因后参数修改方案很清晰核心是把上报模式从cri-RI-PMI-CQI降级到cri-RI-CQI同时调整CSI-RS的行数配置。下表是本次实际修改的参数参数名按网管配置项展开参数名修改前修改后作用说明CQIMeasureCfg csiRsEnableTRUETRUE保持CSI-RS测量开启CQIMeasureCfg csiRow12CSI-RS资源映射行数适配单通道室分CQIMeasureCfg csirsPortAntMap全0映射全0映射单端口映射不变CQIMeasureCfg reportQuantitycriricqpmicriricqi上报量去掉PMI只保留CRIRICQIAprdPmiMeasureCfg csiRsEnableTRUEFALSE关闭PMI测量配置逐条解释。csiRow是CSI-RS的时频图案参数不同行号对应不同的资源映射密度。A小区原来是1改成2之后1T终端也能按这个pattern完成CSI-RS测量。reportQuantity是关键从criricqpmi改成criricqi后UE不再被要求反馈PMI1T终端就不会在重配阶段卡住。AprdPmiMeasureCfg的csiRsEnable改成FALSE是为了把PMI测量链路整个关掉避免基站侧继续按多端口方式调度。需要注意csirsPortAntMap这次没动仍然是全0映射因为室分单通道逻辑下CSI-RS端口就是单端口改成多端口反而和物理通道对不上。实际修改时要保证三个参数作为一个组合下发不能只改一个。比如只把reportQuantity改成criricqi但保留csiRow1部分终端仍然可能在CSI测量资源上拿不到稳定结果失败次数会下降但不彻底。3.2 用网管命令完成修改的示例现网调整走网管MML命令。不同设备商的命令字不一样但参数结构类似下面这个示例是我在项目里常用的写法# 修改CQI测量配置保持CSI-RS开启csiRow改为2上报量改为CRI-RI-CQI MOD NRCELLCQIMESCFG: NrCellId1, CsiRsEnableTRUE, CsiRow2, ReportQuantityCRI-RI-CQI; # 关闭PMI测量配置 MOD NRCELLPMIMEASCFG: NrCellId1, CsiRsEnableFALSE;第一条命令把CSI-RS行数和上报量一次改到位第二条命令关闭PMI测量。执行前先查询当前配置把修改前的参数值记录下来。命令执行后通常立即下发不需要重启小区重配置流程会在下一个接入请求时触发。设备商差异较大具体命令以现场网管手册为准但参数名和值的对应关系是一致的。我在执行时会额外做一步把修改前后的参数值截图存到工单附件里方便后续回溯。这类参数改动虽然可以热生效但如果改错终端侧行为会影响整个小区的用户体验所以操作前要把“当前值”和“目标值”写清楚再提交。3.3 参数生效后的验证思路参数修改后的验证不能等日报要在网管监控界面实时看Counter。A小区修改时间是5月11日当天失败次数从4275次降到1031次说明大部分1T终端已经能正常完成重配。当天QoS Flow建立成功率只回到96.92%还在缓慢恢复这是剩余终端和存量会话的滞后效应不是参数没有生效。如果改动后失败次数没有变化反过来检查三件事参数是否真的下发到了目标小区有没有被其他策略覆盖终端版本是否确认支持cri-RI-CQI上报以及旁边是否有同频干扰抬高了底噪。参数兼容问题修完后失败次数下降曲线是非常陡峭的如果依然是几百上千次往往还有第二层原因不要只盯一个参数。4. 指标恢复与全区核查从单小区整改到12个站点批量处理4.1 调整前后指标对比直接看A小区调整前后四天的指标变化能很直观地理解参数效果日期无线接通率(%)SA_RRC连接建立成功率(%)SA_QoSFlow建立成功率(%)NG口信令成功率(%)其它原因失败次数5月10日55.8899.5156.3299.714,2755月11日96.5199.6596.9299.921,0315月12日99.4699.5799.89100395月13日99.6299.7499.89100425月10日是问题基线QoS Flow建立成功率56.32%失败次数4275。5月11日改参数当天无线接通率回到96.51%QoSFlow建立成功率96.92%。5月12日、13日基本收敛到99.89%失败次数降到40次上下。这说明修改csiRow和reportQuantity后1T终端的重配流程被打通网络侧不再因为等不到PMI上报而超时释放。注意无线接通率和QoS Flow建立成功率是强关联的。无线接通率本身就是以QoS Flow建立成功为关键事件计算的指标所以QoS Flow恢复后接通率也被拉回到正常区间。之前看到55.88%实际上是QoS Flow失败拖累的结果不是随机接入出了问题。4.2 批量核查条件与SQL脚本A小区的问题解决了但要防的是全区存在同类配置。室分站点数量多一个个点开网管看不现实。我采用的办法是把全网站点配置导出到数据库用一条SQL把“单通道错层室分 csiRow1 reportQuantity含PMI”的小区筛出来-- 筛选疑似存在1T终端兼容问题的室分小区 SELECT s.site_name, c.cell_id, c.csi_row, c.report_quantity FROM site s JOIN cell_config c ON s.site_id c.site_id WHERE s.site_type 室分 AND s.cover_mode LIKE %错层% AND c.csi_row 1 AND UPPER(c.report_quantity) LIKE %PMI%;这里site_type限定室内分布cover_mode用错层匹配避免误伤双流区域。csi_row1加上report_quantity含PMI正好对应A小区的原始问题配置。筛选结果里再结合现网站点是否按单通道基线配置就能确定候选清单。筛选条件不要只用其中一个必须site_type和cover_mode同时过滤否则会捞出一堆宏站的小区人工复核工作量很大。配置导出这一步不同厂商的网管支持程度不同。能直接查数据库的走SQL不能走SQL的就把全网配置批量导出为XML再用脚本解析。SQL里的LIKE %PMI%不能漏掉大小写过滤我在条件里加了UPPER否则部分厂商配置里存的是小写会漏数据。4.3 整改结果与经验固化按这个逻辑核查全区共发现12个同类室分站点覆盖场景一致都是单通道错层覆盖且CSI配置含PMI。逐个做信令跟踪确认后按A小区的参数模板统一整改。整改完成后这12个站点的QoS Flow建立成功率和无线接通率全部恢复正常。这个数据说明室分建设期按“双通道”字面配置CSI参数的现象不是孤例错层覆盖下必须有明确的单通道参数基线。做完这一步我把核查逻辑和参数模板整理成了脚本和表格每次新建室分站开通前都比对一次确保建设期就把csiRow和上报量配成单通道版本。同时把这次处理的参数、信令特征、指标对比表一起归档到室分优化手册里作为后续同类问题的标准参考。5. 把问题变成手册QoS Flow建立成功率异常的快速判定技巧5.1 监控触发条件与预判在网管指标中心把QoS Flow建立成功率监控阈值设为98%。当指标低于阈值且失败Counter里“其它原因”占比超过80%时直接进入这类问题的排查路径。“其它原因”占比高是参数兼容问题的典型特征。如果失败原因分布在“无线层问题”、“传输问题”上则优先查覆盖和传输不要被这个案例带偏。5.2 现场三步验证法第一看配置检查csiRow是否为1、reportQuantity是否含PMI。第二看信令跟踪失败用户重点看RRC重配置消息的CSI字段以及是否收到RRC Connection Reconfiguration Complete。第三看终端能力统计失败UE的能力字段确认是否为1T终端。三步走完就能确定是否走本案例的整改方案。如果第三步统计出来的终端五花八门有1T也有2T那就要再排查其他因素不能一概而论。5.3 参数模板归档与配置源头控制把修改前后的参数表、信令特征、指标对比连同12个站点的整改记录一起固化到日常优化手册里。在网管配置模板里把室分单通道小区的csiRow默认值改为2、reportQuantity默认改为cri-RI-CQI新建站开通时直接套用从配置源头把这类失败挡在建设期。本文还有配套的精品资源点击获取