GAter和GPU资源配置评估及优化建议专题.docx
《GAter和GPU资源配置评估及优化建议专题.docx》由会员分享，可在线阅读，更多相关《GAter和GPU资源配置评估及优化建议专题.docx（18页珍藏版）》请在冰点文库上搜索。
GAter和GPU资源配置评估及优化建议专题
资源配置评估及优化建议专题
G-Ater/GPU资源专题
2009-3-12
AlcatelLucent
目录
1.概述3
2.现网资源负荷评估3
2.1G-Ater资源负荷评估方法3
2.2湖州现网G-Ater口资源负荷情况3
2.3GPU/GP负荷评估5
3.G-Ater资源配置算法6
3.1G-Ater资源配置算法介绍6
3.2G-Ater资源配置算法验证6
3.3三种算法比较小结9
4.G-Ater资源配置建议9
4.1G-Ater资源高负荷但不过载配置建议9
4.2G-Ater资源负荷不均衡配置建议11
4.3G-Ater资源拥塞参数调整建议12
4.4G-Ater资源负荷区域配置建议13
4.5G-Ater资源负荷预测配置建议14
5.GPU/GP资源配置14
5.1GPU/GP资源配置算法15
5.2GPU/GP资源配置建议15
6.小结16
7.附件16
1.概述
G-ATER口是连接BSC与GPU之间的接口，是数据业务传输侧的重要通道；GPU是数据业务处理单元，是保证数据业务的核心单元。
如果G-Ater出现负荷过高，会导致客户感知度下降，最直接的表现形式是速率的降低；如果GPU出现过载会影响网络的稳定性。
本专题主要针对G-Ater口容量和GPU负荷，结合湖州现网实际资源比较紧张的情况，进行一个详细的分析，从G-Ater口负荷评估的多个角度考虑，选取更适合湖州情况的算法进行验证。
同时也将对GPU负荷评估算法进行说明。
2.现网资源负荷评估
湖州现网共有MFS7套，其中MXMFS4套，主要分布在城区，G2MFS4套；BSC67套；GPU75块，GP27块；G-Ater口共计552条，详细拓扑结构请参见附件1。
1
2
1
2
2.1G-Ater资源负荷评估方法
现网一般判断G-Ater口拥塞的两个重要BSC指标为P383a和P383b，这两个Counter表征G-Ater口的负荷情况，其中，P383b是在G-Ater口负荷高于高负荷门限值的时候计数，而P383a是在G-Ater口出现拥塞的时候计数。
通常情况下当P383b/36000>30%就建议扩容G-Ater口。
而P383a一旦出现拥塞就必须进行G-Ater口扩容。
表格1G-Ater口扩容标准
G-Ater口资源评估项
判断准则
建议
G-Ater口拥塞标准
P383a/36000>0.1%
扩G-Ater传输
P383b/36000>30%
Counter说明：
【P383a】：
G-Ater口拥塞时长
【P383b】：
G-Ater口高负荷时长
2.2湖州现网G-Ater口资源负荷情况
依照上述判断依据，湖州现网G-Ater口出现高负荷和拥塞的共有以下42个BSC，按照负荷级别可分为三类BSC，16个G-Ater口拥塞的BSC，26个G-Ater高负荷的BSC和普通BSC，详见下表：
表格2G-Ater口负荷情况
类型
判定标准
涉及BSC
高负荷
P383a/36000<=0.1%
P383b/36000>0
UZBSC028HUZ,UZBSC045HUZ,UZBSC052DEQ,UZBSC010DEQ,
UZBSC014CHX,UZBSC019HUZ,UZBSC020CHX,UZBSC041DEQ,
UZBSC008HUZ,UZBSC026CHX,UZBSC030HUZ,UZBSC032HUZ,
UZBSC033ANJ,UZBSC035CHX,UZBSC036CHX,UZBSC037ANJ,
UZBSC038HUZ,UZBSC039HUZ,UZBSC040DEQ,UZBSC042ANJ,
UZBSC047HUZ,UZBSC051DEQ,UZBSC066DEQ,UZBSC053CHX,
UZBSC059CHX,UZBSC062HUZ
拥塞
P383a/36000>0.1%
UZBSC002HUZ,UZBSC006CHX,UZBSC011ANJ,UZBSC012CHX,
UZBSC015HUZ,UZBSC016ANJ,UZBSC009HUZ,UZBSC023HUZ,
UZBSC025DEQ,UZBSC034HUZ,UZBSC042ANJ,UZBSC049HUZ,
UZBSC055HUZ,UZBSC057DEQ,UZBSC058ANJ,UZBSC060HUZ
普通
P383b/36000=0
其余BSC
三类BSC在地域分布上也存在差异，如下图：
高负荷的BSC主要集中在主城区和覆盖范围较广的郊区，拥塞BSC则集中分布在几个主要的城镇及人口密集的高校和火车站附近。
针对此类G-Ater口高负荷和拥塞情况的相应处理方案，在后续章节中将分别提供详细优化建议。
图表1G-Ater口负荷区域分布
2.3GPU/GP负荷评估
对于GPU/GP负荷而言，判断拥塞的主要标准为P76a和P77a的计数，一般当P77a大于95的时候说明在这一时段里GPU/GP即将出现过载的情况，如果P76a大于750，则说明该BSC平均负荷达到高负荷警戒门限。
表格3GP/GPU扩容标准
GPU负荷评估项
判断准则
建议
GPU拥塞标准
P76a>750
扩GPU/GP
P77a>95
根据以上判断标准，湖州现网有2个BSC存在GPU负荷过高，具体扩容方案和需求预测将在后面的段落详细介绍：
表格4高负荷GPU列表
BSC
GPU
ATER
晚忙时
早忙时
P76a
P77a
P402
P76a
P77a
P402
UZBSC051DEQ
1-17
4
707
95
0
757
100
140
UZBSC055HUZ
3-3
12
887
100
2430
711
86
0
3.G-Ater资源配置算法
根据以往经验，通过流量比例算法得到的G-Ater口需求对资源要求较高，而块数比例算法的结果又偏于保守，针对湖州目前资源状况，我们提出第三种从现网资源负荷角度出发的算法，并加以验证，同时详细分析三种方法各自的优缺点，寻求最适合湖州的负荷评估算法。
3
3
3.1G-Ater资源配置算法介绍
【流量比例算法】
∑（CS1~MCS9流量占比×各应编码方式对应的GCH数）×MAX_PDCH_HIGH_LOAD
将CS1到MCS9个编码的数据流量（P55系列Counter×各编码码长）所占总流量的比例×CS1到MCS9各编码方式下需求的GCH数相加得到一个小区内平均每个PDCH所占用GCH的个数，再乘以小区配置的MAX_PDCH_HIGH_LOAD数，得到所需的GCH总个数，再将得到GCH总个数目除以112（一条2M线所带的GCH个数），最终的结果就是现网所需要的G-Ater口数目。
【块数比例算法】
∑（CS1~MCS9块数占比×各应编码方式对应的GCH数）×MAX_PDCH_HIGH_LOAD
将CS1到MCS9个编码的数据块数（P55系列Counter）所占总块数的比例×CS1到MCS9各编码方式下需求的GCH数相加得到一个小区内平均每个PDCH所占用GCH的个数，再乘以小区配置的MAX_PDCH_HIGH_LOAD值，得到所需的GCH总个数，再将得到GCH总个数目除以112（一条2M线所带的GCH个数），最终的结果就是现网所需要的G-Ater口数目。
【网络负荷算法】
用实际占用的GCH个数P100f×130%，得到所需的GCH总个数，再将得到GCH总个数目除以112（一条2M线所带的GCH个数），最终的结果就是现网所需要的G-Ater口数目。
3.2G-Ater资源配置算法验证
【流量比例算法特点】
流量比例算法，在G-Ater口扩容的评估中具有最高的确保性，通过流量比例算法计算出来的结果去配置G-Ater口可以基本完全消除拥塞，因为G-Ater资源中的GCH的占用是基于RLC块的编码方式来的，如果按照流量比例来进行GCH折算的话，对应于高阶编码方式（如：
MCS9等）的GCH信道占用比例是最高的，所以基于流量比例对每PDCH进行GCH的折算，其计算结果提供了最大的余量冗余。
但是这个算法适合资源充足的地区使用。
【块数比例算法特点】
针对这一情况，我们从块数比例的角度出发，即不同编码方式的RLC块对应不同的GCH消耗情况（如下表），所以RLC块对应Gater口资源是有它更符合实际占用情况，并且同样可以消除G-Ater口的拥塞，最为关键的是将资源的需求降至最低，充分利用有限的资源。
但是，这种算法会受到外部因素影响，如果配置的Max_PDCH、MAX_PDCH_HIGH_LOAD和Min_PDCH参数设置不合理的话，就会造成MAX_PDCH_HIGH_LOAD个数与实际占用的不匹配，会出现预测结果偏小的情况，即出现拥塞BSC的预测值基本与现网配置的情况相等，即现网不需要进行G-Ater扩容。
虽然前一种流量比例算法也会存在此类情况，但是由于流量比例算法提供足够的增量冗余，所以此类情况基本不会出现。
【网络负荷算法】
由于以上两种算法均不能适应湖州G-Ater口扩容的要求，我们提出第三种方法，从BSC现网实际G-Ater口负荷着手计算，即从现网对GCH资源的已有的需求量计算。
因为前文介绍过，当G-Ater口实际占用超过配置的负荷门限值（Ater_Usage_Threshold，现网70%~80%）的时候，P383b开始计数，因此要想满足G-Ater口不拥塞的前提是将负荷控制在70%以内。
根据这一原则，将出现拥塞的BSC实际GCH占用数（P100f）乘以130%，根据计算的结果扩容，可以降低负荷至门限以下，并且不会造成资源的浪费。
【三种算法统计结果对比】
从三种算法结果的对比表格上看，部分BSC用流量比例算法预测的结果较现网配置高出一倍以上，如UZBSC012CHX，UZBSC015HUZ和UZBSC060HUZ，这样虽然可以完全保证拥塞的消除，但是其资源所提供的冗余度过大，对湖州现网资源不是太充裕的情况来说有一定的浪费。
块数比例算法虽然资源控制的比较好，但是部分出现拥塞的BSC用此方法评估却不需要扩容，如UZBSC009HUZ，UZBSC025DEQ和UZBSC034HUZ，这样的预测结果又偏于保守，从下表可以看出块数比例算法计算出的结果和现网配置基本接近，而且从此类BSC的G-Ater拥塞情况来看，其在忙时的统计周期内仅出现过瞬间的拥塞（P383a），如：
UZBSC009HUZ仅出现过2秒种的拥塞，UZBSC025DEQ出现过6秒钟的拥塞，UZBSC034HUZ出现过4秒钟的拥塞，所以此类算法适合在资源极度匮乏的地区使用，可以最大程度利用资源的同时将拥塞的影响降至最低。
综合考虑，用现网实际负荷去评估湖州G-Ater口资源才是较为理想的方法，将消除拥塞和资源控制很好的结合在一起。
表格5三种算法结果对比
BSC
P100f
P383a
P383b
块数比例算法
现网配置P101
网络负荷算法
流量比例算法
UZBSC012CHX
328
560
34970
552
336
426
751
UZBSC015HUZ
218
360
35880
396
224
283
524
UZBSC060HUZ
638
6740
35960
987
644
829
1235
UZBSC009HUZ
325
20
36000
322
332
423
378
UZBSC025DEQ
216
60
36000
210
224
281
261
UZBSC034HUZ
208
40
34940
213
216
270
258
3.3三种算法比较小结
三种方法，在实际使用中各有长短，综合考虑，使用网络负荷算法更适合湖州现网情况。
流量比例算法是在资源比较充足的情况下，提供了较大的冗余量，而块数比例算法偏保守。
表格6三种算法优势对比
特性
算法
准确性
简单性
资源控制
预测算法
外部影响
流量比例算法
准确
一般
偏大
适合
无
块数比例算法
准确
一般
偏小
适合
PDCH参数设置的合理性
网络负荷算法
准确
简单
合理
不适合
无
因此，对于湖州而言，建议使用网络资源算法对G-Ater口扩容，有如下几点优势：
✓简单适用，适合日常优化中使用；
✓配置合理，充分利用G-Ater口资源；
✓符合扩容原则，不受外部影响。
4.G-Ater资源配置建议
根据2月底至三月初的早晚忙时数据分析，湖州现网共有42个BSC存在不同程度的G-Ater口负荷拥塞及高负荷的情况。
在湖州资源比较紧张的情况下，需要做到在尽量少扩容的同时，通过参数的合理调整达到资源的优化配置。
4
4.1G-Ater资源高负荷但不过载配置建议
高负荷但不过载的BSC从指标上看，P383b有计数但P383a没有计数。
此类BSC在一个小时内出现过高负荷情况，但是未发生过载。
当G-Ater口负荷超过门限值的时候MFS通过降低每PDCH分配的GCH个数，达到降低G-Ater口负荷的目的。
降低多少是由小区级参数GCH_RED_FACTOR_High_Ater_Usage决定的，该参数现网的默认设置为0.75，这就意味着当出现负荷过高的时候，每个PDCH实际分配到得GCH只有原来的3/4。
从客户感知度上看，当BSC出现G-Ater口高负荷的时候，最高理论速率只能达到180Kb/S以内。
举例说明：
MAX_EGPRS_MCS=MCS-9
GCH_RED_FACTOR_High_Ater_Usage=0.75
当ATER口负荷在门限值（Ater_Usage_Threshold）以下的时候所，分配的GCH个数Target_Nb_GCH=1×4.39+1×4.39+1×4.39+1×4.39=17.96，最高理论速率59.2×4=236.8Kb/S；
当ATER口负荷超过门限值（Ater_Usage_Threshold）的时候，所分配的GCH个数Target_Nb_GCH=0.75×4.39+0.75×4.39+0.75×4.39+0.75×4.39=13.47，因为每PDCH分配的GCH个数减少，最大只能满足MCS7的编码方式，最高理论速率为44.8×4=179.2Kb/S。
虽然没有发生过载，但是在速率上却大打折扣。
为保障数据业务的速率，现网必须将G-Ater口负荷控制在门限值以下。
通过调整BSC级参数Ater_Usage_Threshold是最有效的消除高负荷的方法。
在第一个专题中曾经提出一批此类BSC，建议修改Ater_Usage_Threshold值从默认的70调整到80。
修改之后P383b计数明显降低，绝大部分BSC的G-Ater口负荷已经低于门限值。
表格7专题一中高负荷不过载BSC
BSC_NAME
改前P383b
现网P383b
BSC_NAME
改前P383b
现网P383b
UZBSC020CHX
22830
0
UZBSC005ANJ
31170
0
UZBSC018HUZ
23920
0
UZBSC060HUZ
36000
0
UZBSC032HUZ
10000
0
UZBSC061HUZ
36000
0
UZBSC043CHX
1770
0
UZBSC063HUZ
33250
0
UZBSC046ANJ
14960
0
UZBSC064CHX
36000
0
UZBSC048CHX
36000
0
UZBSC065HUZ
11570
0
UZBSC050ANJ
36000
0
UZBSC066DEQ
22210
0
UZBSC054HUZ
3280
0
UZBSC004DEQ
21380
0
G-Ater口负荷过高给速率带来的影响是编码方式降低导致的速率打折，从指标上看，G-Ater口拥塞还会造成小区级TBF建立成功率降低，而与之相关的两个小区级指标为P105g和P105h，分别对G-Ater口拥塞导致的上下行TBF失败计数。
此类TBF建立失败并不计算在BSS和无线拥塞等原因里面，在日常优化中需要特别留意。
Counter说明：
【P105h】：
由于G-Ater口拥塞造成的上行TBF建立失败的个数
【P105g】：
由于G-Ater口拥塞造成的下行TBF建立失败的个数
现网高负荷但不拥塞的BSC共有26个，建议调整BSC参数Ater_Usage_Threshold。
表格8高负荷不过载的BSC调整建议
操作
BSC
调整参数
Ater_Usage_Threshold
70->80
UZBSC028HUZ,UZBSC045HUZ,UZBSC052DEQ,UZBSC010DEQ,
UZBSC014CHX,UZBSC019HUZ,UZBSC020CHX,UZBSC041DEQ,
UZBSC008HUZ,UZBSC026CHX,UZBSC030HUZ,UZBSC032HUZ,
UZBSC033ANJ,UZBSC035CHX,UZBSC036CHX,UZBSC037ANJ,
UZBSC038HUZ,UZBSC039HUZ,UZBSC040DEQ,UZBSC042ANJ,
UZBSC047HUZ,UZBSC051DEQ,UZBSC066DEQ,UZBSC053CHX,
UZBSC059CHX,UZBSC062HUZ
4.2G-Ater资源负荷不均衡配置建议
现网上还存在另一种情况，当BSC下带多块GPU/GP的时候，会出现G-Ater口负荷不均衡的现象，即一块GPU/GP有P383a或P383b的计数，其他几块没有。
有计数的GPU/GP会出现上文提到的拥塞，速率打折等影响，而未计数的GPU/GP有可能很空闲，造成资源的浪费。
出现这种情况的原因主要是每块GPU/GP上小区的分布不均衡，从搜集的数据来看，现网有以下5个BSC存在此类现象，同一个BSC下，不同GPU/GP带的小区的数目最大可以相差一到两倍，G-Ater口的实际占用也相差很多，这就必然导致一块GPU/GP很忙，而另一块很闲的情况。
最有效的解决办法就是对BSC进行RE-Shuffle操作以达到小区数相当，数据业务均衡的目的。
表格9需要进行RE-Shuffle操作的BSC列表
BSC
GPU
ATER
P100f
P383b
小区数
操作
UZBSC009HUZ
1-19
3
135
0
3
RE-Shuffle
1-20
3
325
36000
10
UZBSC023HUZ
0-17
2
133
0
13
RE-Shuffle
1-14
2
209
36000
18
1-6
2
166
3280
16
UZBSC057DEQ
3-10
9
623
0
30
RE-Shuffle
3-12
9
811
35950
81
UZBSC058ANJ
3-1
12
608
0
41
RE-Shuffle
3-11
12
943
35960
44
UZBSC060HUZ
3-13
13
638
0
58
RE-Shuffle
3-3
13
1101
35960
65
4.3G-Ater资源拥塞参数调整建议
在以上方法充分利用了G-Ater资源，如果G-Ater还存在一定的拥塞情况，建议如下的BSC参数设置建议：
【GPRS_MULTISLOT_CLASS_DEF_VALUE】：
✓参数作用：
手机接入网络初始所分配的信道数，即在网络侧无法获知手机多时隙级别时候，给手机分配的默认信道数。
✓参数建议：
1
【T_GCH_INACTIVITY】：
✓参数作用：
GCH释放延迟时间，该参数原先为了加快接入而预留的GCH资源，对于G-Ater资源负荷拥塞的情况下再预留GCH资源是较为浪费的。
✓参数建议：
1
【T_GCH_INACTIVITY_LAST】：
参数作用：
最后一个GCH释放延迟时间，该参数适合T_GCH_INACTIVITY配合使用的。
✓参数建议：
5
4.4G-Ater资源负荷区域配置建议
在湖州资源紧张的情况下，我们必须针对不同的小区提出不同的扩容方案。
首先对全网的小区进行保障等级划分，三个等级分别代表保障小区，重点小区和普通小区，划分的标准是依照小区的重要程度以及巡检测试的可能性制定的（移动用户提供，详见附件2）。
再结合当前G-Ater口的负荷情况，制定参数修改方案和扩容方案。
确保G-Ater口拥塞消除的同时也不影响重点小区的数据业务速率。
具体参数优化方案如下：
【保障小区】
建议采取硬件扩容的的方式，即扩容G-Ater口，并适当调整BSC级参数GCH_RED_FACTOR_High_Ater_Usage（0.75->0.85），目的是在突发的高负荷情况下也能首先保证保障小区的速率；
【普通小区】
普通小区因为没有测试的压力，而且覆盖的地区基本为郊区和人口稀少的偏远山区，用户对数据业务的速率并不十分敏感，与其让这部分BSC出现拥塞而导致TBF建立成功率降低，不如主动的降低这部分BSC对资源的消耗。
可以参考以下几个方法，适当降低资源的消耗：
Ø降低GCH_RED_FACTOR_High_Ater_Usage参数从默认的0.75到0.5。
这样调整的目的是在出现G-Ater口高负荷的时候大幅降低资源的分配，延缓拥塞的发生；
Ø降低初始编码方式。
编码方式越高对应的资源消耗也就越大，MCS1的编码方式下只需要1个GCH资源，而MCS9下，却需要4.5个GCH，郊区用户主要以位置更新为主，有效的数据业务并不多，适当的降低初始编码方式在节约了资源的同时，不会对网络造成太大的影响；
Ø降低每TBF分配的最大PDCH个数MAX_PDCH_PER_TBF。
现网手机大多为CLASS4（3+1）和CLASS8（4+1）模式，即最大支持3个或者4个下行PDCH加1个上行PDCH，降低该参数进一步降低了资源的分配。
对于这部分普通小区的具体调整建议如下，供参考：
表格10小区参数修改建议
小区参数修改建议
参数说明：
【Ater_Usage_Threshold】：
GPU的G-Ater口高负荷门限。
【GCH_RED_FACTOR_High_Ater_Usage】：
当G-Ater口处于高负荷状态后每个PDCH分配的GCH的个数
4.5G-Ater资源负荷预测配置建议
随着数据业务的与日俱增，资源的需求也逐渐成为关注的焦点，其中G-Ater口的资源是数据业务的重中之重，如何预测G-Ater口的需求也成为日常优化中比较重要的一个环节。
上文介绍的三种方法中，块数比例算法和流量比例算法都适用于预测，两者的区别在于流量比例算法保留的余量较大，而块数比例算法更贴近实际。
在资源较为紧缺的情况下，我们建议采用块数比例算法。
在预测的过程中，首先需要预测MAX_PDCH_HIGH_LOAD值，具体的预测方法在
升级会员 