CSFB失敗問題快速定位手冊

1、CSFB失敗問題快速定位手冊文檔名稱CSFB失敗問題快速定位手冊目 錄1.準(zhǔn)備工作32.主叫失敗32.1定位技巧32.2定位流程32.3定位案例73.被叫失敗83.1定位技巧83.2定位流程103.3定位案例104.附錄131. 準(zhǔn)備工作2. 主叫失敗122.1 定位技巧由于主叫側(cè)使用雙待手機，所以可以認為主叫手機語音業(yè)務(wù)一直工作在2G，因此一旦發(fā)現(xiàn)主叫失敗后，往往可以將問題收斂至2G，從而加快定位速度。2.2 定位流程1. 打開CDS后，新建標(biāo)簽頁，命名為“主被叫比對”，在視圖頁拖動兩個信令窗口放置在上方，然后再拖動兩個事件窗口放置在下方，在左側(cè)的信令和事件窗口點擊右鍵，選擇主叫終端，在右側(cè)

2、同樣操作，選擇被叫終端，如下圖。2. 然后再點擊統(tǒng)計-事件，新建一個標(biāo)簽頁，然后在事件中，將“Call blocked”拖動至剛打開的統(tǒng)計頁中，此時會顯示總失敗次數(shù)，將其打開，下方會顯示失敗對應(yīng)的時間點，雙擊它，會直接跳到失敗的時間點，如下圖。3. 回到剛才打開的主被叫比對頁面，可以在下方事件窗口中看到，每一個事件都有對應(yīng)的關(guān)鍵信令，正確的信令流程如下圖，可以看出，主叫側(cè)已經(jīng)上報呼叫建立，同時進入等待，這時主叫側(cè)的起呼流程就走完了。此后，在收到核心網(wǎng)下發(fā)的Connect后，代表主叫側(cè)呼叫建立。最后，主叫側(cè)上報Disconnect，核心網(wǎng)下發(fā)拆鏈，拆鏈完成，一次完整的主叫呼叫流程就走完了。4.

3、接下來我們看被叫側(cè)的信令，點擊主叫側(cè)Setup信令，記錄此信令上報時間，在右側(cè)找到此時間點稍后時間的尋呼消息（滯后12S），雙擊它，可以看到尋呼原因是CS被叫，如下圖所示。5. 此時的流程分為兩類：1） 終端處于空閑態(tài)。這時終端會收到Paging，然后發(fā)起RRC連接建立請求，隨后完保通過，基站側(cè)下發(fā)RRCConnectionRelease，這條信令會攜帶2G頻點信息，終端收到這條信令后開始回落2G，如下圖。2） 終端處于連接態(tài)。這時終端會收到CS Service Notification，即CS服務(wù)通知，隨后終端上報Extended Service Request，這時就省略了建立RRC連接，

4、基站側(cè)直接下發(fā)RRCConnectionRelease，終端回落2G，如下圖。6. 經(jīng)過步驟5后，終端回落至2G，隨后上報尋呼響應(yīng)，核心網(wǎng)下發(fā)呼叫建立，終端上報呼叫響應(yīng)，開始振鈴，之后被叫接聽，由于腳本設(shè)置，10S后主叫側(cè)掛機，被叫側(cè)收到Disconnect后上報拆鏈請求，最終核心網(wǎng)下發(fā)拆鏈完成，一次標(biāo)準(zhǔn)的被呼流程就完成了，此時對應(yīng)的事件是Call hangup，也就是掛機。2.3 定位案例1.分析LOG時經(jīng)?？梢园l(fā)現(xiàn)一些失敗是由于主叫側(cè)2G擁塞造成，如下圖。立即指配拒絕，原因為SD信道擁塞，將出現(xiàn)擁塞的小區(qū)反饋給2G優(yōu)化人員后，通過2G擴容，此問題可以解決。2. 由于2G網(wǎng)絡(luò)處理channe

5、l release消息和handover command消息并發(fā)沖突，導(dǎo)致拆鏈?zhǔn)?，如下圖，此問題的現(xiàn)象為無法掛機。3. 被叫失敗12333.1 定位技巧被叫失敗是目前失敗的重點，一旦確認主叫側(cè)呼叫建立完成但是卻未呼通時，通常需要從被叫側(cè)尋找原因，而被叫側(cè)失敗的原因往往較多，這里記錄典型原因如下。1. 被叫側(cè)未收到尋呼消息，導(dǎo)致未呼通。4G核心網(wǎng)存在二次尋呼，二次尋呼的間隔各地不同，山西省目前設(shè)置為10S，我們在分析未呼通原因時需要分析兩次尋呼都丟失的原因。原因：現(xiàn)階段丟尋呼通常有三種原因。1） 被叫終端駐留在4G網(wǎng)絡(luò)，此時正在進行TAU過程。2） 被叫終端駐留在3G網(wǎng)絡(luò)，此時正在進行RAU或

6、者LAU過程。3） 此時信道質(zhì)量較差，尋呼丟在空口。分析方法：首先查看主叫側(cè)終端LOG，找到主叫側(cè)上報Setup的時間點，按照此時間點向下12S尋找被叫側(cè)是否收到了一次尋呼。如果沒有收到，再向下10S觀察是否收到了二次尋呼。兩次尋呼丟失的原因很可能并不相同，因此需要區(qū)分對待。如果確認尋呼丟失，需要提取被叫側(cè)終端所駐留站點的CDL，查看主叫側(cè)上報Setup后對應(yīng)時間點被叫側(cè)所駐留的小區(qū)是否收到了核心網(wǎng)下發(fā)的尋呼消息，此消息是否下發(fā)給終端了，如果確認已下發(fā)，則需要再深入分析究竟尋呼是丟在了基站側(cè)底層處理上，還是丟在了空口。2. 除去尋呼，被叫側(cè)的4G關(guān)鍵信令是RRCConnectionReques

7、t、RRCConnectionSetupComplete和RRCConnectionRelease，如下圖。在分析LOG時經(jīng)常發(fā)現(xiàn)關(guān)鍵信令丟失導(dǎo)致的被叫失敗。建議：查看當(dāng)時的無線環(huán)境，由于覆蓋問題導(dǎo)致的丟消息需要提交優(yōu)化人員處理，如果不是因為覆蓋問題導(dǎo)致，則需要提取當(dāng)時的基站側(cè)CDL對照，進行重點關(guān)注。3. 4G側(cè)漏配2G頻點導(dǎo)致被叫失敗。建議：添加2G頻點。4. 在分析晉城CSFB失敗問題時發(fā)現(xiàn)，存活檢測的RRC Connection Release先于攜帶CSFB的RRC Connection Release發(fā)給終端（此時在nas層已經(jīng)開始響應(yīng)paging消息），則會出現(xiàn)丟失攜帶CSFB的

8、RRC Connection Release消息導(dǎo)致CSFB失敗，如下圖。建議：此問題已經(jīng)專家確認為版本BUG，存活檢測僅看DRB而未檢測SRB2，導(dǎo)致了攜帶CSFB信息的RRC Connection Release被基站側(cè)丟棄，需要通過升級版本解決。3.2 定位流程同2.2節(jié)定位流程。3.3 定位案例1. 4G側(cè)漏配2G頻點導(dǎo)致被叫失敗，如下圖。查看了主叫側(cè)使用的2G頻點，如下圖。發(fā)現(xiàn)519 頻點并未添加到4G側(cè)的頻點列表中，導(dǎo)致4G回落2G失敗，添加2G頻點后問題解決。2.在分析LOG時經(jīng)常發(fā)現(xiàn)被叫丟尋呼導(dǎo)致的失敗，如下圖。此時查看被叫側(cè)狀態(tài)，發(fā)現(xiàn)無線環(huán)境已經(jīng)很差，屬于弱覆蓋區(qū)域，如下圖：

9、查看了基站側(cè)CDL，發(fā)現(xiàn)基站側(cè)已經(jīng)將尋呼消息下發(fā)給UE，據(jù)此判斷是由于無線環(huán)境差導(dǎo)致尋呼消息丟在空口，此處弱覆蓋需要由優(yōu)化人員處理。3.由于2G網(wǎng)絡(luò)處理LAU和TCH建立并發(fā)時沖突異常，導(dǎo)致呼叫失敗，如下圖，終端在發(fā)起語音業(yè)務(wù)時，需要先建立SD信道，再通過SD信道申請TCH信道，而如果在申請SD信道時，終端發(fā)起LAU，這時終端就會先響應(yīng)LAU，重新為LAU申請新的SD信道，從而導(dǎo)致了呼叫失敗，這是2G實現(xiàn)問題，屬于正常情況。4. 被叫終端在2G網(wǎng)絡(luò)通話結(jié)束后拆鏈?zhǔn)。?CN沒有在nas層下發(fā)release消息導(dǎo)致被叫處在連接態(tài)，下一次呼叫失敗。5.被叫側(cè)終端在收到尋呼后會發(fā)起RRC連接建立請求，但是R