被叫接入失败的原因分析与解决方案

经过对拨测数据前后台跟踪信令的分析，发现接入失败基本都是由于接入超时导致。因为测试软件的接入时长设置为10s，如果在接续过程中超过10s，那么测试软件会自动释放掉这次接入，并统计为一次接入失败。为什么会概率性地出现接入时长超过10s的情况呢？对后台测试信令进行分析，发现下面两种情况会导致问题的出现。

1.寻呼出现在UE空闲态转业务态过程中

现网中核心网的寻呼策略是三次寻呼，中间间隔时间分别是6s、5s、5s，这三次寻呼使用的都是TMISI，在LAC区域进行寻呼，如果三次寻呼之后还是没有响应，则寻呼失败；RNC侧收到核心网的寻呼后，根据手机所处的状态进行寻呼消息类型1或2的下发，如果UE处在空闲态，则下发寻呼消息1；如果UE处在业务态，则下发寻呼消息2；根据参数设置，RNC侧的寻呼类型消息重发1次，也就是下发2次，中间的时间间隔为640ms，如图8-3所示。

图8-3 寻呼策略

作为被叫，核心网过来的寻呼消息到达RNC侧后，如果RNC判断此时UE处于空闲态，则会下发寻呼消息类型1给UE，但就在下发此寻呼类型1消息同时，假如UE正好发起RRC建立，那么就发生了UE状态转换和寻呼消息间的碰撞，此时因为UE收到寻呼消息时已经不是处于空闲态，所以对于RNC下发给它的寻呼类型1消息是不做任何反应和处理的，而只能等待核心网第二次寻呼的到来，这就势必延长了主叫的业务建立时间。如果核心网第一次和第二次寻呼间隔为6s，那么一般通过二次寻呼成功建立业务的时间都在10s以上。如图8-4所示，RNC收到核心网寻呼时UE正好发起了数据业务，导致核心网第一次寻呼失败。

图8-4 空闲态转业务态过程中寻呼失败

从空口的消息来看，由于RNC收到CN的寻呼消息时，此时还没有收到UE的RRC连接建立请求，因此RNC采用寻呼消息类型1下发，而UE一旦发起了RRC连接建立请求就意味着其从空闲态进入了连接态，这样导致了UE无法正常接收寻呼消息类型1，如图8-5所示。

(www.xing528.com)

图8-5 空闲态转业务态过程中寻呼失败前台消息

这样，由于寻呼消息下发的时刻UE从空闲态转换到了连接态导致其寻呼失败。

2.寻呼出现在UE业务态转空闲态过程中

与上面的状态相反，如果寻呼下发的时刻正好是UE从业务态向空闲态转换的过程，那么此时也会发生寻呼消息与状态转换之间的碰撞，出现被叫对寻呼消息不进行处理和反应的现象。如图8-6和图8-7所示，RNC收到核心网寻呼时正好发起了RRC释放，导致核心网第一次寻呼失败。

图8-6 业务态转空闲态过程中寻呼失败

图8-7 业务态转空闲态过程中寻呼失败前台消息

RNC侧收到寻呼消息时UE还处于连接状态，之后RNC给UE侧下发寻呼消息类型2，但是此时UE收到网络侧RRC连接释放消息，立即从DCH态转换到了空闲态，从而导致了被叫寻呼消息丢弃，主叫业务建立失败。