信令分析案例.docVIP

1、 MS呼叫未接通： 问题描述: 在做DT测试过程中发生了一次未接通，地点是LAC区交接处.在DT测试 的行程中，可能发生数次跨LAC区的切换，极易发生掉话或未接通情况。主要有以下三条 信令消息： UL：CHANNEL REQUEST DL：IMMEDIATE ASSIGNMENT UL：CM SERVICE REQUEST 问题分析: (1)在上行的CM SERVICE REQUEST信令发出后，没有下行的响应，通话状 态由起呼直接转为空闲模式（IDLE），由此可以断定发生了一次未接通。由于上行UL：CM SERVICE REQUEST是MS发起的对SDCCH的申请，发出申请后没有应答，没有出现标志 呼叫接通的信令消息，可以断定发生了一次未接通情况。其原因可能为该服务小区的SDCCH 信道拥塞，也可能是由于无线环境的恶化造成SDCCH信令丢失。因为此次DT测试发生在 跨数个LAC的路段，而且是上一个通话刚刚结束，起初判断可能是发生了一次位置更新。 (2) 位置更新信令消息如下： DL：CHANNEL RELEASE UL：CHANNEL REQUEST（开始位置更新） DL：IMMEDIATE ASSIGNMENT UL：LOCATION UPDATING REQUEST DL：AUTHENTICATION REQUEST UL：AUTHENTICATION RESPONSE DL：LOCATION UPDATING ACCEPT UL：TMSI REALLOCATION COMPLETE DL：CHANNEL RELEASE 结合此例的第三层信令消息来看，例子中MS发出了UL：CM SERVICE REQUEST， 并不是UL：LOCATION UPDATING REQUEST，由此可以判断出此例并非是位置更新。 2 、位置更新导致数据吞吐量为0 问题描述: 在某路段,进行数据业务测试时,发现MS数据吞吐量变为0,没有了与GPRS网络的连接. 问题分析: (1) 在该路段进行语音业务测试, 确认已经完全覆盖. (2) 分析当时数据业务测试的层3信令. 当时的信令为: DL：SYSTEM INFORMATION TYPE 1 UL：LOCATION UPDATING REQUEST UL：CHANNEL REQUEST 初步定位数据吞吐量变为0的原因是 MS执行了一次跨路由区的小区重选  (3) 对比在当时显示图的信令部分可以明显的看出该MS正在做位置更新. 3 、FTP下载中断 问题描述: 在DT FTP下载测试中，MS已成功登陆FTP Server，并已经开始下载数据，FTP下载进度 为9％，在经过一次小区重选后, FTP下载不能继续进行，在一系列的Ping fail后，FTP掉线. 问题分析: (1) 查看层三信令,具体显示如下： Direction Type Layer 3 Message UL GPRS SM Deactivate PDP Context Request DL RR System Information Type 13 UL RR Channel Request DL RR Immediate Assignment DL GPRS SM Deactivate PDP Context Accept 发现在事件列表中有PDP Deactivated的消息，在层三消息中可以看到是手机发起的上行消息. (2)发生这种情况可能有3种原因： 一是手机在测试过程中电缆的某个接口发生了松动，这样手机可能会发出PDP去激活申请。 二是手机本身存在一些问题也可能导致这个问题。 三是测试用的笔记本电脑可能存在一些问题 4、 没有物理消息导致切换失败 问题描述: 某地主要由4173、4081小区覆盖，上述两个小区及相邻小区同属于LAC：13588。DT测 试过程中，MS当前服务小区为4173，当检测到有Level 更强的邻区时，BSC指示MS切换（发起DL： HANDOVER COMMAND），此时发生了连续的三次切换失败（UL：HANDOVER FAILURE）。虽然本例 中经历了连续三次切换失败，MS仍然没有掉话（MS还在发送测量报告），但是对连续的切换失败应 该给予很大的重视。 问题分析: (1) 查看当时的层三信令, 具体如下: DL：HANDOVER COMMAND UL：HANDOVER ACCESS UL：HANDOVER COMPLETE UL：MEASUREMENT REPORT UL：HANDOVER FAILURE DL：SYSTEM INFORMATION TYPE 5 (2) 从切换的两