2016年VOLTE專項案例庫.docx

1.1. 優(yōu)化案例提供的案例必須通過無線信令分析，每個案例必須與投標方所從事的項目關聯(lián)，提供的案例需指明所從事項目合同名稱、合同編號，及相關合同關鍵頁復印件，同時案例要求有詳細的分析過程、指出問題所在、提出解決方案、并有實施效果前后對比等要素，即為一個合格的案例.附表2-優(yōu)化案例提供的案例必須通過無線信令分析，每個案例必須與投標方所從事的項目關聯(lián)，提供的案例需指明所從事項目合同名稱、合同編號，及相關合同關鍵頁復印件，同時案例要求有詳細的分析過程、指出問題所在、提出解決方案、并有實施效果前后對比等要素，即為一個合格的案例.格式自擬優(yōu)化案例目合同名稱、合同編號，及相關合同關鍵頁復印件序號案例名稱合同名稱合同編號16.2.1. 北京移動某區(qū)域CSFB提升優(yōu)化中國移動北京公司2015-2017年五環(huán)外無線網(wǎng)絡日常優(yōu)化服務合同（第一比選包）CMBJ-2015-00004934-CG-0000091526.2.2. MGCF參數(shù)配置問題導致未接通中國移動通信集團內(nèi)蒙古有限公司2016年日常優(yōu)化服務框架合同（烏海業(yè)務區(qū)）OPER2016-02436.2.3. UE瞬間脫網(wǎng)案例分析中國移動北京公司2015-2017年五環(huán)外無線網(wǎng)絡日常優(yōu)化服務合同（第一比選包）CMBJ-2015-00004934-CG-0000091546.2.4. VOLTE參數(shù)設置導致eSRVCC無法切換中國移動通信集團內(nèi)蒙古有限公司2016年日常優(yōu)化服務框架合同（烏海業(yè)務區(qū)）OPER2016-02456.2.5. Volte功能特性設置導致被叫未接通中國移動北京公司2015-2017年五環(huán)外無線網(wǎng)絡日常優(yōu)化服務合同（第一比選包）CMBJ-2015-00004934-CG-0000091566.2.6. 智能網(wǎng)導致主叫未接通、被叫單通20S掉話問題陜西移動2015年第三方基礎優(yōu)化服務框架合同（電旗）OPER2015-03476.2.7. 目標小區(qū)故障導致SRVCC切換失敗2015年河北移動無線網(wǎng)絡基礎支撐服務采購合同WLWH2015030286.2.8. 二次注冊IP端口號不一致導致注冊失敗2015年河北移動無線網(wǎng)絡基礎支撐服務采購合同WLWH2015030296.2.9. VOLTE用戶前轉(zhuǎn)優(yōu)化2015年河北移動無線網(wǎng)絡基礎支撐服務采購合同WLWH20150302106.2.10. E-Nodeb參數(shù)設置錯誤導致接通時延較大湖南移動日常協(xié)優(yōu)服務合同（主用合同-北京電旗）CMHNBBCG2015-1-0067116.2.11. 核心網(wǎng)入Pool導致切換成功率下降陜西移動2014年第三方基礎優(yōu)化服務框架合同（北京電旗）SN(2014)0552126.2.12. 超級小區(qū)切換入失敗問題優(yōu)化提升中國移動北京公司2015-2017年五環(huán)外無線網(wǎng)絡日常優(yōu)化服務合同（第一比選包）CMBJ-2015-00004934-CG-00000915136.2.13. CSFB提升優(yōu)化2015年河北移動無線網(wǎng)絡基礎支撐服務采購合同WLWH20150302146.2.14. 北京LTE駐留比優(yōu)化中國移動北京公司2015-2017年五環(huán)外無線網(wǎng)絡日常優(yōu)化服務合同（第一比選包）CMBJ-2015-00004934-CG-000009151.1.1. 北京移動某區(qū)域CSFB提升優(yōu)化問題描述LTE優(yōu)化人員測試發(fā)現(xiàn)某地區(qū)同時出現(xiàn)CSFB通話結(jié)束后2G會回到4G室分頻點后再重選到4G宏站頻點，該問題較為異常，目前已經(jīng)對該問題進行信令側(cè)分析。問題分析正常信令：異常信令： 異常信令 正常信令當UE占用GSM網(wǎng)絡進行語音通話結(jié)束后，UE收到EnodeB下發(fā)的SIB1系統(tǒng)消息后向EnodeB發(fā)送TAU請求，并發(fā)起RRC連接請求，隨后EnodeB下發(fā)RRC建立鏈路指令，UE響應并發(fā)送RRC建立鏈路完成。正常情況下UE會使用與EnodeB建立完成的鏈路完成TAU過程。但上圖異常信令中RRC建立鏈路完成之后UE卻第二次收到了EnodeB下發(fā)RRC建立鏈路指令。隨后UE第一次上報Cell_List，上報情況如下： 異常占用頻點 正常占用頻點UE從GSM返回LTE后第一次上報Cell_List室分頻點變成了主服務小區(qū)，而宏站頻點變成了鄰區(qū)，其中室分小區(qū)RSRP=-113dBm，宏站小區(qū)RSRP=-95dBm，正常情況下UE會占用RSRP最強的小區(qū)。實施方案7月29日對室分問題連同G網(wǎng)人員一同進行處理，選取凱萊酒店室分場景進行測試，對G網(wǎng)小區(qū)40261、20421、30011、30012進行FR功能關閉后測試：處理前占用4G宏站站點撥測回落G網(wǎng)頻點占用G網(wǎng)小區(qū)回退4G站點CSFB回落時延備注福斯德-ZLH_251240261鐘鼓樓辦事處-ZLW_112.57s主叫福斯德-ZLH_251240261信合大樓-ZLW_110.707s主叫福斯德-ZLH_26430012鐘鼓樓辦事處-ZLW_14.61s被叫處理后福斯德-ZLH_251240261財貿(mào)廣場-ZLH_38.534s主叫福斯德-ZLH_26430012福斯德-ZLH_29.556s主叫福斯德-ZLH_26430012福斯德-ZLH_23.590s被叫調(diào)整措施UE占用宏站撥打（09:44:06）通話結(jié)束后G網(wǎng)占用頻點512鏈路釋放：UE占用頻點512回退且首先回退到室分信號（鐘鼓樓辦事處-ZLW_1）：CSFB回落時延（12.57s）：UE占用宏站撥打（09:44:50）通話結(jié)束后G網(wǎng)占用頻點512鏈路釋放：UE占用頻點512回退且首先回退到室分信號（信合大樓-ZLW_1）：CSFB回落時延（10.707s）：UE占用宏站接聽（10:14:47）通話結(jié)束后G網(wǎng)占用頻點64鏈路釋放：UE占用頻點64回退且首先回退到室分信號（鐘鼓樓辦事處-ZLW_1）：CSFB回落時延（4.61s）：效果對比UE占用宏站撥測（14:30:16）：通話結(jié)束后G網(wǎng)占用頻點512鏈路釋放：UE占用頻點512回退且回退到宏站信號（財貿(mào)廣場-ZLH_3）：CSFB回落時延（8.534s）：UE占用宏站撥測（10:38:36）：通話結(jié)束后G網(wǎng)占用頻點64鏈路釋放：UE占用頻點64回退且回退到宏站信號（福斯德-ZLH_2）：CSFB回落時延（9.556s）：UE占用宏站接聽（10:38:42）：通話結(jié)束后G網(wǎng)占用頻點64鏈路釋放：UE占用頻點64回退且回退到宏站信號（福斯德-ZLH_2）：CSFB回落時延（3.590s）：G網(wǎng)FR開關打開時，UE在附近有室分信號的情況下，占用宏站撥測通話結(jié)束后首先回落室分信號再切換到宏站信號，而G網(wǎng)FR開關關閉后得該問題得到解決。1、問題處理前CSFB回落時延（12.57s）、（10.707s）、（4.61s），處理后時延（8.534s）、（9.556s）、（3.590s）通過問題處理前后對比，主被叫CSFB回落時延都有明顯改善。、2、后續(xù)需要G網(wǎng)優(yōu)化人員對該問題全網(wǎng)性處理。案例合同關鍵頁1.1.2. MGCF參數(shù)配置問題導致未接通現(xiàn)象描述車輛烏海大學校園內(nèi)行駛，被叫UE占用海勃灣奧林匹克中心-NLHF-2（PCI=141、RSRP=-87.43 dbm、SINR=22.8），09:34:49.683奧體中心附近出現(xiàn)未接通。問題分析從LOG分析發(fā)現(xiàn)主被叫信令流程，在MO發(fā)送完IMS_SIP_INVITE-Request消息后，MT正常接收網(wǎng)絡側(cè)轉(zhuǎn)發(fā)的IMS_SIP_INVITE-Request，并上發(fā)IMS_SIP_INVITE-Trying 100消息確認請求處理成功。在上發(fā)IMS_SIP_INVITE 183會話消息后，網(wǎng)絡側(cè)下發(fā)LTE NAS-Deactivate EPS bearer context request，釋放QCI1專用承載，釋放原因為ESMCause = (36)Regular deactivation。隨后網(wǎng)絡側(cè)下發(fā)LTE RRC-RRC Connection Release，導致本次通話未接通。經(jīng)查詢，確認核心網(wǎng)側(cè)主叫側(cè)SBC概率性不轉(zhuǎn)發(fā)被叫側(cè)發(fā)送的183消息導致。解決措施核心網(wǎng)側(cè)處理：MGCF做參數(shù)調(diào)整適配。效果對比MGCF做參數(shù)調(diào)整適配，未接通問題解決。案例合同關鍵頁1.1.3. UE瞬間脫網(wǎng)案例分析問題描述某客戶反饋在使用4G手機通話后，會偶發(fā)瞬間脫網(wǎng)2秒左右，然后再正常駐留到4G網(wǎng)絡。問題發(fā)生地點不固定，與地理位置無關。問題分析（1） 排查無線側(cè)參數(shù)通過核查3G、4G網(wǎng)絡的無線側(cè)3G/4G互操作參數(shù)、4G無線側(cè)鑒權加密參數(shù)，未發(fā)現(xiàn)參數(shù)配置問題，并且也無影響業(yè)務的告警出現(xiàn)。（2） 排查終端問題咨詢客戶得知，客戶使用的基本是iphone6手機，在通話后會偶發(fā)性出現(xiàn)手機瞬間脫網(wǎng)2-3秒，然后正常駐留4G。在前期的終端摸底測試中，已經(jīng)知道iphone6終端比一般終端信號靈敏度低5dB-10dB。因此，安排測試人員在客戶投訴較多的區(qū)域周邊片區(qū)，同時攜帶iphone6手機和Q801手機進行拉網(wǎng)測試和定點CQT測試。通過測試3G-4G重選、單發(fā)業(yè)務CSFB、并發(fā)業(yè)務CSFB等來模擬4G用戶行為。協(xié)調(diào)3G側(cè)后臺人員同步對測試手機進行3G側(cè)的IMSI和投訴用戶的IMSI信令跟蹤。通過大量的測試，成功地復現(xiàn)了手機偶發(fā)瞬間脫網(wǎng)問題。該問題偶發(fā)，和手機終端類型無任何關系。（3） 分析信令前臺信令分析（路測信令）從前臺測試log可以看出，在信號較好，RSRP為-84dbm的情況下，仍然出現(xiàn)了手機脫網(wǎng)現(xiàn)象，從信令上可以看到TAU被拒、Attach被拒，原因是Network Failure，如下圖所示。后臺信令分析（基站側(cè)信令）通過信令分析可以發(fā)現(xiàn)問題出在用戶從3G回LTE網(wǎng)絡的時候TAU被拒、Attach被拒，導致UE瞬間脫網(wǎng)，被拒的原因是DNS解析失?。ㄈ缦旅鎺讉€圖所示），DNS解析失敗說明DNS解析SGW有問題，需要DNS側(cè)進一步配合排查。TAU失?。篋NS解析失?。海?） 核查DNS參數(shù)從3G側(cè)給出DNS參數(shù)核查結(jié)果，可以看出DNS多配置了2個MME，如下圖所示。優(yōu)化方案MME查詢DNS按照UDP協(xié)議，最多不超過512字節(jié)，返回結(jié)果最多帶4條記錄，超過4條記錄就會被丟棄。其中，返回結(jié)果所帶的記錄至少要包含一條SGW的解析，終端才能正常返回4G。當前在DNS的配置中配置了4個MME，這就存在一定概率返回的結(jié)果中所帶4條記錄都是MME，此時沒有SGW解析，從而導致用戶脫網(wǎng)。這就是用戶小概率脫網(wǎng)的原因。咨詢DNS側(cè)，確認是由于MME組POOL時，在DNS側(cè)配置了冗余數(shù)據(jù)導致概率性出現(xiàn)脫網(wǎng)。效果對比從配置來看：MME12的MMEC為8C，MME13的MMEC為8E。DNS多配置了8D和8F，如下圖所示。需要DNS刪除8D和8F的配置即可解決。DNS側(cè)修改參數(shù)后，安排測試人員現(xiàn)場4個多小時反復測試驗證，未發(fā)現(xiàn)手機偶發(fā)脫網(wǎng)問題。詢問之前發(fā)生問題區(qū)域的客戶，反饋未再發(fā)現(xiàn)脫網(wǎng)現(xiàn)象。案例合同關鍵頁1.1.4. VOLTE參數(shù)設置導致eSRVCC無法切換現(xiàn)象描述測試人員在室內(nèi)某處做eSRVCC測試項驗證，主叫UE占用海勃灣酒廠辦公樓-NLHF-2（PCI=356、RSRP=-121.5dbm、SINR=-5.3），在15:07:30.569時間出現(xiàn)eSRVCC不切換，導致本次通話掉話。問題分析回放LOG發(fā)現(xiàn)，MO在PCI 356電平在-105.25 dBm，SINR 3.9情況下發(fā)起VoLTE語音呼叫(即發(fā)送INVITE消息)，MT在PCI 電平在-108.93 dBm，SINR 8.1情況下響應VoLTE語音呼叫(即發(fā)送INVITE Trying消息)。從LOG分析發(fā)現(xiàn)主被叫呼叫信令流程正常，通話正常接通。此時MT向室內(nèi)移動，在RSRP-116 dBm的情況時，MT開始持續(xù)上發(fā)B2事件。在多次上發(fā)B2事件后，卻未收到網(wǎng)絡下發(fā)的切換命令，最終導致本次通話掉話。初步懷疑VOLTE參數(shù)設置不合理，導致eSRVCC無法切換。問題定位1、由于本次通話滿足eSRVCC門限卻未發(fā)生切換，需要核查eSRVCC鄰區(qū)LNADJG、LNHOG和LNREG，以及切換觸發(fā)門限及判決門限等參數(shù)是否設置合理。經(jīng)核查eSRVCC門限參數(shù)設置合理。2、從核心網(wǎng)的信令分析結(jié)果看，eSRVCC eMSC收到PS到CS切換請求后，通知目標MSC準備CS無線承載資源，然后發(fā)起Session Transfer過程。然而此時無線再次發(fā)handover cancel導致流程失敗，原因有可能是msc 回響應超時。發(fā)起handover cancel原因值tS1relocprep-expiry（9）,tS1relocprep是eNB的定時器。從消息上看，這個定時器應該是1s。該參數(shù)應為3s。優(yōu)化方案1、核查核查eSRVCC鄰區(qū)LNADJG、LNHOG和LNREG，以及切換觸發(fā)門限及判決門限等參數(shù)：4G A2測量事件（觸發(fā)異系統(tǒng)測量）本系統(tǒng)判決門限（含門限遲滯值）-110dBm門限遲滯值hysteresis1dB觸發(fā)時間timetotrigger320ms4G B2測量事件本系統(tǒng)判決門限（含門限遲滯值）-116 dBm異系統(tǒng)判決門限（含門限遲滯值）-100 dBm門限遲滯值hysteresis1dB觸發(fā)時間timetotrigger320ms2、修改tS1relocprep定時器為3s。效果對比修改tS1relocprep定時器為3s后，該問題解決。在日常優(yōu)化過程中，注意加大對全網(wǎng)VOLTE相關參數(shù)的核查力度，注意對新開站點的參數(shù)整體把控，后期優(yōu)化過程中避免出現(xiàn)因參數(shù)設置不合理而導致eSRVCC切換失敗而掉話。案例合同關鍵頁1.1.5. Volte功能特性設置導致被叫未接通問題描述烏海二月份Volte摸底測試過程中，車輛沿新華南路由北向南行駛，被叫占用JYG01Orenminyinhang_1小區(qū)信號（頻點：38400；PCI：78），RSRP電平值為-86dBm左右，SINR值良好13dB；測試過程中被叫上發(fā)IMS_SIP_INVITE 487，被叫終端觸發(fā)Terminating Volte Abnormal，出現(xiàn)未接通事件。被叫測試圖例如下：問題分析基于被叫出現(xiàn)的未接通事件，被叫在09:36:58.050時刻觸發(fā)IMS_SIP_INVITE 183進程，隨即在09:36:58.098收到網(wǎng)絡側(cè)的IMS_SIP_CANCAL消息，同時刻查看主叫信令，觸發(fā)相應的流程一致，主被叫信令流程圖如下：查看被叫IMS_SIP_CANCAL消息的具體原因如下：消息Content = Reason: SIP;cause=503;text=PT: ASR: INSUFFICIENT_BEARER_RESOURCES；表示承載資源不足(503：SIP服務器故障不能完成對正確消息的處理)，需要終止當前會話，隨后被叫上發(fā)IMS_SIP_INVITE 487 (487：Request Terminated，請求終止)；既然是“承載資源不足”導致，那我們看看主被叫承載建立的情況；1）主叫承載建立2）被叫承載建立綜合主被叫承載的建立可以看出，主叫已正常建立了SRB1+SRB2+2DRB(QCI=9;QCI=5)，但是建立第三個DRB（QCI=1）的時候出現(xiàn)異常；而被叫也是一樣，被叫就有沒建立DRB(QCI=1)的承載；由于Volte語音的接續(xù)過程必需要建立在承載之上，最終由于QCI=1的專用承載未成功建立，而導致出現(xiàn)“承載資源不足”導致的IMS_SIP_INVITE 487；呼叫流程終止；在測試過程中發(fā)現(xiàn)，在“JYG01Orenminyinhang”附近出現(xiàn)較多次的未接通、掉話等異常事件，出現(xiàn)多次“RRC Connection Reestablishment Reject”；最終鎖定“JYG01Orenminyinhang”站點存在問題，且懷疑該站點VOLTE功能性參數(shù)設置有問題；a) 確認站點無故障，小區(qū)狀態(tài)正常；b) 核查確認該站點及周邊均無干擾；c) 核查確認該站點鄰區(qū)，發(fā)現(xiàn)該站點與周邊存在鄰區(qū)漏配現(xiàn)象；該站點在測試前期出現(xiàn)過站點故障，更換了基帶單板，基站配置數(shù)據(jù)重做，才出現(xiàn)鄰區(qū)漏配的現(xiàn)象；d) 鄰區(qū)添加后現(xiàn)場復測，仍然出現(xiàn)未接通現(xiàn)象；e) 檢查該基站的VOLTE功能性參數(shù)配置，發(fā)現(xiàn)該站點相關參數(shù)均為默認配置，且VOLTE的功能性開關未開啟，如下：優(yōu)化方案開啟“JYG01Orenminyinhang”站點VOIP特性設置，依據(jù)集團VOLTE參數(shù)進行調(diào)整；MO 名稱參數(shù)IDVoIP開關EutranVoipSupportSwitchROHC參數(shù)RohcSwitchHighestModeProfilesRLC/PDCP參數(shù)RlcPdcpParaGroupIdRlcModeDRX參數(shù)組DrxParaGroupIdEnterDrxSwitchLongDrxCycleOnDurationTimerDrxReTxTimerDrxInactivityTimereSRVCC參數(shù)HoModeSwitchAllInterRatHoCommGroupIdInterRatHoA2ThdRsrpInterRatHoA1A2HystInterRatHoA1A2TimeToTrigInterRatHoA1ThdRsrpInterRatHoGeranB1HystInterRatHoGeranB1TimeToTrigInterRatHoGeranB1Thd優(yōu)化效果在完成“JYG01Orenminyinhang”站點VOIP特性參數(shù)設置后，對“JYG01Orenminyinhang”站點附近進行區(qū)域拉網(wǎng)測試，主被叫RB承載建立正常，均未出現(xiàn)未接通及掉話等異常事件；總體從前臺測試，分析，定位，后臺配合，逐步排查，最終確認問題根源；建議后續(xù)的工作流程，先總體后局部，保障現(xiàn)網(wǎng)所有站點的鄰區(qū)的合理性、參數(shù)的一致性，避免問題的案例合同關鍵頁1.1.6. 智能網(wǎng)導致主叫未接通、被叫單通20S掉話問題問題描述測試車輛由東向西行駛，UE占用車輛檢測站_2(PCI=273)小區(qū)，RSRP=71dB，SINR=23dB，無線環(huán)境良好，主叫UE在15：54：56.343出現(xiàn)未接通事件、被叫在2016-04-19 15:55:21產(chǎn)生掉話。問題分析測試車輛在來遠路西段由東向西行駛，占用車輛檢測站_2小區(qū)，PCI=273，RSRP -74左右，SINR22，無線環(huán)境正常。主叫UE在第一次發(fā)送UPDATE請求后，被叫已有時回應UPDATE ok消息，并且上發(fā)Ringing消息；但主叫并收收到Ringing消息，而是先后兩次收到系統(tǒng)下發(fā)的UPDATE消息，導致未接通事件。被叫15:54:54.699振鈴后，主叫未收到IMS_SIP_INVITE-Ringing消息，15:54:56.343核心網(wǎng)下發(fā)中斷請求。20秒后，15:55:16.386被叫主動上發(fā)IMS_SIP_BYE-Request，被叫統(tǒng)計為掉話。炎強截圖：由上圖可以看出，SCPAS1返回給CSCF100trying后，CFCF01沒有繼續(xù)向SBC02下發(fā)100trying，而是直接丟失信令1分鐘導致未接通事件。網(wǎng)絡結(jié)構圖：從網(wǎng)絡結(jié)構看信令在IMS系統(tǒng)上傳遞后，還會經(jīng)過業(yè)務平臺傳遞，從而導致時延增加，信令丟失的概率變大。測試時延分析：測試日期呼叫建立時延(s)2016/2/222.142016/3/172.762016/3/192.732016/4/175.882016/4/197.432016/4/222.06從以往數(shù)次測試情況結(jié)果對比分析發(fā)現(xiàn)，測試呼叫建立時延從2月份的2.14s增加到4月份的7.43s，期間測試卡開啟過智能網(wǎng)業(yè)務，然后跟蹤主叫信令確定炎強平臺存在智能網(wǎng)網(wǎng)元。4月22日更換未開啟智能網(wǎng)業(yè)務測試卡后，時延從7.43s降低到2.79s，拉網(wǎng)測試也未出現(xiàn)此類主叫未接通，被叫單通20S后掛機現(xiàn)象。實施方案開啟智能網(wǎng)業(yè)務會增加呼叫建立時延，且智能網(wǎng)網(wǎng)元容易導致信令丟失，易產(chǎn)生異常事件?，F(xiàn)階段建議關閉。效果對比在關閉掉智能網(wǎng)之后，主叫未接通，被叫單通20S后掛機現(xiàn)象在拉網(wǎng)測試中沒有復現(xiàn)，時延從7.43s降低到2.79s。案例合同關鍵頁1.1.7. 目標小區(qū)故障導致SRVCC切換失敗問題描述SEQ平臺上提取每天的切換失敗次數(shù)，發(fā)現(xiàn)4月29號切換失敗次數(shù)猛增，如下所示： 對切換失敗原因分析發(fā)現(xiàn)，原因值為Handover/Relocation cancelled by source system的切換失敗次數(shù)明顯增加，4月28號為23次，4月29號增加到247次，如下所示：從SEQ平臺提取4月29號的詳單，發(fā)現(xiàn)是Top用戶1583395* 和1383310* 占用LTE小區(qū)（政法學院3_1）后做語音業(yè)務，切換到GSM小區(qū)SJGH0842政法學院3_0或SJGH0842政法學院3_1失敗，累計失敗214次，集中在13點到14點半之間。進一步分析發(fā)現(xiàn)，剔除29號切換失敗后，多個LTE小區(qū)向同一GSM基站(政法學院3)發(fā)起切換，但全部失敗，且持續(xù)較長時間，切換統(tǒng)計如下所示：日期LTE小區(qū)GSM小區(qū)切換請求次數(shù)切換失敗次數(shù)4月21號-5月4號SJXIH1128政法學院新校區(qū)-HLHF_1SJGH0842政法學院3_136364月21號-5月4號SJXIH0533政法學院3-HLHF_1SJGH0842政法學院3_048484月21號-5月4號SJXIH0533政法學院3-HLHF_1SJGH0842政法學院3_19696Top小區(qū)地理位置：問題分析通過SEQ平臺對切換Top小區(qū)分析發(fā)現(xiàn)，向GSM基站SJGH0842政法學院3切換的原因全部是Handover /Relocation Failure with Target system，如下所示：對其中一條切換失敗信令分析如下：2016-05-05 22:50:11.765，LTE終端發(fā)起HANDOVER REQUIRED請求，2016-05-05 22:50:11.786 MME向MSC發(fā)起SRVCC PS TO CS REQUEST，向GSM小區(qū)SJGH0842政法學院3_1發(fā)起切換。2016-05-05 22:50:12.115 MSC向MME發(fā)送SRVCC PS TO CS RESPONSE(Cause:73),提示GSM小區(qū)Noresourcesavailable，導致切換失?。?016-05-05 22:50:14.565 LTE終端重新發(fā)起HANDOVER REQUIRED請求，GSM切換目標小區(qū)為SJDHM724政法新校區(qū)3_0，隨后切換成功。 對多條到GSM小區(qū)SJGH0842政法學院3_1的切換信令分析發(fā)現(xiàn)， 全部提示Cause:73，GSM小區(qū)Noresourcesavailable導致切換失敗，緊接著切換到周邊其他GSM小區(qū)且切換成功。問題共性明顯，一般情況下ESRVCC切換失敗原因為Cause:73的，大多由于2G鄰區(qū)定義錯誤或2G無線原因造成，定位分析如下： 第一步，核查LTE側(cè)GSM小區(qū)定義信息，全部正確；第二步，核查GSM小區(qū)負荷情況，業(yè)務量低，無擁塞；第三步，核查GSM小區(qū)干擾情況，無干擾；第四步，核查GSM基站告警情況，無告警。第五步，核查GSM基站整體指標，發(fā)現(xiàn)3個小區(qū)接入異常，本系統(tǒng)切換正常，但話務量較低，統(tǒng)計4月24號到5月4號日均值，如下表所示：GSM小區(qū)名稱日均呼叫占用請求日均呼叫占用成功日均TCH話務量日均無線切換失敗次數(shù)SJGH0842_01115.519SJGH0842_11126.469SJGH0842_2668.667 GSM基站有本系統(tǒng)切換，但接入存在問題，提交GSM側(cè)安排人員現(xiàn)場測試，對問題進一步分析；同時提交核心網(wǎng)核查數(shù)據(jù)是否配置正確。影響范圍：出現(xiàn)概率較大，影響用戶感知優(yōu)化方案由于GSM 900基站SJGH0842政法學院3接入問題，ESRVCC無法切換成功，暫時刪除到該基站的鄰區(qū)關系，可以由同覆蓋GSM 1800頻段基站SJDH0842政法學院3接續(xù)，等GSM基站處理好后再重新添加鄰區(qū)關系優(yōu)化效果 通過鄰區(qū)優(yōu)化SRVCC切換失敗事件大大減少。案例合同關鍵頁1.1.8. 二次注冊IP端口號不一致導致注冊失敗問題描述在利用SEQ平臺對現(xiàn)網(wǎng)用戶的IMS注冊成功率進行分析時，發(fā)現(xiàn)失敗原因值為”400 Bad Request”的占比較高為37.4%，嚴重影響整體的IMS注冊成功率。用戶無法成功注冊IMS時將進行CSFB到GSM網(wǎng)絡通話，無法使用VOLTE進行語音業(yè)務，影響用戶感知問題分析通過SEQ平臺的信令配合功能可直接定位到出現(xiàn)錯誤的失敗信令，失敗信令的詳細解釋為“Sipkeyparameterinvalid”SIP關鍵參數(shù)無效；正常的IMS初始注冊信令流程如下：1.UE在QCI 5的默認承載上用于SIP信令向IMS發(fā)送注冊請求； 2.經(jīng)過S-CSCF分配后注冊請求送達S-CSCF；3.S-CSCF向HSS下載鑒權數(shù)據(jù)后給UE反回401消息，包含鑒權元素；4.UE重構注冊消息，按照初始注冊消息的路徑發(fā)給IMS；5.經(jīng)過S-CSCF查詢、簽約數(shù)據(jù)下載后，給UE反饋200 OK響應,表示初始注冊成功；根據(jù)SIP協(xié)議規(guī)定，終端發(fā)初次注冊請求后S-CSCF 會返回 401（未授權）響應要求終端進行認證，則終端用戶將發(fā)送第二個 REGISTER 請求，第二個請求包含相同的有關注冊信息，并經(jīng)過的路由與第一個 REGISTER 的路由完全相同。但是第二個 REGISTER 產(chǎn)生一個新的Cseq 號碼、branch 參數(shù)以及一個新的 From 標簽，并且該 REGISTER 請求會帶入新的安全認證標簽信息。對比異常用戶第一次和第二次發(fā)送的REGISTER信令消息中的“MessageHeader”信息，發(fā)現(xiàn)前后callid一致，用戶名一致，Cseq信息不一致。二次注冊也同時產(chǎn)生了新的branch參數(shù)和新的From tag;但對比時還發(fā)現(xiàn)兩條注冊信息的頭消息中的PORT-C、PORT-S、SPI-C、SPI-S端口配置信息不一致；二次注冊的CALLID相同，但是IP端口號不一致，導致關鍵SIP信息錯誤IMS返回“400 Bad Request”注冊失?。欢鴮Ρ日５亩巫孕帕睿嚓P端口信息是一致的詳情如下：初步推斷由于終端版本或芯片原因?qū)е掳l(fā)送二次注冊時端口號配置錯誤引發(fā)注冊失敗，出現(xiàn)該問題的終端類型99%為IOS終端，其他終端占比為1%。優(yōu)化方案 與終端場景溝通，升級版本優(yōu)化效果終端升級后，指標ok。案例合同關鍵頁1.1.9. VOLTE用戶前轉(zhuǎn)優(yōu)化問題描述A打B，B轉(zhuǎn)C，C轉(zhuǎn)D，A與D接通。ABCD均為VOLTE號碼，前轉(zhuǎn)次數(shù)過多，排查后出現(xiàn)后續(xù)問題，導致未接通。測試號：AB題分析A打B，B轉(zhuǎn)C，C轉(zhuǎn)D，A與D接通。消息中可以看到volte用戶進行了二次前轉(zhuǎn)，而集團規(guī)范要求前轉(zhuǎn)一次，與集團規(guī)范不符。（原因是VOLTE用戶開戶默認前轉(zhuǎn)次數(shù)為5次）實施方案ATS SGP側(cè)執(zhí)行如下腳本可將用戶前轉(zhuǎn)次數(shù)修改為1。USE ME:NAME=對應ATS網(wǎng)元;MOD_MSR:IMPU=tel:+8614745142724,PATH=/simservs/complete-communication-diversion/operator-communication-diversion/total-number-of-diversions-for-each-communication,SERVICEDATA=1;優(yōu)化效果采用以上處理方式解決將前轉(zhuǎn)次數(shù)設置為1時，又出現(xiàn)如下問題： VOLTE用戶在2/3G情況下，會出現(xiàn)與華為volte用戶接續(xù)失敗問題。案例合同關鍵頁1.1.10. E-Nodeb參數(shù)設置錯誤導致接通時延較大問題描述湖南移動某地市在進行VOLTE例行測試過程中，測試設備雖注冊在IMS網(wǎng)元上進行起呼，卻進行CS FB呼叫，導致接通時延過長。測試號碼主叫測試號碼被叫題分析經(jīng)過分析定位，在輪滑廣場進行定點CQT測試時發(fā)現(xiàn)該出無法進行volte正常通話，進行CSFB接通。Pioneer信令分析：14:31:53.418時，主叫測試終端占用YL0462_002_雙雙鴨輪滑廣場-HLH_3進行上發(fā)INVITE消息，無線環(huán)境良好（RSRP=-81.50，SINR=26.1），并于14:31:53.559收到網(wǎng)絡側(cè)回復INVITE 100消息，此時信令消息正常，14:31:53.715時收到網(wǎng)絡側(cè)下發(fā)的異常信令INVITE 503消息，內(nèi)含“Content = Warning: 399 00000.00000.A.005.406.228.255.255.00045.00000002 Media Bearer Lost”造成VOLTE起呼失敗，進行CS FB業(yè)務測試；查看被叫信令流程，被叫于14:32:00.298收到網(wǎng)絡側(cè)下發(fā)的INVITE消息，并在同一時間上發(fā)INVITE 100回復，但收到網(wǎng)絡側(cè)下發(fā)的CANCEL消息，查看信令內(nèi)容依然是Media Bearer Lost；對主被叫終端建立承載信令進行細致分析查看，以主叫為例，在14:31:53.418時建立RRC連接，并進行SRB=1的信令承載，于14:31:53.481進行RRC Connection Reconfiguration，內(nèi)含SRB=2的信令承載建立與3條DRB業(yè)務承載建立，根據(jù)現(xiàn)網(wǎng)Enodeb配置的eNodeB 觸發(fā)Polling的PDU數(shù)據(jù)量門限(字節(jié))= “無限長“可以看出drb-Identity=2為QCI=5的承載，此時信令流程正常，但在主叫收到網(wǎng)絡側(cè)回復的INVITE 100后并沒有建立QCI=1的VOLTE專用語音業(yè)務承載，導致無法進行VOLTE業(yè)務，造成終端進行CS FB業(yè)務； SEQ信令跟蹤分析：由于radioNetwork:not-supported-QCI-value (37)導致id-E-RABFailedToSetupListBearerSURes，以及Cause : System failure (72) 導致的Create Bearer Response失敗，造成VOLTE無法正常進行續(xù)兒進行CSFB。解決方案1. 確認站點無故障，小區(qū)狀態(tài)正常；2. 檢查業(yè)務無 線環(huán)境，并進行干擾排查，周圍無線環(huán)境良好，不存在外部干擾及內(nèi)部干擾；3. 檢查手機狀況及手機軟件版本是否正確，測試終端功能正常，軟件版本3.591403.1；4. 經(jīng)過核查，該問題站點于之前告警處理運維部門做過E-NODEB基站版本還原處理，導致部分功能開關處于關閉狀態(tài)，經(jīng)進一步核查發(fā)現(xiàn)VOIP能力開關為關閉狀態(tài)，修改后復測正常，問題得以解決。優(yōu)化效果 文件名主叫起呼時間主叫結(jié)束時間呼叫類型代碼呼叫類型呼叫結(jié)果振鈴時長呼叫建立時長通話時長測試1_0419-143131126_UE12015年4月19日2015年4月19日2VoLTESuccess4.463 9.343 193.173 測試1_0419-143131126_UE12015年4月19日2015年4月19日2VoLTESuccess14.406 19.264 204.322 測試1_0419-143131126_UE12015年4月19日2015年4月19日2VoLTESuccess3.292 8.087 33.630 文件名主叫起呼時間主叫結(jié)束時間呼叫類型代碼呼叫類型呼叫結(jié)果振鈴時長呼叫建立時長通話時長調(diào)整后_0421-150936582_UE12015年4月21日2015年4月21日2VoLTESuccess0.000 2.162 95.456 調(diào)整后_0421-150936582_UE12015年4月21日2015年4月21日2VoLTESuccess0.000 3.711 95.672 調(diào)整后_0421-150936582_UE12015年4月21日2015年4月21日2VoLTESuccess0.000 3.704 95.591 案例合同關鍵頁1.1.11. 核心網(wǎng)入Pool導致切換成功率下降問題概述監(jiān)控指標發(fā)現(xiàn)全網(wǎng)同頻切換成功率從2月2號惡化嚴重，同頻切換成功率從99.8%下降到99.0%左右。問題分析 全網(wǎng)同頻切換成功率惡化0.8%，分析切換失敗原因：1、核查全網(wǎng)告警：發(fā)現(xiàn)全網(wǎng)無新增告警且基站運行狀態(tài)正常，排除告警原因?qū)е隆?、核查參數(shù)配置：無線側(cè)未進行參數(shù)修改，排查參數(shù)原因?qū)е隆?、是否存在重大操作：存在核心網(wǎng)入Pool操作，是否影響指標需進一步核查。3、是否存在TOP小區(qū)：存在TOP小區(qū)。 分析TOP小區(qū)FH南崗隆馬特-21指標如下：切換成功率在2月3日零時開始下降 從一對一切換指標上可以看出FH南崗隆馬特-21并非與所有小區(qū)切換都失敗，失敗原因為目標小區(qū)回復切換準備失敗消息導致切換出準備失敗。從切換失敗的時間點可以初步判斷問題發(fā)生在2月3日0點與入Pool時間點吻合。跟蹤FH南崗隆馬特X2和S1接口信令，X2接口信令失敗原因為未知的MME Code 按照流程X2切換失敗后會進行S1切換，但是問題小區(qū)S1切換也失敗，失敗原因為ho-failure-in-target-EPC-eNB-or-target-system。 對比問題小區(qū)X2切換成功與失敗信令發(fā)現(xiàn)切換目標基站相同，但是有成功也有失敗。成功時MME Code為192，失敗時MME Code為196。 問題小區(qū)S1配置S1接口標識S1接口CP承載號核心網(wǎng)的相對容量3173460-01-24320-194,460-01-24320-19540460-01-24320-192,460-01-24320-1935174460-01-24320-196,460-01-24320-1976175460-01-24320-198,460-01-24320-199 切換目標小區(qū)S1配置S1接口標識S1接口CP承載號服務核心網(wǎng)的全局唯一標識00460-01-24320-192,460-01-24320-193 可以看出問題小區(qū)存在4條S1（已經(jīng)入Pool），切換目標小區(qū)1條S1（未入Pool）。由于源eNodeB是在pool內(nèi)的，而目標eNodeB不在pool內(nèi)，eNodeB所在MME認為切換是跨MME的，但是目標MME中有源eNodeB信息，認為是本MME內(nèi)的切換，兩個MME對切換的判斷是不一致的，所以會切換失敗。通過上述分析問題小區(qū)切換失敗主要由于目標基站未入Pool導致。解決方案 基站入pool調(diào)整。效果驗證2月8日目標基站入Pool后切換指標恢復正常。1、對于入Pool的操作，建議同一個TAC統(tǒng)一操作，同一TAC不要分多次否則一定會造成切換失敗2、由于兩個TAC間是否有X2，已經(jīng)組pool的TAC下的小區(qū)給未組pool的小區(qū)發(fā)送X2 prepare的時候，會帶上Pool內(nèi)其他MME的MME Code，但是未組pool TAC下的小區(qū)并沒有和這些MME相連，肯定會拒掉的，完全組pool后會正常。案例合同關鍵頁1.1.12. 超級小區(qū)切換入失敗問題優(yōu)化提升問題描述在2.2期工程設計批復的要求下需要對不符合設計批復的室分小區(qū)進行合并，在2015年10月份完成對工商學院、科技大學、博文職業(yè)技術學院、旅游學院共4所高校的超級小區(qū)合并工作，在超級小區(qū)合并后周邊宏站對室分小區(qū)進行切換時出現(xiàn)大量的切換準備失敗次數(shù)，由下表可知在10月份切換準備失敗次數(shù)占切換失敗總次數(shù)的20.34%，而宏站對高校室分問題占切換準備失敗次數(shù)的43.39%，此問題對切換成功率指標造成了嚴重的影響。統(tǒng)計類型10月份指標明細切換失敗次數(shù)5147657切換準備失敗次數(shù)1046883室分站點切換準備失敗次數(shù)454223切換準備失敗問題占比20.34%室分站點問題占比43.39%問題分析無線環(huán)境測試卡倫工商學院西南1小區(qū)向工商學院5號公寓切換對的切換準備成功率僅20%左右，因此重點對工商學院內(nèi)進行了相關測試。下圖為工商學院內(nèi)各室分的分布情況：通過現(xiàn)場測試發(fā)現(xiàn)，該學校的宿舍樓覆蓋場景較為特殊，宿舍樓道及宿舍外圍墻體均為落地窗，導致室分信號外泄嚴重，各宿舍樓之間道路均由室分覆蓋，宏站與室分鄰區(qū)配置不全，導致校區(qū)內(nèi)多處出現(xiàn)弱覆蓋脫網(wǎng)現(xiàn)象，如下圖：通過對鄰區(qū)關系的完善和對周邊宏站的RF優(yōu)化調(diào)整，該校園內(nèi)覆蓋問題得到明顯改善，對比測試如下圖：無線環(huán)境優(yōu)化前：無線環(huán)境優(yōu)化后：在無線環(huán)境良好的情況下對吉林工商學院5號公寓周邊進行現(xiàn)場測試，在測試過程中發(fā)現(xiàn)ENB已下發(fā)了A3事件的測量后UE不斷在發(fā)送測量報告，如下圖：由于前臺測試軟件看不到到X2及S1口信令，因此需要與后臺配合進行信令跟蹤及分析。信令跟蹤及分析對卡倫工商學院西南1小區(qū)進行切換對指標統(tǒng)計，發(fā)現(xiàn)此鄰區(qū)關系僅在S1切換準備過程中失敗，X2正常。S1切換整理流程如下圖所示：過程涉及源側(cè)eNB、目標側(cè)eNB及核心網(wǎng)。通過對源側(cè)及目標側(cè)小區(qū)同時進行信令跟蹤，并對獲取的信令進行分析。分析一段時間的信令，出現(xiàn)切換準備失敗的確實僅在S1切換中。如下圖所示：UE GID=316的UE在進行切換時，當源側(cè)小區(qū) 289329_1在完成判決后向核心網(wǎng)發(fā)送了handover required消息，但是卻收到了handover preparation failure消息。詳細的信令解析如下：源小區(qū) 289329_1在完成切換判決后，發(fā)送了handover required，解析出的目標小區(qū)eNB ID換算成十進制，確實為288417（吉林工商學院5號公寓）。至此證明此次切換源側(cè)eNB的判決和動作均正常。但是接下來，源側(cè)eNB卻收到了來自核心網(wǎng)的handover preparation failure消息，切換準備失敗，原因值為“未知的目標小區(qū)”如下圖紅框所示。也就是說核心網(wǎng)認為目標小區(qū)是未知的，判斷切換準備失敗。首先懷疑是否為目標小區(qū)的問題導致核心網(wǎng)作出此判斷，因此查看工商學院5號公寓作為目標小區(qū)時收到其UE GID450對應的信令，可以發(fā)現(xiàn)只要工商學院5號公寓能收到核心網(wǎng)發(fā)來的handover request消息，均做出了正確的判斷并回復了handover request acknowledge消息，可以證明只要目標小區(qū)能收到handover request，就能完成正常的切換準備后的響應。如下圖所示：綜上所述，通過對切換準備失敗的信令進行分析，及對目標小區(qū)的對比核查情況，目前可以判斷問題主要集中在核心網(wǎng)在收到handover required后，會認為目標小區(qū)未知而直接發(fā)送handover preparation failure。通過查看卡倫工商學院西南1小區(qū)的切換信令，可以看出對應的核心網(wǎng)為MME3，因此需要核心網(wǎng)的同事幫忙確認為何eNODEB在發(fā)起handover requ