CSFB失敗問題快速定位手冊(cè)

1、CSFB失敗問題快速定位手冊(cè)文檔名稱CSFB失敗問題快速定位手冊(cè)文檔編號(hào)版 本 號(hào)1.0.0作 者張晚辰目 錄1.準(zhǔn)備工作32.主叫失敗32.1定位技巧32.2定位流程32.3定位案例73.被叫失敗83.1定位技巧83.2定位流程103.3定位案例104.附錄131. 準(zhǔn)備工作按照目前山西移動(dòng)的拉網(wǎng)規(guī)范，CSFB拉網(wǎng)需要使用1部雙待手機(jī)作為主叫，1部CSFB手機(jī)作為被叫，兩部手機(jī)同時(shí)連接CDS路測(cè)軟件進(jìn)行拉網(wǎng)，所以在做CSFB拉網(wǎng)測(cè)試分析時(shí)，我們需要將主叫失敗與被叫失敗區(qū)分對(duì)待。同時(shí)，CSFB失敗的現(xiàn)象可能各不相同，但是成功的現(xiàn)象基本是一致的，所以我們?cè)诜治龀跗趯?duì)信令不熟悉時(shí)，往往可以通過與正

2、確流程進(jìn)行比對(duì)，來確定失敗的癥結(jié)所在，此處也會(huì)盡量多介紹一些失敗的案例，供大家分析參考。2. 主叫失敗1.1 定位技巧由于主叫側(cè)使用雙待手機(jī)，所以可以認(rèn)為主叫手機(jī)語音業(yè)務(wù)一直工作在2G，因此一旦發(fā)現(xiàn)主叫失敗后，往往可以將問題收斂至2G，從而加快定位速度。1.2 定位流程1. 打開CDS后，新建標(biāo)簽頁(yè)，命名為“主被叫比對(duì)”，在視圖頁(yè)拖動(dòng)兩個(gè)信令窗口放置在上方，然后再拖動(dòng)兩個(gè)事件窗口放置在下方，在左側(cè)的信令和事件窗口點(diǎn)擊右鍵，選擇主叫終端，在右側(cè)同樣操作，選擇被叫終端，如下圖。2. 然后再點(diǎn)擊統(tǒng)計(jì)-事件，新建一個(gè)標(biāo)簽頁(yè)，然后在事件中，將“Call blocked”拖動(dòng)至剛打開的統(tǒng)計(jì)頁(yè)中，此時(shí)會(huì)顯示

3、總失敗次數(shù)，將其打開，下方會(huì)顯示失敗對(duì)應(yīng)的時(shí)間點(diǎn)，雙擊它，會(huì)直接跳到失敗的時(shí)間點(diǎn)，如下圖。3. 回到剛才打開的主被叫比對(duì)頁(yè)面，可以在下方事件窗口中看到，每一個(gè)事件都有對(duì)應(yīng)的關(guān)鍵信令，正確的信令流程如下圖，可以看出，主叫側(cè)已經(jīng)上報(bào)呼叫建立，同時(shí)進(jìn)入等待，這時(shí)主叫側(cè)的起呼流程就走完了。此后，在收到核心網(wǎng)下發(fā)的Connect后，代表主叫側(cè)呼叫建立。最后，主叫側(cè)上報(bào)Disconnect，核心網(wǎng)下發(fā)拆鏈，拆鏈完成，一次完整的主叫呼叫流程就走完了。4. 接下來我們看被叫側(cè)的信令，點(diǎn)擊主叫側(cè)Setup信令，記錄此信令上報(bào)時(shí)間，在右側(cè)找到此時(shí)間點(diǎn)稍后時(shí)間的尋呼消息（滯后12S），雙擊它，可以看到尋呼原因是CS

4、被叫，如下圖所示。5. 此時(shí)的流程分為兩類：1） 終端處于空閑態(tài)。這時(shí)終端會(huì)收到Paging，然后發(fā)起RRC連接建立請(qǐng)求，隨后完保通過，基站側(cè)下發(fā)RRCConnectionRelease，這條信令會(huì)攜帶2G頻點(diǎn)信息，終端收到這條信令后開始回落2G，如下圖。2） 終端處于連接態(tài)。這時(shí)終端會(huì)收到CS Service Notification，即CS服務(wù)通知，隨后終端上報(bào)Extended Service Request，這時(shí)就省略了建立RRC連接，基站側(cè)直接下發(fā)RRCConnectionRelease，終端回落2G，如下圖。6. 經(jīng)過步驟5后，終端回落至2G，隨后上報(bào)尋呼響應(yīng)，核心網(wǎng)下發(fā)呼叫建立，終

5、端上報(bào)呼叫響應(yīng)，開始振鈴，之后被叫接聽，由于腳本設(shè)置，10S后主叫側(cè)掛機(jī)，被叫側(cè)收到Disconnect后上報(bào)拆鏈請(qǐng)求，最終核心網(wǎng)下發(fā)拆鏈完成，一次標(biāo)準(zhǔn)的被呼流程就完成了，此時(shí)對(duì)應(yīng)的事件是Call hangup，也就是掛機(jī)。1.3 定位案例1.分析LOG時(shí)經(jīng)常可以發(fā)現(xiàn)一些失敗是由于主叫側(cè)2G擁塞造成，如下圖。立即指配拒絕，原因?yàn)镾D信道擁塞，將出現(xiàn)擁塞的小區(qū)反饋給2G優(yōu)化人員后，通過2G擴(kuò)容，此問題可以解決。2. 由于2G網(wǎng)絡(luò)處理channel release消息和handover command消息并發(fā)沖突，導(dǎo)致拆鏈?zhǔn)。缦聢D，此問題的現(xiàn)象為無法掛機(jī)。3. 被叫失敗1.4 定位技巧被叫失敗

6、是目前失敗的重點(diǎn)，一旦確認(rèn)主叫側(cè)呼叫建立完成但是卻未呼通時(shí)，通常需要從被叫側(cè)尋找原因，而被叫側(cè)失敗的原因往往較多，這里記錄典型原因如下。1. 被叫側(cè)未收到尋呼消息，導(dǎo)致未呼通。4G核心網(wǎng)存在二次尋呼，二次尋呼的間隔各地不同，山西省目前設(shè)置為10S，我們?cè)诜治鑫春敉ㄔ驎r(shí)需要分析兩次尋呼都丟失的原因。原因：現(xiàn)階段丟尋呼通常有三種原因。1） 被叫終端駐留在4G網(wǎng)絡(luò)，此時(shí)正在進(jìn)行TAU過程。2） 被叫終端駐留在3G網(wǎng)絡(luò)，此時(shí)正在進(jìn)行RAU或者LAU過程。3） 此時(shí)信道質(zhì)量較差，尋呼丟在空口。分析方法：首先查看主叫側(cè)終端LOG，找到主叫側(cè)上報(bào)Setup的時(shí)間點(diǎn)，按照此時(shí)間點(diǎn)向下12S尋找被叫側(cè)是否收到

7、了一次尋呼。如果沒有收到，再向下10S觀察是否收到了二次尋呼。兩次尋呼丟失的原因很可能并不相同，因此需要區(qū)分對(duì)待。如果確認(rèn)尋呼丟失，需要提取被叫側(cè)終端所駐留站點(diǎn)的CDL，查看主叫側(cè)上報(bào)Setup后對(duì)應(yīng)時(shí)間點(diǎn)被叫側(cè)所駐留的小區(qū)是否收到了核心網(wǎng)下發(fā)的尋呼消息，此消息是否下發(fā)給終端了，如果確認(rèn)已下發(fā)，則需要再深入分析究竟尋呼是丟在了基站側(cè)底層處理上，還是丟在了空口。2. 除去尋呼，被叫側(cè)的4G關(guān)鍵信令是RRCConnectionRequest、RRCConnectionSetupComplete和RRCConnectionRelease，如下圖。在分析LOG時(shí)經(jīng)常發(fā)現(xiàn)關(guān)鍵信令丟失導(dǎo)致的被叫失敗。建議

8、：查看當(dāng)時(shí)的無線環(huán)境，由于覆蓋問題導(dǎo)致的丟消息需要提交優(yōu)化人員處理，如果不是因?yàn)楦采w問題導(dǎo)致，則需要提取當(dāng)時(shí)的基站側(cè)CDL對(duì)照，進(jìn)行重點(diǎn)關(guān)注。3. 4G側(cè)漏配2G頻點(diǎn)導(dǎo)致被叫失敗。建議：添加2G頻點(diǎn)。4. 在分析晉城CSFB失敗問題時(shí)發(fā)現(xiàn)，存活檢測(cè)的RRC Connection Release先于攜帶CSFB的RRC Connection Release發(fā)給終端（此時(shí)在nas層已經(jīng)開始響應(yīng)paging消息），則會(huì)出現(xiàn)丟失攜帶CSFB的RRC Connection Release消息導(dǎo)致CSFB失敗，如下圖。建議：此問題已經(jīng)專家確認(rèn)為版本BUG，存活檢測(cè)僅看DRB而未檢測(cè)SRB2，導(dǎo)致了攜帶CS

9、FB信息的RRC Connection Release被基站側(cè)丟棄，需要通過升級(jí)版本解決。1.5 定位流程同2.2節(jié)定位流程。1.6 定位案例1. 4G側(cè)漏配2G頻點(diǎn)導(dǎo)致被叫失敗，如下圖。查看了主叫側(cè)使用的2G頻點(diǎn)，如下圖。發(fā)現(xiàn)519 頻點(diǎn)并未添加到4G側(cè)的頻點(diǎn)列表中，導(dǎo)致4G回落2G失敗，添加2G頻點(diǎn)后問題解決。2.在分析LOG時(shí)經(jīng)常發(fā)現(xiàn)被叫丟尋呼導(dǎo)致的失敗，如下圖。此時(shí)查看被叫側(cè)狀態(tài)，發(fā)現(xiàn)無線環(huán)境已經(jīng)很差，屬于弱覆蓋區(qū)域，如下圖：查看了基站側(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ā)時(shí)沖突異常，導(dǎo)致呼叫失敗，如下圖，終端在發(fā)起語音業(yè)務(wù)時(shí)，需要先建立SD信道，再通過SD信道申請(qǐng)TCH信道，而如果在申請(qǐng)SD信道時(shí)，終端發(fā)起LAU，這時(shí)終端就會(huì)先響應(yīng)LAU，重新為L(zhǎng)AU申請(qǐng)新的SD信道，從而導(dǎo)致了呼叫失敗，這是2G實(shí)現(xiàn)問題，屬于正常情況。4. 被叫終端在2G網(wǎng)絡(luò)通話結(jié)束后拆鏈?zhǔn)。?CN沒有在nas層下發(fā)release消息導(dǎo)致被叫處在連接態(tài)，下一次呼叫失敗。5.被叫側(cè)終