葫蘆島-課題-研究呼叫時延問題驗證分析報告

葫蘆島呼叫時延問題分析處理報告——進一步驗證分析報告呼叫時延問題背景遼寧目前6個地市的呼叫時延均在9S左右，CS域核心網(wǎng)均為愛立信，華為RNC在愛立信核心網(wǎng)下呼叫時延為7.3S左右，華為的RNC配合華為的CS域核心網(wǎng)呼叫時延在6S左右，遼寧省華為和愛立信核心網(wǎng)接入?yún)^(qū)域存在較大差距。在日常測試中愛立信核心網(wǎng)接入?yún)^(qū)域的呼叫時延總體大于8S，影響客戶使用感知度，下表為7月份省公司第三方拉網(wǎng)測試的各個城市的接入時延情況。測試省份測試城市TD平均接入時長核心網(wǎng)廠家遼寧鐵嶺6.61華為阜新6.72朝陽6.75沈陽8.24愛立信盤錦8.28鞍山8.39遼陽8.59錦州8.94葫蘆島9.04撫順9.1大連9.16丹東9.86營口9.87本溪10.63查看大唐與華為的UE測試LOG，大唐與華為的整體呼叫流程一致，通過對比各個信令點時延直觀發(fā)現(xiàn)大唐的RB建立周期（UE收到RADIOBEARERSETUP到UE回復RADIOBEARERSETUPCOMPLETE）比華為長500ms左右.而愛立信的核心網(wǎng)的RAB指派是主被叫串行執(zhí)行，CN收到被叫CALLCONFIRM后先進行主叫RAB指派，主叫完成后進行被叫RAB指派，RAB主被叫串行處理機制導致在RB建立周期和華為拉出500MS*2=1s左右的差距，放大了RB建立時長對呼叫時延的影響。所以目前來看目前主要分為兩個問題：大唐RNC的RB建立時長較長愛立信核心網(wǎng)RAB指派為主被叫串行執(zhí)行進一步拉大主被叫的整體RAB建立時長呼叫時延問題分析大唐RNC的RB建立時長分析在TDD系統(tǒng)中，為了保證RNC和UE能夠同時使新配置參數(shù)生效，RNC在發(fā)送重配置命令時，一般會攜ActivationTime參數(shù)，設置新配置的生效時間。ActivationTime定義了操作和變化的生效時間，以CFN為參考時間，取值為[0,255]。終端接收到的重配置命令中攜帶ActivationTime參數(shù)，該參數(shù)如果不為“Now”，那么UE需要在ActivationTime時刻指定的TTI邊界完成配置轉(zhuǎn)換。RNC在計算這個時間時，需要獲得發(fā)送信令時刻的NowCFN，考慮處理時延（包括傳輸時延），通過如下公式計算出生效時刻：ActiveTime=（NowCFN+CfnOffset）%256CFNOffset與發(fā)送信令的長度，信令采用的速率和承載方式，已經(jīng)無線環(huán)境都有關(guān)系。CFNOffset的配置需要保證在激活時間超時前，網(wǎng)絡和UE的配置操作已經(jīng)完成，否則可能會導致UE無法正確獲得重配置信令，從而引起同步配置過程的失敗。但是，如果這個參數(shù)配置過大，有會延長配置過程的時間，影響呼叫時延等網(wǎng)絡性能指標?，F(xiàn)在系統(tǒng)中，對CFNOffset參數(shù)，是采用靜態(tài)配置方式處理的。采用靜態(tài)配置方式為了避免信令無法被UE正確收到，一般都采用了較保守的配置，是造成MMC呼叫過程中RB建立時間較長的主要原因。核心網(wǎng)RAB指派機制分析愛立信核心網(wǎng)RAB指派機制分析葫蘆島CS域核心網(wǎng)廠家為愛立信。下圖2為RNC側(cè)的CallTrace跟蹤，可以跟蹤到IU、UU、IUB口的信令流程。由圖表2中可以看到RNC向核心網(wǎng)回復被叫（UEID=32782）直傳消息CALLCONFIRMED后未收到核心網(wǎng)下發(fā)被叫的RAB指派消息，只收到核心網(wǎng)10：33：42對主叫UE的RAB指派消息，主叫UE（UEID=32781）RB建立完成后10:33:44RNC向核心網(wǎng)回復RABASSIGNMENTRESPONSE，核心網(wǎng)收到主叫的RABASSIGNMENTRESPONSE后對被叫進行RAB指派，可以看到目前網(wǎng)絡中主被叫的RAB指派消息是串行的，整個過程將會多出1個RAB指派周期，目前的RAB指派周期在2S左右，所以串行的RAB指派機制將會大幅加大接續(xù)時長的開銷。圖表SEQ圖表\*ARABIC2主被叫的RAB指派過程下圖3為相關(guān)的UU口信令截圖，可以看到主被叫的RB建立為串行執(zhí)行，主叫在10：30：24：328向網(wǎng)絡側(cè)上發(fā)RBSETUPComplete，被叫在10：30：24：421收到網(wǎng)絡側(cè)下發(fā)的的RBSETUP消息。圖表SEQ圖表\*ARABIC3UU口主被叫RB建立串行執(zhí)行下圖4、5為在新疆現(xiàn)場抓取的CallTrace跟蹤，CS域核心網(wǎng)為愛立信。圖表4為主叫，圖表5為被叫，在圖中可以看到，11：45：30主叫UE收到CN下發(fā)的CallProceeding消息進入等待，圖表5可以看到被叫UE在11：45：33CN收到被叫的CallConfirm消息進入等待，圖表4中主叫UE側(cè)RNC在11：45：33收到CN下發(fā)RABASSIGNMENTREQUEST，隨后在11：45：35完成RAB指派向核心網(wǎng)回復RABASSIGNMENTRESPONSE，圖標5中被叫UE在11：45：35收到CN下發(fā)的RABASSIGNMENTREQUEST，在11：45：37完成RAB指派，整個過程和遼寧現(xiàn)場的愛立信核心網(wǎng)RAB指派過程一樣，主被叫的RAB指派過程為串行，主被叫UE需要各自等待對方RAB指派周期，嚴重影響呼叫時延。圖表SEQ圖表\*ARABIC4主叫UE的CallTrace跟蹤圖表SEQ圖表\*ARABIC5被叫UE的CallTrace跟蹤愛立信的MMC的整理流程可以簡單描述如下：圖表SEQ圖表\*ARABIC6愛立信MMC流程圖中興核心網(wǎng)RAB指派機制分析下圖7為保定現(xiàn)網(wǎng)抓取的呼叫流程CallTrace跟蹤，CS域核心網(wǎng)廠家為中興?？梢钥吹街鞅唤械腞AB建立為并發(fā)執(zhí)行的，主被叫（主叫UEID=35961、被叫UEID=36016）在12：09：35同時收到核心網(wǎng)的RABASSIGNMENTREQUEST指派消息，在12：09：37幾乎同時完成RB建立，整個主被叫的RAB周期一共2S，將大幅節(jié)省呼叫時延開銷。圖表SEQ圖表\*ARABIC7主被叫RAB指派并行執(zhí)行中興整體MMC流程圖可以簡單描述如下：圖表SEQ圖表\*ARABIC8中興MMC流程圖華為核心網(wǎng)RAB指派機制分析下圖9為蘭州現(xiàn)網(wǎng)抓取的CallTrace跟蹤，核心網(wǎng)廠家為華為。由圖中可以看到，主叫UE（UEID=102020）在11：48：55收到CN下發(fā)的CallProceeding，500ms后RNC側(cè)立刻收到CN下發(fā)的針對主叫的RAB指派請求，800ms后被叫UE（UEID=100463）開始尋呼響應，主叫RB建立和被叫的尋呼響應為并發(fā)執(zhí)行的，在被叫的尋呼響應過程中主叫UE完成了RAB指派，隨后主叫UE等待被叫UE的RAB指派完成收到ALERTING完成起呼。整個過程同樣比愛立信核心網(wǎng)實現(xiàn)流程節(jié)省一個RAB指派周期，大幅縮短呼叫時延。圖表SEQ圖表\*ARABIC9華為RAB指派實現(xiàn)機制華為整體MMC流程圖可以簡單描述如下圖所示：圖表SEQ圖表\*ARABIC10華為MMC整體流程圖各個廠家愛核心網(wǎng)RAB指派機制總結(jié)各個廠家核心網(wǎng)的RAB指派機制在相關(guān)協(xié)議里面并沒有明確規(guī)定，所以各個廠家RAB指派機制不同直接影響到下掛RAN的呼叫時延，中興和華為的RAB指派機制整體比愛立信減少一次RAB建立時長，所以愛立信核心網(wǎng)大幅增加MMC情況下的呼叫時延。呼叫時延問題處理通過前期溝通了解到愛立信廠家暫時無法更改MMC情況下的RAB指派流程，所以在大唐公司導入遼寧移動需求,在40版本進行導入,在后臺支持的情況下，現(xiàn)場確定如下處理方法：RNC進行Uu接口消息瘦身，減少消息中不必要的可選IE減少消息長度，可配置更低信令傳輸時延，降低RB建立過程。目前RNC產(chǎn)品繼承TDR2000產(chǎn)品時對于尋呼處理內(nèi)部保留了小于100ms的保護時間，經(jīng)過評估該保護時間可以刪除該保護時間改善MMC呼叫試延。經(jīng)過試驗室測試可減少300ms~400ms之間。RNC側(cè)參數(shù)修改：SYNC算法和T2定時器在省公司的協(xié)調(diào)下計劃于7月中旬進行版本升級，升級后完成處理方法1、2.，隨后進行參數(shù)修改驗證，在修改前后進行拉網(wǎng)測試和KPI觀察，確保網(wǎng)絡的持續(xù)穩(wěn)定。RNC版本升級7月21日現(xiàn)場進行RNC版本升級為40版本，升級后進行測試對比升級前后的RadioBearerSetu消息的解析內(nèi)容，發(fā)現(xiàn)升級后RadioBearerSetup已經(jīng)不攜帶“rb-nformationAffectedList”，整個解碼消息較升級前大幅縮減。，如下圖所示:解碼消息原始文件列表：下表1為升級前，下表2為升級后升級后進行區(qū)域內(nèi)拉網(wǎng)測試，發(fā)現(xiàn)呼叫時延較升級前有大幅下降，測試呼叫時延為8.26S。試呼次數(shù)接通次數(shù)掉話次數(shù)PCCPCH總采樣點PCCPCHRSCP>=-95dBm&C/I>=-3采樣點DPCH總采樣點DPCHC/I>=-3采樣點接續(xù)時長(s)主叫被叫主叫被叫主叫被叫主叫被叫主叫被叫主叫被叫15151500608160626072600630122859301128598.2615151500608160626072600630122859301128598.26SYNC算法和T2定時器在40版本基礎上，進行現(xiàn)網(wǎng)參數(shù)優(yōu)化調(diào)整，呼叫時延的優(yōu)化主要涉及2個參數(shù)修改：修改小區(qū)中的SYNC算法參數(shù)修改RNC的T2定時器修改小區(qū)中的SYNC算法參數(shù)目前小區(qū)SYNC算法中SRB傳輸時延設置1.2秒，導致呼叫時延比其它廠家的呼叫時延多出1秒左右，經(jīng)實驗室初步測試減小這個時延可以減小呼叫接入時延，所以建議標參、ODG、OMC同步修改此值為0.46～0.60秒內(nèi)。由于早期的網(wǎng)絡覆蓋和終端的不穩(wěn)定，因此這些值取的比較大，盡量減少呼叫失敗的發(fā)生次數(shù)。目前的網(wǎng)絡覆蓋已經(jīng)很好，終端的穩(wěn)定性也有很大的提高，因此有條件修改這些參數(shù)。修改后，接續(xù)時延預計優(yōu)化600ms左右。現(xiàn)場SRB傳輸時延設置如下圖所示：現(xiàn)場將SRB傳輸時延由120幀修改為90幀，如下圖所示：修改T2定時器以前設計該定時器用于等待因為配置不支持等情況的UE失敗消息，實際使用中，因為分資源時已經(jīng)考慮了UE能力，所以已經(jīng)規(guī)避此種情況；而且，ToUEDelay里面包括T2的時長，如果T2長，ToUeDlay也需要相應增加。因此，這個參數(shù)對系統(tǒng)的影響不大，主要是起保護作用。修改方法如下圖所示：DT和KPI情況現(xiàn)場在8月16日完成RNC版本升級和參數(shù)修改，隨后進行拉網(wǎng)測試和KPI指標觀察確?，F(xiàn)場網(wǎng)絡情況的持續(xù)穩(wěn)定，通過路測發(fā)現(xiàn)呼叫時延有300MS左右改善，沒有異常事件發(fā)生，KPI指標也保持穩(wěn)定。路測情況修改現(xiàn)場組織進行測試，接續(xù)時長為：7.99S，較修改前有300MS左右改善，沒有異常事件發(fā)生。試呼次數(shù)接通次數(shù)掉話次數(shù)PCCPCH總采樣點PCCPCHRSCP>=-95dBm&C/I>=-3采樣點DPCH總采樣點DPCHC/I>=-3采樣點接續(xù)時長(s)主叫被叫主叫被叫主叫被叫主叫被叫主叫被叫主叫被叫1010000826299638244994457006291567962857.991010000826299638244994457006291567962857.99呼叫時延UU口信令截圖如下圖所示，可以看到RRCConnectionRequest到Alerting時延為7.64SKPI情況8月份正月指標情況如下圖所示，8月底的時候由于個別營業(yè)廳異常上網(wǎng)行為導致的指標波動外，其它時間KPI指標保持持續(xù)穩(wěn)定8月16日完成參數(shù)修改，觀察8月份平均指標情況，如下圖所示：PS掉話率指標在8月26日到8月30日指標異常是有由于個別營業(yè)廳異常上網(wǎng)行為導致，已經(jīng)確認處理。語音掉話率在8月31日指標異常也是由于個別營業(yè)廳異常上網(wǎng)行為導致，已經(jīng)確認處理。葫蘆島驗證情況在以上基礎上，葫蘆島于9月19日進一步修改小區(qū)的SYNC算法參數(shù)?，F(xiàn)場將SRB傳輸時延由120幀修改為60幀，如下圖所示：路測情況試呼次數(shù)接通次數(shù)掉話次數(shù)接續(xù)時長(s)主叫被叫主叫被叫21210007.3321210007.33呼叫時延UU口信令截圖如下圖所示，可以看到RRCConnectionRequest到Alerting時延為7.28s與9月10日葫蘆島3方測試呼叫時延進行對比各信令階段所用時間修改參數(shù)前時間/s修改參數(shù)后時間/s對比差異值/srrcConnectionRequest—Setup1.221.150.07Setup—CallProceed