核心网案例汇总Word文件下载.docx
《核心网案例汇总Word文件下载.docx》由会员分享，可在线阅读，更多相关《核心网案例汇总Word文件下载.docx（23页珍藏版）》请在冰豆网上搜索。
required消息，但是CN没有向目标BSC发送Handover
request消息，导致计时器溢出，RNC判决向次优小区（江滨路国土局-1），切换失败。
该区域GSM、TD-SCDMACN侧设备均属于NSN（诺西）。
5
8、RNC间切换成功率问题定位5
RNC割接完毕后，切换成功率不足5%，原因为RNCID配置错误5
9、主控板隐性故障导致PS业务异常6
三个小区的PS业务均异常，做64K上传、384K和H业务下载时，速率都很低，且既不稳定。
6
10PS高掉线率处理案例6
11，QAAL2_PATH未配置导致无法占用H载波6
12异厂家RNC间切换算法差异导致RNC间切换成功率低7
13天线类型设置错误导致功率不匹配8
14PS接通率提升9
15某局点PS域异系统出切换成功率低分析10
16核心网鉴权拒绝导致主叫起呼失败11
17普通PS业务RAB建立后直接释放11
1、23G切换迁移失败问题分析与解决
了MSC侧参数，发现PHASE2错误处理功能开关未激活，导致23G切换失败
通过以上排查，可以断定此现象与TD侧网优参数无关，且23G侧也对TD的数据进行了正常的定义，所以能够存在正常的切换，只是由于某个协议错误，导致了切换存在失败的概率，且迁移失败原因为协议错误。
与核心网人员一起进行了问题的定位，核查了MSC侧参数，发现PHASE2错误处理功能开关未激活，将该开关打开后，问题解决.该参数在中兴的TD网络中也出现过类似的问题，同样在华为设备中，RNC发出迁移请求时，所包含的classmarkInformation2不能被爱立信的MSC所完全翻译，核心网发往爱立信的BSC后就会被拒绝，当PHASE2错误处理开关被激活后，由于数据不能被完全解读而造成了大量迁移失败问题得以解决。
2、接入CE数据错误导致PS业务概率性出现速率为0的问题
题RNC中任意小区均能概率性出现PS业务无速率，原因为接入CE数据错误
1、从前台观察，在ftp
download
connect如果有sender
retr信令返回DPCH会恢复，业务速率正常。
2，若没有sender
retr信令返回，则DPCH持续很低（DPCH
RSCP在-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，
和产品人员对传输进行定位，据查，RNC2和RNC6有部分IPPATH的IP检测开关是关闭的，将其打开后，发现RNC2出现两条目的地址不可达告警，RNC6出现3条目的地址不可达告警。
将RNC2和RNC6的GOU单板复位后，告警仍然存在，复位RNC6后，问题依旧存在。
7，
将RNC2和RNC6上出现告警的IPPATH删除后测试，发现问题依旧出现，排除是IPPATH的原因。
8，
与汇聚CE工程师进行问题排查，在NE80E侧Ping
CE05的Loopback地址Ping不通，pingCE05的直链地址可以Ping通，查看到CE05的接口是G1/0/6
G1/0/7两个接口做的端口聚合，G1/0/6接口是UP的，G1/0/7接口是Down的，查看G1/0/7接口是强制全工，光功率发送正常，接收光功率在-34DB。
基本可以判断是CE05发光到CE01异常。
9，
据分析：
如果CE01有网管，并且网管发送告警的话，客户应该会查到这个问题。
原因是：
GE光口异厂家对接，移动采用的是强制全双工的方式。
在单链路时可以靠Ospf来检测接口是否异常。
但是威海同时采用的链路聚合，当SE800发送故障时，NE80E可以检测到，但是NE80E发送仍然正常，SE800无法检测到自身发送存在问题。
SE800
接口仍然UP，在数据转发时，数据Hash到两个接口向外发送，导致经过CE05-SE800的数据部分被丢弃。
10，当其中一个接入CE的传输数据故障时，走该通路的业务就会不可用，所以会概率性出现PS业务速率为0的问题，将该接入CE的传输数据重新做后，业务恢复正常。
3、通过OMC定位解决跨RNC切换失败问题
出现大量跨RNC切换失败，通过omc定位问题，由于无线环境不好
1、LST
NRNC，查看邻RNC是否定义，参数是否正确；
然后通过LST
NRNCNCELL
核查PS域的跨RNC相关数据是否配置，通过LST
IPPATH，查看是否将邻RNC的IP数据定义，此项影响PS域的切换；
和核心网沟通，核查MSC数据是否定义了邻RNC,此项影响CS域的切换。
VS.HHO.ReqRelocPrep.RF：
因无线链路信号质量导致硬切换伴随迁移出小区准备次数。
HHO.FailOutInterCellInterFreq.2：
RNC内小区间异频硬切换出失败次数<
物理信道失败>
由以上原因值和地理环境我们可以大概猜测出此次用户行为为：
当用户在家里进行PS业务上网时，由于震琳1小区信号在室内衰减严重，导致无线链路信号质量不好，向银镝服饰2小区做出硬切换迁移准备，且由于此时银镝服饰2小区信号强度不够，导致银镝服饰2小区和UE的物理信道建立失败。
4、RRU版本不同，导致切换失败
问题出现的原因是由于RRU版本不同
4.通过更换不同终端在问题站点进行测试，发现只有DT8120占用问题小区后可以正常出切换，其他终端DX128、ET128和DX188均无法正常出切换。
5.根据研发人员建议，将CONN
MODE
TIMER中的T312值由1S修改为3S，现场测试，发现切换成功率有所提高，但是切换失败现象仍然存在；
并且在测试中发现RRU同为SPC520版本的站点之间，出切换都没有问题。
6.9月27日按照产品人员的建议，修改其他小区到本小区切换均为硬切换；
修改后无效果；
7.
考虑到由于问题小区为无法正常出切换，所以尝试修改问题小区到其他小区的切换均为硬切换，现场测试后，发现切换正常，问题规避。
5、PS掉线次数RNC级和小区级统计不一致
分析现网PS掉线率问题时，通过RNC级话统得到，两个RNC的掉线次数总和为760次，通过小区级数据查找掉线主要由何种PS业务引起时，发现H掉线次数达2000多次，加之PS384K、PS128K、PS64K，各业务掉线总和为2192次，和RNC级统计的不一致，具体指标详见附件。
最后通过请教研发，给出的解释是，不一致是因为RNC4.0.1版本做过优化导致，即对于影响掉话率KPI的counter：
RNC级IU.NbrRABPSRelIuConnperCause.16这个指标去除了该项统计，而CELL级保留。
6、TD终端无法起呼案例
RANAP_SECRRITY_MODE_REQUEST，无法起呼
将该问题升级之后，办事处人员反馈情况为SIM卡的数据配置有误，正常的鉴权会连续导致位置更新失败，鉴于对SIM数据修改的操作难度较大，故对核心网的鉴权模式进行修改，降低了鉴权的要求，准许用户正常接入。
由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:
42'
712
MGW上发消息Transaction
Reply,原因值为Insufficient
resources。
首先MGW侧因其内部原因未成功分配切换相关资源，原因值为Insufficient
resources；
其次,因上述原因导致A接口交换机释放资源，原因值为Protocol
error
between
BSC
and
MSC；
最后因上述原因导致IuCS接口交换机释放资源，原因值为：
message_not_compatible_with_receiver_state。
可知MGW内部相关软硬件问题导致异系统切换失败。
进一步和诺西MGW侧研发工程师进行问题联合分析。
MGW侧研发跟踪MGW信令。
从MGW的消息追踪来看，可以发现负责承载资源控制功能的模块BC2给H.248模块hta发出“出错报告”（CA28消息），随后该出错信息通过H.248消息送往MSS。
诺西研发反馈该问题发生在主被叫UE几乎同时（前后间隔200ms以内）向同一MSS发起切换时造成。
第二个切换空口完成之后MSS请求MGW改变拓扑结构，此时任何一个老的Iu口都还没有释放。
但在MGW响应该拓扑请求之前，第一个切换方的Iu接口资源释放，MGW拓扑结构中的termination与之前在请求中的情况已经不同，MGW无法识别拓扑请求中的termination,
所以拒绝了该请求，导致无资源切换失败。
8、RNC间切换成功率问题定位
RNC割接完毕后，切换成功率不足5%，原因为RNCID配置错误
2、收集RNC
IU口信令进行分析，发现CN返回RELOCATION
FAIL，原因为unknows
target
rnc，联系CN侧进行数据核查，补订数据，观察话务统计，切换成功率提高到50%。
3、由于小区级话务统计正常，因此问题初步判断还是RNC与CN间存在问题，再次收集IU口信令，发现已无RELOCATION
FAIL。
分析counter计数方式，RNC发起RELOCATION后，计为一次RNC间请求尝试，收到FAIL或无响应计为失败。
分析所有IU口信令发现，仍存在部分RNC
发送reloction
request后，未收到cn任何响应
4、由于CN侧无响应，还是怀疑与CN侧对接数据存在问题。
根据上诉信令点分析，发往SGSN的数据全部失败，联合产品、CN现场复测跟踪，发现RNCID定义有误，修改后，切换成功率达到95%以上。
9、主控板隐性故障导致PS业务异常
4，由于该岛8个站点中7个站点均能正常处理PS业务，所以RNC参数应该没有问题，和产品人员配合对RNC、NODEB的开站脚本进行了参数核查，均无异常。
5，通过以上排查，怀疑问题出在基站安装或者某个控制板的隐性故障。
对该站进行测试，能够正常进行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小区的观察与分析，发现掉线次数TOPN小区为A、B、C、D等4个小区，且RNC请求释放的分组域RAB数目统计中发现这些小区所覆盖的用户中有5个IMSI贡献的次数占整个RNC释放的RAB数目的一半以上，通过协调客户核查这5个IMSI所对应的SIM卡，发现这些卡都没有开通TD业务功能，导致PS掉线率居高不下。
协调客户对这些IMSI用户开通TD业务功能后，跟踪最近2天指标发现这些TOPN小区PS掉线问题已经基本解决。
建议与总结：
由于TD是一张新网络，终端、设备等一系列配套仍在不断完善中，我们在日常优化中遇到问题，要多方面考虑，设备、终端及用户行为等都可能对网络造成影响。
11，QAAL2_PATH未配置导致无法占用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、跟踪信令，发现发往和来自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业务在现场问题定位中一定要对数据进行仔细检查，由目前发现的问题中数据配置问题导致的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间切换成功率，发现两个指标均低，为65%和86%左右。
说明是PS和CS域的RNC间切换成功率低共同造成了整网的切换成功率低。
4、统计我司RNC间切换失败原因counter，发现主要失败原因有两个：
trellocalloc-expiry和failure
in
RNC
or
CN
system，分别占失败原因的70%和25%。
5、提取出我司RNC间切换失败的TOP小区，并通过CELL-NCELL提取出ZX侧的目标小区，用大唐8130e测试终端现场验证，经测试一切正常，切换成功率为100%。
用同样方法更换多个TOP小区进行测试，均不能复现切换失败的情况。
6、协调ZX侧察看目标侧的话统，发现ZX的RNC间切出和切入指标均正常，我方切换出TOP小区对应的ZX侧目标小区的话统均良好。
7、为排除话统不准确的可能，我们全天跟踪全网的IU口和TOP小区的IUB口信令，发现确实存在很多trellocalloc-expiry和failure
system引起的RNC间切换失败，不能复现问题原因定位为测试方法问题。
8、现网有多种测试终端，我们使用鼎新的DX188终端进行测试，复现了问题。
测试发现，从我司开始业务后进入ZX区域，PS业务表现为RNC向核心网上发RELOCATION
REQUIRED后，9秒钟后核心网下发RELOCATION
PREPARATION
FAILURE，原因值是trellocalloc
expiry。
CS业务表现为RNC向核心网上发RELOCATION
REQUIRED后，6秒钟后核心网下发RELOCATION
CANCEL，原因值为failure
system。
但是，从ZX侧起呼后进入华为区域，再回到ZX区域，切换正常。
9、对比RNC间切换成功和切换失败的RELOCATION
REQUEST信令解码，发现不同之处很多，主要是切换失败的解码中rRC-Container的16进制串末尾多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进制串末尾少带BIT以适配类似ZX的处理方式，问题得到解决，CS和PS域RNC间切换均正常，切换出成功率提升至97%。
在涉及跨厂家的切换时问题很多很杂，我们分析处理时要思路清晰，针对性要强。
另外，要和研发保持良好沟通，促进问题快速解决。
13天线类型设置错误导致功率不匹配
现象描述：
某站点小区进行MAXTXPOWER功率设置时，提示功率不匹配。
问题分析：
导致功率不匹配的原因可能为：
1、NodeB设置的功率过小，导致RNC功率设置比NodeB设置功率大时出现功率不匹配现象；
2、RRU级联过多，导致功率设置受限；
3、参数设置不当，导致功率不匹配。
1、检查NodeB脚本，发现NodeB功率设置为MAXDLPCSPSC=460，没有问题；
2、跟踪IUB口信令，在MML中键入ADTRES:
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.SuccEstabPSNoQueuing.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建立成功率低，目前RRC.SuccConnEstab.Sum是统计全业务的RRC建立成功率，现网影响RRC建立成功率的主要原因由于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、解决建议：
（1）调整GSM小区参数Qsearch_I=-74dbm,TDDOFFSET=-2,目的是减小从GSM网络重选回TD网络的概率，降低由于用户上网地方3g弱覆盖造成的RRC频繁注册失败。
（2）3g小区配置的2g邻区如下表所示（相应的2g也配置了同样的3g小区）：
15某局点PS域异系统出切换成功率低分析
物理信道失败原因很多，主要有以下几个
升级会员 