GT分流后TD掉话整治优化

ostcom_B2000产品配置手册TD-SCDMA掉话问题分析优化指导手册- 4 - 内容介绍TD-SCDMA网络优化掉话问题分析介绍了TD-SCDMA网络优化中的掉话问题进行分析，包括掉话定义，分析流程和方法，常见掉话原因和典型掉话案例分析。本文分5章。l 概述。l 掉话定义：介绍路测和话统中掉话定义。l 掉话分析流程和方法:详细介绍掉话分析的流程和分析方法。l 常见掉话原因分析：介绍覆盖、邻区关系、切换、干扰等造成掉话的原因及分析的方法。l 典型掉话案例分析：结合广州TD网络优化案例进行分析。读者对象本书适合下列人员阅读：l 参与网络优化的相关人员。目录优化指导手册1-1前言iii内容介绍iii读者对象iii本书约定iii目录- 1 -第1章概述1-1第2章掉话定义2-12.1路测的掉话定义2-12.2话统指标中的掉话定义2-1第3章掉话分析流程和方法3-13.1路测数据分析流程3-13.2话统数据分析流程3-33.3跟踪数据分析流程3-63.4用户投诉分析流程3-9第4章常见掉话原因分析4-14.1覆盖差4-14.2邻区漏配4-14.3切换掉话4-24.4干扰掉话4-24.5流程交互失败4-34.6异常4-34.7调整措施4-34.7.1工程参数4-34.7.2小区参数4-3第5章典型掉话案例分析5-15.1邻区漏配5-15.2乒乓切换5-25.3弱覆盖5-3附录A:缩略语1附录B：文档修订记录2图 31掉话分析流程树3-1图 32 掉话原因判断3-2图 33 呼叫跟踪分析流程3-7图 34用户投诉分析流程3-9图 51邻区漏配调整前5-1图 52邻区漏配调整后5-1图 53乒乓切换调整前5-2图 54乒乓切换调整后5-2图 55弱覆盖调整前5-3图 56弱覆盖调整5-3TD-SCDMA网络优化掉话问题分析第4章 常见掉话原因分析第1章 概述在网络建设及运营中，掉话率（calldroprate）是反映网络质量的重要指标之一；掉话问题也是日常网络优化面临的一个常见问题。掉话问题对用户的负面影响最直接，因此掉话率是运营商最为关注的指标之一。实际的网络中，影响掉话率的因素很多，包括硬件问题、干扰问题、覆盖问题、切换问题、参数问题等。本文结合广州TD网络建设和优化的经验，对掉话的定义、分析流程和方法、原因分析等内容进行描述。4-4第2章 掉话定义2.1 路测的掉话定义从UE侧记录的空口信令上看，在通话过程（连接状态下）中，如果空口的消息，满足以下三个条件的任何一个：1）收到任何的BCH消息（即系统消息）2）收到RRC Release消息且释放的原因值为Not Normal3）收到CC Disconnect，CC Release Complete，CC Release三条消息中的任何一条，而且释放的原因为Not Normal Clearing或者Not Normal，Unspecified。2.2 话统指标中的掉话定义广义的掉话率应该包含CN和UTRAN的掉话率，由于网优重点关注与UTRAN侧的掉话率指标，本文掉话率描述也重点关注UTRAN侧的KPI指标分析。UTRAN侧相关指标就是RNC触发释放的各业务RAB个数。主要包括两个方面：（1）业务建立成功后，RNC向CN发送RAB RELEASE REQUEST消息。（2）业务建立成功后，RNC向CN发送IU RELEASE REQUEST消息，其后收到CN发送的IU RELEASE COMMAND。从大的方面来讲，掉话分为两大类，信令面掉话和用户面掉话；从流程上看，信令面掉话是RNC发起了Iu release request，用户面掉话是RNC主动发起RAB release request。需要说明的是RAN话统掉话的定义只从Iu接口的角度进行统计，统计了RNC主动发起的RAB release请求次数和Iu release请求次数。而路测掉话定义主要从空口的消息和非接入层的消息结合原因值来进行定义的，两者不完全一致的。比如说，对于同时进行主被叫通话，工具记录主叫的空口消息，如果被叫异常掉话，那么分析主叫的流程也会是一次掉话，但从话统上看，这次主叫是没有掉话指标记录的。所以两者的定义是不完全一致的，在分析时要注意区分。第3章 掉话分析流程和方法3.1 路测数据分析流程图 31掉话分析流程树图 32 掉话原因判断 准备数据路测软件采集数据文件RNC记录的单用户跟踪RNC记录的CDL 获取掉话位置采用路测数据处理软件，比如Analyzer和获取掉话的时间和地点，获取掉话前后Scanner采集的导频数据，手机采集的激活集和监测集信息，信令流程等。 分析Scanner主导小区变化情况主要分析主导小区的变坏情况，如果主导小区相对稳定，进一步分析RSCP和C/I情况；如果主导小区变化频繁，需要区分主导小区变化快的情况，或者没有主导小区的情况，然后进一步进行乒乓切换掉话分析。 分析Scanner主导小区信号RSCP和C/I观察Scanner最好小区RSCP，C/I，根据不同的情况分别处理RSCP差，C/I差，可以确定为覆盖问题；RSCP正常，C/I差（排除切换来不及导致的，同频邻区干扰），可以确定为导频干扰问题；RSCP正常，C/I正常，如果UE激活集中小区与Scanner最好小区不一致，可能为邻区漏配或者切换来不及导致的掉话；如果UE激活集中小区与Scanner最好小区一致,可能为上行干扰或者异常掉话。 路测重现问题由于一次路测不一定能够采集到定位掉话问题需要的所有信息，此时需要通过进一步路测来收集数据。通过进一步的路测也能确认该掉话点是随机掉话的点或者固定掉话点，一般来说固定掉话点一定需要解决，而随机掉话点则需要根据掉话发生的概率来确定是否需要解决。3.2 话统数据分析流程分析话统指标时，要先看RNC掉话率指标和信令面掉话率指标，掌握了网络运行的整体情况。同时对关注的小区（小区集合）针对性地分析，按小区（小区集合）得到更详细的掉话指标。分析时可使用话统分析工具得到不同业务的掉话情况以及大致的掉话原因。话统分析应获得指标明显异常的小区分析，如果小区以前KPI良好，此时很可能是版本、硬件、传输、天馈或者数据出了问题导致的异常，可以结合告警首先从这几个方面检查。如无明显异常，根据指标将各扇区载频进行统计分类，可整理出各重点指标较差小区列表，对于这些小区进一步细分话统指标（如分析更多相关指标，分析小时间间隔，分析可能引起掉话的指标，如切换指标等），同时结合CDL看掉话的原因。实际分析解决等问题时，在重点抓住某个指标分析的同时需要结合其他指标一起分析。需要说明的是话统只有在统计量较大时，指标数值才具有指导意义。例如，出现掉话率为50%并不就代表网络差，只有在呼叫次数、呼叫成功次数、掉话总次数的绝对值都已具备统计意义时，这个数值才具有意义话统分析流程可以简述如下：1. 分析RNC掉话率和信令面掉话率RNC掉话率统计RNC触发释放的各业务RAB个数，主要包括两个方面：（1）业务建立成功后，RNC向CN发送RAB RELEASE REQUEST消息。（2）业务建立成功后，RNC向CN发送IU RELEASE REQUEST消息，其后收到CN发送的IU RELEASE COMMAND。信令面掉话主要是RNC发起了Iu Release Request。分析IU口连接释放情况得到信令面掉话率。2. 分析掉话原因在话统分析中还分析引起掉话的主要原因，可分析以下主要指标：Rab释放请求次数，原因：无线网络层资源不足CSConvRabRelReq_ResRab释放请求次数，原因：无线网络层其他错误CSConvRabRelReq_RErrRab释放请求次数，原因：传输层错误CSConvRabRelReq_L2ErrRab释放请求次数，原因：协议错误CSConvRabRelReq_PErrRab释放请求次数，原因：非接入层错误CSConvRabRelReq_NASErrRab释放请求次数，原因：杂项错误CSConvRabRelReq_OthErrRab释放请求次数，原因：无线网络层资源不足PSConvRabRelReq_ResRab释放请求次数，原因：无线网络层其他错误PSConvRabRelReq_RErrRab释放请求次数，原因：传输层错误PSConvRabRelReq_L2ErrRab释放请求次数，原因：协议错误PSConvRabRelReq_PErrRab释放请求次数，原因：非接入层错误PSConvRabRelReq_NASErrRab释放请求次数，原因：杂项错误PSConvRabRelReq_OthErr类似还有interactive、streaming、background类型的CS、PS业务。3. 分析小区（小区集合）的掉话率指标上述只是对整个网络分析，我们可分析小区掉话率指标，主要需要分析小区“AMR掉话率”、“VP掉话率”、“PS掉话率”、“硬切换掉话率”。 对所有小区分别用以上的指标进行排序，选择指标特别差的小区或者最差的一些小区，进一步按照分析掉话原因。无线电路域掉话率电路域掉话的RAB数目/电路域RAB指派建立成功的RAB数目*100%电路域掉话的RAB数目RNC请求释放的电路域RAB数目+RNC请求释放的电路域Iu连接对应的RAB数目。无线分组域掉线率分组域掉线的RAB数目/分组域RAB指派建立成功的RAB数目*100%分组域掉线的RAB数目RNC请求释放的分组域RAB数目+RNC请求释放的分组域Iu连接对应的RAB数目无线掉话率扩展CS/PS域因该原因掉话的RAB数目/CS/PS域RAB指派成功的RAB数目*100%CS/PS域因该原因掉线的RAB数目RNC请求释放的CS/PS域RAB数目（对应该原因值）RNC请求释放的CS/PS域Iu连接对应的RAB数目（对应该原因值）电路域掉话的RAB数目/电路域64K业务话务量*100%电路域掉话的RAB数目RNC请求释放的电路域RAB数目+RNC请求释放的电路域Iu连接对应的RAB数目。为分析不同速率的PS掉话情况，可分析指标RNC_PS_384K_RAB_REL_CELL_TRIG_BY_RNCRNC_PS_128K_RAB_REL_CELL_TRIG_BY_RNCRNC_PS_64K_RAB_REL_CELL_TRIG_BY_RNC切换掉话率情况：HHO_INTERFEQ_DROP_OUT_CELL / HHO_INTERFEQ_OUT_CELLHHO_INTERFEQ_DROP_IN_CELL / HHO_INTERFEQ_IN_CELLHHO_INTRAFEQ_DROP_OUT_CELL/ HHO_INTRAFEQ_OUT_CELLHHO_INTRAFEQ_DROP_IN_CELL/ HHO_INTRAFEQ_IN_CELL通过上述这些掉话率的分析，我们可获得不同业务及其速率在网络中的性能，可获得切换掉话情况。重要的是通过这一步可获得指标较差的小区以及时间段。释放原因指标：Rab释放请求次数，原因：无线网络层资源不足CSConvRabRelReq_ResRab释放请求次数，原因：无线网络层其他错误CSConvRabRelReq_RErrRab释放请求次数，原因：传输层错误CSConvRabRelReq_L2ErrRab释放请求次数，原因：协议错误CSConvRabRelReq_PErrRab释放请求次数，原因：非接入层错误CSConvRabRelReq_NASErrRab释放请求次数，原因：杂项错误CSConvRabRelReq_OthErrRab释放请求次数，原因：无线网络层资源不足PSConvRabRelReq_ResRab释放请求次数，原因：无线网络层其他错误PSConvRabRelReq_RErrRab释放请求次数，原因：传输层错误PSConvRabRelReq_L2ErrRab释放请求次数，原因：协议错误PSConvRabRelReq_PErrRab释放请求次数，原因：非接入层错误PSConvRabRelReq_NASErrRab释放请求次数，原因：杂项错误PSConvRabRelReq_OthErr流程定时器超时指标：流程定时器超时可重点分析以下流程(主要分析请求与CMP次数，已经相应超时次数统计指标)：RB_SETUPRB_RECFGACTIVE_SET_UPDATEPHY_CFGRL Failure指标：CELL_UPDT_RL_FAIL_CELL（下行失步）IUB_RL_FAIL（上行失步）RTWP，TCP指标：RTWP均值、最大值TCP均值、最大值4. 检查小区是否异常如果小区以前KPI正常，可检查小区的告警，排除小区异常方面的原因。5. 分析掉话原因设备问题：按照2、3如果分析结果是传输、设备原因，则可归类为设备问题。覆盖差：按照2、3如果分析结果是空口原因，则可归类为覆盖差，无线环境变化块等原因。切换导致的掉话：HHO相关指标导致的掉话。干扰导致的掉话：分析RL Failure、RTWP，TCP相关指标，由于话统粒度粗，主要看整体情况，无法精确分析。从话统详细分析掉话时，需按照掉话原因分类分析相关指标，必要时结合CDL分析。6. 通过路测重现问题由于话统给出了趋势，并给出了可能的问题，具体问题的定位和分析还需要结合路测或者针对小区的CDL分析来进行。对于问题小区，一般都需要安排针对小区进行路测，跟踪手机侧和RNC的信令流程进行分析，详细分析方法请参见路测数据分析流程。3.3 跟踪数据分析流程跟踪数据分析包括单用户跟踪消息分析，通常情况下，单用户消息结合数据采集工具记录的UE侧数据，能够基本上定位一些掉话问题；对于更加复杂的问题，需要配合CDL和实时状态监控来综合分析。也有一些商用手机的问题或者重点用户的问题，没有手机侧记录的消息，需要通过从单用户跟踪数据来分析和定位。单用户跟踪除了记录单用户的信令消息（Iu，Iur，Iub，Uu），同时需要记录P-CCPCH RSCP、 C/I性能跟踪，记录UE的发射功率，记录上行SIR，SIR Target，记录上行BLER，记录下行码发射功率，如果是数据业务，还要进一步记录上下行的业务量和吞吐量。图 33 呼叫跟踪分析流程1. 获取单用户跟踪消息单用户跟踪消息需要事先在RNC上进行跟踪，才能记录相应的消息。根据IMSI进行跟踪记录的消息用来分析掉话问题是足够的。2. 获取掉话点信息从单用户跟踪消息来看，掉话的定义是RNC主动发起了RAB释放（消息名称为RANAP_RAB_RELEASE_REQ），或者RNC主动发起IU释放（消息名称为RANAP_IU_RELEASE_REQ）。前者对应为用户面掉话，后者对应为信令面掉话。通过查找以上两条消息，就可以或者掉话点的时间，以及掉话前的信令消息，以便进一步进行分析。3. 信令面掉话分析信令面掉话表现为手机或者RNC不能收到确认模式传送的信令，产生SRB复位，导致连接释放。下行方向一般有这些消息手机不能收到而可能导致SRB复位：安全模式过程，鉴权加密过程，测量控制，激活集更新，物理信道重配置，传输信道重配置，RB重配置以及3G到2G的切换命令（HANDOVER FROM UTRAN COMMAND），手机是否收到这些命令需要手机侧的跟踪消息来确认；上行方向有以下的消息可能导致SRB复位：测量报告，激活集更新完成，物理信道重配置完成，传输信道重配置完成，RB重配置完成，同样需要RNC侧的跟踪消息来确认是否收到。4. 用户面掉话分析用户面掉话主要是TRB复位，这种情况主要在PS业务上发生，voice和VP业务不会产生TRB复位。一般可以通过确认掉话发生时的UE发射功率或者下行码发射功率情况来辅助确认。当激活集中只有一条链路上，会由于RL failure导致RNC发起Iu Release， RL failure是上行失步引起的，但是下行失步会使UE关闭发射机，接着就造成上行失步，在定位掉话是上行引起释放还是下行引起的时候，需要分析掉话前手机的发射功率和实时状态监控的下行的码发射功率来区分。下行覆盖差、下行干扰强或者上行干扰都会导致TRB复位。有时候数据业务由于重传次数设置不合理，在切换来不及的情况下，TRB比SRB先产生复位，在分析时要注意区分。5. 异常掉话分析异常掉话一般指掉话无法从覆盖、干扰等方面找到原因，也无法根据前面介绍的用户面掉话或者信令面掉话原因来解释，这种掉话往往是设备的异常或者是手机的异常导致的。比如由于传输突然中断导致的掉话、基站设备异常导致的掉话、手机突然死机等都会导致异常掉话。对于传输异常一般通过分析CDL或者参看告警来进一步分析；对于基站设备异常可以通过查询基站状态来确认，对于手机异常，需要通过分析手机记录的数据来定位。6. 拨测，重现问题当已有的数据不足以定位掉话问题的时候，启动更详细的数据跟踪，最好的办法采用测试手机是在问题点进行拨测，重现问题，然后继续进行分析。3.4 用户投诉分析流程图 34用户投诉分析流程1. 了解用户投诉用户投诉发生的时候需要详细记录问题发生的时间，问题产生的地点，以及问题的具体现象。2. 检查话统指标通过分析用户投诉相关的话统指标，来进一步分析该投诉是某个用户特有的问题还是网络一般性的问题，对于一般性的问题，请参考话统指标的分析来进一步分析投诉。3. 检查告警根据投诉的时间，查看CN，RNC或者投诉地点对应基站的告警，看这些告警是否会产生相应的掉话，如果存在这个告警，试着消除和解决这个告警。4. 检查CDLCDL记录了用户异常发生时候的信令，状态等信息，通过分析CDL可以进一步了解投诉产生的原因。5. 投诉点拨测，重现问题对于话统分析，告警分析以及CDL分析都无法解决的问题，需要通过到现场拨测的方法进行问题重新，拨测的时候数据记录的方法和路测方法相同，在某些场合，可能不适合记录手机侧信息，那么需要通过RNC来尽量多的记录各种信息，特别需要记录收集上报的C/I和RSCP信息，以排除覆盖问题导致的掉话。对于一些特别的地点，到现场拨测都不可能，那么需要通过用户的手机号码来获取IMSI，然后在RNC启动呼叫跟踪，以便进一步定位问题。第4章 常见掉话原因分析4.1 覆盖差TD网络覆盖指标主要是P-CCPCH的RSCP、C/I。通常所说的覆盖差，是指RSCP小于100dBm。对覆盖差问题进行分析是，通常要考虑上行覆盖和下行覆盖。上行覆盖差还是下行覆盖差的问题需要通过掉话前上行或者下行的专用信道功率来确认，需要采用以下的方法来确认：如果掉话前的上行发射功率达到最大值，并且上行的BLER也很差或者从RNC记录的单用户跟踪上看到NodeB上报RL failure，基本可以认为上行覆盖差导致的掉话。如果掉话前，下行发射功率达到最大值，并且下行的BLER很差，基本可以认为是下行覆盖不行导致的掉话。在合理的链路平衡情况下，而且上下行没有干扰的情况下，上行和下行发射功率会同时受限，此时不一定要严格区分哪一方先出现受限。如果上下行严重不平衡，则应该初步判定为受限方向存在干扰。确认覆盖的问题简单直接的方式是直接观察Scanner采集的数据，若最好小区的RSCP和C/I都很低，就可以认为是覆盖问题。由于缺站、扇区接错、功放故障导致站关闭等原因都会导致覆盖差，在一些室内，由于过大的穿透损耗也会导致覆盖太差，扇区接错或者站点由于故障原因关闭等容易在优化过程中出现，表现为其他小区在掉话点的覆盖差，需要注意分析区别。4.2 邻区漏配一般来讲，初期优化过程掉话占大多数是由于邻区漏配导致的。对于同频邻区，通常采用以下的办法来确认是否为同频邻区漏配：方法一：观察掉话前UE记录的激活集C/I信息和Scanner记录的Best Server C/I信息，如果UE记录的C/I很差，而Scanner记录的Best Server C/I很好；同时检查Scanner记录Best Server扰码是否出现在掉话前最近出现的同频测量控制的邻区列表中，如果测量控制的邻区列表中中没有扰码，那么可以确认是邻区漏配。方法二：如果掉话后UE马上重新接入，如果UE重新接入的小区扰码和掉话时的扰码不一致，也可以怀疑是邻区漏配问题，可以通过测量控制进一步进行确认（从掉话位置的消息开始往前找，找到最近一条同频测量控制消息，检查该测量控制消息的邻区列表）。方法三：有些UE会上报检测集（Detected Set ）信息，如果掉话发生前检测集信息中有相应的扰码信息，也可以确认是邻区漏配的问题。邻区漏配导致的掉话也包括异频邻区漏配和异系统邻区漏配。异频邻区漏配的确认方法和同频几乎相同，主要是掉话发生的时候，手机没有测量或者上报异频邻区，而手机掉话后重新驻留到异频邻区上。异系统邻区漏配表现为手机在3G掉话，掉话后手机重新选网驻留到2G网络，从信号质量来看，2G网络的质量很好（在掉话点用2G测试手机观察RSSI信号）。4.3 切换掉话切换导致掉话主要有两类原因：切换来不及或者乒乓切换。从信令流程上CS业务表现为手机收不到激活集更新命令（物理信道重配置），PS业务也有可能收不到激活集更新命令，也有可能在切换之前先发生TRB复位。从信号上看，切换来不及主要有以下现象：1）拐角：源小区C/I陡降，目标小区C/I陡升（即突然出现就是很高的值）；2）针尖：源小区C/I快速下降后一段时间后上升，目标小区出现短时间的陡升。从信令流程上看，一般在掉话前手机上报了邻区的1g或者2a测量报告，RNC也收到了测量报告，并下发了激活集更新消息，但UE收不到激活集更新消息。乒乓切换主要有以下两种现象：1）主导小区变化快：2个或者多个小区交替成为主导小区，主导小区具有较好的RSCP和C/I每个小区成为主导小区的时间很短；2）无主导小区：存在多个小区，RSCP正常而且相互之间差别不大，每个小区的C/I都很差。从信令流程上看，一般可以看到1个小区刚刚删除，然后马上要求加入，此时收不到RNC下发的激活集更新命令导致失败。解决切换来不及导致的掉话，可以通过调整天线扩大切换区，也可以配置1g事件的切换参数使切换更容易发生，或者配置Offset使目标小区能够提前发生切换；解决乒乓切换带来的掉话问题，可以调整天线使覆盖区域形成主导小区，也可以配置1g事件的切换参数减少乒乓的发生等方法来进行。对于异频切换和系统间切换，在切换前需要进行异频或者异系统测量，测量启动太迟，可能导致手机来不及测量目标小区的信号，从而产生掉话，也可能手机完成了测量，但下发的异频或者异系统切换请求手机不能正常接收而导致掉话。对于3G 2G系统间切换掉话的常见原因大概如下：邻区漏配置，可以通过配置邻区解决；信号变化太快导致掉话；手机问题，比如UE回切换失败或者UE没有上报异系统测量报告导致掉话等；物理信道重配置时发生最优小区发生变更导致掉话，需要产品算法进行优化；异系统小区配置过多导致掉话，可以通过优化邻区数目解决；LAC区配置错误导致的掉话，可以通过数据配置检查解决。4.4 干扰掉话下行和上行的干扰都会导致掉话。一般情况下，对于下行，当激活集P-CCPCH RSCP大于-85dB，而激活集综合C/I小于-9dB产生了掉话，基本上可以认为是下行干扰的问题（当切换不及时的时候，也可能出现服务小区RSCP信号很好，但C/I很差；但此时监测集小区RSCP和C/I都很好）；对于上行RTWP比正常值（-107-105）超过10dB，干扰时间超过23s，就有可能造成掉话，需要重点解决。下行的干扰通常是指导频污染，指覆盖地区存在3个以上的小区满足切换条件，由于信号的波动常常出现激活集替换或者最优小区发生变化，通常当激活集综合质量不好（P-CCPCH的C/I都在-3dB左右波动），容易出现切换失败导致SRB复位，也可能出现TRB复位。上行的干扰增加了连接模式的手机上行发射功率，从而产生过高的BLER导致SRB或者TRB复位或者由于失步导致掉话。另外，在切换的时候，新建链路由于上行干扰问题导致链路不能同步，从而造成该小区的切换成功率低，或者造成切换失败而导致掉话。通常在没有干扰的情况下，上下行是平衡的，也就是说掉话前上下行的发射功率都会接近最大值。但当干扰存在时，如果是下行的干扰，往往出现上行发射功率很小或者BLER收敛的情况，但下行发射功率达到最大值同时也伴随着下行BLER不收敛；对于上行干扰，会存在同样的表现，在实际分析可以通过这个方法来区分。4.5 流程交互失败一些需要信令交互的流程，如AMR控制、UE的状态迁移等，常常会由于信号的原因，手机支持方面的原因或者RAN设备和手机的配合问题，导致流程失败，最后导致掉话。还有一种特殊情况就是在流程的交互过程中，如RB建立，RB重配置等流程中，切换的测量报告不能及时处理，导致信号变差而掉话。这类问题需要针对特定的流程和手机进行分析，没有一般性的处理方法。4.6 异常在排除了以上的原因之后，其他的掉话一般需要怀疑设备的问题，需要通过查看设备的日志，告警等进一步来分析掉话原因。比如：NodeB异常引起同步失败，导致的链路不停增加和删除,手机不上报1g测量报告导致掉话.这里需要重点注意的是测试手机异常死机引起的掉话问题，一般在拨测过程中容易出现这个问题，具体表现为路测记录的数据中有一段时间没有手机上报的信息。4.7 调整措施4.7.1 工程参数工程参数的调整可以调整站点的位置、天线的高度、下倾角、天线的波瓣宽度、天线增益以及方向角等。对于上行或下行覆盖问题导致的掉话，增加站点是最好的办法，同时可以考虑更改天线的高度、下倾角，也可以更换增益更高的天线或者增加塔放。对于针尖和拐角效应，通过天线调整也是比较有效的解决办法，由于针尖效应和拐角效应往往出现在街道拐弯的地方或者两条街道交界的地方，可以考虑通过天线的方向角和街道错开一定的角度的方式来调整，但同时需要注意原来街道路边商铺的覆盖不要有很大的影响。对于导频干扰引起的覆盖问题，可以通过调整某一个天线的工程参数，使该天线在干扰位置成为主导小区；也可以通过调整其他几个天线参数，减小信号到达这些区域的强度；从而减少导频个数；如果条件许可，可以增加新的基站覆盖这片地区；如果干扰来自一个基站的两个扇区，可以考虑进行扇区合并。工程参数的调整需要综合考虑整个小区调整效果，在解决一个问题的同时要注意不在其它区域引入新的问题。4.7.2 小区参数可调的参数包括小区偏移Offset、切换延迟触发时间、测量启动门限、切换判决门限、相关定时器和计数器等，详细的参数及相应的应用描述请参考对应的算法参数手册TD-SCDMA网络参数手册。TD-SCDMA网络优化掉话问题分析第5章 典型掉话案例分析第5章 典型掉话案例分析5.1 邻区漏配图 51邻区漏配调整前测试车辆由“清河东机楼”向“石碁永善村”行驶时，发现“清河东机楼-3”的信号逐渐变差，但没有出现理应更好的“石碁永善村-2”信号，始终不能切换，最终掉话。掉话后，手机重选到“石碁永善村2”，信号证实该小区信号很强。按照前面介绍的掉话分析过程，初步怀疑掉话原因是邻区漏配造成。经查询RNC配置数据，发现“清河东机楼A3”与“石碁永善村2”之间没有邻区关系。解决方法：“清河东机楼A3”与“石碁永善村2”相互添加邻区关系。复测结果UE在“清河东机楼A-3”作为服务小区时，能够测量到“石碁永善村-2”的信号，并顺利切换。图 52邻区漏配调整后5.2 乒乓切换图 53乒乓切换调整前由南向北行驶进行测试的过程中，在南沙基站北的一个十字路口南沙3小区和塘坑工业区1小区间出现乒乓切换现象。从网络拓扑图可以看到，这两个扇区的信号均能沿街道直射到此处，造成该处两个小区的信号强度差不多，但没有一个主信号，进而出现乒乓切换现象。对于乒乓切换，常用的解决办法有：调整小区之间的切换迟滞和在乒乓切换提供一个信号。在这里选择提供一个主信号的方法来解决问题。通过对现场无线环境的勘察和实际覆盖情况的需要，决定增大塘坑工业区1小区的下倾角来控制它的覆盖范围，使南沙3小区成为问题区域的主覆盖小区，从而避免乒乓切换的发生。在规划设计中塘坑工业区1小区的下倾角为3度，但在进行调整时发现其实际下倾为1度，调整到规划值3度。调整后复测，问题解决。图 54乒乓切换调整后5.3 弱覆盖图 55弱覆盖调整前问题区域应由梅山糖厂1小区来覆盖，但在行驶过程中一直是由梅山糖厂2小区来覆盖，并没有切换到梅山糖厂1小区，从而造成问题区域内覆盖较弱，查看服务小区和邻小区信息后发现梅山糖厂1小区的RSCP在105以下，估计是梅山糖厂1小区发生故障。联系基站维护人员后得到确认，对梅山糖厂1小区排障后复测，覆盖问题解决。图 56弱覆盖调整5-3TD-SCDMA网络优化掉话问题分析附录附录A:缩略语英文缩写英文原语中文含义AAMRAdaptive multi Rate自适应多速率附录B：文档修订记录更新日期更新人版本备注附-2