EGPRS无线网络资源配置调整原则v3.1-rel

EGPRS无线网络资源配置调整原则PDCH/AbisExTS部分依据网络结构部门供应的算法撰写（B10）1. 概述 12. PDCH配置 42.1 统计每个小区忙时的PS_Erl 42.2 利用爱尔兰S算法计算每个小区须要的PDCH数 52.3 计算小区所需CS+PS载频总数 62.4 确定PDCH相关配置参数 72.5 PDCH配置不足的后果 82.5.1 PDCH复用度增加，用户平均速率下降 82.5.2 PDCH配置严峻不足，将导致TBF建立失败 93. ABISextraTS配置 93.1 Abis接口基本配置设计 103.2 Abis接口配置优化 124. Ater口的配置 134.1 基本配置 134.2 扩容Ater口的选择 134.3 扩容Ater数目的确定 135. Gb口的配置 145.1 扩容Gb口的选择 145.2 Gb平均流量计算方法： 145.3 扩容Gb带宽数目的确定 155.3.1 GBoFR 155.3.2 GboIP 156. GPU/GP扩容推断 176.1 扩容触发标准1： 176.2 扩容触发标准2： 176.3 重点留意 18若有疑问可联系刘鹏peng.liu@alcatel-sbell分机4967述GPRS/EDGE网络结构如下图所示：MobileRadioMobileRadioBTSBSCAbisBTSBTSTCMobileCoreCircuitSwitchingMSC/VLRHLRPSTNGPRSPCUMobileCorePacketSwitchingGnGiGGSNSGSNIPbackboneInternet/Intranet空口PDCH配置Abis资源配置Ater_PS配置PCU配置Gb配置图表SEQ图表\*ARABIC1：GPRS/EDGE网络网元及接口示意GPRS/EDGE无线网络资源的配置主要是指对：空口PDCH资源的配置；Abis接口E1数量和ExtraTS资源的配置；Ater_PS接口数量的配置；MFS中GPU数量的配置；Gb接口数量的配置。PCU（GP）配置配置依次遵循由下而上（从空中接口到Gb接口）的原则。

GPRS/EDGE网络资源配置的重要性：GPRS/EDGE网络资源配置干脆影响到GPRS/EDGE的网络质量，配置的好坏在很大程度上确定了DT和CQT测试的平均吞吐速率。影响FTP路测平均吞吐速率的网络因素主要有以下几点：无线环境——包括C/I、接收电平、多径环境、手机移动速率等。 在城市路测中，无线环境为TU50环境，接收电平都比较好，所以确定FTP下载速率的主要是C/I。统计FTP测试中各MCS的占比和重传率状况，可以很好地计算出特定无线环境下的单时隙FTPRLC层吞吐速率VRadioEv。小区重选——小区重选会导致FTP的中断。 一般状况下，一次小区重选将导致4秒钟左右的数据中断；NACC状况下的小区重选将导致1秒钟以下的数据中断。统计单位时间平均的小区重选次数，以及每次小区重选导致的平均停传时间，就可以得到小区重选时间占总时间的比例，从而计算由于小区重选导致的速率降级因子ΦCR。资源受限——小区空口、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配置）。PDCH配置空中接口PDCH配置中，我们须要依据每个小区的数据业务量、MCS比例信息，以及须要达到的QoS要求，来确定每个小区须要配置的PS载频数，并且确定PDCH相关配置参数，如Min_PDCH、Max_PDCH和Max_PDCH_High_Load。统计每个小区忙时的PS_Erl小区PS_Erl可以通过OMC-R的GPRS报告取得： 其中，P350a为全部下行DataBlock的数量，包括重传和Dummy块；P59为下行限制块的数量；180000为一个PDCH一个小时内可以传送180000个RLC无线块。注：在计算小区所需PDCH信道数时，之所以运用PS_Erl而不是PS_Mbytes，是因为后者对PDCH信道的占用还受到平均每信道吞吐速率的影响，相比之下，前者更精确。PS_Erl和PS_MByte有一个阅历的对应关系：1PS_Erl=5PS_Mbytes左右。（下图是对长春现网的一个统计）图表SEQ图表\*ARABIC2：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。利用爱尔兰S算法计算每个小区须要的PDCH数爱尔兰S算法探讨的是PS_Erl、PDCH配置数和速率降级因子之间的关系。随意输入其中的两者以及手机占用PDCH时隙数（一般状况下，建议设为4），就可以计算出第三者的值。图表SEQ图表\*ARABIC3：Erl_S算法示意爱尔兰S算法经过多次现网验证，是目前我们运用的最接近实际状况的PS容量算法。（下面图中为不同小区在不同PDCH配置下的实测速率降级（蓝色）和爱尔兰S算法（黄色）以及其他算法（红色）的契合度对比）图表SEQ图表\*ARABIC4：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增长。计算小区所需CS+PS载频总数在配置PDCH信道之前，必需先考虑小区的总载频数以及CS业务量，以避开由于光考虑PS业务进行PDCH配置后的CS拥塞问题。对于可能产生拥塞的小区应当优先考虑扩容。考虑CS忙时话务量以及CS业务增长状况、节日效应，依据Erl_B公式计算CS所需信道数TCHreq。（TCH信道具体计算方法这里不做具体探讨）考虑信令忙时符合以及信令增长状况、节日效应，依据阅历公式计算信令所需SDCCH信道数SDCCHreq。（SDCCH信道具体计算方法这里不做具体探讨）小区总载频数可以计算为： 依据TRXreq进行增减容。确定PDCH相关配置参数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%。Min_PDCH建议依据小区属性定义Min_PDCH：Min_PDCH=重点测试小区4市区小区4农村小区2Max_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手机的吞吐速率。PDCH配置不足的后果PDCH复用度增加，用户平均速率下降复用度增加意味着PDCH的共享程度增加，对应速率降幅度增加。PDCH复用度也是衡量是否须要PDCH扩容的重要指标。一般市区的PDCH复用度限制在1.2~2之间。小区PDCH复用度指标超过1.2~1.5时（门限依据各地状况不同可采纳不同标准），然后依据ErlangS进行须要的PDCH数目的评估。理论上说随着PDCH有效配置数目的增加（指实际安排给GPRS运用的时隙数目），复用度也会线性概率降低。下行PDCH复用度定义：P451b/P38e上行PDCH复用度定义：P451a/P38f由于一般下行业务占主要比例，因此一般考察下行PDCH复用度。PDCH配置严峻不足，将导致TBF建立失败PDCH配置不足将导致TBF建立失败率增加。归结到P27中（下行为P14）。以P27的触发条件举例如下：ULTBF无线拥塞缘由的失败P27Counterdefinition:NumberofULTBFestablishmentfailuresduetoalackofradioresourcesTriggercondition:ThecounterisincrementedwheneveranULTBFestablishmentfailsduetoalackofradioresources.Alackofradioresourceoccurs:i)ifthemaximumnumberofMSsperslavePDCHinuplinkisreachedforalltheslavePDCHsallocatedtotheMFS,orii)ifthereisnoTAIorTFIleftintheMFS.oriii)ifnoPDCHaregrantedtoMFSduetoaCScongestionandmax_pdch_high_loadisnull.当出现PDCH拥塞缘由的TBF建立胜利率失败，PDCH必需进行扩容，将造成肯定程度的重复恳求，使GP的负荷增加。ABISextraTS配置Abis接口容量设计基于BTS级别，因为小区间的Bonus和Extranibble在BTS的全部载频上进行共享。BonusNibble主要取决于BTS的CCCH和SDCCH信道配置数目，而可用的ExtraNibble的大小则由N_Extra_Abis_TS参数的大小确定。Abis接口容量设计就是要确定AbisE1的数量和N_Extra_Abis_TS参数设值。Abis接口容量配置可以分设计和优化两种方法——在调整空口PDCH配置的同时，须要依据Abis接口容量设计结果配置Abis资源在空口PDCH和Abis资源调整完毕后，依据GPRS报告中Abis的拥塞状况来调整优化Abis接口配置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和BonusNibble总数Extra_Bonus_Abis_Nibblereq,i为： 由于整个BTS下面的全部小区共享Extra和BonusNibble，考虑到共享增益，可以适当少配一些Abis_Extra_TS。可以参考下面公式：EMBEDEquation.3Error!Objectscannotbecreatedfromeditingfieldcodes. EMBEDEquation.3Error!Objectscannotbecreatedfromeditingfieldcodes. EMBEDEquation.3Error!Objectscannotbecreatedfromeditingfieldcodes.其中，EMBEDEquation.3Error!Objectscannotbecreatedfromeditingfieldcodes.为对BTS中全部EMBEDEquation.3Error!Objectscannotbecreatedfromeditingfieldcodes.从高到低排序，然后取第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动态复用的时候，对于FRTRX，一个Abis_TS可以复用4个、2个或1个RSL，假如是3个RSL则须要2个Abis_TS来带；对于DRTRX，一个Abis_TS可以复用2个或1个RSL。最终可以计算出所需的AbisE1数：

内部参考在B10版本中，MxBSC对于AbisExtraTS配置基本没有限制，但是G2BSC中每2根AbisExtraTS对应一块等效载频，而每个TCU_TSU只能处理32块等效载频。所以在配置AbisExtraTS时，必需考虑这一因素，一旦受限，可以通过对K值进行调整，按比例缩小全部受影响的AbisExtraTS配置。Abis接口配置优化在Abis接口配置设计中运用了一些阅历公式，所以为了更精确地配置Abis资源，须要依据之后的GPRS报告，依据Abis接口的拥塞状况进行配置微调。一般状况下，当TBF并未出现拥塞时，Abis的拥塞导致TBF速率的下降。为此可以依据Abisnibble的缺乏数Counter来指导Abisnibble的扩容，以优化TBF的速率。当缺乏数到达肯定门限时，即可考虑增加Abisnibble/ExtraTS资源。缺乏数运用CounterP469，最大的AbisGCH的缺乏数目来参考取值，AbisGCH/4为须要增加的ExtraTS64kbps时隙的数目。（由于该Counter运用到了R_AVERAGE_EGPRS/GPRS两个参数值，所以对这两个参数的修改将导致对Counter值的改变；该两个参数依据用户平常的要求进行适当设置）对于不同类型的小区，Abis扩容数目，可以考虑不同的冗余比例：比如，室内微蜂窝，VIP宏站可以扩容数目是Counter指示值的1.2~1.5倍一般的小区可以是1~1.2倍，依据现场须要进行该系数调整。而象西部的一般性非热点地区，给与0.5~0.9的折扣。当AbisNibble缺乏到某种极限状况下，TBF出现拥塞，可以考察下面两项指标：

当上述值出现时，Abis数目扩容必需进行，以保持网络质量，同时TBF失败率的增加会增加MSTBF的重试量，增加虚拟业务，增加GP负荷。Ater口的配置基本配置一般初始Ater口的配置，GPU一般配置2~4路Ater（若只有CS1/2，则只需配2路Ater口，CS3/4、EDGE可配3~4路）；而GP一般初始配置10~12路Ater口（初始状况下配置较多的Ater口冗余可以避开日后工程割接的繁琐；Ater口MxMFS在工程实施时，应向MxBSC提取时钟，可以使MxMFSAter的可利用端口不受时钟提取影响）。然后依据实际网络的Counter所指示的拥塞状况来进行扩容处理。扩容Ater口的选择目前，现网推断须要扩容Ater口的标准是依据P383a（Atermuxcongestionduration(inseconds)duetoalackofGCHtransmissionresourcesontheAtermuxinterface.）和P383b（Time(cumulatedoveragranularityperiod)duringwhichtheGPUremainsin"high"Aterusage）来进行衡量的。当P383a/36000大于1%(或简化为出现非零值)或者P383b大于36000的30%~50%时，考虑扩容Ater。的时候，说明Ater口存在拥塞状况，须要对Ater口进行扩容。（现场可依据用户对速率的需求状况适当调整门限，同时须要考虑适当频度，然后触发扩容。此处是一般要求，若对速率要求较高则P383b的要求要更严格，即门限小于30%~50%）扩容Ater数目的确定依据当前占用的平均GCH数目，运用ErlangC表，进行Ater口数目的计算。当前运用的BSC下的GCH运用数目求和，由P100c进行统计求和，然后输入到ErlangC表中进行计算，得到总GCH需求数目，然后折算到Ater口的数目（可按每专用PSAter112个GCH来计算，或依据当地实际配置计算）。（ErlangC工具见GB数目测算一节，可以运用相像的延时堵塞概率来进行GCH需求数目的计算）。一般来说，工程上采纳逐步扩容、尽量多配的原则来进行工程实施。Gb口的配置扩容Gb口的选择由于下行Gb的拥塞由SGSN限制，因此在无线侧只能通过Gb平均流量来估算Gb是否接近设计容量。当然有些核心网能够统计BearerChannel是否拥塞，可以推断Gb是否须要扩容。一：简洁估计法：当平均占用带宽达到设计带宽70%时，可以考虑进一步带宽扩容。扩容Gb遵循先扩时隙，扩满时隙后，再扩PCM链路的原则。二：精确计算法较为精确的估算方法同样是运用ErlangC表格：（精确计算法）将需求的平均流量加上15%的冗余，折算成需求业务Erlang数，通过ElangC表可以获得须要的GB时隙数目。Measured_GboFR_traffic=Max(P45,P46)/28800NumberofrequiredGbTSperlink=ErlangC(Required_GboFR_traffic;pGb)注：1Erlang=[GbTSspeed(64kbps)*3600]/8=28800KbytesMinimum2GblinksarerequiredforoneGP(U)duetosecurityreasonPGb为设定的拥塞概率和延时时延，一般取1%的拥塞概率，0s延时。（运用附件3的公式）ERLANGC工具：Gb平均流量计算方法：GboFR：P45:NumberofKbytesreceivedfromtheSGSN平均带宽占用：(sum（P45）*1024*8)/3600单位kbpsGboIP：运用P45a代替P45。扩容Gb带宽数目的确定GBoFR依据用户Gb的资源状况，可以将Gb宽度配置为平均占用的1.2~1.5倍。有条件的可以视状况进一步适当放宽Gb宽度。但，当用户数据量较小时，在开启EDGE的状况下，每GPU/GP的GB带宽建议最少不能少于480kbps，保证测试时不限制测试手机的最大吞吐速率。（GB链路上的带宽参数设置（CIR，NIR，EBS，CBS等）也不能少于480kbps）GboIP在配置为GboIP的状况下，网络结构如下图所示：如上图所示，Gb接口通过路由器连接到SGSN。对于一个MFS来说，配置一个Gateway地址。因此GB接口容量依据整个相关MFS的数据流进行计算。从GboverFR到GboverIP的转换的GB带宽的计算由于P45系列Counter计算的是NS层以上的数据。当计算底层的带宽需求时，须要考虑物理层到NS层的包头大小。NS/UDP/IP/Ethernet的包头为70Byets（NS/FrameRelay的包头大小为6Byets）。若假设平均IPPDU包大小为300byets，则其中70byets为NS以下包头。当运用GboverIP时，IP节点间的平均速率依据以下公式进行计算：DLDatarate[Kbps]=1.233*(P45a*8)/(3600-P34a)ULDatarate[Kbps]=1.233*(P46a*8)/(3600-P34a)当通过GboverFR来估算GboverIP的带宽需求时，EstimatedDLIPDatarate[Kbps]=(n+70/n+6)*(P45*8)/(3600-P34)EstimatedULIPDatarate[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))).极限以太网GB带宽需求参考UsingGigabitEthernetlinktotheaggregationRouter,wecancalculatetheextremeloadedcaseasfollows:ForMxMFS1560GCHperGP*16Kbps=24.96MbpsAssumingallthistrafficcomingfromSGSNforoneMxMFSwith21GPboardsweget:21boards*24.96Mbps=524.16Mbps->HalfoftheGigaEthernetlinkcapacity.ForLegacyMFS（类推16块板的状况下，为16*24.96Mbps，约为400Mbps）480GCHperGP*16Kbps=7.68MbpsAssumingallthistrafficcomingfromSGSNforoneMFSDS10with30GPUboardsweget:30boards*7.68Mbps=230.4Mbps->QuarteroftheGigaEthernetlinkcapacity.Congestionisnotexpectedatthelevelofthelinktotheaggregationrouter.AnyCongestionseenafterwardsisdependentonbandwidthmanagementofthecoreIPnetwork.GPU/GP扩容推断PMUCPU过载总时长：推断GPU须要扩容的标准之一是依据P402（CumulativetimeduringwhichtheGPUstaysinthePMUCPUoverloadstateduetoPMUCPUpowerlimitations）来进行衡量的。一般来说，比如取一周每天最忙时段（2最忙时或4最忙时），下述标准超过忙时时段的20%，建议可以进行扩容。满意下述条件之一即须要GP