CSFB呼叫流程貫穿LTE與GSM兩網，涉及網元數量多、流程複雜，與2/3G語音相比，端到端呼叫成功率相對較低。各類失敗情形多，信令過程複雜。為便於現網CSFB問題的分析定位，特編寫本手冊供現網CSFB維護人員參考。手冊從CSFB主叫失敗、CSFB被叫失敗、CSFB時延大、CSFB其它失敗四個部分對CSFB失敗原因的信令特徵：加以說明。
2 失敗類型：CSFB主叫失敗
2.1 失敗原因： 終端回落到了弱覆蓋的2G小區,終端在2G的接續過程中掉話在空口上，接入過程中，信令中斷，或者出現頻繁切換請求或者命令，之後A口下發釋放消息。
頻繁切換:
2G弱覆蓋掉話：
A接口：
情形1.主叫回落到2G後,BSC在CM-Service- Request消息和ALERTING消息之間發出了CLEAR REQUEST消息.
情形2.主叫回落到2G後,終端在CM-Service- Request消息和ALERTING消息之間對網絡側下發的某個消息無響應(如鑑權請求),終端在2G脫網,然後在S1AP口出現TAU位置更新,MSC收到TAU位置更新後在A口下發clear_command.
3 失敗類型：CSFB被叫失敗
3.1失敗原因： 用戶處在2個TA重疊的覆蓋範圍, 經常在兩個TA之間來回重選，做被叫時正在重選過程中導致的CSFB被叫時失敗信令特徵
SGS接口：
MSC下發SGS尋呼消息後,MME無SGSap-Service- Request消息響應。
MME-S1接口：
S1口會下發SGS口下發的尋呼信令。
Uu接口：
存在頻繁的位置更新消息，嚴重時頻度達到每分鐘3-4次，且位置更新消息中的TAC在2個TAC之間來回桌球切換。ENODEB在下發尋呼時，用戶正處在位置更新過程中。
3.2失敗原因： 未部署MTRF功能情況下 UE跨MSC Pool回落，導致的CSFB被叫失敗信令特徵
終端註冊在LA1對應的MSC1上，MSC1在MSC PooL1內。終端做被叫回落時選擇接入的GSM小區為LA2，對應的MSC為MSC2，MSC2在MSC PooL2內
SGS接口：
SGS口信令接續正常，下發尋呼，並收到MME發送給MSC的sevicerequest
MME-S1接口：
S1口信令接續正常，手機收到尋呼之後，正常發起Extend sevice request，並正常下發Release command與Release response，之後手機脫離4G並在2G中發起駐留
A接口：手機嘗試在2G網絡上發起駐留，駐留完成之後發Paging response，鑑權之後，網絡會下發clear的釋放消息
或者是看不到A口的任何消息，信令丟失了
Uu接口：
空口信令正常接續，與A口信令一致，主要是上發pagingresponse消息，完成立即指配之後，網絡下發clear command消息
3.3失敗原因： 諾西ENodeB的CSFB功能未打開，導致的CSFB被叫失敗
信令特徵
SGS接口：
MME-S1接口：
Uu接口：
在Downlink NAS Transport裡有service reject消息，EMM Cause為11
3.4失敗原因： 阿朗ENodeB的CSFB LICENSE功能未打開，導致的CSFB被叫失敗。
信令特徵
SGS接口：
不需關注
MME-S1接口：
MME收到終端回的尋呼響應後，向終端發起指示CSFB回落,在MME發送Initial Context Setup消息給EnodeB之後， EnodeB回復initalcontext setup failure消息帶了失敗原因值om-intervention。然後MME回復EnodeB downlink-nas-transport-service reject，帶cause值implicitly detached.
Uu接口：
CSFB手機會回落TDS進行主叫，接續時延普遍超過20s
3.5失敗原因： 諾西MME軟體缺陷，當用戶正在進行X2切換時，MME並沒有等待該切換完成後重新下發Paging消息，最終導致尋呼未正常下發.諾西計劃在14年6月的NS31中解決。
信令特徵
SGS接口：
不需關注
MME-S1接口：
MME下發尋呼時, 用戶正在進行X2切換,eNodeB發出暫時拒絕尋呼的消息，在X2切換完成後MME沒有重新下發Paging消息。
Uu接口：
不需關注
3.6失敗原因： 手機終端設置黑名單或來電防火牆引起CSFB被叫失敗
信令特徵
SGS接口：
不需關注
MME-S1接口：
不需關注
Uu接口：
不需關注
A接口：
被叫成功回落到2G,尋呼響應鑑權過程均正常,然後MSC向手機下發SETUP消息,
情形1.手機側立即回RELEASE complete消息,攜帶原因值user busy
情形2.手機側回ALERTING消息後立即發出DISCONNECT消息,攜帶原因值userbusy
3.7失敗原因： 回落2G後發生LAC改變,改變後的LAC所屬BSC(華為）的GSM小區未開啟CSFB功能，導致主叫失敗
信令特徵
回落2G後發生LAC改變，比如：eNodeBTAC為22718（對應GSM LAC為22718），回落GSM小區LAC為22559。
SGS接口：
不需關注
MME-S1接口：
不需關注
Uu接口：
若未開啟「support CSFB功能」，則華為的BSC不會透傳LAU信令（在華為的單用戶信令跟蹤A+abis口中都無法跟蹤到這條LAU信令），從終端側表現來看上報LAU後網絡側未給回應。這個目前採用周期性後臺核查方式來解決。
A接口：
無信令
Abis接口：
從目前的表象看，若不開啟該功能，Abis口的單用戶信令跟蹤也不顯示LAU。
手機回落後在上報LAU後，BSC無響應，後續直接channelrelease。LAU中攜帶相關欄位（3GPP R10後同時有CSMO和CSMT欄位）：csmo = 1(0x1)(cs fallback MO call) ，csmt = 0 (0x0) (no additional info)。回落後，若終端檢測到LAC改變，則會觸發LAU（帶CSFB標誌），等到LAU Accept之後才進行後續的呼叫流程（Setup等）。
• 通過華為BSC側信令跟蹤，發現若GSM小區CSFB開關未打開，BSC將會截留終端的攜帶回落指示的LAU信令。 華為BSC打開GSM小區CSFB開關指令SET GCELLSOFT： IDTYPE=BYNAME, CELLNAME="xxxxxxxxx", SUPPORTCSFB=SUPPORT;
3.8失敗原因：阿朗ENODEB採用BitMap方式下發GSM回落頻點導致CSFB接通失敗
信令特徵
CSFB過程中，RRC Release過程中下發GSM頻點，阿朗ENODEB支持三種發送機制：
Ø explicitListOfARFCNs：列出頻點
Ø equallySpacedARFCNs：等差的，列出頭一個頻點和等差步長；
Ø variableBitMapOfARFCNs：列出第一個頻點，用bitmap表達其他的；
這三種方式上海貝爾ALU eNB都支持，最終顯示出來是用哪種方式是由算法決定的。三種方式下，空口消息的長度可能是不一樣的，ALU eNB會選擇最有效率的方式來編碼。在CSFB過程中採用BitMap方式下發GSM頻點後，手機終端往往佔用第一個GSM頻點（即配置頻點的最小頻點），極可能佔用不合適的小區（如室分小區、較遠的小區），從而導致CSFB接通失敗。通過分析推斷，現網中的手機並不支持Bitmap的下發方式，導致無法正常的解碼頻點，從而只佔用了第一個GSM頻點。
SGS接口：無
MME-S1接口：無
Uu接口：
無明顯異常，被叫終端接入頻點可能導致通話失敗。
3.9失敗原因：回落鄰區漏配、少配或者優先級不當引起回落失敗
信令特徵
SGS接口：
MME-S1接口：
Uu接口：
鄰區少配或者漏配，主要體現在回落小區不合適，導致無線接入失敗或者是接入之後，短時間內切換很多，特別是振鈴之前，其他無異常
3.10 失敗原因： 諾西MME的BUG造成7108D等單卡雙待手機存在聯合附著. 引起雙待手機被叫失敗
信令特徵
三星NOTE2/3雙待終端發起周期性TAU時，諾西MME將TAU類型改為聯合位置更新，導致被叫尋呼消息發向SGS接口，引起被叫失敗
SGS接口：
MME-S1接口：
手機會在S1口上發正常位置更新或者周期性位置更新，網絡回復的位置更新為聯合位置更新，周期大致在54分鐘左右
Uu接口：
空口信令是正常的，無顯著異常
3.11 失敗原因： ENODEB將ESR(TAU)錯誤分發至另外一個SGSN，引起被叫無法接續（大唐、中興ENDOBE)
信令特徵
SGS接口：
MME-S1接口：
Uu接口：
UE側信令跟蹤顯示TAU REQUEST消息目標MMEC為149，但是網絡側下發TAU ACCEPT的MMEC為146，不屬於同一個MME。
3.12 失敗原因： 偽基站幹擾，CSFB手機做被叫時回落至偽基站，造成被叫失敗
信令特徵
SGS接口：
MME-S1接口：
S1信令正常接續，收到sgs口的paging消息，手機發起Extendedsevice request請求，並正常release消息，之後在CSFB信令平臺中找不到對應的2G信令。
Uu接口：
主被叫均佔用h710113紅雷絲織廠LY廣田大酒店SM_1小區（PCI=49，EARFCN=38350）信號發起CSFB，主叫釋放後佔用GSM小區 CI=30131，BCCH=92，BSIC=73,RXLEV=-52，RXQUAL=0，被叫釋放後佔用GSM小區CI=10，BCCH=84，BSIC=32，RXLEV=-58，RXQUAL=0。核查CI=10，LAC=21008的小區現網工參中不存在，為偽基站。被叫從LTE重定向到GSM的TAC-LAC不一致進行位置更新，導致未接通。
3.13 失敗原因： 4G網絡弱覆蓋尋呼無響應造成被叫失敗。
信令特徵
SGS接口：
MSS向MME下發paging request，4G網絡尋呼無響應
MME-S1接口：
MME向ENODEB下發paging request，4G網絡尋呼無響應
Uu接口：
從eNodeB採集信令來看，空口已經下發Paging消息，但是手機並未響應尋呼消息；
3.14 失敗原因： 4G網絡SINR值差，導致iPhone手機終端無法收到Paing消息造成被叫失敗。
信令特徵
SGS接口：
MSS向MME下發paging request，4G網絡尋呼無響應
MME-S1接口：
MME向ENODEB下發paging request，4G網絡尋呼無響應
Uu接口：
從eNodeB採集信令來看，空口已經下發Paging消息，但是手機並未相應尋呼消息；
手機終端側：
iPhone手機在尋呼響應時對最低SINR要求偏高（這個也和高通和華為討論了一下，建議開展相關專項，研究一下具體的門限，因為之前沒有相關的規範，目前還不能完全確定iPhone對SINR要求偏高）。
在14時25分03秒，系統下發Paging，PDCCH解調成功，而PDSCH解調失敗，此時MCS為0，採用調製方式為QPSK，分配RB數為3。
第218幀的SINR測量值為空（10.000類似值為假），從後續SINR顯示來看此時SINR值處於惡化狀態。
4秒以後二次paging失敗，此時分配RB數為4。
第141幀的SINR測量值為空（10.000類似值為假），從後續SINR顯示來看此時SINR值較第一次更差
兩次Paging時電平均強於-110dBm，覆蓋相對較好。
3.15 失敗原因： 華為MME流程衝突導致的CSFB被叫失敗
信令特徵
終端在進行TAU的流程時，如果此時用戶收到下行數據消息，MME會中止TAU流程，造成TAU流程不完整，將導致後續用戶的CSFB被叫失敗。具體而言，是由於MME在TAU過程中與DOWNLINK DATA NOTIFICATION衝突，沒有在TAU結束後給MSC回TMSI 分配確認消息。MSC發起IMSI尋呼導致無線側失敗，CSFB被叫流程失敗。
SGS接口：
MME-S1接口：
Uu接口：
4 失敗類型：CSFB呼叫時延過大4.1失敗原因：用戶在主叫回落前和回落後所處的TAC/LAC不一致，導致回落後先發起位置更新，再進行主被叫流程,造成時延增加兩秒左右。
信令特徵
SGS接口：不需關注
MME-S1接口： 不需關注
Uu接口：
空口信令接續正常，與正常語音通話的信令流程相比，在接入的時候增加一個位置更新流程，與A口類似。
A接口：
主叫回落到2G後,終端先發起位置更新,然後再發出CM-Service- Request消息.
5 失敗類型：其他5.1失敗原因： 諾西MME存在BUG，在雙待手機上發周期性位置更新請求時，會給雙待手機下發聯合位置更新，造成雙待手機無法被叫。
信令特徵
SGS接口：
IMEI型號是雙待手機的會出現聯合位置更新
MME-S1接口：
隨後MME向ENODEB下發的SeviceReject消息,其中攜帶EMM Cause為Implicitly detached
Uu接口：無需關注
5.2失敗原因：諾西MME由於版本缺陷下發錯誤的 QCI=0造成所有業務失敗
信令特徵
SGS接口：
無信令
MME-S1接口：
ENODEB向MME發出業務請求消息（Service Request）後,MME向ENODEB發送UECapbilityInformation消息所攜帶的QCI信息為0, 非協議規範中定義的1~9.
隨後MME向ENODEB下發的SeviceReject消息,其中攜帶EMM Cause為Implicitly detached
Uu接口：不需關注
5.3失敗原因：京信NanoCell站點不支持手機接入層的空口協議版本高於R9，造成部分空口協議版本為R10的手機附著失敗
信令特徵
天語TOUCH 3及酷派8730L手機接入層支持的空口協議版本為R10
SGS接口：無
MME-S1接口：無
Uu接口： 接入失敗原因值為failure-in-radio-interface-procedure。
5.4失敗原因1： MME漏配或錯配TA/LA,MME找不到TA/LA對應的MSC，導致UE聯合註冊失敗
信令特徵
SGS接口：無信令
MME-S1接口：
UE附著LTE網絡時,ENODEB發出附著請求（Attach Request）,攜帶「聯合附著」（combined EPS/IMSI attach）指示,MME返回（Attach Accept）消息,攜帶EMM Cause為MSCTEMPORARILYNOTREACHABLE。