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

導讀本文根據以往網上問題整理VoLTE相關問題的相關案例，在處理網上語音問題時，可以先翻閱本文相關案例，以拓展思路并縮小問題范圍，最終提升問題定位效率。本文所包含案例包括從各產品收集到的歷史案例，以及GTACVoLTE專題組啟動后處理的問題提取出來的案例，在案例格式上有些差異，后續逐步統一。本文檔會逐步完善，新需求或建議，請聯系xxxx00130333。

語音呼叫類問題呼叫失敗案例1：英國VDF，VoLTE用戶呼叫失敗問題分析【問題描述】英國VDF在11月15號下午反饋同一終端同一套核心網，在愛立信/諾西基站下成功打通VoLTEcall，在xx基站下必然失敗；問題表現為：VoLTE終端開機后，QCI5、默認承載均可建立但無法建立QCI1導致不能通話；【問題分析】1.組網環境信息分析1.1VoLTE業務原理分析正常VoLTE業務流程分為以下幾個過程：VoLTE終端完成TAUAttach流程建立QCI5承載；VoLTE終端發起IMS注冊流程,注冊使用的SIP信令使用QCI5承載；VoLTE終端發起語音呼叫，建立QCI1專有承載，語音媒體使用QCI1承載；VoLTE終端發起視頻呼叫，建立QCI2專有承載，視頻媒體使用QCI2承載；圖1：正常VoLTE用戶注冊流程圖2：正常VoLTE用戶語音呼叫流程圖3：VoLTE業務所使用的承載方式1.2網絡拓撲分析11.18日下午，一線實驗室復測抓取了S-PGWP-CSCF上的抓包。分析xx和愛立信基站下主要有如下兩個差異點

1)xx基站下注冊的終端是諾基亞，愛立信基站下注冊的終端型號未知。2）注冊到xx的register消息是通過TCP承載，且在TCP層有分包，對端SBC回503serviceunavailable，而注冊到愛立信的register消息是UDP承載，無分包，對端SBC正常回復401。通過多次抓包和定點分析最終確定網絡拓撲圖如下：圖4：英國VDF實驗室組網圖B2.分段隔離分析針對現場所有xx站點分析，現場總共有6個xx站點PTH100/101/102/104/110/112，而發現在xxPTH102站點(未配置IPSEC)進行測試，VoLTE業務有大概率60%左右成功率(剩余40%失敗主要和核心網相關)，當時已經懷疑和IPSEC隧道(SeGW節點)強相關。進一步鎖定在PTH112站點(配置IPSEC)分析，通過修改S1接口上鏈路，嘗試旁路CPN和SeGW，并且修改IPSec加密算法為空加密等方案后，發現VoLTE業務均能建立成功，最終問題隔離到和IPSEC相關。2.1IPSec旁路方案一圖5：IPSec旁路方案一安全網關SeGW旁路之后，基站配置不變，基站的下一跳地址配置到跟SGE比較靠近的路由器上，基站直接拉線到該路由器；VoLTE業務測試結果為OK。此旁路方案同PTH102站點，102站點沒有配置IPSec，從102站點的S1用戶面地址pingSpGW地址，8000字節的報文都可以ping通，整條鏈路沒有報文大小限制。2.2IPSec旁路方案二圖6：IPSec旁路方案二相對于方案一，方案二直接把在連接安全網關SeGW兩端的路由器互聯，基站配置不變；VoLTE業務測試結果為OK。2.3IPSec旁路方案三圖7：IPSec旁路方案三方案三實際上沒有改變組網，而是將基站和安全網關的IPSECPROPOSAL的加密算法設置為NULL，驗證算法不改；VoLTE業務測試結果為失敗。同時抓取路由器和安全網關兩端報文，確認SIP_401消息已經從安全網關發送到基站；此時排查重點轉移到基站，需要確認eNodeB是否成功轉發401消息；3.eNodeB版本和配置以及話統分析檢查eNodeB版本：BTS3900V100R009C00SPC160；檢查EUTRAN支持VoIP能力開關：ENodeBAlgoSwitch.EutranVoipSupportSwitch=ON；檢查小區信號質量：正常；檢查數傳業務成功率：正常；檢查所有基站配置和VoLTE業務：總共6個基站PTH100/101/102/104/110/112，VoLTE均失敗；檢查話統話統來確認QCI5是否丟包：話統正常無丟包；CellDT和IFTS跟蹤：確認eNodeB的PDCP和MAC層無丟包且調度正常；eNodeB跟蹤CELLDT和終端側QXDM數據分析從Celldt132跟蹤看，有些時候VoLTE建立的時候QCI5的下行有數據包，有些時候又沒有下行數據包。從CELLDT34看，下行都是ACK，說明空口發送QCI5數據時沒有誤碼。終端側QXDM看到，QCI5的RBID為2，該RB下行也收到了數據包，但有時這些數據包能到PDCP層，有些到不了PDCP層，但是SIP層都收不到，不確定這些數據包是否就是401消息。4.異常問題流程分析由于前期從英國VDF一線和羅馬尼亞GTAC二線得到信息是終端收不到SIP_401消息，前后方重點都放在下行SIP_401丟失問題上，但是前面分析SeGW證實已經下發；而eNodeBeRAN7.0使用CellDT、IFTS、話統等都無法準確判斷401是否從S1和UU接口轉發，現場的終端Nokia和Sony也都不具備QXDM抓包條件；問題分析未能取得突破進展。為了統一思路前后方重新整理問題和思路尋求新的突破口，正對不同終端在同一個xx站點PTH112下面驗證總共得到以下3種失敗場景如下：Case1:VoLTE注冊過程中網絡下發401鑒權挑戰消息，終端未收到；圖9：Case1網絡下發鑒權挑戰401終端未收到Case2:Sony終端基于UDP的Register消息異常；圖10：Case2Sony終端基于UDP的注冊失敗Case3:Nokia終端基于TCP的Register消息異常；圖11：Case3Nokia終端基于TCP的注冊失敗根據以上3種失敗場景，根據不同終端和網元節點跟蹤定位分析確定如下失敗模型；至此很明顯最初得到的Case1所描述的失敗類型是一個錯誤的判斷，是因為Nokia和Sony終端不同的失敗表現產生混淆導致：5.友商成功數據分析針對相同終端在IMS側抓包，分別從E///站點和xx站點比較分析，發現E///站點和xx站點的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至此，通過以上分析判斷排除終端和核心網異常；而從P1點抓包來看也能夠確認eNodeB成功轉發了Register和401Unauthorized消息。6.諸點抓包分析通過xx站點和E///站點對比分析，已經明確問題出現在S1接口所連接設備上面，但是由于eRAN7.0版本(內部確認eRAN8.0以上版本可以)不具備SIP信令跟蹤和足夠的證據，來證明eNodeB成功轉發SIP消息；即便我們能夠證明PDCP和MAC無丟包且調度正常。根據現場組網信息啟動網絡逐點抓包隔離異常網元，開始嘗試Ping不同大小報文并且抓包分析結果如下：對Nokia和Sony兩款終端異常場景抓包分析發現P3段會丟棄大于1500Bytes的報文，統計數據結果如下：同時對Nokia和Sony兩款終端在友商E///抓包分析發現報文在P3段傳輸固定為1420Bytes的報文，統計數據結果如下：至此，發現丟包問題最終鎖定在P3(SeGW-->CPN)抓包段，并且此段只會丟棄大于1490Bytes的報文；而對比友商E///網絡傳送的1420Bytes報文能夠成功傳輸；最終問題鎖定在SeGW和CPN網元節點。7.UE側問題分析7.1xxP7 現場使用的P7不支持VoLTE，臨時升級到研發內部版本但是仍然測試失敗;通過測試發現P7使用的SIP基于UDP承載，并且Register消息總共才1172Bytes，MTU值可通過root權限配置但是設置未生效；待進一步驗證。P7升級到測試成功，但在E///的基站下，接入失敗。IMS直接回494消息，CN側抓包如下：如下是P7失敗和sony成功（E///基站）的對比，差異如紅圈出，但P7發送的也符合協議RFC3329.對比協議，P7發送的register消息，是符合協議的，需聯合IMS確認，其發送494的原因。RFC3329定義的SIP協商安全傳輸機制：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.協議RFC3329要求494必帶Security-Server頭域

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

TheserverMUSTaddaSecurity-Serverheaderfieldtothisresponseistingthesecuritymechanismsthattheserversupports.

TheserverMUSTadditslisttotheresponseeveniftherearenocommonsecuritymechanismsintheclient'sandserver'slists.

Theserver'slistMUSTNOTdependonthecontentsoftheclient'slist.愛立信核心網回的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綜上所述發現P7終端VoLTE業務失敗原因為SIP協商安全傳輸機制失敗，由于P7使用測試版本有可能不支持IPSec加密算法”ealg=null;”原因，導致友商E///的IMSCore直接拒絕；而P7終端在研發內部測試VoLTE業務成功，使用的是xxCN兼容性更高。7.2NokiaLumia830現場使用的Nokia終端，WindowsPhone操作系統Lumia系列手機；通過測試發現Nokia終端使用的SIP基于TCP承載，并且第一條Register消息的大分片報文為1360Bytes，第二條Register消息的大分片報文為1480Bytes；Nokia的MTU值通過信令判斷為1480，具體配置待繼續研究；7.3SonyXperiaZ2現場使用的Sony終端，安卓操作系統；通過測試發現Sony終端使用的SIP基于UDP承載，并且第一條Register消息的大分片報文為1500Bytes，第二條Register消息的大分片報文為1500Bytes；Nokia的MTU值通過信令判斷為1500，具體配置待繼續研究；8.eNodeB側問題分析8.1xxeNodeB版本為BTS3900V100R009C00SPC160，此系列版本無SIP信令跟蹤，并且不能基于CellDT和IFTS跟蹤判斷SIP消息；即eRAN7.0版本無有效定位SIP信令的手段。//已經確認eRAN8.0以上版本可跟蹤SIP消息。通過對比xx和E///報文分析，發現MTU實現差異如下，xxeNodeB經過加密后在IPSEC以下IP層進行MTU(1500)分包；SeGW收到后會進行組包再解密，解密后如果報文大于SeGW的MTU設置會再次進行分片處理；8.2E///eNodeB 通過對比xx和E///報文分析，發現MTU實現差異如下，友商E///可以實現在IPSEC以上IP層進行MTU(1420)分包，即先將業務報文分片再進行獨立加密傳輸；SeGW收到后對報文解密而不需要組包，這樣避免了傳輸過程中再次組包和分片的操作；其IPSEC是通過獨立單板實現；8.3NSNeNodeB NSNeNodeB暫時未抓取報文，但是相同組網其站點下業務能夠成功說明其實現也有類似業務分片機制；NSN具體實現方式待后續驗證9.傳輸問題分析根據現場網絡拓撲和組網進行分段Ping包，能夠快速進行分段隔離異常網元；通過現場測試不同大小報文的Ping結果，發現異常點主要集中在P3抓包點，而P3抓包點為SeGW—>CPN互聯方向；P3點報文大于1490Bytes都被丟棄，而SeGW組包后解密再分片的小包能夠正常傳輸，最初問題鎖定在T5(SeGW)和T6(CPN)兩個端點； 通過多次修改SeGW和CPN端口的MTU值嘗試Ping包測試，并且結合現場CPN抓包鏡像端口M，實際抓包端口M也是CPN物理端口，此端口M通過鏡像T2/T3/T6/T7實現Wireshark抓包的，丟包點再次確認為T6(CPN)和T7(CPN)兩個端點；即T6實際收到報文且出現異常丟棄導致沒有發送給鏡像端口M。再次檢查整條鏈路中各節點MTU配置，統一修改eNodeB(T1)、T2、T3、T4、T5、T6、T7MTU為1700Bytes，再次檢查SeGW的PathMTU為1700；最終Ping報文1601Bytes能夠成功，驗證VoLTE業務成功。Ping結果如下：【問題根因】問題結論簡述：現象為VoLTE用戶注冊失敗，上行傳輸網絡有大包限制和丟棄問題；處理問題過程中發現eRAN7.0BTS3900V100R009C00SPC160版本存在兩點不足：1）、eRAN7.0以前版本不支持SIP信令跟蹤，缺乏有效手段定位SIP消息轉發情況；2）、xxeNodeB對不支持按照業務報文分片處理，雖然符合協議但是與友商靈活實現機制相比；xxeNodeB實現方式優勢：可以減少傳輸網絡負荷，提高傳輸效率；xxeNodeB實現方式缺點：安全網關SeGW需要組包，增加對組網傳輸網路MTU限制的要求；RFC:791【解決方案】解決英國VDF的VoLTE問題，根據現場訴求提供兩種方案：方案1）、建議現場檢查全網設備節點的MTU設置，通過Ping報文確認S1口(eNodeB-->SpGW)能夠ping通至少1600Bytes報文；研發根據現場組網提供推薦配置和現場實際成功配置如下：方案2）、xxeNodeB根據現場訴求實現按照業務報文分片處理功能，待最終討論確認正式版本；案例2：iphone6做主叫VoLTE呼叫失敗問題分析【問題描述】西研實驗室進行iphone6VoLTE測試，iphone6VoLTESIPRegistration成功，但iphone6作為主叫呼叫P7，呼叫失敗；而P7呼叫iphone6是正常的。【問題分析】1、根據問題現象，屬于VoLTE呼叫建立失敗問題，這類問題，從語音核心網IMS側入手分析VoLTE呼叫控制面SIP信令效率較高。eNodeB/S-GW/P-GW主要負責將SIP信令（承載在QCI5EPSbearer上）在UE和P-CSCF間正確轉發，如下為LTE終端與LTE終端呼叫示意圖，其中，黑色虛線為VoLTE呼叫建立所涉及到的網元：流程簡述：LTE用戶發起呼叫。MMTelAS執行主叫業務處理。完成主叫業務處理后，MMTelAS將呼叫路由回S-CSCF；S-CSCF查詢ENUM，并將呼叫路由到被叫。在被叫側，呼叫被路由到向被叫用戶提供業務的I-CSCF，I-CSCF發送呼叫請求到S-CSCF。MMTelAS執行被叫業務處理后，MMTelAS將呼叫路由回S-CSCF；S-CSCF觸發SCCAS進行域選（即選擇被叫落地的域），選擇LTE網絡接入被叫用戶。S-CSCF將呼叫請求通過P-CSCF接續到被叫用戶。承載建立。2、如下為測試同事在SBC側鏡像抓包采集的log：從上面可以看出，當Iphone6發起VoLTE呼叫時，Iphone6先觸發建立TCPconnection，但SBC卻沒有響應，經確認，我司SBCSE2600在作為A-SBC時，缺省情況下，僅支持SIPoverUDP，SIPoverTCP為可選特性，需要相關license和相關配置才能支持，如下內容摘自SE2600產品手冊：注：SE2600部署在IP網絡的邊緣或匯聚層，是會話信令和媒體流的聚合點。SE2600作為信令代理和媒體代理設備。通過對信令和媒體的處理，SE2600實現拓撲隱藏、NAT（NetworkAddressTranslation）/防火墻穿越等功能。A-SBCSIP代理功能包括信令代理和媒體代理。信令代理：對SIP信令報文的解析、處理和轉發。媒體代理：對音頻、視頻等媒體流的代理。3、測試同事在SBC上補充SIPoverTCP相關配置后，再進行測試，發現仍是無法呼叫，log如下：經測試同事咨詢SE2600同事，該問題確認為：Iphone6在SIPRegistration過程中采用的是UDP傳輸協議，而在發起VoLTE呼叫時，采用的是TCP傳輸協議，我司SE2600不支持這種場景，僅支持對于同一個UA，所有SIP消息都采用UDP協議或TCP協議。所以，導致iphone6終端作為主叫時，VoLTE呼叫無法建立。問題分析到這里，我們會有個疑問，那到底SE2600的問題，還是Iphone6的問題呢？翻查了一下RFC3261SIP協議（18Transport章節），18.1.1SendingRequestsIfarequestiswithin200bytesofthepathMTU,orifitislargerthan1300bytesandthepathMTUisunknown,therequestMUSTbesentusinganRFC2914[43]congestioncontrolledtransportprotocol,suchasTCP.18.2.1ReceivingRequestsForanyportandinterfacethataserverlistensonforUDP,itMUSTlistenonthatsameportandinterfaceforTCP.ThisisbecauseamessagemayneedtobesentusingTCP,ratherthanUDP,ifitistoolarge.Asaresult,theconverseisnottrue.AserverneednotlistenforUDPonaparticularaddressandportjustbecauseitislisteningonthatsameaddressandportforTCP.Theremay,ofcourse,beotherreasonswhyaserverneedstolistenforUDPonaparticularaddressandport.大致理解如下：SIP協議是基于transaction的協議，每個transaction應該都可以根據SIP消息需求場景決定所要采用的傳輸協議。而且，SIP協議也要求大于1300字節的SIPRequest消息使用支持擁塞控制的傳輸層協議（如：TCP）。所以，該問題應該是SE2600的兼容性不夠導致的問題，Iphone6的實現沒有錯。【問題根因】Iphone6終端在VoLTESIPRegistration過程中采用了SIPoverUDP，發起VoLTE呼叫時，采用了SIPoverTCP，而我司SE2600不支持場景，SE2600只支持對于同一個UA，所有SIP消息都采用UDP協議或TCP協議。所以，出現了Iphone6注冊成功，但做主叫時，呼叫無法建立的問題。該問題根因是SE2600產品兼容性問題，我司SBC下一代產品SE2900會支持上述場景。【解決方案】1）目前，西研實驗室下，由Iphone6臨時加載補丁，使得Iphone6在SIPRegistration和VoLTE呼叫過程中都采用UDP傳輸協議來規避。2）也可以考慮部署SE2900設備來解決（SE2900的SIPoverTCP是產品基礎特性，不再受license限制）。案例:3：UE未發送INVITE消息導致電話呼叫失敗的問題分析【問題描述】一線反饋VoLTE電話呼叫失敗【問題分析】1、終端撥打電話時，基站側的Uu口和S1口沒有建立QCI1的承載2、QCI1的建立條件：只有在MME在收到SIP消息后才會觸發QCI1的承載建立。由于在基站側看到沒有建QCI1，所以懷疑MME沒有收到SIP消息。3、通過UE側的QXDM抓包，確認UE沒有在撥打電話時沒有發送INVITE消息，所以呼叫失敗。4、復位手機后，問題現象消失，QXDM抓包如下【問題根因】UE沒有在撥打電話時沒有發送INVITE消息【解決方案】需要終端分析不發送invite消息的原因。本案例中復位手機可以解決該問題。案例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///處理異常導致UE從xx基站切換到E///基站后，語音中斷【問題描述】阿聯酋+ET，V100R008C00SPC260，客戶在實驗室測試，發現從xx基站切換到E///基站后，語音通話中斷，從E///切換到xx，沒有問題。【問題分析】1.UE側日志分析。（一線只反饋了UE側日志的截圖，沒有反饋具體的日志信息）從圖1和圖2對比分析，切換后語音中斷出現在PCI=381（我司基站）往PCI=16（E///基站）切換以后；PCI=16往PCI=381切換沒有問題。從切換流程分析，兩次切換均成功。排除切換失敗導致的語音中斷。圖1.切換后出現通話中斷圖2.切換后通話正常2.eNB側日志分析由于語音業務需要建立qci5和qci1的承載，所以接下來需要分析，切換后qci5和qci1是否建立正常。1）handoverrequestack消息對比分析：當UE從PCI=381的站點切換到PCI=16的站點時，qci1的承載準入失敗。由此找到了語音中斷的原因：切換到E///后，qci1準入失敗。2）handoverrequest消息對比分析：qci1的開戶信息一致，無異常；排除切換后qci1開戶信息不一致導致的準入失敗。由此需要進一步分析qci1的空口配置信息是否一致。qci1空口配置分析：RLCSNsize配置不一致。我司切換到E///基站時，qci1的RLCSNSize=5bit；而從E///基站切換回來時，qci1的RLCSNSize=10bit。由此推測：我司基站qci1的RLCSNSize配置的5bit；E///基站qci1的RLCSNSize配置的10bit。3、在其他局點遇到過類似問題，當E///基站配置的SNSize和他收到的切換命令中的SNsize不一致時，E///基站處理會出問題，導致承載準入失敗。4、一線將我司基站qci1的RLCSNsize配置成10bit后，問題可以規避。【問題根因】當E///基站配置的SNSize和他收到的切換命令中的SNsize不一致時，E///基站處理會出問題，導致承載準入失敗。需要E///給出根因。我司基站做了兼容性處理，當基站配置的SNSize和收到的切換命令中的SnSize不一致時，會選擇基站配置的SNsize下發給UE，不會準入失敗。【解決方案】將我司基站qci1的RLCSNsize和E///基站配置一致，可以規避該問題。案例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單通分析【問題描述】西研實驗室采用iphone6，HuaweiP7，Huaweimate7終端進行VoLTEIOT測試，發現iphone6呼叫P7出現單通問題，iphone6聽不到P7側語音，而其他場景下，語音均正常：【問題分析】根據測試同事反饋，iphone6呼叫P7時，單通問題必現，并且均為iphone6聽不到P7話音，而其他呼叫場景，包括P7呼叫iphone6，iphone6呼叫mate7等，呼叫都正常，所以，該問題初步懷疑是iphone6與P7之間因兼容性問題導致單通，與其他網元無關。對于這種實驗室內必現的單通問題，網元側數據采集比較方便，問題是比較容易分析的。如下為LTE終端與LTE終端呼叫示意圖，其中，黑色虛線為VoLTE呼叫建立所涉及到的網元，藍色實線為媒體RTP包所經歷路徑：從上圖可以看出，SBC是VoLTESIP信令和RTP媒體都經過的網元，實驗室內SBC可以通過鏡像抓包采集到SIP信令和RTP媒體包，并且可以通過wireshark進行數據分析，因此，該問題優先選擇在SBC網元（實驗室為我司SE2600）采集數據包進行分析。如下為SBC網元iphone6呼叫P7數據log：Iphone6IP：8P7IP：77SBC信令代理IP：SBC媒體代理IP：從上述wiresharklog，可以比較容易找到“疑點”，SBC→iphone6的RTP報文，沒有解析為AMR-WBcodec，僅是解析到RTP包，PT=DynamicRTP-Type-116：而SBC→P7的RTP報文，均解析為AMR-WB：所以，我們懷疑iphone6側單通，是因為無法正常將RTP包解碼為AMR-WB導致的。那為何wireshark沒有將SBC發送給iphone6的RTP報文解析為AMR-WB呢？RTP媒體包收發規則是在VoIP呼叫建立過程中，通過SDPoffer/answer機制“協商”確定的，包括收發RTP包的IP地址，端口號，codec類型等。在上述流程中，主叫終端iphone6在SIP：INVITE消息中攜帶了SDPoffer，被叫終端P7在SIP：200OK中攜帶了SDPanswer：SIP：INVITE——SDPoffer：SIP：200OK——SDPanswer：從上述RTP媒體協商來看，iphone6在SDPoffer中攜帶了其支持的codec集合，按照優先codec順序進行了排序：P7在SDPanswer中攜帶了如下媒體信息：我們可以看出，iphone6和P7最終協商要采用的codec是相同的，都是bandwidth-efficientformatAMR-WB，但iphone6和P7所要使用的RTPPayloadType卻是不同的，再繼續看看RTP媒體中的PayloadType，發現iphone6發送的RTP包是采用的PT=116，P7發送端RTP包也是采用的PT=116，而PT116在iphone6SDPoffer中沒有包含，會不會是因為這個原因導致iphone6無法解碼相應的RTP包而單通呢？問題分析到這里，我們要回答如下幾個問題：Q1：通話RTP包中的PT的取值到底是如何確定的？是應該根據對端在SDPoffer/answer中給定的PT來發送？還是根據最終在SDPanswer中指定的PT來發送？Q2：主被叫都支持的是完全相同的codec，那到底如何確定PT類型呢？是否必須遵從SDPoffer中的PT嗎？Q3：相同的codec類型，是否必須要協商采用相同取值的PT呢？上述問題，翻查了幾個協議，整理如下：1）SDPoffer方接收的RTP包的Payloadtype必須為SDPoffer中的payloadtypenumber，SDPoffer方也希望在相應的payloadtypenumber上發送RTP包2）協議上是允許SDPanswer中對相同的codec使用不同的payloadtypenumber。3）SDPoffer方必須根據SDPanswer中的payloadtypenumber來發送RTP包4）若SDPoffer和SDPanswer支持相同的codec，則建議SDPanswer采用與SDPoffer中相同的payloadtype。相關協議摘錄如下：RFC3264：5.1UnicastStreamsForrecvonlyRTPstreams,thepayloadtypenumbersindicatethevalueofthepayloadtypefieldinRTPpacketstheoffererisexpectingtoreceiveforthatcodec.ForsendonlyRTPstreams,thepayloadtypenumbersindicatethevalueofthepayloadtypefieldinRTPpacketstheoffererisplanningtosendforthatcodec.ForsendrecvRTPstreams,thepayloadtypenumbersindicatethevalueofthepayloadtypefieldtheoffererexpectstoreceive,andwouldprefertosend.However,forsendonlyandsendrecvstreams,theanswermightindicatedifferentpayloadtypenumbersforthesamecodecs,inwhichcase,theoffererMUSTsendwiththepayloadtypenumbersfromtheanswer.DifferentpayloadtypenumbersmaybeneededineachdirectionbecauseofinteroperabilityconcernswithH.323.6.1UnicastStreamsInthecaseofRTP,ifaparticularcodecwasreferencedwithaspecificpayloadtypenumberintheoffer,thatsamepayloadtypenumberSHOULDbeusedforthatcodecintheanswer（這里采用should來描述，表示建議，并不是強制）.Evenifthesamepayloadtypenumberisused,theanswerMUSTcontainrtpmapattributestodefinethepayloadtypemappingsfordynamicpayloadtypes,andSHOULDcontainmappingsforstaticpayloadtypes.7OffererProcessingoftheAnswerWhentheoffererreceivestheanswer,itMAYsendmediaontheacceptedstream(s)(assumingitislistedassendrecvorrecvonlyintheanswer).ItMUSTsendusingamediaformatlistedintheanswer,anditSHOULDusethefirstmediaformatlistedintheanswerwhenitdoessend.3GPP26.114A.3.1aSDPanswerfromanMTSIclientinterminalwhenonlynarrowbandspeechwasoffered回答了上述幾個問題，該單通問題的原因也就找到了：就是因為P7終端發送的RTP媒體包中的Payloadtype取值不正確，導致iphone6側無法解碼相應的RTP包而導致單通。Iphone6終端工程師針對該問題的答復與我們的分析是相同的，如下：此外，我們對比了正常的Iphone6呼叫mate7以及mate7呼叫iphone6的流程，這兩種場景下，SDPanswer都是遵從了SDPoffer中建議的Payloadtypenumber：【根因總結】通過上面分析，Iphone6呼叫P7單通問題（Iphone6側聽不到P7側話音），是因為P7終端未根據SDPoffer/answer過程中協商的RTPpayloadnumber來正確填寫媒體包RTPHeader中的Payloadtype字段導致Iphone6無法解碼相應的RTP包而出現單通。【解決方案】該問題需P7終端修正相關bug【參考協議】（1）IETFRFC3264(2002):"AnOffer/AnswerModelwiththeSessionDescriptionProtocol(SDP)"（2）3GPPTS26.114:"IPMultimediaSubsystem(IMS);Multimediatelephony;Mediahandlingandinteraction".案例2：S國N局點VoIP概率單通問題分析【問題描述】eRan6.0,TDD,S國N局點WBBVoIP概率單通，需要分析原因。【問題分析】對于VoIP單通問題，通常我們需從VoIP媒體包“途經”通道的網元節點采集log，根據log來確認問題發生節點。LTEVoIP媒體通道如下：客戶反饋采用QCI1專用EPSbearer承載會概率出現語音單通，而采用QCI9缺省EPSbearer承載則不會出現語音單通問題，所以，我們需重點排查EPSbearer所經歷的網元：LTECPE，eNodeB，S-GW/P-GW。4月28日，一線反饋單通復現后的相關log（客戶此次僅采集了問題發生后的數據log，未采集到問題發生時間點的log），分析發現：1）ThroughputMonitoring：QCI1承載ULRLC和DLRLC速率基本對稱，符合VoIP業務行為：注：單路G.729語音IP層速率約為24kbps，ThroughputMonitoring中DL/ULRLC吞吐量是指RLCSDU/PDCPPDU的吞吐量：當PDCPSNsize=7bits時，相應的RLC吞吐量為24.4kbps；UserPlaneTrace->L2Performance->138跟蹤項，顯示僅有下行RTP媒體包，而無任何上行RTP媒體包為何ThroughputMonitoring中，QCI1承載上ULRLC吞吐量正常，而到138跟蹤中，卻沒有任何上行RTP媒體包信息呢？聯合FDD層二專家一起分析，采用FDD層二專家提供的“MyLDT”解析工具重新解析138跟蹤，發現并不是真的QCI1承載上ULPDCP層沒有數據包，而是ULPDCP層數據包是“壞包”，IpVersion字段已不是“4”，即：ULPDCP層數據包已經不是“IPpacket”了。到此，問題鎖定在CPE和eNodeB之間。為何ULPDCP層數據包“壞”了呢？我們先看一下PDCP層對業務面數據所提供的功能：從PDCP層所提供的功能來看，很容易想到是因為“解密”過程導致數據包“壞了”。后續重點分析為何解密過程出了問題。LTE加密/解密示意圖如下：加密/解密過程涉及如下參數，對于同一個PDCPSDU，必須采用相同的參數完成加密和解密過程，我們分析一下哪個參數會導致解密失敗呢：加密/解密參數32-bitCOUNT由兩部分組成：HFN和PDCPSN1）當DRB承載建立時，UE和eNodeB側將HFN和PDCPSN均初始化為0.2）對于每一個PDCPSDU，PDCPSN++；3）當PDCPSN達到Maximum_PDCP_SN，HFN++;PDCPSN會在每一個PDCPPDU中明文傳遞，而HFN則是由UE和eNodeB根據PDCPSN取值自行維護。 因此，COUNT中HFN失步將會導致解密過程異常，數據包壞掉。 根據理論分析和FDD專家經驗，導致HFN失步的最大可能性是連續丟包超過Maximum_PDCP_SN導致：AlossofsynchronizationoftheCOUNTvaluebetweentheUEandeNodeBcanthenonlyoccurifanumberofpacketscorrespondingtothemaximumSNarelostconsecutively.Inprinciple,theprobabilityofthiskindoflossofsynchronizationoccurringcouldbeminimizedbyincreasingthelengthoftheSN,eventotheextentoftransmittingthewholeCOUNTvalueineveryPDCPDataPDU.However,thiswouldcauseahighoverhead,andthereforeonlytheleastsigni?cantbitsareusedastheSN;theactualSNlengthdependsonthecon?gurationandtypeofPDU.——LTE–THEUMTSLONGTERMEVOLUTIONRLCUMmode對應的PDCPSNsize有兩種：7bits和12bits。對于QCI1DRB承載，eNodeB產品默認建議PDCPsize配置為7bits；即：當出現連續丟棄128個PDCPSDU（即：IP包），就可能出現HFN失步；通常，一路VoIP語音，每20ms一個VoIP語音包，1s約50個語音包，對于N路話音場景，則1s約N*50個語音包；因此：1）當網絡存在突發干擾或信道突然惡化2）當同時通話話路所需帶寬大于QCI1承載GBR配置可能會因連續丟包導致HFN失步。連續丟包導致HFN失步，表現為加密端HFN>解密端HFN；該問題可以通過擴展PDCPSNsize為12bits來解決。客戶4月28日復現單通問題，并未采集到出現單通時的userplanetrace數據，所以，到底是否是因為連續丟包導致HFN失步并無法確認。直到客戶在5月5日反饋4月29日時復現的單通log，TDD研發層二專家分析133跟蹤項后，初步懷疑是PDCP層數據包亂序導致HFN失步，并不是之前理論分析的連續丟包導致HFN失步。1、標紅代表出問題的時間點（138跟蹤解密后的數據的IP頭都異常了），在出問題前，基本1s有100個包左右（2路VoIP話路，1s約100個VoIP媒體包），PDCP入口的包數量跟基站維護的HFN,SN計算的包數量一致；在出問題的時間點，可以發現PDCP入口收到的包數量還是100左右，而基站維護的HFN,SN計算出的包數量增加了224個，兩者之間剛好差128（對應7bitPDCPSN配置），此差異是由于基站的HFN調整導致的。基站HFN調整的過程：PDCP每收到一個包，首先解析包頭，獲取SN號，然后對SN號進行判斷，如果SN號比基站預期要接收到的SN號小，則基站認為中間有丟包且HFN應該要加1。由于出問題的時候，基站維護的包數量剛好比真實的包數量多128，認為丟包剛好丟128個的可能性比較少，因此認為PDCPSN號亂序的可能性較大（從eNodeBULPDCP在HFN自行調整前后PDCP層收到數據包個數來看，VoIP話路數并未改變，因此，也可以確認空口并未發生連續丟包，HFN自行調整是因亂序引入。）。例如：如果基站收到的包并沒有丟，而只是SN號亂序，例如：1,3,2,4,基站收到的這類包后HFN就會調整加1，而維護的總包數也會剛好比真實包數多128。2、分析上行調度49號跟蹤，出問題時間點附近的誤幀、MCS、RB數，調度間隔都沒有異常，基本排除空口傳輸異常的可能性——TDD層二專家分析結論從一線單通獲取日志，無法定位是什么原因導致PDCP層數據包亂序，包括eNodeB側log信息因流控有信息丟失，并且B222終端無法采集空口相關log：1、133號跟蹤中的PDCP_Trace_Type_PktLoss內容項有丟失，49號跟蹤內容也有丟失，應該是被流控掉了，無法判斷基站側PDCP層具體收到的包的SN號不連續的具體情況2、分析RLC142號跟蹤，在出問題的時刻，RLC剛好檢測到有重復RLC包；而到出問題前，RLC共檢測到重復RLC包11次；由于49號跟蹤數據丟失很嚴重，無法把調度跟RLC檢測到重復包進行關聯——TDD層二專家分析結論PDCP數據包亂序導致HFN失步，表現為加密端HFN<解密端HFN；該問題可以在eNodeB上開啟countercheck功能來規避：eNodeBcountercheck功能用于與UE核查安全參數COUNT是否一致，如果出現加密端HFN<解密端HFN，當COUNTERCHECKUSERRELSWITCH=ON，eNodeB會觸發該承載釋放（E-RABRelease）。研發實驗室人為構造上述兩種HFN失步場景，驗證相應規避方案有效后，提供給一線實施：一線反饋客戶執行規避方案后，現網仍出現單通問題。經分析確認：1）擴大PDCPSNsize后仍有單通問題：說明現網大部分單通問題不是因連續丟包導致HFN失步；2）開啟countercheck后仍有單通問題：經確認，一線客戶執行countercheck功能有誤，我們建議配置：MODCOUNTERCHECKPARA:COUNTERCHECKCOUNTNUM=128,COUNTERCHECKUSERRELSWITCH=ON;而客戶執行配置為：MODCOUNTERCHECKPARA:COUNTERCHECKTIMER=128,COUNTERCHECKUSERRELSWITCH=ON;COUNTERCHECKTIMER配置為128表示每128s執行一次countercheck功能；而我們是建議每128個包執行一次countercheck功能（若單路呼叫，相當于2.5s執行一次countercheck功能）。實驗室復現下行單通時，分析eNodeBlog，確認：eNodeB下行發送的