VoLTE業(yè)務(wù)資料VoLTE問題案例集

VoLTE網(wǎng)上問題案例集文檔版本V1.0發(fā)布日期xxxx-01-28VoLTE網(wǎng)上問題案例集文檔版本DOCPROPERTYDocumentVersionV1.0(DATE\@"yyyy-MM-dd"2017-08-25)第頁(yè)修訂記錄Date日期RevisionVersion修訂版本CRIDCR號(hào)SectionNumber修改章節(jié)ChangeDescription修改描述Author作者xxxx-01-22V1.0初稿完成xxxx00130333目錄TOC\o"1-2"\h\z\u1 導(dǎo)讀 42 語(yǔ)音呼叫類問題 52.1 呼叫失敗 52.2 單通 313 語(yǔ)音質(zhì)量類問題 583.1 語(yǔ)音質(zhì)量差 584 語(yǔ)音增強(qiáng)特性類問題 594.1 RoHC 594.2 TTI_Bundling 664.3 SPS 70

導(dǎo)讀本文根據(jù)以往網(wǎng)上問題整理VoLTE相關(guān)問題的相關(guān)案例，在處理網(wǎng)上語(yǔ)音問題時(shí)，可以先翻閱本文相關(guān)案例，以拓展思路并縮小問題范圍，最終提升問題定位效率。本文所包含案例包括從各產(chǎn)品收集到的歷史案例，以及GTACVoLTE專題組啟動(dòng)后處理的問題提取出來的案例，在案例格式上有些差異，后續(xù)逐步統(tǒng)一。本文檔會(huì)逐步完善，新需求或建議，請(qǐng)聯(lián)系xxxx00130333。

語(yǔ)音呼叫類問題呼叫失敗案例1：英國(guó)VDF，VoLTE用戶呼叫失敗問題分析【問題描述】英國(guó)VDF在11月15號(hào)下午反饋同一終端同一套核心網(wǎng)，在愛立信/諾西基站下成功打通VoLTEcall，在xx基站下必然失?。粏栴}表現(xiàn)為：VoLTE終端開機(jī)后，QCI5、默認(rèn)承載均可建立但無法建立QCI1導(dǎo)致不能通話；【問題分析】1.組網(wǎng)環(huán)境信息分析1.1VoLTE業(yè)務(wù)原理分析正常VoLTE業(yè)務(wù)流程分為以下幾個(gè)過程：VoLTE終端完成TAUAttach流程建立QCI5承載；VoLTE終端發(fā)起IMS注冊(cè)流程,注冊(cè)使用的SIP信令使用QCI5承載；VoLTE終端發(fā)起語(yǔ)音呼叫，建立QCI1專有承載，語(yǔ)音媒體使用QCI1承載；VoLTE終端發(fā)起視頻呼叫，建立QCI2專有承載，視頻媒體使用QCI2承載；圖1：正常VoLTE用戶注冊(cè)流程圖2：正常VoLTE用戶語(yǔ)音呼叫流程圖3：VoLTE業(yè)務(wù)所使用的承載方式1.2網(wǎng)絡(luò)拓?fù)浞治?1.18日下午，一線實(shí)驗(yàn)室復(fù)測(cè)抓取了S-PGWP-CSCF上的抓包。分析xx和愛立信基站下主要有如下兩個(gè)差異點(diǎn)

1)xx基站下注冊(cè)的終端是諾基亞，愛立信基站下注冊(cè)的終端型號(hào)未知。2）注冊(cè)到xx的register消息是通過TCP承載，且在TCP層有分包，對(duì)端SBC回503serviceunavailable，而注冊(cè)到愛立信的register消息是UDP承載，無分包，對(duì)端SBC正?；貜?fù)401。通過多次抓包和定點(diǎn)分析最終確定網(wǎng)絡(luò)拓?fù)鋱D如下：圖4：英國(guó)VDF實(shí)驗(yàn)室組網(wǎng)圖B2.分段隔離分析針對(duì)現(xiàn)場(chǎng)所有xx站點(diǎn)分析，現(xiàn)場(chǎng)總共有6個(gè)xx站點(diǎn)PTH100/101/102/104/110/112，而發(fā)現(xiàn)在xxPTH102站點(diǎn)(未配置IPSEC)進(jìn)行測(cè)試，VoLTE業(yè)務(wù)有大概率60%左右成功率(剩余40%失敗主要和核心網(wǎng)相關(guān))，當(dāng)時(shí)已經(jīng)懷疑和IPSEC隧道(SeGW節(jié)點(diǎn))強(qiáng)相關(guān)。進(jìn)一步鎖定在PTH112站點(diǎn)(配置IPSEC)分析，通過修改S1接口上鏈路，嘗試旁路CPN和SeGW，并且修改IPSec加密算法為空加密等方案后，發(fā)現(xiàn)VoLTE業(yè)務(wù)均能建立成功，最終問題隔離到和IPSEC相關(guān)。2.1IPSec旁路方案一圖5：IPSec旁路方案一安全網(wǎng)關(guān)SeGW旁路之后，基站配置不變，基站的下一跳地址配置到跟SGE比較靠近的路由器上，基站直接拉線到該路由器；VoLTE業(yè)務(wù)測(cè)試結(jié)果為OK。此旁路方案同PTH102站點(diǎn)，102站點(diǎn)沒有配置IPSec，從102站點(diǎn)的S1用戶面地址pingSpGW地址，8000字節(jié)的報(bào)文都可以ping通，整條鏈路沒有報(bào)文大小限制。2.2IPSec旁路方案二圖6：IPSec旁路方案二相對(duì)于方案一，方案二直接把在連接安全網(wǎng)關(guān)SeGW兩端的路由器互聯(lián)，基站配置不變；VoLTE業(yè)務(wù)測(cè)試結(jié)果為OK。2.3IPSec旁路方案三圖7：IPSec旁路方案三方案三實(shí)際上沒有改變組網(wǎng)，而是將基站和安全網(wǎng)關(guān)的IPSECPROPOSAL的加密算法設(shè)置為NULL，驗(yàn)證算法不改；VoLTE業(yè)務(wù)測(cè)試結(jié)果為失敗。同時(shí)抓取路由器和安全網(wǎng)關(guān)兩端報(bào)文，確認(rèn)SIP_401消息已經(jīng)從安全網(wǎng)關(guān)發(fā)送到基站；此時(shí)排查重點(diǎn)轉(zhuǎn)移到基站，需要確認(rèn)eNodeB是否成功轉(zhuǎn)發(fā)401消息；3.eNodeB版本和配置以及話統(tǒng)分析檢查eNodeB版本：BTS3900V100R009C00SPC160；檢查EUTRAN支持VoIP能力開關(guān)：ENodeBAlgoSwitch.EutranVoipSupportSwitch=ON；檢查小區(qū)信號(hào)質(zhì)量：正常；檢查數(shù)傳業(yè)務(wù)成功率：正常；檢查所有基站配置和VoLTE業(yè)務(wù)：總共6個(gè)基站PTH100/101/102/104/110/112，VoLTE均失?。粰z查話統(tǒng)話統(tǒng)來確認(rèn)QCI5是否丟包：話統(tǒng)正常無丟包；CellDT和IFTS跟蹤：確認(rèn)eNodeB的PDCP和MAC層無丟包且調(diào)度正常；eNodeB跟蹤C(jī)ELLDT和終端側(cè)QXDM數(shù)據(jù)分析從Celldt132跟蹤看，有些時(shí)候VoLTE建立的時(shí)候QCI5的下行有數(shù)據(jù)包，有些時(shí)候又沒有下行數(shù)據(jù)包。從CELLDT34看，下行都是ACK，說明空口發(fā)送QCI5數(shù)據(jù)時(shí)沒有誤碼。終端側(cè)QXDM看到，QCI5的RBID為2，該RB下行也收到了數(shù)據(jù)包，但有時(shí)這些數(shù)據(jù)包能到PDCP層，有些到不了PDCP層，但是SIP層都收不到，不確定這些數(shù)據(jù)包是否就是401消息。4.異常問題流程分析由于前期從英國(guó)VDF一線和羅馬尼亞GTAC二線得到信息是終端收不到SIP_401消息，前后方重點(diǎn)都放在下行SIP_401丟失問題上，但是前面分析SeGW證實(shí)已經(jīng)下發(fā)；而eNodeBeRAN7.0使用CellDT、IFTS、話統(tǒng)等都無法準(zhǔn)確判斷401是否從S1和UU接口轉(zhuǎn)發(fā)，現(xiàn)場(chǎng)的終端Nokia和Sony也都不具備QXDM抓包條件；問題分析未能取得突破進(jìn)展。為了統(tǒng)一思路前后方重新整理問題和思路尋求新的突破口，正對(duì)不同終端在同一個(gè)xx站點(diǎn)PTH112下面驗(yàn)證總共得到以下3種失敗場(chǎng)景如下：Case1:VoLTE注冊(cè)過程中網(wǎng)絡(luò)下發(fā)401鑒權(quán)挑戰(zhàn)消息，終端未收到；圖9：Case1網(wǎng)絡(luò)下發(fā)鑒權(quán)挑戰(zhàn)401終端未收到Case2:Sony終端基于UDP的Register消息異常；圖10：Case2Sony終端基于UDP的注冊(cè)失敗Case3:Nokia終端基于TCP的Register消息異常；圖11：Case3Nokia終端基于TCP的注冊(cè)失敗根據(jù)以上3種失敗場(chǎng)景，根據(jù)不同終端和網(wǎng)元節(jié)點(diǎn)跟蹤定位分析確定如下失敗模型；至此很明顯最初得到的Case1所描述的失敗類型是一個(gè)錯(cuò)誤的判斷，是因?yàn)镹okia和Sony終端不同的失敗表現(xiàn)產(chǎn)生混淆導(dǎo)致：5.友商成功數(shù)據(jù)分析針對(duì)相同終端在IMS側(cè)抓包，分別從E///站點(diǎn)和xx站點(diǎn)比較分析，發(fā)現(xiàn)E///站點(diǎn)和xx站點(diǎn)的Register和401Unauthorized消息沒有明顯差異；E///，從IMSCORE到SBCWWW-Authenticate:Digestnonce="6TbnQHPNBhWjXau/+X5Q3CTBZv5lNwAAogwDWpz3r+Y=",realm="ims.vodafone.co.uk",algorithm=AKAv1-MD5,qop="auth",ck="673C3B94B35314C9FE03432A239BA836",ik="FFD4EB7997DCB64E714184274286A155"AuthenticationScheme:DigestNonceValue:"6TbnQHPNBhWjXau/+X5Q3CTBZv5lNwAAogwDWpz3r+Y="Realm:"ims.vodafone.co.uk"Algorithm:AKAv1-MD5QOP:"auth"CypheringKey:"673C3B94B35314C9FE03432A239BA836"IntegrityKey:"FFD4EB7997DCB64E714184274286A155"E///，從SBC到UESecurity-Server:ipsec-3gpp;q=0.1;alg=hmac-sha-1-96;ealg=aes-cbc;prot=esp;mod=trans;spi-c=3407;spi-s=3408;port-c=6000;port-s=7000[Security-mechanism]:ipsec-3gppq=0.1alg:hmac-sha-1-96ealg:aes-cbcprot:espmod=transspi-c:3407(0x00000d4f)spi-s:3408(0x00000d50)port-c:6000port-s:7000Huawei從IMSCORE到SBCWWW-Authenticate:Digestnonce="+cF5iJzFh0c1ulqe4K+f0gqf1fC3WAAA2YG/KEDpHPQ=",realm="ims.vodafone.co.uk",algorithm=AKAv1-MD5,qop="auth",ck="31ED1CC2BAE29058057070437894DBC0",ik="71CF825E807149738C7EF51A794D7FEF"AuthenticationScheme:DigestNonceValue:"+cF5iJzFh0c1ulqe4K+f0gqf1fC3WAAA2YG/KEDpHPQ="Realm:"ims.vodafone.co.uk"Algorithm:AKAv1-MD5QOP:"auth"CypheringKey:"31ED1CC2BAE29058057070437894DBC0"IntegrityKey:"71CF825E807149738C7EF51A794D7FEF"HUAWEI，從SBC到UESecurity-Server:ipsec-3gpp;q=0.1;alg=hmac-sha-1-96;ealg=aes-cbc;prot=esp;mod=trans;spi-c=3437;spi-s=3438;port-c=6000;port-s=7000[Security-mechanism]:ipsec-3gppq=0.1alg:hmac-sha-1-96ealg:aes-cbcprot:espmod=transspi-c:3437(0x00000d6d)spi-s:3438(0x00000d6e)port-c:6000port-s:7000至此，通過以上分析判斷排除終端和核心網(wǎng)異常；而從P1點(diǎn)抓包來看也能夠確認(rèn)eNodeB成功轉(zhuǎn)發(fā)了Register和401Unauthorized消息。6.諸點(diǎn)抓包分析通過xx站點(diǎn)和E///站點(diǎn)對(duì)比分析，已經(jīng)明確問題出現(xiàn)在S1接口所連接設(shè)備上面，但是由于eRAN7.0版本(內(nèi)部確認(rèn)eRAN8.0以上版本可以)不具備SIP信令跟蹤和足夠的證據(jù)，來證明eNodeB成功轉(zhuǎn)發(fā)SIP消息；即便我們能夠證明PDCP和MAC無丟包且調(diào)度正常。根據(jù)現(xiàn)場(chǎng)組網(wǎng)信息啟動(dòng)網(wǎng)絡(luò)逐點(diǎn)抓包隔離異常網(wǎng)元，開始嘗試Ping不同大小報(bào)文并且抓包分析結(jié)果如下：對(duì)Nokia和Sony兩款終端異常場(chǎng)景抓包分析發(fā)現(xiàn)P3段會(huì)丟棄大于1500Bytes的報(bào)文，統(tǒng)計(jì)數(shù)據(jù)結(jié)果如下：同時(shí)對(duì)Nokia和Sony兩款終端在友商E///抓包分析發(fā)現(xiàn)報(bào)文在P3段傳輸固定為1420Bytes的報(bào)文，統(tǒng)計(jì)數(shù)據(jù)結(jié)果如下：至此，發(fā)現(xiàn)丟包問題最終鎖定在P3(SeGW-->CPN)抓包段，并且此段只會(huì)丟棄大于1490Bytes的報(bào)文；而對(duì)比友商E///網(wǎng)絡(luò)傳送的1420Bytes報(bào)文能夠成功傳輸；最終問題鎖定在SeGW和CPN網(wǎng)元節(jié)點(diǎn)。7.UE側(cè)問題分析7.1xxP7 現(xiàn)場(chǎng)使用的P7不支持VoLTE，臨時(shí)升級(jí)到研發(fā)內(nèi)部版本但是仍然測(cè)試失敗;通過測(cè)試發(fā)現(xiàn)P7使用的SIP基于UDP承載，并且Register消息總共才1172Bytes，MTU值可通過root權(quán)限配置但是設(shè)置未生效；待進(jìn)一步驗(yàn)證。P7升級(jí)到測(cè)試成功，但在E///的基站下，接入失敗。IMS直接回494消息，CN側(cè)抓包如下：如下是P7失敗和sony成功（E///基站）的對(duì)比，差異如紅圈出，但P7發(fā)送的也符合協(xié)議RFC3329.對(duì)比協(xié)議，P7發(fā)送的register消息，是符合協(xié)議的，需聯(lián)合IMS確認(rèn)，其發(fā)送494的原因。RFC3329定義的SIP協(xié)商安全傳輸機(jī)制：2.Solution2.1OverviewofOperation

Themessageflowbelowillustrateshowthemechanismdefinedinthis

documentworks:

1.Clientclientlist>Server

2.Client<serverlistServer

3.Client(turnonsecurity)Server

4.Clientserverlist>Server

5.Client<okorerrorServer

Figure1:Securityagreementmessageflow.

Step1:

Clientswishingtousethisspecificationcansendalistoftheirsupportedsecuritymechanismsalongthefirstrequesttotheserver.

Step2:

Serverswishingtousethisspecificationcanchallengetheclienttoperformthesecurityagreementprocedure.

Thesecuritymechanismsandparameterssupportedbytheserveraresentalonginthischallenge.

Step3:

Theclientthenproceedstoselectthehighest-preferencesecuritymechanismtheyhaveincommonandtoturnontheselectedsecurity.

Step4:

Theclientcontactstheserveragain,nowusingtheselectedsecuritymechanism.

Theserver'slistofsupportedsecuritymechanismsisreturnedasaresponsetothechallenge.

Step5:

Theserververifiesitsownlistofsecuritymechanismsinordertoensurethattheoriginallisthadnotbeenmodified.協(xié)議RFC3329要求494必帶Security-Server頭域

AserverreceivinganunprotectedrequestthatcontainsaRequireorProxy-Requireheaderfieldwiththevalue"sec-agree"MUSTrespondtotheclientwitha494(SecurityAgreementRequired)response.

TheserverMUSTaddaSecurity-Serverheaderfieldtothisresponseistingthesecuritymechanismsthattheserversupports.

TheserverMUSTadditslisttotheresponseeveniftherearenocommonsecuritymechanismsintheclient'sandserver'slists.

Theserver'slistMUSTNOTdependonthecontentsoftheclient'slist.愛立信核心網(wǎng)回的494沒有Security-ServerSIP/2.0494SecurityAgreementRequiredTo:<sip:234159136179274@>;tag=aprqngfrt-0fqlel2000020From:<sip:234159136179274@>;tag=Z3dcbqtCall-ID:Y2dcbqtET@6CSeq:1REGISTERVia:SIP/2.0/UDP6:5060;received=6;branch=z9hG4bKW4dcbqtETatET9aaaqJg;rport綜上所述發(fā)現(xiàn)P7終端VoLTE業(yè)務(wù)失敗原因?yàn)镾IP協(xié)商安全傳輸機(jī)制失敗，由于P7使用測(cè)試版本有可能不支持IPSec加密算法”ealg=null;”原因，導(dǎo)致友商E///的IMSCore直接拒絕；而P7終端在研發(fā)內(nèi)部測(cè)試VoLTE業(yè)務(wù)成功，使用的是xxCN兼容性更高。7.2NokiaLumia830現(xiàn)場(chǎng)使用的Nokia終端，WindowsPhone操作系統(tǒng)Lumia系列手機(jī)；通過測(cè)試發(fā)現(xiàn)Nokia終端使用的SIP基于TCP承載，并且第一條Register消息的大分片報(bào)文為1360Bytes，第二條Register消息的大分片報(bào)文為1480Bytes；Nokia的MTU值通過信令判斷為1480，具體配置待繼續(xù)研究；7.3SonyXperiaZ2現(xiàn)場(chǎng)使用的Sony終端，安卓操作系統(tǒng)；通過測(cè)試發(fā)現(xiàn)Sony終端使用的SIP基于UDP承載，并且第一條Register消息的大分片報(bào)文為1500Bytes，第二條Register消息的大分片報(bào)文為1500Bytes；Nokia的MTU值通過信令判斷為1500，具體配置待繼續(xù)研究；8.eNodeB側(cè)問題分析8.1xxeNodeB版本為BTS3900V100R009C00SPC160，此系列版本無SIP信令跟蹤，并且不能基于CellDT和IFTS跟蹤判斷SIP消息；即eRAN7.0版本無有效定位SIP信令的手段。//已經(jīng)確認(rèn)eRAN8.0以上版本可跟蹤SIP消息。通過對(duì)比xx和E///報(bào)文分析，發(fā)現(xiàn)MTU實(shí)現(xiàn)差異如下，xxeNodeB經(jīng)過加密后在IPSEC以下IP層進(jìn)行MTU(1500)分包；SeGW收到后會(huì)進(jìn)行組包再解密，解密后如果報(bào)文大于SeGW的MTU設(shè)置會(huì)再次進(jìn)行分片處理；8.2E///eNodeB 通過對(duì)比xx和E///報(bào)文分析，發(fā)現(xiàn)MTU實(shí)現(xiàn)差異如下，友商E///可以實(shí)現(xiàn)在IPSEC以上IP層進(jìn)行MTU(1420)分包，即先將業(yè)務(wù)報(bào)文分片再進(jìn)行獨(dú)立加密傳輸；SeGW收到后對(duì)報(bào)文解密而不需要組包，這樣避免了傳輸過程中再次組包和分片的操作；其IPSEC是通過獨(dú)立單板實(shí)現(xiàn)；8.3NSNeNodeB NSNeNodeB暫時(shí)未抓取報(bào)文，但是相同組網(wǎng)其站點(diǎn)下業(yè)務(wù)能夠成功說明其實(shí)現(xiàn)也有類似業(yè)務(wù)分片機(jī)制；NSN具體實(shí)現(xiàn)方式待后續(xù)驗(yàn)證9.傳輸問題分析根據(jù)現(xiàn)場(chǎng)網(wǎng)絡(luò)拓?fù)浜徒M網(wǎng)進(jìn)行分段Ping包，能夠快速進(jìn)行分段隔離異常網(wǎng)元；通過現(xiàn)場(chǎng)測(cè)試不同大小報(bào)文的Ping結(jié)果，發(fā)現(xiàn)異常點(diǎn)主要集中在P3抓包點(diǎn)，而P3抓包點(diǎn)為SeGW—>CPN互聯(lián)方向；P3點(diǎn)報(bào)文大于1490Bytes都被丟棄，而SeGW組包后解密再分片的小包能夠正常傳輸，最初問題鎖定在T5(SeGW)和T6(CPN)兩個(gè)端點(diǎn)； 通過多次修改SeGW和CPN端口的MTU值嘗試Ping包測(cè)試，并且結(jié)合現(xiàn)場(chǎng)CPN抓包鏡像端口M，實(shí)際抓包端口M也是CPN物理端口，此端口M通過鏡像T2/T3/T6/T7實(shí)現(xiàn)Wireshark抓包的，丟包點(diǎn)再次確認(rèn)為T6(CPN)和T7(CPN)兩個(gè)端點(diǎn)；即T6實(shí)際收到報(bào)文且出現(xiàn)異常丟棄導(dǎo)致沒有發(fā)送給鏡像端口M。再次檢查整條鏈路中各節(jié)點(diǎn)MTU配置，統(tǒng)一修改eNodeB(T1)、T2、T3、T4、T5、T6、T7MTU為1700Bytes，再次檢查SeGW的PathMTU為1700；最終Ping報(bào)文1601Bytes能夠成功，驗(yàn)證VoLTE業(yè)務(wù)成功。Ping結(jié)果如下：【問題根因】問題結(jié)論簡(jiǎn)述：現(xiàn)象為VoLTE用戶注冊(cè)失敗，上行傳輸網(wǎng)絡(luò)有大包限制和丟棄問題；處理問題過程中發(fā)現(xiàn)eRAN7.0BTS3900V100R009C00SPC160版本存在兩點(diǎn)不足：1）、eRAN7.0以前版本不支持SIP信令跟蹤，缺乏有效手段定位SIP消息轉(zhuǎn)發(fā)情況；2）、xxeNodeB對(duì)不支持按照業(yè)務(wù)報(bào)文分片處理，雖然符合協(xié)議但是與友商靈活實(shí)現(xiàn)機(jī)制相比；xxeNodeB實(shí)現(xiàn)方式優(yōu)勢(shì)：可以減少傳輸網(wǎng)絡(luò)負(fù)荷，提高傳輸效率；xxeNodeB實(shí)現(xiàn)方式缺點(diǎn)：安全網(wǎng)關(guān)SeGW需要組包，增加對(duì)組網(wǎng)傳輸網(wǎng)路MTU限制的要求；RFC:791【解決方案】解決英國(guó)VDF的VoLTE問題，根據(jù)現(xiàn)場(chǎng)訴求提供兩種方案：方案1）、建議現(xiàn)場(chǎng)檢查全網(wǎng)設(shè)備節(jié)點(diǎn)的MTU設(shè)置，通過Ping報(bào)文確認(rèn)S1口(eNodeB-->SpGW)能夠ping通至少1600Bytes報(bào)文；研發(fā)根據(jù)現(xiàn)場(chǎng)組網(wǎng)提供推薦配置和現(xiàn)場(chǎng)實(shí)際成功配置如下：方案2）、xxeNodeB根據(jù)現(xiàn)場(chǎng)訴求實(shí)現(xiàn)按照業(yè)務(wù)報(bào)文分片處理功能，待最終討論確認(rèn)正式版本；案例2：iphone6做主叫VoLTE呼叫失敗問題分析【問題描述】西研實(shí)驗(yàn)室進(jìn)行iphone6VoLTE測(cè)試，iphone6VoLTESIPRegistration成功，但iphone6作為主叫呼叫P7，呼叫失敗；而P7呼叫iphone6是正常的?！締栴}分析】1、根據(jù)問題現(xiàn)象，屬于VoLTE呼叫建立失敗問題，這類問題，從語(yǔ)音核心網(wǎng)IMS側(cè)入手分析VoLTE呼叫控制面SIP信令效率較高。eNodeB/S-GW/P-GW主要負(fù)責(zé)將SIP信令（承載在QCI5EPSbearer上）在UE和P-CSCF間正確轉(zhuǎn)發(fā)，如下為L(zhǎng)TE終端與LTE終端呼叫示意圖，其中，黑色虛線為VoLTE呼叫建立所涉及到的網(wǎng)元：流程簡(jiǎn)述：LTE用戶發(fā)起呼叫。MMTelAS執(zhí)行主叫業(yè)務(wù)處理。完成主叫業(yè)務(wù)處理后，MMTelAS將呼叫路由回S-CSCF；S-CSCF查詢ENUM，并將呼叫路由到被叫。在被叫側(cè)，呼叫被路由到向被叫用戶提供業(yè)務(wù)的I-CSCF，I-CSCF發(fā)送呼叫請(qǐng)求到S-CSCF。MMTelAS執(zhí)行被叫業(yè)務(wù)處理后，MMTelAS將呼叫路由回S-CSCF；S-CSCF觸發(fā)SCCAS進(jìn)行域選（即選擇被叫落地的域），選擇LTE網(wǎng)絡(luò)接入被叫用戶。S-CSCF將呼叫請(qǐng)求通過P-CSCF接續(xù)到被叫用戶。承載建立。2、如下為測(cè)試同事在SBC側(cè)鏡像抓包采集的log：從上面可以看出，當(dāng)Iphone6發(fā)起VoLTE呼叫時(shí)，Iphone6先觸發(fā)建立TCPconnection，但SBC卻沒有響應(yīng)，經(jīng)確認(rèn)，我司SBCSE2600在作為A-SBC時(shí)，缺省情況下，僅支持SIPoverUDP，SIPoverTCP為可選特性，需要相關(guān)license和相關(guān)配置才能支持，如下內(nèi)容摘自SE2600產(chǎn)品手冊(cè)：注：SE2600部署在IP網(wǎng)絡(luò)的邊緣或匯聚層，是會(huì)話信令和媒體流的聚合點(diǎn)。SE2600作為信令代理和媒體代理設(shè)備。通過對(duì)信令和媒體的處理，SE2600實(shí)現(xiàn)拓?fù)潆[藏、NAT（NetworkAddressTranslation）/防火墻穿越等功能。A-SBCSIP代理功能包括信令代理和媒體代理。信令代理：對(duì)SIP信令報(bào)文的解析、處理和轉(zhuǎn)發(fā)。媒體代理：對(duì)音頻、視頻等媒體流的代理。3、測(cè)試同事在SBC上補(bǔ)充SIPoverTCP相關(guān)配置后，再進(jìn)行測(cè)試，發(fā)現(xiàn)仍是無法呼叫，log如下：經(jīng)測(cè)試同事咨詢SE2600同事，該問題確認(rèn)為：Iphone6在SIPRegistration過程中采用的是UDP傳輸協(xié)議，而在發(fā)起VoLTE呼叫時(shí)，采用的是TCP傳輸協(xié)議，我司SE2600不支持這種場(chǎng)景，僅支持對(duì)于同一個(gè)UA，所有SIP消息都采用UDP協(xié)議或TCP協(xié)議。所以，導(dǎo)致iphone6終端作為主叫時(shí)，VoLTE呼叫無法建立。問題分析到這里，我們會(huì)有個(gè)疑問，那到底SE2600的問題，還是Iphone6的問題呢？翻查了一下RFC3261SIP協(xié)議（18Transport章節(jié)），18.1.1SendingRequestsIfarequestiswithin200bytesofthepathMTU,orifitislargerthan1300bytesandthepathMTUisunknown,therequestMUSTbesentusinganRFC2914[43]congestioncontrolledtransportprotocol,suchasTCP.18.2.1ReceivingRequestsForanyportandinterfacethataserverlistensonforUDP,itMUSTlistenonthatsameportandinterfaceforTCP.ThisisbecauseamessagemayneedtobesentusingTCP,ratherthanUDP,ifitistoolarge.Asaresult,theconverseisnottrue.AserverneednotlistenforUDPonaparticularaddressandportjustbecauseitislisteningonthatsameaddressandportforTCP.Theremay,ofcourse,beotherreasonswhyaserverneedstolistenforUDPonaparticularaddressandport.大致理解如下：SIP協(xié)議是基于transaction的協(xié)議，每個(gè)transaction應(yīng)該都可以根據(jù)SIP消息需求場(chǎng)景決定所要采用的傳輸協(xié)議。而且，SIP協(xié)議也要求大于1300字節(jié)的SIPRequest消息使用支持擁塞控制的傳輸層協(xié)議（如：TCP）。所以，該問題應(yīng)該是SE2600的兼容性不夠?qū)е碌膯栴}，Iphone6的實(shí)現(xiàn)沒有錯(cuò)?！締栴}根因】Iphone6終端在VoLTESIPRegistration過程中采用了SIPoverUDP，發(fā)起VoLTE呼叫時(shí)，采用了SIPoverTCP，而我司SE2600不支持場(chǎng)景，SE2600只支持對(duì)于同一個(gè)UA，所有SIP消息都采用UDP協(xié)議或TCP協(xié)議。所以，出現(xiàn)了Iphone6注冊(cè)成功，但做主叫時(shí)，呼叫無法建立的問題。該問題根因是SE2600產(chǎn)品兼容性問題，我司SBC下一代產(chǎn)品SE2900會(huì)支持上述場(chǎng)景?！窘鉀Q方案】1）目前，西研實(shí)驗(yàn)室下，由Iphone6臨時(shí)加載補(bǔ)丁，使得Iphone6在SIPRegistration和VoLTE呼叫過程中都采用UDP傳輸協(xié)議來規(guī)避。2）也可以考慮部署SE2900設(shè)備來解決（SE2900的SIPoverTCP是產(chǎn)品基礎(chǔ)特性，不再受license限制）。案例:3：UE未發(fā)送INVITE消息導(dǎo)致電話呼叫失敗的問題分析【問題描述】一線反饋VoLTE電話呼叫失敗【問題分析】1、終端撥打電話時(shí)，基站側(cè)的Uu口和S1口沒有建立QCI1的承載2、QCI1的建立條件：只有在MME在收到SIP消息后才會(huì)觸發(fā)QCI1的承載建立。由于在基站側(cè)看到?jīng)]有建QCI1，所以懷疑MME沒有收到SIP消息。3、通過UE側(cè)的QXDM抓包，確認(rèn)UE沒有在撥打電話時(shí)沒有發(fā)送INVITE消息，所以呼叫失敗。4、復(fù)位手機(jī)后，問題現(xiàn)象消失，QXDM抓包如下【問題根因】UE沒有在撥打電話時(shí)沒有發(fā)送INVITE消息【解決方案】需要終端分析不發(fā)送invite消息的原因。本案例中復(fù)位手機(jī)可以解決該問題。案例4：AnalysisreportforVOLTEsetupfailureunderHL475201_Sangambank300site【問題描述】TheVOLTEservicealwaysfailsunderMicrositeHL475201_Sangambank300【問題分析】1.ENODEBalarmandfaultyanalysisThereisnoanyrelatedactivealarmandfaultyfromENODEBside.2.ENODEBtraceanalysisAsdemonstratedinthebelowfigure,thereisnoRRCsetupandERABsetupfailure,nocalldrop.AndtheQCI5whichisusedtocarrytheVOIPsetupsignal(SIP)issetupsuccessfully.Figure1.S1andUUinterfacesignalflowSotheVOLTEsetupfailureshouldbefromSIPsignalpart.3.WiresharktraceanalysisInthisversion,thereisnowaytocapturetheSIPsignalfromENODEBside.SotheonlymethodtotracetheSIPsignalistocaptureallthedatatransmissionbetweenENODEBandSGW.Belowfigureshowswherethewiresharkdatawascaptured.Figure2.DatacapturelocationFromthewiresharktrace,theVOLTEcallfailureisduetoregisterfail,andthereasonistheCNdoesnotreceivesthesecondregistermessagefromUEaftersending“401unauthorized”messagetoUE.Figure3.TheSIPsignaltracebetweenENODEBandSGWFigure4.ThenormalregisterSIPsignalflowThepossiblereasonsofCNnotreceivethesecond“register”messageare:a.UEdoesn’treceivethe“401unauthorized”message.b.UEdoesn’tsendthesecondregister.c.ENODEBdoesn’tsendthesecondregistertoCN.1).UEdoesn’treceivethe“401unauthorized”messageBycomparingwiththeENODEBtrace,thetimedifferencebetweentheCNdataandENODEBtraceis1hour,ENODEBtimeis1hourlaterthanCN.Sothe4timesfailureshappenedfrom3:53:06to3:53:21accordingtoENODEBtime.Therearelogstorecordthedatapacketsateachpointdemonstratedinthebelowfigure:Figure5.TheENODEBpacketstatisticpointA:receivedtotalGTPpacketsnumberfromSGW.B:sentGTP-UpacketsnumbertoPDCPmoduleC:sentGTP-CpacketsnumbertoGTPcontrolmoduleD:PDCPreceivedtotalGTP-UpacketsfromtransmissionmoduleFirstly,fromthePDCPcounter,thereisnoanyQCI5DLdatareceivedfromtransmissionmodulefrom3:50:00to3:55:00.Figure6.TheENODEBcounterL.Traffic.UL.PktLoss.Tot.QCI.5:ULreceivedQCI5datafromUE. L.PDCP.Tx.TotRev.Trf.SDU.QCI.5:DLreceivedQCI5datafromtransmissionmodule.L.PDCP.Tx.TotRev.Trf.SDU.QCI.8:DLreceivedQCI8datafromtransmissionmodule.Secondly,fromthetransmissionmodulestatistic,alltheGTPdatareceivedfromSGWhavebeensenttoPDCPandGTPcontrolmoduleFigure7.TheENODEBpacketstatisticBycomparingthestatisticatpointBandD,itisthesecondproofthatthereisnoanydatalossfromENODEBside,andENODBEdoesnotreceivetheDLSIPmessagesuchas“Unauthorized”.BelowsheetshowsthestatisticatpointDFigure8.TheENODEBcounterPDCPreceived18730packetsfromtransmissionmodulefrom3:30to4:30,anditissamewiththestatisticatpointBbytransmissionmodule.2)TheQCI5downlinkpacketsdiscardedbytransmissionThedatatracewascaptureattheoutletofSGW,itprovesthattheSGWalreadysenttheSIPmessagetoENODEB,buttheENODEBdidn’treceiveit.Soitmustbetransmissionnetworkproblem.Afterthetransmissioninvestigation,itisconfirmedthattheDLQCI5packets(DLSIPmessage)discardedbymistake,becausedifferentQCIpackethasdifferentDSCPvalue,theQCI5DL(fromSGWtoENODEB)DSCPis46,andallpacketswithDSCP46werediscardedattransmissionequipment.Aftercorrecttheerroroftransmissionequipment,theproblemissolved.【問題根因】Wrongconfigurationfromtransmissionequipment,causeallpacketswithDSCP46arediscardedbymistake.【解決方案】Correctthetransmissionwrongconfiguration.案例5：E///處理異常導(dǎo)致UE從xx基站切換到E///基站后，語(yǔ)音中斷【問題描述】阿聯(lián)酋+ET，V100R008C00SPC260，客戶在實(shí)驗(yàn)室測(cè)試，發(fā)現(xiàn)從xx基站切換到E///基站后，語(yǔ)音通話中斷，從E///切換到xx，沒有問題?！締栴}分析】1.UE側(cè)日志分析。（一線只反饋了UE側(cè)日志的截圖，沒有反饋具體的日志信息）從圖1和圖2對(duì)比分析，切換后語(yǔ)音中斷出現(xiàn)在PCI=381（我司基站）往PCI=16（E///基站）切換以后；PCI=16往PCI=381切換沒有問題。從切換流程分析，兩次切換均成功。排除切換失敗導(dǎo)致的語(yǔ)音中斷。圖1.切換后出現(xiàn)通話中斷圖2.切換后通話正常2.eNB側(cè)日志分析由于語(yǔ)音業(yè)務(wù)需要建立qci5和qci1的承載，所以接下來需要分析，切換后qci5和qci1是否建立正常。1）handoverrequestack消息對(duì)比分析：當(dāng)UE從PCI=381的站點(diǎn)切換到PCI=16的站點(diǎn)時(shí)，qci1的承載準(zhǔn)入失敗。由此找到了語(yǔ)音中斷的原因：切換到E///后，qci1準(zhǔn)入失敗。2）handoverrequest消息對(duì)比分析：qci1的開戶信息一致，無異常；排除切換后qci1開戶信息不一致導(dǎo)致的準(zhǔn)入失敗。由此需要進(jìn)一步分析qci1的空口配置信息是否一致。qci1空口配置分析：RLCSNsize配置不一致。我司切換到E///基站時(shí)，qci1的RLCSNSize=5bit；而從E///基站切換回來時(shí)，qci1的RLCSNSize=10bit。由此推測(cè)：我司基站qci1的RLCSNSize配置的5bit；E///基站qci1的RLCSNSize配置的10bit。3、在其他局點(diǎn)遇到過類似問題，當(dāng)E///基站配置的SNSize和他收到的切換命令中的SNsize不一致時(shí)，E///基站處理會(huì)出問題，導(dǎo)致承載準(zhǔn)入失敗。4、一線將我司基站qci1的RLCSNsize配置成10bit后，問題可以規(guī)避?！締栴}根因】當(dāng)E///基站配置的SNSize和他收到的切換命令中的SNsize不一致時(shí)，E///基站處理會(huì)出問題，導(dǎo)致承載準(zhǔn)入失敗。需要E///給出根因。我司基站做了兼容性處理，當(dāng)基站配置的SNSize和收到的切換命令中的SnSize不一致時(shí)，會(huì)選擇基站配置的SNsize下發(fā)給UE，不會(huì)準(zhǔn)入失敗?！窘鉀Q方案】將我司基站qci1的RLCSNsize和E///基站配置一致，可以規(guī)避該問題。案例6：DRXtoolongcausedQCI5packetsdiscardedbyENB【問題描述】whenDRXON,thereissometimesVOLTEcannotworkwhenused2VOLTEUEdoingcalls.【問題分析】1.LastQCI5TCPpacketlostByanalysistheS1wireshsarklog,whenQCI5bearissetup,theSIPsignallingmessageisnormal,butthelastTCP[RST,ACK]packetsislostwhentransmitthroughLTEwirelessair.Figure1lastTCPpacketatENBS1Asthefigureaboveshows,everytimeVOLTEcallsinterrupted,thelastQCI5TCPpacketsisnotreceivedbyUE,butreceivedbyENBS1,itmeansthepacketsislostwithinENB.2.QCI5packetsdiscardedbyENBPDCPByanalyzingthePDCPtrace,whenVOLTEcallsinterrupted,thereisQCI5packetslostduetoPDCPdiscardtimertimeoutasshownbelow(thelastQCI5[RST,ACK]TCPpacketisabout66bytes).Figure2thestatisticsofPDCPpackets3.DRXparametersunreasonablecasuedpacketslostAfteranalysisthewirelessUUtrace,itshowswhenQCI1isreleased,QCI5DRXparametersisre-configuredbyENBsenttoUEduetohigherpriorityofQCI5thanQCI6.andthelongDRXis320ms:Figure3theUUtraceAndtheQCI5PDCPdiscardedtimeris150msindefault:SowhenUEisinDRXsleepstatus,andENBwillwait320msatmosttosendthelastTCPpackettoUE,butthePDCPdiscardtimerofQCI5is150ms,soENBwilldiscardthispacket.【問題根因】BecausethelongDRXis320mstoolong,

afterENBreceived[RST,ACK]packets,theUEmayisinsleepstatus,andENBwillwait320msatmosttosendthelastTCPpackettoUE,butthePDCPdiscardtimerofQCI5is150ms,soENBwilldiscardthispacket.【解決方案】1.modifytheQCI5PDCPdiscardedtimertoinfinite.2.modifythelongDRXofQCI5asthesameasQCI1.單通案例1：iphone6呼叫P7單通分析【問題描述】西研實(shí)驗(yàn)室采用iphone6，HuaweiP7，Huaweimate7終端進(jìn)行VoLTEIOT測(cè)試，發(fā)現(xiàn)iphone6呼叫P7出現(xiàn)單通問題，iphone6聽不到P7側(cè)語(yǔ)音，而其他場(chǎng)景下，語(yǔ)音均正常：【問題分析】根據(jù)測(cè)試同事反饋，iphone6呼叫P7時(shí)，單通問題必現(xiàn)，并且均為iphone6聽不到P7話音，而其他呼叫場(chǎng)景，包括P7呼叫iphone6，iphone6呼叫mate7等，呼叫都正常，所以，該問題初步懷疑是iphone6與P7之間因兼容性問題導(dǎo)致單通，與其他網(wǎng)元無關(guān)。對(duì)于這種實(shí)驗(yàn)室內(nèi)必現(xiàn)的單通問題，網(wǎng)元側(cè)數(shù)據(jù)采集比較方便，問題是比較容易分析的。如下為L(zhǎng)TE終端與LTE終端呼叫示意圖，其中，黑色虛線為VoLTE呼叫建立所涉及到的網(wǎng)元，藍(lán)色實(shí)線為媒體RTP包所經(jīng)歷路徑：從上圖可以看出，SBC是VoLTESIP信令和RTP媒體都經(jīng)過的網(wǎng)元，實(shí)驗(yàn)室內(nèi)SBC可以通過鏡像抓包采集到SIP信令和RTP媒體包，并且可以通過wireshark進(jìn)行數(shù)據(jù)分析，因此，該問題優(yōu)先選擇在SBC網(wǎng)元（實(shí)驗(yàn)室為我司SE2600）采集數(shù)據(jù)包進(jìn)行分析。如下為SBC網(wǎng)元iphone6呼叫P7數(shù)據(jù)log：Iphone6IP：8P7IP：77SBC信令代理IP：SBC媒體代理IP：從上述wiresharklog，可以比較容易找到“疑點(diǎn)”，SBC→iphone6的RTP報(bào)文，沒有解析為AMR-WBcodec，僅是解析到RTP包，PT=DynamicRTP-Type-116：而SBC→P7的RTP報(bào)文，均解析為AMR-WB：所以，我們懷疑iphone6側(cè)單通，是因?yàn)闊o法正常將RTP包解碼為AMR-WB導(dǎo)致的。那為何wireshark沒有將SBC發(fā)送給iphone6的RTP報(bào)文解析為AMR-WB呢？RTP媒體包收發(fā)規(guī)則是在VoIP呼叫建立過程中，通過SDPoffer/answer機(jī)制“協(xié)商”確定的，包括收發(fā)RTP包的IP地址，端口號(hào)，codec類型等。在上述流程中，主叫終端iphone6在SIP：INVITE消息中攜帶了SDPoffer，被叫終端P7在SIP：200OK中攜帶了SDPanswer：SIP：INVITE——SDPoffer：SIP：200OK——SDPanswer：從上述RTP媒體協(xié)商來看，iphone6在SDPoffer中攜帶了其支持的codec集合，按照優(yōu)先codec順序進(jìn)行了排序：P7在SDPanswer中攜帶了如下媒體信息：我們可以看出，iphone6和P7最終協(xié)商要采用的codec是相同的，都是bandwidth-efficientformatAMR-WB，但iphone6和P7所要使用的RTPPayloadType卻是不同的，再繼續(xù)看看RTP媒體中的PayloadType，發(fā)現(xiàn)iphone6發(fā)送的RTP包是采用的PT=116，P7發(fā)送端RTP包也是采用的PT=116，而PT116在iphone6SDPoffer中沒有包含，會(huì)不會(huì)是因?yàn)檫@個(gè)原因?qū)е耰phone6無法解碼相應(yīng)的RTP包而單通呢？問題分析到這里，我們要回答如下幾個(gè)問題：Q1：通話RTP包中的PT的取值到底是如何確定的？是應(yīng)該根據(jù)對(duì)端在SDPoffer/answer中給定的PT來發(fā)送？還是根據(jù)最終在SDPanswer中指定的PT來發(fā)送？Q2：主被叫都支持的是完全相同的codec，那到底如何確定PT類型呢？是否必須遵從SDPoffer中的PT嗎？Q3：相同的codec類型，是否必須要協(xié)商采用相同取值的PT呢？上述問題，翻查了幾個(gè)協(xié)議，整理如下：1）SDPoffer方接收的RTP包的Payloadtype必須為SDPoffer中的payloadtypenumber，SDPoffer方也希望在相應(yīng)的payloadtypenumber上發(fā)送RTP包2）協(xié)議上是允許SDPanswer中對(duì)相同的codec使用不同的payloadtypenumber。3）SDPoffer方必須根據(jù)SDPanswer中的payloadtypenumber來發(fā)送RTP包4）若SDPoffer和SDPanswer支持相同的codec，則建議SDPanswer采用與SDPoffer中相同的payloadtype。相關(guān)協(xié)議摘錄如下：RFC3264：5.1UnicastStreamsForrecvonlyRTPstreams,thepayloadtypenumbersindicatethevalueofthepayloadtypefieldinRTPpacketstheoffererisexpectingtoreceiveforthatcodec.ForsendonlyRTPstreams,thepayloadtypenumbersindicatethevalueofthepayloadtypefieldinRTPpacketstheoffererisplanningtosendforthatcodec.ForsendrecvRTPstreams,thepayloadtypenumbersindicatethevalueofthepayloadtypefieldtheoffererexpectstoreceive,andwouldprefertosend.However,forsendonlyandsendrecvstreams,theanswermightindicatedifferentpayloadtypenumbersforthesamecodecs,inwhichcase,theoffererMUSTsendwiththepayloadtypenumbersfromtheanswer.DifferentpayloadtypenumbersmaybeneededineachdirectionbecauseofinteroperabilityconcernswithH.323.6.1UnicastStreamsInthecaseofRTP,ifaparticularcodecwasreferencedwithaspecificpayloadtypenumberintheoffer,thatsamepayloadtypenumberSHOULDbeusedforthatcodecintheanswer（這里采用should來描述，表示建議，并不是強(qiáng)制）.Evenifthesamepayloadtypenumberisused,theanswerMUSTcontainrtpmapattributestodefinethepayloadtypemappingsfordynamicpayloadtypes,andSHOULDcontainmappingsforstaticpayloadtypes.7OffererProcessingoftheAnswerWhentheoffererreceivestheanswer,itMAYsendmediaontheacceptedstream(s)(assumingitislistedassendrecvorrecvonlyintheanswer).ItMUSTsendusingamediaformatlistedintheanswer,anditSHOULDusethefirstmediaformatlistedintheanswerwhenitdoessend.3GPP26.114A.3.1aSDPanswerfromanMTSIclientinterminalwhenonlynarrowbandspeechwasoffered回答了上述幾個(gè)問題，該單通問題的原因也就找到了：就是因?yàn)镻7終端發(fā)送的RTP媒體包中的Payloadtype取值不正確，導(dǎo)致iphone6側(cè)無法解碼相應(yīng)的RTP包而導(dǎo)致單通。Iphone6終端工程師針對(duì)該問題的答復(fù)與我們的分析是相同的，如下：此外，我們對(duì)比了正常的Iphone6呼叫mate7以及mate7呼叫iphone6的流程，這兩種場(chǎng)景下，SDPanswer都是遵從了SDPoffer中建議的Payloadtypenumber：【根因總結(jié)】通過上面分析，Iphone6呼叫P7單通問題（Iphone6側(cè)聽不到P7側(cè)話音），是因?yàn)镻7終端未根據(jù)SDPoffer/answer過程中協(xié)商的RTPpayloadnumber來正確填寫媒體包RTPHeader中的Payloadtype字段導(dǎo)致Iphone6無法解碼相應(yīng)的RTP包而出現(xiàn)單通?！窘鉀Q方案】該問題需P7終端修正相關(guān)bug【參考協(xié)議】（1）IETFRFC3264(2002):"AnOffer/AnswerModelwiththeSessionDescriptionProtocol(SDP)"（2）3GPPTS26.114:"IPMultimediaSubsystem(IMS);Multimediatelephony;Mediahandlingandinteraction".案例2：S國(guó)N局點(diǎn)VoIP概率單通問題分析【問題描述】eRan6.0,TDD,S國(guó)N局點(diǎn)WBBVoIP概率單通，需要分析原因。【問題分析】對(duì)于VoIP單通問題，通常我們需從VoIP媒體包“途經(jīng)”通道的網(wǎng)元節(jié)點(diǎn)采集log，根據(jù)log來確認(rèn)問題發(fā)生節(jié)點(diǎn)。LTEVoIP媒體通道如下：客戶反饋采用QCI1專用EPSbearer承載會(huì)概率出現(xiàn)語(yǔ)音單通，而采用QCI9缺省EPSbearer承載則不會(huì)出現(xiàn)語(yǔ)音單通問題，所以，我們需重點(diǎn)排查EPSbearer所經(jīng)歷的網(wǎng)元：LTECPE，eNodeB，S-GW/P-GW。4月28日，一線反饋單通復(fù)現(xiàn)后的相關(guān)log（客戶此次僅采集了問題發(fā)生后的數(shù)據(jù)log，未采集到問題發(fā)生時(shí)間點(diǎn)的log），分析發(fā)現(xiàn)：1）ThroughputMonitoring：QCI1承載ULRLC和DLRLC速率基本對(duì)稱，符合VoIP業(yè)務(wù)行為：注：?jiǎn)温稧.729語(yǔ)音IP層速率約為24kbps，ThroughputMonitoring中DL/ULRLC吞吐量是指RLCSDU/PDCPPDU的吞吐量：當(dāng)PDCPSNsize=7bits時(shí)，相應(yīng)的RLC吞吐量為24.4kbps；UserPlaneTrace->L2Performance->138跟蹤項(xiàng)，顯示僅有下行RTP媒體包，而無任何上行RTP媒體包為何ThroughputMonitoring中，QCI1承載上ULRLC吞吐量正常，而到138跟蹤中，卻沒有任何上行RTP媒體包信息呢？聯(lián)合FDD層二專家一起分析，采用FDD層二專家提供的“MyLDT”解析工具重新解析138跟蹤，發(fā)現(xiàn)并不是真的QCI1承載上ULPDCP層沒有數(shù)據(jù)包，而是ULPDCP層數(shù)據(jù)包是“壞包”，IpVersion字段已不是“4”，即：ULPDCP層數(shù)據(jù)包已經(jīng)不是“IPpacket”了。到此，問題鎖定在CPE和eNodeB之間。為何ULPDCP層數(shù)據(jù)包“壞”了呢？我們先看一下PDCP層對(duì)業(yè)務(wù)面數(shù)據(jù)所提供的功能：從PDCP層所提供的功能來看，很容易想到是因?yàn)椤敖饷堋边^程導(dǎo)致數(shù)據(jù)包“壞了”。后續(xù)重點(diǎn)分析為何解密過程出了問題。LTE加密/解密示意圖如下：加密/解密過程涉及如下參數(shù)，對(duì)于同一個(gè)PDCPSDU，必須采用相同的參數(shù)完成加密和解密過程，我們分析一下哪個(gè)參數(shù)會(huì)導(dǎo)致解密失敗呢：加密/解密參數(shù)32-bitCOUNT由兩部分組成：HFN和PDCPSN1）當(dāng)DRB承載建立時(shí)，UE和eNodeB側(cè)將HFN和PDCPSN均初始化為0.2）對(duì)于每一個(gè)PDCPSDU，PDCPSN++；3）當(dāng)PDCPSN達(dá)到Maximum_PDCP_SN，HFN++;PDCPSN會(huì)在每一個(gè)PDCPPDU中明文傳遞，而HFN則是由UE和eNodeB根據(jù)PDCPSN取值自行維護(hù)。 因此，COUNT中HFN失步將會(huì)導(dǎo)致解密過程異常，數(shù)據(jù)包壞掉。 根據(jù)理論分析和FDD專家經(jīng)驗(yàn)，導(dǎo)致HFN失步的最大可能性是連續(xù)丟包超過Maximum_PDCP_SN導(dǎo)致：AlossofsynchronizationoftheCOUNTvaluebetweentheUEandeNodeBcanthenonlyoccurifanumberofpacketscorrespondingtothemaximumSNarelostconsecutively.Inprinciple,theprobabilityofthiskindoflossofsynchronizationoccurringcouldbeminimizedbyincreasingthelengthoftheSN,eventotheextentoftransmittingthewholeCOUNTvalueineveryPDCPDataPDU.However,thiswouldcauseahighoverhead,andthereforeonlytheleastsigni?cantbitsareusedastheSN;theactualSNlengthdependsonthecon?gurationandtypeofPDU.——LTE–THEUMTSLONGTERMEVOLUTIONRLCUMmode對(duì)應(yīng)的PDCPSNsize有兩種：7bits和12bits。對(duì)于QCI1DRB承載，eNodeB產(chǎn)品默認(rèn)建議PDCPsize配置為7bits；即：當(dāng)出現(xiàn)連續(xù)丟棄128個(gè)PDCPSDU（即：IP包），就可能出現(xiàn)HFN失步；通常，一路VoIP語(yǔ)音，每20ms一個(gè)VoIP語(yǔ)音包，1s約50個(gè)語(yǔ)音包，對(duì)于N路話音場(chǎng)景，則1s約N*50個(gè)語(yǔ)音包；因此：1）當(dāng)網(wǎng)絡(luò)存在突發(fā)干擾或信道突然惡化2）當(dāng)同時(shí)通話話路所需帶寬大于QCI1承載GBR配置可能會(huì)因連續(xù)丟包導(dǎo)致HFN失步。連續(xù)丟包導(dǎo)致HFN失步，表現(xiàn)為加密端HFN>解密端HFN；該問題可以通過擴(kuò)展PDCPSNsize為12bits來解決?？蛻?月28日復(fù)現(xiàn)單通問題，并未采集到出現(xiàn)單通時(shí)的userplanetrace數(shù)據(jù)，所以，到底是否是因?yàn)檫B續(xù)丟包導(dǎo)致HFN失步并無法確認(rèn)。直到客戶在5月5日反饋4月29日時(shí)復(fù)現(xiàn)的單通log，TDD研發(fā)層二專家分析133跟蹤項(xiàng)后，初步懷疑是PDCP層數(shù)據(jù)包亂序?qū)е翲FN失步，并不是之前理論分析的連續(xù)丟包導(dǎo)致HFN失步。1、標(biāo)紅代表出問題的時(shí)間點(diǎn)（138跟蹤解密后的數(shù)據(jù)的IP頭都異常了），在出問題前，基本1s有100個(gè)包左右（2路VoIP話路，1s約100個(gè)VoIP媒體包），PDCP入口的包數(shù)量跟基站維護(hù)的HFN,SN計(jì)算的包數(shù)量一致；在出問題的時(shí)間點(diǎn)，可以發(fā)現(xiàn)PDCP入口收到的包數(shù)量還是100左右，而基站維護(hù)的HFN,SN計(jì)算出的包數(shù)量增加了224個(gè)，兩者之間剛好差128（對(duì)應(yīng)7bitPDCPSN配置），此差異是由于基站的HFN調(diào)整導(dǎo)致的?；綡FN調(diào)整的過程：PDCP每收到一個(gè)包，首先解析包頭，獲取SN號(hào)，然后對(duì)SN號(hào)進(jìn)行判斷，如果SN號(hào)比基站預(yù)期要接收到的SN號(hào)小，則基站認(rèn)為中間有丟包且HFN應(yīng)該要加1。由于出問題的時(shí)候，基站維護(hù)的包數(shù)量剛好比真實(shí)的包數(shù)量多128，認(rèn)為丟包剛好丟128個(gè)的可能性比較少，因此認(rèn)為PDCPSN號(hào)亂序的可能性較大（從eNodeBULPDCP在HFN自行調(diào)整前后PDCP層收到數(shù)據(jù)包個(gè)數(shù)來看，VoIP話路數(shù)并未改變，因此，也可以確認(rèn)空口并未發(fā)生連續(xù)丟包，HFN自行調(diào)整是因亂序引入。）。例如：如果基站收到的包并沒有丟，而只是SN號(hào)亂序，例如：1,3,2,4,基站收到的這類包后HFN就會(huì)調(diào)整加1，而維護(hù)的總包數(shù)也會(huì)剛好比真實(shí)包數(shù)多128。2、分析上行調(diào)度49號(hào)跟蹤，出問題時(shí)間點(diǎn)附近的誤幀、MCS、RB數(shù)，調(diào)度間隔都沒有異常，基本排除空口傳輸異常的可能性——TDD層二專家分析結(jié)論從一線單通獲取日志，無法定位是什么原因?qū)е翽DCP層數(shù)據(jù)包亂序，包括eNodeB側(cè)log信息因流控有信息丟失，并且B222終端無法采集空口相關(guān)log：1、133號(hào)跟蹤中的PDCP_Trace_Type_PktLoss內(nèi)容項(xiàng)有丟失，49號(hào)跟蹤內(nèi)容也有丟失，應(yīng)該是被流控掉了，無法判斷基站側(cè)PDCP層具體收到的包的SN號(hào)不連續(xù)的具體情況2、分析RLC142號(hào)跟蹤，在出問題的時(shí)刻，RLC剛好檢測(cè)到有重復(fù)RLC包；而到出問題前，RLC共檢測(cè)到重復(fù)RLC包11次；由于49號(hào)跟蹤數(shù)據(jù)丟失很嚴(yán)重，無法把調(diào)度跟RLC檢測(cè)到重復(fù)包進(jìn)行關(guān)聯(lián)——TDD層二專家分析結(jié)論P(yáng)DCP數(shù)據(jù)包亂序?qū)е翲FN失步，表現(xiàn)為加密端HFN<解密端HFN；該問題可以在eNodeB上開啟countercheck功能來規(guī)避：eNodeBcountercheck功能用于與UE核查安全參數(shù)COUNT是否一致，如果出現(xiàn)加密端HFN<解密端HFN，當(dāng)COUNTERCHECKUSERRELSWITCH=ON，eNodeB會(huì)觸發(fā)該承載釋放（E-RABRelease）。研發(fā)實(shí)驗(yàn)室人為構(gòu)造上述兩種HFN失步場(chǎng)景，驗(yàn)證相應(yīng)規(guī)避方案有效后，提供給一線實(shí)施：一線反饋客戶執(zhí)行規(guī)避方案后，現(xiàn)網(wǎng)仍出現(xiàn)單通問題。經(jīng)分析確認(rèn)：1）擴(kuò)大PDCPSNsize后仍有單通問題：說明現(xiàn)網(wǎng)大部分單通問題不是因連續(xù)丟包導(dǎo)致HFN失步；2）開啟countercheck后仍有單通問題：經(jīng)確認(rèn)，一線客戶執(zhí)行countercheck功能有誤，我們建議配置：MODCOUNTERCHECKPARA:COUNTERCHECKCOUNTNUM=128,COUNTERCHECKUSERRELSWITCH=ON;而客戶執(zhí)行配置為：MODCOUNTERCHECKPARA:COUNTERCHECKTIMER=128,COUNTERCHECKUSERRELSWITCH=ON;COUNTERCHECKTIMER配置為128表示每128s執(zhí)行一次countercheck功能；而我們是建議每128個(gè)包執(zhí)行一次countercheck功能（若單路呼叫，相當(dāng)于2.5s執(zhí)行一次countercheck功能）。實(shí)驗(yàn)室復(fù)現(xiàn)下行單通時(shí)，分析eNodeBlog，確認(rèn)：eNodeB下行發(fā)送的