CSFB異常點分析總結(jié)

1、文檔名稱文檔密級1 問題現(xiàn)象1：R9盲重定向后讀取3G系統(tǒng)消息接入如下圖所示：UE發(fā)起CSFB后，接入3G后讀取系統(tǒng)消息，說明R9的FLASH CSFB未生效分析LTE側(cè)RRC連接釋放消息，可以看到ENB只下發(fā)了頻點，沒有下發(fā)相應(yīng)小區(qū)信息分析LTE側(cè)SIB1消息，可以看到此時接入的LTE ENB為9，小區(qū)為1結(jié)論：9號enb為集錦飯店，此站的RIM流程有問題，DSP UTRANRIMINFO中，未包含最高優(yōu)先級的3G鄰區(qū)，由于測試版本BUG，導(dǎo)致rrc release消息中未攜帶系統(tǒng)消息，接入3G小區(qū)后讀取了系統(tǒng)消息。2 問題現(xiàn)象2：CSFB至3G后發(fā)起LAU，并且無法快速返回4G，并且未發(fā)現(xiàn)

2、alerting問題如下所示，UE在3G側(cè)發(fā)起LAU從呼叫開始分析，在16:16:40.135，LTE發(fā)起RRC連接釋放觸發(fā)CSFB動作，由于RRC連接釋放消息中只攜帶頻點，因此是R8的重定向CSFB，UE在3G側(cè)讀取系統(tǒng)消息接入UE在16:16:41.300發(fā)起RRC連接請求，此次RRC連接請求是CSFB的接入請求，可以看到RRC連接請求攜帶的原因為conversation callUE在16:16:42.957發(fā)送RB SETUP CMP消息完成CS RAB的建立，但從UE側(cè)信令上看，過了6秒之后，UE進入空閑態(tài)UE在16:16:48.742發(fā)送cell update重新接入，攜帶原因為u

3、nrecoverableError，并且報AM-RLC在RB 2-3or4上錯誤指示為1，因此判斷鏈路發(fā)生SRB復(fù)位掉話，UE后續(xù)通過cell update重新接入。從當時的信號強度和質(zhì)量來看，下行Ec/Io較好，因此判斷是上行失敗導(dǎo)致UE掉話。懷疑RNC未收到UE發(fā)送的RB SETUP CMP消息。 由于UE掉話，后續(xù)UE接入后重新發(fā)起RRC連接請求，此時攜帶原因值為注冊。表示此時UE認為該次RRC連接并非CSFB業(yè)務(wù)。UE在16:16:49.509發(fā)起RRC連接請求，原因為注冊。由于前面UE也沒有做過位置區(qū)更新，因此本次注冊后，UE發(fā)起位置區(qū)更新并且由于此次UE認為并非CSFB業(yè)務(wù)，發(fā)起的

4、RRC連接請求里攜帶了pre-redirection信元，因此RNC判斷此次UE接入并非CSFB業(yè)務(wù)，也就不會發(fā)起fastreturn了3 問題現(xiàn)象3：出現(xiàn)連續(xù)Reconfiguration及Measurement過程如下圖所示：LTE發(fā)送ReconfigurationLTE下發(fā)Reconfiguration有兩種作用，一種是RLC層參數(shù)的重新配置（類似于3G的RB重配），比如上圖中的第一個RRCconnectionReconfiguration，里面攜帶的信元基本為RLC層參數(shù)配置及信道參數(shù)配置第二個RRCconnectionReconfiguration為下發(fā)的測量控制，包括系統(tǒng)內(nèi)測量或系

5、統(tǒng)間測量4 問題現(xiàn)象4：未發(fā)送ESR，從4G重定向到3G該現(xiàn)象為基于覆蓋的PS重定向，由于異系統(tǒng)切換未打開，因此移動性走重定向流程。ENB 16:25:27.655下發(fā)測量控制，攜帶A1/A2/A3事件相關(guān)參數(shù)從該測量控制中可以看出，A2測量事件的測量ID為3，門限為70（異系統(tǒng)），即為70測量ID為5，門限為40（異頻），即為100通過信令，可以看到MS上報測量報告，上報A2事件，并且測量ID為3，說明啟動異系統(tǒng)測量之后ENB下發(fā)測量控制，要求UE測量異系統(tǒng)（3G）鄰區(qū)UE上報3G鄰區(qū)后，ENB發(fā)起重定向流程，將用戶重定向到3G鄰區(qū)5 問題現(xiàn)象5：UE多次收到RRC CONNECTION S

6、ETUP消息這個是由于UE發(fā)送RRC CONNECTION REQUEST消息后，監(jiān)聽下行CCCH信道，如果收到是屬于自己的RRC CONNECTION SETUP消息則響應(yīng)，但也會收到其他用戶的RRC CONNECTION SETUP消息，則不響應(yīng)，區(qū)分是否為自己的RRC CONNECTION SETUP主要是看其中攜帶的TMSI。如下圖所示：可以看到UE收到了兩條RRC CONNECTION SETUP消息，只響應(yīng)了第二條分析RRC CONNECTION REQUEST消息，可以看到其TMSI為0x06C83BC6第一條RRC CONNECTION SETUP消息中攜帶的TMSI為0x0A

7、B0A886，因此并非UE所發(fā)RRC CONNECTION REQ消息的響應(yīng)，因此UE不回復(fù)而第二條RRC CONNECTION SETUP消息中攜帶的TMSI為0x06C83BC6，因此UE回復(fù)RRC CONNECTION SETUP COMPLETE6 問題現(xiàn)象6：切換失敗，F(xiàn)ast Return失敗，并出現(xiàn)TAU Reject重新附著流程首先看fastreturn為什么失敗。CSFB走的基于測量的PSHO，但切換發(fā)起后，UE在3G同步上行信道失敗，進入空閑態(tài)后重選到一個新的小區(qū)發(fā)起RRC連接請求首先我們看UE在LTE側(cè)上報B1事件的測量報告里上報的小區(qū)為PSC=193但UE接入到3G后，

8、193小區(qū)信號很差（ECI0很差），導(dǎo)致UE切換接入失敗UE后續(xù)重選到PSC=194小區(qū)重新接入但由于此時是重選重新接入，導(dǎo)致UE認為其并非CSFB用戶，RRC連接請求中攜帶pre-redirection信元，因此后續(xù)fastreturn不成功TAU拒絕的流程，首先看到在LTE側(cè)做TAU拒絕的原因為No EPS Bearer Context activated。協(xié)議里規(guī)定，UE在TAU REQ消息里必須攜帶一個缺省承載，如果不攜帶缺省承載的話，MME拒絕本次TAU請求，要求UE進行附著（Attach）23401 5.3.3.1If the MME has changed the new MME

9、 verifies the EPS bearer status received from the UE with the bearer contexts received from the old MME/old S4 SGSN. If the MME has not changed the MME verifies EPS bearer status from the UE with the bearer contexts available in the MM context. The MME releases any network resources related to EPS b

10、earers that are not active in the UE. If there is no bearer context at all, the MME rejects the TAU Request協(xié)議的意思是說，如果MME沒有從UE中獲取激活的MME CONTEXT并且改變其MME verifies EPS bearer status，MME則拒絕這次TAU Request分析TAU REQ消息，可以看到其中的EPS bearer context status均為INACTIVE，因此MME拒絕此次TAU REQ，要求UE進行附著而導(dǎo)致UE發(fā)這個的原因是因為在老側(cè)的SGSN沒

11、有激活相應(yīng)的PDP連接，導(dǎo)致UE在老側(cè)SGSN沒有上下文報文，因此該值為空。分析信令，可以看到PDP連接被UE去激活，并且后續(xù)沒有再激活。PDP承載去激活屬于NAS消息，即屬于核心網(wǎng)直接下發(fā)給UE的消息，無線側(cè)只做轉(zhuǎn)發(fā)，不解析其中任何內(nèi)容，從協(xié)議上來看，當核心網(wǎng)不再為UE保持pdp連接的時候，即發(fā)起PDP去激活。UE下載再做數(shù)傳業(yè)務(wù)的話，就需要重新激活PDP連接。7 問題現(xiàn)象7：鑒權(quán)失敗的原因為同步失敗根據(jù)協(xié)議描述，該原因值表示UE認為Authentication Req里攜帶的SQN超過范圍而SQN包含在Authentication Req里的AUTN里核心網(wǎng)羅曉 分析猜測這種鑒權(quán)失敗的如下

12、：CSFB 回落成功電話掛機后應(yīng)該是手機發(fā)起TAU/LAU，在TAU 到MME 后MME 做了一次鑒權(quán)，鑒權(quán)成功后手機SIM卡上的SQN被改寫，而MSC 上發(fā)送給手機的鑒權(quán)請求為MSC 先期到HLR 取的鑒權(quán)集中的SQN，所以嚇到手機上出現(xiàn)不一致，手機會鑒權(quán)失敗，MSC在收到手機的鑒權(quán)失敗后，MSC發(fā)起向HLR 取新的鑒權(quán)集，之后MSC 再次向手機發(fā)起鑒權(quán)請求，此時鑒權(quán)成功，位置更新也成功；核心網(wǎng)龔華龍答復(fù)：1、 鑒權(quán)問題1） 少量的鑒權(quán)重同步在現(xiàn)網(wǎng)是非常正常的，只要鑒權(quán)重同步成功就不是問題。如果大量的重同步或者在某場景下必現(xiàn)問題請一線在HSS收集用戶跟蹤，發(fā)給研發(fā)定位。2） 只要HSS是2/

13、3/4G融合版本，并且當前測試用戶都在這個HSS上，HSS就會分域處理，VLR/MSC和MME是不同的兩個域，正常鑒權(quán)場景下，它們之間的SQN相互不影響，不會存在下面郵件中“猜測鑒權(quán)失敗”的問題。3） GU互操作等場景都會觸發(fā)域切換，這些場景在現(xiàn)網(wǎng)很多地方都有運用，在聯(lián)通實驗室也測試通過，這是基本功能，如果有問題早就發(fā)現(xiàn)了。一般出問題都比較異常場景，需要提供HSS消息跟蹤、重現(xiàn)場景等定位信息，否則無法定位?，F(xiàn)網(wǎng)出現(xiàn)鑒權(quán)失?。ㄖ赝胶筮€失敗的問題）的幾種可能原因，以供參考：l MSC/SGSN鑒權(quán)請求未攜帶RequestingNodeType信元，導(dǎo)致HSS無法區(qū)分域信息l USIM卡中的L值設(shè)

14、置過小。l 4G的 HSS和2/3G HLR分離部署，不是融合部署。l HSS系統(tǒng)時間跳變。8 問題現(xiàn)象8：L到U基于覆蓋的盲重定向在LTE建立RRC連接后，ENB下發(fā)測量控制，攜帶A2事件門限，A2事件的門限為40，且測量ID為3后續(xù)UE上報A2事件，可以看到測量ID為3（表示為A2事件），實際測量RSRP為39，小于A2門限，A2事件觸發(fā)A2事件表示當LTE當前信號小于某一個值時，UE啟動異系統(tǒng)測量，而由于盲切換打開，因此處走的是基于覆蓋的盲重定向流程到3G。LTE側(cè)直接RRC RELEASE，攜帶3G頻點。9 異常時延分析【問題描述】10月19日測試數(shù)據(jù)總共兩次異常時延，如下圖所示：Lo

15、g名測量類型主被叫時延Probe_20131019114956-44主叫_1盲重定向主叫/MS212.643Probe_20131019114956-44主叫_1盲重定向主叫/MS29.708【問題分析】l 第一次異常點：ESR: 12:07:57.775 -> RRC release: 12:07:57.805LTE側(cè)時延：30ms RRC release: 12:07:57.805 -> 3G RRC connection req: 12:07:58.2453G搜網(wǎng)時間: 440msRRC connection req: 12:07:58.245 -> RB setup

16、cmp: 12:07:59.785主叫RB建立時延：1540msRB setup cmp: 12:07:59.785 -> Alerting: 12:08:10.418等待被叫響應(yīng)：10633ms分析主叫各段時延，主要是等待被叫響應(yīng)時延過長導(dǎo)致。需要分析被叫行為，本次呼叫被叫也為LTE起呼。被叫MS收到ESR時間為12:07:59.564，分析信令，主要有兩處導(dǎo)致被叫時延較長1、 被叫FLASH CSFB沒有生效，在3G側(cè)讀取了系統(tǒng)消息（并非主要時延）分析系統(tǒng)消息3，其中Cellidentity表明接入的3G小區(qū)為18232，查詢其擾碼為19，下行頻點為10713Cellidentity

17、后面16位表示cellid，計算得出為18232，分析LTE側(cè)的RRC connection release，該小區(qū)并未被下發(fā)，查詢配置，該小區(qū)并未添置為鄰區(qū)從收到LTE的RRC connection release到在3G小區(qū)發(fā)起RRC連接請求，時延為1670ms2、 UE在3G的18232小區(qū)接入，后續(xù)該小區(qū)信號衰變，UE掉話脫網(wǎng)，發(fā)送cell update進行鏈路重建后在PSC=178小區(qū)重新建立CS業(yè)務(wù)，整段時延達到10秒左右（主要原因）如下圖所示，UE在PSC=19小區(qū)響應(yīng)尋呼后，進行相關(guān)NAS層交互（路由區(qū)更新和認證加密等），但在上報同頻測量報告后進入空閑態(tài)，同頻測量報告中178小

18、區(qū)Ec/Io較好，但19小區(qū)Ec/Io已經(jīng)較差。分析懷疑此時RNC收到了測量報告，可能下發(fā)了ASU準備進行1A事件，但UE未收到。UE發(fā)送cell update進行重建，再建立CS業(yè)務(wù)查看工參，18232小區(qū)為CELLNAME="WD杭州華鴻科技大廈_2"，并不在該51號enodeb周邊，懷疑可能是3G越區(qū)覆蓋到此處，導(dǎo)致信號衰變引起該問題，建議RF調(diào)整。l 第二次異常點：LTE側(cè)時延：28msUE搜網(wǎng)時延：1027ms 此處UE接入3G時讀取了系統(tǒng)消息，說明FLASH CSFB未生效，導(dǎo)致時延較長主叫CSRAB建立時延：7012ms等待被叫時延：1641ms此次呼叫影響時延主要是2點，一個時f