SA常见KPI优化指导书-德赢Vwin官网网

1、KPI优化提升

KPI性能可以从“网络健康度优化”和“针对失败原因的KPI专项优化”两个方面进行提升。

1.1网络健康度优化提升

提高网络健康度（参数核查、告警处理、干扰消除）是提升网络KPI的基础，在保障网络健康度的前提下针对相应的KPI指标再做专项优化提升。

表 5-1 网络健康度提升Checklist

1.1.1NR PCI规划与核查

需要重点核查PCI冲突、PCI混淆、PCI复用距离。其中造成PCI冲突/混淆可以通过部署“PCI自优化”功能来进行问题小区识别

1.1.1.1PCI冲突

如果使用同一PCI的两个同频5G NR小区在地理位置上的隔离度过小，则UE在这两个小区的信号交叠区域不能正常实现信号同步、解码。如图1所示，小区A和B为NR小区且频率相同（F1），PCI相同，就出现了Cell A与Cell B的PCI冲突。

图 5-1 PCI冲突原理图

1.1.1.2PCI混淆

两个相同频点、相同PCI的小区虽然在覆盖上是隔离的，但却是同一个小区的邻区，如果SN Change/切换时UE上报了该混淆的PCI，就会导致UE在切换时发生混淆，服务小区无法确定UE的切换目标小区，从而导致切换失败而掉话。

PCI混淆主要发生在下面的场景：NR同频小区间的PCI混淆

图 5-2 NR同频小区间的PCI混淆

在这种场景下，小区A和C为NR小区且频率相同（F1），PCI相同，且都为NR小区B的邻区。因此，小区A和C对小区B造成了PCI混淆。

1.1.1.3PCI复用距离

相同PCI最小复用距离等参数设置，推荐配置如下：

1.1.2PRACH规划与核查

PRACH相关参数配置不合理会导致MSG1虚检、MSG1解析错误等问题，从而影响RRC链接建立成功率，PRACH相关参数需要核查以下两方面内容：

1、重点核查PRACH相关参数是否和《5G无线参数规划操作指导书》推荐参数配置是否一致，参数包括：非竞争的随机接入前导码、每个RACH Occasion的波束个数、msg1子载波间隔、竞争解决定时器时长、PRACH前导码个数、PRACH频域RACH Occasion个数、频域RACH Occasion的起始RB、PRACH功率攀升步长、基站期望的前导接收功率、前导最大发送次数、基于逻辑根序列的循环移位参数(Ncs)、PRACH时域资源配置索引、用于BFR的基于逻辑根序列的循环移位参数(Ncs)。

1.1.3覆盖优化

弱覆盖可以通过MR数据进行分析，弱覆盖站点可以通过调整天馈、降低发射功率进行优化调整。

超远覆盖可以通过MR数据、路测数据、KPI TA统计进行分析。UE从网络侧接收TA命令，调整上行PUCCH/PUSCH/SRS的发射时间，目的是为了消除UE之间不同的传输时延，使得不同UE的上行信号到达eNodeB的时间对齐，保证上行正交性，降低小区内干扰，30KHz子载波间隔1TA≈39m。超远覆盖站点可以通过调整天馈、降低发射功率进行优化调整。不同子载波间隔对应的TA距离参见下表：

1.1.4定时器核查

UE侧定时器为集团管控参数，有明确的其中：

1）T300、T301、T310、N310、T311、T319、T304设置越大，对指标改善越明显，建议全网核查：低于集团规范值的站点修改为集团规范值，高于集团规范值的站点为保持指标稳定暂时保留；

2）N311、UE不活动定时器设置越小，对指标改善越明显，建议全网核查：高于于集团规范值的站点修改为集团规范值，低于集团规范值的站点为保持指标稳定暂时保留

3）UE侧定时器定义详见附录

控制面定时器为厂家私有参数（非集团管控）：控制面定时器配置过小，可能会影响无线指标；配置过大，若出现异常，UE会一直占用基站资源，造成资源浪费。

1.1.55G内系统邻区核查

5G内系统邻区核查内容包括：外部小区参数配置一致性、邻区漏配、超远邻区核查，建议：

1）开启系统内ANR功能添加漏配邻区；

2）根据邻区对统计，对大于2Km且切换成功率为0的小区进行删除；

3）检查外部邻区参数（PCI、小区ID、TAC等）配置是否和小区实际配置一致

1.2、KPI分析及优化提升

1.2.1无线接通率优化提升

1.2.1.1参数优化

1.2.1.1.1PDCCH公共空间EPRE相对于小区RE参考功率的偏移

通过优化“PDCCH公共空间EPRE相对于小区RE参考功率的偏移”可以提升无线接通率。

负面影响：参数修改后，为保障PDCCH功率，PDCCH最大可用资源减少，当5G用户过多时，会造成PDCCH资源不足。

1.2.1.1.2MSG4不携带P0-PUSCH-AlphaSet问题优化

在V5.35.30 1230之前的版本中MSG4消息不携带P0-PUSCH-AlphaSet，RRC重配之前的上行调度按照协议是使用的Msg3/msg1的P0，会概率导致基站收不到UE的建立完成消息。并且经过对比HW和我司参数配置，当PL<130时，我司MSG5的发射功率低于HW区域，这种情况会影响RRC连接建立成功率和QoS Flow建立成功率。

最终解决方案：V5.35.30 1230版本，在MSG4下发功控dedicated。

临时解决方案：可以通过修改“MSG3相对于PRACH的功率配置”进行优化提升，待版本升级后再进行参数回退。

备注：该参数为集团规范参数，各地根据实际情况进行修改

MSG4不携带P0-PUSCH-AlphaSet问题说明详见附录

1.2.1.2RRC连接建立成功率

1.2.1.2.1RRC建立失败原因解析

RRC连接建立失败原因包括定时器超时、接纳失败、其它原因。

定时器超时

当gNB由于等待分接入类型的RRC连接建立完成消息(RRCSetupComplete)定时器超时后，计数器加1。

造成等待定时器超时的原因包括：功控参数设置不合理、RRU功率异常、弱覆盖、上行干扰、高CPU利用率。

接纳失败

当gNB接收到从UE来的分接入类型RRC连接建立请求(RRCSetupRequest)消息后，由于接纳失败导致RRC连接建立失败时，计数器加1。

造成接纳失败的原因包括：接纳参数设置不合理、小区负荷过高。

其他原因

当gNB接收到从UE来的分接入类型RRC连接建立请求(RRCSetupRequest)消息后，由于gNB内部原因（例如CPU冲高）失败导致RRC连接建立失败时，计数器加1。

造成该失败的主要原因可能是由于NR内部处理流程异常，需要通过分析失败信令进行问题定位。

1.2.1.2.2影响RRC连接建立成功率的因素

影响RRU接入的主要因素如下，可在优化RRC成功率时参考

基站故障；

PRACH参数配置，最小接入电平设置；

上行干扰NI太高；

弱场接入，RRC无法完成；

用户数多导致，SR容量不足；

CPU负荷高

1.2.1.2.3RRC连接建立成功率处理思路

1. 通过统计分析是否出现RRC接入成功率低的问题，当前RRC接通率指标要求为99%。

2. 确认是否全网指标恶化，如果是全网指标恶化，需要检查操作记录，告警，是否存在网络变动和升级行为。

3. 如果是部分站点指标恶化，拖累全网指标，需要寻找TOP站点。

4. 查询RRC连接建立最低的TOPN站点及时间段，细分失败原因值。

5. 查看TOPN站点告警，BBU状态，小区状态，OMMB操作日志，配置是否异常。

6. 针对TOP站点进行针对性的信令跟踪、干扰检测进行分析。

7. 将信令跟踪文件，干扰检测结果，操作日志交研发人员分析。

1.2.1.3QoS Flow建立成功率

1.2.1.3.1QoS Flow建立失败原因解析

QoS Flow建立失败原因包括消息参数错误、切换引起、空口失败、其它原因。

消息参数错误

gNodeB处理InitialContextSetupRequest、PDU SESSION RESOURCE SETUP REQUEST或PDU SESSION RESOURCE MODIFY RESPONSE过程中，校验消息中的参数，如果参数校验失败，则导致5QI Flow建立失败。

造成消息参数错误的原因可能是由于NR侧和核心网侧对消息中某些字段理解不一致导致，该问题的排查需要根据失败信令进行分析。

切换引起

当切换流程打断了PDU Session流程（PDU SESSION RESOURCE SETUP RESPONSE或PDU SESSION RESOURCE MODIFY RESPONSE）造成消息携带的QoS Flow Setup Request List中存在某些5QI的QoS Flow异常释放。

切换引起的Flow建立失败主要是流程冲突导致，该问题主要通过优化信令流程来进行规避。

空口失败

向AMF发送了INITIAL CONTEXT SETUP FAILURE、PDU Session Resource Failed to Setup Lis、INITIAL CONTEXT SETUP RESPONSE消息携带了一个或多个PDU session的QoS Flow Failed to Setup List、PDU SESSION RESOURCE SETUP RESPONSE携带了PDU Session Resource Failed to Setup List或PDU SESSION RESOURCE MODIFY RESPONSE携带了一个或多个PDU session的QoS Flow Failed to Add or Modify List，且失败原因为“空口失败”。

该问题主要适合基站故障、空口质量相关，需要重点排查：弱覆盖、重叠覆盖、过覆盖、上行干扰、基站告警、基站功率设置。

1.2.1.3.2影响QOS Flow建立成功率的因素

无线覆盖环境较差，如弱场覆盖，上行NI偏高；

无线参数设置错误，如加密完保算法不合理，接纳控制门限过低；

传输故障；

系统Bug；

1.2.1.3.3QoS Flow建立成功率处理思路

1. 通过统计分析是否出现ERAB接入成功率低的问题，目前ERAB接通率指标一般为99%。

2. 确认是否全网指标恶化，如果是全网指标恶化，需要检查操作，告警，是否存在网络操作和升级行为。

3. 如果是部分站点指标恶化，拖累全网指标，需要查找TOP站点。

4. 查询ERAB连接建立最低的TOPN站点及时间段，细分失败原因值。

5. 查看TOP站点告警，检查单板状态，小区状态，OMMB操作日志，配置是否异常。

6. 针对TOP站点进行针对性的信令跟踪、干扰检测进行分析。

7. 将信令跟踪文件，干扰检测结果，操作日志交研发人员分析

1.2.1.4无线接通率案例解析

1.2.1.4.1EPS Fallback测控参数漏配导致5QI[1]建立失败

问题现象：

某区域TOP站点3419530 5QI[1] QoS Flow建立成功次数为0，失败原因是radioNetwork = 34 : Ngap_CauseRadioNetwork_Root_not_supported_5QI_value。

问题分析

正常基于切换的EPS-Fallback，PDU session resource modify rsponse回复的消息应该是radioNetwork = 34 : Ngap_CauseRadioNetwork_Root_ims_voice_eps_ fallback_or_rat_fallback_triggered。

目前回复的原因值为34，不是正常基于切换的EPS Fallback信令流程，初步判断是由于EPS Fallback相关参数配置错误导致。

基于切换的EPS Fallback参数推荐配置如下表：

核查TOP站3419530的EutranFreqRelation、EutranFreq、FrequencyBandList配置均为空，基本可以判断是由于相关测量参数未配置导致。

问题解决

把测量相关参数配置添加完成后，QoS Flow建立成功率5QI[1]由0%恢复到100%。

附录:EPS FB实现方式

1.2.2无线掉线率

1.2.2.1定时器优化

UE在非语音业务时，UE状态识别为无线链路失败或拔卡后，延迟通知控制面释放该UE的时间。把该定时器由6s->10s后，可以减少“GNB由于RLF引发释放”原因造成的异常释放次数，从而改善无线掉线率。

1.2.2.2版本优化

在V5.35.30 1130之前的版本中，如果接入过程核心网在初始上下文建立请求消息中没有携带PduSessionResourceSetup IE，基站侧等核心网的pdu session 建立10s超时，会触发了上下文释放，释放原因为其它，该种情况主要是核心网或终端原因，和无线侧无关。

在V5.35.30 1130及之后的版本中，新增加了计数器“C600050034:Context释放次数，GNB由于等待核心网消息超时”，该计数器不再计为异常释放。

等待PDU Session超时问题说明文档，详见附录！

1.2.2.3异常释放原因解析

异常释放原因包括：GNB切换失败引发释放次数、GNB空口失败引发释放次数、由于小区关断或复位引发释放次数、GNB由于其它原因引发释放次数和GNB由于RLF引发释放。

GNB切换失败引发释放次数

当gNode由于切换失败发送UE CONTEXT RELEASE REQUEST消息时，计数器加1。

该问题通常是UE在切换执行阶段，由于目标侧发生RRC连接重建立或者RRC连接重配完成定时器超时等原因，触发UE释放。切换失败引发的释放通常是由于邻区配置、弱覆盖、上下行干扰导致，可通过跟踪信令排查切换前上报的MR信息来确认问题原因。

GNB空口失败引发释放次数

当gNodeB由于RRC重建立或者RRC重配过程中，等待RRC重建立完成或者RRC重配完成定时器超时，给AMF发送UE CONTEXT RELEASE REQUEST消息时，计数器加1。

该问题通常和干扰、弱覆盖、重叠覆盖、RRC重配消息中部分字段和UE理解不一致。

由于小区关断或复位引发释放次数

如下场景，每存在一个上下文释放，计数器+1：

1）当gNodeB接收到小区闭塞命令，或者小区配置信息删除，给AMF发送UE CONTEXT RELEASE REQUEST消息时；2）当gNodeB给AMF发送NG Reset消息时。该原因造成的异常释放和告警（闭塞告警、复位告警）相关，需要重点排查告警。

备注：V5.35.25 P61版本中存在NR切换到LTE后的正常释放会误统计为小区关断或复位引发的释放，该问题在V5.35.30版本已解决。

GNB由于RLF引发释放

当gNodeB由于无线链路检测失败，给AMF发送UE CONTEXT RELEASE REQUEST消息时，计数器加1。

gNodeB检测RLF包含以下三种场景：1）50次新传算一个窗，窗内harqfail比例>50%，统计为异常窗，连续10个异常窗；2）连续50次harqfail，即连续错包250个；3）连续4个检测窗的平均功率下降20db以上，其中8次SRS测量作为一个检测窗。

该问题触发的异常释放通常和弱覆盖、重叠覆盖、干扰相关。通过修改“非语音业务延迟释放定时器：6s->10s”，可改善该种原因造成的掉线。

GNB由于其它原因引发释放次数

当gNodeB由于除GNB切换失败、空口失败、用户无业务进IDLE、RLF外其它原因，给AMF发送UE CONTEXT RELEASE REQUEST消息时，计数器加1。该问题需要跟踪信令联合研发做进一步分析。

备注：在V5.35.30 1130之前的版本，接入过程核心网如果在初始上下文建立请求消息中没有携带PduSessionResourceSetup IE，基站侧会等核心网的pdu session 建立，如果10s内未收到pdu session 建立请求，会触发了上下文释放（释放原因：其它）。该种释放和无线无关，和终端和核心网处理相关，在V5.35.30 1130及之后的版本新增了计数器“C600050034:Context释放次数，GNB由于等待核心网消息超时”，该种原因不再计为异常释放。

1.2.2.4无线掉线率处理思路

1. 按照掉线率分子，提取细分原因的计数器，查看由那类计数器引起的失败次数最多，针对性处理。

2. 正常情况下，某个小区周边都存在邻区，如果无线环境不是很差，都可以通过切换的方式改变服务小区。当某个站点缺失邻区或者邻区添加不合理，会导致无法切换出而掉死。因此处理掉线率较高的小区时，需要核查邻区配置是否合理。

3. 核查小区是否存在超远覆盖，导致覆盖孤岛，无法切换到周边邻区。可以通过后台跟踪信令，观察测量报告，并补齐漏配的邻区。随后需要对覆盖进行控制。

4. 对于因弱覆盖导致掉线，若终端处于覆盖边缘，周围无可用的NR小区，可以添加系统间邻区，使用切换到4G的方式，减少掉线次数。但门限设置需要合理，不能太容易去到4G。

1.2.2.5无线掉线案例解析

1.2.2.5.1等待PDU Session超时导致异常释放

针对GNB由于其它原因引发释放，筛选TOP小区跟踪信令，结合信令和CPA打印，基本可以确认其它原因的上下文释放主要是由于接入过程核心网在初始上下文建立请求消息中没有携带PduSessionResourceSetup IE，导致基站侧等核心网的pdu session 建立10s超时，触发了上下文释放。

该种释放和无线无关，和终端和核心网处理相关，在V5.35.30 1130及之后的版本新增了计数器“C600050034:Context释放次数，GNB由于等待核心网消息超时”，该种原因不再计为异常释放。FOA 区域版本升级后，无线掉线率由0.11%下降到0.39%，其它原因引发的释放次数由1780次下降到338次。

1.2.3系统内切换成功率

1.2.3.1系统内切换失败原因解析

切换失败原因包括切换出准备失败和切换出执行失败，具体详见下表：

切换出准备失败，源侧发生重建立

在切换过程中，由于gNodeB在源小区或源gNodeB站内其他小区接收到UE的RRCReestablishmentRequest消息或者接收到其他gNodeB发送的XnRetrieveUe ContextRequest消息，造成切换准备失败。

切换出准备失败，源侧重建立通常是由于无线覆盖质差导致，需要重点核查干扰、弱覆盖、超远覆盖和重叠覆盖。

切换出准备失败，等待切换响应定时器超时

在切换过程中，由于源gNodeB等待HandoverRequestAck消息定时器超时，造成切换出准备失败。

切换出准备失败，等待切换响应定时器超时通常是由于TAC插花、外部邻区参数配置和小区实际配置不一致、XN或是NG链路故障。需要重点核查TAC插花、外部邻区参数配置、XN/NG链路是否丢包。

切换出准备失败次数，目标侧资源不足

在切换过程中由于目标侧资源准备不足，造成切换出准备失败。

切换出准备失败，目标侧资源不足通常和目标侧负荷（用户数、CPU利用率）、小区Cellbar、基站内部处理异常相关。该种原因如果目标侧RRC连接最大用户数<50、CPU利用率<60%且无Cellbar配置的情况下，建议提故障单转研发做进一步排查。

另外需关注：高铁站点在V5.35.30之前的版本如果开启周期性MR会导致切换过程中目标侧资源不足的情况发生，建议V5.35.30之前的版本不要开启周期性MR。

切换出准备失败次数，其它原因

除以上原因外，导致的切换出准备失败。

其它原因的准备失败，在核查完外部邻区参数配置，如果配置正确需要跟踪信令确定问题现象，上报第一响应组协助进行分析。

切换出执行失败次数，源侧发生重建立

在切换过程中，由于gNodeB在源小区或源gNodeB站内其他小区接收到UE的RRC ReestablishmentReques消息或者接收到其他gNodeB发送的XnRetrieveUeContext Request消息，造成切换出执行失败。

切换出执行失败次数，源侧发生重建立可能是由于切换CIO配置不合理（建议-3dB~3dB）、覆盖问题（弱覆盖、重叠覆盖、超远覆盖）、干扰、邻区漏配。TOP小区处理时建议根据信令判断发生切换失败发生时是否是在弱场、是否存在邻区漏配、测量参数是否不合理。

切换出执行失败次数，等待UE CONTEXT RELEASE消息超时

在切换过程中，由于源gNodeB等待目标侧小区的UE Context Release定时器超时，造成切换出执行失败。

切换出执行失败次数，其它原因

统计发生除以上原因以外导致从gNodeB切换出执行失败，需要跟踪信令确认问题现象再做针对性的分析优化。

1.2.3.2切换成功率低处理思路

切换过程中包含切换准备阶段，与切换执行阶段，2个阶段涉及到的因素各不一样，因此需要分开来处理。

切换准备失败，多由外部邻小区参数配置错误（邻区配置正确）或者切换准备目标基站故障引起。

切换执行失败，发生在切换命令下发后，终端执行时失败，与无线环境，邻区配置的合理性强相关。

对于整网切换成功率较低的网络，需要先分析切换准备与执行那个导致的失败次数较多，再按TOP小区针对分析处理。

切换准备失败处理

切换准备失败需要提取切换准备相关的计数器分解，查看具体的准备失败原因。切换准备失败主要关注邻区参数的正确性，具体包括：

1、切换准备失败需要定期核查现网邻区数据,保证数据的有效与准确；

2、现网中邻区参数配置错误的，如外部小区定义中与邻接基站定义不一致的；定期提取规划数据，进行核查；

3、现网中对异厂家站点邻区定义错误的，需定期索取异常家工参核查；

4、现网中邻区基站ID错误的，即不存在于异厂家网管，也不存在与中兴网管中的邻区关系。需要删除这类邻区数据；

5、定期核查现网中超远邻区关系，以2KM为界，对于超远邻区且切换成功率<50%的邻区对暂时删除。

切换出执行失败处理

切换执行阶段失败同样需要提取切换准备相关的计数器分解，查看具体的执行失败原因。

1、切换出执行失败次数>10次且切换成功率=0的小区对，建议删除同时开启系统内ANR功能对邻区进行重新添加；

2、切换出执行失败次数>10次且切换成功率<90%,首先核查切换目标小区是否与周边站点同频同PCI，如果存在同频同PCI小区，进行PCI重规划；

3、切换出执行次数>10次且切换成功率<90%，核查目标基站否存在上行干扰，如果存在上行干扰，即需要进行干扰排查。

1.2.3.3切换成失败案例解析

1.2.3.3.1NG AP未配置导致切换失败

11579866-311向11579911发起Handover Required消息，目标侧（11579911）未收到Handover Request消息，AMF直接回复Handover Preparation Failure消息（cause：ho_failure_in_target_5GC_ngran_node_or_target_system）导致NG切换准备失败。

核查目标侧11579911的接入信令，目标侧收到RRCSetupComplete消息后未发送Intial UE Messeage给AMF，说明该小区接入存在异常。

核查目标侧11579911 NG SCTP和NG AP配置：NG SCTP配置以及状态正常，NG AP未配置。添加NG AP配置后11579866-311向11579911切换恢复正常。

1.2.3.3.2源侧和目标侧AMF配置不一致导致切换失败

【问题现象】

XN口向目标站点发送切换请求，目标侧回复Xnap_CauseRadioNetworkLayer_Root_ invalid_ AMF_Set_ID原因的准备失败，随后向同一个目标站点再发NG口的切换请求，并收到Ngap_CauseRadioNetwork_Root_ho_failure_in_target_5GC_ ngran_node_or_ target_system原因的切换准备失败。

【原因分析】

针对这种准备失败的原因可能是目标侧与源侧配置的AMF不一致，一般外场都会有多套AMF，全网所有的站点都需要将每条AMF配置全备，不然会出现切换准备失败的问题。

1.2.3.3.3切片配置错误导致无法切换

【问题发现】

多维分析-控制面分析--N1N2接口分析巡检发现，较多次N2切换失败，原因为

slice-not-supported ，切片不支持，定界为无线

【原因分析】

通过下钻小区分析，有多个小区存在N2切出失败问题

以MSISDN 17598808267为例，经信令回溯分析，用户驻留小区LFSHQ1023利比玻璃-ZWH-2向基站gNB-ID为1069677发起切换，向AMF发起切换准备请求NGAP Handover Required，AMF回复切换失败消息，原因为切片不支持（slice-not-supported）。

cell_id为4381396994

协议分析，Slice(s) not supported为NG STEUP或者RAN CONFIGURATION UPDATE流程时，携带的切片AMF都不支持，可能是无线配置问题

网元名称:APP-HBBADheAMF001BZX-05AZX011
网元类型:AMF
网元ID:1090519041

节点IP:10.36.82.161&10.36.82.129&24095003:101

网元名称:APP-HBBADheSMF003BZX-05AZX012
网元类型:SMF
网元ID:1107296263
节点IP800b1705:301

【问题解决】

Slice(s) not supported为NG STEUP或者RAN CONFIGURATION UPDATE流程时，携带的切片AMF都不支持，可能是无线配置问题，查看小区LFSHQ1023利比玻璃-ZWH-2和基站gNB-ID为1069677其切片配置中tac与本小区tac配置不一致，修改后问题解决。

网管截图：