移动集团下发EDGE优化案例.docx
- 文档编号:12186623
- 上传时间:2023-04-17
- 格式:DOCX
- 页数:33
- 大小:1.08MB
移动集团下发EDGE优化案例.docx
《移动集团下发EDGE优化案例.docx》由会员分享,可在线阅读,更多相关《移动集团下发EDGE优化案例.docx(33页珍藏版)》请在冰豆网上搜索。
移动集团下发EDGE优化案例
优化经验案例分析
(第五期)
目录
1安徽2
1.1PCU隐性故障导致数据业务接入困难2
1.2使用数据业务时无法做被叫问题6
2北京8
2.1重点道路优化经验总结8
3福建9
3.1NSN设备_DAP拥塞小区优化案例9
3.2TBF掉线的优化11
3.3MOTO设备_交叉线导致GBL链路负荷异常14
4甘肃16
4.11800M频段和900M频段小区频繁重选问题讨论16
5广东21
5.1话务网和数据网无线资源均衡优化策略21
1安徽
1.1PCU隐性故障导致数据业务接入困难
问题描述:
本周接到客户投诉,反映在经济开发区建工学院校内GPRS业务无法正常使用。
为此我们实地进行了CQT测试,测试中手机主要占用教育学院3(21882-773)、教育学院西1(21882-771)和建工学院新区1800(21882-3086)小区,3个小区都已经开通EDGE功能,但是测试中Attach都失败,PDP也无法激活,测试图如下:
从Layer3信令上看,是由于下行TBF无法建立导致请求超时最终失败,测试中这3个小区都存在此问题。
解决过程:
为了进一步查找问题原因,我们查看了BSC12在12月7日晚忙22时的小区级话务统计,发现有较多小区PDCH上行分配成功率不高,甚至有些小区上行PDCH占用成功率低至20%以下,肯定会造成用户接入困难。
下表列出了BSC12下上行PDCH分配成功率低于80%的小区:
小区名
ci
测量时间
所在PCU
TCH话务量
PDCH尝试次数_上行TBF
上行PDCH分配成功率
上行PDCH占用成功率
可口可乐-2
762
2008-12-722:
00
3
9.95
6195
65.29%
33.14%
可口可乐-3
763
2008-12-722:
00
5
65.85
76104
48.17%
12.85%
肥南-3
11583
2008-12-722:
00
5
14.01
13280
75.02%
73.00%
卧云小学-2
11267
2008-12-722:
00
0
49.05
31681
72.51%
53.21%
合力叉车-1
10036
2008-12-722:
00
3
3.37
2029
64.61%
28.93%
合力叉车-2
10037
2008-12-722:
00
3
3.84
1989
74.71%
23.43%
锦绣社区-2
22
2008-12-722:
00
3
51.84
15850
77.55%
63.70%
教育学院西1
771
2008-12-722:
00
3
62.84
31953
51.66%
16.09%
教育学院西2
772
2008-12-722:
00
3
99.53
68234
63.38%
48.63%
教育学院西3
773
2008-12-722:
00
3
44.76
21687
74.43%
42.06%
省经贸学校-1
13946
2008-12-722:
00
3
31.08
6176
60.28%
23.40%
合肥学院南区-3
728
2008-12-722:
00
1
37.91
89055
40.12%
23.15%
行政学校1800-2
3166
2008-12-722:
00
3
12.49
1736
77.53%
29.61%
BTSM:
42/BTS:
2
11458
2008-12-722:
00
3
9.48
2920
78.97%
16.61%
上表中列出了这些PDCH占用成功率低的小区所在的PCU,可以看到,教育学院西的几个小区都是在PCU3下,且在PCU3下的其它小区上行PDCH分配和占用成功率也非常低,初步怀疑是BSC12的PCU3存在隐性故障。
通过上诉分析,我们对BSC12PCU3进行了Lock操作。
根据西门子PCU均衡算法,当BSC中的某块PCU发生故障或被人为锁定(LockPCU)时,系统会自动将其上所有的PTPPKF重新分配到剩余的PCU上,保证这些小区GPRS业务的正常运行,如下图所示(该例中共有三块PCU):
在对BSC12的PCU3进行Lock操作后,此时773小区挂到了PCU0下。
而后到建工学院再次实地测试,测试中Attach,PDP激活,FTP下载和WAP业务都很正常,测试图如下:
为了验证PCU3是否存在隐性故障,我们解锁PCU3之后再次进行测试,解锁后773小区仍然挂在PCU0下,在该小区下的各项业务也无异常,测试图如下:
解锁PCU3之后,根据PCU均衡算法,一些小区重新回到了PCU3上。
在RC上观察该PCU也工作正常。
通过话务统计观察,重新调整后PCU3下属小区各项指标也无异常出现,上下行PDCH接入指标较好,如下表:
小区名
CI
所在PCU
测量时间
上行PDCH分配成功率
上行PDCH占用成功率
下行PDCH分配成功率
下行PDCH占用成功率
可口可乐-1
761
3
12/8/200816:
00
96.96%
96.07%
100.69%
98.08%
可口可乐-2
762
3
12/8/200816:
00
94.43%
92.63%
100.34%
97.13%
可口可乐-3
763
3
12/8/200816:
00
93.06%
89.66%
100.53%
97.77%
莲花社区-3
603
3
12/8/200816:
00
96.99%
96.49%
99.54%
96.58%
官塘村-1
11806
3
12/8/200816:
00
93.84%
90.04%
99.08%
96.38%
官塘村-2
11807
3
12/8/200816:
00
95.31%
87.35%
98.33%
93.97%
官塘村-3
11808
3
12/8/200816:
00
86.16%
85.06%
99.50%
98.36%
行政学校-3
11363
3
12/8/200816:
00
95.76%
93.64%
100.52%
95.51%
行政学校-2
11362
3
12/8/200816:
00
99.06%
98.28%
100.00%
97.45%
丰乐种业-3
593
3
12/8/200816:
00
95.37%
92.77%
99.51%
98.53%
肥南-1
11581
3
12/8/200816:
00
95.06%
92.92%
98.85%
95.40%
打电话回访客户,客户反映现在GPRS业务已经恢复正常,至此投诉问题解决。
总结:
PCU隐性故障可能导致数据业务接入困难。
通过倒换PCU和对PCU的Lock/Unlock操作,可以解决PCU隐性故障造成的PCU下属小区接入困难,网络指标差的问题。
1.2使用数据业务时无法做被叫问题
近日用户投诉反映,每次在接收和发送彩信的时候做被叫都无法接通,等到接收和发送彩信完毕后才收到一条未接来电的短信通知。
其实这个问题以前就一直存在,对于目前的网络来说是正常现象,因为ClassB类的手机在传数据的时候(Packettransfermode)只监听PDCH信道,而不监听PCH信道,因此无法收到CS域发来的Paging消息,等到手机上下行TBF释放,回到Packetidlemode下,就可以收到PCH信道下发的CSPaging消息。
但这个问题是可以有解决办法的,在西门子BSC中有一个参数叫PAGCOORCLB(BSC级参数),解释如下:
通过开启该参数,可以使在该BSC下的B类手机使用数据业务的同时实现被叫接收到寻呼消息的功能,因此已可以实现PS域服务时接收CS域PAGING消息的可能,该功能对其他层面的影响不大,因此不会造成其他业务的使用。
这样既可以提高用户的感知度,理论上也可以提高寻呼成功率指标。
我们对此进行了参数开启和功能验证。
测试环境
选择BSC1的小区,使用测试手机进行FTP测试,另外使用商用手机拨打测试手机。
测试设备
SagemOT498手机一部,上下行支持1+4模式;商用Nokia手机一部。
未开启该功能时,使用商用手机拨打测试手机会回复:
“您所拨打的电话暂时无法接通”
在开启该功能后,测试手机就可以在进行数据业务的同时接收寻呼信息,如下图所示:
从图上可以看出当商用手机拨打测试手机后,测试手机将挂起数据业务,并与主叫手机接通电话,当通话结束后测试手机接到网络下发的RESUME信息并恢复FTP下载,我们使用其他商用手机测试也正常。
在测试手机收发彩信的时候做被叫同样正常。
总结:
从以上测试结果中证明该功能可以正常开启,虽然对网络指标影响不大,但可以提高用户感知度,避免此类用户投诉行为。
2北京
2.1重点道路优化经验总结
1)_cell_data调低对提升EDGE覆盖率很有帮助。
但是对网络的整体影响需要通过全网或者相关小区的统计来分析。
2)调整小区中_cell_data参数之前一定要保证GPRS和EDGE信道配置的充足性,避免造成用户感知下降。
3)测试中出现PacketTBFrelease(abnormaldl/ulrelease),部分情况下信道可以重新建立起来,有些情况下不行,因而造成数据停传。
所以增加gprs_ms_pan_max值的目的就是为了增大确认计数器,降低TBF异常释放的频率。
具体效果有待分析。
4)测试中对功控参数的调整起到了较大正面作用,但个参数及效果需要进一步研究。
5)平均MCS值低不一定是BEP_period/2和egprs_init_dl/ul_cs参数的影响。
BLER的影响是非常大的。
同样Mean_BEP和CV_BEP的情况下获得的MCS差异极大,就是因为MCS选择还要考虑windowstall、Nack以及编码方式变化频度等几方面因素的影响。
6)目前网络中参数还需要进一步核查,设置值差异较大,比如下行功控部分小区开启、部分未开启。
因此需要做好优化参数模板,并做好核查工作。
FTP测试情况
本周对三方测试线路进行了多次FTP测试,具体情况如下:
测试时间
EDGE覆盖率
尝试下载次数
掉线次数
应用层吞率(KB/s)
均MCS
下行平均时隙数量
说明
11月24日
91.20%
202
0
11.77
7.1
3.29
参数未优化
11月25日
93.40%
220
2
11.98
7.0
3.36
参数已优化
11月27日
94.16%
223
0
11.74
7.1
3.36
参数已优化
可以看出经过前几周的参数优化,DT检查的难点“EDGE覆盖率”和“应用层速率”有了很大提升。
三方路段上GPRS+EDGEFTP测试结果:
FTP吞吐量>95Kbps
EDGE覆盖率>93%
平均时隙数~3.3
平均MCS>7
3福建
3.1NSN设备_DAP拥塞小区优化案例
莆田网络中,全网共有1108个小区配置了dap,部分小区DAP_12较高,其中超过5%接近200个小区,需要优先优化或扩容以降低下行DAP拥塞率。
一般认为,EDAP拥塞达到1.5%,即认为该EDAP需要进行优化以降低EDAP拥塞,改善EGPRS性能。
对于高数据流量的EDGE与GPRS混用小区,EDAP资源紧张并出现拥塞现象,而GPRS占用比例又比较高的小区,由于GPRS用户多,CS2的编码方式会占用DAP资源,也是导致DAP拥塞率上升的原因之一。
DAP拥塞率改善方案:
本次采用CommonBCCH改造来改善小区DAP拥塞率。
12月5日,小区3131进行CommonBCCH改造。
12月5日至12月9日,指标观察阶段
3131小区改造前的一些基本信息如下,取20081202晚忙时(23点)的数据。
CELL_ID
BSCNAME
DAP_ID
DAP时隙数
DAP请求数
DAP拥塞率
gprs流量占比
下行EDGE流量
3131
BSC434
20
5
903839
3.76505
66.90%
11315.4048
在12月5日对该拥塞小区进行CommonBCCH改造,其中一个BTS开EDGE业务,而另一个BTS则只开通GPRS业务,DAP时隙数保持不变。
改造后对一些KPI指标进行跟踪观察。
DAP拥塞率情况:
从上图可以看出,改造后由于减少GPRS用户的CS2对DAP资源的开销,使得DAP请求数明显减少,DAP拥塞率也有较大改善。
其中DAP拥塞率从之前的2.7%左右减少到0.8%左右。
MCS789占用比例:
从上图可以看出,由于原来DAP资源不足,高编码占用比例较低,在减少了部分GPRS用户对DAP资源的占用后,DAP资源则更多的由MCS789高编码比例用户占用。
下行每时隙吞吐量:
同样,在减少部分GPRS用户对DAP资源的占用后,DAP请求数明显减少,高编码比例上升,相应的下行每时隙吞吐量也得到一定程度的提升。
本次CommonBCCH改造的情况来看,对于DAP高拥塞率的GPRS和EDGE混合小区,如果采用CommonBCCH进行改造,特别是对GPRS占用比例较高的小区,可以在一定程度上缓解DAP的拥塞,而且有提升高编码方式的占用比例和单信道吞吐量等益处,对EGPRS网络的性能指标优化有一定的参考价值。
3.2TBF掉线的优化
在日常数据网优化过程中,在KPI统计分析中,发现有部分小区出现大量的TBF掉线。
其主要表现为用户反映上网速度慢且很难上。
另外从指标上看其TBF建立成功率很低,重传率很高。
图1异常小区数据KPI指标
案例分析及解决:
一般对于高TBF掉线我们主要是从无线及硬件上去分析其原因。
这些可以从一些相关的无线话音指标来判断分析。
首先我们对这个小区的语音KPI进行了分析,主要是掉话率,语音质量、干扰。
如果确实无线及硬件问题,如此高的掉线率,那其必然伴随着高语音掉话或SD掉话、很差的语音质量、高干扰等的出现。
下图2为其语音KPI情况,从图上我们可以看出其无线及硬件没什么异常,其语音各项指标良好。
因此排除了其无线及硬件问题。
图2异常小区语音KPI指标
其次我们对对这个小区进行现场测试,主要是想从用户角度去实地核查一下,该小区是否真的高TBF掉线。
并从路测信令上寻找导致高TBF掉线的真正原因。
从实际现场测试发现,该小区FTP下载拨号连接很困难,经常要拨好几次才能连接上网络,从信令看当手机发出’RASDial’指令后,一直收不到网络下发的回应消息,导致接入网络失败。
从现场测试看问题可能出现在数据网本身。
由于仅从现场测试我们无法真正了解导致该小区高TBF掉线的根本原因,只能确定该小区确实存在问题。
随后我们想到了从NSN数据网的相关一些计数器的分析,来对故障进行定位。
我们收集了近20天该小区与数据业务相关P_NBSC_PACKET_CONTROL_UNIT表下所有COUNTER的值,进行分析,结果我们发现其中有一计数器(DISC_LLC_BLOCKS_DUE_TO_EXP)出现异常,其值与TBF掉线率成正比。
该计数器主要是由于超时导致LLC层数据块丢失,其原因主要由以下两方面:
一是本身数据流量负荷过高,高拥塞导致其信令阻塞而超时;二是链路本身问题,导致其无法正常传送数据而超时。
而从我们前面分析的数据关键KPI指标看,该小区数据并不拥塞。
因此肯定是链路本身存在问题。
经过却换NSEI,或是BCSU、重启GENA等手段,可以解决该信令吊死问题。
使得异常TBF掉线得到解决。
3.3MOTO设备_交叉线导致GBL链路负荷异常
1.案例分析背景
GBL接口作为PCU-SGSN重要的接口,这一接口是标准的Gb接口,负责在BSS和GGSN之间传递用户数据(PDU)和信令控制消息(如移动性管理等)。
根据ETSI规范,这一接口采用帧中继做为传输和信令的协议平台。
2.问题描述
由于BSC70504_GBL负荷太大,从而引起GPRS投诉、全曲下载速率慢等问题。
基于负荷大的原因,我们进行了紧急扩容2条GBL,但扩容GBL链路后,采集现网GBL负荷情况,发现GBL的两项指标gbl_dl_data_thrput_mean、gbl_ul_data_thrput_mean的数值为0,为异常现象。
图1异常GBL链路负荷情况
3.分析原理
GBL是通过E1传输连接SGSN,检查传输问题是异常GBL链路负荷情况的关键。
4分析过程
1:
用statepcugbl**查看GBL链路,发现GBL都显示B-U状态;
2:
用statepcudproc**查看PCU的DRPOC硬件,发现所有DPROC都显示B-U状态;
3:
用disp_eqpcugbl20查看GBL_mms为170;用disp_eqpcugbl30查看GBL_mms为160;statepcumms170、statepcumms160,两个mms都显示B-U状态;
4:
从硬件查看情况,可以判定不是PCU的DPROC板硬件故障引起;
5:
从传输DDF架查看GBL20(跳线线性为1、2)、GBL30(跳线线性3、4)传输情况,发现这两条DDF架跳线出现GBL20(跳线线性1、4)、GBL30(跳线2、3)明显交叉现象;
6:
重新焊接DDF架上的跳线,GBL链路负荷不再出现异常现象;
图2正常GBL链路负荷情况
5.取得效果
通过物理上链路链接的排查,异常GBL负荷情况得以解决。
6.案例小结
指标异常必须硬件、传输逐步排查,问题才能得以解决。
4甘肃
4.11800M频段和900M频段小区频繁重选问题讨论
兰州移动自9月份开通1800频段小区以来,市区干扰情况明显好转,部分地区原本拥塞情况得到彻底解决,但由于1800小区参数设置不太合理,导致部分1800小区话务量较少。
并且从IDLE测试和数据业务测试来看1800频段小区和900频段小区重选比较频繁,由于小区重选对数据业务的下载速率影响较大,因此我们需要探讨减少小区重选,提高数据业务的性能。
1、优化前测试情况
优化前对城关区进行了全面的测试,从测试情况来看由于1800频段小区与900频段小区共址,并且功率、天线下倾角等基本一致,在路面上测试到的信号强度基本相同,由于参数设置基本一致,根据小区重选原则,其在IDLE情况下或者是在数据业务测试时重选频繁属于正常情况,但由于频繁重选,当在下载数据时小区重选会导致TBF不断重新关闭、申请。
所以严重影响到FTP的上传、下载等速率。
下图为在南滨河民族中学路段占用民族中学站时的测试采样图:
可以从上图看到占用民族中学后1800频段和900频段的同向小区由于信号强度基本一直,导致最少都会发生2次以上相互重选。
2、现网1800小区重点参数设置情况
现网一共开通98个1800频段的小区,基本参数设置如下:
81个小区放在第一层(17个小区放在第二层),一层小区层门限值大部分设置在60-70间,CRO设置为0,CRH设置为4,ACCMIN设置为100左右,功率设置为43。
每个小区具体设置情况如下:
现参数设置导致的问题
1、由于部分1800小区层门限设置过低,当信号强度低于切换门限时就会切换到更好小区,导致话务过低,没有起到1800小区充分吸收话务的作用。
2、还有17个小区设置在第二层,话务量较低,载波利用率极低。
3、由于兰州城关区的地形和实际情况,根据小区重选原则,在信号强度基本一样的情况下,因重选参数设置基本一致,没有考虑到控制重选问题,所以导致小区重选频繁。
4、试验小区设置情况
根据1800频段优先占用原则,并且考虑到话音业务方面,对民族中学1800频段小区参数修改如下:
CELL
原层
修改层
原层门限
修改层门限
原CRO
修改后CRO
原ACCMIN
修改后ACCMIN
LK2055F
1
1
70
70
0
12
100
85
LK2055G
1
1
68
68
0
12
100
85
LK2055H
1
1
60
72
0
12
100
85
LK2055I
1
1
65
68
0
12
100
85
修改的原则就是尽量提高1800频段的C2值,让其停留在1800频段而不重选到900频段小区。
通过此次参数调整后,南滨河路民族中学路段重选次数明显减少,参数调整后测试数据也证实,此次调整对该路段无论GPRS或者是EDGE业务的承载能力也有显著提高。
这种精细优化的方法可以在全网中的重点道路推行。
5、试验小区优化后测试情况
下图是优化后测试采样图:
优化后测试来看小区重选次数明显减少,即使1800频段小区信号强度明显弱于900频段小区,但由于C2值高于900频段小区依然停留在1800频段上,一方面达到了控制小区频繁重选,另一方面也由于1800频段相对干净,导致下载速率大大提高。
下表为优化前后的话务量
CELL
基站名
载波数
修改前话务量
修改后话务量
优化后载
波利用率
LK2055F
民族中学
4
20.2
22.18
110.07%
LK2055G
民族中学
4
21.26
24.13
119.75%
LK2055H
民族中学
4
5.72
15.96
79.21%
LK2055I
民族中学
4
11.51
14.84
73.65%
从统计来看,话音方面经过调整后吸收话务情况更加合理,载波利用率处在较高状态。
6、对1800频段和900频段小区重选优化的建议
由于1800小区频点干净,并且受到覆盖范围的限制,建议优先给1800频段吸收话音业务和数据业务,但由于小区重选与层设置级别没有任何关系,并且现网1800频段小区和900频段小区重选参数设置基本一致,没有起到数据业务优先的作用。
从试验可以看到减少ACCMIN而加大CRO的目的是为了加大C2值,以达到减少小区重选的目的。
小区重选原则如下:
当手机附着在GPRS系统后,无论是在PacketIdle或者是在PacketTransfer模式下均由手机自动进行小区重选。
小区重选使用C1/C2算法,公式如下:
C1=RLA_C-ACCMIN-max(CCHPWR–P,0)
C2=C1+CRO-TO*H(PT-T)若PT<>31。
C2=C1-CRO若PT=31。
其中H(x)=0(x<0),H(x)=1(x>=0),x=PT–T,T为计时器,ACCMIN,CCHPWR,CRO,TO及PT为由BCCH发布的参数。
由于兰州大部分小区的PT设置为0,TO设置为0,
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 移动 集团 下发 EDGE 优化 案例