VoLTE信令分析經(jīng)驗(yàn)交流-江蘇

1、VoLTE信令分析經(jīng)驗(yàn)交流 江蘇公司 網(wǎng)絡(luò)部 2015.102目錄目錄信令分析案例分享信令跟蹤手段介紹3江蘇省江蘇省VoLTEVoLTE網(wǎng)絡(luò)架構(gòu)網(wǎng)絡(luò)架構(gòu)n 蘇北7地市及南京使用蘇北大區(qū)華為IMS、華為EPC、華為+貝爾HSSn 蘇南5地市使用蘇南大區(qū)華為IMS、愛(ài)立信EPC、愛(ài)立信HSSn 全省共用華為EMSC、貝爾LDRA、ENUM/DNSn 全省無(wú)線設(shè)備廠家包括華為、貝爾、中興、愛(ài)立信4信令跟蹤手段介紹信令跟蹤手段介紹n目前江蘇VOLTE信令分析平臺(tái)尚未上線，VOLTE信令分析主要依靠各網(wǎng)元人工跟蹤信令l工具： SBC，CSCF&TAS，MGCF (對(duì)應(yīng)網(wǎng)元版本的iLMT客戶端)l

2、能力：可以單用戶跟蹤，最大可以跟蹤8個(gè)用戶，可以長(zhǎng)期跟蹤。l工具：MME, S-GW ,P-GW（對(duì)應(yīng)網(wǎng)元版本的iLMT客戶端）l能力：華為可以跟蹤信令面、用戶面，最大可以跟蹤4個(gè)用戶，不能長(zhǎng)期跟蹤。愛(ài)立信僅能跟蹤信令面。l工具：各廠家網(wǎng)管（江蘇無(wú)線廠家：華為、中興、愛(ài)立信、貝爾）l能力：網(wǎng)管僅支持單基站信令面消息跟蹤，跟蹤用戶面消息需要人工上站跟蹤。l工具：惠杰朗CDS、鼎利Pioneer測(cè)試軟件l能力：可以采集UU口消息，無(wú)法采集手機(jī)內(nèi)部LOG。5目錄典型案例分享信令跟蹤手段介紹6典型案例分享典型案例分享n案例1：Forbidden 403錯(cuò)誤連續(xù)未接通問(wèn)題分析現(xiàn)象：網(wǎng)格測(cè)試中，主被叫占用

3、故障小區(qū)，終端上行發(fā)射功率高，連續(xù)兩次RRC重配置均失敗，上發(fā)bye消息后未收到AS反饋的BYE200消息，主被叫掉話。7典型案例分享典型案例分享n案例1：Forbidden 403錯(cuò)誤連續(xù)未接通問(wèn)題分析現(xiàn)象：現(xiàn)象：主被叫掉話后，主叫做TAU更新，被叫信令缺失，有可能終端吊死。主叫15s后再次發(fā)起呼叫，收到403錯(cuò)誤消息，呼叫未接通，隨后15分鐘內(nèi)主叫持續(xù)呼叫，始終無(wú)法接通，錯(cuò)誤原因均是403（user is busy）.8典型案例分享典型案例分享n案例1：Forbidden 403錯(cuò)誤連續(xù)未接通問(wèn)題分析分析：連續(xù)未接通前上一次呼叫，由于無(wú)線基站原因造成核心網(wǎng)一直沒(méi)有收到前一次呼叫的BYE消息

4、，且被叫終端未發(fā)起IMS重注冊(cè)。核心網(wǎng)認(rèn)為用戶一直處于忙的狀態(tài)，所以ATS返回了403用戶忙。導(dǎo)致主叫連續(xù)20次起呼失敗。目前IMS的Session-Expires設(shè)置為 1800，核心網(wǎng)等待15分鐘沒(méi)有收到會(huì)話刷新消息則認(rèn)為會(huì)話中斷，在15分鐘內(nèi)則認(rèn)為該呼叫存在，15分鐘超時(shí)后IMS會(huì)主動(dòng)下發(fā)UPDATE，終端回復(fù)后IMS會(huì)將終端從忙的狀態(tài)釋放，后續(xù)呼叫正常。結(jié)論：開(kāi)啟無(wú)媒體流檢測(cè)開(kāi)關(guān)可以解決該問(wèn)題。120s檢測(cè)一次，如果不是通話狀態(tài)則釋放用戶。9典型案例分享典型案例分享n案例2：切換后雙不通導(dǎo)致掉話問(wèn)題分析現(xiàn)象：網(wǎng)格測(cè)試中，主被叫在跨廠家切換后，間隔30ms幾乎同時(shí)上發(fā)bye消息，IMS服

5、務(wù)器由于bye消息碰撞，回復(fù)bye487（Glare Bye condition encountered）10典型案例分享典型案例分享n案例2：切換后雙不通導(dǎo)致掉話問(wèn)題分析分析：UE掉話的原因是由終端發(fā)送BYE消息導(dǎo)致，發(fā)送BYE的原因是RTP超時(shí)，UE一直向網(wǎng)絡(luò)發(fā)送RTP包，但是長(zhǎng)時(shí)間沒(méi)有收到網(wǎng)絡(luò)側(cè)的RTP包，導(dǎo)致最后RTP timer超時(shí)。即出現(xiàn)單通現(xiàn)象，導(dǎo)致UE長(zhǎng)時(shí)間收不到下行數(shù)據(jù)包，定時(shí)器（20s）超時(shí)而釋放。UE從A廠家基站切換到B廠家基站后，在B廠家基站上跟蹤，出現(xiàn)了大量的上行丟包，頻度20ms一次。從PDCP的入口來(lái)看，基站上行收到了UE的數(shù)據(jù)包，但是沒(méi)有發(fā)送到核心網(wǎng)。判斷是PD

6、CP解包失敗。11典型案例分享典型案例分享n案例2：切換后雙不通導(dǎo)致掉話問(wèn)題分析分析：確定問(wèn)題在PDCP解包失敗后，抓取UE側(cè)LOG。發(fā)現(xiàn)UE在A廠家小區(qū)建立通話時(shí)，PDCP SN bit長(zhǎng)度配置為12bit。切換到B廠家小區(qū)時(shí)，由于基站沒(méi)有下發(fā)配置，PDCP SN SIZE不變，依然為12bit。實(shí)際B廠家基站該參數(shù)配置為7bit。 A廠家小區(qū)下配置情況 切換至B廠家小區(qū)下，基站未下發(fā)配置分析：UE在從A廠家小區(qū)切換至B廠家小區(qū)后，依然按照12bit封包上發(fā)，基站按照7bit解包，導(dǎo)致解包失敗，上行全部丟包。基站按照7bit封包下發(fā)，UE按照12bit解包，下行包也全部解析失敗。所以該問(wèn)題是

7、異廠家PDCP SN SIZE設(shè)置不一樣導(dǎo)致切換后雙不通，RTP超時(shí)后掉話的問(wèn)題。12典型案例分享典型案例分享n案例2：切換后雙不通導(dǎo)致掉話問(wèn)題分析結(jié)論：UE可以根據(jù)基站下發(fā)的配置，調(diào)整自己的封包、解包策略。UE的初始PDCP-config參照起呼時(shí)所占用基站下發(fā)的配置。 如果基站間PDCP SN SIZE配置不一致，只要在切換時(shí)目標(biāo)基站下發(fā)PDCP-config，UE可以調(diào)整。目前華為、貝爾基站在切換時(shí)會(huì)下發(fā)PDCP-config，中興、愛(ài)立信不會(huì)下發(fā)PDCP-config。建議全網(wǎng)統(tǒng)一PDCP SN SIZE、RLC SN SIZE。13典型案例分享典型案例分享n案例3：基站承載建立失敗導(dǎo)

8、致未接通問(wèn)題分析現(xiàn)象：在拉網(wǎng)測(cè)試過(guò)程中，發(fā)現(xiàn)部分手機(jī)呼叫失敗，失敗原因是主叫收到503，原因?yàn)閙edia bearer lost。503錯(cuò)誤是VOLTE未接通問(wèn)題中較為常見(jiàn)的錯(cuò)誤，此類問(wèn)題一般是由于承載建立失敗導(dǎo)致。14典型案例分享典型案例分享n案例3：基站承載建立失敗導(dǎo)致未接通問(wèn)題分析分析：跟蹤基站側(cè)trace，發(fā)現(xiàn)核心側(cè)發(fā)給基站E-RAB SETUP REQUEST消息中，上行的最大的帶寬為88kbps，而基站側(cè)配置的上下行最大帶寬均為52kbps。由于申請(qǐng)的帶寬已經(jīng)超出了基站設(shè)置的最大帶寬設(shè)置，專用承載無(wú)法建立，所以在E-RAB SETUP RESPONSE消息中攜帶“Radio-res

9、ource-not-available”。測(cè)試中發(fā)現(xiàn)的測(cè)試中發(fā)現(xiàn)的異常情況異常情況正常情況正常情況15典型案例分享典型案例分享n案例3：基站承載建立失敗導(dǎo)致未接通問(wèn)題分析1、通過(guò)信令跟蹤確認(rèn)是SBC申請(qǐng)帶寬過(guò)大，導(dǎo)致enodeb回錯(cuò)，所以需要看被叫的RX消息。2、觀察主叫側(cè)收到和發(fā)出去的INVITE，SBC收到的是b=AS:49，而SBC轉(zhuǎn)發(fā)的INVITE里帶的是b=AS:80。3、了解到華為SBC的C20版本做了個(gè)特性，配置編解碼轉(zhuǎn)換后，SBC轉(zhuǎn)發(fā)INVITE時(shí)會(huì)根據(jù)SBC添加的編解碼，重新計(jì)算帶寬，并更新SDP中的B行，由于配置了G711，所以帶寬更新為80。這個(gè)就是導(dǎo)致被叫側(cè)AAR中帶寬

10、變化的原因結(jié)論：1、在華為SBC：BCPLC中修改 信任終端媒體帶寬信息為否。2、考慮到多方通話等業(yè)務(wù)需要QCI1帶寬較大，調(diào)整基站帶寬至200kbps.16典型案例分享典型案例分享n案例4：智能網(wǎng)短號(hào)業(yè)務(wù)問(wèn)題導(dǎo)致呼叫未接通問(wèn)題分析現(xiàn)象：號(hào)碼A呼叫號(hào)碼B時(shí)，被叫顯示來(lái)電為短號(hào)。但號(hào)碼B使用短號(hào)回?fù)軙r(shí)呼叫失敗。使用號(hào)碼A的長(zhǎng)號(hào)回?fù)芸梢越油?。分析?、主叫號(hào)碼A發(fā)起短號(hào)呼叫，正常接通2、分析主叫UE的INVITE消息，撥打號(hào)碼為6495117典型案例分享典型案例分享n案例4：智能網(wǎng)短號(hào)業(yè)務(wù)問(wèn)題導(dǎo)致呼叫未接通問(wèn)題分析3、分析S-CSCF消息，正常觸發(fā)智能流程（10.189.101.9為SCPAS）。

11、4、SCPAS返回主叫的短號(hào)和被叫的長(zhǎng)號(hào)，S-CSCF通過(guò)SBC將主叫短號(hào)發(fā)送給被叫UE，被叫UE顯示主叫號(hào)碼為短號(hào)18典型案例分享典型案例分享n案例4：智能網(wǎng)短號(hào)業(yè)務(wù)問(wèn)題導(dǎo)致呼叫未接通問(wèn)題分析5、號(hào)碼B使用上一通呼叫顯示的短號(hào)回?fù)芎?，無(wú)法接通。分析UE的INVITE消息，撥打號(hào)碼為676956、分析S-CSCF消息，未見(jiàn)觸發(fā)智能業(yè)務(wù)流程，S-CSCF將67695直接路由到MGCF（10.189.97.18是MGCF的IP地址）19典型案例分享典型案例分享n案例4：智能網(wǎng)短號(hào)業(yè)務(wù)問(wèn)題導(dǎo)致呼叫未接通問(wèn)題分析7、MGCF將67695路由到CS域，CS域處理67695號(hào)碼分析失敗，放音。主叫聽(tīng)音過(guò)程中掛機(jī)拆除呼叫