核心网案例汇总.docx

核心网案例汇总.docx

《核心网案例汇总.docx》由会员分享，可在线阅读，更多相关《核心网案例汇总.docx（18页珍藏版）》请在冰豆网上搜索。

核心网案例汇总

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 发送reloction request后，未收到cn任何响应

4、由于CN侧无响应，还是怀疑与CN侧对接数据存在问题。

根据上诉信令点分析，发往SGSN的数据全部失败，联合产品、CN现场复测跟踪，发现RNCID定义有误，修改后，切换成功率达到95%以上。

9、主控板隐性故障导致PS业务异常

备注：

三个小区的PS业务均异常，做64K上传、384K和H业务下载时，速率都很低，且既不稳定。

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 target RNC or CN or target 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 in target RNC or CN or target system引起的RNC间切换失败，不能复现问题原因定位为测试方法问题。

8、现网有多种测试终端，我们使用鼎新的DX188终端进行测试，复现了问题。

测试发现，从我司开始业务后进入ZX区域，PS业务表现为RNC向核心网上发RELOCATION REQUIRED后，9秒钟后核心网下发RELOCATION PREPARATION FAILURE，原因值是trellocalloc expiry。

CS业务表现为RNC向核心网上发RELOCATION REQUIRED后，6秒钟后核心网下发RELOCATION CANCEL，原因值为failure in target RNC or CN or target 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域异系统出切换成功率低分析

物理信道失败原因很多，主要有以下几个：

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域异系统出切换失败KPI进行分析，从全天统计来看，失败主要原因为IRATHO.FailOutPsUtran.2（RNC收到UE发送“从UTRAN小区改变失败”（CELLCHANGEORDERFROMUTRANFAILURE）消息次数，指示分组域系统间切换出失败，对应原因：

物理信道失败）。

2、对邻区配置参数进行核查，未发现问题。

3、检查2G、3G基站运行状态，未发现问题。

4、修改PS域2G、3G切换门限参数HSPATIMETOTRIG3AUSEDFREQHTHDRSCP、，使UE尽量占用TD网络，避免频繁的23G切换。

问题解决。

指标有了明显提升。

16核心网鉴权拒绝导致主叫起呼失败

国内某TD局点，局方经理投诉在进行正常拨打过程中，主叫起呼后未听到任何放音提示回到空闲态，起呼失败。

 告警信息：

无

 原因分析：

由于诺西核心网在被叫进行接入过程中鉴权拒绝，导致被叫直接被拆链；同时主叫收到核心网下发的释放消息，未进入alerting过程，主叫直接回到空闲状态。

 处理过程：

经过拨打后问题在14:

00呼叫时重现，现将问题分析如下：

1.从主叫看，UE从RRC连接请求后信令流程正常，在RAB建立完成后（14：

00：

06（44）），UE收到核心网下发的disconnect直传消息命令，如下图示。

释放的原因值为destination-out-of-order，目标不可达，即被叫端问题。

2.从被叫的信令来看，被叫的鉴权请求被拒，故被叫在Altering前就发起来RRC连接释放，主叫UE随后没有收到被叫Altering信令也进入释放流程，起呼失败，所以从用户感知看主叫UE进行拨号起呼后的4s内，没有听到任何声音提示（即无铃音或核心网放音提示），直接回到空闲状态。

3.查看被叫UE信令，被叫在14:

00:

03收到核心网的寻呼消息，之后发起RRC连接，进入鉴权加密的过程中，在14：

00：

06（33）进行了鉴权回复，如下图示；但是在14：

00：

06（50）核心网下发直传消息鉴权拒绝，之后被叫UE进入释放过程，直接释放RRC连接。

同时主叫在14：

00：

06（52）收到核心网的disconnect消息，释放原因为被叫不可达。

4.针对该问题咨询诺西核心网工程师，诺西交换机上跟踪信令发现拒绝原因为鉴权不通过，即非法用户，原因是SRES（符号响应，鉴权3元组其中一个元素）不匹配；导致核心网认为UE非法；进一步跟踪分析发现，SRES不匹配的的原因是SRES手机计算的结果和VLR中不一致，导致鉴权不通过；诺西工程师认为是SIM卡工艺问题导致的小概率事件，通过打开2次鉴权可避免该类接入失败。

 建议与总结：

对于该类问题先抓住出现问题的网元，再进行深入分析可提高效率。

在排除无线原因后，需要考虑因核心网/传输影响导致问题出现。

17普通PS业务RAB建立后直接释放

新开通的部分站点在做PS384单站验证的时候，RAB连续建立两次，手机收到CN下发的PDP激活接受后，IU口发起释放。

第二次再次申请相同的业务，RAB只建立一次，上行直接为32k，且没有PDP激活接受的直传消息。

做H业务没有任何问题。

 告警信息：

无

 原因分析：

1、怀疑终端原因，使用别的终端测试。

仍然出现这种现象。

2、因为第一次都是信令面建立完全后才释放，所以查询是否基站的业务面配置有问题，经产品同时配合查询后和其它基站也没有任何区别。

 处理过程：

1、 因为存在RAB请求的上行降速，所以怀疑DCCC参数问题。

核对DCCC参数基线，没有问题。

同时关闭DCCC算法测试还是出现上述情况。

2、 某次现场使用数据卡测试，出现相同的想象。

因为数据卡没有手工选择R4或者R5的开关，所以前期统一把下行BE业务H判决门限：

DLBETRAFFTHSONHSDPA统一从64改为512。

这个参数的含义是：

当终端下行请求速率大于等于512则网络侧分配H资源给终端。

如果此参数是64那么我们的数据卡只要申请大于等于64都会上H载波，项目上的数据卡就无法做R4的PS测试。

后来因为单站验证的结束和用户的增长，怕PS出现拥塞，统一把DLBETRAFFTHSONHSDPA修改回64，复测后发现业务正常，但是占用的是H载波。

也就是说不管是手机主动选择R4还是，调整网络侧的参数DLBETRAFFTHSONHSDPA，让网络侧决定占用R4都会有上述的失败现象。

占用H就不会出现。

3、 再次查询基站配置，发现数据和别的站点配置相同。

但是只有一个主载波可用，查询发现此载波是H载波。

经过和产品侧确认，因为他们为了进度开通的很多站都只配了一块BBI板，其它的BBI板未到货，所以只开通了一个主载波。

我们网络侧现在的配置现在H2D,D2H的开关都是关闭的，所以终端申请的上行64，下行384网络侧或者手机直接判决为R4载波，但是网络侧无法把此业务迁移到H信道。

至于发起两次RAB建立。

至于第二次上行降速为32，可能是现网配置的DCCC的中间速率是32导致。

4、 使用一部8130手机，在手机上强制选R4。

然后模拟只有一个H主载的场景（毙掉其它载波），出现和之前一样的失败想象。

 建议与总结：

1、 产品开站要按照标准配置开通，不能只为了赶进度。

如果那些未按照标准开通应该知会网优人员，以免出现很多难定位的问题。

2、 出现批量站点无法做业务，看是信令面见不起来还是业务面有问题。

如果是业务面的问题，着重注意基站的物理配置。

 附件：

R4的ps业务建链后释放.doc

18小区服务区码与核心网配置不一致造成终端无法接入

移动大楼站点测试前后台信令

前台测试信令截图：

图

（1）前台测试信令

后台信令截图：

19TD-HSDPA定点下载速率不稳定的解决过程

S省C市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之间）；

 告警信息：

无

 原因分析：

无线环境恶劣（干扰）导致重传率高；

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、PCCPCH C/I、DPCH RSCP、DPCH C/I都较好，波动随于正常的无线信号波动（不像之前波动呈“矩形”），问题依然没有解决，H速率不稳定的现象依然存在；排除无线环境恶例引起的干扰；

3、之前在其它区域作单站时使用的测试软件和终端及测试卡均与目前一致，所以首选排除测试软件、终端和HLR开户速率问题；

4、将问题反馈给后台系统分析工程师，跟踪该站2小区码资源占用情况，得知该小区只有一个H用户占用（就是我们自己测试卡），同时也查询该站没有硬件告警出现；排除多用户共享导致和硬件告警；

5、该问题现象在多区域大面积的出现；并且这几个区域均属于同一个RNC，初步怀疑新建RNC问题，联系RNC督导核查RNC侧配置脚本未发现异常，并RNC督导将重新执行一次RNC配置脚本和RNC备件进行主备份倒换；排除RNC侧和NODEB硬件问题导致；

6、现场测试改用从internet寻找的可用资源进行下载测试（使用讯雷外加多下载任务方式），下载速率均不稳定，排除FTP服务器限速问题的影响；

7、通过对测试软件H业务测试任务进行核查，发现连接线程数设置为3；如下图所示，将连接线程数改为10后测试10次H速率都较稳定，且峰值达1.8Mbps，期间未发现DPCH RSCP和DPCH C/I呈矩形波动情况出现（DPCH的波动随于正常的无线信号波动，但整体情况较之前测试要好）；

注：

线程可以理解为下载的通道,一个线程就是一个文件的下载通道,多线程也就是同时开起好几个下载通道.当服务器提供下载服务时,使用下载者是共享带宽的,在优先级相同的情况下,总服务器会对总下载线程进行平均分配.不难理解,如果线程多的话,那下载的越快.

 建议与总结：

定位问题时先通过问题现象判断可能出现问题的大概原因，然后再逐一通过现场测试方法的调整、后台数据的检查，这样逐一排查后，缩小问题的范围。

 附件：

TD—HSDPA定点下载速率不稳定的解决过程.doc

20同小区内立即激活缺省偏移值设置不当造成并发业务失败

在秦淮西路-3小区经行并发业务测试时，如果先进行H业务之后尝试语音业务会导致RAB建立失败，同时H业务掉话。

此次CS业务没有建立成功，5秒后RNC申请IURELEASE，PS业务掉话。

原因值为：

无线进程接口失败。

如下图所示：

1.根据其后台跟踪RB建立的具体信令可以看出RB建立失败原因为ulWatiRbFailTimeristooshort。

5秒后RB建立超时，IU释放。

如下图所示：

2．与其他小区进行参数对比，发现该小区同小区内立即激活缺省偏移值设置为40，远小于基线参数设置的150，如下图所示：

该参数指示UE新配置生效的时间点，便于UE、NodeB和RNC在该时间点同时使用新的配置信息，保证数据的可靠传输。

RNC建立新配置时根据当时的帧号推算新配置的生效时间点，既要考虑携带该参数的信令在Iub和Uu口的传输时延，又要考虑新配置建立时间不能过长。

如果新配置的建立时间和生效时间间隔过短，可能会出现在UE未收到配置信息之前网络侧新配置已经生效，而UE依然使用旧配置，导致数据传输出现错误。

3.将该小区同小区内立即激活缺省偏移值更改为150。

21、CS业务无法进行2-3G切换问题排查

1、现场反应在RNC1覆盖的个别区域不能进行CS域2－3G切换，经过区域分析，发现全部都处于G网BSC“CC1”的覆盖范围，同RNC的“CC3”区域切换正常。

2、由于该市的2－3G互操作是一个区域一个区域进行的，不排除两区域数据添加的差异，TD和GSM侧都进行了2－3G相关参数的仔细检查，发现没有异常。

同时，两个BSC对应的LAC都为9868，因此核心网侧肯定已经添加完。

3、跟踪信令进行分析。

后台信令显示终端已经向无线侧上报3A测量报告，并向核心网发起重定位请求，但核心网返回重定位失败，失败原因如图1所示：

4、怀疑该BSC未升级或升级未完善，但客户答复已肯定全部升级完成。

让客户定位G网无线侧参数，客户再次表明参数配置没有任何问题。

为进一步说明TD侧交互一切正常，继续跟踪TD核心网信令。

（其中TD的核心网是华为的，但GSM的核心网是爱立信的无法跟踪。

）跟踪TD核心网MSC（SZS13）,发现TD侧确实已经成功发送消息至G网核心网MSC（CYCMSC）,也收到返回的切换失败消息，如图2所示：

从上