话统分析

话统分析
话统分析

在线模式(小区参数检查、话统分析及其他功能)

一、配置、话统数据导入:

使用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文件所在的目录。

在工作区中选择BSC,然后选择“BSC->Run Update Omc Data”,软件会执行配置参数导入操作。

6、话统数据导入配置:

选择“Tools->Options”,弹出Options对话框。

在“OMC Statistic Language Version”中,选择话统数据的语言版本,可以为中文或英文。

在“Data Cycle”输入框输入话统数据统计时间周期(min)。

在“Only import the same cycle data”复选框中,选择是否仅导入相同时间周期的数据。

在“Verify Statistic Data”复选框中,选择是否对话统数据正确性进行验证。

在“Don’t show time config and import all data”复选框中,选择是否在话统导入时默认导入所有数据。

在“Delete statistic data automatically”复选框中,选择是否自动删除话统数据。

在“Begin transaction at the day of every month”输入框中,输入每个月的第几天进行数据的转换。

在“Delete all special item month ago”输入框中,输入每几个月删除一次特性指标。

在“Delete all common item month ago”输入框中,输入每几个月删除一次公共指标。

单击“OK”,结束设置。

7、静态导入话统数据:

单击软件界面的“Static Statistic Data Path”输入框右边的“Browse”,弹出“浏览文件夹”对话框。

在“浏览文件夹”对话框中选择话统数据所在的目录。

话统数据导入操作。

执行过程中,系统会弹出“Tasks Information”对话框。

可以设置导入的话统的时间,设置完毕后,单击“OK”,软件开始导入话统数据。根据计算机的配置以及导入的数据量,导入过程可能会比较长。

8、关闭TransData:

右键单击任务栏中的TransData图标,选择“Quit”,弹出“QUIT”对话框。

单击“OK”,即可关闭TransData。

二、新建并打开项目:

插上硬件狗,启动GENEX Nastar GSM主程序,显示“用户登陆”对话框。

单击“设置”,弹出“项目设置”对话框。

单击“添加”,弹出“新建项目”对话框,输入新项目名称。

在“模式”中选择“在线”选项,设定本项目为在线模式的项目。然后在“数据库”输入框右边的按钮,弹出“本地网列表”对话框,选择本地网,单击“确定”。

在“地图文件”中可以导入GST格式的地图文件。单击“确定”后,回到“用户登陆”对话框。

单击“确定”,进入Nastar GSM主程序。

三、系统菜单:

1、工程参数导入:

同第四章工程参数导入部分的内容。

2、工程参数服务器备份:

用户可以将工程参数上传到服务器,也可以下载服务器已备份的工程参数,以实现工程参数的备份、共享。工程参数共享用于多个用户使用同一个服务器的情况下,如果一个用户更改了工程参数,并将修改后的工程参数上传到服务器,则另一个用户便可通过从服务器下载更新后的工程参数以达到同步的目的。

选择“工程参数服务器备份”,弹出“备份工程参数”对话框。

选中“上传”单选框,选择一个备份项,如果勾选“上传到最早一个”,则自动选择最早的备份。名称为“unused”的是未使用的备份。上传到已使用的备份会自动覆盖以前的备份。然后在“备份名称”文本框中输入备份名,单击“确定”,即可完成工程参数服务器备份。

选择“工程参数服务器备份”,弹出“备份工程参数”对话框。

选中“下载”单选框,选择一个已使用的备份项,单击“确定”,即可完成工程参数服务器下载。

3、资源统计:

利用资源统计功能,可以对全网范围内的各项资源(包括BSC、基站、小区、载频、信道、单板等)进行统计,以便让用户了解其配置情况。

选择“资源统计”,弹出“资源统计”对话框。

选择统计范围,可多选,然后选择统计对象,单击“确定”,即可完成相应的统计。

4、下载配置参数:

可以通过下载配置参数功能从服务器导入配置参数信息。

选择“下载配置参数”,下载完毕后,报告下载结果。

如果下载配置数据,将会按照配置数据对工程参数的映射来刷新工程参数,并以刷新后的工程参数为基准。如果没有下载配置数据,将直接以工程参数数据源为基准。下载配置数据后,Nastar GSM会自动更新本地工程参数。

5、数据备份:

备份本地数据库数据和SQL数据信息。

选择“数据备份”,弹出“浏览文件夹”对话框。

设置保存路径,单击“确定”,即可完成备份。6、数据还原:

还原本地数据库数据和SQL数据信息。

选择“数据还原”,弹出“浏览文件夹”对话框。

设置保存路径,单击“确定”,即可完成还原。

1、跳频检查报告:

选择“跳频检查报告”,弹出“跳频报告对象设置”。

可以单击“保存路径”右边的按钮,选择报告的保存路径,然后进行对象选择,最后单击“确定”,即可生成跳频检查报告结果。

1、日报:

选择“日报”,弹出“日报”对话框。

在“对象设置”页面中可以设置报告的保存路径、报告的对象以及报告的时间。

话统分析

在线模式(小区参数检查、话统分析及其他功能) 一、配置、话统数据导入: 使用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.覆盖差

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来看基站比较稀疏或有遮挡。

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

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掉线专题分析指导 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/0512134408.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,

掉话原因及处理

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)对于由于切换引起的掉话的解决,可先进行大范围的路测,通过路测可以确定是和哪个相邻小区切换不正常。对于一些与该小区有切换关系而拥塞率又较高的小区应作为测试的重点,并需要检查小区周围是否有盲区存在,如果是这种原因应及时修改相关频率并

高掉话小区处理流程

高掉话小区处理流程建议 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类掉话。

华为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

掉话优化思路

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级参数 设置错误引起的掉话主要有以下几种:

02 话统分析

目 录2-18A.2 中国联通质量考核指标........................................2-16 A.1 中国移动话统考核指标2002年...............................2-16 附录A ...........................................................2-142.4.6 切换成功率低的分析........................................2-12 2.4.5 SDCCH 拥塞率分析..........................................2-10 2.4.4 TCH 拥塞率的分析..........................................2-7 2.4.3 掉话率高的分析.............................................2-6 2.4.2 话统分析整体思路...........................................2-6 2.4.1 话统分析准备...............................................2-6 2.4 话统分析.......................................................2-4 2.3.2 运营商考核指标.............................................2-4 2.3.1 关键性能指标...............................................2-4 2.3 话统指标简介...................................................2-3 2.2.2 话务统计功能...............................................2-2 2.2.1 话务统计系统结构...........................................2-2 2.2 话务统计系统的结构和功能.........................................2-1 2.1 概述 ..........................................................2-1 第2章 话统分析........................................................

VOLTE参数分层指导书

VOLTE参数分层 指导书

VOLTE错误!未知的文档属性名称目录 目录 1概述 (3) 1.1背景 (3) 2QCI分层思路 (3) 2.1参数分层验证结果 (5) 2.1.1异系统参数分层验证结果 (5) 2.1.2系统内同频、异频参数分层验证结果 (6) 3QCI分层脚本 (11)

1 概述 1.1 背景 VOLTE开通后,为不影响数据业务,且可灵活调整VOLTE对应参数,提升VOLTE增益,现对VOLTE和数据业务参数进行分层,通过参数分层,实现针对不同业务、精细规划切换门限,可以实现数据业务和语音业务分离,数据业务尽可能驻留LTE网络,语音业务尽早切换保证用户感知。 2 QCI分层思路 1、异系统QCI1/5/9使用互不相同策略参数组 异系统采用QCI分层策略后,不同QCI使用不同的策略组,有如下好处: 1)、不修改非VOLTE用户现有的参数; 2)、QCI 1/5/9异系统完全分层。1/5/9分别使用不同的异系统参数组。 分层思路: 分层前: QCI 9 参数组:InterRatHoCommGroupId=0; QCI 1&QCI 5 参数组:InterRatHoCommGroupId=1; 分层后: QCI 9 参数组:InterRatHoCommGroupId=0; QCI 1参数组:InterRatHoCommGroupId=1; 新增QCI 5参数组:InterRatHoCommGroupId=2; 分层后QCI 1/5/9 可以分别设置各自的A1/A2门限;

2、QCI1同频、异频策略参数分层 切换会引起MOS分下降,通过调整VOLTE策略参数,尽量减少切换和切换的及时性,提升MOS,而不影响现网业务及其指标。QCI5和QCI9使用一样的即可,QCI5只用来传输SIP消息,保证传输可靠性就可以了。QCI1分层的目标是对语音业务做专门的设置,MOS值的优化。 分层思路: 分层前: QCI 1/5/9 参数组:IntraFreqHoGroupId=0;InterFreqHoGroupId=0; 分层后: QCI 1参数组:IntraFreqHoGroupId=1;InterFreqHoGroupId=1;

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 异常释放

相关文档
最新文档