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消息。
发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，10. UE发RRC_RB_REL_CMP消息给RNC，业务RB释放完成11. RNC发RANAP_RAB_ASSIGNMENT_RESP消息给CN，RAB释放完成第二节空中接口掉话定义空中接口掉话定义在通话过程中，如果空中接口信息满足下面三个条件中的任何一条，可以判断为掉话：1.收到任何的BCH消息（即系统消息）2.收到RRC Release消息（原因为非正常释放Not normal）3.收到CC Disconnect，CC Release Complete，CC Release三条消息中的任何一条，而且释放的原因为Not Normal Clearing或者Not Normal，Unspecified。
从RNC记录的信令上看，如果在Iu接口上看到了RNC 发向CN的消息为IuRelease Request或者RNC发给CN的消息为RAB Release Request消息，此时定义为异常掉话。
第三节掉话话统指标定义－CS通过统计RNC触发的RAB 释放个数，统计RAB 建立个数，进而得到掉话率。
根据测量对象的不同，掉话率可以分为面向RNC 和面向小区的掉话率，分别考察整个RNC 和单个小区的掉话情况。
面向RNC 的CS掉话率公式：(RNC_CS_RAB_REL_CONV_TRIG_BY_RNC+RNC_CS_RAB_REL_STR_TRIG_BY_RNC)/(CS_RAB_ SETUP_SUCC_CONV+CS_RAB_SETUP_SUCC_STR)*100%测量点：CS会话类(流类）业务建立成功后，RNC向CN CS发送IU RELEASE REQUEST消息，原因不是“Release due to UE generated signalling connection release”。
面向RNC 的RNC 触发CS RAB 释放原因统计话统指标定义－CS掉话统计面向小区的CS掉话率公式：(RNC_CS_RAB_REL_CONV_CELL_TRIG_BY_RNC+RNC_CS_RAB_REL_STR_CELL_TRIG_BY_RNC )/(CS_RAB_SETUP_SUCC_CONV_CELL +CS_RAB_SETUP_SUCC_STR_CELL )*100% 测量点：CS会话类(流类）业务建立成功后，RNC向CN CS发送IU RELEASE REQUEST消息，原因不是“Release due to UE generated signalling connection release”。
面向小区的RNC 触发CS RAB 释放原因统计话统指标定义－CS掉话统计CS掉话统计（面向业务）：AMR语音与VP掉话统计：AMR语音业务：面向RNC的AMR语音掉话率= RNC_CS_RAB_REL_AMR_TRIG_BY_RNC / CS_RAB_SETUP_SUCC_CONV_0_32 * 100%面向小区的AMR语音掉话率= RNC_AMR_RAB_REL_CELL_TRIG_BY_RNC / CS_RAB_SETUP_SUCC_AMR_CELL * 100%VP业务：面向RNC 的VP掉话率=RNC_CS_RAB_REL_CONV_64K_TRIG_BY_RNC / CS_RAB_SETUP_SUCC_CONV_32_64 * 100%面向小区的VP掉话率= RNC_CS_CONV_64K_RAB_REL_CELL_TRIG_BY_RNC/ CS_RAB_SETUP_SUCC_CONV_64K_CELL * 100%第四节掉话话统指标定义－PS面向RNC 的PS掉话率公式：(RNC_PS_RAB_REL_CONV_TRIG_BY_RNC+RNC_PS_RAB_REL_STR_TRIG_BY_RNC+RNC_PS_RAB_REL_INTER_TRIG_BY_RNC+RNC_PS_RAB_REL_BKG_TRIG_BY_RNC )/(PS_RAB_SETUP_SUCC_CONV +PS_RAB_SETUP_SUCC_STR +PS_RAB_SETUP_SUCC_INTER +PS_RAB_SETUP_SUCC_BKG )*100% 测量点：PS会话类(流类，交互类、背景类)业务建立成功后，RNC向CN PS发送RAB RELEASE REQUEST消息。
PS会话类(流类，交互类、背景类)业务建立成功后，RNC向CN PS发送IU RELEASE REQUEST 消息，释放原因不是“UE Inactivity”、“Successful Relocation”和“Release due to UE generated signalling connection release”。
面向RNC 的RNC 触发PS RAB 释放原因统计话统指标定义－PS掉话统计面向小区的PS掉话率公式：(RNC_PS_RAB_REL_CONV_CELL_TRIG_BY_RNC+RNC_PS_RAB_REL_STR_CELL_TRIG_BY_RNC +RNC_PS_RAB_REL_INTER_CELL_TRIG_BY_RNC +RNC_PS_RAB_REL_BKG_CELL_TRIG_BY_RNC )/(PS_RAB_SETUP_SUCC_CONV_CELL +PS_RAB_SETUP_SUCC_STR_CELL +PS_RAB_SETUP_SUCC_INTER_CELL +PS_RAB_SETUP_SUCC_BKG_CELL )*100%测量点：PS会话类(流类，交互类、背景类)业务建立成功后，RNC向CN PS发送IU RELEASE REQUEST 消息，释放原因不是“UE Inactivity”、“Successful Relocation”和“Release due to UE generated signalling connection release”。
话统指标定义类别总结：话统指标对掉话的定义分为：CS掉话:面向对象统计：RNC、小区面向业务统计：AMR 语音、VP业务PS掉话：面向对象统计:RNC、小区第二章常见掉话原因与掉话处理流程第一节常见掉话原因邻区漏配一般来讲，初期优化过程掉话占大多数是由于邻区漏配导致的。
对于同频邻区，通常采用以下的办法来确认是否为同频邻区漏配：方法一：观察掉话前UE记录的活动集EcIo信息和Scanner记录的Best Server EcIo信息，如果UE记录的EcIo很差，而Scanner记录的Best Server EcIo很好；同时检查Scanner记录Best Server扰码是否出现在掉话前最近出现的同频测量控制中，如果测量控制中没有扰码，那么可以确认是邻区漏配。
方法二：如果掉话后UE马上重新接入，如果UE重新接入的小区扰码和掉话时的扰码不一致，也可以怀疑是邻区漏配问题，可以通过测量控制进一步进行确认。
邻区漏配导致的掉话也包括异频邻区漏配和异系统邻区漏配。
覆盖问题通常所说的覆盖差，主要是指RSCP不和EcIo都很差。
覆盖的问题需要通过掉话前上行或者下行的专用信道功率来确认，需要采用以下的方法来确认：如果掉话前的上行发射功率达到最大值，并且上行的BLER也很差或者从RNC记录的单用户跟踪上看到NodeB上报RL failure，基本可以认为上行覆盖差导致的掉话；如果掉话前，下行发射功率达到最大值，并且下行的BLER很差，基本可以认为是下行覆盖不行导致的掉话。