核心网案例汇总Word文件下载.docx
《核心网案例汇总Word文件下载.docx》由会员分享,可在线阅读,更多相关《核心网案例汇总Word文件下载.docx(23页珍藏版)》请在冰豆网上搜索。
![核心网案例汇总Word文件下载.docx](https://file1.bdocx.com/fileroot1/2023-1/3/4c5436ff-f19a-4e7a-9587-0c948cc58c12/4c5436ff-f19a-4e7a-9587-0c948cc58c121.gif)
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域异系统出切换成功率低分析
物理信道失败原因很多,主要有以下几个