网络优化典型案例分析

网络优化典型案例分析

网络优化案例

案例

1：关于邻小区列表设置的问题

【现象描述】

手机在通话过程中可以成功的从A小区切换到B小区,但无法从B小区切换到A小区；手

机距离某小区C很近,但在手机的导频激活集中看不到C小区的PN码。这样随着手机向目标

小区移近,手机导频激活集中的EC/IO将逐渐降低、FER逐渐增大,继而引起掉话。

【原因分析】

一般情况下,CDMA手机有四个寄存器,分别存放6个激活导频集、5个候选导频集和20

个相邻导频集。虽然在目前的系统中,部分厂家的数据库最多可提供多达45个相邻小区,但

系统通过Neighbor

List

Updat消息经空中接口向手机传送的只有20个,而这20个邻区是系统

按一定的算法从当前的服务小区的多个邻小区数据库列表中选出来的,在选择过程中系统一

般不依赖于这些小区的信号强度和质量,而仅仅根据数据库的静态定义按照预先设定的算法

进行选择。这样如果某个目标小区在系统邻小区中未定义或定义了但由于优先级低而未能

通过空中接口消息告之手机,手机的邻小区寄存器中未存放该目标小区的信息,就会导致上

述问题现象的发生。

【解决方案】

通过路测设备或其它呼叫跟踪设备采集空中接口消息,采集掉话前后的信息,确定掉话

后同步的PN码,然后查找该同步消息上面最近的Neighbor

List

Updat消息,看是否由该PN码,

并结合邻小区列表数据库中判断是否为未定义或虽然定义了但优先级太低。

案例

2：关于导频检测参数设置的问题

【现象描述】

手机在通话过程中由于无线环境变化,导致信号急剧变化,此时会出现手机虽然已搜索

到目标小区信号,但由于未达到切换门限而无法切换或切换区域不足,导致误帧率上升引起

掉话。下面是一组现场测试数据,可以看出由于无线环境的变化,PN75的信号急剧减弱,但

PN396由于切换门限T-ADD为-12db,未能进入有效集,导致PN27虽然已达到门限值,但由于高

误帧而无法完成切换,导致掉话。

【原因分析】

分析该问题,我们需要对导频检测参数的定义和设置意义要有些了解。目前,基站导频

检测参数主要有T-ADD、T-DROP、T-TDROP、T-COMP等,这里我们主要了解一下T-

ADD和T-DROP两个参数。T-ADD是移动台用来检测接收到的导频强度的门限值。如果

T_ADD设置太小,会导致过多的掉话和覆盖空洞,也有可能导致切换区域不足。如果T_ADD

设置过大,会导致切换区域过大,从而使前向容量损失和由于需要增加信道卡而使成本增加。

另外由于切换区域的增加还会使呼叫和切换阻塞增加,后者还有可能导致掉话。T-DROP是.

导频去掉门限。当激活集和候选集中的导频强度低于该门限值时移动台会启动该导频对应

的切换去掉计时器。如果T_DROP设置过小,会导致过早地去掉可用导频,从而产生掉话,因

为去掉的导频只会是以干扰的形式出现的。如果T_DROP设置过大,会导致切换区域过大,

从而使前向容量损失和由于需要增加信道卡而使成本增加。另外由于切换区域的增加还会

使呼叫和切换阻塞增加,后者还有可能导致掉话。因此上面的问题主要由于切换门限T-ADD

设置太小引起切换区域不足,有效信号无法进入而引起掉话。

【解决方案】

通过对测试后台数据的分析,可以发现该问题主要由于信号突变,导致强信号无法及时

进入有效集,因此需要降低其切换门限,以便有足够的切换区域。因此通过调整PN75的T-

ADD的值为-13db,问题解决。

以下是调整后的测试数据：

案例

3：关于移动台搜索窗设置的问题

【现象描述】

当手机从当前服务小区移向某个覆盖范围较大的基站时,如果目标站的搜索窗口设置太

小,则手机将不能及时搜索到该目标站的PN,这样随着手机向目标基站的移动,必然出现当前

服务小区的信号强度减弱,而目标小区的信号增强而变为强干扰信号,这样就会出现接收电

平增强、服务小区的EC/IO减弱、TX、FER增加而导致掉话,这里我们将举个具体案例供大

家参考。

下图是某市某掉话点的后台

FER

效果图和前台数据：

【原因分析】

通过前台测试数据回放和后台数据分析,我们可以排除邻小区列表问题。（下图红圈。）

检测搜索窗参数设置：PN432：SRCH-WIN-A 为9；SRCH-WIN-N为10；由于PN54

基站设备为三星PICO设备,该设备分为SMU（三星PICO设备主控单元）和SRU（三星

PICO设备远程单元）两部分,其中射频SRU部分可拉远,经与相关工程人员确认,该设备

SMU和SRU采用光纤传输,距离大于10KM。由于基站SRCH-WIN-N的设置要大于2倍的PN

PHASE。

PN_phase

=Optic

cable

delay

+

Air

delay+

system

delay

=10*6chip+0+0chip=60chip

所以SRCH-WIN-A和SRCH-WIN-N要大于120chip

SRCH_WIN_A

SRCH_WIN_N

SRCH_WIN_R

CF_SRCH_WIN_N

CF_SRCH_WIN_R

Window

Size

(PN

chips)

SRCH_WIN_A

SRCH_WIN_N

SRCH_WIN_R

CF_SRCH_WIN_N

CF_SRCH_WIN_R

Window

Size

(PN

chips)

0

4

8

60

1

6

9

80

2

8

10

100

3

10

11

130

4

14

12

160

5

20

13

226

6

28

14

320

7

40

15

452

参照下表,

SRCH-WIN-N要大于等于11。

【解决方案】

参照上表,将

PN432

的

SRCH-WIN-N

改为

11,则问题解决,见下图（调整后

FER

效果图）

【总结】

从这个案例可以看出,搜索窗参数的设置过小会导致移动台无法搜索到目标小区而导致

呼叫掉话,但在实际应用中,我们也不能把搜索窗设置的太大,因为这样会导致搜索邻小区列

表的速度太慢。

案例

4：关于系统参数设置的问题

【现象描述】

手机在通话过程中可以成功的从A小区切换到B小区,已成功捕捉到B小区信号,进入候

补集,但基站无法完全解调手机的上行信号,无法下达切换指令,导致相关指标恶化而引起掉

话。下图是某组测试数据,从图中可以看出,PN141信号已经很强并已进入候补集,但无法完

成切换进入有效集,导致FER等指标恶化,最终导致掉话。

【原因分析】

从上图案例主要是由于系统未下发切换指令,而引起切换失败。在切换过程中,与手机

搜索窗相对应的基站的搜索参数是DEMOD-WIN-LENGTH ,该参数的取值范围为

0~3072（1/8

PN

CHIP

UNIT）。在切换过程中,|RTD

of

Master

–

RTD

of

Slave|

<

DWL/2(Demod_Win_Length),分别测算切换点距PN141和PN186两基站的空间距离,两直线

距离相差约为8KM（注：PN141基站为位于海对岸漳州中银基站,图中未标注。）,因此|RTD

of

Master

–

RTD

of

Slave|>4CHIP*8=32CHIP。因此DWL的取值应大于512,核查系统参数

中DWL的设置为默认值288,因此基本可判断该问题与DWL的设置过小有关。

采集开始时间

BTS

Cell

子系

统号

载

频

号

前向发

射功率

达到级

别

1

的

采样次

数

前向发

射功率

达到级

别

2

的

采样次

数

前向发

射功率

达到级

别

3

的

采样次

数

前向发

射功率

达到级

别

4

的

采样次

数

功率过

载时长

(ms)

2009-2-24

20:00

92

1

0

0

125

14

9

15

7800

2009-2-24

20:30

92

1

0

0

170

16

9

39

12800

2009-2-26

21:00

92

1

0

0

148

16

5

23

8800

2009-2-26

21:30

92

1

0

0

14

0

1

1

400

2009-2-27

20:30

92

1

0

0

1016

192

108

462

149600

2009-2-27

20:00

92

1

0

0

169

30

12

47

17800

2009-2-28

20:00

92

1

0

0

205

28

21

28

15400

2009-2-28

20:30

92

1

0

0

182

26

8

30

12800

开始时间

BTS

CELL

1X:

语音

呼叫话务

量

(Erl)

语音呼叫

拥塞次数

1X:

语音起

呼成功率

(%)

业务信道负

载率(%)

2

月

24

20:00

[92]邮电大楼

1

4.1739

2

98.62

16.82

2

月

25

20:00

[92]邮电大楼

1

5.9686

0

100

24.05

2

月

26

20:00

[92]邮电大楼

1

4.7878

1

98.15

19.3

2

月

27

20:00

[92]邮电大楼

1

5.0306

13

96.67

20.27

2

月

28

20:00

[92]邮电大楼

1

6.1469

2

97.81

24.77

处理前前向功率过载分析：

话统指标：

【解决方案】

调整两扇区

DWL

参数设置,将其调整为

600,则问题解决,下图为调整后现场测试数据。

案例

5：基站过覆盖,导致前向功率不足,起呼成功率不高

【现象描述】

由于邮电大楼基站较高（11层楼上面有一铁塔20多米）,覆盖远,旁瓣范围较大；观察

指标发现,此基站2扇区经常出现呼叫失败,前向功率不足等现象,导致指标相对较差。

从上面的统计来看,此基站2扇区连续几天晚忙时都存在前向功率过载,出现呼叫拥塞,导

致呼叫失败,并且过载的时长相对较长。连续几天的起呼成功率都在99%以下。

【原因分析】

分析此小区的话务量,发现并不是很高,并且没有出现由于CE不足导致的拥塞,查看呼叫

次数也不是很高,观察前向功率状况分析统计,发现都是由于前向功率不足导致的呼叫失败,

拥塞等现象,于是怀疑可能是此小区覆盖过远导致的前向功率不足。我们对此基站进行了实

地勘察,发现此基站天线较高,在11层楼楼顶20米高的铁塔上,并且检查其俯仰角发现机械倾

角仅1度,并且2扇区覆盖的区域没有太高的楼,因此造成此小区过远覆盖,旁瓣较大。我们对

此小区的覆盖进行了DT测试,如下图所示：

从上面图示来看,此小区旁瓣覆盖过大,并且覆盖到了万福桥附近,对周围小区造成一定的影

响。

【处理过程】

根据以上的基站勘察和实地测试分析,发现此小区出现前向功率过载,呼叫失败,主要是

由于此基站较高,主瓣覆盖过远,导致大部分用户处于离基站较远的位置进行通话,由于路径

损耗,因此分给每个用户的前向功率就增多,这样造成在用户不多的情况下也很容易出现由

于前向功率不足导致的起呼不成功。因此需要从两方面入手,处理此问题；一方面控制此小

区的覆盖,另一方面调整此小区的过载功率门限。

【解决方案】

邮电大楼2扇区俯仰角从1度→7度；

限制呼叫门限：90→95；限制切换门限

95→98；

导频占最大过载功率比例：150→120；

采集开始时间

BTS

Cell

子系

统号

载

频

号

前向发

射功率

达到级

别

1

的

采样次

数

前向发

射功率

达到级

别

2

的

采样次

数

前向发

射功率

达到级

别

3

的

采样次

数

前向发

射功率

达到级

别

4

的

采样次

数

功率过

载时长

(ms)

3

月

3

19:00

92

1

0

0

0

0

0

0

0

3

月

3

19:30

92

1

0

0

0

0

0

0

0

3

月

3

20:00

92

1

0

0

0

0

0

0

0

3

月

3

20:30

92

1

0

0

0

0

0

0

0

3

月

4

20:00

92

1

0

0

0

0

0

0

0

3

月

4

20:30

92

1

0

0

1

0

0

0

0

3

月

4

20:00

90

1

0

0

0

0

0

0

0

3

月

4

20:30

90

1

0

0

0

0

0

0

0

3

月

5

19:00

92

1

0

0

0

0

0

0

0

3

月

5

19:30

92

1

0

0

0

0

0

0

0

3

月

5

20:00

92

1

0

0

0

0

0

0

0

3

月

5

20:30

92

1

0

0

1

0

0

0

0

开始时间

BTS

CELL

1X:

语音

呼叫话务

量

(Erl)

语音呼叫

拥塞次数

1X:

语音

起呼成功

率(%)

业务信道负载

率(%)

3

月

3

20:00

[92]邮电大楼

1

4.6472

0

99.27

18.73

3

月

4

20:00

[92]邮电大楼

1

4.9847

0

99.54

20.09

3

月

5

20:00

[92]邮电大楼

1

4.4906

0

99.41

18.1

3

月

6

20:00

[92]邮电大楼

1

4.3742

0

99.55

17.63

【处理后结果】

根据以上调整方案,我们进行了调整实施,从调整后的话统来看,由于前向功率不足导致

的拥塞已经没有了,并且起呼成功率也有所提高,覆盖基本正常合理。

前向功率过载观察：

从上面的统计来看,经过调整后,前向功率过载测试明显减少,几乎没有；并且从指标观

察,此小区的语音呼叫没有出现拥塞现象,并且起呼成功率有所提高在99%以上,业务信道负

载也比以前明显降低。

覆盖图示：

开始时间

BTS

CELL

1X:

语

音呼叫

话务量

(Erl)

1X:

语

音软切

换成功

率(%)

1X:

语

音起呼

成功率

(%)

1X:

语

音寻呼

成功率

(%)

业务信

道掉话

率(%)

呼叫

失败

次数

3

月

16

赤水邮电大楼

0

3.09

100

99.44

99.23

0

2

3

月

16

赤水邮电大楼

1

2.32

100

100

100

0

0

3

月

16

赤水邮电大楼

2

3.55

100

98.39

100

0.67

4

替换前指标：（20:00---21:00）

从上面的统计来看,此基站3个扇区的切换成功率都在99%以上；起呼成功率在99%左右；

从调整后的覆盖来看,此小区的覆盖得到了很好的控制,过覆盖现象基本消除,对周围基站

的影响明显减少。

【总结】

从上面的案例分析得出,城区基站不宜选址较高,选址过高,可能造成超远覆盖,导致前向

功率不足,影响相关的指标。并且天线挂高过高,为了控制覆盖,可能要大程度的下压天线俯

仰角,这样很容易造成波型变型,旁瓣变大,对周围基站产生很大的影响,因此城区基站应该根

据周围的建筑及用户量,覆盖距离合理的选取天线的高度。

案例

6：基站替换后呼叫失败次数高,切换成功率低的问题

【现象描述】

赤水邮电大楼基站被替换为支持EVDO的基站后,观察指标发现,此基站的呼叫失败次数

较高,呼叫建立成功率差,起呼成功率不高,并且切换成功率偏低。

开始时间

BTS

CELL

1X:

语

音呼叫

话务量

(Erl)

1X:

语

音软切

换成功

率(%)

1X:

语

音起呼

成功率

(%)

1X:

语

音寻呼

成功率

(%)

业务信

道掉话

率(%)

呼叫

失败

次数

18:00:00

赤水邮电大楼

0

6.38

93.58

95.52

99.53

0.15

24

18:00:00

赤水邮电大楼

1

2.72

94.10

94.22

96.79

0.40

15

18:00:00

赤水邮电大楼

2

1.07

93.22

95.24

98.86

1.90

7

19:00:00

赤水邮电大楼

0

9.70

91.00

97.19

96.29

0.00

30

19:00:00

赤水邮电大楼

1

3.13

91.92

96.67

95.41

0.43

11

19:00:00

赤水邮电大楼

2

1.82

93.22

96.82

99.18

0.52

6

20:00:00

赤水邮电大楼

0

7.17

93.35

96.00

98.36

0.00

19

20:00:00

赤水邮电大楼

1

1.85

94.02

98.23

96.3

1.34

5

20:00:00

赤水邮电大楼

2

3.06

89.29

95.18

98.17

0.56

10

21:00:00

赤水邮电大楼

0

6.40

91.42

92.63

98.35

0.25

30

21:00:00

赤水邮电大楼

1

2.34

92.00

89.86

97.26

0.00

16

21:00:00

赤水邮电大楼

2

2.70

89.92

93.53

96.15

0.00

13

语音寻呼成功率也相对较高,呼叫失败次数最多的小区仅为4次。

替换后指标：3月18日（18:00---23:00）

从上面的统计来看,此基站替换后,切换成功率在95%以下；起呼成功率在95%左右,寻呼

成功率也相对较低,并且从呼叫失败次数来看,此基站各小区的呼叫失败次数较多。

【告警信息】无

观察此基站的告警信息,没有发现有任何信息。

【原因分析】

引起接入失败和切换失败的主要原因有以下：

1、

高话务；

2、

跨载频业务信道分配；

3、

邻区关系缺失；

4、

参数设置错误；

5、过大的软切换区域；

6、缺乏覆盖；

7、搜索窗问题；

8、干扰；

9、GPS模块及其它硬件故障；

结合以上原因我们分析此基站3个扇区的都较差,说明主要是3个扇区共用的部分出现问

题,从硬件来说可能是时钟模块或主控模块存在问题,因此我们对此基站的时钟模块和主

控模块进行了诊断,没有发现问题,并且进行了更换,问题仍然存在,说明两硬件没有问题。

主控板：

从上面的诊断来看,主控板工作正常。

时钟板：

从上面的诊断来看,此基站的时钟模块工作正常,GPS接收机正常,搜索卫星12个。

采集开始时间

System

小

区

号

主集

RSSI

最

大值

(dBm)

主集

RSSI

最

小值

(dBm)

主集

RSSI

平

均值

(dBm)

分集

RSSI

最

大值

(dBm)

分集

RSSI

最

小值

(dBm)

分集

RSSI

平

均值

(dBm)

2009-3-18

18:00

129

0

-101.2

-113.24

-111.4

-106.17

-114.71

-112.97

2009-3-18

18:00

129

1

-110.74

-113.97

-112.94

-111.5

-114.03

-113

2009-3-18

18:00

129

2

-107.66

-113.58

-112.44

-111.96

-115.6

-114.09

2009-3-18

18:30

129

0

-108.94

-113.4

-112.36

-110.88

-114.87

-113.87

2009-3-18

18:30

129

1

-108.65

-113.96

-113.01

-98.85

-114

-112.78

2009-3-18

18:30

129

2

-111.35

-114.05

-113.02

-102.86

-114.99

-113.86

2009-3-18

19:00

129

0

-105.97

-113.56

-111.96

-107.57

-114.6

-113.48

2009-3-18

19:00

129

1

-111.45

-113.9

-112.98

-103.22

-114.33

-112.71

2009-3-18

19:00

129

2

-109.52

-113.82

-112.84

-97.29

-115.34

-113.56

2009-3-18

19:30

129

0

-106.38

-113.76

-111.42

-106.26

-115.03

-112.75

2009-3-18

19:30

129

1

-111.63

-113.44

-112.92

-107.23

-113.59

-112.19

2009-3-18

19:30

129

2

-108.28

-113.9

-112.85

-106.79

-114.45

-113.07

2009-3-18

20:00

129

0

-109.63

-113.4

-112.39

-111.59

-114.78

-113.82

2009-3-18

20:00

129

1

-96.71

-113.71

-112.34

-100.14

-113.92

-112.05

2009-3-18

20:00

129

2

-108.85

-113.66

-112.71

-110.57

-114.59

-113.7

2009-3-18

20:30

129

0

-99.71

-114.05

-110.25

-87.43

-115.44

-112.06

2009-3-18

20:30

129

1

-96.72

-114.24

-111.54

-105.87

-114.11

-112.48

2009-3-18

20:30

129

2

-104.47

-113.59

-112.07

-109.28

-114.96

-113.63

2009-3-18

21:00

129

0

-106.35

-114.19

-112.09

-110.42

-115.03

-113.87

2009-3-18

21:00

129

1

-112.28

-114

-113.15

-110.97

-114.89

-113.25

2009-3-18

21:00

129

2

-110.64

-114

-112.95

-111.52

-114.8

-114.06

2009-3-18

21:30

129

0

-110.83

-113.17

-112.34

-108.24

-115.05

-113.5

2009-3-18

21:30

129

1

-110.89

-114.14

-112.89

-112.34

-114.66

-113.44

2009-3-18

21:30

129

2

-107.8

-114.1

-112.53

-112.78

-114.85

-114.19

怀疑是否存在外部反向干扰,导致3个扇区呼叫失败次数多,切换差；由于外部干扰较难

掌握和控制,有可能出现,于是观察了此基站的底噪发现3个扇区都基本正常,如下统计：

从上面的统计来看,此基站3个小区的底噪基本正常,反向干扰基本能够排除。

由于此基站替换后数据重新制作,因此对此基站的搜索窗、接入等参数、PN码等进行了

检查和对比,和原来的一样,邻区关系也和原来保持一致,没有发现有漏加的邻区关系；因

此也可以排除参数设置不当,导致出现此问题。

观察此基站开通的话务变化,1扇区话务量有所增高,2,3扇区的话务量基本上变化不大,由

于此基站进行了升高,所以1扇区的话务出现升高的现象,但是从拥塞统计来看,3个扇区

都没有出现拥塞的现象。因此排除此因素的影响。

跨载频业务信道分配,目前此基站仅为单载频基站,不牵扯跨载频业务信道指配,固也不是

此原因导致的。

失败原因

次数

ERR_SPS_RLSA_BSSAP_TE_Tfchsetup

136

ERR_SPS_RLSA_DSPM_CLH_TimerExpired_Twaitorder

5

RESULT_DEFAULT_ERROR

1

SDM_Activate_Fail_AcquirePreambleFail_Normal

12

SDM_Find_Fail_WaitConfigVTCTimeout

1

从切换比例来看,此基站的切换比例和原来差不多,也不存在切换区域过大的现象。

由于此基站为县城基站,位置升高,和原来情况相差不大,因此也不可能是缺乏覆盖导致。

我们对此基站的呼叫失败原因进行了分析,如下统计：

以上是3月18日18点到22点的呼叫失败原因统计,从上面来看,总共失败155次,其中

ERR_SPS_RLSA_BSSAP_TE_Tfchsetup导致的占136次,因此呼叫失败主要是此原因导致。查

询手册说明：

从上面看,可能是定时器设置太短,此定时器没有进行过修改,因此应该没有问题。观察

CCM板CPU占用率不高,也不是此原因造成,由于失败原因是BSC长时间没有收到BTS上建

立基本信道成功或失败的响应消息,因为BTS和BSC主要是2M线连接,经询问此基站替换后

扩了两条传输,因此怀疑可能与传输线有关。

【处理过程】

查看E1流量情况,发现有两条E1接收流量较小,仅为200多bps,而另外两条传输为上万

开始时间

BTS

CELL

1X:

呼

叫建立

成功率

(%)

1X:

语

音寻呼

成功率

(%)

1X:

语

音无线

掉话率

(%)

1X:

语

音软切

换成功

率(%)

1X:

语

音起呼

成功率

(%)

2009-3-19

20:00

[129]赤水邮电大楼

0

99.36

100

0

100

98.92

2009-3-19

20:00

[129]赤水邮电大楼

1

99.61

100

0

99.83

99.37

2009-3-19

20:00

[129]赤水邮电大楼

2

100

100

0

100

100

2009-3-19

21:00

[129]赤水邮电大楼

0

100

100

0.32

100

100

2009-3-19

21:00

[129]赤水邮电大楼

1

98.59

100

0

100

97.4

2009-3-19

21:00

[129]赤水邮电大楼

2

100

100

0

100

100

2009-3-19

22:00

[129]赤水邮电大楼

0

99.71

100

0

100

99.53

2009-3-19

22:00

[129]赤水邮电大楼

1

99.26

100

0.49

100

98.85

2009-3-19

22:00

[129]赤水邮电大楼

2

100

100

0

100

100

2009-3-19

23:00

[129]赤水邮电大楼

0

99.14

98

0

100

100

2009-3-19

23:00

[129]赤水邮电大楼

1

100

100

0

100

100

2009-3-19

23:00

[129]赤水邮电大楼

2

98.77

97.14

0

100

100

bps,明显有两条传输存在问题,导致流量不正常。因此怀疑可能是这两条传输存在问题导致

接入失败高,指配差等问题,因此断掉了这两条传输。于是我们又对此基站的话统进行了观

察统计,发现基本正常。

从上面的统计来看,此基站另外两条传输断掉后,此基站的呼叫建立成功率正常,99%左右；

寻呼成功率也相对较高；软切换成功率正常；起呼成功率也相对较高。

【解决方案】

建议传输维护人员,检查另外两条传输线性能及质量,并重新进行制作；

【处理后结果】

传输线处理后,我们对此基站的各项指标进行了跟踪观察,并对E1流量进行了统计,发现都

已经基本正常,此问题也得到解决。

处理后的E1流量观察：

从上面的图来看,各E1的接收流量基本正常。

处理后的话统观察：

开始时间

BTS

CELL

1X:

语音

呼叫

话务

量

(Erl)

1X:

语

音软切

换成功

率(%)

1X:

语

音起呼

成功率

(%)

1X:

语音

寻呼

成功

率(%)

业务

信道

掉话

率(%)

呼叫

失败

次数

3

月

21

20:00

[129]赤水邮电大楼

0

5.63

99.89

99.36

99.49

0.00

3

3

月

21

20:00

[129]赤水邮电大楼

1

2.25

100

98.69

100

0.00

2

3

月

21

20:00

[129]赤水邮电大楼

2

2.12

99.59

99.25

100

0.63

1

3

月

22

20:00

[129]赤水邮电大楼

0

4.13

99.65

97.95

100

0.00

6

3

月

22

20:00

[129]赤水邮电大楼

1

2.41

99.80

100

100

0.00

0

3

月

22

20:00

[129]赤水邮电大楼

2

2.01

100

99.15

100

0.66

1

3

月

23

20:00

[129]赤水邮电大楼

0

6.51

100

99.44

100

0.00

2

3

月

23

20:00

[129]赤水邮电大楼

1

2.15

100

99.17

99.07

0.00

2

3

月

23

20:00

[129]赤水邮电大楼

2

1.88

100

97.5

100

0.00

3

上面的统计来看,软切换成功率较高99.5%以上；语音起呼成功率也较高,寻呼成功率99%以

上,呼叫失败次数2,3次基本正常,此问题基本解决。

【总结】

从上面的案例分析得出,工程质量是非常重要的,小小的疏忽都可能导致问题的出现,影响

网路的服务性能,引起不必要的投诉,因此在后续替换基站的过程中各个环节都应该保证工

程质量,尽量避免人为疏忽导致的各种问题,影响替换后的各项指标。

案例

7：邻区漏加,导致掉话

【问题描述】

在从遵义市马拦坝基站往遵义市二职高基站测试行驶过程中,在二职高基站附近手机

Ec/Io

变差,发射功率升高,接收电平正常,最后出现掉话。

下图为掉话点图示：

【问题分析】

通过对测试数据分析发现,手机掉话前占用马拦坝

PN147

的信号,此小区接收电平较好

-70dBm

左右,手机发射功率偏大,Ec/Io

较差-22dBm,FFER

较大

100%。掉话处离二职高基站

较近,但是没有切换到二职高基站,并且掉话后手机同步到二职高

sec-1(PN18)上,经检查发现

主要是由于马拦坝

sec-1（PN147）没有添加二职高

PN18

和

PN186

为邻区关系,因此不能进

行切换,在二职高基站附近对

PN147

信号造成强干扰,Ec/Io

变差,FFER

升高,没有合适的邻小

区进行切换,最终导致掉话。

PN147

邻区图：

以上是

PN147

的邻区图,黄颜色的为邻区,从上面的图来看,PN147

没有添加二职高

PN18

和

PN186

为邻区关系。

掉话后同步到

PN18

图示：

【解决方案】

建议马拦坝

sec-1(PN147)和二职高

sec-1(PN18)、二职高

sec-2（PN186）互为添加邻区关

系。

【处理结果】

从上图来看,在此处没有出现掉话,此问题得到解决。

邻区关系：

分析图：

切换成功图示：

从以上图示对比可以看出,添加邻区关系后,MS

可以正常的切换到遵义市二职高

Sec-

1(PN18),Ec/Io

为-4

很好,接收电平为-55dBm

很好,发射功率为-33dBm

正常,各项指标正常,没

有出现掉话现象。

案例

8：中心血站导频污染问题

【问题描述】

我们对中心血站进行了测试,测试位置为

1

楼、8

楼、12

楼。通过数据分析发现,1

楼的

各项指标正常,覆盖较好；8

楼和

12

楼覆盖良好,切换频繁,12

楼部分点

Ec/