事件分析
主叫起呼，被叫在做位置更新，会不会导致未接通事件呢？另外未接通的原因从哪条信令可以看出来？
会出现未接通的情况，我用TEMS测试遇到过这种情况。
信令不是很懂，被叫做位置更新会导致未接通事件
可以从被叫侧的寻呼响应来看
这种情况一般是会导致未接通的。
以TD系统为例进行说明。
主叫侧：
1、首先发起RRC信令连接建立，建立接入层的信令连接（RRC连接）。
2、发送CM service request，并进行鉴权和安全模式控制过程。
3、发送setup消息给CN，其中携带了被叫的电话号码
4、建立RAB也即业务承载的过程（这个是否在此流程中建立和CN的策略（早指配和晚指配）有关
5、等待被叫的alerting和connect。收到connect后回复connect ack就建立了呼叫。
而被叫侧的流程和主叫类似，只是触发的消息为收到寻呼。
被叫侧的信令流程：
1、收到来自网络侧的寻呼消息（paging）
2、建立RRC信令连接
3、回复paging response，进行鉴权和安全模式控制过程
4、接受setup消息，其中有主叫的电话号码（这个也和配置有关），如果被叫可以与此主叫建立请求的业务则响应call confirm
5、建立RAB
6、发送alerting和connect，等待connect ack
所以如果被叫进行位置区更新，则此过程中被叫无法接听paging，从而不会进行随后的过程。对于主叫侧大多看到的是建立RAB后一直等待alerting和connect的过程中收到了CN下发的disconnect
被叫做位置更新会导致未接通
connect出现之前，信令走到哪里都是未接通
会导致未接，寻呼不到被叫
被叫做位置更新会导致未接通事件
会导致未接，寻呼不到被叫，从Disconnect消息中的Cause Value中可以看到事件
被叫若正处于位置更新中，主叫起呼，是会导致未接通的，主叫不能寻呼到被叫导致未接通。未接通的原因值可以从主叫的disconnect消息中看出。也可以同时观察主被叫同一时间的状态。
有可能，要具体分析信令。
是会导致未接通，但TEMS和日迅测试差别较大，日迅出现的这种情况较多，而TEMS就少。
在一次呼叫信令中没有出现connect或connect ack ，即为未接通！
会导致未接通