ATU中的CSFB未接通

高鐵用5S測(cè)試CSFB：

在擴(kuò)展服務(wù)請(qǐng)求之后，的下一條信令是RRC Connection Request而不是RRC Connection Release;后在2G側(cè)重新接入到公網(wǎng)小區(qū)導(dǎo)致的未接通，

下面是RRC Connection Request

重新接入

更新后在公網(wǎng)小區(qū)：

在2G公網(wǎng)起呼導(dǎo)致的CSFB失敗，

你這個(gè)終端應(yīng)該在IDLE狀態(tài)下，終端發(fā)送ESR后，需要建立RRC連接，然后網(wǎng)絡(luò)通過(guò)RRC釋放消息進(jìn)行重定向到2G

從截圖可以看到，終端發(fā)送RRC請(qǐng)求后沒(méi)有響應(yīng)，那么應(yīng)該是終端在LTE下隨機(jī)接入失敗了，可以看一下LTE小區(qū)，為何隨機(jī)接入失敗

看一下所加頻點(diǎn)中有沒(méi)有需要回落的2G頻點(diǎn)及4-2互操作參數(shù)

MT被叫由paging觸發(fā)：Idle狀態(tài)下CSFB由RRC層的paging觸發(fā)，Active狀態(tài)下由NAS

層的CS Service Notification觸發(fā)，Idle狀態(tài)需要RRC建立流程，Active狀態(tài)下不需要此流程，所以出現(xiàn)RRC Connection Request是正常，一般高鐵用專網(wǎng)進(jìn)行覆蓋，盡量不要用到公網(wǎng)的小區(qū)，后續(xù)會(huì)出現(xiàn)切換順序混亂和掉話未接通，扯遠(yuǎn)了，看占用的小區(qū)信號(hào)質(zhì)量和強(qiáng)度良好，但信令里面出現(xiàn)了一個(gè)位置更新，會(huì)不會(huì)出現(xiàn)LAC和TAC不一致的問(wèn)題導(dǎo)致未接通，想要批量檢查TAC和LAC不一致的問(wèn)題，我剛上傳一個(gè)檢查TAC和LAC不一致的小技巧，大家可以看下