核心网案例汇总

1、爽8、RNC间切换成功率问题定位备注：RNC割接完毕后，切换成功率不足5%,原因为RNCID配置错误1、收集RNC IU 口信令进行分析，发现CN返回RELOCATION FAIL 原因为unknows target rnc，联系 CN侧进行数据核查，补订数据，观察话务统计，切换成功率提高到50%。3、由于小区级话务统计正常，因此问题初步判断还是RNC与CN间存在问题，再次收集IU 口信令， 发现已无RELOCATION FAIL。分析counter计数方式，RNC发起RELOCATION后，计为一次RNC 间请求尝试，收到FAIL或无响应计为失败。分析所有IU 口信令发现，仍存在部分RNC发

2、送 reloction request后，未收到cn任何响应4、由于CN侧无响应，还是怀疑与CN侧对接数据存在问题。根据上诉信令点分析，发往SGSN的数 据全部失败，联合产品、CN现场复测跟踪，发现RNCID定义有误，修改后，切换成功率达到95%以 上。9、主控板隐性故障导致PS业务异常备注：三个小区的PS业务均异常，做64K上传、384K和H业务下载时，速率 都很低，且既不稳定。4，由于该岛8个站点中7个站点均能正常处理PS业务，所以RNC参数应该没有问题，和产品人员配合 对RNC、NODEB的开站脚本进行了参数核查，均无异常。5，通过以上排查，怀疑问题出在基站安装或者某个控制板的隐性故障。

3、对该站进行测试，能够正常进行 CS业务，和切换业务，所以排除CS域故障，问题定位控制PS域的某个单板，将问题定位于主控板。工程人员更换SGSN主控板后，进行复测，各个PS业务均能正常运行，H业务达到1.3M以上稳定速率， 问题解决。10、PS高掉线率处理案例某局点PS掉线率一直居高不下，经过分析，掉线次数主要集中在其中一个RNC的4个 小区。告警信息：无PS掉线率=RNC请求释放的分组域RAB数目/PS域RAB指派建立成功RAB数目*100% 原因分析：从PS掉线率统计公式中，可以看出要降低PS掉线率必须要减少RNC请求释放的分组域RAB数目。处理过程：经过多天对掉线TOPN小区的观察与分析，

4、发现掉线次数TOPN小区为A、B、C、D等4个小区，且RNC请求释放的分组域RAB数目统计中发现这些小区所覆盖的用户中有5 个IMSI贡献的次数占整个RNC释放的RAB数目的一半以上，通过协调客户核查这5个 IMSI所对应的SIM卡，发现这些卡都没有开通TD业务功能，导致PS掉线率居高不下。 协调客户对这些IMSI用户开通TD业务功能后，跟踪最近2天指标发现这些TOPN小区 PS掉线问题已经基本解决。土 工工 由于TD是一张新网络，终端、设备等一系列配套仍在不断完善中，我们在日常优化中遇 建议与总结：到问题，要多方面考虑，设备、终端及用户行为等都可能对网络造成影响。QAAL2_PATH未配置导

5、致无法占用H载波某局点进行HSDPA 下载业务时，下载速 率最高只能达到384Kbps。告警信息：无导致下载速率慢的原因可能为：1、天馈、载频等硬件故障导致无法占有H载波；原因分析：2、USIM卡签约速率问题，不支持HSDPA业务；3、看看TRAMAP中H业务的传输映射是否正确；4、参数配置不当，导致无法占用H载波。1、由于该手机和卡在其他站点可以正常测试，而且在RAB_ASSIGNMENT_REQ小 区中也看到了分配的业务速率是2048000，所以排除卡开户速率问题；2、DSP CARRIER看H载波的状态是激活状态；3、LST TRAMAP看到H业务是承载在H PATH上；4、跟踪信令，发

6、现发往和来自NODEB的QAAL2_ESTABLISH_REQUEST出现了 2处理过程：次，第1次分配PATHID为1，不成功，第2次分配PATHID为2,业务就在该PATH 上进行，但是一般的脚本中配置了 4路PATH，H业务一般占用第3条PATH，该问 题就是出在HSDPA的PATH有故障，业务通过NRT的PATH进行，因此只有384kbps ；5、根据以上分析，回头DSP AAL2PATH发现第3，第4路PATH故障，原因是NODEB 侧未配置；6、重新配置数据，该问题解决，测试后H业务恢复正常。建议与总结：H业务在现场问题定位中一定要对数据进行仔细检查，由目前发现的问题中数据配置 问

7、题导致的H业务异常现象比较常见。12异厂家RNC间切换算法差异导致RNC间切换 成功率低A市TD网络由华为和ZX公司合力承建，从我司话统发现RNC间切 换出成功率低，在85%左右，PS和CS均低。告警信息：原因分析：无1、统计现网的告警，发现并无大面积的和切换强相关的告警，排 除设备原因。2、从OMC统计华为向华为RNC间的切换成功率、华为向ZX的RNC 间的切换成功率，发现华为对华为RNC间的切换成功率在96%左右， 华为对ZX的RNC间切换成功率在75%左右，说明我司的RNC间切换 成功率指标低是由于我司和ZX RNC间切换成功率低造成。3、分别提取CS域和PS域的RNC间切换成功率，发现

8、两个指标均 低，为65%和86%左右。说明是PS和CS域的RNC间切换成功率低 共同造成了整网的切换成功率低。4、统计我司RNC间切换失败原因counter，发现主要失败原因有两 个：trellocalloc-expiry 和failure in target RNC or CN or target system，分别占失败原 因的70%和25%。5、提取出我司RNC间切换失败的TOP小区，并通过CELL-NCELL提 取出ZX侧的目标小区，用大唐8130e测试终端现场验证，经测试 一切正常，切换成功率为100%。用同样方法更换多个TOP小区进行 测试，均不能复现切换失败的情况。6、协调ZX侧

9、察看目标侧的话统，发现ZX的RNC间切出和切入指 标均正常，我方切换出TOP小区对应的ZX侧目标小区的话统均良 好。7、为排除话统不准确的可能，我们全天跟踪全网的IU 口和TOP小 区的IUB 口信令，发现确实存在很多trellocalloc-expiry和 failure in target RNC or CN or target system 引起的 RNC 间切 换失败，不能复现问题原因定位为测试方法问题。8、现网有多种测试终端，我们使用鼎新的DX188终端进行测试， 复现了问题。测试发现，从我司开始业务后进入ZX区域，PS业务 表现为RNC向核心网上发RELOCATION REQUIR

10、ED后，9秒钟后核心 网下发 RELOCATION PREPARATION FAILURE，原因值是 trellocalloc expiry。CS业务表现为RNC向核心网上发 RELOCATION REQUIRED 后，6 秒钟后核心网下发 RELOCATION CANCEL， 原因值为 failure in target RNC or CN or target systemo 但 是，从ZX侧起呼后进入华为区域，再回到ZX区域，切换正常。9、对比RNC间切换成功和切换失败的RELOCATION REQUEST信令解 码，发现不同之处很多，主要是切换失败的解码中rRC-Container 的1

11、6进制串末尾多3个BIT，询问研发得知，主要是华为RNC与 ZX的RNC对于IU 口的ASN编解码的理解不一致：ZX采用的ASN编 解码工具编解码工具认为rRC-Container中的len-in-bits的长度 只包含Value结构体的长度；华为采用的ASN编解码工具编解码工 具认为rRC-Container中的len-in-bits的长度包含了 len-in-bits和Value结构体的长度。而协议并没有明确规定 len-in-bits计算按照固定长度计算还是实际长度计算的方法，所以该差异导致切换兼容问题。问题定位结束。处理、过研发人员开发补丁，打上补丁后，rRC-Container的16

12、进制串末尾处理过 少带BIT以适配类似ZX的处理方式，问题得到解决，CS和PS域 王：RNC间切换均正常，切换出成功率提升至97%。建议与总结：在涉及跨厂家的切换时问题很多很杂，我们分析处理时要思路清 晰，针对性要强。另外，要和研发保持良好沟通，促进问题快速解 决。13天线类型设置错误导致功率不匹配现象描述：某站点小区进行MAXTXPOWER功率设置时，提示功率不匹配。问题分析：导致功率不匹配的原因可能为：1、NodeB设置的功率过小，导致RNC功率设置比NodeB设置功率大时出现功率不匹配 现象；2、RRU级联过多，导致功率设置受限；3、参数设置不当，导致功率不匹配。处理过程：1、检查Nod

13、eB脚本，发现NodeB功率设置为MAXDLPCSPSC=460，没有问题；2、跟踪IUB 口信令，在MML中键入ADT RES: NODEBNAME=XXX命令进行资源核查。在跟踪的信令中查看NBAP_AUDIT_RSP消息中报上来的功率值为410，如下图所示：maximumDL-PowerCapability:0 x19a (410) minSpreadingFactor:v256 (6)3、由于该站点为室外站，使用的RRU为268,不存在级联现象；4、检查该站点NodeB脚本数据，发现天线类型设置为室内类型，而该站点实际为室外宏 站；0Circular（8U 阵型）摺号天魏类型SPIan

14、ar（S 平阵型） 6Planar（6 平阵型） Singl及单根型） 6Circular（6阵型）IndcicirCciv(室内类型)BDualF血(8取极型) In血cirCciv屋内类型)pr5、把天线类型设置为8双极型后功率设置正常，功率不匹配问题解决。14PS接通率提升(RAB.SuccEstabPSNoQueuing.Conv+RAB.SuccEstabPSNoQueuing.Strm +RAB.SuccEstabPSNoQueuing.Intact+RAB.SuccEstabPSNoQueuing.Bgrd) +(RAB.SuccEstabPSQueuing.Conv+RAB.S

15、uccEstabPSQueuing.Strm +RAB.SuccEstabPSQueuing.Intact+RAB.SuccEstabPSQueuing.Bgrd)/ (RAB.AttEstabPS.Conv+RAB.AttEstabPS.Strm+RAB.AttEstabPS.Intact +RAB.AttEstabPS.Bgrd)*(RRC.SuccConnEstab.Sum/RRC.AttConnEstab.Sum)*100%由于PS接通率目前主要问题是RRC建立成功率低，目前RRC.SuccConnEstab.Sum是统 计全业务的RRC建立成功率，现网影响RRC建立成功率的主要原因由

16、于PS域频繁重选 业务的 RRC 建立失败(RRC.AttConnEstab.11 RRC.SuccConnEstab.11)造成的。.11业务主要是统计PS域GSM小区重选到TD网络后由于需要注册造成的RRC建立失败。1、通过分析发现PS接通率由于p业务特点造成频繁在gsm和TD网络进行注册，导致RRC建立失败的TOPN小区，占所有RRC建立失败原因50 %左右，下图为PS域RRC 建立原因所有业务失败统计：3、解决建议：调整 GSM 小区参数 Qsearch_I = -74dbm,TDD OFFSET=-2,目的是减小从 GSM 网络重选回TD网络的概率，降低由于用户上网地方3g弱覆盖造成

17、的RRC频繁注册 失败。3g小区配置的2g邻区如下表所示(相应的2g也配置了同样的3g小区)：15某局点PS域异系统出切换成功率低分析物理信道失败原因很多，主要有以下几个:1、2G侧基站链路存在问题；2、3G侧基站异常；3、2G邻区配置参数不匹配，如2G侧BCCH、BSIC、LAC、RAC等参数和3G侧 邻区参数配置不一致；4、终端问题。处理过程：1、针对2G、3G出切换成功率低的问题，我们首先通过KPI话统进行分析统计，发现2G、3G切换成功率低的问题主要表现在PS域，CS域的23G成 功率每天保持在97%以上。而且PS域的失败也主要分布在放号用户密集 区域。提取全天PS域异系统出切换失败K

18、PI进行分析，从全天统计来看， 失败主要原因为IRATHO.FailOutPsUtran.2（RNC收到UE发送“从UTRAN 小区改变失败”（CELL CHANGE ORDER FROM UTRAN FAILURE 消息次数，指示分组域系统间切换出失败，对应原因：物理信道失败）。2、对邻区配置参数进行核查，未发现问题。3、检查2G、3G基站运行状态，未发现问题。4、修改 PS 域 2G、3G 切换门限参数 HSPATIMETOTRIG3AUSEDFREQHTHDRSCP、， 使UE尽量占用TD网络，避免频繁的23G切换。问题解决。指标有了明 显提升。16核心网鉴权拒绝导致主叫起呼失败国内某T

19、D局点，局方经理投诉在进行正常拨打过程中，主叫起呼后未听到任何放音提示 回到空闲态，起呼失败。告警信息：无原因分析：由于诺西核心网在被叫进行接入过程中鉴权拒绝，导致被叫直接被拆链；同时主叫收到 核心网下发的释放消息，未进入alerting过程，主叫直接回到空闲状态。经过拨打后问题在14:00呼叫时重现，现将问题分析如下：1.从主叫看，UE从RRC连接请求后信令流程正常，在RAB建立完成后（14： 00： 06 （44），UE收到核心网下发的disconnect直传消息命令，如下图示。释放的原因值为 destination-out-of-order，目标不可达，即被叫端问题。处理过程：从被叫的信

20、令来看，被叫的鉴权请求被拒，故被叫在Altering前就发起来RRC连接释 放，主叫UE随后没有收到被叫Altering信令也进入释放流程，起呼失败，所以从用户感 知看主叫UE进行拨号起呼后的4s内，没有听到任何声音提示（即无铃音或核心网放音 提示），直接回到空闲状态。查看被叫UE信令，被叫在14:00:03收到核心网的寻呼消息，之后发起RRC连接，进 入鉴权加密的过程中，在14： 00： 06（33）进行了鉴权回复，如下图示；但是在14： 00：06（50）核心网下发直传消息鉴权拒绝，之后被叫UE进入释放过程，直接释放RRC连 接。同时主叫在14： 00： 06（52）收到核心网的disco

21、nnect消息，释放原因为被叫不可 达。4.针对该问题咨询诺西核心网工程师，诺西交换机上跟踪信令发现拒绝原因为鉴权不通 过，即非法用户，原因是SRES （符号响应，鉴权3元组其中一个元素）不匹配；导致核 心网认为UE非法；进一步跟踪分析发现，SRES不匹配的的原因是SRES手机计算的结 果和VLR中不一致，导致鉴权不通过；诺西工程师认为是SIM卡工艺问题导致的小概率 事件，通过打开2次鉴权可避免该类接入失败。建议与总结：对于该类问题先抓住出现问题的网元，再进行深入分析可提高效率。 在排除无线原因后，需要考虑因核心网/传输影响导致问题出现。17普通PS业务RAB建立后直接释放新开通的部分站点在做

22、PS384单站验证的时候，RAB连续建立两次，手机收到CN下发 的PDP激活接受后，IU 口发起释放。第二次再次申请相同的业务，RAB只建立一次， 上行直接为32k，且没有PDP激活接受的直传消息。做H业务没有任何问题。告警信息：无1、怀疑终端原因，使用别的终端测试。仍然出现这种现象。原因分析：2、因为第一次都是信令面建立完全后才释放，所以查询是否基站的业务面配置有问题，经产品同时配合查询后和其它基站也没有任何区别。1、因为存在RAB请求的上行降速，所以怀疑DCCC参数问题。核对DCCC参数基线， 没有问题。同时关闭DCCC算法测试还是出现上述情况。2、某次现场使用数据卡测试，出现相同的想象。

23、因为数据卡没有手工选择R4或者R5 的开关，所以前期统一把下行BE业务H判决门限：DLBETRAFFTHSONHSDPA统一从 64改为512。这个参数的含义是：当终端下行请求速率大于等于512则网络侧分配H资 源给终端。如果此参数是64那么我们的数据卡只要申请大于等于64都会上H载波，项 目上的数据卡就无法做R4的PS测试。后来因为单站验证的结束和用户的增长，怕PS出现拥塞，统一把 DLBETRAFFTHSONHSDPA修改回64，复测后发现业务正常，但是占用的是H载波。处理过程：也就是说不管是手机主动选择R4还是，调整网络侧的参数DLBETRAFFTHSONHSDPA，让网络侧决定占用R4

24、都会有上述的失败现象。占用H就不会出现。3、再次查询基站配置，发现数据和别的站点配置相同。但是只有一个主载波可用，查询 发现此载波是H载波。经过和产品侧确认，因为他们为了进度开通的很多站都只配了一 块BBI板，其它的BBI板未到货，所以只开通了一个主载波。我们网络侧现在的配置现 在H2D,D2H的开关都是关闭的，所以终端申请的上行64,下行384网络侧或者手机直接 判决为R4载波，但是网络侧无法把此业务迁移到H信道。至于发起两次RAB建立。至 于第二次上行降速为32,可能是现网配置的DCCC的中间速率是32导致。4、使用一部8130手机，在手机上强制选R4。然后模拟只有一个H主载的场景（毙掉其

25、 它载波），出现和之前一样的失败想象。1、产品开站要按照标准配置开通，不能只为了赶进度。如果那些未按照标准开通应该知 建议与总结：会网优人员，以免出现很多难定位的问题。2、出现批量站点无法做业务，看是信令面见不起来还是业务面有问题。如果是业务面的 问题，着重注意基站的物理配置。附件:R4 的 ps 业务建链后释放.doc18小区服务区码与核心网配置不一致造成终端无法接入移动大楼站点测试前后台信令前台测试信令截图:16:42:27.8416:42:27.95316:42;7.95316:42:42.06216:42:42.60916:42:42.71816:42:42.023ssteml nfo

26、rmationEJlockT vpe5systeml nformationBlo.T 5Jpe3 systemi nformationB lockTvpe2 . rrcConnectionRequsUL_CCCH) rrcConnectionSetupfD L_CCCH) rrcConnectionS etupComplete(U L_D CCH) Location Updating Requasir .16:42:47.960 DL rrcConnectionReleasefDL DCLH16:42.40.073 UL rrcConnectionR eleaseComplete(U L_D

27、CCH)16:42:48.296 UL rrcConnectionR eleasgCompletefU L_D CCH iQ lessageDecode - 1014 自贡移动室分IE； MessageDL-D CCH-Message- message- rrcConnectionR elease- Iater-than-r3rrc-T ranacJtionldentirier,一； criticalEKteriafcirrs 工,rtl 、又入. 图(1)前台测试信令r4rrcConnectionR elease(D L_D CCH)lu接口跟踪 皿发往RANAP_IU_RE LEASMPL

28、ETElu接口跟踪1迫0发往C0RANAP_I N ITIAL_U E_M ESSAGElu接口跟踪1：J：3RANAP INITIAL. UE MESSAGE!口接口跟踪 1：!J：3发往却RANAP INITIAL. UE MESSAGE令截图:nrnnnprHni 1R aIrasa-； d1:Q:3RANAP INITIAL UE MESSAGE发往 C NRANAP INIrIAL L!E MES SAG E发往 C NRANAP INITIAL l!E MES SAG E发往CNRANAF INITIAL UE MESSAGE19 TD-HSDPA定点下载速率不稳定的解决过程S省C

29、市TD网络某站点单站验证测试过程中，发现某站H业务下载速率不稳定，波动 较大，峰值过低（1.2mbps左右），平均速率为900kpbs左右；通过其他区域测试工程师 反馈，与该站问题现象一致且都是大面积都是同样问题；如附件中图1:告警信息:原因分析:处理过程:建议与总结:附件：通过分析LOG发现在该站3小区在作H业务时，DPCH RSCP及DPCH C/I波动较大且 有规律波动（不属于正常无线信号的波动），如附件图2：在DPCH RSCP和DPCH C/I 波动时H业务下载速率也跟着变化，当DPCH变小时H下载速率也变慢（500-700Kbps 之间），反之H下载速率较快（1-1.2Mbps之间

30、）；无无线环境恶劣（干扰）导致重传率高；HLR定义问题，用户开户速率较低；小区信道资源不足，多用户共享；NODEB或RNC硬件问题导致；RNC与NODEB数据配置问题导致；下载数据源问题，FTP服务器限速；测试软件及测试终端问题导致；1、测试地点无线信号很好，PCCPCH RSCP和PCCPCH C/I均在较好的水平 （PCCPCH RSCP=-64dBm,PCCPCH C/I=-17dB），且 CS 业务均正常；排除弱覆盖；2、由于测试时DPCH RSCP及DPCH C/I波动较大，为了排除干扰，寻找较偏远的B基站并去激活其他所有同频小区后进行H业务测试；如图所示，PCCPCH RPCP、P

31、CCPCH C/I、DPCH RSCP、DPCH C/I都较好，波动随于正常的无线信号波动（不像之 前波动呈“矩形”），问题依然没有解决，H速率不稳定的现象依然存在；排除无线环境恶 例引起的干扰；3、之前在其它区域作单站时使用的测试软件和终端及测试卡均与目前一致，所以首选 排除测试软件、终端和HLR开户速率问题；4、将问题反馈给后台系统分析工程师，跟踪该站2小区码资源占用情况，得知该小区 只有一个H用户占用（就是我们自己测试卡），同时也查询该站没有硬件告警出现；排除 多用户共享导致和硬件告警；5、该问题现象在多区域大面积的出现；并且这几个区域均属于同一个RNC，初步怀疑 新建RNC问题，联系R

32、NC督导核查RNC侧配置脚本未发现异常，并RNC督导将重新 执行一次RNC配置脚本和RNC备件进行主备份倒换；排除RNC侧和NODEB硬件问题 导致；6、现场测试改用从internet寻找的可用资源进行下载测试（使用讯雷外加多下载任务方 式），下载速率均不稳定，排除FTP服务器限速问题的影响；7、通过对测试软件H业务测试任务进行核查，发现连接线程数设置为3；如下图所示， 将连接线程数改为10后测试10次H速率都较稳定，且峰值达1.8Mbps，期间未发现 DPCH RSCP和DPCH C/I呈矩形波动情况出现（DPCH的波动随于正常的无线信号波动， 但整体情况较之前测试要好）；注：线程可以理解为

33、下载的通道，一个线程就是一个文件的下载通道，多线程也就是同时开起 好几个下载通道.当服务器提供下载服务时，使用下载者是共享带宽的，在优先级相同的情 况下，总服务器会对总下载线程进行平均分配.不难理解，如果线程多的话，那下载的越快. 定位问题时先通过问题现象判断可能出现问题的大概原因，然后再逐一通过现场测试方 法的调整、后台数据的检查，这样逐一排查后，缩小问题的范围。TDHSDPA定点下载谏率不稳定的解决过程.doc20同小区内立即激活缺省偏移值设置不当造成并发业务失 败在秦淮西路-3小区经行并发业务测试时，如果先进行H业务之后尝试语音业务会导致RAB 建立失败，同时H业务掉话。201 U-03

34、-1 y 11 ：1 3:01 (56)5726U： 0： 3来自|JERRC_UL_DIR_TRANSF2010-03-19 11:13:01(56)57270:0:3发往UNRANAP_DIRE CT_TRAN SFER201 U-03-1 9 1 1:1 3:01 (64)63500:0:3来自CNRANAFLDIRECT-TRAN SFER2010-03-19 11:13:01(64)63510:0:3发往UERRC_DL_DIRECT_TRANSF201 U-03-1 y 1 1:1 3:02(00)9245U： 0:3来自UERRC_MEAS_RPRT2010-03-19 11:1

35、3:02(01)93630:0:3发往NodeBQML2_M 0 DI FY.RE Q UE ST201 U-03-1 9 1 1:1 3:02(03)9472U： 0： 3来自NodeBQAAL2_MO DI FY.AC KN OWLEDGE2010-03-19 11:13:02(03)4310:0:3发往NodeBNBAP_RL_RECFG_PREP201 U-03-1 y 1 1:1 3:02(07)9837U： 0： 3来自NodeBNBAP_RL_RECFG_READY2010-03-19 11:13:02(07)98460:0:3发往UERRC_RB_RECFG2010-03-19

36、 11:13:02(28)114750:0:3发往NodeBNBAP_RL_RECFG_COMMIT201 U-03-1 9 1 1:1 3:02(76)15325U： 0： 3来自|JERRC_RE：_RECFG_CMFI2010-03-19 11:13:02(76)153520:0:3发往UERRC_MEAS_CTRL201 U-03-1 9 1 1:1 3:05(08)33878U： 0： 3来自CNRANAP_RAB_AS SIG NMENT_REQ2010-03-19 11:13:05(09)339660:0:3发往UNQAAL2_E STABLISH_REQUEST201 U-03

37、-1 U 11:1 3:05(1 5)34485U： 0： 3来自CNQ.M.L2_ESTABLISH_CON FIR M2010-03-19 11:13:05(1 6)345500:0:3发往NodeBNBAP_RL_RECFG_PREP201 U-03-1 9 1 1:1 3:05(24)35165U： 0： 3来自NodeBNBAP_RL_RECFG_READY2010-03-19 11:13:05(24)3517S0:0:3发往NodeBQML2_E STABLISH_REQUEST201 U-03-1 y 1 1:1 3:05(27)353970:0:3来自NodeBQAAL2_ES

38、TABLISH_CON F IR M2010-03-19 11:13:05(27)354250:0:3发往UERRC_RB_SETUP2010-03-19 11:13:05(48)370740:0:3发往NodeBNBAP_RL_RECFG_COMMIT201 0-03-1 9 11:1 3:10(49)771730:0:3发往ONranap_rab_as signment_resp201 0-03-1 9 1 1:1 3:1 0(49)77173U： 0： 3发往卵RANAFLIU-RE lease_req uest201 0-03-1 9 1 1:1 3:1 0(49)77173U： 0：

39、 3发往C：NRANAPJU_RE LEASE_REQUEST201 U-03-1 9 1 1:1 3:10(52)774460:0:3来自CNRANAPJU_RE LEASE_C 0 M MAN D201 U-03-1 U 11:13:10(55)77631U： 0： 3来自CMRANAPJU_RE LEASE_C 0 M MAN D201 0-03-1 9 11:1 3:10(55)776390:0:3发往UNQAAL2_RE LEAS E_R EQUEST201 0-03-1 9 11:1 3:10(55)776480：0：3发往UNRANAPJU_R E LEAS E_COMP LET

40、E201 0-03-1 9 11:1 3:10(55)776490:0:3发往UNRANAPJU_R E LEASE_COMP LETE201 0-03-1 9 11:1 3:10(55)776500:0:3发往UERRC_RRC_CONN_REL201 U-03-1 9 1 1:1 3:11 (40)84445U： 0： 3来自|JERRC_MEAS_RPRT201 0-03-1 9 11:13:14(81)96 8 U U0:4:3来自CNRANAP_PAGING201 0-03-1 9 11:1 3:15(56)1177150:0:3发往UERRC_RRC_CONN_REL201 U-0

41、3-1 U 11:13:19(94)1 4 4 El U 50:4:2来自CNRANAFLPAGING2010-03-19 11:13:20(57)1577910:0:3发往UERRC_RRC_CONN_REL201 U-03-1 9 1 1:1 3:25(94)192793U：4：2来自CNRANAFLPAGING2010-03-19 11:13:25(58)1978730:0:3发往NodeBNBAP_RL_DEL_REQ此次CS业务没有建立成功，5秒后RNC申请IU RELEASE, PS业务掉话。原因值为：无线进 程接口失败。如下图所示：1.根据其后台跟踪RB建立的具体信令可以看出RB

42、建立失败原因为ulWatiRbFailTimer is too shorto2010-03-19 11:13:05 (27)FSM: KB MS: RB_SETUP_DCH2DCH SS: RB_WAIT_RL_RECFG_RSP Interface: RBCAT_INTRA_IHTEJJAJCE Msg： RBCAT_RL_SYNC_RECFG_RS：2010-03-19 11:13:05 (27)INFO-RR_EER_RB_06All - ffErr in fJjTCAP_ActTimeGetDITfcslnfo: ucChoice of CtfcSize in aItem0 is UU

43、_CTFC6_BIT_CHDSEN!2010-03-19 11:13:05 (27)INFO- ER_EBR_FiL0651 - Err in RffCAJ_tWai tRbFailTimer: ulWatiRbFailTimer is too short. iLTim er Value = 1902010-03-19 11:13:05 (27)旺 M: RB MS: FiLSETHT_DCK2DCHSS: EB_WAIT JJE项B_SETUT_FAIL2010-03-19 11:13:05 (27)FF ID 184 sends out dl trch sync frairie, retr

44、ycdurLter 0 times5秒后RB建立超时，IU释放。如下图所示:2010-03-19 11:13:10(49)FSM:RB MS:RB_SETUP_DCH2DCH SS:RB_WAIT_UE_RB_SETUP_RSP Interface:RNCAP_CCB_STATE_TIMER_INTERFACE Msg：RMCAP_T1_RB_WAIT-UE-RB_SETUP_RSP12010-03-19 11 13:10(49)INFO-RR_ERR_RB_0310 - “Err in RNCAP_RbSetupDch2DchUeTimeout： Wait W_RB_SETUP_CMP message timeout.2010-03-19 11:13:10(49)FSM：RAB MS：RAB_SETUP_CS SS:RAB_WAIT_RB_SETUP_RSP Interface:RNCAP_INTRA_INTERFACE Msg：RHCAP_RB_SETUP_FAIL与其他小区进行参数