EDGE DT下载速率优化思路和案例汇总.doc

EDGE DT下载速率优化思路和案例汇总一、 概述由于数据业务KPI指标体系尚不完全，现实中运营商往往对数据业务路测（包括DT/CQT）的下载速率往往更加重视，对这方面的考核和要求也更高。这些需要网规网优将网络规划和优化到合理的程度。在搬迁后我们针对DT/CQT下载速率方面做了很多的优化工作，本文总结了数据业务DT下载速率优化过程中常规的优化手段以及实际案例。资源类规划和优化由于介绍较多，本文不做叙述。二、 路测分析思路三、 主要问题1. 小区重选和位置区、路由区更新较多在DT的FTP测试中，除了资源和链路质量外，小区重选也是影响速率的一个因素。由于目前的GPRS/EGPRS还是小区重选而没能实现切换，发生小区重选的时候TBF必然中断，需要在新的小区重新建立TBF，而目前没有开通NACC功能的情况下小区重选的时间一般在5秒左右，这样每发生一次小区重选，上层的业务就会中断一定的时间，因此在DT测试的时候要尽量减少小区重选的影响。小区重选频繁或位置区、路由区更新的主要原因有：1) 小区覆盖不合理首先要尽量保证小区覆盖的合理性，过覆盖、弱覆盖、针尖效应、拐角效应等问题都可能导致小区覆盖不合理，从而造成不必要的重选，也会对网络造成干扰，降低无线环境。因此良好的RF优化是小区覆盖合理的基础。但是在实际的网络中，DT路经的小区不可能都是所有条件都满足的，对于条件相对不好的小区尽量避免选入、条件好的小区较长时间的驻留、避免乒乓重选、整体上小区重选次数减少、整体上保证所选入小区平均速率最优。2) RA/LA规划不合理由于在数据传输过程中跨PCU的小区重选，PCU侧是必然丢包的，这样有一定的几率会导致上层的数据的中断，时间长的话超过3分钟无数据下载导致掉线，因此对于DT测试路线上的相邻小区尽可能配置在同一个PCU内，这样可以减少丢包的概率。尽量避免将RA/LA设置在话务密集区域和交通繁忙区域。3) 参数设置不合理邻区关系设置不合理、重选参数设置不合理等都有可能导致重选次数过多。例如漏加邻区、CRH设置过小、PANMAX设置过小等。可以通过合理设置ACCESS_MIN、CRO、TO 、PT、CRH等参数来达到控制小区重选的目的，在特定的情况下还可以通过删除部分小区BA1表中部分邻区频点以避免选入没有必要选入的小区，来减少小区重选造成的业务中断。4) 由于无线环境或手机自身原因导致的邻区解码不全无线环境也对小区重选产生一定的影响。比如虽然有邻区信号很强，但是由于干扰原因其小区信息解不全，因而不能准确计算出C2。不同的手机解码能力不一样，同样的无线环境不同的终端对邻区的解码结果也不完全一样。2. 无线环境复杂，频率干扰导致网络底噪较高在测试路线上小区存在干扰，会导致RLC数据块重传，影响整体速率。由于EGPRS对C/I的要求更高，因此DT对测试区域整体的无线质量提出了更高的要求，整网频率、信道配置、功控、话务均衡等都要求优化好。Um口的质量主要受接收电平、C/I、上下行链路平衡的影响，Um口质量对FTP速率的影响主要包括两个方面：一个是编码方式，另一个是空口重传率。编码方式越高，Um口单信道的吞吐率就越高，Um口质量越好，系统就可以根据绑定到的PCIC数选择更高的编码方式，FTP的吞吐率就越高；重传率越高，说明实际的有效吞吐率越低，空口的带宽都用在了无效的重传上，Um口质量越好，其重传率就越低，有效的吞吐率就越高。在资源满足的情况下，测试过程中，EGPRS编码方式主要是由MS上报的测量报告中MEAN BEP和CV BEP的值来决定的，这两个值反映了无线的接收质量，MEAN BEP为0到31，CV BEP为0到7，都是值越高说明无线质量越好。另外在实际路测中往往会看到下行C/I正常，但BLER较高造成重传块或控制块多导致速率低。我们可以利用nastar软件对频点规划进行检查，检查上下行接收质量、上行干扰带分布、上下行紧急切换比例、上下行平衡等话统以及上行频点扫描等手段来判断干扰或硬件问题。必要时安排射频人员至现场基站进行干扰排查。建议单独对PDCH信道做频率规划（网络规模较小时，建议配置在主BCCH上，但是要注意低BTS版本时高速情况下可能会造成邻区BSIC无法解码，见相关预警），必须配置在TCH上时建议PDCH所在TCH载频不参与跳频。3. EDGE信道数目不稳定问题信道数目不稳定的原因有：1) 动态PDCH被语音业务抢占通常默认设置为语音业务优先，因此当忙时测试时往往会造成语音业务抢占动态PDCH，导致PDCH被释放。可以通过增加静态PDCH或修改为数据业务优先方式来进行优化。2) PDCH信道失步，导致被释放信道失步的原因很多，例如传输质量问题、数据配置错误、软件版本bug以及一些未知原因等。在BTSV100R001C07B236之前版本可能会出现PDCH信道失步的问题，主要有四类：A、 BSC6000与双密度BTS配合问题导致的信道失步；B、 BTS3006跨机柜导致的信道失步；C、 在时钟不稳情况下上行TRAU帧号跳变导致信道失步D、 PCU数据配置错误。例如某几块RPPU板上的主链路E1端口故障，数据被删除后副链路没有配置同步时隙，导致信道出现失步现象。该问题在副链路上配置同步时隙后解决。其中前两类通过升级BTS版本至BTSV100R001C07B236可以解决。第三类问题需要升级到BTSV100R001C07B239或BTS3000V100R001C07B416解决。4. 各接口资源不足各类资源不足，包括PDCH复用过多、占用PDCH少、空闲时隙不足、PCIC资源不足、Gb口资源不足等。其中PDCH复用过多可以在TEMS里观察时隙占用的other比例。由于这方面内容是主要优化内容，相关材料介绍较多，这里就不再阐述。5. 合理设置信道类型PDCH配置较多、必须配置在两块或两块以上载频时，建议按照信道类型进行分类，分别设置为GPRS普通类型和EGPRS普通信道类型，一方面可以提升EGPRS的性能（可以避免GPRS用户对EGPRS用户的影响，主要是G上对E下的影响，此时E下也只能使用GMSK调制方式），另一方面可以节约Abis接口及Pb接口的资源（配置为GPRS信道类型的PDCH只能用作GPRS，单个GPRS信道最多只需要两条PCIC，只需要额外绑定1条空闲时隙）。6. 合理配置小区数据这里的参数主要指PCU里面的一些参数，具体的参数介绍可以看PCU的开局指导书，这里重点介绍几个常用的参数。1) cspara 表cspara表是配置信道编码方式（CS）动态调整算法的参数。小区的CS可以设置固定值，即采用固定的编码方式，也可以设置动态的CS方式，即网络根据小区的无线质量情况和包的重传等信息进行动态调整CS的方式。通常情况下把上下行编码方式都设置为非固定的，上行初始编码方式设置为CS2,下行初始的编码方式设置为CS4，如果小区的无线环境不好可以适当的降低初始编码方式。此参数表在进行EGPRS CQT测试时，不需要修改。2) EGPRSPara表EGPRSPara表是配置EGPRS小区信道编码方式（MCS）动态调整算法的参数，小区的编码方式（MCS）可以设置固定值，即采用固定的编码方式，也可以设置动态的编码方式（MCS）方式，即网络根据小区的无线质量情况和包的重传等信息进行动态调整MCS的方式。 在无线环境较好的小区，可以适当的提高初始编码方式。在进行EGPRS CQT测试时，需要把设置为MCS9，以减少CQT测试时的爬坡时延。3) pdchpara 表pdchpara表为小区TBF使用PDCH信道的配置信息，跟动态PDCH转换和系统容量有关。通常可以根据小区的用户情况来合理配置此表，如果小区用户数较少，为了提高单用户的吞吐率可以降低信道的复用度，如果小区用户数比较多，为了避免拥塞，可以提高信道的复用度。通常情况下为了避免拥塞，上行TBF的上限数目还是设置为7，下行TBF的上限数目设置为8。4) gprs表gprs表为小区的系统消息基本配置表，包括是否支持EGPRS，T3168，T3192等。在gprs中，和CQT相关的有以下几个参数： 该参数设置的越小，MS就很有可能在PCU返回上行确认消息之前，又一次重传等待超过的RLC数据块，这样就会导致资源的无效占用率增加。 该参数设置的越大，滑动窗口移动的效率会降低，而且上行TBF传输进入倒计数的概率增加，这样反而会降低上行传输效率。 该参数和MS到PCU的传输延时相关，在现网中，MS到PCU的传输时延一般为200ms，此时该参数至少设置为10，对于传输时延超过200ms的小区，可以设置为15，例如卫星小区。Pan类参数包括PanDec、PanInc、PanMax，主要影响小区重选，按开局指导书要求，依次配置为2、4、12即可。软参类：g_ulPreConnectPcicNum此参数为每条PDCH激活后默认绑定的PCIC数目，对于GPRS来说，在单块RPPU单板上配置的PDCH数目小于110条的时候，可以配置为2，即每条PDCH激活后默认绑定的PCIC数为2，可以直接使用CS4的编码方式，有利于提升速率，如果单块RPPU单板上配置的PDCH数目大于110条，设置为2后就会出现第111条PDCH信道无法激活的情况（单板的PCIC以及到达上限）。同理，开通EGPRS的情况下，如果单块RPPU单板上配置的PDCH数目不超过55条，且传输资源足够，此参数就可以设置为4，如果单块RPPU单板上配置的PDCH大于55条，就需要根据具体的数目和相应的场景来设置此参数。总之，在资源足够的情况下把此参数设置较大可以提升速率，如果资源不足，此参数设置较大就可能会出现部分信道由于绑定不了PCIC而不可用的情况，因此需要根据资源及场景来合理设置此参数。在进行EGPRS CQT测试时，可以将此值设为4，提高传输速率。7. 其他原因其他如单线程下载、SIM卡开户信息不正确、FTP服务器故障、测试电脑软件更新、手机多时隙能力等原因都可能造成下载速率慢。其中FTP服务器问题、SGSN侧问题等需要与交换工程师和业软工程师共同定位。这方面案例其他资料也较多。四、 实际案例1. 邻区漏加导致重选频繁【现象描述】在北塘路上俞家潭基站至小商品市场基站间连续发生小区重选及RAU，由于小区重选必然导致数据断流，而RAU时间较长也会导致不能迅速开始数据业务。【问题分析】回访测试log，MS占上俞家潭DCS-1后继续向东边行驶，俞家潭DCS-1信号开始衰落，邻区列表中城北村-3信号最强，当持续超出CRH后MS重选到城北村-3，MS占上城北村-3后邻区关系列表中解码出小商品市场-2信号为-51dbm，很快就重选到小商品市场-2，由于小商品市场-2与城北村-3不在同一个RA下，因此需要做一次RAU。因此产生疑问：在车速较快的情况下，MS为什么不直接从俞家潭DCS-1重选到小商品市场-2？这样可以减少一次重选。在俞家潭DCS-1邻区列表里面没有看到小商品市场-2，怀疑俞家潭DCS-1没有加小商品市场-2的邻区。经检查，确认没有俞家潭DCS-1没有添加小商品市场-2和小商品市场DCS-2的邻区。【处理过程】添加从俞家潭DCS-1到小商品市场-2和小商品市场DCS-2的邻区。【建议和总结】邻区关系是否合理、是否存在漏加多加的情况同样适用于GPRS优化。由于GPRS没有单独针对邻区组之间的参数，调整CRH会影响周边所有小区，可以通过删除邻区关系来避免不合理的重选，但也不要出现因为邻区漏加导致增加重选。因此调整邻区关系显得非常必要。2. 频率干扰导致下载速率低【现象描述】MS占上高田大酒店-2后下载速率低。【问题分析】可以看出，在占用4个时隙的情况下，由于C/I不到20、只能使用MCS-7的编码方式，RLC层最高下载速率仅为120kbps。该小区主BCCH为94号频点，怀疑周边存在频率干扰，导致重传率较高。打开上行频点扫描功能，看到95号频点存在非常强的信号，直接导致94号频点上行受到非常强的邻频干扰。【处理过程】将高田大酒店-2频点从94修改为73。由于是锁频测试，开始时在3小区覆盖位置速率较慢，随后测试最高下载速率可达到234kbps。注：红色部分为1M文件下载完毕、TBF释放后处于断传状态。【建议和总结】同样道理，金苑大厦-1也存在强邻频干扰，导致下载速率偏慢。频率干扰导致C/I差无法使用高编码方式，或即使强制使用高编码方式也会因为BLER差、重传率过高而降低编码方式。由于路测只能检测出下行干扰，上行干扰往往需要通过话统和上行频点扫描等功能来检测。我们通常可以利用的话统有上下行平衡测量、上下行质量测量、上行干扰带分布、上下行质量/电平切换比例。3. MCU故障GAbis口失步后GPRS无法上网【现象描述】有用户反映际下基站（CI：61571,RAC:FD,lac:22930，PCU93A）GPRS无法上网。实测发现手机可以附着到网络，但无法进行数据连接。SGSN是N厂家的设备。在话统上看RLC层平均吞吐率很低，几乎没有有效数据块。上下行TBF统计显示无信道资源原因导致建立失败或建立成功后释放较多；下行RLC统计显示CS1重传率很高（甚至达到70），无法占上CS2；G-Abis口统计有大量丢帧，并且bsc-lapd统计该站所在lapd链路有异常。跟踪Pb信令，发现下行立即分配拒绝很多。【原因分析】GPRS无法上网首先要检查gcell、PDCH使用状态，随后检查Gb/Pb/G-Abis（PCIC/lapd链路等）状态。从该小区G-Abis口统计有大量丢帧以及bsc-lapd统计该站所在lapd链路有异常可以初步判断是传输故障问题。【处理过程】1、mt gcel show state 61571 检查小区状态正常（bsc/Gb均为解闭状态）；2、mt pdch show state 61571 all 检查发现该小区pdch状态不稳定，信道不同步与可用状态交替；3、mt pdch show avail 0 all 统计RPPU板上pdch数目没有超过120条4、mt pcic show unavail 4 检查120条pcic全部可用（该RPPU板只配1条E1）；5、mt lapd show state 检查lapd链路全部正常无告警，延时普遍在100ms左右；6、pcu check cellconfig 小区数据添加正常；7、pcu check e1exchange 正常，随后人工检查e1slot配置、e1/pcic对应数据、e1时钟配置等都正确，排除数据配置错误可能性（且该小区原本可以上网，并没有修改过数据）；8、1）mt bvc ptp reset 复位ptp bvc 2）mt gcell reset 复位cell数据业务 3）复位基站 复位后问题仍然存在；9、BSC侧更换端口、更换BSC至DDF架传输后问题（图中1、2、3部分）仍然存在；10、基站及BSC均无时钟失锁告警；11、到基站后测量光缆光功率，输入输出均正常，确认光缆无问题（图中45之间）；12、更换了BTS侧MCU板（BTS3002C是光纤直接接入MCU板），以确认基站侧传输光口是否有问题（即图中8），更换后GPRS业务正常，信道状态正常。RLC/TBF/G-ABIS/LADP统计均无异常。 【建议与总结】1、就本次问题来说，由于MCU侧光口故障导致PCM失步，PDCH信道状态不稳定，不同步与可用状态交替。MS Attach正常，当用户申请业务时，由于信道状态不稳定导致立即指配失败，话统就计成无信道资源失败，即使分配成功也因为无法占用上而出现无信道资源的异常释放。2、信道不同步通常是由于传输问题所引起，建议对G-Abis口链路、bsc-lapd链路进行统计，配合确认是否有链路问题。3、可以看出，数据业务对于传输质量的要求比语音业务高很多，本问题中，语音业务完全正常，而GPRS业务无法使用。4、传输问题很多，建议按照以上过程分别进行排障，而不是直接更换MCU或TMU（根据不同BTS产品）。 4. 畈里张空闲时隙不足导致编码方式低【现象描述】观察PCU告警发现畈里张-2和畈里张-3小区相对频繁出现PDCH中继调整失败(告警ID1735)，且告警原因值为2，查告警信息意思为空闲时隙不足。【问题分析】畈里张配置现网配置信息小区名称载频数静态PDCHSDCCHTCH动态PDCH空闲时隙数畈里张-178542078畈里张-2585242畈里张-37363610该站配置了3条传输2M，PDCH总数是31个。按照实际的空闲时隙需求事31393个，实际配置78个，时隙明显不足。【问题处理】空口要达到高速的编码方式不仅需要RPPU单板能力支持，还需要空口质量满足要求以及Abis口有足够的空闲时隙。Abis口的空闲时隙是以基站为单位的，即分配该站点的空闲时隙能够被该基站上的所有小区共享。在初始配置情况下，每条PDCH信道固定绑定一条PCIC，CS1/CS2编码方式下每条PDCH仅需要1条PCIC，不需要额外绑定PCIC，当使用CS3/CS4的编码方式的时候就需要额外绑定1条PCIC，Abis口需要配置1条空闲时隙，开通EDGE就需要配置更多的空闲时隙。编码方式 CS1CS2CS3CS4MCS1MCS2MCS3MCS4MCS5MCS6MCS7MCS8MCS9Abis口分配16K时隙数 1+01+11+21+3每条E1有32个64K时隙，每个64K时隙分为4个16K子时隙。空闲时隙就对应着这样的16K子时隙。每基站有1条OML链路，每载频需1条RSL链路。在2:1中继模式下，OML与RSL采用2:1复用。因此设置AROUNDUP(（1站点载频数）/2)，每个静态PDCH、动态PDCH、TCH各占用1个16K子时隙。因此站点能配置的最大空闲时隙数124E1数目A4配置为静态PDCH、动态PDCH、TCH时隙数之和。畈里张基站剩余的空闲时隙=124*3-10*4-133=199。实际需要的空闲时隙=(8+8+3+10+2)*3=93个，可见畈里张基站空闲时隙不足，不足以实现MCS9的编码方式，速率也就上不去。由于剩余的时隙满足要求，故直接增加空闲时隙即可。5. EGPRS license不足导致PDCH无法初始化【现象描述】从上下行TBF建立统计中观察新大楼-3小区TBF建立尝试次数为0，维护台上用mt pdch show state 805 all 命令看，显示如下信息：小区 : 805PDCHNo : 4操作状态 : 不可用可用状态 : 设备未初始化BSC的管理状态 : 解闭BSC闭塞的原因 : 未知操作维护的管理状态 : 解闭连接的PCIC数目 : 0可用的PCIC数目 : 0连接的PCIC状态 : 信道未使用PCIC【问题分析】信道可用状态为：设备未初始化（device has not been initialized）PCU不能从BSC申请得到PDCH。通常有如下几种情况： (1) 动态PDCH还未向BSC申请（比较常见）；(2) 向BSC申请PDCH失败。申请PDCH失败的原因有BTSM配置失败、联网失败、PCIC不可用、信道已被电路业务使用、信道已经联网、没有可用的Abis接口时隙。 【问题处理】使用 mt gcell show state 805 观察GPRS小区状态正常。检查该小区pdch配置为14个静态pdch，所以排除动态pdch转换的情况。使用 mt pcic show unavail all 没有发现不可用pcic，检查Abis时隙和端口正常。由于此前已经发现EGPRS license超出限制，因此怀疑是全网开通EGPRS后EGPRS license受限导致EGPRS 普通信道无法激活。临时关闭一个EGPRS TBF尝试次数很少的小区后，新大楼-3小区PDCH正常激活。【问题建议】数据业务需求增长迅猛，EGPRS需求大大增加，特别是如果客户要求替换后全部开通EGPRS，相应的EGPRS license也需要增加。6. 解决公园口-2小区BCCH载频上行损耗大问题【现象描述】在自由路段测试中发现当重选到公园口-2小区后，接入时延较长，造成数据断流。【问题分析】通过检查上下行平衡话统，发现公园口-2BCCH载频TRX8的上下行平衡等级十一的比例最大时为27.85，上行损耗较大。【处理过程】上站检查硬件连线，发现BCCH载频射频连续松动，将其拧紧。再次检查话统，公园口-2BCCH载频上下行信号已经恢复平衡。统计时间统计对象等级六的比例等级七的比例等级八的比例等级九的比例等级十的比例等级十一的比2007-4-14（调整前）公园口-2,TRX号:811.5224.1815.77.974.9427.852007-4-16（调整后）公园口-2,TRX号:820.7325.8423.1412.993.652.12在自由路上进行测试，重选到公园口-2小区后，已经能快速接入。7. PDCHPARA参数修改减少TBF拥塞【问题描述】BSC136朱池-0 PDCH信道配置为1静5动，由于TBF尝试次数较多，个别时段TBF拥塞率较高（3月27日晚22:00达到16的拥塞率）。由于该小区语音业务也很忙，增加静态PDCH可能会导致语音业务拥塞。【处理过程】检查现网设置PDCHPARA设置为4 8 3 4，也就是说上行每PDCH可复用4个TBF，下行每PDCH可复用8个TBF，当上行TBF超过3个时PCU向BSC申请动态PDCH，当下行TBF超过4个时PCU向BSC申请动态PDCH。考虑到该小区动态PDCH较多，需要尽快申请动态PDCH，其次可以通过增加PDCH复用数来尽量让更多的MS接入，从而增大TBF并发数，减少TBF拥塞。具体命令为：Pcu set pdchpara 209 7 8 2 2。修改后当上下行TBF数达到2个以上就申请动态PDCH，并且上行PDCH可复用7个TBF，尽可能接入更多上行TBF。【处理结果】3月28日17:50修改完以上参数。可分上下行来对比修改效果：日期timeCI上行TBF建立尝试次数上行TBF建立成功次数上行平均并发TBF数无信道资源导致上行TBF建立失败次数上行TBF拥塞率3-2421:0015372723271013.315130.18%3-2422:001537211012107384.9631101.00%3-2521:0015372686267772.86820.03%3-2522:0015372985497083.675230.23%3-2621:0015372659064802.91410.02%3-2622:0015372995697824.014230.23%3-2721:0015372855183993.814280.33%3-2722:001537215091145646.0323112.06%3-2821:0015372714570143.53100.00%3-2822:0015372912089884.51910.01%上行TBF复用数从4修改到7、上行动态PDCH门限申请从3修改为2后，在建立尝试次数相当的情况下，上行TBF拥塞次数大大减少，平均并发TBF数有所提高。最终提高了接入性能。日期时间cellname下行TBF建立尝试次数下行TBF建立成功次数下行TBF建立成功率无信道资源导致下行TBF建立失败次数下行TBF拥塞率下行平均并发TBF数TCH话务量3-2421:00朱池-0364535480.973641.7555.51130.5333-2422:00朱池-0495045350.9163286.6268.08618.3333-2521:00朱池-0332332500.978280.8425.08332.9713-2522:00朱池-0410239450.961561.3656.54619.4813-2622:00朱池-0417540250.964842.0116.67820.2113-2721:00朱池-0392837520.9551253.1826.06731.7863-2722:00朱池-0674455590.824108116.02910.52218.0453-2821:00朱池-0385637240.965651.6855.73832.1883-2822:00朱池-0427940310.9421683.9267.30821.415下行动态PDCH申请门限修改效果与TCH话务量高低密切相关。当语音话务量高、无空闲TCH时，由于语音业务优先，即使门限修改也无法申请到动态PDCH。在语音话务量下降时，提前申请动态PDCH，相近的TBF尝试次数下可以复用更多的TBF。【问题建议】本例解决方案适用于一些仅有少量TBF拥塞或动态PDCH较多的小区。其根本解决方案还是扩容载频，增加静态PDCH，解决语音和数据两方面需求。8. SGSN与PCU间RA不一致导致RAU失败【现象描述】某搬迁局PCU入网后，在进行跨区移动测试时会出现RAU失败，无法再次上网。测试发现：在华为PCU的小区和M厂家PCU的小区之间进行移动切换时，会出现RAU失败的情况；具体情况如下：（1）、从LAC 22290（M厂家区域，归属SGSN9）切换到LAC 22555（华为区域，归属SGSN4），RAU失败（2）、从LAC 22555（华为区域，归属SGSN4）切换到LAC 22290（M厂家区域，归属SGSN9），RAU失败（3）、从LAC 22553（M厂家区域，归属SGSN9）切换到LAC 22555（华为区域，归属SGSN4），RAU失败（4）、从LAC 22555（华为区域，归属SGSN4）切换到LAC 22553（M厂家区域，归属SGSN9），RAU失败【原因分析】从故障表现看，华为区域和M厂家区域之间双向RAU均不成功。故障定位到位置区更新，应为SGSN端数据配置不当。网优中心立刻联系省公司进行了相关数据核对，核对发现的问题如下：1) DNS上的华为PCU1470和PCU1471下的LAC 22555；对应的SGSN为SGSN9，而实际上PCU1470和PCU1471配置在SGSN4下。2) DNS上关于PCU 相关配置信息如下：PCU规划LACRACSGSNPCU105（M厂家）2229019PCU43（M厂家）2255319PCU1470（华为）2255514PCU1471（华为）2255514而实际现网中各PCU的配置信息如下：PCU规划LACRACSGSNPCU105（M厂家）2229019PCU43（M厂家）2255319PCU1470（华为）2255504PCU1471（华为）2255504PCU1470和PCU1471的RAC信息不一致从以上分析可知，本次某局地区数据业务投诉主要是由于核心侧DNS数据配置不当造成。造成这种数据核心侧和无线侧不一致的情况主要原因如下：A. PCU归属SGSN位置不当：某局地区共有2个SGSN；根据省公司原有原则： 郊县PCU均挂接在SGSN9下，某局市区PCU均挂接在SGSN4下；分公司申请新增PCU时提供覆盖区域，由省公司确定归属SGSN，并完成数据配置。但是本次新增的华为PCU1470、PCU1471、PCU1480、PCU1481、PCU1490、PCU1491、PCU1492均配置SGSN4下。原有M厂家各PCU均在SGSN9 下。B. 利旧LAC在DNS侧的数据未能及时修改：本次华为割接各PCU中的LAC有部分是现网中没有的LAC（新增），有一部分是利用现网中已有的LAC（利旧）；目前已上网的华为区域各PCU的LAC数据如下:PCULACRACSGSNLAC是新增还是利旧PC增2255504利旧PC增2255504利旧PC增2253104新增PC增2253104新增PC增2253104新增14新增PC旧2253004新增2253204新增PC旧114新增2253004新增2253204新增114新增PC旧2252914新增2253004新增2253114新增2253204新增其中因22555和22462为原来已有数据，故在DNS中已配置了相关数据，但因SGSN归属原来为SGSN9，本次调整后并未及时进行DNS数据更新，依然保持为SGSN9，这与实际PCU配置到SGSN4不一致。C. PCU中RAC和DNS中的RAC配置不一致：前期所有PCU的RAC全部默认为1，但新增华为PCU的RAC做了变动，部分PCU的RAC调整为非1的值。但这些信息并未及时通知省公司进行更新。导致省公司直接默认将这些LAC对应的RAC都配置为1，与PCU配置数据不符。【处理过程】根据以上发现结果，省公司对核心网侧DNS相关数据修改如下：1) 将LAC 22555对应SGSN号由SGSN9修改为SGSN4；2) PCU1470和PCU1471对应RAC由1修改为0；完成以上参数修改后，再次进行现场测试，测试情况一切正常。【建议与总结】根据对本次故障的主要原因，我们发现：本次故障主要是由PCU新增流程上的不完善造成。1) 将要入网的PCU配置数据进行核对，及时完成配置数据的修改2) 完善PCU新增流程，和省公司确认各种数据配置原则9. PB口LAPD状态核查开关未关导致FTP下载速率低【现象描述】2007-08-15，某局割接后，路测工程师反应北岙九厅村和新码头EDGE下载速率较低，只有80-120kbps，没有达到期望的数值150kbps。现场测试人员反应下载时候占用四个信道且载干比良好。【问题分析】下载速率慢问题主要涉及以下几个方面的问题：1.服务器原因导致速率问题2.PDCH信道配置过少3.空闲时隙不足4.手机多时隙能力不足导致速率问题和SIM卡开户时候速率限制5.RPPU单板处理能力受限导致的速率问题。一块RPPU可以最多同时激活240个PCIC。6.um口传输质量和GABIS口链路质量【问题处理】观察该局的测试数据CI在20以上，电平一个是-58，一个是-79左右，而且MCS-9编码方式占用比例在77%左右。按此比例计算单信道也应该有40kbps，四个信道也应该有160kbps。1.FTP服务器是本地的,在友商的测试下速率是稳定的，约150Kbps，服务器原因排除。2.使用CDS+SAGEM OT498手机进行测试，在后面测试的大门岙底村基站CQT可以达到200kbps的下载速率，故手机的多时隙能力和SIM卡开户的速率限制都可排除。3.PDCH信道配置足够，且空闲时隙是按照信道数*3配置的，使用PCU 命令mt pdch sh st LCNO all核查每PDCH绑定的时隙数目都是4条PCIC，说明空闲时隙是足够的，且MCS-9的编码方式可以达到的。4.该局的PCU每RPPU板下挂PDCH总数在30个左右，RPPU板的PCIC资源充足，GB口时隙配置也是充足的。5.链路质量问题。经观察PCU历史故障告警，发现很多Pb接口E1端口远端失步（ALARMID=1768），PCU-BTS TRAU链路故障（ALARMID=1800）和LAPD链路故障（ALARMID=1760），以上告警都是比较严重的PB接口链路告警，严重影响EDGE数据性能， BSS工程师检查发现PCU LAPD状态核查开关没有关。15号中午关闭后之后没有再发生类似告警，新码头测试的时间是15号凌晨。另外发现现场测试人对测试要求没有完全掌握，测试的时候需要将卡巴斯基、病毒防火墙、windows自动更新等软件都关闭掉，以上这些因素都会导致数据业务异常，例如在大门、潭头等基站下测试时，CQT速度就出现过异常，后关闭卡巴斯基后速率正常，一般都在160-200kbps之间。10. wap服务器原因导致图铃下载成功率低【现象描述】8月22日完成某移动局替换割接工程，替换前该局除了新城移动营业厅开了EDGE之外，其余都只开CS-1、CS-2，替换后全部开通EDGE， 替换后每个县城1个BSC、2个PCU。 PCU都挂在N厂家的SGSN11下，替换后路测工程师反映图铃下载成功率较搬迁前降低，但其他指标都较好，FTP下载速率能在170kbps左右。【问题分析】替换后三个县城每县城1个BSC，2个PCU.华为的PCU都挂在N厂家的SGSN11下。【处理过程】1) 检查版本及其PCU资源:PCU版本: PCU6000 G3PCUV300R008C01SP04BSC版本:BSC6000V900R001C01B086SP08区域BSCPCU基站数小区数载频数RPPU板数Pb口PB口链路数静态PDCH动态PDCH该局WZHBSC203PCU54065536918155200PCU63550155918114172对该局PCU资源进行了核查，每块RPPU板下挂小区配置的PDCH总数没有超过50个，RPPU板及绝大数基站的空闲时隙都充足。2) 检查GB时隙:取9月9日到9月15日一周0:00-23:00的NS传输性能测量话统.GB口的需要的时隙没有超出13个，资源相对充足，但是考虑70%的利用率，建议增加到20个时隙。3) 检查传输性能测量：从取一周的GABIS口性能传输性能测量“接收校验错帧的个数”来看，部分小区存在误帧率长期过高，但是测试点的在测试时间的误帧率不高。4) 测试验证9月15日在该局新客运站(占用北岙九厅村-0信号)，新码头(占用新码头-0信号)和县委(占用综合楼进行测试)，测试呈现以下2个特征：l 失败原因代码都是0X48 (REQUEST TIMEOUT)l 查看WTP+WSP协议发现有丢包现象，且丢包之后不会重传丢失的包，而是传丢失包下面的包，但是一直得不