CSFB失敗問題快速定位手冊

1、CSFB失敗問題快速定位手冊 大唐移動 CSFB失敗問題快速定位手冊文檔名稱CSFB失敗問題快速定位手冊文檔編號版 本 號1.0.0作 者張晚辰目 錄1.準備工作32.主叫失敗32.1定位技巧32.2定位流程32.3定位案例73.被叫失敗83.1定位技巧83.2定位流程103.3定位案例104.附錄131. 準備工作按照目前山西移動的拉網規(guī)范，CSFB拉網需要使用1部雙待手機作為主叫，1部CSFB手機作為被叫，兩部手機同時連接CDS路測軟件進行拉網，所以在做CSFB拉網測試分析時，我們需要將主叫失敗與被叫失敗區(qū)分對待。同時，CSFB失敗的現象可能各不相同，但是成功的現象基本是一致的，所以我們在

2、分析初期對信令不熟悉時，往往可以通過與正確流程進行比對，來確定失敗的癥結所在，此處也會盡量多介紹一些失敗的案例，供大家分析參考。2. 主叫失敗122.1 定位技巧由于主叫側使用雙待手機，所以可以認為主叫手機語音業(yè)務一直工作在2G，因此一旦發(fā)現主叫失敗后，往往可以將問題收斂至2G，從而加快定位速度。2.2 定位流程1. 打開CDS后，新建標簽頁，命名為“主被叫比對”，在視圖頁拖動兩個信令窗口放置在上方，然后再拖動兩個事件窗口放置在下方，在左側的信令和事件窗口點擊右鍵，選擇主叫終端，在右側同樣操作，選擇被叫終端，如下圖。2. 然后再點擊統(tǒng)計-事件，新建一個標簽頁，然后在事件中，將“Call blo

3、cked”拖動至剛打開的統(tǒng)計頁中，此時會顯示總失敗次數，將其打開，下方會顯示失敗對應的時間點，雙擊它，會直接跳到失敗的時間點，如下圖。3. 回到剛才打開的主被叫比對頁面，可以在下方事件窗口中看到，每一個事件都有對應的關鍵信令，正確的信令流程如下圖，可以看出，主叫側已經上報呼叫建立，同時進入等待，這時主叫側的起呼流程就走完了。此后，在收到核心網下發(fā)的Connect后，代表主叫側呼叫建立。最后，主叫側上報Disconnect，核心網下發(fā)拆鏈，拆鏈完成，一次完整的主叫呼叫流程就走完了。4. 接下來我們看被叫側的信令，點擊主叫側Setup信令，記錄此信令上報時間，在右側找到此時間點稍后時間的尋呼消息（

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

5、G，隨后上報尋呼響應，核心網下發(fā)呼叫建立，終端上報呼叫響應，開始振鈴，之后被叫接聽，由于腳本設置，10S后主叫側掛機，被叫側收到Disconnect后上報拆鏈請求，最終核心網下發(fā)拆鏈完成，一次標準的被呼流程就完成了，此時對應的事件是Call hangup，也就是掛機。2.3 定位案例1.分析LOG時經?？梢园l(fā)現一些失敗是由于主叫側2G擁塞造成，如下圖。立即指配拒絕，原因為SD信道擁塞，將出現擁塞的小區(qū)反饋給2G優(yōu)化人員后，通過2G擴容，此問題可以解決。2. 由于2G網絡處理channel release消息和handover command消息并發(fā)沖突，導致拆鏈失敗，如下圖，此問題的現象為無法

6、掛機。3. 被叫失敗12333.1 定位技巧被叫失敗是目前失敗的重點，一旦確認主叫側呼叫建立完成但是卻未呼通時，通常需要從被叫側尋找原因，而被叫側失敗的原因往往較多，這里記錄典型原因如下。1. 被叫側未收到尋呼消息，導致未呼通。4G核心網存在二次尋呼，二次尋呼的間隔各地不同，山西省目前設置為10S，我們在分析未呼通原因時需要分析兩次尋呼都丟失的原因。原因：現階段丟尋呼通常有三種原因。1） 被叫終端駐留在4G網絡，此時正在進行TAU過程。2） 被叫終端駐留在3G網絡，此時正在進行RAU或者LAU過程。3） 此時信道質量較差，尋呼丟在空口。分析方法：首先查看主叫側終端LOG，找到主叫側上報Setu

7、p的時間點，按照此時間點向下12S尋找被叫側是否收到了一次尋呼。如果沒有收到，再向下10S觀察是否收到了二次尋呼。兩次尋呼丟失的原因很可能并不相同，因此需要區(qū)分對待。如果確認尋呼丟失，需要提取被叫側終端所駐留站點的CDL，查看主叫側上報Setup后對應時間點被叫側所駐留的小區(qū)是否收到了核心網下發(fā)的尋呼消息，此消息是否下發(fā)給終端了，如果確認已下發(fā)，則需要再深入分析究竟尋呼是丟在了基站側底層處理上，還是丟在了空口。2. 除去尋呼，被叫側的4G關鍵信令是RRCConnectionRequest、RRCConnectionSetupComplete和RRCConnectionRelease，如下圖。在

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

9、，存活檢測僅看DRB而未檢測SRB2，導致了攜帶CSFB信息的RRC Connection Release被基站側丟棄，需要通過升級版本解決。3.2 定位流程同2.2節(jié)定位流程。3.3 定位案例1. 4G側漏配2G頻點導致被叫失敗，如下圖。查看了主叫側使用的2G頻點，如下圖。發(fā)現519 頻點并未添加到4G側的頻點列表中，導致4G回落2G失敗，添加2G頻點后問題解決。2.在分析LOG時經常發(fā)現被叫丟尋呼導致的失敗，如下圖。此時查看被叫側狀態(tài)，發(fā)現無線環(huán)境已經很差，屬于弱覆蓋區(qū)域，如下圖：查看了基站側CDL，發(fā)現基站側已經將尋呼消息下發(fā)給UE，據此判斷是由于無線環(huán)境差導致尋呼消息丟在空口，此處弱覆蓋需要由優(yōu)化人員處理。3.由于2G網絡處理LAU和TCH建立并發(fā)時沖突異常，導致呼叫失敗，如下圖，終端在發(fā)起語音業(yè)務時，需要先建立SD信道，再通過SD信道申請TCH信道，而如果在申請SD信道時，終端發(fā)起LAU，這時終端就會先響應LAU，重新為LAU申請新的SD信道，從而導致了呼叫失敗，這是2G實現問題，屬于正常情況。4. 被叫終端在2G網絡通話結束后拆鏈失敗， CN沒有在nas層下發(fā)release消息導致被叫處在連接態(tài)，下一次呼叫失敗。5.被叫側終端在收到尋呼后會發(fā)起R