陕西汉中移动GSM网络大话务保障方案优选Word文件下载.docx

陕西汉中移动GSM网络大话务保障方案优选Word文件下载.docx

《陕西汉中移动GSM网络大话务保障方案优选Word文件下载.docx》由会员分享，可在线阅读，更多相关《陕西汉中移动GSM网络大话务保障方案优选Word文件下载.docx（36页珍藏版）》请在冰豆网上搜索。

1649.7609

1326.8

HZ-HW-BSC15

1412.59

1539

1977.626

2154.3

HZ-HW-BSC16

718.74

461

1006.236

644.7

HZ-HW-BSC17

594.66

427

832.53053

597.4

HZ-HW-BSC18

602.86

455

843.99764

637

从以上统计结果对应各BSC所能承载的话务量情况来看，BSC08需考虑承载问题，需要增加GDPUX单板来抗击节假日话务量的冲击，其余BSC可承受春节大话务冲击。

1.2GPRS容量分析

对于BSC设备硬件容量的分析需要从BSC级及小区级进行分析，评估其能够承载的业务量，具体从如下几个方面来分析。

1.2.1Pb口容量评估

对网络资源通过Pb口来进行评估，需要区分外置PCU及内置PCU进行分析，汉中全部为内置PUC，无外置PCU，故没有Pb口。

根据RPPU单板配置规格判断是否需要增加RPPU单板。

一块RPPU单板最大支持120个小区，最多能同时激活120条GPRS信道，如果含有EDGE信道，那么最多能同时激活100条。

一块RPPU单板最多能支持两块L2PU小板，一块L2PU小板最多能支持100条PCIC（G3PCUV300R005C05B052之后略有提高），所以一块RPPU单板最多能支持200条PCIC。

如果小区支持EDGE，并且都使用了MCS9的信道编码方式，那么一块RPPU板上只能同时支持[200/4=50条]EDGEPDCH信道；

对于内置PCU来说Pb接口功能已经由GDPUP单板承担，该每块单板的承载能力是22*48＝1056－32＝1024PDCH信道，需要统计每块单板每个DSP上承载的PDCH信道数已经达到处理上限，建议不超过40个，否则需要对小区进行DSP重分布（注：

22为GDPUP单板上的DSP单元数，48为每个DSP所能够承载的PDCH资源数）。

汉中现网华为GDPUP单板DSP的负荷情况如附件所示，DSPCPU占有率平均值大于60％的主要集中在BSC04、BSC05、BSC07、BSC08、BSC11、BSC14以及BSC15的DSP单板上，且BSC11和15已经出现DSP过载告警，若考虑节假日业务增长，BSC04、07、08、11、14和15的DSP负荷还会增大，预计会达到80%以上，需进行相关资源调整处理（通过调整各小区归属DSP来解决，若该GDPUP单板所有dsp负荷都高就需要扩容GDPUP单板）；

详细各BSCGDPUP单板DSP占用率情况如下附件所示：

1.2.2Gb口容量评估

GB口需要考虑用户数据流量，根据GB接口E1线配置的时隙数计算GB接口的链路能够支持的最大流量。

如果GB口的用户数据峰值流量超过当前链路支持最大流量的80％，则建议进行扩容，否则在部分忙时可能由于GB接口流量限制影响用户数据吞吐率。

NS性能测量--→NSVC传输性能测量--→NS_PDU峰值发送、接收传输字节数。

下行链路的评估

“NS性能测量”—>

“NS传输能力测量”，其中的话统指标“接收NSPDU的峰值字节数”，在一个测量周期内对各NSVC求和，可以得到整个PCU在一个测量周期内的接收下行LLC_PDU峰值总字节数。

Gb口时隙下行利用率=一个测量周期内接收下行LLC_PDU峰值总字节数×

8/（1024×

测量周期×

60）/（64×

可用时隙数目）

其中“测量周期”的单位是秒，对于外置PCU为5秒，内置PCU为10秒。

上行链路的评估

“NS性能测量”—〉“NS传输能力测量”，其中的话统指标“发送NSPDU的峰值字节数”，在一个测量周期内对各NSVC求和，可以得到整个PCU在一个测量周期内的发送上行LLC_PDU峰值总字节数。

Gb口时隙下行利用率=一个测量周期内发送上行LLC_PDU峰值总字节数×

测量周期）/（64×

其中“测量周期”的单位是秒。

评估准则：

一般“Gb口时隙下行利用率”要远大于“Gb口时隙上行利用率”，因为用户一般是做下行业务比上行业务多，若是“Gb口时隙下行利用率”大于80％，则要考虑Gb口时隙需要扩容了。

PCU6000中GB接口扩容包括：

license软件，GB接口E1传输，甚至增加GB接口板（包括小扣板和RPPU板）。

内置PCU中GB接口扩容包括：

license软件，GB接口E1传输，甚至增加GB接口板（GEPUG或者GFGUG）。

汉中现网GB口上下行利用率如下表所示（其他BSC的Gb口以IP传输，不存在容量负荷问题）：

NSE标识

BC时隙数

L9604:

发送NSPDU峰值字节数

L9605:

接收NSPDU峰值字节数

Gb口时隙上行利用率

Gb口时隙下行利用率

Gb口时隙下行利用率（节假日）

BSC04

360

93

1132399

4366645

14.86%

57.32%

74.52%

361

82

696209

2678504

10.36%

39.87%

51.83%

667

124

968787

3829407

9.54%

37.70%

49.01%

958

62

687236

3366702

13.53%

66.29%

86.18%

1334

953319

3801204

12.51%

49.89%

64.86%

BSC05

362

463568

1918644

6.08%

25.18%

32.73%

444

158342

814371

3.12%

16.03%

20.84%

700

155

1458910

5875369

11.49%

46.27%

60.15%

1335

617490

1979270

12.16%

38.97%

50.66%

BSC08

363

748360

2258918

14.73%

44.48%

57.82%

749

166

1795045

6375485

13.20%

46.88%

60.94%

1336

58

491696

1474175

10.35%

31.03%

40.34%

BSC09

364

673398

1733979

13.26%

34.14%

44.38%

635

123

1438833

4706938

14.28%

46.71%

60.72%

1337

31

547220

1886240

21.55%

74.28%

96.56%

BSC10

365

925108

3185304

18.21%

62.71%

81.52%

750

106

958260

3319312

11.04%

38.23%

49.70%

1338

385438

1138653

15.18%

44.84%

58.29%

BSC11

366

549584

1888341

7.21%

24.79%

32.23%

751

105

1636413

5273844

19.02%

61.31%

79.70%

BSC12

752

1213097

4288193

14.10%

49.85%

64.81%

BSC13

580

1932099

6040037

14.21%

44.42%

57.75%

从上表的统计来看，若节假日业务增长按1.3倍来计算，BSC04、BSC09、BSC10、BSC11的Gb口利用率已大于80%，需要及时对这些BSC的Gb口时隙进行扩容。

1.3BSC话务承载分析

框号

GDPUX单板数量

小区数

TRX数

半速率载频数

实际承载话务量

预测节假日承载的话务量

单板理论承载话务量

HW-BSC04

2

104

632

85

1192.86

1670.00

2112

1

92

573

110

1111.94

1556.71

9

42

17

83.73

117.22

1056

HW-BSC05

41

214

66

430.07

602.10

34

184

79

361.20

505.67

3

33

138

26

266.83

373.57

HW-BSC06

32

332.37

465.32

176

576

159

1177.46

1648.45

99

244

23

286.18

400.66

HW-BSC07

70

195

21

309.29

433.00

115

451

141

1112.25

1557.16

90

297

40

385.07

539.10

HW-BSC08

73

317

55

782.44

1095.41

78

303

503.24

704.53

301

24

414.97

580.96

HW-BSC09

4

290

87

616.60

863.24

4224

6

118

289

86

645.74

904.03

6336

114

278

52

578.92

810.49

6336

HW-BSC10

102

74

699.15

978.81

5

294

56

473.95

663.53

5280

272

434.03

607.64

HW-BSC11

63

433.11

606.35

368

744.20

1041.88

HW-BSC12

96

689.39

965.14

134

359

101

764.62

1070.47

HW-BSC13

234

53

547.16

766.03

3168

76

286

651.31

911.84

97

470.02

658.03

HW-BSC14

61

157

186.29

260.81

88

242

427.66

598.73

268

39

530.60

742.84

HW-BSC15

27

36

294.40

412.17

54

300

521.43

730.00

274

477.22

668.11

HW-BSC16

94

15

209.28

292.99

30

348.36

487.70

20

12

113.94

159.52

HW-BSC17

60

151

144.24

201.94

65

172

7

126.66

177.32

229

293.29

410.61

HW-BSC18

120

8

113.41

158.77

218

13

320.63

448.88

59

152

224.03

313.64

从现网BSC各框话务量分布情况来看，有些BSC的硬件配置（GDPUX）还不能够满足节日期间的大话务冲击，需增加GDPUX单板的数量来抗击大话务的冲击，同时从安全性考虑BSC配置的GDPUX单板需满足1＋1备份的要求，假如有1块单板存在问题，该框所承载的小区话务负荷将会出现过高，甚至无法承载而流控的问题，主要有以下框需要注意：

从以上分析来看，BSC08的GDPUX单板数量明显不能满足现网及节假日大话务的需求，需及时扩容GDPUX单板的数量。

1.4LAC区容量分析

对当前网络网络结构进行分析，其组网合理性及安全性进行评估，主要涉及BSC容量均衡性、插花严重程度及位置区容量的分析。

图1.LAC区分布图

MSC

LAC

TRX

承载的寻呼量量

预计节日寻呼量

GM2

37227

205

1271

100584

130759

GM3

37228

111

560

39659

51557

GM1

37220

307

924

56710

73723

GM4

37218

275

925

62397

81116

37219

18

1203

1564

GM5

37225

257

921

58986

76682

37216

311

857

63267

82247

37217

315

932

56425

73353

37223

162

640

47868

62228

37224

226

656

43717

56832

37221

236

823

45707

59419

37229

219

41515

53970

37230

51288

66674

37231

107

310

19904

25875

37226

215

552

10786

14022

37222

199

490

20995

27294

当前汉中地区BSC割接工作结束后，LAC区分布已经很合理，但LAC区37219下仍有6个小区，属割接遗留站点，后续会割接到LAC区37218下；

预计汉中节假日最大寻呼量为13万，所以不会存在寻呼过载问题。

注：

依照如下寻呼参数进行网络寻呼容量的评估

CCCH_Config：

非组合BCCH

AGB：

寻呼方式

移动：

采用首次寻呼TMSI，二次寻呼IMSI的寻呼机制

联通：

2BSC节前性能分析

2.1现网KPI分析

2.1.1现网话务分析

获取每框话务量，以及每框各个单板的CPU占用率；

A接口寻呼消息数；

每个GEIUB单板的信道请求数量，每个小区SDCCH信道拥塞率，每个小区的TCH信道拥塞率，计算每个位置区下的小区数，并对这些数据进行分析。

该处网优侧需要关注CPU占用率、A接口寻呼消息数、每个小区SDCCH信道拥塞率，每个小区的TCH信道拥塞率及每个位置区下小区数、载频数及寻呼数。

2.1.2框话务评估

获取每框话务量，以及每框各个单板的CPU占用率。

BSC6000每框支持2500Erl话务量，这时各个单板CPU平均占用率应该在60%左右。

如果不能满足于这个比例，进行如下处理，

问题的原因

处理方法

话务负荷不均匀

参考2.3.5

话务模型与标准模型不一致

参考2.2.1I中的工具具进行扩容

汉中现网华为BSC各框话务分布如下：

承载话务量

1192.859

1111.9373

83.727

430.07067

361.19633

266.833

332.36933

1177.4633

286.18333

309.28767

1112.2547

385.07133

782.43733

503.237

414.97233

616.59867

645.73567

578.92267

699.148

473.94933

434.03167

433.10967

744.198

689.38767

764.62267

547.16167

651.31367

470.02333

186.29333

427.66433

530.59833

294.40433

521.42533

477.22267

209.28033

348.35767

113.94267

144.24133

126.65967

293.29467

113.40567

320.626

224.032

汉中现网华为BSC各框单板CPU占用率最大值为57.00%，CPU占用率平均最大值为47.23%，具体情况如附件所示：

2.1.3A接口寻呼能力评估

获取A接口寻呼消息数。

如果15分钟的A接口寻呼消息数大于11万/位置区，则参考2.3.6和2.3.15处理。

汉中华为现网15分钟A口寻呼消息最大在25146左右，依照节假日寻呼量按1.5倍数增长，节假日承载的最大寻呼量为37719，从网络角度考虑是安全的，具体如下表所示：

承载的寻呼量（15分钟）

预计节日承载的寻呼量（15分钟）

25146

37719

9915

14873

14177

21266

15599

23399

452

14746

22119

15817

23726

14106

21159

11967

17951

10929

16394

11427

17141

10379

15569

12822

19233

4976

7464

2696

4044

5249

7874

2.1.4Abis接口处理能力评估

获取每个GEIUB单板的信道请求数量，如果大于150个/秒，则参考2.3.7处理；

:

话统中只有按照小区统计的信道请求数，因此需要先确定每个GEIUB单板包含哪些小区，再手工将这些小区的信道请求数加到一起，才能得到每个GEIUB单板的信道请求数量

GEIUB板号

信道请求/S

13.63

9.53

22

13.78