核心网案例汇总Word文件下载.docx

1、required消息，但是CN没有向目标BSC发送Handoverrequest消息，导致计时器溢出，RNC判决向次优小区（江滨路国土局-1），切换失败。 该区域GSM、TD-SCDMACN侧设备均属于NSN（诺西）。 58、RNC间切换成功率问题定位 5RNC割接完毕后，切换成功率不足5%，原因为RNCID配置错误 59、主控板隐性故障导致PS业务异常 6三个小区的PS业务均异常，做64K上传、384K和H业务下载时，速率都很低，且既不稳定。 610PS高掉线率处理案例 611，QAAL2_PATH未配置导致无法占用H载波 612异厂家RNC间切换算法差异导致RNC间切换成功率低 713 天

2、线类型设置错误导致功率不匹配 814PS接通率提升 915某局点PS域异系统出切换成功率低分析 1016 核心网鉴权拒绝导致主叫起呼失败 1117普通PS业务RAB建立后直接释放 111、23G切换迁移失败问题分析与解决了MSC侧参数，发现PHASE2错误处理功能开关未激活，导致23G切换失败通过以上排查，可以断定此现象与TD侧网优参数无关，且23G侧也对TD的数据进行了正常的定义，所以能够存在正常的切换，只是由于某个协议错误，导致了切换存在失败的概率，且迁移失败原因为协议错误。与核心网人员一起进行了问题的定位，核查了MSC侧参数，发现PHASE2错误处理功能开关未激活，将该开关打开后，问题解

3、决.该参数在中兴的TD网络中也出现过类似的问题，同样在华为设备中，RNC发出迁移请求时，所包含的classmarkInformation2不能被爱立信的MSC所完全翻译，核心网发往爱立信的BSC后就会被拒绝，当PHASE2错误处理开关被激活后，由于数据不能被完全解读而造成了大量迁移失败问题得以解决。2、接入CE数据错误导致PS业务概率性出现速率为0的问题题RNC中任意小区均能概率性出现PS业务无速率，原因为接入CE数据错误1、从前台观察，在ftpdownloadconnect如果有senderretr信令返回DPCH会恢复，业务速率正常。2，若没有senderretr信令返回，则DPCH持续很

4、低（DPCHRSCP在-80多，C/I在-20左右），PS业务速率为0。4， 核查了问题RNC的网优参数，与正常RNC的参数进行了对比，并将问题RNC中与正常RNC不同的网优参数进行了修改，修改后测试，问题仍然存在。其中：为了提高手机的DPCH，修改了相关速率的最小和最大发射功率，测试后，无效果，在PS业务无速率时，DPCH的RSCP和C/I仍然会陡降。修改了DCCC相关业务业务索引的4A4B参数，单信令切换开关等参数进行测试，无效果。与SGSN侧人员配合定位问题，核查了数据配置，无问题，抓取了核心侧的信令发现当PS速率为0的时候，RLCBO值为0，怀疑传输存在问题。5， 6，和产品人员对传输

5、进行定位，据查，RNC2和RNC6有部分IPPATH的IP检测开关是关闭的，将其打开后，发现RNC2出现两条目的地址不可达告警，RNC6出现3条目的地址不可达告警。将RNC2和RNC6的GOU单板复位后，告警仍然存在，复位RNC6后，问题依旧存在。7， 将RNC2和RNC6上出现告警的IPPATH删除后测试，发现问题依旧出现，排除是IPPATH的原因。8， 与汇聚CE工程师进行问题排查，在NE80E侧PingCE05的Loopback地址Ping不通，pingCE05的直链地址可以Ping通，查看到CE05的接口是G1/0/6G1/0/7两个接口做的端口聚合，G1/0/6接口是UP的，G1/0

6、/7接口是Down的，查看G1/0/7接口是强制全工，光功率发送正常，接收光功率在-34DB。基本可以判断是CE05发光到CE01异常。9， 据分析：如果CE01有网管，并且网管发送告警的话，客户应该会查到这个问题。原因是：GE光口异厂家对接，移动采用的是强制全双工的方式。在单链路时可以靠Ospf来检测接口是否异常。但是威海同时采用的链路聚合，当SE800发送故障时，NE80E可以检测到，但是NE80E发送仍然正常，SE800无法检测到自身发送存在问题。SE800接口仍然UP，在数据转发时，数据Hash到两个接口向外发送，导致经过CE05-SE800的数据部分被丢弃。10， 当其中一个接入CE

7、的传输数据故障时，走该通路的业务就会不可用，所以会概率性出现PS业务速率为0的问题，将该接入CE的传输数据重新做后，业务恢复正常。3、通过OMC定位解决跨RNC切换失败问题出现大量跨RNC切换失败，通过omc定位问题，由于无线环境不好1、 LSTNRNC，查看邻RNC是否定义，参数是否正确；然后通过LSTNRNCNCELL核查PS域的跨RNC相关数据是否配置，通过LSTIPPATH，查看是否将邻RNC的IP数据定义，此项影响PS域的切换；和核心网沟通，核查MSC数据是否定义了邻RNC,此项影响CS域的切换。VS.HHO.ReqRelocPrep.RF：因无线链路信号质量导致硬切换伴随迁移出小区

8、准备次数。HHO.FailOutInterCellInterFreq.2：RNC内小区间异频硬切换出失败次数由以上原因值和地理环境我们可以大概猜测出此次用户行为为：当用户在家里进行PS业务上网时，由于震琳1小区信号在室内衰减严重，导致无线链路信号质量不好，向银镝服饰2小区做出硬切换迁移准备，且由于此时银镝服饰2小区信号强度不够，导致银镝服饰2小区和UE的物理信道建立失败。4、RRU版本不同，导致切换失败问题出现的原因是由于RRU版本不同4. 通过更换不同终端在问题站点进行测试，发现只有DT8120占用问题小区后可以正常出切换，其他终端DX128、ET128和DX188均无法正常出切换。5. 根

9、据研发人员建议，将CONNMODETIMER中的T312值由1S修改为3S，现场测试，发现切换成功率有所提高，但是切换失败现象仍然存在；并且在测试中发现RRU同为SPC520版本的站点之间，出切换都没有问题。6. 9月27日按照产品人员的建议，修改其他小区到本小区切换均为硬切换；修改后无效果；7.考虑到由于问题小区为无法正常出切换，所以尝试修改问题小区到其他小区的切换均为硬切换，现场测试后，发现切换正常，问题规避。5、PS掉线次数RNC级和小区级统计不一致分析现网PS掉线率问题时，通过RNC级话统得到，两个RNC的掉线次数总和为760次，通过小区级数据查找掉线主要由何种PS业务引起时，发现H掉

10、线次数达2000多次，加之PS384K、PS128K、PS64K，各业务掉线总和为2192次，和RNC级统计的不一致，具体指标详见附件。最后通过请教研发，给出的解释是，不一致是因为RNC 4.0.1版本做过优化导致，即对于影响掉话率KPI的counter：RNC级IU.NbrRABPSRelIuConnperCause.16这个指标去除了该项统计，而CELL级保留。6、TD终端无法起呼案例RANAP_SECRRITY_MODE_REQUEST，无法起呼将该问题升级之后，办事处人员反馈情况为SIM卡的数据配置有误，正常的鉴权会连续导致位置更新失败，鉴于对SIM数据修改的操作难度较大，故对核心网的

11、鉴权模式进行修改，降低了鉴权的要求，准许用户正常接入。由CN发送至RNC后RNC对UE下发的RRC_SECURITY_MODE_CMD命令后，UE能够正确的将RRC_SECURITY_MODE_CMP命令回复给RNC，RNC将此命令发往CN。7、MGW问题导致异系统切换失败该区域GSM、TD-SCDMACN侧设备均属于NSN（诺西）。由信令可知：在3A上报后，RNC侧向CN侧发起重定位请求，CN侧收到请求后却未向目标BSC发送切换命令，导致切换失败。进一步通过专用工具进行Mc接口信令跟踪流程,发现在14:42:42712MGW上发消息TransactionReply,原因值为Insuffici

12、entresources。首先MGW侧因其内部原因未成功分配切换相关资源，原因值为Insufficientresources；其次,因上述原因导致A接口交换机释放资源，原因值为ProtocolerrorbetweenBSCandMSC；最后因上述原因导致IuCS接口交换机释放资源，原因值为：message_not_compatible_with_receiver_state。可知MGW内部相关软硬件问题导致异系统切换失败。进一步和诺西MGW侧研发工程师进行问题联合分析。MGW侧研发跟踪MGW信令。从MGW的消息追踪来看，可以发现负责承载资源控制功能的模块BC2给H.248模块hta发出“出错报

13、告”（CA28消息），随后该出错信息通过H.248消息送往MSS。诺西研发反馈该问题发生在主被叫UE几乎同时（前后间隔200ms以内）向同一MSS发起切换时造成。第二个切换空口完成之后MSS请求MGW改变拓扑结构，此时任何一个老的Iu口都还没有释放。但在MGW响应该拓扑请求之前，第一个切换方的Iu接口资源释放，MGW拓扑结构中的termination与之前在请求中的情况已经不同，MGW无法识别拓扑请求中的termination,所以拒绝了该请求，导致无资源切换失败。8、RNC间切换成功率问题定位RNC割接完毕后，切换成功率不足5%，原因为RNCID配置错误2、 收集RNCIU口信令进行分析，发

14、现CN返回RELOCATIONFAIL，原因为unknowstargetrnc，联系CN侧进行数据核查，补订数据，观察话务统计，切换成功率提高到50%。3、由于小区级话务统计正常，因此问题初步判断还是RNC与CN间存在问题，再次收集IU口信令，发现已无RELOCATIONFAIL。分析counter计数方式，RNC发起RELOCATION后，计为一次RNC间请求尝试，收到FAIL或无响应计为失败。分析所有IU口信令发现，仍存在部分RNC发送reloctionrequest后，未收到cn任何响应4、由于CN侧无响应，还是怀疑与CN侧对接数据存在问题。根据上诉信令点分析，发往SGSN的数据全部失败

15、，联合产品、CN现场复测跟踪，发现RNCID定义有误，修改后，切换成功率达到95%以上。9、主控板隐性故障导致PS业务异常4， 由于该岛8个站点中7个站点均能正常处理PS业务，所以RNC参数应该没有问题，和产品人员配合对RNC、NODEB的开站脚本进行了参数核查，均无异常。5， 通过以上排查，怀疑问题出在基站安装或者某个控制板的隐性故障。对该站进行测试，能够正常进行CS业务，和切换业务，所以排除CS域故障，问题定位控制PS域的某个单板，将问题定位于主控板。工程人员更换SGSN主控板后，进行复测，各个PS业务均能正常运行，H业务达到1.3M以上稳定速率，问题解决。10、PS高掉线率处理案例某局点

16、PS掉线率一直居高不下，经过分析，掉线次数主要集中在其中一个RNC的4个小区。告警信息：无原因分析：PS掉线率=RNC请求释放的分组域RAB数目/PS域RAB指派建立成功RAB数目*100%从PS掉线率统计公式中，可以看出要降低PS掉线率必须要减少RNC请求释放的分组域RAB数目。处理过程：经过多天对掉线TOPN小区的观察与分析，发现掉线次数TOPN小区为A、B、C、D等4个小区，且RNC请求释放的分组域RAB数目统计中发现这些小区所覆盖的用户中有5个IMSI贡献的次数占整个RNC释放的RAB数目的一半以上，通过协调客户核查这5个IMSI所对应的SIM卡，发现这些卡都没有开通TD业务功能，导致

17、PS掉线率居高不下。协调客户对这些IMSI用户开通TD业务功能后，跟踪最近2天指标发现这些TOPN小区PS掉线问题已经基本解决。建议与总结：由于TD是一张新网络，终端、设备等一系列配套仍在不断完善中，我们在日常优化中遇到问题，要多方面考虑，设备、终端及用户行为等都可能对网络造成影响。11，QAAL2_PATH未配置导致无法占用H载波某局点进行HSDPA下载业务时，下载速率最高只能达到384Kbps。导致下载速率慢的原因可能为：1、天馈、载频等硬件故障导致无法占有H载波；2、USIM卡签约速率问题，不支持HSDPA业务；3、看看TRAMAP中H业务的传输映射是否正确；4、参数配置不当，导致无法占

18、用H载波。1、由于该手机和卡在其他站点可以正常测试，而且在RAB_ASSIGNMENT_REQ小区中也看到了分配的业务速率是2048000，所以排除卡开户速率问题；2、DSPCARRIER看H载波的状态是激活状态；3、LSTTRAMAP看到H业务是承载在HPATH上；4、跟踪信令，发现发往和来自NODEB的QAAL2_ESTABLISH_REQUEST出现了2次，第1次分配PATHID为1，不成功，第2次分配PATHID为2，业务就在该PATH上进行，但是一般的脚本中配置了4路PATH，H业务一般占用第3条PATH，该问题就是出在HSDPA的PATH有故障，业务通过NRT的PATH进行，因此只

19、有384kbps；5、根据以上分析，回头DSPAAL2PATH发现第3，第4路PATH故障，原因是NODEB侧未配置；6、重新配置数据，该问题解决，测试后H业务恢复正常。H业务在现场问题定位中一定要对数据进行仔细检查，由目前发现的问题中数据配置问题导致的H业务异常现象比较常见。12异厂家RNC间切换算法差异导致RNC间切换成功率低 A市TD网络由华为和ZX公司合力承建，从我司话统发现RNC间切换出成功率低，在85%左右，PS和CS均低。1、统计现网的告警，发现并无大面积的和切换强相关的告警，排除设备原因。2、从OMC统计华为向华为RNC间的切换成功率、华为向ZX的RNC间的切换成功率，发现华为

20、对华为RNC间的切换成功率在96%左右，华为对ZX的RNC间切换成功率在75%左右，说明我司的RNC间切换成功率指标低是由于我司和ZXRNC间切换成功率低造成。3、分别提取CS域和PS域的RNC间切换成功率，发现两个指标均低，为65%和86%左右。说明是PS和CS域的RNC间切换成功率低共同造成了整网的切换成功率低。4、统计我司RNC间切换失败原因counter，发现主要失败原因有两个：trellocalloc-expiry和failureinRNCorCNsystem，分别占失败原因的70%和25%。5、提取出我司RNC间切换失败的TOP小区，并通过CELL-NCELL提取出ZX侧的目标小区

21、，用大唐8130e测试终端现场验证，经测试一切正常，切换成功率为100%。用同样方法更换多个TOP小区进行测试，均不能复现切换失败的情况。6、协调ZX侧察看目标侧的话统，发现ZX的RNC间切出和切入指标均正常，我方切换出TOP小区对应的ZX侧目标小区的话统均良好。7、为排除话统不准确的可能，我们全天跟踪全网的IU口和TOP小区的IUB口信令，发现确实存在很多trellocalloc-expiry和failuresystem引起的RNC间切换失败，不能复现问题原因定位为测试方法问题。8、现网有多种测试终端，我们使用鼎新的DX188终端进行测试，复现了问题。测试发现，从我司开始业务后进入ZX区域，

22、PS业务表现为RNC向核心网上发RELOCATIONREQUIRED后，9秒钟后核心网下发RELOCATIONPREPARATIONFAILURE，原因值是trellocallocexpiry。CS业务表现为RNC向核心网上发RELOCATIONREQUIRED后，6秒钟后核心网下发RELOCATIONCANCEL，原因值为failuresystem。但是，从ZX侧起呼后进入华为区域，再回到ZX区域，切换正常。9、对比RNC间切换成功和切换失败的RELOCATIONREQUEST信令解码，发现不同之处很多，主要是切换失败的解码中rRC-Container的16进制串末尾多3个BIT，询问研发得

23、知，主要是华为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进制串末尾少带BIT以适配类似ZX的处理方式，问题得到解决

24、，CS和PS域RNC间切换均正常，切换出成功率提升至97%。在涉及跨厂家的切换时问题很多很杂，我们分析处理时要思路清晰，针对性要强。另外，要和研发保持良好沟通，促进问题快速解决。13 天线类型设置错误导致功率不匹配现象描述：某站点小区进行MAXTXPOWER功率设置时，提示功率不匹配。问题分析：导致功率不匹配的原因可能为：1、NodeB设置的功率过小，导致RNC功率设置比NodeB设置功率大时出现功率不匹配现象；2、RRU级联过多，导致功率设置受限；3、参数设置不当，导致功率不匹配。1、检查NodeB脚本，发现NodeB功率设置为MAXDLPCSPSC=460，没有问题；2、跟踪IUB口信令，

25、在MML中键入ADT RES: NODEBNAME=XXX;命令进行资源核查。在跟踪的信令中查看NBAP_AUDIT_RSP消息中报上来的功率值为410，如下图所示：3、由于该站点为室外站，使用的RRU为268，不存在级联现象；4、检查该站点NodeB脚本数据，发现天线类型设置为室内类型，而该站点实际为室外宏站；5、把天线类型设置为8双极型后功率设置正常，功率不匹配问题解决。14PS接通率提升1. （RAB.SuccEstabPSNoQueuing.Conv+RAB.SuccEstabPSNoQueuing.Strm+RAB.SuccEstabPSNoQueuing.Intact+RAB.Su

26、ccEstabPSNoQueuing.Bgrd）+（RAB.SuccEstabPSQueuing.Conv+RAB.SuccEstabPSQueuing.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%2. 由于PS接通率目前主要问题是RRC建立成功率低

27、，目前RRC.SuccConnEstab.Sum是统计全业务的RRC建立成功率，现网影响RRC建立成功率的主要原因由于PS域频繁重选业务的RRC建立失败（RRC.AttConnEstab.11RRC.SuccConnEstab.11）造成的。.11业务主要是统计PS域GSM小区重选到TD网络后由于需要注册造成的RRC建立失败。1、 通过分析发现PS接通率由于p业务特点造成频繁在gsm和TD网络进行注册，导致RRC建立失败的TOPN小区，占所有RRC建立失败原因50左右，下图为PS域RRC建立原因所有业务失败统计：3、解决建议：（1） 调整GSM小区参数Qsearch_I=-74dbm,TDD OFFSET=-2,目的是减小从GSM网络重选回TD网络的概率，降低由于用户上网地方3g弱覆盖造成的RRC频繁注册失败。（2） 3g小区配置的2g邻区如下表所示（相应的2g也配置了同样的3g小区）：15某局点PS域异系统出切换成功率低分析物理信道失败原因很多，主要有以下几个