WCDMA信令流程解析介绍.ppt

* * * * * * * * * * * * * * * * * * * 这里的MAC为MAC-d，如果是HSDPA业务，在NodeB要增加MAC-hs，如果是HSUPA，在NodeB要增加MAC-e。 * 这里的MAC为MAC-c * * * * UTRAN启动的寻呼，可能是UTRAN发起的，也可能是CN发起的。 问题：当一个UE在CELL_PCH状态，有一个呼叫寻呼它，它会响应哪一种原因的寻呼消息？ * * * * * * 同步有RL RECONFIG COMMIT，异步没有。 * * * UE发起的通常切换是指分组数据业务，它都是以重选的方式工作的，因此，是由UE发起的。（状态有：CELL_DCH、CELL_FACH、CELL_PCH、URA_PCH） * * * * 供参考，欢迎讨论。 * URA是UTRAN行为。 * * * CDT：呼叫过程跟踪工具 * * * * 软切换 无线链路增加（1A事件） * 硬切换 为了UE能进行异频测量，在WCDMA中引入了压缩模式技术。 目前绝大多数情况下用物理信道重配置过程完成硬切换（图中没有包含启动压缩模式的流程）。 * WCDMA→GSM系统间切换 图中没有包含启动压缩模式的流程 * 前向切换 前向切换分为小区更新和URA更新，主要用于当UE位置发生改变时及时更新UTRAN侧关于UE的位置信息。（属于UTRAN行为） 小区更新的原因： 注*：响应寻呼指在CELL_PCH/URA_PCH状态下收到寻呼，在CELL_FACH状态下响应寻呼。 注**：在CELL_PCH/URA_PCH状态下，UE的AM RLC实体发生了不可恢复的RLC错误，需转到CELL_FACH状态。 * 前向切换 小区更新基本流程： 发起URA更新过程的可能原因有： ●URA重选； ●周期性URA更新。 URA更新基本流程： * 二、获取信令流程 * DT的LOG文件 可以用华为的路测软件PROBE或后台分析软件ASSISTANT，一般都是用ASSISTANT进行信令分析。实际上就是UE采集到的信令流程。 查看UE中L3中RRC信令等，双击“L3 message” 。 * 登录RNC采集信令 ●采信令： 通过LMT（华为本地维护终端）登录RNC。 点击“维护”卡片。 双击：跟踪管理\接口跟踪\CDT。输入测试手机的IMSI号码。 文档保存在：根目录:\HW LMT\client\output\RNC \BSC6810V200R010C01B061\trace\下面（.tmf文件）。 ●读信令： 双击.tmf文件。 * 登录RNC采集信令 * 正常信令流程模板 根据ASSISTANT和登录RNC采集到的实际信令流程，整理出各种正常信令流程的模板，以便信令分析时对照。 此外，列出了从哪些信令消息中可以找到的部分相关信息，例如：MCC、MNC、LAC、RAC、CPICH Ec/Io、主扰码、CI、IMSI、TMSI等。 * 三、DT信令流程分析案例 * 嵊州天池制药被叫掉话 问题分析： 经查该被叫手机掉话时间为14:35:11.216，但掉话处的信号较好，RSCP=-79，EcIo=-10.7，应该不会掉话。查看ASSISTANT层3信令。 * 嵊州天池制药被叫掉话 * 嵊州天池制药被叫掉话 发现奇怪现象，对应的掉话时间处，是一个正常的RRC释放过程，不像是掉话。再往上看，发现有Attach过程，说明是一个开机过程，因此不存在掉话的问题（不是通话过程）。再往上看，发现时间上有约2分钟的空缺（14:33:48~14:35:10），也就是说前一段的通话与后一段的开机过程中间丢失了一部分内容。这样，ASSISTANT软件由于没有看到正常的挂机（disconnect），但发现了空闲状态，所以判为掉话。怀疑是两个LOG之间的断点，经查发现此空缺在LOG的中间位置，而不是在LOG的头尾，即不是LOG之间的断点，因此初步判断为手机故障引起掉话。 * 嵊州天池制药被叫掉话 查看事件： * 嵊州天池制药被叫掉话 从event list中，在掉话时间的位置没有看到掉话事件，却在数据断点处14:33:49.499有UE Disconnected的字样（说明手机已经与电脑断开），正常的被叫手机挂机情况应该是IncomingCallDisconnected。与路测工程师沟通，此处确实出现手机没电了的现象。可以认为手机在得电后进行了开机过程，由于手机与电脑的连接建立需要一定的时间，故开机过程信令不能完整记录下来。另外主叫手机工作正常，故操作者没有停止LOG而重开LOG，由于手机断电故障出现在LOG的中间位置，所以容易造成系统掉话的假象。 * 嵊州天池制药被叫掉话 查看RNC的CDT信令跟踪消息： 由于手机