GT分流后TD掉话整治优化

知识水坝（豆丁网 pologoogle）为您倾心整理（下载后双击删除） 百度一下 知识水坝 TD-SCDMA 掉话问题分析 优化指导手册 TD-SCDMA 网络优化 掉话问题分析 目录 - 1 - ostcom_B2000 产品配置手册 - 2 - ostcom_B2000 产品配置手册 - 3 - 内容介绍 TD-SCDMA网络优化 掉话问题分析 介绍了 TD-SCDMA网络优化中的掉话问题进行分析，包括掉话定义，分析流程和方法，常见掉话原因和典型掉话案例分析。本文分 5章。 概述。 掉话定义：介绍路测和话统中掉话定义。 掉话分析流程和方法 :详细介绍掉话分析的流程和分析方法。 常见掉话原因分析：介绍覆盖、邻区关系、切换、干扰等造成掉话的原因及分析的方法。 典型掉话案例分析：结合广州 TD网络优化案例进行分析。 读 者对象 本书适合下列人员阅读： 参与网络优化的相关人员 。 目 录 优化指导手册 . 1-1 前言 .错误 !未定义书签。 内容介绍 . - 3 - 读者对象 . - 3 - 本书约定 . 错误 !未定义书签。 目 录 .- 3 - 第 1 章 概述 . 1-1 第 2 章 掉话定义 . 2-1 2.1 路测的掉话定义 . 2-1 2.2 话 统指标中的掉话定义 . 2-1 第 3 章 掉话分析流程和方法 . 3-1 3.1 路测数据分析流程 . 3-1 3.2 话统数据分析流程 . 3-3 ostcom_B2000 产品配置手册 - 4 - 3.3 跟踪数据分析流程 . 3-7 3.4 用户投诉分析流程 . 3-10 第 4 章 常见掉话原因分析 . 4-1 4.1 覆盖差 . 4-1 4.2 邻区漏配 . 4-1 4.3 切换掉话 . 4-2 4.4 干扰掉话 . 4-2 4.5 流程交互失败 . 4-3 4.6 异常 . 4-3 4.7 调整措施 . 4-3 4.7.1 工程参数 .4-3 4.7.2 小区参数 .4-3 第 5 章 典型掉话案例分析 . 5-1 5.1 邻区漏配 . 5-1 5.2 乒乓切换 . 5-2 5.3 弱覆盖 . 5-3 附录 A:缩略语 .1 附录 B：文档修订记录 .2 图 3-1掉话分析流程树 . 3-1 图 3-2 掉话原因判断 . 3-2 图 3-3 呼叫跟踪分析流程 . 3-8 图 3-4用户投诉分析流程 . 3-10 图 5-1邻区漏配调整前 . 5-1 图 5-2邻区漏配调整后 . 5-1 图 5-3乒乓切换调整前 . 5-2 图 5-4乒乓切换调整后 . 5-2 图 5-5弱覆盖调整前 . 5-3 图 5-6弱覆盖调整 . 5-3 TD-SCDMA 网络优化 掉话问题分析 第 1 章 概述 1-1 第 1章 概述 在网络建设及运营中，掉话率（ calldroprate）是反映网络 质量的重要指标之一；掉话问题也是日常网络优化面临的一个常见问题。掉话问题对用户的负面影响最直接，因此掉话率是运营商最为关注的指标之一。实际的网络中，影响掉话率的因素很多，包括硬件问题、干扰问题、覆盖问题、切换问题、参数问题等。本文结合广州 TD网络建设和优化的经验，对掉话的定义、分析流程和方法、原因分析等内容进行描述。 TD-SCDMA 网络优化 掉话问题分析 第 2 章 掉话定义 2-1 第 2章 掉话定义 2.1 路测的掉话定义 从 UE侧记录的空口信令上看，在通话过程（连接状态下）中，如果空口的消息，满足以下三个条件的任何一个： 1） 收到任何的 BCH消息（即系统消息） 2） 收到 RRC Release消息且释放的原因值为 Not Normal 3） 收到 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请求次数。而路测掉话定义主要从空口的消息和非接入层的消息结合原因值来进行定义的，两者不完全一致的。比如说，对于同时进行主被叫通话，工具记录主叫的空口消息，如果被叫异常掉话，那么分析主叫的流程也会是一次掉话，但从话统上看，这次主叫是没有掉话指标记录的。所以两者的定义是不完全一致的，在分析时要注意区分 。 TD-SCDMA 网络优化 掉话问题分析 第 3 章 掉话分析流程和方法 3-1 第 3章 掉话分析流程和方法 3.1 路测数据分析流程 准 备 数 据获 取 掉 话 时间 和 位 置邻 区 露 配覆 盖 分 析切 换 分 析干 扰 分 析异 常 分 析重 新 路 测重 现 问 题XYYYYYNNNNN图 3-1掉话分析流程树 TD-SCDMA 网络优化 掉话问题分析 第 3 章 掉话分析流程和方法 3-2 准 备 数 据 U E和S c a n n e r最 好 小 区 比 较稳 定 一 致 N获 取 掉 话 位 置 和 时 间 分 析 S c a n n e r主 导 小区 信 号 变 化 R S C P 差 C / I 差 R S C P 正 常 C / I 差 R S C P 正 常 C / I 正 常 邻 区 漏 配 上 行 干 扰 问题切 换 不 及 时 确 认 漏 配 邻 区 ？ 覆 盖 问 题 异 常 掉 话 导 频 干 扰 问题 不 一 致 确 认 上 行 干 扰 ？ 问 题 是 否 解 决 重 新 路 测Y主 导 小 区 信 号稳 定 ？ S c a n n e r 最 优 小 区R S C P 和 C / I乒 乓 切 换 问题 变 化 频 繁YN图 3-2 掉话原因判断 准备数据 路测软件采集数据文件 RNC记录的单用户跟踪 TD-SCDMA 网络优化 掉话问题分析 第 3 章 掉话分析流程和方法 3-3 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%并不就代表网络差，只有在呼叫次数、呼叫成功次数、掉话总次数的绝对值都已具备统计意义时，这个数值才具有意义 话统分析流程可以简述如下： TD-SCDMA 网络优化 掉话问题分析 第 3 章 掉话分析流程和方法 3-4 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_Res Rab释放请求次数，原因：无线网络层其他错误 CSConvRabRelReq_RErr Rab释放请求次数，原因：传输层错误 CSConvRabRelReq_L2Err Rab释放请求次数，原因：协议错误 CSConvRabRelReq_PErr Rab释放请求次数，原因：非接入层错误 CSConvRabRelReq_NASErr Rab释放请求次数，原因：杂项错误 CSConvRabRelReq_OthErr Rab释放请求次数，原因：无线网络层资源不足 PSConvRabRelReq_Res Rab释放请求次数，原因：无线网络层其他错误 PSConvRabRelReq_RErr Rab释放请求次数，原因：传输层错误 PSConvRabRelReq_L2Err Rab释放请求次数，原因：协议错误 PSConvRabRelReq_PErr Rab释放请求次数，原因：非接入层错误 PSConvRabRelReq_NASErr Rab释放请求次数，原因：杂项错误 PSConvRabRelReq_OthErr 类似还有 interactive、 streaming、 background类型的 CS、 PS业务。 3. 分析小区（小区集合）的掉话率指标 上述只是对整个网络分析，我们可分析小区掉话率指标，主要需要分析小区“ AMR掉话率”、“ VP掉话率”、“ PS掉话率”、“硬切换掉话率”。 对所有小区分别用以上的指标进行排序，选择指标特别差的小区或者最差的一些小区，进一步按照分析掉话原因。 无线电路域掉话率 电路域掉话的 RAB数目 /电路域 RAB指派建立成功的 RAB数目 *100% 电路域掉话的 RAB数目 RNC请求释放的电路域 RAB数目+RNC请求释放的电路域 Iu连接对应的 RAB数目。 无线分组域掉线 分组域掉线的 RAB数目 /分组 分组域掉线的 RAB数目 RNCTD-SCDMA 网络优化 掉话问题分析 第 3 章 掉话分析流程和方法 3-5 率 域 RAB指派建立成功的 RAB数目 *100% 请求释放的分组域 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_RNC RNC_PS_128K_RAB_REL_CELL_TRIG_BY_RNC RNC_PS_64K_RAB_REL_CELL_TRIG_BY_RNC 切换掉话率情况： HHO_INTERFEQ_DROP_OUT_CELL / HHO_INTERFEQ_OUT_CELL HHO_INTERFEQ_DROP_IN_CELL / HHO_INTERFEQ_IN_CELL HHO_INTRAFEQ_DROP_OUT_CELL/ HHO_INTRAFEQ_OUT_CELL HHO_INTRAFEQ_DROP_IN_CELL/ HHO_INTRAFEQ_IN_CELL 通过上述这些掉话率的分析，我们可获得不同业务及其速率在网络中的性能，可获得切换掉话情况。重要的是通过这一步可获得指标较差的小区以及时间段。 释放原因指标： Rab释放请求次数，原因：无线网络层资源不足 CSConvRabRelReq_Res Rab释放请求次数，原因：无线网络层其他错误 CSConvRabRelReq_RErr Rab释放请求次数，原因：传输层错误 CSConvRabRelReq_L2Err Rab释放请求次数，原因：协议错误 CSConvRabRelReq_PErr Rab释放请求次数，原因：非接入层错 CSConvRabRelReq_NASErr TD-SCDMA 网络优化 掉话问题分析 第 3 章 掉话分析流程和方法 3-6 误 Rab释放请求次数，原因：杂项错误 CSConvRabRelReq_OthErr Rab释放请求次数，原因：无线网络层资源不足 PSConvRabRelReq_Res Rab释放请求次数，原因：无线网络层其他错误 PSConvRabRelReq_RErr Rab释放请求次数，原因：传输层错误 PSConvRabRelReq_L2Err Rab释放请求次数，原因：协议错误 PSConvRabRelReq_PErr Rab释放请求次数，原因：非接入层错误 PSConvRabRelReq_NASErr Rab释放请求次数，原因：杂项错误 PSConvRabRelReq_OthErr 流程定时器超时指标： 流程定时器超时可重点分析以下流程 (主要分析请求与 CMP次数，已经相应超时次数统计指标 )： RB_SETUP RB_RECFG ACTIVE_SET_UPDATE PHY_CFG RL Failure指标： CELL_UPDT_RL_FAIL_CELL（下行失步） IUB_RL_FAIL（上行失步） RTWP， TCP指标： RTWP均值、最大值 TCP均值、最大值 4. 检查小区是否异常 如果小区以前 KPI正常，可检查小区的告警，排除小区异常方面的原因。 5. 分析掉话原因 设备问题：按照 2、 3如果分析结果是传输、设备原因，则可归类为设备问题。 覆盖差：按照 2、 3如果分析结果是空口原因，则可归类为覆盖差，无线环境变化块等原因。 切换导致的掉话： HHO相关指标导致的掉话。 TD-SCDMA 网络优化 掉话问题分析 第 3 章 掉话分析流程和方法 3-7 干扰导致的掉话：分析 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，记录下行码发射功率，如果是数据业务，还要进一步记录上下行的业务量和吞吐量。 TD-SCDMA 网络优化 掉话问题分析 第 3 章 掉话分析流程和方法 3-8 获 取 单 用 户 跟踪 消 息获 取 掉 话 点 信息信 令 面 掉 话？用 户 面 掉 话？异 常 掉 话 ？掉 话 问 题 解决 ？拨 测 ， 重 现 问题解 决 信 令 面 掉话解 决 用 户 面 掉话解 决 异 常 掉 话YYYYNNNN图 3-3 呼叫跟踪分析流程 1. 获取单用户跟踪消息 单用户跟踪消息需要事先在 RNC上进行跟踪，才能记录相应的消息。根据 IMSI进行跟踪记录的消息用来分析掉话问题是足够的。 2. 获取掉话点信息 从单用户跟踪消息来看， 掉话的定义是 RNC主动发起了 RAB释放（消息名称为RANAP_RAB_RELEASE_REQ），或者 RNC主动发起 IU释放（消息名称为 RANAP_IU_RELEASE_REQ） 。前者对应为用户面掉话，后者对应为信令面 掉话。通过查找以上两条消息，就可以或者掉话点的时间，以及掉话前的信令消息，以便进一步进行分析。 3. 信令面掉话分析 信令面掉话表现为手机或者 RNC不能收到确认模式传送的信令，产生 SRB复位 ，导致连接释放。下行方向一般有这些消息手机不能收到而可能导致 SRB复位：安全模式过程，鉴权加密TD-SCDMA 网络优化 掉话问题分析 第 3 章 掉话分析流程和方法 3-9 过程，测量控制，激活集更新，物理信道重配置，传输信道重配置， 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. 拨测，重现问题 当已有的数据不足以定位掉话问题的时候，启动更详细的数据跟踪，最好的办法采用测试手机是在问题点进行拨测，重现问题，然后继续进行分析。 TD-SCDMA 网络优化 掉话问题分析 第 3 章 掉话分析流程和方法 3-10 3.4 用户投诉分析流程 了 解 用 户 投诉检 查 话 统 指标检 查 告 警检 查 C D L投 诉 问 题解 决拨 测 ， 重 现问 题YN图 3-4用户投诉分析流程 1. 了解用户投 诉 用户投诉发生的时候需要详细记录问题发生的时间，问题产生的地点，以及问题的具体现象。 2. 检查话统指标 通过分析用户投诉相关的话统指标，来进一步分析该投诉是某个用户特有的问题还是网络一般性的问题，对于一般性的问题，请参考话统指标的分析来进一步分析投诉。 3. 检查告警 根据投诉的时间，查看 CN， RNC或者投诉地点对应基站的告警，看这些告警是否会产生相应的掉话，如果存在这个告警，试着消除和解决这个告警。 4. 检查 CDL CDL记录了用户异常发生时候的信令，状态等信息，通过分析 CDL可以进一步了解投诉产生的原因。 5. 投诉点拨 测，重现问题 TD-SCDMA 网络优化 掉话问题分析 第 3 章 掉话分析流程和方法 3-11 对于话统分析，告警分析以及 CDL分析都无法解决的问题，需要通过到现场拨测的方法进行问题重新，拨测的时候数据记录的方法和路测方法相同，在某些场合，可能不适合记录手机侧信息，那么需要通过 RNC来尽量多的记录各种信息，特别需要记录收集上报的 C/I和RSCP信息，以排除覆盖问题导致的掉话。对于一些特别的地点，到现场拨测都不可能，那么需要通过用户的手机号码来获取 IMSI，然后在 RNC启动呼叫跟踪，以便进一步定位问题。 TD-SCDMA 网络优化 掉话问题分析 第 4 章 常见掉话原因分析 4-1 第 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信号）。 TD-SCDMA 网络优化 掉话问题分析 第 4 章 常见掉话原因分析 4-2 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，干扰时间超过 2 3s，就有可能造成掉话，需要重点解决。 下行的干扰通常是指导频污染 ，指覆盖地区存在 3个以上的小区满足切换条件，由于信号的波动常常出现激活集替换或者最优小区发生变化，通常当激活集综合质量不好（ P-CCPCH 的C/I都在 -3dB左右波动），容易出现切换失败导致 SRB复位，也可能出现 TRB复位。 上行的干扰增加了连 接模式的手机上行发射功率，从而产生过高的 BLER导致 SRB或者 TRBTD-SCDMA 网络优化 掉话问题分析 第 4 章 常见掉话原因分析 4-3 复位或者由于失步导致掉话。另外，在切换的时候，新建链路由于上行干扰问题导致链路不能同步，从而造成该小区的切换成功率低，或者造成切换失败而导致掉话。 通常在没有干扰的情况下，上下行是平衡的，也就是说掉话前上下行的发射功率都会接近最大值。但当干扰存在时，如果是下行的干扰，往往出现上行发射功率很小或者 BLER收敛的情况，但下行发射功率达到最大值同时也伴随着下行 BLER不收敛；对于上行干扰，会存在同样的表现，在实际分析可以通过这个方法来区分。 4.5 流程 交互失败 一些需要信令交互的流程，如 AMR 控制 、 UE 的状态迁移等，常常会由于信号的原因，手机支持方面的原因或者 RAN 设备和手机的配合问题，导致流程失败，最后导致掉话。还有一种特殊情况就是在流程的交互过程中，如 RB 建立， RB 重配置等流程中，切换的测量报告不能及时处理，导致信号变差而掉话。 这类问题需要针对特定的流程和手机进行分析，没有一般性的处理方法。 4.6 异常 在排除了以上的原因之后，其他的掉话一般需要怀疑设备的问题，需要通过查看设备的日志，告警等进一步来分析掉话原因。比如： NodeB 异常引起同步失败，导致的链 路不停增加和删除 ,手机不上报 1g 测量报告导致掉话 .这里需要重点注意的是测试手机异常死机引起的掉话问题，一般在拨测过程中容易出现这个问题，具体表现为路测记录的数据中有一段时间没有手机上报的信息。 4.7 调整措施 4.7.1 工程参数 工程参数的调整可以调整站点的位置、天线的高度、下倾角、天线的波瓣宽度、天线增益以及方向角等。 对于上行或下行覆盖问题导致的掉话，增加站点是最好的办法，同时可以考虑更改天线的高度、下倾角，也可以更换增益更高的天线或者增加塔放。 对于针尖和拐角效应，通过天线调整也是比较有效的解决办法，由于针尖效应和拐 角效应往往出现在街道拐弯的地方或者两条街道交界的地方，可以考虑通过天线的方向角和街道错开一定的角度的方式来调整，但同时需要注意原来街道路边商铺的覆盖不要有很大的影响。 对于导频干扰引起的覆盖问题，可以通过调整某一个天线的工程参数，使该天线在干扰位置成为主导小区；也可以通过调整其他几个天线参数，减小