EGPRS无线网络资源配置调整原则v31rel.doc

EGPRS无线网络资源配置调整原则 PDCH/AbisExTS部分根据网络结构部门提供的算法撰写

（B10）
1. 概述 1
2. PDCH配置 4
2.1 统计每个小区忙时的PS_Erl 4
2.2 利用爱尔兰S算法计算每个小区需要的PDCH数 5
2.3 计算小区所需CS+PS载频总数 6
2.4 确定PDCH相关配置参数 7
2.5 PDCH配置不足的后果 8
2.5.1 PDCH复用度增加，用户平均速率下降 8
2.5.2 PDCH配置严重不足，将导致TBF建立失败 9
3. ABIS extra TS配置 9
3.1 Abis接口基本配置设计 10
3.2 Abis接口配置优化 12
4. Ater 口的配置 13
4.1 基本配置 13
4.2 扩容Ater 口的选择 13
4.3 扩容Ater 数目的确定 13
5. Gb口的配置 14
5.1 扩容Gb口的选择 14
5.2 Gb 平均流量计算方法： 14
5.3 扩容Gb 带宽数目的确定 15
5.3.1 GBoFR 15
5.3.2 GboIP 15
6. GPU/GP扩容判断 17
6.1 扩容触发标准1： 17
6.2 扩容触发标准2： 17
6.3 重点注意 18

若有疑问可联系 刘鹏 peng.liu@alcatel-
分机4967； 13916929859
1. 概述
GPRS/EDGE网络结构如下图所示：
Mobile Radio
BTS
BSC
Abis
BTS
BTS
TC
Mobile Core Circuit Switching
MSC/VLR
HLR
PSTN
GPRS
PCU
Mobile Core Packet Switching
Gn
Gi
GGSN
SGSN
IP
backbone
Internet / Intranet
空口PDCH配置
Abis资源配置
Ater_PS配置
PCU配置
Gb配置

图表 1：GPRS/EDGE网络网元及接口示意

GPRS/EDGE无线网络资源的配置主要是指对：
- 空口PDCH资源的配置；
- Abis接口E1数量和Extra TS资源的配置；
- Ater_PS接口数量的配置；
- MFS中GPU数量的配置；
- Gb接口数量的配置。
- PCU（GP）配置

配置顺序遵循由下而上（从空中接口到Gb接口）的原则。

GPRS/EDGE网络资源配置的重要性：

GPRS/EDGE网络资源配置直接影响到GPRS/EDGE的网络质量，配置的好坏在很大程度上决定了DT和CQT测试的平均吞吐速率。

影响FTP路测平均吞吐速率的网络因素主要有以下几点

1） 无线环境——包括C/I、接收电平、多径环境、手机移动速率等。
在城市路测中，无线环境为TU50环境，接收电平都比较好，所以决定FTP下载速率的主要是C/I。统计FTP测试中各MCS的占比和重传率情况，可以很好地计算出特定无线环境下的单时隙FTP RLC层吞吐速率VRadioEv。

2） 小区重选——小区重选会导致FTP的中断。
一般情况下，一次小区重选将导致4秒钟左右的数据中断；NACC情况下的小区重选将导致1秒钟以下的数据中断。统计单位时间平均的小区重选次数，以及每次小区重选导致的平均停传时间，就可以得到小区重选时间占总时间的比例，从而计算由于小区重选导致的速率降级因子ΦCR。

3） 资源受限——小区空口、Abis资源以及BSC/MFS的GAter、Gb和GPU（GP）资源受限的情况下都会导致FTP速率的降级。
速率降级因子可以用ΦResourceSharing来表示。一般情况下，GAter、Gb和GPU（GP）资源应该配足，不会成为瓶颈，而小区空口和Abis资源的多少将是决定速率降级的主要原因，也是我们GPRS/EDGE网络配置的重点和难点。配置原则将在下面文档中进行详细讨论。

当然还有其他一些因素：如手机、核心网、FTP服务器以及FTP参数设置等都有可能导致FTP路测速率下降，但在本文档中假设这些因素都没有问题，不导致速率下降。所以，FTP路测的平均吞吐速率可以表述为：

在现场网络设计、规划和优化中，我们根据要求达到的FTP路测速率VRadio,req，可以细分到VRadioEv,req、ΦCR,req和ΦResourceSharing,req三个要求。比较路测得到的VRadioEv、ΦCR和ΦResourceSharing与之对比就可以得到努力的方向（提高无线质量、减少小区重选或是增加PS配置）。

2. PDCH配置

空中接口PDCH配置中，我们需要根据每个小区的数据业务量、MCS比例信息，以及需要达到的QoS要求，来确定每个小区需要配置的PS载频数，并且确定PDCH相关配置参数，如MinPDCH、Max_PDCH和Max_PDCH_High_Load。

2.1 统计每个小区忙时的PS_ERL

小区PS_Erl可以通过OMC-R的GPRS报告取得：

其中，P350a为所有下行Data Block的数量，包括重传和Dummy块；P59为下行控制块的数量；180000为一个PDCH一个小时内可以传送180000个RLC无线块。
注：在计算小区所需PDCH信道数时，之所以使用PS_Erl而不是PS_Mbytes，是因为后者对PDCH信道的占用还受到平均每信道吞吐速率的影响，相比之下，前者更精确。
PS_Erl和PS_MByte有一个经验的对应关系：1PS_Erl = 5PS_Mbytes左右。（下图是对长春现网的一个统计）

图表 2：PS_Erl和PS_Mbytes的对应关系

为了确保取得的PS_Erl代表忙时PS业务量但又要避免极个别时段的“毛刺”，建议：
- 取一周每天8:00至次日凌晨01:00的GPRS报告，每小区计算7*18=126个PS_Erli采样点；
- 将PS_Erli正序排列，去掉前3%的（如：4个）最大异常采样点，去掉后85%的（如：107个）的小流量采样点。剩余12%的（如：15个）采样点取平均得到小区忙时PS_Erl。
2.2 利用爱尔兰S算法计算每个小区需要的PDCH数

爱尔兰S算法讨论的是PS_Erl、PDCH配置数和速率降级因子之间的关系。任意输入其中的两者以及手机占用PDCH时隙数（一般情况下，建议设为4），就可以计算出第三者的值。

图表 3：Erl_S算法示意

爱尔兰S算法经过多次现网验证，是目前我们使用的最接近实际情况的PS容量算法。（下面图中为不同小区在不同PDCH配置下的实测速率降级（蓝色）和爱尔兰S算法（黄色）以及其他算法（红色）的契合度对比）

图表 4：Erl_S算法与实测结果对比

这里我们根据小区的PS_Erl和速率降级因子计算小区所需的PDCH信道数。

速率降级因子（）
重点测试小区
90%
市区小区
80%
农村小区
70%

注：速率降级因子为用户设定的小区PS业务质量等级，代表了允许由于PS共享信道而导致的速率降级，一般取70%~90%。（70%代表允许共享导致速率降低30%；90%代表允许共享导致速率下降10%，速率降级因子越高，要求的PDCH信道数量越多）用户可以区分小区属性，例如：市区/郊区/农村、室内/室外、测试区域/重点区域/普通区域等来确定每个小区允许的速率降级因子。建议对于测试区域，应该进行保证90%的速率降级因子；而对于普通区域，70%应该足够了。

注：需要考虑一定的PS业务增长。一般情况下，PS_MBytes的年增长可以达到200%左右，PS_Erl的增长略少一些，但也在100%以上。如果希望做的PS配置能够满足未来3个月到半年的需求，则需考虑50%左右的PS_Erl增长。

2.3 计算小区所需CS+PS载频总数
在配置PDCH信道之前，必须先考虑小区的总载频数以及CS业务量，以避免由于光考虑PS业务进行PDCH配置后的CS拥塞问题。对于可能产生拥塞的小区应该优先考虑扩容。
考虑CS忙时话务量以及CS业务增长情况、节日效应，根据Erl_B公式计算CS所需信道数TCHreq。（TCH信道具体计算方法这里不做详细讨论）

考虑信令忙时符合以及信令增长情况、节日效应，根据经验公式计算信令所需SDCCH信道数SDCCHreq。（SDCCH信道具体计算方法这里不做详细讨论）
小区总载频数可以计算为：

根据TRXreq进行增减容。

2.4 确定PDCH相关配置参数
1） Max_PDCH_High_Load
建议根据上面计算得到的PDCHreq来设置Max_PDCH_High_Load：

Max_PDCH_High_Load =
重点测试小区

市区小区

农村小区

其中，Nb_TRX为小区现有载频数，如果与需要的信道数相比缺口比较大的话，为了更多地保证CS，所以用两者比值的平方来乘PDCHreq以得到Max_PDCH_High_Load。例如：小区现有载频数为8载频，但经过计算：PDCHreq=18，SDCCHreq=6，TCHreq=52，则TRXreq=10载频。如果小区由于某种原因暂时无法扩容，则信道配置时：Max_PDCH_High_Load=13，为需要数量的72%，而相应剩余的TCH数为8*8-6-13=45，为需求数的87%。对于现有载频数远小于需求数的情况，如小区现有载频数仅有6个，那么根据上面公式，会更多地压缩PS信道，此时Max_PDCH_High_Load=8，为需要数量的44%，而相应剩余的TCH数为8*6-6-8=34，为需求数的65%。

2） Min_PDCH
建议根据小区属性定义Min_PDCH：

Min_PDCH =
重点测试小区
4
市区小区
4
农村小区
2

3） Max_PDCH
建议根据PDCHreq计算Max_PDCH：

Max_PDCH =
重点测试小区

市区小区
农村小区
Max_PDCH数不超过PDCHreq的2倍，也不超过小区总信道数的一半。
注意：即便当现有小区载频数与需求相比缺口较大，从而导致Max_PDCH_High_Load设置远远小于PDCHreq时，仍然建议使用PDCHreq（而不是Max_PDCH_High_Load）的值来计算Max_PDCH。这样，在CS相对不忙的时候，PS仍然有可能得到较大的PDCH数。
注意：要求每个小区支持高功率EDGE的载频模块（如：TRAGE或Twin）数

否则部分PDCH信道可能无法被用于EDGE或虽然能用于EDGE但使用相对较低的8PSK发射功率，从而影响EDGE手机的吞吐速率。

2.5 PDCH配置不足的后果
2.5.1 PDCH复用度增加，用户平均速率下降
复用度增加意味着PDCH的共享程度增加，对应速率降幅度增加。PDCH复用度也是衡量是否需要PDCH扩容的重要指标。一般市区的PDCH复用度控制在1.2~2之间。小区PDCH复用度指标超过1.2~1.5时（门限根据各地情况不同可采用不同标准），然后按照ErlangS进行需要的PDCH数目的评估。
理论上说随着PDCH有效配置数目的增加（指实际分配给GPRS使用的时隙数目），复用度也会线性概率降低。
下行PDCH复用度定义：P451b/P38e
上行PDCH复用度定义：P451a/P38f
由于一般下行业务占主要比例，因此一般考察下行PDCH复用度。

2.5.2 PDCH配置严重不足，将导致TBF建立失败

PDCH配置不足将导致TBF建立失败率增加。归结到P27中（下行为P14）。
以P27的触发条件举例如下：UL TBF无线拥塞原因的失败P27
Counter definition:
Number of UL TBF establishment failures due to a lack of radio resources
Trigger condition:
The counter is incremented whenever an UL TBF establishment fails due to a lack of radio resources. A lack of radio resource occurs:
i) if the maximum number of MSs per slave PDCH in uplink is reached for all the slave PDCHs allocated to the MFS, or
ii) if there is no TAI or TFI left in the MFS.or
iii) if no PDCH are granted to MFS due to a CS congestion and max_pdch_high_load is null.

当出现PDCH拥塞原因的TBF建立成功率失败，PDCH必须进行扩容，将造成一定程度的重复请求，使GP的负荷增加。

3. ABIS EXTRA TS配置

Abis接口容量设计基于BTS级别，因为小区间的Bonus和Extra nibble在BTS的所有载频上进行共享。Bonus Nibble主要取决于BTS的CCCH和SDCCH信道配置数目，而可用的Extra Nibble的大小则由N_Extra_Abis_TS参数的大小决定。
Abis接口容量设计就是要决定Abis E1的数量和N_Extra_Abis_TS参数设值。
Abis接口容量配置可以分设计和优化两种方法——
1） 在调整空口PDCH配置的同时，需要根据Abis接口容量设计结果配置Abis资源
2） 在空口PDCH和Abis资源调整完毕后，根据GPRS报告中Abis的拥塞情况来调整优化Abis接口配置

3.1 ABIS接口基本配置设计
Abis接口配置设计的中心原则是满足空中接口计算得到的TCHreq和PDCHreq的Abis接口要求，使得当TCH/PDCH信道占用数小于等于空口配置数时，Abis接口不会成为瓶颈，这样就可以保证空口配置时的QoS要求。

假设一个BTS包括若干个小区，MCS9一个空口PDCH信道需要4.5个Abis_Nibble与之对应，CS4一个空口PDCH信道需要1.6个Abis_Nibble与之对应，所以需要的Abis_Nibble数与最大MCS/CS有关，假设为K。那么小区i在有PDCHreq个MCS9的空口PDCH占用时，所需的Extra和Bonus Nibble总数Extra_Bonus_Abis_Nibblereq,i为：

由于整个BTS下面的所有小区共享Extra和Bonus Nibble，考虑到共享增益，可以适当少配一些Abis_Extra_TS。可以参考下面公式：

Error! Objects cannot be created from editing field codes. Error! Objects cannot be created from editing field codes.
Error! Objects cannot be created from editing field codes.
其中，Error! Objects cannot be created from editing field codes.为对BTS中所有Error! Objects cannot be created from editing field codes.从高到低排序，然后取第i个。
例如：一个BTS支持4/4/4配置，PDCHreq,1=8，PDCHreq,2=12，PDCHreq,3=6，当最大MCS9时，分别对应Extra_Bonus_Abis_Nibblereq：28、42和21个。假设三个小区总共的Bonus_Nibble为12个，那么Abis_Extra_TS=ROUNDUP[(42+28/2+21/3-12)/4] =13。基本上为1载频对应1根Abis_Extra_TS。

计算整个BTS所需的Abis_TS数目（不包括TS0）：

其中，

注意：使用64k动态复用的时候，对于FR TRX，一个Abis_TS可以复用4个、2个或1个RSL，如果是3个RSL则需要2个Abis_TS来带；对于DR TRX，一个Abis_TS可以复用2个或1个RSL。
最后可以计算出所需的Abis E1数：

内部参考
在B10版本中，MxBSC对于Abis Extra TS配置基本没有限制，但是G2BSC中每2根Abis Extra TS对应一块等效载频，而每个TCU_TSU只能处理32块等效载频。所以在配置Abis Extra TS时，必须考虑这一因素，一旦受限，可以通过对K值进行调整，按比例缩小所有受影响的Abis Extra TS配置。

3.2 ABIS接口配置优化

在Abis接口配置设计中使用了一些经验公式，所以为了更准确地配置Abis资源，需要根据之后的GPRS报告，根据Abis接口的拥塞情况进行配置微调。
一般情况下，当TBF并未出现拥塞时，Abis的拥塞导致TBF速率的下降。为此可以根据Abisnibble的缺乏数Counter来指导Abis nibble 的扩容，以优化TBF的速率。当缺乏数到达一定门限时，即可考虑增加Abis nibble/ExtraTS资源
缺乏数使用Counter P469，最大的AbisGCH的缺乏数目来参考取值，AbisGCH/4为需要增加的ExtraTS 64kbps时隙的数目。（由于该Counter使用到了R_AVERAGE_EGPRS/GPRS两个参数值，所以对这两个参数的修改将导致对Counter值的变化；该两个参数根据用户平时的要求进行适当设置）
对于不同类型的小区，Abis扩容数目，可以考虑不同的冗余比例：
比如，室内微蜂窝，VIP宏站可以扩容数目是Counter指示值的1.2~1.5 倍
一般的小区可以是1~1.2倍，根据现场需要进行该系数调整。
而象西部的一般性非热点地区，给与0.5~0.9的折扣。
当AbisNibble缺乏到某种极限情况下，TBF出现拥塞，可以考察下面两项指标：

当上述值出现时，Abis数目扩容必须进行，以保持网络质量，同时TBF失败率的增加会增加MS TBF的重试量，增加虚拟业务，增加GP负荷。
4. ATER 口的配置

4.1 基本配置
一般初始Ater口的配置，GPU一般配置2~4路Ater（若只有CS1/2，则只需配2路Ater口，CS3/4、EDGE可配3~4路）；
而GP一般初始配置10~12路Ater口（初始情况下配置较多的Ater口冗余可以避免日后工程割接的繁琐；Ater口MxMFS 在工程实施时，应向MxBSC提取时钟，可以使MxMFS Ater的可利用端口不受时钟提取影响）。
然后根据实际网络的Counter 所指示的拥塞情况来进行扩容处理。
4.2 扩容ATER 口的选择
目前，现网判断需要扩容Ater口的标准是根据P383a（Atermux congestion duration (in seconds) due to a lack of GCH transmission resources on the Atermux interface.）和P383b（Time (cumulated over a granularity period) during which the GPU remains in "high" Ater usage）来进行衡量的。
当P383a/36000大于1%(或简化为出现非零值)
或者P383b大于36000的30%~50%时，考虑扩容Ater。
的时候，说明Ater口存在拥塞情况，需要对Ater口进行扩容。
（现场可根据用户对速率的需求情况适当调整门限，同时需要考虑适当频度，然后触发扩容。此处是一般要求，若对速率要求较高则P383b的要求要更严格，即门限小于30%~50%）
4.3 扩容ATER 数目的确定
根据当前占用的平均GCH数目，使用Erlang C表，进行Ater口数目的计算。
当前使用的BSC下的GCH使用数目求和，由P100c进行统计求和，然后输入到Erlang C表中进行计算，得到总GCH需求数目，然后折算到Ater口的数目（可按每专用PS Ater 112个GCH来计算，或根据当地实际配置计算）。（ErlangC工具见GB数目测算一节，可以使用相似的延时阻塞概率来进行GCH需求数目的计算）。
一般来说，工程上采用逐步扩容、尽量多配的原则来进行工程实施。
5. GB口的配置

5.1 扩容GB口的选择
由于下行Gb的拥塞由SGSN控制，因此在无线侧只能通过Gb平均流量来估算Gb是否接近设计容量。当然有些核心网能够统计Bearer Channel 是否拥塞，可以判断Gb是否需要扩容。
一：简单估计法：
当平均占用带宽达到设计带宽70%时，可以考虑进一步带宽扩容。
扩容Gb遵循先扩时隙，扩满时隙后，再扩PCM链路的原则。
二：精确计算法
较为精确的估算方法同样是使用ErlangC表格：（精确计算法）
将需求的平均流量加上15%的冗余，折算成需求业务Erlang数，通过ElangC表可以获得需要 的GB时隙数目。
Measured _GboFR _ traffic= Max(P45,P46)/28800

Number of required Gb TS per link
= Erlang C (Required_GboFR_traffic; pGb)
注：
1 Erlang = [Gb TS speed (64kbps) * 3600] / 8 =28800 K bytes
Minimum 2 Gb links are required for one GP(U) due to security reason
PGb为设定的拥塞概率和延时时延，一般取1%的拥塞概率，0s延时。（使用附件3的公式）

ERLANG C工具：

5.2 GB 平均流量计算方法：
GboFR：P45: Number of Kbytes received from the SGSN
平均带宽占用：(sum（P45）*1024*8)/3600 单位kbps
GboIP：使用P45a代替P45。
5.3 扩容GB 带宽数目的确定
5.3.1 GBoFR
根据用户Gb的资源情况，可以将Gb宽度配置为平均占用的1.2~1.5倍。有条件的可以视情况进一步适当放宽Gb宽度。
但，当用户数据量较小时，在开启EDGE的情况下，每GPU/GP的GB带宽建议最少不能少于480kbps，保证测试时不限制测试手机的最大吞吐速率。（GB链路上的带宽参数设置（CIR，NIR，EBS，CBS等）也不能少于480kbps）
5.3.2 GboIP
在配置为GboIP的情况下，网络结构如下图所示：

如上图所示，Gb接口通过路由器连接到SGSN。对于一个MFS来说，配置一个Gateway地址。因此GB接口容量按照整个相关MFS 的数据流进行计算。
5.3.2.1 从GboverFR到GboverIP的转换的GB带宽的计算
由于P45系列Counter计算的是NS层以上的数据。当计算底层的带宽需求时，需要考虑物理层到NS层的包头大小。
NS/UDP/IP/Ethernet的包头为70Byets（NS/FrameRelay的包头大小为6Byets）。
若假设平均IP PDU 包大小为300byets，则其中70byets为NS以下包头。
当使用GboverIP时，IP 节点间的平均速率按照以下公式进行计算：
DL Data rate [Kbps] = 1.233*(P45a*8)/(3600-P34a)
UL Data rate [Kbps] = 1.233*(P46a*8)/(3600-P34a)
当通过GboverFR来估算GboverIP的带宽需求时，
Estimated DL IP Data rate [Kbps] = (n+70/n+6)*(P45*8)/(3600-P34)
Estimated UL IP Data rate [Kbps] = (n+70/n+6)*(P46*8)/(3600-P34)
（平均NS包大小nByets,一般假定300）
所以一般IP带宽需求至少要比FR带宽高(n+70/n+6)倍，当n=300时，为120.9%
另外由于P45/P46统计的计算结果属于平均带宽，若考虑Gb峰值-均值比约在1.3（各地模型可能不太一致，可根据本地情况进行调整）；
则IPGB的带宽应再预留130%的空间。
故一般来说，只考虑下行方向：
BWIP=120.9%*SUM(BSCi(130%*(P45*8)/(3600-P34))).
5.3.2.2 极限以太网GB带宽需求参考

Using Gigabit Ethernet link to the aggregation Router, we can calculate the extreme loaded case as follows:
For MxMFS
1560 GCHperGP * 16 Kbps = 24.96 Mbps
Assuming all this traffic coming from SGSN for one MxMFS with 21 GP boards we
get:
21 boards*24.96 Mbps = 524.16 Mbps -> Half of the GigaEthernet link capacity.
For Legacy MFS（类推16块板的情况下，为16*24.96Mbps，约为400Mbps）
480 GCHperGP * 16 Kbps = 768 Mbps
Assuming all this traffic coming from SGSN for one MFS DS10 with 30 GPU boards
we get:
30 boards*7.68 Mbps = 230.4 Mbps -> Quarter of the GigaEthernet link capacity.
Congestion is not expected at the level of the link to the aggregation router.
Any Congestion seen afterwards is dependent on bandwidth management of the core IP network.

6. GPU/GP扩容判断
PMU CPU过载总时长：判断GPU需要扩容的标准之一是根据P402（Cumulative time during which the GPU stays in the PMU CPU overload state due to PMU CPU power limitations）来进行衡量的。

一般来说，比如取一周每天最忙时段（2最忙时或4最忙时），下述标准超过忙时时段的20%，建议可以进行扩容。
满足下述条件之一即需要GP/GPU扩容：
6.1 扩容触发标准1：
Max (P201, P202)/3600 or P402/3600 is regularly > 1%.
or If P76a is regularly > 70% ,
then GPU/GP re-dimensioning is required.
（各地网络要求不同，因此可根据情况适当使用过滤条件：
1）调整P76A扩容门限到75%~80%，比如虽然P76a到达门限有一定频繁度，即观察忙时时段，连续出现多少次概率比例（比如时间出现的概率大于10%~20%采实施扩容），
2）同时配合观测话务报告TBF由于GPU拥塞（上行TBF P105f，下行TBF P105e占各自请求的比例）失败率指标超过一定值（5%或其他可以忍受的值），考虑扩容）
6.2 扩容触发标准2：
P384 DSP拥塞出现计数达到一定的频繁程度，也需要考虑扩容。

同样，上述比例若在用户可以忍受的百分比之内，也可暂缓扩容。

但一般来说，出现了GP上述两种情况下的拥塞后，系统处在高负荷运行下，出现不稳定的情况的概率会增加，因此需要重点关注，及时促进用户扩容，以免引起用户对系统稳定性的投诉。

GP/GPU扩容的数目的确定

可根据Ater口GCH的业务量（P100c）和ErlangC工具预测结果，结合每GP/GPU支持的Ater口的数目来进行计算确定。
Ater 口允许扩容的情况下，优先扩容Ater接口（P76a和DSP已经出现拥塞的需要优先扩容GP）。
一般来说，售后工程上采用逐步扩容，逐步观察的工程实施原则来实施GP/GPU的扩容。而预测GP走势，需要网络设计部门的工具来实现预测。

6.3 重点注意

1，由于现网很多情况下会导致异常的EGPRS的TBF的请求，如RA 规划设置不合理，穿越道路频繁，或核心网络故障导致的RA更新成功率低等等原因导致GPU的负荷虚高，这些并非实际业务导致负荷虚高，首先应考虑网络结构的优化调整，信令跟踪分析。Ater 口允许扩容的情况下，优先扩容Ater接口。

2，某些情况下小区PDCH数目不足或Abis_ExtraTS时隙或同时在线的TBF数目太高时，会引起GP的负荷虚高。

比如BSC下某些小区(P35 > 200 or P39 > 200) 同时 (P36 > 180 or P40 > 180),GP负荷也会因此而达到了扩容要求，可采取行为包括：
1， 是否有异常的网络结构干扰，比如RA配置错误，核心网业务异常(attach pdp RA 成功率低)等
2， 需要进行小区资源配置优化，如增加PDCH，增加ExtraAbisTS，Ater接口等，将资源瓶颈打通；减少虚拟负荷；(资源瓶颈会导致TBF不顺畅，引发MS重新尝试、甚至用户重新尝试的虚拟负荷及流量，首先采取措施降低其他原因导致的TBF成功率失败，比如拥塞，P105E/F外的其他P105系列原因的失败)；举例：某地高校较忙GP，试图通过降低MCS编码来降低负荷（限制在MCS4），结果不降反升，因为由于数据拥堵，引起了更高的请求和同时在线数目。
3， 若上述措施执行后，同时在线TBF数仍然没有改善，则应考虑增加新小区，来减少每个小区的负荷，以此减轻GP负荷。

3，同时要注意到GPU之间的负荷是否均衡，必要时进行GPU Reshuffle（B10MR2 由于FR限制禁止Reshuffle，可用Reinital代替）后再进行负荷观察和判断。