每一步都可能异常，我们在设计用例测试RNC特性的时候都需要考虑每一步异常的，甚至内部流程也考虑异常。比如回错误、失败、不回，异常后回退还是中断？比如：
一般来说，对方相应建立失败比较容易定位，而不响应则较难。
比如UE发出RRC请求，RNC没有收到？可能原因包括UE内部L3/L2/L1那一块没发对？或者网络端RACH配的有问题？或者网络侧的L2/L3问题？
UE收不到RRC建立：这个时候通常在RNC侧看log是UE不回RRC完成，而实际是UE没有收到或者接收RRC_SETUP消息不全，这时在UE侧较好定位。考虑原因包括fach信道问题、网络侧L3/L2/L1有没有正确下发？UE侧物理层、L2有没有丢包？
收不到RB_setup/RB_reconfig消息比较常见，大部分情况是收不全，从UE端L2 log比较容易看出来，一般是有丢包。因为这条消息较大，如果RRC建立在FACH或者3.4k DCH或者证分复用时比较容易发生。我的定位方法一般是：
先重试找到失败的规律；然后在这个失败的规律上大胆的预测最可能的原因，然后去实证；如果失败，则逐一排查每个网元、甚至每层的模块进行log分析。
