精品案例_SFN小区扇区级话统指标分析应用方案

SFN小区扇区级话统指标分析应用方案

SFN小区扇区级话统指标分析应用方案 (3)

一、研究背景 (3)

二、总体思路 (4)

2.1 扇区级指标订阅和查询 (5)

2.2 扇区级指标关联 (6)

2.3 扇区级指标分析 (7)

三、实施案例与成果 (8)

3.1 应用案例 (8)

四、经验总结 (11)

SFN小区扇区级话统指标分析应用方案

【摘要】通常多个RRU合并组成的小区，往往出现小区级指标正常但是无法察觉RRU是否异常。如有正常的上下行总流量和用户，但这并不能代小区中每个RRU都在正常工作,可能存在的RRU级别问题。本文介绍通过分析SFN小区的扇区级指标从而判断SFN小区RRU扇区问题，通过扇区级指标分析定位RRU故障、SFN解绑扩容、干扰排查的方法，指导室分等SFN 小区优化，提升室内深度覆盖助力VoLTE商用。

【关键字】SFN 扇区级指标RRU故障定位

【业务类别】优化方法、感知提升

一、研究背景

如下图所示，通常多个RRU合并组成的小区，常规小区级话统指标正常但无法察觉RRU 工作异常，如有正常的上下行总流量和用户，但这并不能代小区中每个RRU都在正常工作,可能存在的RRU级别问题：

1）RRU没有正确配置；

2）RRU没有按设计施工，覆盖区域无用户；

3）RRU存在隐性故障；

4）RRU之后连接的器件故障，如室分馈线，天线故障。

图1 SFN小区实例

华为设备支持把指标统计分析到扇区级别，通过扇区级别的指标分析，结合现场测试验证，可以进一步的把问题分析到RRU级别。华为支持扇区级别话统指标如下：

表1：华为支持的扇区级指标

二、总体思路

扇区级指标应用为SFN小区的优化提供一个新的思路，当发现小区指标异常时可以根据扇区级指标分析具体出现问题的RRU，快速定位小区问题。扇区级话统指标应用总体思路如下：

图2：扇区级指标分析思路

第一步-扇区级指标订阅：在U2000上订阅扇区级指标、采集小区级别工参数据、提取基站xml配置数据，获取扇区级别工参数据。

第二步-扇区级指标关联：扇区级别工参数据与扇区级话统数据进行匹配，获取具有携带RRUInfo的话统数据。

第三步-扇区级指标分析：结合携带RRUInfo的话统数据，排查扇区级指标是否存在异常，如扇区的RRC连接次数、用户数明显少于同一小区的其他扇区等。

第四步-问题分析和定位：后台核查如果存在故障告警、参数设置问题、性能指标问题，进行告警排查处理、参数校正等；通过扇区级别上下行所有用户平均个数、上下行PRB利用率指标进行筛选，识别高负荷、底负荷、高干扰等场景；

第五步-现场勘查和整改：针对高负荷场景，根据扇区级别指标和对应RRUInfo，现场确认覆盖情况、用户情况，重新输出小区划分方案；低负荷场景、现场确认用户情况、覆盖情况，输出相应整改方案。

2.1 扇区级指标订阅和查询

扇区级指标的订阅与其他指标的订阅方法相同，具体步骤如下：打开U2000，选择性能--->测量管理

图3：测量管理

在测量管理下，选择eNodeB功能下的算法相关的测量项（LTE），同时选择需要订阅的网元。

图4：测量项

在算法相关测量项（LTE）下选择一个测量项点击右键，选择快速设置。在快速设置中，勾选指标订阅的周期，选择需要订阅的网元，然后在功能子集中的算法相关的测量项（LTE）下勾选需要订阅的测量项（说明：小区扇区设备物理层测量（ChMeas.PHY.CellSectorEQUIP）在信道相关的测量项（LTE）下）

图5：订阅指标

点击确定后会弹出执行结果

图6：订阅成功返回结果

2.2 扇区级指标关联

扇区级指标的查询方法与其他指标的查询方法相同，具体步骤如下：选择性能--->结果查询。

图7：指标查询入口

新建查询，在新查询的对象设置中选择需要查询指标的网元，在指标设置中选择需要查询的具体指标，设置查询的周期，在时间设置中设置需要查询的时间段，点击查询或导出即可。

图8：指标查询设置

将查询到的扇区级指标与RRU工参进行关联获取扇区覆盖区域和安装位置以及归属的小区名称，通过小区名称关联小区级指标，从而就可以对小区及指标进行分析，判断小区级指标是否异常以及异常原因。

关联后指标如下表所示：

表2：扇区级指标关联

2.3 扇区级指标分析

结合携带RRUInfo的话统数据，排查扇区级指标是否存在异常，如扇区的RRC连接次数、用户数明显少于同一小区的其他扇区等，另外可以根据小区级指标异常情况定位具体异常的扇区，如下表中标黄的为问题扇区。

表3：识别出的问题扇区

三、实施案例与成果

3.1 应用案例

金宝汇广场为平层覆盖室分，共计4个RRU,SFN配置为1个小区：XY-FY-市区-金宝汇广场-HFTA-436965-5，长期为MR质差室分，3、4月份MR覆盖率一直在92%左右。

评估前指标情况：金宝汇广场室分小区KPI性能指标分析，数据业务无线接通率大于99%、切换成功率大于98%、无线掉线率低于0.1%，各项关键性能指标较好；小区业务量、RRC连接用户数、PRB利用率等指标正常；VOLTE业务无线接通率大于99%、VOLTE用户切换成功率100%各项指标均正常；小区级MR覆盖类指标统计，弱覆盖采样点比例8%左右，存在一定程度的弱覆盖，具体如下表示。

提取A小区扇区级话统数据，分析得知SectorID 16上行、下行所有用户平均个数均较低，可能存在覆盖问题，SectorID 18上行、下行平均用户数均较高。

通过RRUInfo在U2000查询到RRU资产编号（ESN）信息，通过ESN现场确认对应的RRU。

后台查询小区无告警、参数设置均正常；通过后台查询，确认小区每个Sector对应的RRU柜框槽号及RRU资产编号。该楼宇平层均已做覆盖，其中0-93-0的RRU覆盖公寓内电梯及5-14层平层部分。

根据ESN确认RRU，该小区问题扇区RRU安装在金宝汇广场10F配电间。对0-93-0 RRU 进行扇区级话统分析及覆盖验证，SectorID为18的扇区上行、下行所有用户平均个数均较高。测试A、B、C、D电梯均存在弱覆盖问题，5-10层平层未覆盖，平层及电梯周围占用室分泄露信号，RSRP达到-110dBm以下。

平层未覆盖，选测10F电梯周围RSRP-110dBm 以下平层未做覆盖，选测5F平层部分区域RSRP-110dBm以下

维护人员对问题区域室分馈线进行摸排，确认在RRU出口10米处，馈线被业主装修人为破坏，导致覆盖差：

评估覆盖较好扇区验证：对0-99-0进行后台扇区级话统分析及现场覆盖验证。后台分析SectorID为18的扇区上行、下行所有用户平均个数均较高，RRU覆盖1-4层南半部，现

场人员测试覆盖较好，室内平均RSRP在-82dbm左右

四、经验总结

采用验证扇区级话统指标评估方式，针对上下行平均用户数、上下行占用平均RPB个数较低小区，且后台分析不存在故障告警、参数设置等问题，现场可能存在较严重弱覆盖问题导致用户无法占用。经案例验证，现场测试验证结果与后台扇区级话统指标分析结果一致。扇区级话统数据结合xml解析工具，可以批量的进行扇区级别（RRU级别）的问题评估。

优点：通过扇区级话统指标评估结合xml解析工具、小区性能指标、故障告警、参数设置等分析，可以发现异常扇区，实现批量的、精准的、高效的扇区级别问题分析。

缺点：因缺乏扇区级性能指标，针对特殊场景适用性仍有欠缺，无法准确辨别“覆盖较好、用户量少”及“覆盖差、用户量大”场景问题。

应用价值：扇区级话统指标评估方法，针对以下场景的批量的扇区级别评估较具有应用价值。

1、长期上下行平均用户数、上下行占用平均RPB个数较低，该扇区室分系统存在故障，如RRU被天线封堵、信源未接入分布系统；

2、上下行平均用户数、上下行占用平均RPB个数较少，室分覆盖不合理，如部分室分系统支路未接入信源、元器件故障、天线点位分布不合理、天线过少等问题；

3、上下行平均用户数、上下行占用平均RPB个数较少过高，需评估容量是否均衡，考虑扇区、小区划分的合理性；

话统分析

在线模式（小区参数检查、话统分析及其他功能）一、配置、话统数据导入：使用TransData工具可以进行配置及话统数据的导入。操作前先插上硬件狗。 1、启动SQL Server：查看在任务栏中是否出现如下图所示的SQL Server图标。该图标说明SQL Server 启动成功并正常运行。如果任务栏中的图标是如下图所示的，则说明SQL Server服务没有启动。双击该图标，弹出SQL Server Service对话框。单击Start/Continue按钮，启动SQL Server服务。 2、启动TransData：启动Nastar GSM TransData，弹出Login对话框。

在对话框中输入服务器名为.\Genex，用户名为sa，密码为GENEX。如果勾选Delete&Clear Database，则Transdate会删除所有已有的本地网和BSC。需要完全新建Nastar数据库时，请勾上该复选框。单击“OK”，进入TransData程序。 3、创建本地网：

选择“Add Net”，弹出Add Network Information对话框。在Network Name中输入本地网名称，单击“确定”，完成本地网的创建。 4、创建BSC：选择“Add BSC”，弹出“BSC Property”对话框。

在BSC Name中输入BSC名称，在Version中选择BSC的版本号（娄底数据的BSC 版本号为G3BSC32V300R002C10。单击“确定”，完成BSC的创建。 5、导入BSC配置数据：单击软件界面的“OMC Config Data Path”输入框右边的“Browse”，弹出“浏览文件夹”对话框。在“浏览文件夹”对话框中选择配置参数的DBF文件所在的目录。

WCDMA掉话问题分析及处理方案

WCDMA掉话问题分析及处理方法作者：南京格安在国外，W CDMA已经在多个国家投入商用；在国内，WCDMA产品正逐步走向成熟，网络商用化的脚步正在加快。在网络建设及运营中，掉话率（calldroprate）是反映网络质量的重要指标之一；掉话问题也是日常网络优化面临的一个常见问题。本文从掉话的定义、掉话处理的基本流程、各种掉话数据分析方法、掉话问题的解决方法等方面加以研究，并结合实际掉话案例进行分析。一、掉话的定义 1.路测的掉话定义路测的掉话定义是：从UE侧记录的空口信令上看，在通话过程（连接状态下）中，如果空口的消息满足以下3个条件的任何一个就视为路测掉话。 (1)收到任何的广播信道消息。 (2)收到无线资源释放的消息且释放的原因为非正常的。 (3)收到呼叫控制断连接、呼叫控制释放等消息，而且释放的原因为非正常的。 2.话统指标中的掉话定义广义的掉话率应该包含CN和UTRAN的掉话率，由于网优重点关注与UTRAN侧的掉话率指标，本文掉话率描述也重点关注UTRAN侧的KPI指标。从大的方面讲，掉话分为两大类，信令面掉话和用户面掉话。需要说明的是：无线接入网话统掉话的定义只从Iu接口的角度进行统计，统计了RNC 主动发起的非正常资源释放的请求次数；路测的掉话定义主要从空口的消息和非接入层的消息结合原因值来进行定义的，两者不完全一致。比如说，对于同时进行主被叫通话，工具记录主叫的空口消息，如果被叫异常掉话，那么分析主叫的流程也会是一次掉话，但从话统上

看，这次主叫是没有掉话指标记录的。所以两者的定义是不完全一致的，在分析时需加以区分。二、掉话原因分析由于掉话分析将涉及到具体的信令分析，因此本文参考华为设备的参数设置进行分析，而不同设备的参数定义并不一定相同，但是分析方法是相通的。 1.邻区漏配一般来讲，掉话在初期优化过程中大多数是由于邻区漏配导致的。对于同频邻区，通常采用以下方法来确认是否为同频邻区漏配。方法一：观察掉话前UE记录的活动集EcIo信息和记录的BestServerEcIo信息。如果UE记录的EcIo很差，而记录的BestServer EcIo很好，同时检查记录Best Server EcIo 扰码是否出现在掉话前最近出现的同频测量控制的邻区列表中。如果同频测量控制的邻区列表中没有扰码，那么可以确认是邻区漏配。方法二：如果掉话后UE马上重新接入，UE重新接入的小区扰码和掉话时的扰码不一致，也可以怀疑是邻区漏配问题，可以通过测量控制，进一步进行确认（从掉话位置的消息开始往前找，找到最近一条同频测量控制消息，检查该测量控制消息的邻区列表）。方法三：有些UE会上报检测集（DetectedSet）信息，如果掉话发生前检测集信息中有相应的扰码信息，也可以确认是邻区漏配的问题。邻区漏配导致的掉话包括异频邻区漏配和异系统邻区漏配。异频邻区漏配的确认方法和同频几乎相同，主要是掉话发生的时候，手机没有测量或者上报异频邻区，而手机掉话后重新驻留到异频邻区上。异系统邻区漏配表现为手机在3G网络掉话，掉话后手机重新选网驻留到2G网络，从信号质量来看，2G网络的质量很好（在掉话点用2G测试手机观察RSSI信号）。 2.覆盖差

华为TOP小区处理阶段流程经验总结

TOP小区处理流程总结 1TOP小区处理流程及整体处理情况 1.1 TOP小区分解 TD-SCDMA网络系统重要的话统KPI包括CS/PS无线接通率、CS/PS无线掉线率、接力切换成功率、RNC间硬切换成功率、3G/2G互操作成功率等，针对这些KPI指标，可以通过分析、处理和解决影响这些指标的问题小区，提升和改善KPI指标。 1. 2 问题处理流程 TOP小区问题处理流程中，原因分析是流程中的关键点和重点。

2无线接通率TOP小区分析处理无线接通率＝RRC建立成功率*RAB建立成功率，接通率需要从RRC建立成功率和RAB建立成功率两块进行分析。RRC建立成功率与业务类型没有关系，RAB建立成功率则与业务类相关，需要分PS业务/CS业务进行分析。每次RRC和RAB建立失败，话统都会输出一个失败原因统计。 2.1RRC建立失败处理

2.1.1RRC建立失败原因 RRC建立失败的原因可以通过RRC原因统计的细化Counter进行确定。表3是RRC建立失败的对应原因打点。表4为RRC失败对应的原因分析。表3：RRC失败原因打点表4：RRC失败对应的原因分析

2.1.2RRC建立失败处理 1)拥塞在RRC建立出现拥塞时，可以进行下面的操作： ?将主要业务的RRC建立在公共信道上，修改命令行为： ?主叫流媒类体RRC建立在FACH上 SET RRCESTCAUSE: RRCCAUSE=ORIGSTREAMCALLEST, SIGCHTYPE=FACH； ?主叫交互类RRC建立在FACH上 SET RRCESTCAUSE: RRCCAUSE=ORIGINTERCALLEST, SIGCHTYPE=FACH； ?主叫背景类RRC建立在FACH上 SET RRCESTCAUSE: RRCCAUSE=ORIGBKGCALLEST, SIGCHTYPE=FACH； ?终止流媒体类RRC建立在FACH上 SET RRCESTCAUSE: RRCCAUSE=TERMSTREAMCALLEST, SIGCHTYPE=FACH； ?终止交互类RRC建立在FACH上 SET RRCESTCAUSE: RRCCAUSE=TERMINTERCALLEST, SIGCHTYPE=FACH； ?终止流媒体类RRC建立在FACH上 RCESTCAUSE: RRCCAUSE=TERMBKGCALLEST, SIGCHTYPE=FACH； ?去附着信令承载建立在FACH上 SET RRCESTCAUSE: RRCCAUSE=DETACHEST, SIGCHTYPE=FACH； ?注册登记承载在FACH上 SET RRCESTCAUSE: RRCCAUSE=REGISTEST, SIGCHTYPE=FACH； ?提高拥塞小区的最小接入电平，限制部分低电平用户的接入：修改命令：MOD CELLSELRESEL: QRXLEVMIN=-96； ?打开LDC开关； ?对于业务量持续较大的小区，可以考虑建议扩容。 2)RL建立失败

CDR 分析简介

CDR 分析简介 1、CDR(Call Detail Record)呼叫详细记录，用于记录一个呼叫的关键历史信息，包括该呼叫的终端特征信息、呼叫建立特征信息、Qos相关信息、呼叫过程行为信息、呼叫释放相关信息。我们通过CDR可以看出一次呼叫的位置、接入和释放时的无线环境质量、是否正常释放等信息，通过这些信息我们就可以分析出每一次呼叫释放的原因，能够发现网络中存在的一些问题。 CDR的分析一定要与话统分析和路测分析结合起来，才能够比较全面的分析出网路问题，为网络优化提供指导。 CDR功能必须要启动命令后才能对数据进行采集，系统默认情况下是关闭此功能的。打开命令：MOD CDRFILTER 查询命令：LST CDRFILTER 2、由于CDR的原始文件较大，包含的字段较多，1x有670多个字段，DO 连接级共有420多个字段，我们也不可能去对所有字段进行了解。 3、CDR数据的分析一般分为3种 a、单个IMSI的分析，一般针对于投诉处理 b、单个基站或单个载频的分析，一般针对TOPN处理 c、整个BSC或者全网的分析，一般针对大面积的网络优化 IMSI分析：一般对于一个用户的投诉我们首先要尽可能多的了解用户投诉的信息，一般要收集用户投诉的时间、地点、现象、主被叫号码等信息。我们可以利用收集到的这些信息来和CDR数据进行匹配，一般可以精确到是哪一条记录。匹配时要注意：如果用户投诉是掉话，我们不能只从释放原因值来看，由于掉话定时器的影响，可能在系统掉话之前用户就主动挂机了，这种是不会从释放原因值来反映出来的，但是一般掉话前反向FER都会很高，我们可以通过这一点来确定是否真正掉话。 ?我们遇到最多的投诉就是掉话，一般当我们可以从以下的角度来分析：?此条记录当时的无线环境，可以从EC/IO和FER来分析，来判断是否是由于无线环境差所造成掉话，但是这种无线环境差不一定是由弱覆盖造成，具体的原因还需要继续分析。 ?用户行为的分析，这一点也非常的关键，了解了该用户的移动方向对于具体原因的分析帮助很大。另外用户一般掉话后会再拨同一个号码，这样也可以推断是否真正掉话 ?单个载频的分析：对于单个载频的分析一般是针对掉话的TOP站来分析。?首先根据话统指标来筛选出TOP站点 ?根据CDR来筛选出掉话的记录 ?寻找的这些记录的规律，找出掉话原因 ?掉话原因常见有以下几种：弱覆盖引起掉话。这种掉话表现为：释放时激活集中分支EC/IO都很差，从mapinfo来看基站比较稀疏或有遮挡。

10-掉话类故障分析与处理

M900/M1800 基站子系统故障处理手册目录目录第10章掉话类故障分析与处理...........................................................................................10-1 10.1 概述...............................................................................................................................10-1 10.1.1 掉话问题描述......................................................................................................10-1 10.1.2 掉话的计算公式..................................................................................................10-3 10.2 导致掉话的几种因素......................................................................................................10-4 10.2.1 覆盖引起的掉话..................................................................................................10-4 10.2.2 切换引起的掉话..................................................................................................10-6 10.2.3 干扰引起的掉话..................................................................................................10-8 10.2.4 天馈引起的掉话................................................................................................10-10 10.2.5 传输引起的掉话................................................................................................10-11 10.2.6 无线参数设置不合理.........................................................................................10-11 10.2.7 其它原因引起的掉话.........................................................................................10-12 10.3 典型案例......................................................................................................................10-13 10.3.1 优化切换参数减少掉话.....................................................................................10-13 10.3.2 直放站干扰引起掉话.........................................................................................10-13 10.3.3 MAIO相同引起干扰掉话...................................................................................10-15 10.3.4 上下行不平衡....................................................................................................10-15 10.3.5 孤岛效应引起掉话.............................................................................................10-16 10.3.6 与版本相关的参数设置.....................................................................................10-17

LTE接入问题分析

1、无线接通率指标无线接通率=RRC连接建立成功率*E-RAB建立成功率=(RRC连接建立完成次数/RRC连接请求次数（不包括重发）)*E-RAB建立成功总次数/E-RAB建立尝试总次数*100% 、 RRC连接建立成功率 RRCSetupSuccessRate=（）/话统统计方法： RRC建立统计点【A点】（1）指标加1，不统计重发的次数。 Case1：eNB下发RRC_Conn_Setup消息后，在T300定时器超时前，收到相同的UeID发起的RRC_Conn_Req（Setup丢失，UE MAC冲突解决定时器超时后重发RRC_Conn_Req，UeID 不变），记为一次重发RRC_Conn_Req消息。 Case2：T300超时后，UE仍未收到RRC_Conn_Setup，UE重新搜网，发起初始接入，UeID 是取0~239的随机值或上层下发的TMSI。eNB侧记为新的一次初始接入，加1。 Case3：发起Attach后会启动T3410定时器。如果UE发出RRC_Conn_Setup_Cmp后，ENB 没有收到，UE会在定时器超时后重新发起Attach，ENB侧记为新的一次初始接入；RRC_Conn_Setup_Cmp丢失不会触发重建，发起重建的前提是安全已经激活。（2）如果RRC Connection Request消息信元Establishment Cause为“emergency”，指标加1。（3）如果RRC Connection Request消息信元Establishment Cause为“highPriorityAccess”，指标加1。（4）如果RRC Connection Request消息信元Establishment Cause为“mt-Access”，指标加1。（5）如果RRC Connection Request消息信元Establishment Cause为“mo-Singnalling”，指标加1。（6）如果RRC Connection Request消息信元Establishment Cause为“mo-Data”，指标加1。【B点】当eNodeB下小区接收到UE发送的RRC Connection Request消息并下发RRC Connection

掉话原因及处理

GSM网络优化中掉话、拥塞的原因及解决办法 1．掉话在移动通信中，掉话是指在分配了话音信道（TCH）后，由于某种原因，使呼叫丢失或中断，正常通话无法进行的现象。掉话不仅影响网络指标，而且会给用户造成许多不便，是用户投诉的热点。 1.1掉话产生的原因 1、由干扰引起的掉话：干扰主要包括同频、邻频及交调干扰。当手机在服务小区中收到很强的同频或邻频干扰信号时，会引起误码率恶化，使手机无法准确解调邻近小区的BSIC码或不能正确接收移动台测量报告。基站在通过SDCCH为手机分配好应使用的话音信道后,由于没有临近小区BSIC码而无法判断该使用哪个小区的话音信道，从而产生掉话。交调干扰主要来自于外部干扰，如CDMA站会对我基站上行频率产生干扰。 2、由于切换引起的掉话：（1） MS在通话中，手机列表中计算6个最好的相邻小区为切换做准备，但当网络覆盖不好时，会产生频繁切换，造成无主控小区，产生掉话。（2）一些小区由于话务忙，会把话务推给相邻小区，但当相邻小区信号不好或无空闲信道时就会产生掉话。（3）孤岛效应。如果服务小区A由于地形的原因产生的场强覆盖小岛C，而在小岛C周围又为小区B的覆盖范围，如在A的相邻小区列表中未添加小区B，那么当用户在C 中建立呼叫后一走出小岛C，由于无处可切换将产生掉话。 3、参数设置不合理引起的掉话：影响掉话的参数主要有切换参数和相邻小区参数。如：PMRG设置过高或相邻小区参数做错都会导致掉话。 4、基站硬件引起的掉话： BTS的硬件故障也会引起掉话，NOKIA设备中的7745（CHANNEL FAILURE RATE ABOVE DEFINED THRESHOLD）、7949 （DIFFERENCE IN RX LEVELS OF MAIN AND DIVERSITY ANTENNA / TRX）是特别要引起注意的，因为这些告警同时伴随着掉话。 5、Abis接口失败产生的掉话 Abis接口的，包括BSC未收到来自BTS的测量报告，超过TA极限，切换过程的一些信令失败以及一些内部原因，此外还有Abis接口的误码率的影响。 6、覆盖不好引起的掉话：有些小区由于覆盖范围过大造成在小区覆盖的边缘地带信号不好，电平值很低，手机列表中测量的相邻小区的电平值又达不到接入的要求（如RXLEV ACCESS MIN＝－95dBm）而引起掉话，在边远地区、网络覆盖不好的情况下经常会出现这种掉话。 1.2 掉话的解决办法如果一个小区掉话很高，可以先通过查掉话报告（如163报告），先确定是由于哪方面引起的掉话。（1）对于由于切换引起的掉话的解决，可先进行大范围的路测，通过路测可以确定是和哪个相邻小区切换不正常。对于一些与该小区有切换关系而拥塞率又较高的小区应作为测试的重点，并需要检查小区周围是否有盲区存在，如果是这种原因应及时修改相关频率并

lte掉线专题分析指导 v

东莞LTE掉线指标专题分析指导 1、概述本文主要结合东莞移动LTE现网无线掉线指标情况，根据现网数据统计分析，重点介绍了LTE系统内掉线率指标的优化思路、分析方法、定位手段及典型案例；影响掉线指标的原因主要包括：弱覆盖、干扰、故障及参数设置、异常TOP终端等。 2、无线掉线率定义及分析 2.1无线掉线指标定义无线掉线率= eNB异常请求释放上下文数/初始上下文建立成功次数*100%。（eNB请求释放上下文数=eNodeB发起的UE Context释放次数+eNodeB发起的S1 RESET 导致的UE Context释放次数

无线掉线率该指标指示了UE CONTEXT异常释放的比例。异常请求释放上下文数通过UE CONTEXT RELEASE REQUEST中包含异常原因的消息个数统计；初始上下文建立成功次数通过包含建立成功信息的Initial Context Setup Response 消息个数。如图1中A点所示，当eNodeB向MME发送UE CONTEXT RELEASE REQUEST 消息，会释放UE的所有E-RAB。当释放原因不为“Normal Release”，“Detach”，“User Inactivity”，“CS Fallback triggered”，“UE Not Available for PS Service”，“Inter-RAT Redirection” ，“Time Critical Handover”，“Handover Cancelled”时，测量指标L.UECNTX.AbnormRel加1 如图2中A点所示，当eNodeB向MME发送S1 RESET消息时，根据包含的上下文个数，指标L.UECNTX.Rel.S1Reset.eNodeB进行累加。

RRC重比率高问题分析和优化方法

RRC重建比率高问题分析和优化方法一、重建原理 1、重建概述 RRC重建（RRC connection re-establishment）是UE处于RRC_CONNECTED状态，因为一些移动性管理或底层链路故障，导致连接中断，UE发起的空口资源重新建立的过程，以继续空口的RRC连接。重建是UE在连接状态下，空口异常时重新恢复空口的过程。重建成功的前提是收到重建请求的小区有UE的上下文。重建的意义在于快速恢复空口业务，提高业务的连续性。重建成功流程： RRC重建请求消息:

RRC重建命令消息： RRC重建完成消息：

如果目标小区无该UE 的上下文信息，此时UE 的RRC 重建请求可能会被拒绝重建失败流程： 2、重建原因 2.1 重建条件 UE 在检测下行失步、切换失败、RLC 重传达到最大次数等原因条件下，会在新的小区发起RRC 重建过程，以试图快速重建业务，提升用户感受。LTE 协议规定，网络侧只能对存在上下文的连接接受重建请求，没有上下文ID 的请求将被拒绝而掉话。当UE 从基站 A 重建至基站 B 时，这种重建必然因获取不到上下文而失败。在现网中，无上下重建失败在重建失败总次数占绝大多数。严重影响了客户感受。上下文一般是eNodeB 侧存储的UE 的一些重要信息，包括UE 能力、多承载信息（承载

ID，QCI等级）、S1AP_ID、UE的安全性算法等。对于没有UE上下文的重建，目标基站必须通过某种手段获取源站的上下文，协议规定源站可以通过切换请求把UE的上下文带到目标站，因此获取上下文的载体是有了，但是如何通知源站把上下文通过切换请求带到目标站，协议中没有规定。因此只能通过私有消息方式通知源站，若私有消息走S1口，需要进核心网，核心网侧也需要识别该消息，处理上比较复杂，所以一般情况下会直接经过X2口处理该私有消息。目标基站收到RRC重建请求后，发现没有该UE的上下文，所以通过X2口发送一个私有消息给源侧基站请求源侧基站发送上下文，收到回复后，就按照正常的流程，继续完成RRC重建过程。 2.2引发重建的原因协议上规定，引发UE发起重建流程的原因主要有以下几点：

详细讲解WCDMA掉话问题分析及优化方法

WCDMA 掉话问题分析第一章掉话分类定义第一节正常释放流程一个CS正常释放信令流程 1.UE发RRC_UL_DIR_TRANSF消息给RNC，消息中nasmessage是0325，表示是call control 子层的disconnect消息。 2.RNC发RANAP_DIRECT_TRANSFER消息给CN，消息中naspdu是0325，表示是call control 子层的disconnect消息。 3. CN发RANAP_DIRECT_TRANSFER消息给RNC，消息中naspdu是832d，表示是call control 子层的release消息。 4.RNC发RRC_DL_DIRECT_TRANSF消息给UE，消息中nasmessage是832d，表示是call control子层的release消息。 5.UE发RRC_UL_DIR_TRANSF消息给RNC，消息中nasmessage是032a，表示是call control 子层的release complete消息。 6. RNC发RANAP_DIRECT_TRANSFER消息给CN，消息中naspdu是032a，表示是call control 子层的release complete消息。

https://www.360docs.net/doc/fd1296614.html,发RANAP_IU_RELEASE_COMMAND消息给RNC，开始释放Iu口资源，包括RANAP 层和ALCAP层资源。 8. RNC发RANAP_IU_RELEASE_COMPLETE消息给RNC。 9.RNC发RRC_RRC_CONN_REL消息给UE，开始释放RRC连接。 10. UE发RRC_RRC_CONN_REL_CMP消息给RNC。 11.RNC发NBAP_RL_DEL_REQ消息给NODEB，开始释放Iub口资源，包括NBAP层和ALCAP 层，PHY层资源。 12. NODEB发NBAP_RL_DEL_RSP消息给RNC，整个释放过程结束。一个PS正常释放信令流程 1.UE发RRC_UL_DIR_TRANSF消息给RNC，消息中nasmessage是0a46，表示是session management子层的deactivate PDP context request消息。 2.RNC发RANAP_DIRECT_TRANSFER消息给CN，消息中naspdu是0a46，表示是session management子层的deactivate PDP context request消息。 3. CN发RANAP_DIRECT_TRANSFER消息给RNC，消息中naspdu是8a47，表示是session management子层的deactivate PDP context accept消息。 4. CN发RANAP_RAB_ASSIGNMENT_REQ消息给RNC，消息中给出要释放的RAB list，其中包含了要释放的RAB ID。 5. RNC发RRC_DL_DIRECT_TRANSF消息给UE，消息中nasmessage是8a47，表示是session management子层的deactivate PDP context accept消息。 6. RNC发NBAP_RL_RECFG_PREP消息给NODEB。 7. NODEB发NBAP_RL_RECFG_READY消息给RNC， 8. RNC发RRC_RB_REL消息给UE，释放业务RB。 9. NODEB发NBAP_RL_RECFG_COMMIT消息给RNC，

高掉话小区处理流程

高掉话小区处理流程建议 1. 背景掉话率反映了系统话音业务的通讯保持能力，反映了系统的稳定性和可靠性，反映统计时间话音信道占用后因各种原因导致掉话严重程度，是无线通讯系统的重要性能指标，当系统的掉话率高时，会严重影响用户的感知，从而导致用户投诉或不满。此次我们主要针对TCH掉话的分析过程进行说明。在NOKIA设备中，掉话次数count主要统计的是掉话出现在哪个接口，如：无线口、A_BIS口，A 口等等，并没有按掉话原因类型进行分类，如：信号质量差掉话或TA掉话等等，因此，在NOKIA设备中，应该按照掉话出现的接口进行分析。 2. 3J掉话率公式 (sum(a.tch_radio_fail+a.tch_rf_old_ho+a.tch_abis_fail_call+a.tch_abis_fail_old +a.tch_a_if_fail_call+a.tch_a_if_fail_old+a.tch_tr_fail+a.tch_tr_fail_old +a.tch_lapd_fail+a.tch_bts_fail+a.tch_user_act+a.tch_bcsu_reset +a.tch_netw_act+a.tch_act_fail_call)-sum(b.tch_re_est_assign))/ (sum(a.tch_norm_seiz)+sum(c.msc_i_sdcch_tch+c.bsc_i_sdcch_tch+c.cell_sdcch_tch)-sum(a.tc h_succ_seiz_for_dir_acc)+sum(a.tch_seiz_due_sdcch_con) -sum(b.tch_re_est_assign))*100% Counters from tables: A = p_nbsc_traffic B = p_nbsc_service C = p_nbsc_ho 上表就是NOKIA设备中，分为在各个接口的14类掉话。

掉话优化思路

1 网优类 1.1 掉话类掉话排查总体思路流程图

1.1.1 CS掉话类问题处理流程现网的掉话监测分成RNC级的掉话与小区级的掉话两个方面，若出现网元大面积掉话，可能由RNC硬件故障引起。但还有一种情况是全网所有的RNC 掉话率都较高，此时可以考虑可能是由于CN的故障或是由其它系统原因造成，比如系统升级。

造成RNC掉话升级的原因可以有以下几种： 1. 参数配置错误：这有两个方面参数配置存在问题，一是RNC中的全局参数配置存在问题，另一方面是由CN中对RNC的参数配置存在问题。 2. RNC硬件故障问题：需要通过对RNC告警的检查以及对RNC日志的检查来确定是否是由硬件故障引起。小区级掉话率较高，造成小区掉话的原因较多，主要有以下几种： 1. 干扰造成的掉话：（同频干扰、相关性较强的扰码引起的干扰、导频污染、上下行交叉时隙干扰、上下行导频间干扰、系统间干扰、其它无线设置的干扰） 2. 切换造成的掉话：（硬件故障导致切换异常、同频同扰码小区越区覆盖导致切换异常、越区孤岛切换问题、目标小区上行同步失败导致切换失败、无线参数设置不合理导致切换不及时） 3. 基站硬件故障造成的掉话 4. 终端问题造成的掉话 5. 链路失衡造成的掉话 6. 参数配置错误造成的掉话覆盖问题造成的掉话（覆盖空洞造成的掉话、越区覆盖造成的掉话、孤岛效应导致的掉话、导频杂乱导致的掉话、阴影衰落导致的掉话） 1.1.1.1 RNC级问题处理思路 1. 确定问题小区的分布情况（比如是否集中在同一框的某一单板上）。 2. 出现RNC级掉话后，首先需确定该RNC级的掉话是由多个小区引起的，还是由个别高掉话的小区所导致。如果是由个别小区引起的，应进行小区级的掉话处理步骤，否则进入网元级的掉话处理过程。 3. 检查RNC的系统告警，检查是否存在相关硬件的告警信息，如果存在单板的告警，则需要进行排除。 4. 检查RNC的系统日志，对其中不正常部分进行检查。 5. 检查CT数据中掉话部分的信令，分析其错误代码，常见的RNC级参数设置错误引起的掉话主要有以下几种：

VoLTE高掉话小区处理流程

VOLTE高掉话处理流程 1. 基站告警-主要指小区存在明显的站点告警，主要影响业务告警，包含硬件、停电、断站，射频单元驻波，IPPATH，S1故障等告警； 2. 隐形故障-主要指对问题点进行后台排查后，未发现明显故障，需上站检查相关硬件，计为隐性故障； 3. 传输故障-主要指小区存在传输链路断链，误码率过高,传输数据配置异常等问题； 4. 参数问题-主要指小区存在参数设置不合理、设置错误，参数漏配等； 5. 覆盖问题-主要指小区存在弱覆盖、覆盖过远或覆盖不合理等因素； 6. 内部干扰-主要指小区存在时隙配比不一致（要求同频点站点时隙配比一致）、GPS失锁、模三干扰、超远干扰； 7. 外部干扰-主要指小区存在阻塞干扰、杂散干扰、互调干扰、及其他外部干扰； 8. 邻区问题-新开站点邻区关系不全，不合理或未加任何邻区，影响UE小区选择或重选至不合理小区，从而影响掉线率。 9. 拥塞问题-主要指小区存在明显的资源不足，用户过多导致。 10. 核心网问题-主要指核心网数据定义不全、定义错误或网元合理化调整、功能验证等，导致指标恶化，计为核心网问题； 11. 终端问题-主要指对问题点通过后台排查和现场测试，排除为所有可能无线侧因素，结

合相关信令，确认为个别用户终端问题； 12. 突发异常-主要指某项指标在1-2个时段突然出现恶化，然后自行恢复正常，再排查完各种可能性原因后，未发现任何异常，计为突发异常。 2、E-RAB 掉线率(QCI=1/2)-高掉话TOP 小区分析流程 2、E-RAB掉线率(QCI=1/2)-高掉话TOP小区分析流程 1.查询掉线类定时器设置是否正确；（T310、N311、N310、T311、T301） 2.如掉线率突增，查询操作日志，确认是否有修改，导致小区异常； 1. 检查小区时隙配比是否设置准确（DE:SA2\SSP7;F:SA2\SSP5）； 2.如每PRB 上干扰噪声平均值>-110dBm,确认小区存在上行干扰，同时可通过后台跟踪，确认干扰类型 1.通过观察小区上下行丢包率是否正常，如丢包率偏高，基本断定小区存在质差； 2. 通过后台QCI=1/2误码率跟踪，如BLER>1%，确定小区存在高误码； 1.检查传输模式，是否为TM3，如长时间为TM2，确认设置正确的情况下，基本确定小区存在弱覆盖； 2.对比64QAM 和QPSK 占比，如后者比例远大于前者,可确定小区覆盖异常； 1.安排前场人员现场测试，同时后台通过信令跟踪，配合查找问题原因； 2.如果确认问题后，转发相关人员处理，做好跟踪工作，直至问题闭环； 1.确定目标小区运行情况，是否基站故障或异常告警； 2. 检查邻区间参数设置是否正确； 3.通过Mapinfo 检查小区邻区配置是否合理，进行邻区合理性优化； 4.检查基站是否周边站点缺少，如为孤站，可视为正常； 1.通过LST ALMAF 查询站点实时告警,参考历史告警； 2.通过DSP BRD 查询单板运行情况；是否存在弱覆盖 E-RAB 掉线率(QCI=1/2)高掉话TOP 小区服务小区是否存在异常告警或传输闪断，周边300米站点是否存在断站及告警SRB 达到最大重传次数导致的激活的语音业务E-RAB 异常释放次数切换流程失败导致的激活的语音业务E-RAB 异常释放 eNodeB 发起的原因为无线层问题的UE Context 释放次数上行弱覆盖导致的激活的语音业务E-RAB 异常释放通过提取两两小区切换，确定目标小区参数是否设置合理是否存在高干扰是否存在高质差现场测试及后台跟踪 UE Reply 超时导致的激活的语音业务E-RAB 异常释放

华为OMC话统分析流程

华为OMC分析流程华为技术服务有限公司 2020年5月26日

目录一、OMCR分析总体流程图 (3) 二、网络评估和检查 (4) 1、网络评估流程图 (4) 2、网络结构分析 (5) 3、网络性能评估 (5) 4、告警检查及硬件排障处理 (6) 5、网络参数检查 (8) 6、邻区检查 (8) 三、发现网络问题 (8) 四、分析和解决问题 (9) 1、分析和解决问题的流程 (9) 2、掉话问题分析流程 (10) 3、切换问题的分析流程 (14) 4、TCH 拥塞的分析流程： (16) 5、SDCCH拥塞分析流程 (19) 6、接入类问题分析流程 (20) 五、附件：............................................... 错误!未定义书签。

一、OMCR分析总体流程图图1 OMCR总体流程图

二、网络评估和检查 1、网络评估流程图图2 网络评估流程图

2、网络结构分析采集本业务区和相邻业务区的相关信息表，包括BSC号、LAC 号、基站号、Cell_id、载频数、硬件配置、经纬度等相关信息；同时将这些信息集中在一个数据库文档中。这份数据库文档为后续性能指标分析、最差小区分析等工作提供分析依据和数据。采集本业务区和相邻业务区的行政电子地图；同时依据数据库文档中的基站信息表，制作相应的Mapinfo图层，例如：按归属业务区、归属MSC、归属LAC，制作对应的专题图层，按本业务区及相邻业务区基站的分布及MSC间切换区域、BSC区域、LAC区的划分等等。 MSC、BSC、LAC区的容量分布尽量做到均匀, 结构简单, 清晰。基站分布尽量呈网格结构, BSC, MSC、LAC区边界尽量避开话务密集区或重要的地区。 3、网络性能评估整个OMC的分析思路是：从面到点的进行问题定位和分析。在了解一个网络的网络质量时我们一般都先通过话统来了解其网络运行情况，先对BSC整体性能/C1报表这个统计功能子项进行研究和对比分析，如果在BSC整体性能/C1报表统计中发现某个重要指标（如掉话率、切换成功率）有异常情况时，我们再对其相应更详细的内容具体分析。分析网络性能的时候不能只看某一天和某一段时间的话统数据，这样分析比较片面。而应该分析一段时间内的话统指标。一般我们取一周的忙时话统数据平均值来把握网络的性能，同时观察在话务量基本稳定的情况下，有无明显的指标波动情况存在。 ●系统性 →自上而下，从整体到局部 ●整体性 →查看一周以上的指标变化趋势和每天的变化趋势 ●相关性 →各种话务统计指标之间的联系指标名称和评估标准：如切换成功率、掉话率、拥塞率、无线接通率等指标。表1 KPI指标

LTE网络接通率分析思路

TD-LTE网络接通率分析思路接通率优化的思路遵循以下方式： 1. 通过话统分析是否出现接入成功率低的问题，根据局方对接入成功率指标的要求启动问题定位或专题优化。 2. 通过对话统的原始数据进行分析，查出问题出现最多的TOP站点和TOP 时间段。 3. 针对TOP站点进行针对性的网管信令跟踪，LMT跟踪，告警检查等。 4. 如果网管信令和LMT跟踪仍然无法定位问题，针对性的进行路测复现问题，采集前后台log,请相关开发人员协助定位。当获取接入问题的TOP小区和TOP时段后，通过网管信令跟踪，LMT跟踪，告警检查等方法首先排查是否设备异常、组网配置问题： 1. 排查小区状态。 -检查各单板状态、RRU是否正常，小区状态是否为可用； -查看小区是否存在告警，进行告警分析；手动恢复告警后查看告警是否存在；上报问题； 2. 排查UE、小区、核心网组网配置、对接参数是否正常(常见于实验网阶段)。 -检查UE的频点配置是否与eNB一致，检查UE的PLMN与eNB 配置的PLMN是否一致，如果频点、PLMN配置不正确，UE进行小区搜索失败。 -检查核心网是否有开户信息。测试的IMSI没开户，表现为用户完成随机接入，上行直传消息后核心网立即回 “S1AP_DL_CONTEXT_REL_CMD”，释放UE。 -检查SCTP链路状态是否OK，如果异常，需要检查ENODB与 MME连接的网线是否插好，端口是否与配置的SCTP端口号一致，是否与MME正常通信；检查S1接口状态是否正常，S1接口是否处于闭塞状态，寻求设备侧同事的帮助和研发指导。 -检查安全模式配置。UE和核心网需要共同开启或关闭鉴权，并且按照运营商提供的“LTE USIM卡参数建议”配置C值和R值。eNB

GSM坏小区处理流程

亳州GSM坏小区处理流程 1. 指标问题区分优先级别排查 1.1 指标监控一般分类由于正常指标监控时间有限，需要利用有限的时间解决对网络质量影响程度更严重的、范围更广泛的指标问题，因此要将指标问题区分优先级别排查。 1）观察Net Indicator指标：按指标重要性排序，分别为TCH、SD话务量增长情况、话务掉话比、TCH掉话率、TCH信道可用总数、TCH拥塞率（不含切换）、TCH分配失败率、SD拥塞率、切换成功率、TCH拥塞率（含切换）等指标，与近期相同时段相比，把握网络级指标变化情况。监控的宗旨是：网络级容量指标稳中有升；网络级质量相对稳定指标稳定； 2）观察BSC Indicator指标：观察指标及观察方法具体如Net Indicator。监控的宗旨是，在Net Indicator指标变化的前提下，将指标变化范围定位到BSC级别。网络容量指标如果发现为大多数BSC都增加的情况，那么多数都为节假日等公众行为所致，这类情况一般都能事前预测；如为部分BSC增加的情况，需要再进行Cell级别定位。网络质量指标如果发现为大多数BSC都有恶化情况，多数情况为凌晨有网络级工程所致，例如核心网升版、核心网割接等工程，需要立即联系该工程所涉及硬件工程师；如为部分BSC恶化的情况，可以通过工程数据核查是否问题BSC属于某个或者某些特定的MSC，并了解交换侧工程情况，给予定位；如为个别BSC恶化的情况，需要再进行Cell级别定位。 3）观察Cell Indicator指标：观察指标及观察方法具体如Net Indicator，监控的宗旨是，在BSC Indicator指标变化的前提下，将指标变化范围定位到Cell级别。但还需重点观察各小区TCH话务量、MC01/MC02比值及切换请求总次数等，这些指标可以发现是否有基站退服、吊死等故障情况。网络容量指标通过涉及小区的数量及具体地理分布可以将变化情况定位到具体区域，多数原因可能是由于组织区域性活动等所致，这类问题需要局方尽量提前了解活动信息，优化工程师就活动信息提前调整网络配置或采用应急措施（例如：降低半速率占用门限、开启DR功能等）。网络质量指标通过问题BSC下涉及小区数量可以将问题定位至BSC级问题还是