TDSCDMA掉话问题分析 优化指导手册新邮通信.docx
《TDSCDMA掉话问题分析 优化指导手册新邮通信.docx》由会员分享，可在线阅读，更多相关《TDSCDMA掉话问题分析 优化指导手册新邮通信.docx（24页珍藏版）》请在冰豆网上搜索。
TDSCDMA掉话问题分析优化指导手册新邮通信
TD-SCDMA
掉话问题分析
优化指导手册
TD-SCDMA
掉话问题分析
优化指导手册
产品类别：
□Postcom_R2000□Postcom_B2000□Postcom_B2100□Postcom_B2200
□Postcom_B1000□OMC-R□网络规划■网络优化
□其他
产品版本：
V0.1.0
文档编号：
XY/PD003/M
广州市新邮通信设备有限公司（新邮通信）为客户提供全方位的技术支持，用户可与当地的新邮通信办事处联系，也可直接与公司总部客服中心联系。
广州市新邮通信设备有限公司
地址：
广州市科学城光谱西路3号邮编：
510663
网址：
客户服务电话：
0086-20-61397330-810、811
客户服务邮箱：
newpostcom@
声明
广州市新邮通信设备有限公司
版权所有，保留一切权利。
本资料及其包含的所有内容为广州市新邮通信设备有限公司（新邮通信）所有，受中国法律及适用之国际公约中有关著作权法律的保护。
未经新邮通信书面授权，任何人不得以任何形式复制、传播、散布、改动或以其它方式使用本资料的部分或全部内容，违者将被依法追究责任。
由于产品版本升级或其它原因，本手册内容会不定期进行更新。
除非另有约定，本手册仅作为使用指导，本手册中的所有陈述、信息和建议不构成任何明示或暗示的担保。
前言
内容介绍
《TD-SCDMA网络优化掉话问题分析》介绍了TD-SCDMA网络优化中的掉话问题进行分析，包括掉话定义，分析流程和方法，常见掉话原因和典型掉话案例分析。
本文分5章。
●概述。
●掉话定义：
介绍路测和话统中掉话定义。
●掉话分析流程和方法:
详细介绍掉话分析的流程和分析方法。
●常见掉话原因分析：
介绍覆盖、邻区关系、切换、干扰等造成掉话的原因及分析的方法。
●典型掉话案例分析：
结合广州TD网络优化案例进行分析。
读者对象
本书适合下列人员阅读：
●参与网络优化的相关人员。
本书约定
通用格式约定
格式
意义
宋体
正文采用宋体表示。
黑体
除一级标题采用宋体加粗以外，其余各级标题均采用黑体。
楷体
警告、提示等内容一律用楷体，并且在内容前后增加线条与正文隔离。
命令行格式约定
格式
意义
粗体
命令行关键字（命令中保持不变、必须照输的部分）采用加粗字体表示。
斜体
命令行参数（命令中必须由实际值进行替代的部分）采用斜体表示。
[]
表示用“[]”括起来的部分在命令配置时是可选的。
{x|y|...}
表示从两个或多个选项中选取一个。
[x|y|...]
表示从两个或多个选项中选取一个或者不选。
{x|y|...}*
表示从两个或多个选项中选取多个，最少选取一个，最多选取所有选项。
[x|y|...]*
表示从两个或多个选项中选取多个或者不选。
!
由惊叹号“!
”开始的行表示为注释行。
图形界面格式约定
格式
意义
<>
带尖括号“<>”表示操作员从终端输入的信息。
[]
带方括号“[]”表示人机界面、菜单名、数据表和字段名等。
/
多级菜单用“/”隔开。
如[文件/新建/文件夹]多级菜单表示[文件]菜单下的[新建]子菜单下的[文件夹]菜单项。
键盘操作约定
格式
意义
加尖括号的宋体字符
表示键名或按钮名。
如、、、等分别表示回车、制表、退格、小写字母a。
<键1+键2>
表示在键盘上同时按下几个键。
如表示同时按下“Ctrl”、“Alt”、“A”这三个键。
<键1，键2>
表示先按第一键，释放，再按第二键。
如表示先按键，释放后，紧接着再按键。
鼠标操作约定
格式
意义
单击
快速按下并释放鼠标的一个按钮。
双击
连续两次快速按下并释放鼠标的一个按钮。
拖动
按住鼠标的一个按钮不放，移动鼠标。
各类标志
本书还采用各种醒目标志来表示在操作过程中应该特别注意的地方，这些标志的意义如下，正文中的各类警告、提示、说明等的内容一律采用楷体，并在内容前后加横线与正文分开如下：
说明：
说明、提示、窍门、思考：
对操作内容的描述进行必要的补充和说明。
注意：
小心、注意、警告、危险：
提醒操作中应注意的事项。
目 录
优化指导手册1-1
前言iii
内容介绍iii
读者对象iii
本书约定iii
目 录-1-
第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
3.3跟踪数据分析流程3-6
3.4用户投诉分析流程3-9
第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
图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-3
第1章概述
在网络建设及运营中，掉话率（calldroprate）是反映网络质量的重要指标之一；掉话问题也是日常网络优化面临的一个常见问题。
掉话问题对用户的负面影响最直接，因此掉话率是运营商最为关注的指标之一。
实际的网络中，影响掉话率的因素很多，包括硬件问题、干扰问题、覆盖问题、切换问题、参数问题等。
本文结合广州TD网络建设和优化的经验，对掉话的定义、分析流程和方法、原因分析等内容进行描述。
第2章掉话定义
2.1路测的掉话定义
从UE侧记录的空口信令上看，在通话过程（连接状态下）中，如果空口的消息，满足以下三个条件的任何一个：
1）收到任何的BCH消息（即系统消息）
2）收到RRCRelease消息且释放的原因值为NotNormal
3）收到CCDisconnect，CCReleaseComplete，CCRelease三条消息中的任何一条，而且释放的原因为NotNormalClearing或者NotNormal，Unspecified。
2.2话统指标中的掉话定义
广义的掉话率应该包含CN和UTRAN的掉话率，由于网优重点关注与UTRAN侧的掉话率指标，本文掉话率描述也重点关注UTRAN侧的KPI指标分析。
UTRAN侧相关指标就是RNC触发释放的各业务RAB个数。
主要包括两个方面：
（1）业务建立成功后，RNC向CN发送RABRELEASEREQUEST消息。
（2）业务建立成功后，RNC向CN发送IURELEASEREQUEST消息，其后收到CN发送的IURELEASECOMMAND。
从大的方面来讲，掉话分为两大类，信令面掉话和用户面掉话；从流程上看，信令面掉话是RNC发起了Iureleaserequest，用户面掉话是RNC主动发起RABreleaserequest。
需要说明的是RAN话统掉话的定义只从Iu接口的角度进行统计，统计了RNC主动发起的RABrelease请求次数和Iurelease请求次数。
而路测掉话定义主要从空口的消息和非接入层的消息结合原因值来进行定义的，两者不完全一致的。
比如说，对于同时进行主被叫通话，工具记录主叫的空口消息，如果被叫异常掉话，那么分析主叫的流程也会是一次掉话，但从话统上看，这次主叫是没有掉话指标记录的。
所以两者的定义是不完全一致的，在分析时要注意区分。
第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发送RABRELEASEREQUEST消息。
（2）业务建立成功后，RNC向CN发送IURELEASEREQUEST消息，其后收到CN发送的IURELEASECOMMAND。
信令面掉话主要是RNC发起了IuReleaseRequest。
分析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指派建立成功的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_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
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
RLFailure指标：
CELL_UPDT_RL_FAIL_CELL（下行失步）
IUB_RL_FAIL（上行失步）
RTWP，TCP指标：
RTWP均值、最大值
TCP均值、最大值
4.检查小区是否异常
如果小区以前KPI正常，可检查小区的告警，排除小区异常方面的原因。
5.分析掉话原因
设备问题：
按照2、3如果分析结果是传输、设备原因，则可归类为设备问题。
覆盖差：
按照2、3如果分析结果是空口原因，则可归类为覆盖差，无线环境变化块等原因。
切换导致的掉话：
HHO相关指标导致的掉话。
干扰导致的掉话：
分析RLFailure、RTWP，TCP相关指标，由于话统粒度粗，主要看整体情况，无法精确分析。
从话统详细分析掉话时，需按照掉话原因分类分析相关指标，必要时结合CDL分析。
6.通过路测重现问题
由于话统给出了趋势，并给出了可能的问题，具体问题的定位和分析还需要结合路测或者针对小区的CDL分析来进行。
对于问题小区，一般都需要安排针对小区进行路测，跟踪手机侧和RNC的信令流程进行分析，详细分析方法请参见路测数据分析流程。
3.3跟踪数据分析流程
跟踪数据分析包括单用户跟踪消息分析，通常情况下，单用户消息结合数据采集工具记录的UE侧数据，能够基本上定位一些掉话问题；对于更加复杂的问题，需要配合CDL和实时状态监控来综合分析。
也有一些商用手机的问题或者重点用户的问题，没有手机侧记录的消息，需要通过从单用户跟踪数据来分析和定位。
单用户跟踪除了记录单用户的信令消息（Iu，Iur，Iub，Uu），同时需要记录P-CCPCHRSCP、C/I性能跟踪，记录UE的发射功率，记录上行SIR，SIRTarget，记录上行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的切换命令（HANDOVERFROMUTRANCOMMAND），手机是否收到这些命令需要手机侧的跟踪消息来确认；上行方向有以下的消息可能导致SRB复位：
测量报告，激活集更新完成，物理信道重配置完成，传输信道重配置完成，RB重配置完成，同样需要RNC侧的跟踪消息来确认是否收到。
4.用户面掉话分析
用户面掉话主要是TRB复位，这种情况主要在PS业务上发生，voice和VP业务不会产生TRB复位。
一般可以通过确认掉话发生时的UE发射功率或者下行码发射功率情况来辅助确认。
当激活集中只有一条链路上，会由于RLfailure导致RNC发起IuRelease，RLfailure是上行失步引起的，但是下行失步会使UE关闭发射机，接着就造成上行失步，在定位掉话是上行引起释放还是下行引起的时候，需要分析掉话前手机的发射功率和实时状态监控的下行的码发射功率来区分。
下行覆盖差、下行干扰强或者上行干扰都会导致TRB复位。
有时候数据业务由于重传次数设置不合理，在切换来不及的情况下，TRB比SRB先产生复位，在分析时要注意区分。
5.异常掉话分析
异常掉话一般指掉话无法从覆盖、干扰等方面找到原因，也无法根据前面介绍的用户面掉话或者信令面掉话原因来解释，这种掉话往往是设备的异常或者是手机的异常导致的。
比如由于传输突然中断导致的掉话、基站设备异常导致的掉话、手机突然死机等都会导致异常掉话。
对于传输异常一般通过分析CDL或者参看告警来进一步分析；对于基站设备异常可以通过查询基站状态来确认，对于手机异常，需要通过分析手机记录的数据来定位。
6.拨测，重现问题
当已有的数据不足以定位掉话问题的时候，启动更详细的数据跟踪，最好的办法采用测试手机是在问题点进行拨测，重现问题，然后继续进行分析。
3.4用户投诉分析流程
图34用户投诉分析流程
1.了解用户投诉
用户投诉发生的时候需要详细记录问题发生的时间，问题产生的地点，以及问题的具体现象。
2.检查话统指标
通过分析用户投诉相关的话统指标，来进一步分析该投诉是某个用户特有的问题还是网络一般性的问题，对于一般性的问题，请参考话统指标的分析来进一步分析投诉。
3.检查告警
根据投诉的时间，查看CN，RNC或者投诉地点对应基站的告警，看这些告警是否会产生相应的掉话，如果存在这个告警，试着消除和解决这个告警。
4.检查CDL
CDL记录了用户异常发生时候的信令，状态等信息，通过分析CDL可以进一步了解投诉产生的原因。
5.投诉点拨测，重现问题
对于话统分析，告警分析以及CDL分析都无法解决的问题，需要通过到现场拨测的方法进行问题重新，拨测的时候数据记录的方法和路测方法相同，在某些场合，可能不适合记录手机侧信息，那么需要通过RNC来尽量多的记录各种信息，特别需要记录收集上报的C/I和RSCP信息，以排除覆盖问题导致的掉话。
对于一些特别的地点，到现场拨测都不可能，那么需要通过用户的手机号码来获取IMSI，然后在RNC启动呼叫跟踪，以便进一步定位问题。
第4章常见掉话原因分析
4.1覆盖差
TD网络覆盖指标主要是P-CCPCH的RSCP、C/I。
通常所说的覆盖差，是指RSCP小于－100dBm。
对覆盖差问题进行分析是，通常要考虑上行覆盖和下行覆盖。
上行覆盖差还是下行覆盖差的问题需要通过掉话前上行或者下行的专用信道功率来确认，需要采用以下的方法来确认：
如果掉话前的上行发射功率达到最大值，并且上行的BLER也很差或者从RNC记录的单用户跟踪上看到NodeB上报RLfailure，基
升级会员 