PDP激活拒绝分析处理报告.docVIP

PDP激活拒绝分析案例 故障现象： 在哈密前期单站业务验证过程中，优化人员到现场进行测试时发现发现PDP激活拒绝，无法做PS业务。 前台信令截图： 由图：UE在直传Activate PDP Context request后，直接收到了RNC下发的ctivate PDP Context reject，导致无法做PS业务。 原因分析： 流程图： 分析判断可能原因： 1、基站的硬件故障导致PDP无法激活。 2、现场无线环境很差，直接导致RNC拒绝了UE的PDP激活请求。 3、RNC侧的IU-PS局向参数配置问题。 4、NodeB与RNC间的有关PS域的传输有问题。 原因排查： 1.硬件故障导致切换异常 　解放路站点在开通后，优化人员现场测试CS业务和VP业务都正常，但在做PS业务时候发现了PDP激活拒绝。现场联系机房查看基站侧是否有告警，查看结果该站点小区状态完全正常，传输也无链路告警。现场督导通过LMT-B登陆BBU查看本地小区，没有发现异常。 硬件故障这个可能被排除。 2.无线环境太差，验证的弱覆盖或者干扰导致PDP激活拒绝 现场测试截图如下： 从图上可以看出：现场的DPCH RSCP=-64，DPCH CI=14，无线环境很好，不存在弱覆盖或者干扰。开排除无线侧的原因。 3. RNC侧的IU-PS局向参数配置 目前RNC与CN之间配置了IU-CS和IU-PS局向，现场测试解放路站点的CS业务正常，如果IU-PS局向的IP地址配置错误，则就会产生PDP激活拒绝的现象。 如果IU-PS局向的参数配置有问题，就会产生全网性的PS业务问题，但今天测试其他的站点杨家巷和皮件厂的PS业务没有发现问题，因此可以排除是RNC与CN的对接参数配置问题。 4. 排除了硬件故障和参数配置问题，现在再从信令着手： 发现问题的信令点： 在PDP激活请求发出后，直接下发了PDP激活拒绝。对比正常的PS业务流程： 由图：在正常的PS业务流程中，当UE将PDP激活请求直传给CN后，CN会向RNC发起RAB指派请求，之后RNC向NodeB发起RL建立请求，与UE建立RB。当RNC和NodeB之间的RL建立成功后RNC和UE之间的RB建立成功后，RNC向CN回复RAB指派成功，这个流程走完之后，PDP激活成功，开始进行PS业务。 由于缺少跟踪IU口信令工具，未能现场抓取IU口信令，但从对比正常信令的UU口流程： 该次PDP激活由于没能建立RB而导致了失败。因此问题聚焦在解放路站点在申请PS业务的过程中，问题出在IU口的RAB指派过程。 正常的RAB指派流程图： 由于同一个RNC内别的站点的PS业务都是正常的，因此CN肯定已经向RNC发送了RAB Assignment。当前的RB未建立问题就可以定位在RNC和NodeB之间的RL建立过程。 但是现场缺少相关的NodeB侧的码流抓取工具，只能怀疑问题出现在这两个网元之间。 解决措施： 考虑到部分站点能正常做PS业务，对比这些PS业务正常的站点和问题站点解放路，发现1个共性问题：PS业务正常的站点都是用PTN开通的，而问题站点解放路是用2M开通的。问题可以定位在是RNC和NodeB之间的传输问题。 向机房询问解放路站点的开通方式：当现场安装完毕传输对通，确定GPS状态正常后，RNC侧会直接远程配好数据，通过固定脚本开通，相关传输数据也是通过脚本自动配置的： 机房侧对2M开通站点是用脚本根据IMA组生成传输数据，现在怀疑是脚本有问题，导致生成的传输数据在RNC侧和NodeB侧没有对通，让机房重新用另外1个脚本生成传输数据。机房侧重新生成传输数据以后，现场测试情况如下： 如图：机房侧调整后，PDP激活请求发出后，可以成功建立RB，然后PDP激活成功！ 经验总结： 在TD系统中，PS业务是一大特色业务，要解决PS类问题，只能通过关键信令点来定位问题是出现在哪些网元之间，然后深入分析问题。在工程中，由于2M站点是通过脚本远程开通的，一定注意核查开通后RNC侧和NodeB侧的传输链路号是否是完全对应的，两侧的传输号的不对应很容易出现一类业务正常，但另外一类业务异常的情况。