CS掉话问题分析总结

合集下载

龙岩移动CS+PS并发业务信道迁移失步问题

龙岩移动CS+PS并发业务信道迁移失步问题

龙岩移动CS+PS并发信道迁移失步掉话一.问题描述:据客户投诉,新罗移动大楼经常出现通话质量差,断续,甚至掉话问题,CDT分析发现问题都是在CS+PS并发业务期间,掉话原因为Ue_RabOperTimeout。

5月9日、10日安排人员现场复习测试,共复现问题12次,现针对复现出现掉话异常事件进行分析。

二.问题分析:2.1 KPI指标分析统计近2周全网Ue_RabOperTimeout掉话原因值,各个RNC平均次数如下:其中投诉站点新罗移动大楼归属RNC1888Ue_RabOperTimeout掉话次数最多,为32次,统计该小区平均每天该原因值掉话次数高达14次。

由此可见,整个RNC平均每天该原因值掉话次数虽然不多,但是新罗移动大楼高端客户多,出现问题频次高。

2.2 异常信令分析针对本次复现的问题进行分析,测试期间先发起语音业务,期间反复上网,具体事件流程如下:17:07:18.545时刻发起CS业务RB建立,此时业务建立在R4载频10071:17:07:38.412时刻发起PS业务RAB建立,此时业务迁移至HS载波1005517:07:59.342第一次DCH转IDLE,PS域RBRelease正常:又经历12次发起PS业务请求,DCH转IDLE导致PS业务释放,均正常,第13次发起的PS 业务RB释放超时导致CS业务掉话:17:08:22.442再次发起PS业务RAB建立,RB建立在10055HS载波,于17:08:43.382时刻DCH转IDLE Iureleaserequest释放,RB正常释放;17:08:55.502再次发起PS业务RAB建立,RB建立在10080HS载波,于17:09:16.422时刻DCH转IDLE Iureleaserequest释放,RB正常释放;17:09:22.892再次发起PS业务RAB建立,RB建立在10080HS载波,于17:09:44.342时刻DCH转IDLE Iureleaserequest释放,RB正常释放;17:09:49.722再次发起PS业务RAB建立,RB建立在10088HS载波,于17:10:10.622时刻DCH转IDLE Iureleaserequest释放,RB正常释放;17:10:57.532再次发起PS业务RAB建立,RB建立在10096HS载波,于17:11:18.682时刻DCH转IDLE Iureleaserequest释放,RB正常释放;17:11:48.392再次发起PS业务RAB建立,RB建立在10096HS载波,于17:12:14.482时刻DCH转IDLE Iureleaserequest释放,RB正常释放;17:12:30.538再次发起PS业务RAB建立,RB建立在10080HS载波,于17:12:51.418时刻DCH转IDLE Iureleaserequest释放,RB正常释放;17:12:58.688再次发起PS业务RAB建立,RB建立在10088HS载波,于17:13:19.618时刻DCH转IDLE Iureleaserequest释放,RB正常释放;17:13:28.568再次发起PS业务RAB建立,RB建立在10096HS载波,于17:13:49.498时刻DCH转IDLE Iureleaserequest释放,RB正常释放;17:13:56.608再次发起PS业务RAB建立,RB建立在10096HS载波,于17:14:22.738时刻DCH转IDLE Iureleaserequest释放,RB正常释放;17:14:27.428再次发起PS业务RAB建立,RB建立在10096HS载波,于17:14:53.448时刻DCH转IDLE Iureleaserequest释放,RB正常释放;17:15:00.628再次发起PS业务RAB建立,RB建立在10088HS载波,于17:15:21.768时刻DCH转IDLE Iureleaserequest释放,RB正常释放;第13次,17:15:27.358再次发起PS业务RAB建立,RB建立在10088HS载波,于17:15:48.2888时刻DCH转IDLE Iureleaserequest释放,但此时RBrelease超时,CS业务掉话:掉话后出现小区更新,原因为radiolinkfailure:并发业务会伴随信道迁移,发起PS业务后,CS业务从R4信道迁移至HS信道,PS业务释放后,CS业务随着PS的RBrelease迁移回R4信道。

Counter分析和处理

Counter分析和处理

Counter分析和处理异常事件原因分析1.CS掉话原因分析vs.iureleasereqcs.oamintervention原因解释和建议:OAM干扰。

当网络资源或接口被锁定,导致掉话时,建议检查OAM资源和接口是否被锁定。

vs.iureleasereqcs.unspecifiedfailure原因解释和建议:未定义的故障、无线承载重新配置期间的故障(RBR重新配置等),或产品内部问题导致的错误。

建议检查信令流程、Rb配置和UE端配置问题的正确性,或跟踪产品内部跟踪进行进一步分析。

vs.iureleasereqcs.repeatedintegritycheckfailure原因解释和建议:完整性保护检查错误:当安全模式下的完整性保护被激活时,出现完整性检查错误,导致后续RRC报文解码失败;建议检查RNC和CN的数据参数配置,并在问题区域进行拨号验证测试,以正确配置参数。

vs.iureleasereqcs.uegeneratedsignallingconnectionrelease原因解释和建议:在建立认证的过程中设置RNC和RNC的认证参数的原因是CSC RRC发送到网络的认证消息失败。

vs.iureleasereqcs.radioconnectionwithuelost原因解释和建议:UE的无线链路丢失。

在UE和RNC之间建立无线链路。

由于上行链路失步,NodeB向RNC发送上行链路无线链路故障指示。

建议检查无线环境,尤其是上行索引。

vs.iureleasereqcs.abnormalconditiontimerrelocexpiry原因解释和建议:对于原因值为trelocoveralexpiry的异常,由于硬切换期间MSc计时器超时,硬切换失败。

建议调整MSc定时器的持续时间。

vs.iureleasereqcs.othercause原因解释和建议:由于其他未定义的原因,建议跟踪过程分析。

vs.iureleasereqcs.dlrlcerrsrb原因解释和建议:SRB上的下行链路RLC错误。

掉话及呼叫失败分析

掉话及呼叫失败分析

1掉话问题1.1 掉话分析方法1.1.1话统分析:分析话统指标时,要先看BSC整体性能测量指标,掌握了网络运行的整体情况后,再有针对性地分析扇区载频性能统计。

分析时一般采取过滤法,先找出指标明显异常的小区分析,此时很可能是版本、硬件、传输、天馈(含GPS)或者数据出了问题导致的异常,可以结合告警首先从这几个方面检查。

如无明显异常,根据指标将各扇区载频进行统计分类,可整理出各重点指标较差小区列表,以便分类分析。

看指标时,不能只关注指标的绝对数值是高是低,关心的应该是指标的相对高低情况。

只有在统计量较大时,指标数值才具有指导意义。

1.1.2CDT数据分析及呼叫跟踪分析CDT(Call Detail Trace/呼叫详细跟踪)记录了一次呼叫过程中的基本信息(如:主叫、被叫号码、初始接入的小区、扇区、呼叫业务项、持续时长、引起呼叫释放的内部原因值等)和掉话发生时移动台所处的无线环境信息(如:掉话前激活集各个分支的小区号、扇区号、PN码、掉话前前向业务信道功率、掉话前反向EbNt等),我们可以利用这些信息对掉话进行分析。

CDT可以粗略分析到扇区级的呼叫信息如:接入小区、扇区,释放的内部原因,掉话时的分支信息;自动跟踪功能可以让路上行人作为路测对象,关注其详细流程;手动跟踪功能可以使网优人员有目的的定点路测,关注其详细流程。

1.1.3路测路测是了解网络质量、发现网络问题较为直接、准确的方法。

路测在掌握无线网络覆盖框架方面,具有话统等其它方法不可替代的特点。

包括了解是否有过覆盖、覆盖空洞,是否有上下行不平衡,是否有天馈装反,导致PN信号出现在不该出现的地方,等等。

特别在进行了参数调整或做了覆盖方面的调整后,如天馈调整、或功率配比等参数调整后,都需要路测了解这些调整是否达到了预期效果。

路测可以解决细节问题,但也有一定局限。

路测路线有限,时间有限,不可能得到网络完全数据,例如要想通过路测来找到掉话从而分析掉话原因是十分困难的,因为假定当前掉话率为3%,打100个电话才有3个掉话,而且很难找到掉话地点。

CS掉话问题分析总结

CS掉话问题分析总结

CS掉话问题分析总结厦门CS掉话经常的原因值:a.弱覆盖:该问题多存在于城中村、住宅区密集的高楼、岛外郊区等;b.过覆盖:岛外、海边及个别无法上站的站点;c.扰码复用:岛外站点松散区域、岛内密集室分区域d.干扰:个别与小灵通、直放站共站的站点e.设备问题:不定f.邻区漏配:密集室分区域、岛外站点松散区域g.切换不及时掉话:主要道路、城中村、住宅区密集的高楼、岛外郊区等h.紧急呼叫:不定针对以上原因值的处理方法:弱覆盖:针对这类问题,首先是路测找到弱覆盖区域,在不影响路测指标和覆盖的前提下,调整方向角和下倾,通过RF解决;如果RF调整无效的区域,可以通过增加导频功率的方法,一般先将PCPICH信道功率从330提高到346;如果改善不大可以提高到360,并同时提高PCPICH的最大最小功率;这种做法对于岛内可能存在过覆盖现象,需要特别注意!添加邻区等;如果对于无法调整的弱覆盖,比如边界地区,因为你再怎么调还是弱,只不过把弱覆盖的地方外延了;针对这种场景,我们采取控制覆盖的方法:1.调整下倾角,收缩覆盖;2.提高小区接入电平;3.降低CS异系统切换判决门限和2D2F门限,让CS业务尽量承载在2G小区;如果是弱覆盖的情况,2G信号好的话,应会切到2G上?2G/3G都是属于弱覆盖的,有需求的话,只能加站;过覆盖针对这类问题,首先联系RF组确认过覆盖情况,在不影响路测指标和覆盖的前提下,调整方向角和下倾,通过RF解决过覆盖问题;如果RF调整无效的区域,可以通过降低导频功率的方法,一般先将PCPICH信道功率从330降低到313;如果改善不大可以降低到300,并同时降低PCPICH的最大最小功率;对于无法调整的过覆盖,比如大桥和高速等有特殊覆盖需求的位置,还可以通过调整切换参数防止掉话:如增大邻区CIO偏置,调整1A、1B事件参数,使RL加入激活集更加容易,而离开更加困难;同样也可以调整小区接入电平,收缩覆盖;扰码复用干扰设备问题邻区切换不及时掉话紧急呼叫定位分析问题一般流程:1.通过Nastar WCDMA性能统计,获取话统数据及打点信息,筛选出CS掉话TOPN小区,通常时间取2周,全天,筛选出掉话次数大于28次的小区,同时还应参考掉话率指标,对于绝对次数多,但是相对次数少的也可以不进入TOPN,如邮电广通大楼I;2.将TOPN小区在mapinfo中进行地理化显示,检查是否有比较集中的,可能存在区域性的干扰或者断站情况,可询问RF组负责人及RAN侧接口人;其次是在mapinfo中检查工参,检查是否有过覆盖情况;3.邻区完整性检查:地理化显示增加漏配邻区;通过Nastar的同频邻区核查功能,统计漏配邻区,优先添加1A上报次数高,分值高的漏配邻区,注意需结合地理化显示,通过该检查,还可以确定小区是否存在过覆盖或错误覆盖的情况:对于密集室分区域邻区已满或大于28个的,可以通过Nastar的冗余同频邻区分析功能,筛选出从未发生过切换或切换次数为0的邻区;4.如果发现可能存在区域性干扰排查,可以通过Nastar中的自定义RTWP查询,检查掉话时段的RTWP值,对于大于-100dbm以上的存在问题;5.检查站点硬件状态,在M2000上检查是否有存在或未清除历史告警,如驻波告警等会造成业务无法建立或掉话等;进入NODEB LMT中检查发射功率、RTWP测量;6.如果以上分析无法定位问题,则进入CHR分析阶段,首先还是先通过Nastar自带的CHR分析工具:从这里可以很快查询到掉话用户IMSI、掉话时间、所在最好小区、掉话时的ECIO、RSCP等信息,比OMSTAR要快的多;通过以上可以定位出是否为单用户问题、是否为弱覆盖掉话或过覆盖掉话;7.如果以上信息仍不足以定位问题,就需要根据掉话时间,将对应的CHR文件导入OMSTAR中,可以获得额外的:业务类型、业务状态、掉话原因、原小区、目标小区、历史信息等,可以判断是否为紧急通话,在什么进程中掉话,掉话原因(SRB 复位、激活集更新失败等),通过源小区、目标小区、历史信息中可以得知;以下个例子说明:460015*********用户发起的是UU_TRMNT_CONVERSAT_CALL语音被叫业务,掉话时正处于RNCAP_CS_SYS_HO_TO_GSM,异系统切换流程,原小区时401和403,目标小区时LAC14609 CI26291小区;掉话时错误代码为185468955,对应的原因值为物理链路失效:从它的历史纪录中我们可以知道,该用户完成了安全模式加密、软切换、RAB指派完成等阶段,开始了会话业务:8.如果通过以上步骤都没有定位到问题,则对于单用户问题,可以进入RNC LMT进行CDT跟踪,确认问题点,对于单小区问题,可以通过IOS进行单小区跟踪;分析系统信令,问题攻坚!备注本文涉及参数:软切换相对门限:INTRARELTHDFOR1ACSVP、INTRARELTHDFOR1ACSNVP、IntraRelThdFor1APS、INTRARELTHDFOR1BCSVP、INTRARELTHDFOR1BCSNVP、IntraRelThdFor1BPS1A:6 (3dB)、1B:12(6dB)软切换相关的迟滞:HystFor1A、HystFor1B、HystFor1C、HystFor1D1A/1B:0(0dB)、1C/1D:8(4dB)CIOOffset 面向邻区配置的CIO偏置,默认值是0;最低接入电平:PCPICH RSCP 的最低接入电平门限。

无线网络掉话问题的分析及处理

无线网络掉话问题的分析及处理

无线网络掉话问题的分析及处理摘要:移动网络运营中,掉话问题经常成为用户投诉的热点,如何有效降低无线网络掉话,提高用户满意度,成为无线网络优化人员关注的焦点。

本文主要从掉话的分类及原因、分析判断方法以及处理策略等三个方面进行讨论,以降低网络掉话率,努力提高网络运行质量。

关键词:无线网络掉话分析及处理1掉话问题描述掉话是指通话的非正常终止,掉话率是指掉话次数在接通总次数中的比例,它是衡量网络可用性的一个重要指标。

无线网络的掉话可分为两种:一种是在SDCCH信道上的掉话,另一种是在TCH信道上的掉话。

SDCCH掉话是指在BSC 给移动台分配了SDCCH信道,而TCH信道还没有分配成功期间发生的掉话;TCH 掉话是指在BSC给MS成功分配了TCH信道后,发生的不正常TCH释放。

2引起掉话问题的分析及处理无线网络具有较多不确定因素,这些因素对网络质量的影响非常大,其性能优劣常常成为用户对网络满意度的决定性因素,尤其是无线网络的掉话问题更是有直接和明显的影响。

引起掉话的因素很多,大致可以归纳为八个方面:2.1由于覆盖引起的掉话2.1.1产生原因(1)不连续覆盖(存在盲区)。

在孤立的基站边缘,信号强度弱,质量差,无法切换到其它小区而造成掉话;或者由于基站所覆盖的区域地形复杂(如山区公路)、地势起伏,无线传播环境复杂,信号受阻挡造成覆盖不连续引起掉话。

(2)室内覆盖差。

因为建筑物密集,信号传输衰耗大,加上建筑物墙体厚,穿透损耗大,室内电平较低,使得在通话过程中掉话。

(3)孤岛。

服务小区由于各种原因(如功率过大)形成孤岛,以至于移动台超出了它所定义的邻小区B的覆盖范围之外到达了小区C后还占用着原服务小区A的信号,而小区A又未定义邻小区C,此时移动台再根据原服务小区A提供的邻小区B进行切换时,就会因找不到合适的小区而导致掉话,如下图1所示。

图1覆盖过大导致的掉话(4)覆盖过小。

覆盖过小也有可能是由于某个小区的硬件设备出了问题,如天线受到阻挡或携带BCCH的载频发生了故障。

掉话分析报告

掉话分析报告

掉话分析报告1. 引言掉话是指在通信过程中电话突然中断或无法连接的问题。

它是移动通信网络中常见的质量问题之一,对用户体验和运营商的服务质量都有重要影响。

本报告旨在对掉话问题进行分析,帮助运营商了解掉话发生的原因,并提供相应的解决方案。

2. 数据概述本次掉话分析使用的数据集包含了1000个通话记录,每个通话记录包含呼叫起始时间、结束时间、呼叫时长、信号强度等信息。

以下是对数据集的基本描述:•数据集大小:1000行•字段数量:6个•数据格式:CSV3. 掉话分析3.1 掉话率计算掉话率是衡量掉话问题严重程度的指标之一,它表示在所有通话中发生掉话的比例。

根据数据集中的通话记录信息,我们可以计算出掉话率。

具体计算公式如下:掉话率 = (掉话次数 / 总通话次数) * 100%根据数据集,我们计算出的掉话率为5%。

3.2 掉话时间分布分析为了更好地理解掉话发生的时间分布情况,我们对掉话时间进行了统计和分析。

根据数据集中的呼叫起始时间和结束时间信息,我们可以计算出每个通话的掉话时间。

然后,我们对掉话时间进行分布统计,并绘制出柱状图进行可视化展示。

图1展示了掉话时间分布情况。

图1. 掉话时间分布图1. 掉话时间分布从图1中可以看出,在通话开始后的前5分钟内,掉话次数较多,之后逐渐降低。

这可能与网络连接过程中的初始化和信号衰减有关。

3.3 掉话原因分析掉话原因是导致掉话问题发生的主要因素之一。

为了深入了解掉话原因,我们对数据集中的其他字段进行了分析,包括信号强度、通话时长等。

首先,我们计算了每次通话的平均信号强度。

根据数据集中的信号强度信息,我们得到平均信号强度为-80dBm。

根据经验,信号强度越强,掉话问题越少。

其次,我们比较了通话时长和掉话次数之间的关系。

根据数据集中的通话时长信息,我们发现通话时长在1分钟以内的通话掉话率较高,而在1分钟以上的通话掉话率较低。

这可能与网络连接稳定性和信号质量有关。

3.4 解决方案基于对掉话率、掉话时间分布和掉话原因的分析,我们提出以下几点解决方案:•加强网络覆盖:提高网络覆盖范围和密度,特别是在通话质量较差的地区加强信号覆盖。

掉话问题分析

掉话问题分析

1.由于导频污染引起的掉话当强的可用信号多于移动台的RAKE接收机的个数时,由于RAKE接收机个数的限制,多余的分支将无法被移动台利用,从而导致导频污染。

分析:当移动台处于导频污染区时,接收电平RX很好,激活集中的导频的Ec/Io与相邻集或候选集中的某些PN的Ec/Io相差不大(用QualComm Retriever和CAIT测试显示在该区域存在多个导频强度相近的小区信号)。

解决方法:1、合理布置小区一个设计良好的网络应该根据覆盖区域的总体要求来设计整个网络的拓扑结构,设计每个小区应该满足的覆盖区域。

不合理的小区布局可能导致部分区域出现覆盖空洞,而部分区域出现多个导频强信号覆盖。

这样有可能会造成网络中大面积的导频污染或覆盖盲区。

2、避免采用高站如果一个基站选址太高,相对周围的地物而言,周围的大部分区域都在天线的视距范围内,使得信号在很大的范围内传播(尤其是在室外、街道等场所),但由于建筑物等地物的影响,使之又不能在覆盖区域内的所有地点都提供良好覆盖,尤其是室内部分,因此,就算单从覆盖来看,也需要增加其它的基站以满足整个区域的覆盖,这样,为了满足网络整体的覆盖,在高站的周围仍然要增加新的基站,这个高站就可能在许多区域影响到周围的其它站,造成导频污染问题。

另外,从容量方面来看,一个基站提供的容量毕竟有限,尤其在现阶段采用一个载频的情况下,因此,要在城市中满足密集话务分布的需要,大多数情况是需要由多个站来满足容量要求,因此,在这样的多站环境下,若有一个高站的存在,则周围的其它站将可能受到来自高站信号的影响,在切换区域,由于增加了该高站的信号,可能会形成导频污染。

由于高站可能会对多个基站形成干扰,系统容量将会受到较大的影响。

在CDMA网络规划时,要求基站的高度基本保持一致,尽量避免高站的现象。

3、合理设置天线方位在一个多基站的网络中,天线的方位应该根据全网的基站布局、覆盖需求、话务量分布等来合理设置。

一般来说,各扇区天线之间的方位设计应是互为补充。

掉话小分析

掉话小分析

1、根据你平时的工作经验,分析一下现网可能产生掉话的原因及
相应的解决措施。

(14分)
1)由于系统故障导致的掉话
及时查找MSC、BSC告警,并检查系统是否有大规模的调整,软件升级、补丁
2)由基站设备硬件故障引起的掉话
查找相关硬件的告警,更换相关硬件
3)由于天线馈线的原因导致掉话
检查仰角,检查馈线是否接反,接头接触不良或馈线损坏现象,天线的方位角和俯消除天线后向信号的干扰
4)由于A接口、ABIS接口的故障引起。

5)由于传输故障,同步不好,传输质量差造成的掉话
定期进行基站的时钟校准,传输同步检查和传输质量的检查
6)由于干扰导致的掉话
上行干扰:若同频,修正同频频率,若外部干扰,通过频谱分析仪来分析解决,寻找干扰源
下行干扰:通过统计数据的分析,结合现场测试,对干扰的频率进行修改
7)由于覆盖原因导致的掉话
措施:查找覆盖不足的地方;增加基站的覆盖;消除漂移信号的影响,比如仰角的调整,基站的发射功率的调整,最小接入电平的调整
8)由于切换引起的掉话
检查邻小区表是否定义完整:切换参数是否定义正确;目标小区是否拥塞;是否有频率干扰。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

CS掉话问题分析总结
厦门CS掉话经常的原因值:
a.弱覆盖:该问题多存在于城中村、住宅区密集的高楼、岛外郊区等;
b.过覆盖:岛外、海边及个别无法上站的站点;
c.扰码复用:岛外站点松散区域、岛内密集室分区域
d.干扰:个别与小灵通、直放站共站的站点
e.设备问题:不定
f.邻区漏配:密集室分区域、岛外站点松散区域
g.切换不及时掉话:主要道路、城中村、住宅区密集的高楼、岛外郊区等
h.紧急呼叫:不定
针对以上原因值的处理方法:
弱覆盖:
针对这类问题,首先是路测找到弱覆盖区域,在不影响路测指标和覆盖的前提下,调整方向角和下倾,通过RF解决;
如果RF调整无效的区域,可以通过增加导频功率的方法,一般先将PCPICH信道功率从330提高到346;如果改善不大可以提高到360,并同时提高PCPICH的最大最小功率;这种做法对于岛内可能存在过覆盖现象,需要特别注意!添加邻区等;
如果对于无法调整的弱覆盖,比如边界地区,因为你再怎么调还是弱,只不过把弱覆盖的地方外延了;针对这种场景,我们采取控制覆盖的方法:1.调整下倾角,收缩覆盖;2.提高小区接入电平;3.降低CS异系统切换判决门限和2D2F门限,让CS业务尽量承载在2G小区;如果是弱覆盖的情况,2G信号好的话,应会切到2G上?2G/3G都是属于弱覆盖的,有需求的话,只能加站;
过覆盖
针对这类问题,首先联系RF组确认过覆盖情况,在不影响路测指标和覆盖的前提下,调整方向角和下倾,通过RF解决过覆盖问题;
如果RF调整无效的区域,可以通过降低导频功率的方法,一般先将PCPICH信道功率从330降低到313;如果改善不大可以降低到300,并同时降低PCPICH的最大最小功率;
对于无法调整的过覆盖,比如大桥和高速等有特殊覆盖需求的位置,还可以通过调整切换参数防止掉话:如增大邻区CIO偏置,调整1A、1B事件参数,使RL加入激活集更加容易,而离开更加困难;同样也可以调整小区接入电平,收缩覆盖;
扰码复用
干扰
设备问题
邻区
切换不及时掉话
紧急呼叫
定位分析问题一般流程:
1.通过Nastar WCDMA性能统计,获取话统数据及打点信息,
筛选出CS掉话TOPN小区,通常时间取2周,全天,筛选出掉话次数大于28次的小区,同时还应参考掉话率指标,对于绝对次数多,但是相对次数少的也可以不进入TOPN,如邮电广通大楼I;
2.将TOPN小区在mapinfo中进行地理化显示,检查是否有比较集中的,可能存在区域性的干扰或者断站情况,可询问RF组负责人及RAN侧接口人;其次是在mapinfo
中检查工参,检查是否有过覆盖情况;
3.邻区完整性检查:地理化显示增加漏配邻区;通过Nastar的同频邻区核查功能,统计漏配邻区,优先添加1A上报次数高,分值高的漏配邻区,注意需结合地理化显
示,通过该检查,还可以确定小区是否存在过覆盖或错误覆盖的情况:
对于密集室分区域邻区已满或大于28个的,可以通过Nastar的冗余同频邻区分析功能,筛选出从未发生过切换或切换次数为0的邻区;
4.如果发现可能存在区域性干扰排查,可以通过Nastar中的自定义RTWP查询,检查掉话时段的RTWP值,对于大于-100dbm以上的存在问题;
5.检查站点硬件状态,在M2000上检查是否有存在或未清除历史告警,如驻波告警等会造成业务无法建立或掉话等;进入NODEB LMT中检查发射功率、RTWP测量;6.如果以上分析无法定位问题,则进入CHR分析阶段,首先还是先通过Nastar自带的CHR分析工具:
从这里可以很快查询到掉话用户IMSI、掉话时间、所在最好小区、掉话时的ECIO、RSCP等信息,比OMSTAR要快的多;通过以上可以定位出是否为单用户问题、是否为弱覆盖掉话或过覆盖掉话;
7.如果以上信息仍不足以定位问题,就需要根据掉话时间,将对应的CHR文件导入OMSTAR中,可以获得额外的:业务类型、业务状态、掉话原因、原小区、目标小区、历史信息等,可以判断是否为紧急通话,在什么进程中掉话,掉话原因(SRB 复位、激活集更新失败等),通过源小区、目标小区、历史信息中可以得知;以下个例子说明:
460015*********用户发起的是UU_TRMNT_CONVERSAT_CALL语音被叫业务,掉话时正处于RNCAP_CS_SYS_HO_TO_GSM,异系统切换流程,原小区时401和403,目标小区时LAC14609 CI26291小区;掉话时错误代码为185468955,对应的原因值为物理链路失效:
从它的历史纪录中我们可以知道,该用户完成了安全模式加密、软切换、RAB指派完成等阶段,开始了会话业务:
8.如果通过以上步骤都没有定位到问题,则对于单用户问题,可以进入RNC LMT进行CDT跟踪,确认问题点,对于单小区问题,可以通过IOS进行单小区跟踪;分析系统信令,问题攻坚!
备注
本文涉及参数:
软切换相对门限:
INTRARELTHDFOR1ACSVP、INTRARELTHDFOR1ACSNVP、IntraRelThdFor1APS、INTRARELTHDFOR1BCSVP、INTRARELTHDFOR1BCSNVP、IntraRelThdFor1BPS
1A:6 (3dB)、1B:12(6dB)
软切换相关的迟滞:
HystFor1A、HystFor1B、HystFor1C、HystFor1D
1A/1B:0(0dB)、1C/1D:8(4dB)
CIOOffset 面向邻区配置的CIO偏置,默认值是0;
最低接入电平:
PCPICH RSCP 的最低接入电平门限。

只有UE 测得的CPICH RSCP 大于该门限,UE 才有可能驻留到该小区。

参数ID:Qrxlevmin
参数取值范围:-58~-13
物理表示范围:-115dBm~-25dBm,步长为2dB
其中-58 对应-115dBm,-57 对应-113dBm,…,-13 对应25dBm
参数设置:缺省值为-58,即-115dBm。

异系统测量RSCP 启动/停止门限:
InterRATCSThd2DRSCP(CS 业务异系统测量RSCP 启动门限)
InterRATCSThd2FRSCP(CS 业务异系统测量RSCP 关闭门限)
INTERRATCSTHD2DECN0(CS 业务异系统测量Ec/No 启动门限)
INTERRATCSTHD2FECN0(CS 业务异系统测量Ec/No 关闭门限)
InterRatCSThd2DRSCP 的缺省值为-100dBm;
InterRatCSThd2FRSCP 的缺省值为-97dBm;
INTERRATCSTHD2DECN0 的缺省值为-14dB;
INTERRATCSTHD2FECN0 的缺省值为-12dB;。

相关文档
最新文档