CS域掉话分析
表 4.1-3 删除的邻区
优化效果：
更改邻区后，TRI135W－1的CS掉话率由3％左右下降到1.3%左右，如下图所示：
图 4.1-2 邻区优化后掉话率统计图
4.2 邻区优化-2（邻区漏配）
问题归属：
系统内邻小区漏配导致的掉话
22
第4章 案例分析
问题描述：
手机沿图中的红色箭头方向自南向北运动，主服务小区是位于下方扰码为74的小区，但是主服务小区质量已经非常差（Ec/Io为-20.72dB）。但是扰码为9的小区的Ec/Io为-8.75dB，导频质量非常好，但始终在检测集中，不能正常切换导致出现掉话现象。
图 4.2-1 掉话点分析
主要参数： 系统内邻区 排查流程：
上图显示，扰码号9的小区在服务小区（扰码74）质量非常差时仍然在检测集中，无法加入激活集。属于典型的邻区漏配情况。 解决手段：
邻区关系调整，增加扰码9小区为扰码74小区的邻区。 优化效果：
同样测试方案，主服务小区为SC74，SC9的小区已经在SC74的监测集中。当SC9的小区信号足够强时，UE从SC74小区正常切换到SC9小区。如下图所示
23
CS域掉话分析
图 4.2-2 添加邻区-SC9进入检测集
图 4.2-3 完成正常切换
4.3 扰码复用优化
问题归属：
扰码复用距离不足导致的掉话 问题描述：
从联通沿深南大道往华强北走，UE首先在联通大厦室外站的1、2扇区，扰码246、247，此时偶尔有扰码124上报1a，但因为不在检测集中，RNC没有加腿。
24
第4章 案例分析
后来加了350，联通大厦室外站第四扇区，并且马上用124替换了350，经查，350的邻区有124这个小区（香蜜湖东座酒店扇区2）。
再后来，246和247逐渐减弱，最后只剩124，并反复加了几次123，最后剩124，此时报1a加125，没有收到任何RNC下来的激活集更新请求，最后掉话。 主要参数： 系统内邻区，扰码 排查流程：
因为RNC信令没有保存下来，通过分析UE最后上报的测量报告，发现125的偏移与124和123相差很多，如下：
cellSynchronisationInfo {
modeSpecificInfo fdd : {
countC-SFN-Frame-difference {
countC-SFN-High 0, off 33 }, tm 6441 } },
modeSpecificInfo fdd : {
primaryCPICH-Info {
primaryScramblingCode 125 },
cpich-Ec-N0 35, cpich-RSCP 27 } }, {
cellSynchronisationInfo {
modeSpecificInfo fdd : {
25
CS域掉话分析
countC-SFN-Frame-difference {
countC-SFN-High 0, off 212 }, tm 37446 } },
modeSpecificInfo fdd : {
primaryCPICH-Info {
primaryScramblingCode 124 },
cpich-Ec-N0 22, cpich-RSCP 21 } }, {
cellSynchronisationInfo {
modeSpecificInfo fdd : {
countC-SFN-Frame-difference {
countC-SFN-High 0, off 212 }, tm 37958 } },
modeSpecificInfo fdd : {
primaryCPICH-Info {
primaryScramblingCode 123 },
cpich-Ec-N0 6, cpich-RSCP 13 } }
26