TDSCDMA优化常见问题及解决方法.docx

TDSCDMA优化常见问题及解决方法.docx

《TDSCDMA优化常见问题及解决方法.docx》由会员分享，可在线阅读，更多相关《TDSCDMA优化常见问题及解决方法.docx（16页珍藏版）》请在冰豆网上搜索。

TDSCDMA优化常见问题及解决方法

目录

优化2

覆盖优化2

1.邻区缺失引起的弱覆盖2

2.参数设置不合理引起的弱覆盖-功率参数设置不合理2

Forpersonaluseonlyinstudyandresearch;notforcommercialuse

3.参数设置不合理引起的弱覆盖-切换参数设置不合理3

4.缺少基站引起的弱覆盖3

5.越区覆盖3

Forpersonaluseonlyinstudyandresearch;notforcommercialuse

6.背向覆盖3

7.天馈实际安装与规划不一致引起的覆盖问题-下倾角安装不合适4

8.天馈实际安装与规划不一致引起的覆盖问题-天馈接反4

Forpersonaluseonlyinstudyandresearch;notforcommercialuse

9.基站GPS故障引起的弱覆盖4

切换优化5

1.切换参数设置问题5

2.漏配邻区导致不切换5

3.过覆盖导致切换失败6

4.基站和网络不同步切换失败6

接入优化7

1.覆盖问题导致未接通7

2.下行信号干扰导致未接通8

3.核心网问题导致未接通9

掉话优化9

1.弱覆盖导致掉话9

2.切换掉话案例分析10

3.干扰导致掉话案例分析10

优化

覆盖优化

对于不同的覆盖问题，有着不同的优化方法，以下是常见覆盖问题

的优化方法：

（1）对于由于邻区缺失引起的弱覆盖，应添加合理的邻区

（2）对于由于参数设置不合理引起的弱覆盖（包括小区功率参数以及切换、重

选参数），根据具体情况调整相关参数

（3）对于由于缺少基站的弱覆盖，应通过在合适点新增基站以提升覆盖

（4）对于由于越区覆盖导致的覆盖问题，应通过调整问题小区天馈的方位角/

俯仰角或者降低小区发射功率解决，但是降低小区发射功率将影响小区覆盖范

围内所有区域的覆盖情况，不建议此种方法解决越区

（5）对于背向覆盖，大部分由于建筑物反射导致，可以通过合理调整方位角/

下倾角来规避。

另外，还有部分确实是由于天线背向信号很强，建议更换天线

或者加屏蔽抑制背向信号。

（6）对于天馈安装与规划不一致（包括同一基站小区间天馈接反或者天馈下倾

角/方位角不合适等）引起的覆盖问题，应对天馈进行调整

（7）对于由于基站GPS故障引起的弱覆盖，应及时上站更换故障模块

1.邻区缺失引起的弱覆盖

问题描述：

在上海新翔路测试中，UE驻留在年丰-1（频点：

10088码字81），RSCP-95dbm左右，问题路段出现弱覆盖直至UE脱网。

问题分析：

分析扫频数据，发现较强信号翔方-3（频点：

10120码字：

40）检查数据库中年丰-1的邻区关系，发现年丰-1未配置翔方-3之间的邻区关系。

解决措施：

添加年丰-1与翔方-3之间的邻区关系。

处理效果：

添加邻区后由于能够顺利进行小区重选，弱覆盖问题得到较好解决。

2.参数设置不合理引起的弱覆盖-功率参数设置不合理

问题描述：

在上海祁连山路测试中，覆盖较弱，此时UE驻留在全新-1（CPI：

120，频点：

10054），在该问题路段信号很弱，PCCPCH_RSCP在-95dBm以下。

该路段距离全新基站较近，应为全新-1主覆盖。

问题分析：

核查数据库，发现全新-1小区功率参数设置不合理，DwPCH、PCCPCH功率设置偏小（254，即25.4dbm），主要是由于该路段的无线环境与规划仿真时的情况不同导致规划数据出现偏差。

解决措施：

提升全新-1的DwPCH与PCCPCH的功率以提高覆盖。

处理效果：

提升全新-1的功率后问题路段覆盖得到明显提升。

3.参数设置不合理引起的弱覆盖-切换参数设置不合理

问题描述：

在上海大名路测试中，覆盖较弱，此时UE占用较近的圆明园-1（频点：

10054码字：

120），但随着UE的移动，PCCPCHRSCP逐渐衰减到－95dBm以下，仍未触发切换。

问题分析：

核查数据库切换参数，发现圆明园-1小区异频切换门限参数中本小区绝对导频门限强度参数设置不合理（30，即-86dbm），建议调整该门限参数。

解决措施：

将上述参数由30->70（即从-86dBm调整到-46dBm）。

处理效果：

修改切换门限参数后切换顺畅，弱覆盖问题得到很好解决

4.缺少基站引起的弱覆盖

问题描述：

在对上海浦东大道的扫频测试中，位于罗山路、居家桥路之间路段

弱覆盖，UE脱网，PCCPCH_RSCP、PCCPCH_C/I都很差，严重影响覆盖以及网络商用之后的用户感受。

问题分析：

从上图中可以看出，问题区域距离周围基站都比较远，加上建筑物

等的遮挡没有小区能在该区域形成良好覆盖，从大唐移动NPS规划工具的PCCPCH_RSCP覆盖的仿真图中可以清楚的看到这一点：

在上海移动TD-SCDMA网络规划中本有栖山基站（栖山路1128号西山中学）对该区域进行覆盖，但是由于种种原因没有开通。

解决措施：

与业主进行协调或者在附近区域另选站点以增强该路段覆盖。

处理效果：

相信相关基站开通后弱覆盖问题将得到很好解决。

5.越区覆盖

问题描述：

在对上海延安路高架测试中，当测试车辆从西到东行驶到延安

高架位于乌鲁木齐路、华山路之间路段时，由于延镇-2（频点：

10104码

字：

63）越区与愚园-2（频点：

10104码字：

34）形成干扰造成虽然PCCPCH_RSCP良好但是PCCPCH_C/I很差。

问题分析：

由于实际无线环境比较复杂，扩频码不能完全正交，导致虽然

上述两个小区的码字相关性不大，仍出现比较强的干扰。

解决措施：

将延镇-2的机械下倾角6°->9°。

处理效果：

调整延镇-2天线后复测，原来干扰问题得到较好解决。

6.背向覆盖

问题描述：

上海测试中，车辆由天目西路入口进入高架，UE占用中投-3（频点：

10070码字：

108）通话，此时下行PCCPCHRSCP较好，但C/I却达到－5db以下，通话质量较差，最后出现主叫掉话。

问题分析：

分析测试数据，在该处梅丰-3（频点：

10070码字：

49）对中投-3扇区形成干扰，导致C/I较差，最终出现掉话。

实际勘察梅丰-3天线状况，发现其正对一玻璃幕墙建筑，导致该小区反向覆盖较严重，因此建议调整其天线方位角规避该问题。

解决措施：

将梅丰-3（频点：

10070码字：

49）方位角由240°->210°。

处理效果：

对原掉话区域进行复测，测试过程中未出现掉话，原问题段的C/I值

一直正常。

且在该路段，梅丰-3（频点：

10070码字：

49）覆盖已经较弱。

7.天馈实际安装与规划不一致引起的覆盖问题-下倾角安装不合适

问题描述：

上海测试中，在交通路由西向东测试，当行驶到交通西路路口附近时，UE占用中骊3扇区（CPI：

68，UARFCN：

10070）通话，PCCPCH，RSCP在－95dBm以下。

问题分析：

分析测试数据结合实际覆盖情况，建议调整闸中-3（频点：

10070码字：

90）的机械下倾角：

5°->2°。

解决措施：

将闸中-3（频点：

10070码字：

90）的机械下倾角：

5°->2°。

处理效果：

调整后，对交通路交通西路路口附近进行了复测，测试数据显示，调整后该路段覆盖得到加强，PCCPCHRSCP接收电平在－95dBm以上，能够满足正常通话。

8.天馈实际安装与规划不一致引起的覆盖问题-天馈接反

问题描述：

上海测试中，在对中打基站进行单站测试过程时，用大唐移动span

analysist工具的单小区覆盖分析功能分析中打-2、中打-3的PCCPCH_RSCP覆盖情况，发现中打-2、中打-3两个小区覆盖范围与规划不符（规划中中打3个小区的方位角依次为0，120，240）：

问题分析：

从上面的单小区覆盖图中可以明显看出，中打-2、中打-3小区的实际覆盖范围与规划不符：

规划中由中打-2覆盖的区域现在由中打-3覆盖，规划中由中打-3覆盖的区域现在由中打-2覆盖。

在这种情况下，必然导致按照规划配置的邻区关系存在错误以及与周围基站形成严重的干扰，影响网络性能。

解决措施：

按照规划调整中打-2、中打-3的方位角。

处理效果：

对上述小区天馈进行整改后，覆盖达到预期效果。

9.基站GPS故障引起的弱覆盖

问题描述：

在上海逸仙路高架测试过程中，当测试车辆行驶到长逸基站附时，扫频仪收到长逸-2、长逸-3频点：

10104码字：

119；频点：

10120码字：

81）信号很强但是UE显示邻区列表中这两个小区信号很弱，在-110dbm左右；当经过小区初搜驻留在该站小区信号后，解码其它基站邻区信号强度均在-110dbm以下。

这与与相关小区实际信号强度偏差很差。

问题分析：

仔细分析上述测试中出现的现象，发现如下规律：

驻留在长逸基站小区则UE邻区中其它基站小区信号显示与实际情况差别很大；驻留在其它基站小区后则UE列表中长逸基站小区信号显示与实际情况差别很大，这表明长逸基站与其它基站不能良好同步，造成UE在测量时出现偏差，怀疑长逸基站GPS相关模块存在故障，经RNC机房核实长逸基站GPS果然存在告警，处于holdover态。

解决措施：

更换相关故障模块。

处理效果：

故障模块更换后该基站小区与其它基站小区顺利重选、切换，由于该基站失步引起的UE测量失真问题得到很好解决。

切换优化

1.切换参数设置问题

问题分析：

从路测log数据上分析，在掉话前UE从繁华路进入光明北路，从路测图中回放反映出，UE由华海大厦1小区切换到电子公司1小区。

右图所示：

当UE切换到电子公司1小区后继续往前移动，在距离电子公司基站670米、离汀沙基站160米、离富华花园基站230米处，已经满足切换条件，但UE依旧占用电子公司1小区。

如下图，电子公司1小区RSCP比较差了，但是仍然不和强邻小区切换。

UE由光明北路进入到桥兴大道后，UE依旧占用电子公司1小区，且此时电子公司1小区信号非常差了。

从右上图可以看出明显没有切换：

从信令上来分析，UE一直没有发起handover－star，只是发出测量报告一直持续到dropcall

从前面几个服务小区和邻小区信息表，以及从RNC中查看电子公司、富华花园、汀沙等基站的邻小区列表数据，电子公司、富华花园、汀沙等基站的相邻关系并没有漏配。

而电子公司1小区邻区是完整的。

而从RNC中查看电子公司、富华花园、汀沙等基站的小区算法配置，发现HC算法参数中电子公司1的“TDD系统内切换的算法开关”属性值为“关闭”。

而一般该属性值应为“打开”。

解决措施：

修改TDD系统内切换参数开关，由关闭改为打开设置。

处理效果：

完成参数修改后，效果明显，切换顺利进行：

2.漏配邻区导致不切换

问题描述：

在广州RNC17集成优化测试中，UE在西环路的解放西路路口到禹山西路路口，有明显的掉话路段。

从邻小区表和显示其他功率指标分析没有满足切

换邻小区存在。

掉话后再次建立连接时，UE占用世纪城3小区，属正常情况，如

问题分析：

查看路测图，在解放西路路口UE占用西城3小区，此时UE距离最近的基站是世纪城基站，而服务小区和邻小区信息表并无世纪城1、3小区，同时东城2、邻小区5属无效小区。

解决办法：

通过增补邻区关系，广州世纪城第二三小区和西城第一小区互做邻区。

处理效果：

经过添加双向邻区后进行了复测，问题解决。

3.过覆盖导致切换失败

问题描述：

广州测试中，UE在西环路的康裕北园基站到禹山西路路口信号正常，但从禹山西路路口沿着西环路往前，有明显的弱信号150米路段。

从span测试log邻小区表分析榄山2小区显示没有和沙头新村2做邻区为此，需要下压榄

山2小区天线，解决榄山2小区过覆盖问题。

从左上图中，发现存在榄山2小区与康裕北园2小区的邻区关系。

当UE再往前行进，由于康裕北园2小区是正对西环

路覆盖，且没有明显的阻挡物，导致UE切换到康裕北园2小区，因此形成了康裕北园2小区过覆盖。

同时，康裕北园2小区没有建立与沙头新村2小区的邻区关系，基于这种情况，榄山又重新切换回康裕北园2小区上。

解决办法：

在下压榄山2小区天线的下倾角度后，考虑到康裕北园2小区是正对西环路覆盖容易形成峡谷效应，为此需下压康裕北园2小区天线的下倾角度，同时增补康裕北园2小区与沙头新村2小区的邻区关系。

这样，可以更好地完成由康裕北园基站往南直走的西环路时各小区之间切换接续。

完成以调整后再次路测，结果有明显改善。

处理效果：

问题解决措施实施后再次复测，问题解决，从下图可以看出切换正

常，覆盖良好。

4.基站和网络不同步切换失败

问题描述：

于某日广州对RNC17莲湖村基站区域采用span测试软件packer测试终

端进行长呼测试时候出现两次掉话，掉话地点在从水电公司基站往横江基站移动过程中，第一次掉话后起呼在莲湖村基站第三小区cellparameterID为88上面。

掉话地点从掉话时候PCCPCHRSCP值来看非常差。

问题分析：

从路测log数据上分析，在掉话后起呼在莲湖村第三小区上，初步怀疑为切换掉话，水电公司第二小区和莲湖村基站不能切换。

从无线方向上考虑为有以下几种可能：

1、水电公司第三小区没有和莲湖村基站做邻集，缺邻集数据导致不能切换。

2、水电公司和莲湖村有邻集关系，但是基站不同步导致不能切换掉话

3、基站其他硬件问题

分析第一种情况（水电公司没有和莲湖村做邻集关系）如下：

从log分析，在水电公司为服务小区时，莲湖村没有进入到系统下发的邻集表中，怀疑水电公司第二小区邻集配置表中没有莲湖村基站。

检查OMCR数据，发现确实没有添加莲湖村为邻集关系。

从第一个问题反映水电公司第二小区缺邻集所以不能和莲湖村基站切换，最后RSCP值太差掉话。

但是起呼在莲湖村后还是不能和横江3421基站切换又导致第二个掉话，需要进一步分析。

从空口信令来看，可以发现莲湖村第三小区和横江第二小区做了邻集关系，应该不会是缺邻集掉线。

怀疑莲湖村基站存在第二种原因可能为和网络不同步造成不能和

周围基站切换。

上图为UE主邻集信息，发现当服务小区为莲湖村时其他邻区小区RSCP值全部为－116dBm，当基站和网络不同步的时候就会出现这种典型状态，UE不能解调其它小区信号。

怀疑莲湖村基站GPS出现故障导致不能和网络同步，咨询机房RNC工程师，机房通过检测发现GPS存在故障。

解决措施：

水电公司第二小区增添莲湖村基站3个小区为邻集关系，现场检查

GPS，更换问题的GPS。

处理效果：

经过更换GPS后，对掉话区域进行复测，切换正常。

如下图，切换正

常覆盖恢复正常。

接入优化

业务建立过程中，主要有如下几个主要过程的全部或者部分：

RRC建立过程；

鉴权过程；

加密过程；

业务请求与建立过程（初始直传与自传消息交互）；

RB建立过程；

被叫的寻呼响应过程；

GPRS附着过程；

GPRSPDP激活过程；

因此，接入问题的发现与定位，往往都是以路测事件的分析入手的。

接入优化中，以事件进行问题分类比较容易进行。

另外，接入有些问题可能是核心网或者参数设置上的问题，所以应该同时结合CDL进行分析。

1.覆盖问题导致未接通

问题描述：

这是上海TD-SCDMA网络建设初期，在沪太路的日常测试中，发起呼叫时，整体上接通率一般，经常会发生各种各样形式的呼叫失败。

例如，起呼阶段RRC连接建立失败；RB分配过程中，UE没有收到RB建立消息；呼叫过程中，UE没有收到PROGRESS消息；呼叫固定电话过程中，没有收到ALERTING消息等等问题。

问题分析：

汇总多次测试结果，分析了问题发生路段上各主要相关小区发起呼叫的综合

结果，得出：

发生问题的小区并不固定，而且整体上没有发生接入问题的比例占多数。

尽管故障表现多种多样，结合测试日志中故障发生前后PCCPCH的RSCP分析，电平值在-95dBm附近。

PCCPCH的RSCP值是衡量小区覆盖状况的重要标志。

根据目前的标准，PCCPCH的RSCP值低于－95dBm，则认为存在覆盖问题。

但对于PCCPCH的RSCP值高于-95dBm的地段，如果测试中存在较多接入问题的时候，仍然需要通过调整手段改善覆盖，来解决呼叫接入方面的问题。

考虑到处在网络建设初期，部分规划中的基站仍然处在建设中，规划设计的覆盖要求还没有达到。

本案例中，由于PCCPCH的RSCP处在-95dBm的临界水平，改善覆盖状况，能够使得接通率得到改善。

解决措施：

针对路测路段的当前覆盖状况，将闸中1（扰码57）的天线方位角由原来的0度调整至340度。

加强该路段的主力覆盖，右边是天馈调整前后

处理效果：

天馈调整结束后，问题路段的覆盖效果得到改善。

PCCPCH的RSCP最小值从-95dBm提升到了-89dBm。

多次的验证测试中，呼叫故障的发生几率显著降低，接入问题得到解决。

2.下行信号干扰导致未接通

问题描述：

上海TD-SCDMA网络在日常测试中，发起呼叫时，经常出现呼叫失败的问题。

相关小区的定点测试没有明显异常，路段测试中，故障的出现没有明显规律。

问题分析：

由于定点的基站拨打测试都未发现明显的异常，结合告警信息的收

集，可以确认，接入故障的发生与基站的硬件设备无关。

在日常测试中，常常还连接扫频仪，进行同步测试。

扫频仪的测试结果不受邻区关系的限制，可以完整地得到最佳小区的分布图，

从连线图可以看到杰隆-3小区有一个较小的孤立覆盖区域，上图的问题路段

正常情况下，应该由中医大基站作为主服务小区，但是该基站仍然处于施工状态还无法投入使用。

使得李白-3小区的主瓣方向，出现了杰隆-3的较强信号。

这两个小区的主载频频点相同，扰码分别为84和85。

即下行同步码相同。

同频同下行同步码的情况，是TD-SCDMA在进行频率码字规划中必须要避免的重要原则。

这也是在解决接入失败问题的时候，首先要处理的问题。

解决措施：

针对网络的实际情况，有如下几个方面的考虑：

一方面，可以等待中医大基站完成施工和开通，使得问题路段的覆盖发生变化，从而可以消除杰隆-3孤立的最佳小区覆盖区域，但是接入故障的发生几率会大大下降，但是隐患仍然存在；另外一个方面，可以通过调整杰隆-3的天线俯仰角度和天线方位角度，通过调整覆盖，可以完全解决问题，但由于杰隆-3小区的覆盖发生了变化，有可能带来其他地方新的覆盖问题，这需要进行整体上的利弊权衡；

就此案例而言，该路段为密集城区，由于城市繁华、高楼林立，实际的无线状况非常复杂，天馈调整很难做到精确。

同时从码字规划的角度考虑，下行同步码的复用距离过小，码字规划上考虑欠妥当，需要进行修改。

一旦重新规划码字，避免同频同下行同步码的发生，接入问题的发生也能够得到下降。

处理效果：

修改李白-3的码字，以避免与杰隆-3同一个扰码组。

然后进行复测验证。

经过多次测试，发现接入问题的发生几率下降，网络服务状况得到改善。

从而确定，同频同下行同步的出现，是接入问题发生的主要因素。

由于码字的规划，需要全局考虑，调整码字的最后方案，还需要网络规划和设计

的部门进行全局考虑，并最后确认。

3.核心网问题导致未接通

问题描述：

上海TD-SCDMA网络建设初期，某日的常规测试中，集中出现呼叫失败。

但是在下一个时间段，又连续全部呼叫成功。

问题分析：

首先，回放测试数据，可以看到，发生接入失败的时候，全部都是在UE发起CMservicerequest请求消息后，收到网络侧下发的CMservicereject消息，随后RRC连接释放，呼叫失败。

CMservicereject消息中携带的拒绝原因为：

“IMSIunknowninVLR”。

然后，确认测试区域都在同一个RNC下，这样可以确认问题发生在同一个MSC下。

由于同时存在连续呼叫成功的时间，而且CMservicereject消息是CN发出，被RNC透传到空口的。

因此，需要核心网侧对特定的IU口进行核查。

解决措施：

将测试情况完整提交给核心网，并且指明特定的RNC，协助核心网侧

进行核查。

处理效果：

通过核心网做长时间电路监测，发现由于传输设备工作不稳定，造成核心网部分电路在一定时间内个别电路存在异常，导致电路分配过程出现失败的故障。

由于传输设备故障的发生比较随机，异常时间也较短暂，该问题较为隐蔽。

更换相关传输设备后，长时间电路检测未再发现异常。

现场的拨打测试也未再出现CMserviceREJECT消息。

一个比较隐蔽的问题及时得到排除。

掉话优化

掉话从原因来分可以分为以下四大类

1）弱覆盖导致掉话；

2）切换问题导致掉话；

3）干扰导致掉话；

4）核心网络异常拆链导致掉话；

5）其他问题；

1.弱覆盖导致掉话

问题描述：

在对广州主要干道进行优化，测试发现广州土华立交至广州御景湾御江路段出现弱覆盖，信号较差，导致掉话。

问题分析：

从上面图清楚显示发现存在弱覆盖区域，此区域是由土华立交基站进行覆盖，检查土华立交基站状态显示正常，在确认基站正常运行前提下再检查基站天线配置信息。

土华立交基站高度40米，天线方位角40度，下倾角10度，在这种配置下面可以看到天线主波瓣未对准主要干道，初步可以断定为天线角度配置问题导致弱覆盖掉话，为了进一步确定问题原因，检查周围环境是否存在阻挡情况，通过查看三维地图检查周围没有高大建筑存在。

根据华南快速主要干道走向，需要将土华立交基站主波瓣方向调整至180度。

解决措施：

调整土华立交基站天线角度，方位角由40度调整至180度，下倾角由

10度调整至5度。

处理效果：

完成参数修改后，效果明显，PCCPCHRSCP值约为－80dBm左右，

2.切换掉话案例分析

问题描述：

在番禺RNC17测试网络发生一次掉话，掉话时候PCCPCHRSCP值非常

差，掉话后PCCPCHRSCP非常好，从UE接受功率方面初步断定为切换掉话，

问题分析：

当测试从从竹山往石岗东基站方向行驶时，竹山2小区一直作为主服

务小区，随着路测车不断前行，竹山2小区PCCPCH_RSCP不断降低，临小区RSCP

情况同样比较恶劣，最终产生掉话事件，掉话前手机达到最大发射功率，掉话前主服务小区LAI为460742256。

从信令发现，小区掉话前，在频繁试图进行切换，但未有可撑切换邻小区，最终由于物理信道重配置未完成，导致切换失败，造成掉话。

手机在掉话后，UE重新起呼，此时发现主服务小区LAI变为460742257，手机接入RNC18中的傍江基站，经检查发现傍江基站同RNC17中的竹山基站2小区未配置邻区关系。

从下图也可以看出竹山第二小区没有进入傍江第三小区邻小区表里面，具体如右上图所示：

第一次掉话后起呼在RNC18基站上，但是向RNC17区域行进时，发生了第二次掉话，原因为傍江和石岗东基

站不属于相同的RNC，傍江基站三小区没有和石岗东一小区作邻区关系，无法实行切换，造成第二次掉话。

掉话前扫频仪数据如右下图：

从扫频仪接受到信号来分析，掉话区域覆盖良好，非弱覆盖掉话，也可以验证为切换掉话。

解决办法：

由于该路段处于RNC边缘，故信号较凌乱，且RNC间切换数据未配置完成，为解决切换问题，建议采取以下措施：

1）RNC17中的竹山基站1小区、竹山3小区同RNC18中的旧水坑2小区、旧水坑综合市场2小区、傍江3小区两两互作邻区配置。

2）RNC17中的石岗东基站1小区同RNC18中的傍江3小区、傍江2小区互作邻区配置。

3）RNC17中的竹山基站2小区同石岗东基站1小区互作邻区配置。

处理效果：

经过添加双向邻区后进行了复测，问题解决。

3.干扰导致掉话案例分析

问题描述：

对广州RNC16簇39进行长呼测试时候出现两次掉话，掉话地点在从南

浦海滨花园基站往碧桂圆基站移动过程中

问题分析：

从路测log数据上分析，两次掉话都是发生在其他基站往碧桂圆第一小区切换时候，第一次掉话切换还未完成就发生掉话，