掉话_小区更新失败案例分析.doc

大唐移动通信设备有限公司 掉话_小区更新失败案例分析报告 掉话_小区更新失败案例分析版权所有大唐移动通信设备有限公司本资料及其包含的所有内容为大唐移动通信设备有限公司(大唐移动)所有,受中国法律及适用之国际公约中有关著作权法律的保护。未经大唐移动书面授权，任何人不得以任何形式复制、传播、散布、改动或以其它方式使用本资料的部分或全部内容，违者将被依法追究责任。目 录掉话_小区更新失败案例分析报告1问题现象描述32数据呈现及数据路径43分析推理过程54问题结论、优化措施、优化前后效果对比95总结该类问题一般分析优化思路91 问题现象描述测试车辆沿图 11中所示的路线行驶，主叫UE1从闵南-3（CPI=118）顺利切换到华工-1(CPI=91)，被叫UE2在闵南-3（CPI=118）上发Measurement Report欲切换到华工-1(CPI=91)，未收到网络下发的物理信道重配置消息，四秒钟后，UE2由于下行无线链路失败进行小区更新流程，UE2在收到小区更新确认后回复了物理信道重配置完成消息，但未收到测量控制消息，随后下行链路再次失步，UE2发送CELL UPDATE后，立即收到RRC连接释放最后UE2掉话，UE2的空口信令流程图如图 12所示。图 11掉话点情况图图 12UE2空口信令流程图2 数据呈现及数据路径ftp：/39/个人文件夹/0-网络优化上海项目集中培训/整理后的案例/掉话_小区更新失败案例分析/outumlog/6-7.log；ftp：/39/个人文件夹/0-网络优化上海项目集中培训/整理后的案例/掉话_小区更新失败案例分析/ CDL_K1297_calltrace/；ftp：/39/个人文件夹/0-网络优化上海项目集中培训/整理后的案例/掉话_小区更新失败案例分析/ Cfgdata/ cfgdata_rnc405.dat；ftp：/39/个人文件夹/0-网络优化上海项目集中培训/整理后的案例/掉话_小区更新失败案例分析/ Outum基站数据库/ OUTUM-1013.xls；ftp：/39/个人文件夹/0-网络优化上海项目集中培训/整理后的案例/掉话_小区更新失败案例分析/故障告警；3 分析推理过程本案例中UE2掉话的直接原因是由于UE2小区更新流程失败，RNC下发小区更新确认后，未收到UE2上发的物理信道重配置完成消息，如图 31所示，但进一步分析，需要看UE为何会出现下行无线链路失败并引发小区更新。下行无线链路失败原因分析 问题1：UE2上发MEASUREMENT REPORT后为何收不到物理信道重配置消息；l 可能性1:UE2的测量报告触发较迟，导致在无线环境差的情况下上发MEASUREMENT REPORT，最终导致RNC未收到，通过网络侧信令看，如图 31所示，RNC已经收到，该可能性排除；图 31网络侧消息l 可能性2：UE2在发送MEASUREMENT REPORT后，网络下发了物理信道重配消息，在接收物理信道重配置消息期间质量恶化，查看UE在发送MEASUREMENT REPORT到开始进行小区搜索之间的下行质量情况发现，该期间UE的下行SIR很差，已经达到了-7dB，这可能是导致UE未收到物理信道重配置，并最终失步的直接原因，UE在上发MEASUREMENT REPORT附近的下行无线环境情况如图 32所示：图 32UE发送MEASUREMENT REPORT附近无线情况图问题2：何种原因导致UE在上发MEASUREMENT REPORT后下行SIR恶化，并最终下行失步？从道路的覆盖来看信号情况很好，不至于由于覆盖原因导致SIR恶化，那么就是要从干扰入手，是否存在干扰导致SIR恶化？l 可能性1：外界的干扰，如果为外界干扰，那么处于同一位置的主叫UE1也会出现质量恶化的情况，同时同一载波的其他时隙也应该出现相应的ISCP提升的情况，但从UE1UE2测试的情况看并未出现，所以外界干扰存在的可能性可以排除；l 可能性2：系统内干扰，对于业务过程中的下行失步，主要关注的应该是DPCH的干扰情况，TD属于时分的系统，UE的干扰主要来源于同时隙上的干扰，查看UE1和UE2所占的物理信道，UE2的SIR很差时，占用的是闵南-3（CPI=118）10080，下行TS6，而此时同在一个位置的UE1占用华工-1（CPI=91）10080，TS6，UE1和UE2属于不同基站，但属于同频同时隙，UE2此时检测到TS6上的ISCP高达-61dBm，如图 32所示，UE2的SIR较差的原因可能是由于处于同频同时隙的UE1的干扰造成；l 同时对于此案例中，同频同时隙中出现的干扰正好是测试的主被叫UE，对于可能潜在的TD用户在同频同时隙上产生的干扰，可以通过CDL统计出当前干扰附近时间段里的周围小区里用户分布和码道占用情况，RNC会每隔5分钟发送一次“USER distributing” ，该消息由RRM 模块向CDL发送，用来描述Cell的用户分布情况/码道占用情况；问题3：同频同时隙是如何产生的？如何去减少同频同时隙发生的概率？从UE2在出现失步前UE1和UE2的空口LOG来看，UE1从起呼到UE2掉话期间，一直占用华工-1（CPI=91）10080，上行TS2，下行TS6，UE2在起呼时占用华工-1（CPI=91）10080，上行TS3，下行TS6，后切换到闵南-3（CPI=118）10080，上行TS1，下行TS6，并且UE2在闵南-3上掉话。表 31UE占用资源情况表事件UE1占用的资源情况UE2占用的资源情况起呼华工-1（CPI=91）10080，上行TS2，下行TS6华工-1（CPI=91）10080，上行TS3，下行TS6Connect华工-1（CPI=91）10080，上行TS2，下行TS6切换到：闵南-3（CPI=118）10080，上行TS1，下行TS6UE2掉话华工-1（CPI=91）10080，上行TS2，下行TS6闵南-3（CPI=118）10080，上行TS1，下行TS6从上面的表格可以看出，UE1UE2下行码资源都被分配到同一个时隙，并且UE1UE2在同一小区下起呼时被分配同频且下行同时隙，这种分配方式增加了UE间的相互干扰，存在不合理的方面，首先想到是检查华工-1和闵南-3的DCA算法的配置，重点在于载波和时隙的排队方式，图 33图 34中列举了华工-1的载波和时隙的排队方式，“检查发现主要监控区域的RNC405和RNC390下小区中载波和时隙的排队方式采用的都是基于NODE B的公共测量。”图 33DCA中载波的排队方式图 34DCA中时隙的排队方式载波的排队方式基于NODE B的公共测量，则载波的优先级按图 35所示的计算方法计算得到的P j来进行排序。图 35基于NODE B公共测量时载波的排序方式对于时隙的选择方式采用基于的是测量，那么同一载波中上下行时隙的选择按照图 36所示的算法进行。图 36基于测试时时隙的选择方式从上面DCA中对于载波和时隙选择的算法来分析，将被叫UE2分配到UE1已经占用的载波和时隙上的情况是不应该发生的，如果发生此种情况，分析的可能性有如下：l 可能性1：其他载波有用户占用，UE1UE2在华工-1上起呼时被分配同一载波10080，目前华工-1的载频配置为主载波：10088（HSDPA载波），副载波：10080，10096，那么UE1UE2被分配到10080可能因为当时10096有其他用户在占用导致UE1UE2被分配到同一载波，通过查看接入点附近CDL来看华工-1的资源占用情况发现，当时华工-1的10096载波上的确有一个CS64K的用户，所以UE1UE2被分配到同一载波可以解释，但下行被分配同一时隙，没有理论依据；l 可能性2：对于下行被分配同一时隙，可能是由于NODE B公共测量存在问题；l 可能性3：可能测量不存在问题，而RNC用测量结果进行排序处理的时候存在问题；无论是NODE B公共测量问题还是RNC排序处理存在问题，都需要得到NODE B公共测量的原始数据，所以问题继续向下发展。问题4：如何定位NODE B公共测量是否存在问题？判断NODE B公共测量是否存在问题，要有如下准备：1) 了解测量值的报告准则：载波和时隙的排序是基于上行时隙的干扰码功率和下行时隙载波传输功率，那么首先要确定该两种测量值的报告准则，图 37图 38是华工-1的NODE B测量报告准则；图 37上行时隙干扰信号码功率的报告准则图 38下行时隙传输载波功率报告准则2) 如何去获得NODE B的公共测量的原始结果：打开小区公共过程跟踪采集NODE B上报的公共测量参数；了解NODE B公共测量报告的准则后，对于出现同频同时隙的可能性有如下：l 可能性1：上报周期过长，MMC短呼过程中，UE1UE2被分配同频同时隙，由于MMC呼叫时间较短，主被叫UE在资源分配的间隔较短，可能导致DCA算法在进行载波排序和时隙排序的过程中，主被叫采用的是同一个时间点的测量结果，那么会导致分配同频同时隙。从图 38看，华工-1下行时隙传输载波功率的报告周期为1000ms，而MMC过程中，主叫RB分配到被叫RB分配的时间间隔有5000ms之多，所以这其中应该不会基于同一个测量报告。该案例下行出现同频同时隙不是由于报告周期过长导致，但报告周期过长会导致DCA进行排序处理时基于同一个测量报告，并最终导致同频同时隙的发生。因此，检查了所管辖RNC下所有小区的报告准则未发现报告周期过长的小区。l 可能性2:本身NODE B公共测试值不发生变化，对于测量值不发生变化，需要进行LOG的跟踪去定位;对于本案例中进行LOG抓取过程中需要注意的问题：a) 明确需要抓取的LOG类型：NODE B公共测量参数的搜集和小区级的CALLTRACE；b) 测试前明确被测小区的载波和时隙的DCA参数设置是否基于测量；c) 测试前明确当前小区在该时间点是否有其他用户占用，可以让机房协助查看；从小区公共过程跟踪的LOG看,所有载波和TS的Common Measurement Report中的transmitted-carrier-power 都是0 ,没有发生过变化,因此导致队列一直不发生更新,用户始终建立在10080上，消息内容如下：value NBAP-PDU := initiatingMessage : procedureID procedureCode 8, ddMode common , criticality ignore, messageDiscriminator common, transactionID longTransActionId : 0, value CommonMeasurementReport : protocolIEs id 133, criticality ignore, value MeasurementID : 24 , id 31, criticality ignore, value CommonMeasurementObjectType-CM-Rprt : cell : commonMeasurementValueInformation measurementAvailable : commonmeasurementValue transmitted-carrier-power : 0 至此，DCA中RNC将UE1UE2分配到同频同时隙的直接原因已经找到，问题定位到网元NODE B侧：“由于所有载波和TS的Common Measurement Report中的transmitted-carrier-power 都是0，导致队列一直不发生更新”问题5：何种原因导致NODE B上报给高层的测量报告里的测量值均为零？通过中试以及研发人员的测试和确认：l NODE B物理层上报的结果没有问题，中试同事在复现问题的过程中发现，NBAP将测量结果报给RNC时，高层根据过滤系数进行了处理（当前过滤系数为6），通过将过滤系数设置为0，发现NODE B物理层上报结果正常；l NBAP在进行测量结果上报时，是向下取整了，即FCAPB上报（0,1%，且实际功率比较小的时候，NBAP处理为0进行上报，同时研发认为协议上并没有规定NBAP应该如何取整，所以实现没有问题，如需修改的话可以提CR递交产品线审批并修改；小区更新流程失败原因分析问题6:小区更新中，UE发送的物理信道重配置完成消息为何RNC收不到?本案例中UE2掉话的直接原因是由于UE2小区更新流程失败，RNC下发小区更新确认后，未收到UE2上发的物理信道重配置完成消息，最后定时器超时发生掉话，网络侧log如图 31所示，小区更新过程定时器设置如下：图 39MM定时器设置选择了UE2在发送物理信道附近的无线情况如下图，当时的UE的发射功率和当前的接收功率和路损如下图 310所示：图 310UE发送物理信道重配置时情况图由图 310可以看出，当时UE在回物理信道重配完成消息时的发射功率很低，这可能是导致RNC未收到完成消息的原因所在。在切换的过程中，UE使用的是开环功率控制，对于SB的发送功率，规范里定义是和一般数据突发的功率是一致的，只是SB的TFCI填写为“0”，对于DPCH初始功率是通过以下方法计算的：上行初始功率上行期望接收功率（Uu消息配置值）PCCPCH Tx PCCPCH RSCP 10lgSF DPCH信道上行期望接收功率1) 操作维护静态配置。由操作维护设置上行期望接收功率，RNC将此参数配置给UE。可以为每种业务分配设置。2) 根据干扰计算得到。PRXPDCHdes|SF1,dBm=ISCP|dBm+SIR|dB目前现网对于上行期望接收功率的计算采用的是第二种计算方式，那么对于提高上行的初始功率就需要相应的提高SIR的设置，此处的即为“配给NODE B的目标信噪比”影响UE发送物理信道重配置完成消息的功率的参数为“配给NODE B的目标信噪比”（虽说UE发送物理信道重配完成消息时已经进入了闭环，但短时间内外环功控的SIRtarget还可能是该参数在起作用），查看网络侧的小区配置数据，发现该参数设置为3dB建议修改成12dB，以提高RNC接收到物理信道重配置完成消息的几率。图 311华工-1的PC参数设置“配给NODE B的目标信噪比”设置过低会导致UE上发的物理信道重配置完成消息，网络侧无法收到从而引发小区更新失败和切换失败最后导致掉话，因此，检查了所管辖RNC下，所有小区“配给NODE B的目标信噪比”的设置，发现