TDSCDMA无线网络指标优化案例集v1.0综述

产产品名称ProductnameTDSCDMA产品版本ProductversionV400R000C01B161NodeBB260密级ConfidentialitylevelTotal51pages共55页TDSCDMA无线网络指标优化案例集拟制:Preparedby审核:Reviewedby审核:Reviewedby批准:Grantedby2009-4-4华为技术有限公司HuaweiTechnologiesCo.,Ltd.版权所有侵权必究第1页,第1页,共51页修订记录Revisionrecord修订版本修改描述者RevisionversionChangeDescriptionAuthor2009-4-6V1.0第一版2009-7-27第二版第2页,共51页TDSCDMA无线网络指标优化案例集1无线接通率优化案例TOPRRC1.2上行期望功率设置过低导致接通率低2无线掉话率优化案例CS域掉话率2.2PS域掉话率3切换成功率优化案例3.1CIO配置错误导致切换失败率高问题解决3.3UPPTS时隙干扰影响切换成功率问题解决3.4调整切换失败时重发测量控制时间降低切换失败率3.5CS和PS业务跨RNC切换失败的问题定位分析3.6由于IPPATH及IPRT未配置导致RNC间PS切换无法进行的现象43G到2G切换成功率优化案例4.12/3G互操作G网无法重选至T网4.2GSM小区参数值设置不合理导致测试终端无法重选到TD网络上4.32G到3G路由区更新失败处理案例4.4终端能力不足导致异系统切换失败4.5参数设置不当导致PS业务不能迁移至2G网络5H业务优化案例5.1SIM卡设置导致下载速率受限5.2HSDPA速率较低问题分析5.3大唐测试手机HSDPA测试速率过低的处理案例5.4业务建立失败6邻区配置优化案例频同码字导致邻区无法配置6.2外部邻区参数更新不及时导致脱网，重选失败的案例6.3异系统邻区测量启动门限设置不当，导致小区乒乓重选RNC7.1由于RNC侧SAC配置错误导致手机无法注册7.2由于RNC侧网络模式配置错误导致多普达手机无法进行CS业务的问题8门限优化案例 6 6 920232627293131323334353636373740414143444545475050第3页,共51页第4页,共51页TDSCDMA无线网络指标优化案例集关键词：掉话话统摘要：本文收集了网络优化过程中的典型案例，供优化参考。缩略语英文全名AMRAdaptiveMultiRateCallDetailLogRCallDropRate掉话率RCallHistoryRecord呼叫历史记录第5页,共51页1无线接通率优化案例1.1TOP小区RRC接通率优化【问题描述】针对3月10号前几天话统的结果，RRC接通率低的TOP小区进行提取，根据话务统计的结果，调【问题分析】RRC建立是建立业务的前提，如果RRC建立的成功率低，业务建立成功率低的可能性也很大。RRC建立主要分为四个部分：LUE回复RRCCONNECTIONSETUPCOMPLETE。统计RRC接通率的起始点是RNC收到RRCCONNECTIONREQ，终止点是RNC收到RRCCONNECTIONSETUPCOMPLETE。因此影响RRC接通率的RRC建立失败，主要是后面三步没有成功而导致的。RRC建立失按照目前的用户量和话务量，如果出现了前面几种失败原因，一般都是RNC或者NodeB内部出现了问题，需要检查RNC和NodeB的状态或者小区状态。RRCCONNECTIONSETUP消息是在FACH上发给UE的。目前SCCPCH功率配置的值一般是-3db(相对于PCCPCH功率，单码道)。从覆盖上来说，已经和PCCPCH的覆盖一样了。如果仍然出现UE收不到RRCCONNECTIONSETUP消息，需要调整SCCPCH功率，来满足信号覆盖不好的地方功率需求。LETE此时，如果UE上行同步时失败，或者在向网络侧发RRCCONNECTIONSETUPCOMPLETE消息时，网RRC失败。此时，可以通过提高上行期望接收功率/RL初始发射功率和修改上行同步的参数，来使得UE能够正常进行上行同步和上传消息。扰余量主要用于调整上行DPCH开环功率控制中基站期望接收到的场强值：PRXDPCHdes＝initialSIRtarget+UL_ISCP+UL_Margin第6页,共51页targetSIRTarget越大mpletetupCompleteeconfigurationCompleteRRCRB成功率【解决方法】提高上行干扰余量，间接提高SRB/RB建立时的上行期望接行初始发射功率下限ULINTERFERERSVMINDLINITPWRMODCELLNBMOLPC3-200-250【效果对比】和PSRRC接通率的变化趋势，每日把这些TOP小区的RRC接通率次数和成功次数进行累计，作为今天的RRC接通率，为了提高数据的可靠性，在作累计时，抛去当日存在告警信息的小区。因为业务量不能达到一定的规模，数据的可靠性不能完全可信，特别PSRRC尝试次数比较少，但总体上能反映出一定的问题。修改完参数，这两个指标总体来讲，有一定的提高，虽然每日指标有一定的波动。因为3月12日存在大量告警，指标的可信度不是很大，故没有加以考虑。第7页,共51页CSCSRRC接通率TOP小区性能变化78%%%%3月10日3月11日3月12日3月13日3月14日3月15日3月16日%率通接R%%%%%C图1CSRRC接通率TOP小区性能变化CSCSRRC建立及成功次数RRC建立成功次数RRC建立尝试次数03月10日3月11日3月12日3月13日3月14日3月15日图2CSRRC建立及成功次数第8页,共51页PSPSRRC接通率TOP小区性能变化89.01%94.12%73.58%3月10日3月11日3月12日3月13日3月14日3月15日3月16日率通接RP80.00%60.00%40.00%20.00%0.00%3月9日85.71%CS图3PSRRC接通率TOP小区性能变化PSRRC建立及成功次数RRC建立成功次数RRC建立尝试次数03月10日3月11日3月12日3月13日3月14日3月15日图4PSRRC建立及成功次数1.2上行期望功率设置过低导致接通率低【问题描述】A市在做TD手机拨打CS语音业务时，经常出现无法接通的现象。从后台信令跟踪，发现错误原【问题分析】第9页,共51页【解决方法】1、用其他TD手机拨打，未接通现象也会出现。排除终端问题2、用大唐8120测试，从覆盖场强值来看，排除覆盖场强值过低导致掉话的可能。同步失败导致手机无法接通。4、检测后台UPPCH的ISCP值过高，存在干扰。可以提高UPPTS的期望接受功率或进行UP偏移来解决。检查后台参数发现上行干扰余量ULINTERFERERSVP配置为-3，指导书中参数应设置【建议与总结】2无线掉话率优化案例2.1CS域掉话率2.1.1小区更新成功率偏低分析【问题描述】XX网络中小区更新成功率低。作为无线链路异常时的一种补救手段，解决小区更新成功率问题可降低掉话率。【问题分析】其中,连续同步指示次数相当于UE侧的N315连续不同步指示次数相当于UE侧的能N313无线链路失败定时器时长相当于UE侧的T313,【参数分析】我们的CELLUPDATE成功率可能出现的问题点。NmsTs下行失步满足条件后23秒才能进行CELLUPDATE.LFAILURE其中TRLFAILURE=50就是5s那么上行失步NODEB向RNC发起RADIOLINKFAILURE并且进行IURELEASEREQUEST的NOUTSYNCIND×160ms+TRLFAILURE=8.2s，也就是要上行失步满足条件后8.2秒就进行无线所以：UE侧无线链路失败时间远远大于NODEB侧无线链路失败时间假如，在下行失步的时候上行已经失步了，那么上行到8.2秒后就已经把无线链路(包括信令面的链路)释放了，下行再怎么CELLUPDATE也不会有CELLUPDATECONFIRM的回复。造成我们的CELLUPDATED的成功率非常的低。查询了其他厂家的此参数发现LFAILURE这就是CELLUPDATE成功率高的原因。【解决措施】现深圳RNC9T已经把小区更新的参数设置如下：NINSYNCIND=1,NOUTSYNCIND=20,TRLFAILURE=200以上设置可以留给UE发起小区更新足够的时间名词备注：N313(无线链路连续失步最大次数)，T313(计N315的时间间隔)，N315(连续同步的indication}(连续失步指示次数)【效果对比】优化前小区更新成功率KPI指标统计如下：小区更新次数<小小区更新确认次数小区更新成功次数间<小区><小区>小区更新成功率优化前3511.49%优化后63349749077.41%2.2PS域掉话率【问题描述】平均水平有比较大的差距。优化的目标是要将PS掉话率指标控制在20％以内。【问题分析】求释放数目位>求释放数目<GTPU失步>求释放数目>求释放数目<RAB抢占>求释放数目<用户无求释放数目9877769877760000000000000000000000000000000000000000CellNameCellName=12096641,CellID=16641CellName=12092723,CellID=42723CellName=12097161,CellID=17161CellName=12097502,CellID=17502CellName=12086142,CellID=16142CellName=12086602,CellID=16602CellName=12098041,CellID=18041CellName=12087142,CellID=17142CellName=12087553,CellID=17553CellName=12097501,CellID=17501释放分组接对应的RAB数目49246001012释放分组接对应的RAB数目应>0000350000释放分组接对应的RAB数目>0000000000释放分组接对应的RAB数目位>0000000000释放分组接对应的RAB数目49328777766DAT发送端直接发起一个RLC重置过程。在TIMERRST时间内接收到对端响应，则停止TIMERRST 超时定时器。如果TIMERRST定时器，重新发起RLC重置过程，经过MAXRST后尝试后，如果不能接收到对端响应，则上报“RLC不可恢复错误”，RNC发起RAB释放，原因为“RB复位”RL失步是指RNC收到NodeB上报的RLFailureRL失步的判断机制为处于CELL_DCH状态的UE，NB(NodeB)检测到上行连续接收到来自物理层的NOUTSYNCIND个连续”ourofsync”指示时，启动定时器TRLFAILURE，在此过程中若连续接收到来自物理层的NINSYNCIND个连续”insync”指示，TRLFAILURE停止，否则TRLFAILUR时，视为无线链路失败。NB(NodeB)发起RadioLinkFailureIndication过程，RNC等待IUCSRELNORABTMR超时发起Iureleaserequest，请求释放Iu连接名词备注：N313(无线链路连续失步最大次数)，T313(计N315的时间间隔)，N315(连续同步的次数要求)NINSYNCIND(连续同步指示次数),NOUTSYNCIND(连续失步指示次数)【解决方法】质量。T313是连接模式下UE检测无线链路失败的定时器，当UE从L1检测到连续N313个失步指示后启上报原因值为RLFAILURE的CELLUPDATE消息通知RNC空中接口下行失步。T_RLFAILURE定时器是NodeB用于检测UU接口上行是否失步，当CCTRCH处于同步状态，NodeB在连续收到“N_OUTSYNC_IND”个失步指示后会启动T_RLFAILURE定时器；在连续收到“N_INSYNC_IND”个同步指示后会停止和复位T_RLFAILURE定时器。一旦T_RLFAILURE定时器超时，NodeB会上报RADIOLINKFAILUREINDICATION消息通知RNC空中接口上行失增加由于无数据传输导致链路释放的触发时间，避免频繁触发由于无数据传输而导致的网络侧发参数参数说明修改前修改后TIMERRST该定时器属于发送端，当发送了RESETPDU后启动该定时器，收到确认后停止Max_DAT-1次传输后，都没有成功发送，直接发起一个RLC重置过程。D20D40TIMERPOLLPROHIBIT该定时器属于发送端，用于禁止在一定的时间中触发轮询。定时器的值不能大于Timer_poll_periodic的值，否则会使得周期触发轮询失去意义。如果只是使用周期轮询的话，该定时器可以不用。如果除了周期轮询外，还有别的触发方式，该定时器必须使用，此时该定时器的值应该和Timer_poll_periodic的值有一定的时间差值，否则会使得别的触发机DD40TIMERPOLL该定时器属于发送端，当发送端发送了触发轮询后，如果在定时器期间收不到响应，定时器超时后，再次轮询。若没有配置该种轮询机制的话，可以不使用该定时器。于基于PDU的轮询机制，其意义为发出POLLPDU个PDU以后发出一个轮4、对于TOP小区抬高最小接入电平，在目前终端性能的现状下，可在接入电平上做合理限制。(内参)同扰码邻区对打，可能导致副载波同频同码，容易掉话措施：RNC内小规模调整频点和扰码，规避同扰码问题，尽量避免同码组。(1)邻区信息错配或漏配(2)单向邻区措施：分区域检查邻区错配2、导频污染3、越区覆盖，TD系统中需要严格控制越区覆盖操作：天馈分离/天线方向角/下顷角调整【效果对比】通过20多天的努力，目前指标稳定在20％以内，平均15％左右。PSPS优化前网络替换及优化调整优化后2-2-比分百网络优化前后PS掉话指标对比3切换成功率优化案例3.1CIO配置错误导致切换失败率高问题解决【问题描述】向小区17162的切换出失败率较高。具体数据如下表：RNCRNC内小区间RNC内小区间RNC内小区间RNC内小区间29703318714/03/200917161-->17162187【问题分析】分析其切换出失败的细分类，观察到由于<物理信道失败>造成的切换出失败占总失败次数RNCRNC内31551716217162RNC内RNC内RNC内RNC内RNC内RNC内RNC内C0000000000000000000000032227377物理信道失败，通常发生于UE上报测量报告，RNC成功判决并下发物理信道重配置后，无法在切换目标小区接收到UE的物理信道重配置完成消息。这表明在这时刻，切换目标小区的信号质量虽然满足了切换判决，但其信号质量并不好。【解决方法】以下是同频、异频切换的相关定义：同频切换事件件1G下列等式在触发时间(Time-to-trigger)内一直成立的时候，UE报告事件1G(最佳小区的改变)公式中的参数含义如下：SCPmWOi正在评估小区i的单独偏移H1g是报告事件1G的滞后参数。异频切换事件下列等式在触发时间(Time-to-trigger)内一直成立的时候，UE报告事件2A(最佳频率的更新)QQ+H/2公式中的参数含义如下：frequency"没有存储的频率质量估计。 文档名称：TDSCDMA无线网络指标优化案例集文档密级：公开H2a是事件2A的滞后参数。其中估计的质量如下定义：Q=10.LogM+Oi,frequencyji,frequencyji,jMfrequencyj是频率j上的小区i的P-CCPCHRSCP的测量结果，单位mW.Oi,j是当前频率j上的小区i的小区单独偏移，Oi,j由IE"Cellindividualoffset"设置。为0dB，而17162的CIO为7.5dB。由此，可以看到，由于小区17162的CIO设置过高，造成17161向比自己弱的17162切换，导致最后的切换失败。正常情况下，需避免向比原服务小区信号质量差的小区切换出。因此，决定将17162的CIO为7.5dB调整为0dB(于2009年3月14日执行)。【效果对比】调整后，小区17161向小区17162的切换出失败率明显改善，<物理信道失败>造成的切换出失败基本消除。调整前后的切换出失败率对比及<物理信道失败>造成的切换出失败对比见下图：RNCRNC内小区间同频异频硬切换出成功率率80%功60%成40%RNCRNC间RNC区间RNC间RNC内小区间29703318718715/03/200917161-->1716211011067118/03/200917161-->17162660切切换出失败与物理信道失败RNC内小区间同频异频硬切换出失败次数RNC内小区间同频异频硬切换出失败次数<物理信道失败>数4次对象名对象名称171621716217162171621716217162C3155000000000000100000000000000032220010000000000000000000000000C737700103.2“切换惩罚时间设置过大”引起切换不及时的问题解决【问题描述】在路测中，发现有切换不及时现象。具体表现为：从A小区切换到B小区后，UE发现A小区的信号强度又高于B小区，并满足了切换条件，于是上报了测量报告，但RNC收到此测量报告后没有判决切换(即下发物理信道重配置消息)，导致UE在较长时间内无法切换回A小区，而一直占 (其中包含非A的目标小区)，RNC判决切换下发“物理信道重配置”消息，UE切换到新的非A目标小区，业务质量得到改善。【问题分析】时会发生乒乓切换问题。在路测网络中，一般会设置一个切换惩罚时间。切换惩罚时间于RNC成功收到UE上报的上一次切换成功(A>B)的“物理信道重配置完成”消息开始计时。当UE检测到已切出的原服务小区(A)的信号强度高于当前服务小区(B)且满足切换条件后，UE会上报测量报告，RNC在进行判决下发“物理信道重配置”消息。本问题可细分为2个问题：2、UE在上报测量报告后，一直等RNC的判决，直到过了较长时间才再发一次包含非原【解决方法】将切换惩罚时间减小(从5s改为0s)，使UE能及时的切换回信号质量较好的小区，以保证业务【效果对比】调整前调整后调整前调整后调整前调整后可以看到的，切换惩罚时间调整后，UE能及时的切换到信号质量最好的小区，保证了业务的质3.3UPPTS时隙干扰影响切换成功率问题解决【问题描述】深圳TD网络龙华区域中，原来普遍使用硬切换，没有打开接力切换。硬切换成功率偏低。【问题分析】华为机密，未经许可不得扩散第23页,共51页(RNC687、688，部分为0的小区没有统计)，统计分布如下：UPPCHUPPCH平均干扰小区百分比统计UPISCP>-95-100<UPISCP>-95UPISCP<-100%硬切换的过程中，首先要进行上行同步，如果同步时间过长，导致HOPHYCHRECFGTMR超时，硬切换失败原因统计频硬切换失败次数<UE硬切换失败原因统计%异频硬切换失败次数<配%异频硬切换失败次数<配持>%异频硬切换失败次数<物%异频硬切换失败次数<小异频硬切换失败次数<协接力切换的预同步过程属于开环预同步，在UE对本小区基站和相邻小区基站的导频信号强度接力切换的预同步过程属于开环预同步，在UE对本小区基站和相邻小区基站的导频信号强度进行测量的同时记录来自各邻近小区基站的信号与来自本小区基站信号的时延差，预先取得与目标小区的同步参数，并通过开环方式保持与目标小区的同步。因此，接力切换可以规避UP干扰导致的硬切换失败问题。改为接力切换后，切换失败原因统计(统计时间为1天)发现，物理信道失败的次数大大减少：异频异频接力切换失败原因分布频接力切换失败次数异频接力切换失败次数<步>异频接力切换失败次数<整>异频接力切换失败次数<持>异频接力切换失败次数<异频接力切换失败次数<道失败>RNC侧统计RRC尝试次数是以接收到RRCCONREQ的次数计算的，如果没有同步上，则不会计为一次尝试。因此在话统中没有看出对RRC成功率的影响。但对于用户而言，在接收电平较弱的地方，可能会出现按下拨号键以后，很长时间都拨不出去，感受可能变差。需要注意的是，UP干扰问题可能会影响路测指标中RRC建立成功率，因在路测工具侧，软件先【解决方法】【效果对比】从下表可以看出，同频切换成功率提高近25个百分点，异频提高约10个百分点。对象名对象名称RNC9T/RNC功能:RNC9TRNC9T/RNC功能:RNC9TRNC9T/RNC功能:RNC9TRNC9T/RNC功能:RNC9TRNC9T/RNC功能:RNC9TRNC9T/RNC功能:RNC9TRNC9T/RNC功能:RNC9TRNC9T/RNC功能:RNC9T平均起始时间06/03/200907/03/200910/03/200913/03/200914/03/200916/03/200919/03/200920/03/2009硬切换RNC内同频切换成功率83.12173.77779.77551.46544.07444.17676.34868.7565.18575RNC内异频切换成功率87.75586.68790.80190.67990.96188.08292.27668.13686.92213RNC内异频切换尝试数259723162680499RNC内换尝试数314225930748124924148RNC内异频切换成功数227920402473340RNC内换成功数26121233对象名对象名称RNC9T/RNC功能:RNC9TRNC9T/RNC功能:RNC9TRNC9T/RNC功能:RNC9TRNC9T/RNC功能:RNC9TRNC9T/RNC功能:RNC9T平均起始时间25/03/200926/03/200928/03/200929/03/200931/03/2009接力切换切换成功率86.44891.01189.87394.44489.47490.24994异频接力切换成功率97.20398.16496.44897.40296.29697.1026异频接力切换尝试次数28613433320939273105异频接力切换成功次数27813370309538252990力切换尝试次数2143638力切换成功次数3434【遗留问题】查明并彻底排除，以提高用户接入体验。RNC间接力切换功能支持情况需要进一步验证。3.4调整切换失败时重发测量控制时间降低切换失败率【问题描述】在跟踪一些切换失败率高的小区的Trace中，经常看到同一个UE不停的往一个小区切换，但每次切换都失败。例如：这三次都是向同一个小区发起切换，并且间隔大概都在2秒左右。【问题分析】从话统角度来说，这样频繁的发生切换并且每次都失败，对于话统指标是一个很大的隐患：由于一个点的切换不好，导致切换指标恶化的很明显。根据目前的算法和代码实现，不支持对切换失败小区的惩罚，即如果向一个小区切换失败了，如果UE再次上报测量报告，网络仍然会向该小区发起切换。这样就会造成短时间内往一个小区发起多次切换的场景。【解决方法】免发生不必要的切换失败。UE某个小区的信号质量符合切换要切换重试功能，测量控制消息将不会重发。降低切换发生频率可以通过修改重试次数和重试周期来完成。协议上规定了1G和2A,3A等事件都是穿越事件,即一但信号满足了测量的条件，UE会上报相应的测量报告。如果后续信号一直满足测量条件，UE也不会重发测量报告。此时如果网络想让UE再次上报某一个类型的测量报告，就必须再重发一次测量控制给UE，UE才会再次上报(有的UE作的不规范，会不停的上报测量报告，上面的trace中就出现了这种现象)。因此网络可以通过重发测量控制的时间间隔，来避免频繁向同一个小区发起切换。重发测量控制的时间间隔和切换失败重试周期定时器是同一个定时器。如果要启用测量控制重发的功能，必须要把切换失败重试次数设为0.【风险评估】当采用通过重发测量控制的时间间隔来减少切换次数的方法时，会有一些不利的因素：如果重发测量控制的时间间隔过长，UE在这段时间内无法发测量报告，就无法触发切换，会导致掉话率上升。另外，间隔过长，等到下次触发切换时，由于信道环境已经变的比较差，切换失败的概率会增大。会对切换的一些处理有影响，比如网络在防乒乓切换时，UE又上报了往原小区切换的测量报告，此时网络会忽略这个报告。如果采用重发测量控制的方法，此时不会发起测量控制。但是如果采用切换失败重试的方法，就可以在重试周期超时后，发起切换尝试。3.5CS和PS业务跨RNC切换失败的问题定位分析【问题描述】(RNC—CN)，且异频切换多次出现2B。【问题分析】切换不成功多由如下几类原因导致：【解决方法】1)从现场提供的Trace信令分析，返回失败消息为：RANAP_RELOCATION_CANCEL，其中发给CN，可推断为原因2)：RNC涉及切换的参数配置不当，并初步推断为相关的定时器配置小导致。3)查看现有RNC脚本配置，原有SETSTATETIMER中：改为：RELOCCMDTMR=15000,RELOCPHYCHRECFGTMR=8000,RELOCUTRANHOCMPTMR=10000。1)从现场提供的Trace信令流程中发现异频切换多次出现2B生效，同时也有2A在生效，按AB2)针对2A等切换生效的条件主要在RNC一侧，因此推断为原因2)：RNC涉及切换的参数和切换门限值设置较大，从而使2B更容易生效；ADDCELLINTERFREQHONCOV:CELLID=x,INTERFREQFILTERCOEF=D3,HYSTFORINTERCELL=6,TRIGTIMEFORINTERCELL=D320,ERCELLTHDFORINTERHO现场修改上述参数后，切换正常。【建议与总结】切换类问题可根据TRACE或路测数据等，先确定问题原因，及时找到问题源，结合MML等逐步查找定位。3.6由于IPPATH及IPRT未配置导致RNC间PS切换无法进行的现象【现象描述】在RNC间测试业务切换的过程中发现，CS业务正常而PS业务迁移失败。在发往CN的消息“RANAP_RELOCATION_CANCEL”中显示的原因值为“iu-transport-connection-failed-to-establish”【原因分析】PS业务跨RNC切换失败的原因一般有以下一些原因：待切换的两个不同RNC的基站状态异常；无线环境问题；跨RNC邻区配置问题；各网元数据配【处理过程】RNCsetupandenabled查看两2、从路测软件中查看无线环境的RSCP和C/I等，均正常；3、查看跨RNC邻区配置，通过命令“LSTNCELL”,显示待切换测试的两小区分别在各自的邻PSRNC的TRACE，从发往CN的消息“RANAP_RELOCATION_CANCEL”中显示的原因值为“iu-transport-connection-failed-to-establish”据此推测，RNC的PS域IPPATH和路由配置有问题。5、经查询RNC的PS域数据尚未配置：源RNC与目标RCN之间没有配置路由(IPPATH及IPRT)；通过ADDIPPATH和ADDIPRT命令，配置两相邻RNC之间的路由数据。建议为每块配置了Iu-PS接口用户面数据的IP接口板配置到达DRNC的IP路由和IPPath。迁移的轨迹是：当前RNC->SGSN->邻近RNC，因此配置迁移通路的前提条件是本RNC和SGSN之间、邻近RNC和SGSN之间的IPPath已配置完毕。通过ADDIPPATH配置服务RNC(SRNC)到目标RNC(DRNC)间用于迁移的IPPath；通过ADDIPRT，增加到达DRNC的IP路由。下一跳为源RNC对应的CEIP，(CE以太网)。再通过ADDIPRT命令配置一条DRNC的备用路由，下一跳为源RNC对应的CEIP;相应地，在目标RNC侧应对相邻RNC增加路由(IPPATH、IPRT)。华为机密，未经许可不得扩散第29页,共51页例如下：源RNC的用户面IP：7/30目标RNC的用户面IP：7/30源RNC对应的CEIP：7/30和7/30ADDIPPATH:ANI=1994,D6、完成配置，现场测试PS64/128/384/HSDPA上传和下载业务均正常【建议与总结】跨RNC切换涉及各个网元的数据配置，必须协同完整配置完毕；43G到2G切换成功率优化案例4.12/3G互操作G网无法重选至T网【问题描述】某地实验局对移动公司大楼进行2/3G互操作，其中移动公司大楼内有TD室内分布小区A、GSM室内分布小区B，室外宏站小区有C、D、E。所有2/3G互操作参数配置完成以后发现：UE占用TD小区A时，在测试手机(大唐8130：软件版本06A)的小区信息中可以看到G网邻区B、C、D、E的信息，也可实现T网至G网小区B的重选，语音切换以及PS域切换(TD->GPRS)等业务均正常；当UE占用GSM小区B时，测试手机的小区信息中只有G网邻区的信息，并没有TD邻区A的小区信息，同样也无法实现G网至T网的重选。UE作的所有业务均可正常进行。【问题分析】1、邻区关系不完善；G错误(BSIC、BCCH、LAC等等)；G数设置错误；【解决方法】G邻区关系没有问题。2、查询G网小区状态并不存在告警。3、仔细核实GSM现网中B小区的BSIC、BCCH等基础信息，以免在T网中定义错误，并没有发现4、仔细核实G网小区B配置的G网至T网的重选参数Qserch_I和TDD_OFFSET，现网查询得到QserchIG强度高于-90dBm时，终端将启动对TD邻区的测量)，行2G到TD的系统间重选)，参数取值合理。5、查看G网小区B和E的小区基础数据，发现这两个小区的BCCH取值均大于975，为扩展频点，现怀疑和频点的取值有关系，故将这两个小区的频点进行修改，但是问题依然存在。6、利用测试软件查看层三信令发现，当TD小区与G网小区重选正常时，TD小区重选至G网小区SIQOATER息。但是在移UETDG小区B时，系统并不下发此消息，系统并不对G网的异系统邻区进行测量，故无法实现重选。7、现将G网的小区级数据Qua参数(此参数的含义是在2G小区重选的过程中，重选目标小区是否有优先级)进行激活操作，就是将此参数原来的取值N删除，再重新定义取值N，复测结果正4.2GSM小区参数值设置不合理导致测试终端无法重选到TD网络上【问题描述】某局外场测试中，从GSM小区【问题分析】测试终端为8130A，确认没有问题；3、查看GSM小区苹果城_C的QSearch_I(该参数的含义是当2G小区的RSSI在达到一定门限时开示2G服务小区的信号强度高于-90dBm时，终端将启动对TD邻区的测量；)和TDD_OffSet(该TD的P-CCPCHRSCP值连续5秒大于TDD_Qoffset时，将执行2G到TD的系统【解决方法】【建议与总结】的频点和参数的正确设置，并例行梳理2g的相关参数。4.32G到3G路由区更新失败处理案例【现象描述】址，导致DNS解析不到正确的2GSGSN地址，路由更新过程失败。【原因分析】GTDTDSGSNoldRAI的2GSGSN。N【处理过程】PSBANDMAX=64000，说明不存在业务速率超过最大速率限制的问题；1.3再查询GSM无线侧后台数据：TD邻区，测量门限和判决门限，都正确。因为无线侧数据无误，且CS业务互操作正常，初步定位核心网侧PS业务的相关参数配置问题。2.1核实TD核心侧后台数据，MSC/VLR与HLR的参数配置无误，但是NewSGSN(3GSGSN)没有配置OldSGSN(2GSGSN)的DNSH记录。2.2用ADDDNSH命令加一条2GSGSN信令面地址信息记录【建议与总结】GSM/TD互操作涉及网元较多，参数配置也较多，需要从四个方面检查参数配置：(1)TD无线GSM发门限，迟滞和偏置等参数；STD4.4终端能力不足导致异系统切换失败【现象描述】在进行基于23G基于覆盖切换测试时发现网络下发3A测量控制后，终端不上发3A测量报告，导致无法切换【原因分析】【处理过程】A3A测量报告。S业务，正常切换。置不同，目前时隙配比为2：4，申请PS64/384业务后，上行占用一个时隙，下行占用3个时隙，在现有的时隙配置下，无法保证2个以上的空闲时隙用于异MODCELLINTERRATHOCOV:CELLID=***,SETHOCOMM:TSNUMMIN=1;6、该方案可以暂时规避切换功能失败，但牺牲了测量的准确性。【建议与总结】由于TD网络目前尚处与商用实验网阶段，各个环节都有可能出现问题，需要我们细心发现问题，并且问题的解决要跟踪最终结果，找到根本原因，确认问题彻底解决。本次PS64/384切换前期已经可以通过，但由于时隙配比改变(原为3：3，现在2：4)，导致终端测量能力不足，功能验证出现问题。4.5参数设置不当导致PS业务不能迁移至2G网络【问题描述】不下发3A，导致无法对2G系统的迁移。【问题分析】1、信令采集有误。【解决方法】1、重复测试，信令采集现场依旧。对2G系统的迁移。检查异系统切换支持的最大PS域带宽参数设置为128k，而测试时申请的业务为2M，相关参数如下：SETHOCOMM中TSNUMMIN及PSBANDMAX。修改系统间切换测量所需的连续空闲时隙的最小个数(SNUMMIN)为1，异系统切换支持的最大PS域带宽(PSBANDMAX)为2M后，问题解决。【建议与总结】在参数设置过程中，一定要与所对应的业务相匹配。5H业务优化案例5.1SIM卡设置导致下载速率受限【问题描述】【问题分析】配比错误会导致速率下降。【解决方法】M常。常【建议与总结】5.2HSDPA速率较低问题分析【问题描述】【问题分析】【解决方法】【建议与总结】TD题，并且问题的解决要跟踪最终结果，找到根本原因，确认问题彻底解决。5.3大唐测试手机HSDPA测试速率过低的处理案例【现象描述】在**项目单站验证过程中间，使用测试手机8130和数据卡进行HSDPA业务的速率测试，数据卡ps【原因分析】查看小区的配置信息，测试的TD小区已经配置了H资源，时隙配置为2：4，激活HSDPA的最小下行速率门限是64Kbps。使用数据卡可以正常申请到H资源，且在下载外网资源的情况下可以达到1Mbps的平均速率，峰值达到1.6Mbps，但使用大唐8130测试手机测试时，不管申请多大的下psUSIM通的权限有问题。将大唐8130中的USIM卡换到5731数据卡中进行拨号，同样可以达到1Mbps的速率。由此可以排除USIM卡的问题。左右的数据下载速率。可以定位速率过低与手机有一定关系，跟踪IMSI通过Iu口消息发现CN给RNC的RAB指配消息中由此可以得出网络侧给UE分配的速率就是64/128kbps。【处理过程】发现请求的下行速率为(72-64)*8+64=128Kbps。手机向网络侧申请的下行速率为128kbps，因此s现在的问题是在交互界面上请求的速率经过手机后都变成了64/128，在刚开始安装8130驱动的时候在控制面板—>电话和调制解调器选项—>拨号—>属性—>额外的初始化命令中输入了初始化命令，打开对应端口的属性，发现初始化命令中申请的速率为64/128。在初始化命令中将申请的速率改为64/2800，确定后重新拨号，速率峰值达到1.56Mbps，均值达【建议与总结】通过此案例，我们在用大唐8130手机测试H业务时，在拨号连接中有两个地方可以设置拨号连接的属性，第一个是控制面板—>电话和调制解调器选项—>拨号属性—>高级—>额外的初始化命第二个地方的设置就不起作用了，仅在第一个地方没有设置的时候在第二个地方设置才起作用。5.4业务建立失败【现象描述】基站开通后，进行功能验证，语音与PS384业务正常，但视频无法建立，HSDPA可以建立拨号连接，但无流量。【原因分析】与HSDPA相对要求质量较高。2SIM卡问题：权限未开通。3终端原因。数据配置问题。【处理过程】4、首先分析视频测试文件，发现在终端建立业务前(connect)，一切正常，在被叫测量报告下现关于初始发射功率部分过低导致接续失败(初始SIR设置过低，导致初始发射功率过低，MODTYPRABOLPC:RABINDEX=5,SUBFLOWINDEX=0,DELAYCLASS=1,INITSIRTARGET=202,MAXSIRTARGET=202,MINSIRTARGET=202;其中RABINDEX是64K对应的RABINDEX。5、由于上网卡无法收集测试文件，针对其中可能出现环节逐步分析。网络连接可以建立，证明ADDAAL2PATH:ANI=1077,PATHID=3,PT=HSDPA_RT,CARRYT=IMA,CARRYF=0,CARRYSN=18,CARRYIMAGRPN=0,ADDTORSCGRP=NO,CARRYVPI=1, CARRYVCI=56,TXTRFX=152,RXTRFX=152,OWNERSHIP=LOCAL,FWDHORSVBW=0,BWDHORSVBWFWDCONGBW0,BWDCONGBW=0,FWDCONGCLRBW=0,BWDCONGCLRBW=0,TIMERCU=10;检查后发现PATHID配置错误，与其他PATHID重复，导致RNC与NodeB无任何告警，但链路未能正常建立，修改后恢复正常。【建议与总结】TD，这也就需要我们对无线各方面理论全面了解，对可能出现问题进行分析。6邻区配置优化案例9.1同一小区的邻区不同频同码字导致邻区无法配置【现象描述】B站1小区与A站1小区规划时互为邻区，后台添加A站1小区为B站1小区邻区时，却无法配置。【原因分析】【处理过程】NCO&M#149429%%ADDNCELL:CELLID=30111,PLMNMCC="460",PLMNMNC="00",RNCID=353,NCELLID=30191,CELLINDIVIDALOFFSET=0,READSFNIND=FALSE,2、分析频点和扰码。如下图所示(小区图中外小区代表扰码、内小区代表频点)：3、由于频点规划方案中辅频点与主频点是不同的，所以规划频点时只要尽量主频点异频即可。基于同频的情况下，扰码规划原则：邻区及邻区的邻区不同码字、邻区不同上下行同步码、区时，常见邻区无法配置情况为邻区的邻区同频同下行同步码。服服务小区名称频点扰码组扰码邻近小区名称频点扰码组扰码41494A_27494A_34414B_3542464D_37由邻区表可以看出，B站1小区邻区间不存在同频同下行同步码组和同频同码组的情况。升级为LCR4.0.1后，后台邻区配置时，增加了不同频同码字时邻区无法配置的限制条件。华为机密，未经许可不得扩散第42页,共51页错为下行同步码干扰。同的原则使规划更加严格，更有效的保障网络质量。6.2外部邻区参数更新不及时导致脱网，重选失败的案例【现象描述】在N市簇优化过程中，测试车辆在由南向北行驶，如下图，占用豫章后街1的信号，行驶过程中服务小区信号越来越弱，按照正常情况应该重选到距离较近的NS小区XX日报2，但是从邻区中观察一直没有该小区的信号。由于周围其他基站未能覆盖到，所以手机直到脱网，然后选择到XX日报2。【原因分析】产生该现象的原因有如下几种：后街没有添加XX日报2邻区关系；(3)邻区关系参数错误。【处理过程】1、由于脱网后可以选择到XX日报2，所以排除原因1，检查MML中邻区关系发现该邻区关系已经定义：2、按照理论，定义后邻区列表中可以观察到该小区的信号情况，但是我们从邻区列表中一直未发现该小区。所以怀疑外部邻区参数定义错误，同NS厂家同事配合检查发现NS基站在优化过程中修改过XX日报2的频点，而我们添加邻区参数没有更新，导致无法检测到该小区的信号进行重新，造成脱网。3、使用MODNRNCCELL修改邻区频点为10071，测试重选正常。【建议与总结】由于我们使用的RNC间的邻区都是外部邻区，包含2G邻区，优化过程中频点修改后需要对相应的外部邻区参数进行更新，否则会导致无法重选和切换。日常优化过程中需要周期性的进行外部邻区参数的检查。6.3异系统邻区测量启动门限设置不当，导致小区乒乓重选【问题描述】在BT市进行GSM/TD23G互操作测试时，客户反映手机经常进行G和T网之间的小区重选，手机经常不能做主被叫，感知度较差。组网RNC版本为B161，NodeB版本为B261。华为机密，未经许可不得扩散第44页,共51页【问题分析】开启2/3G互操作功能后，异系统小区频繁重选，可能的原因为：1、手机终端问题，目前部分终端性能较差。2、RNC侧重选参数设置不合理导致小区频繁重选。3、网络参数设置问题，由于GSM网络BSC侧小区重选参数不合理导致。【解决方法】针对上述分析，进行了如下处理：1、使用多款普通终端观察发现，异系统小区重选较频繁；基本可以排除终端问题。2、使用路测设备(鼎利软件＋华为ET128)测试，发现异系统小区重选较多，重选时TD小区信号一般在－60dBm左右,重选后GSM小区信号在－45dBm左右。影响异系统小区重选的参数MIN3、根据重选原理，可知当主