中國移動VoNR開網(wǎng)優(yōu)化指導手冊

PAGEPAGEII中國移動VoNR開網(wǎng)優(yōu)化指導手冊中國移動通信有限公司網(wǎng)絡事業(yè)部2022年2月文檔修訂記錄版本號日期修訂頁/修訂描述人員v1.02022/1/26創(chuàng)建文檔羅建迪、高小林（集團）、李天璞、方媛、牛銀山、張斌、章昊（設計院）、李新、烏力吉（研究院）、陳向前、胡曉春（陜西）、雷鶴、趙杰衛(wèi)（四川）、李華木、鄭小春（福建）、高玲、聶英強（遼寧）、張硯寒、徐偉亮（浙江）、侯普、梁立濤（北京）、楊曉康、胡堅（云南）、方東旭、周徐（重慶）、王亭亭（河北）、耿波、李濤（安徽）PAGEPAGE24目錄1． 背景 12． VoNR基本原理 13． VoNR覆蓋分析 34． VoNR容量分析 44.1 2.6GVoNR容量分析 44.2 700MVoNR容量分析 55． ViNR容量分析 65.1 2.6GViNR容量分析 65.2 700MViNR容量分析 76． 各廠家最低版本要求 87． VoNR功能開啟和基線參數(shù) 88． VoNR關鍵功能 118.1 EVS自適應編碼 118.2 弱場起呼轉EPSFB功能 128.3 VoNR頭壓縮RoHC 138.4 VoNRRLC分片優(yōu)化 148.5 VoNR基于語音質量切換功能 148.6 VoNR專用C-DRX功能 158.7 基于覆蓋的VoNR到VoLTE的切換 168.8 VoNR5QI1/5QI5上行預調(diào)度 168.9 上行MCS選階優(yōu)化 178.10 VoNR質差終端黑名單功能 179． VoNR質量評價指標體系 179.1 路測指標 179.2 網(wǎng)管指標 1910． VoNR優(yōu)化方法 1910.1 VoNR接入問題 1910.2 VoNR接通時延問題 2210.3 VoNR語音質量問題 2410.4 VoNR留得住問題 2910.5 VoNR掉話問題 3111． VoNR典型優(yōu)化案例 3211.1 無線案例 3211.1.1 華為設備無線鏈路失敗RRC重建后，終端收到網(wǎng)絡下發(fā)的RRCRelease導致呼叫失敗 3211.1.2 中興區(qū)域VoNR功控參數(shù)設置不合理導致好點RTP丟包率波動性突高 3311.1.3 中興基于質量異系統(tǒng)切換功能與呼叫保持沖突 3411.1.4 中信科弱場語音起呼自適應未回SMF正確cause導致起呼失敗 3811.1.5 愛立信5G基站不支持RoHC頭壓縮功能導致VoNR語音呼叫建立時延長 4011.1.6 愛立信5G站點VoNR通話中PDSCHBLER不收斂導致高丟包 4211.1.7 愛立信N21.2基站版本開啟VoNR后IPhone12終端出現(xiàn)無法被叫 4311.2 核心網(wǎng)案例 4811.2.1 視頻彩鈴協(xié)商流程與呼叫建立流程沖突，導致呼叫失敗 4811.2.2 主叫概率性收到兩條PDU會話修改案例影響接入時延 5011.2.3 Xn切換或RRC釋放流程與呼叫流程沖突，導致VoNR未接通或重選至4G開始通話 5211.2.4 VoNR專載釋放與切換并發(fā)導致主叫未接通 5411.3 終端案例 5611.3.1 高通芯片VoNR切換到VoLTE后必現(xiàn)RTP丟包問題 5611.3.2 驍龍888芯片BUG導致切換后出現(xiàn)視頻通話卡頓解決辦法 58附錄1：各廠家VoNR基線參數(shù)配置 60附錄2：各廠家VoNR增強功能介紹 60附錄3：各廠家VoNR網(wǎng)管指標介紹 60

背景語音業(yè)務是無線通信網(wǎng)絡的基本訴求，VoNR作為5G語音解決方案的終極目標，具有低時延、高清語音質量的優(yōu)勢。前期集團網(wǎng)絡事業(yè)部組織的全網(wǎng)VoNR端到端分場景測試結果表明，當前5GC核心網(wǎng)、無線均已具備VoNR開通條件。為此，特編制本指導書，指導VoNR快速開通和優(yōu)化確保VoNR與VoLTE同感同質。VoNR基本原理VoNR（VoiceoverNR）是5G網(wǎng)絡語音業(yè)務解決方案，是一種建立在IP網(wǎng)絡之上的UE和IMS之間的語音會話，主叫和被叫可以利用該技術在5G網(wǎng)絡上實現(xiàn)語音業(yè)務。其核心業(yè)務控制網(wǎng)絡為IMS網(wǎng)絡，配合NR-RAN及5GC，從而實現(xiàn)端到端的基于分組域的語音及視頻通信業(yè)務。EPSFB到VoNR的網(wǎng)絡結構演進圖5G網(wǎng)絡參照服務類型、時延和丟包率等標準，將具有不同特征的業(yè)務劃分成不同的5QI（5GQosIdentifier）承載類型，與VoNR業(yè)務直接相關的承載包括5QI1、5QI2和5QI5，其中5QI1承載語音，5QI2承載視頻，5QI5承載用于建立VoNR的SIP(SessionInitiationProtocol)信令。VoNR作為5G語音解決方案，相對于4G語音解決方案VoLTE有以下特點：1）空口由NR基站承載語音業(yè)務，完全的5G語音方案；2）新的語音編碼方案：EVS（EnhancedVoiceService）擴展音頻帶寬為50Hz~16KHz，支持人類聽覺的全帶寬。網(wǎng)絡部署初期，傳統(tǒng)4G終端較多，EVS采用AMR兼容模式，網(wǎng)絡成熟期5G終端滲透率提高后，5G終端之間采用EVS提升語音質量；3）3GPPR16制定IVAS（immersiveVoiceandaudioServices）語音編碼標準，支持更好的抗丟包能力。主叫UE和被叫UE之間語音承載的建立和釋放流程如下圖所示:VoNR呼叫信令流程圖具體流程為：1）主叫UE發(fā)起呼叫后，主叫UE和gNodeB之間建立RRC連接。2）5GC建立主叫UE的用于承載SIP（SessionInitiationProtocol）信令的QoSFlow（5QI5），gNodeB建立相應的DRB（dataradiobearer）承載。3）被叫UE和gNodeB之間建立RRC連接。4）5GC建立被叫UE的用于承載SIP信令的QoSFlow（5QI5），gNodeB建立相應的DRB承載。5）主被叫UE和IMS進行語音業(yè)務的SIP會話協(xié)商，如編碼方式、IP地址、端口號和主被叫相關信息等。6）SIP會話協(xié)商成功后，5GC建立主叫UE的用于承載RTP（Real-TimeTransportProtocol）和RTCP（Real-TimeTransportControlProtocol）數(shù)據(jù)流的QoSFlow（5QI1），gNodeB建立相應的DRB承載。7）5GC建立被叫UE的用于承載RTP和RTCP數(shù)據(jù)流的QoSFlow（5QI1），gNodeB建立相應的DRB承載。8）呼叫結束后，主被叫UE釋放各自的QoSFlow（5QI1），gNodeB釋放各自相應的DRB承載。5QI5為默認承載，建立后僅當UE進入空閑態(tài)時才會被釋放。VoNR覆蓋分析不同的業(yè)務類型對速率的要求不同，結合3GPP協(xié)議36.873和38.900的無線傳播模型進行路損仿真分析。不同速率業(yè)務的最大允許路損見下表，其中VoNR（24.4kbps）最大允許路損為118.6dB，為所有業(yè)務的最大值，即覆蓋能力最強;720P視頻業(yè)務最大允許路損為109.7dB，與上行5Mbps數(shù)據(jù)業(yè)務覆蓋能力相當。在5G數(shù)據(jù)業(yè)務淺層覆蓋組網(wǎng)情況下，ViNR視頻深度覆蓋相對不足。不同業(yè)務的MAPL匯總表LinkBudget-PUSCH480P720P1080P數(shù)據(jù)業(yè)務(一)數(shù)據(jù)業(yè)務（二）數(shù)據(jù)業(yè)務（三）數(shù)據(jù)業(yè)務（四）VoNR語音DataRate（mbps）1.003.004.001.003.004.005.000.02440最大允許路損MAPL（dB）114.5109.7108.6116.5111.7110.6109.5118.6備注：上述表格中為固定編碼速率下的結果。對于VoNR語音和視頻業(yè)務，終端可以進一步降低編碼速率從而增加其覆蓋范圍。除了路損外，需要繼續(xù)針對覆蓋強度等繼續(xù)研究。區(qū)別于2.6G和700M，700M覆蓋能力更強，各省可以根據(jù)實際網(wǎng)絡情況，輸出適合本地化的RSRP優(yōu)化標準，利用700M的覆蓋能力解決深度覆蓋不足的問題。VoNR容量分析VoNR語音包發(fā)送周期為20ms，靜默包發(fā)送周期為160ms，VoNR數(shù)據(jù)報文通常為32字節(jié)-61字節(jié)，并且5QI1屬于GBR業(yè)務，優(yōu)先級較高，業(yè)務信道通常不受限。因此，容量主要受限于控制信道。2.6GVoNR容量分析VoNR控制信道CCE個數(shù)計算方法如下表：VoNR控制信道CCE個數(shù)計算表2.6G頻段NRB個數(shù)單tti的CCE數(shù)量（3個符號用于控制信道，CCE利用率為90%）每秒總的CCE數(shù)量（0.5ms/tti，子幀配比7:1:2）每秒用于下行業(yè)務的CCE數(shù)量(控制信道上下行比例1:1)每秒用于上行業(yè)務的CCE數(shù)量(控制信道上下行比例1:1，現(xiàn)網(wǎng)k值為2)27312219520017080024400VoNR用戶調(diào)用次數(shù)計算根據(jù)現(xiàn)網(wǎng)配置：語音靜默因子為0.5，語音包發(fā)送周期為20ms，靜默包發(fā)送周期為160ms。VoNR用戶調(diào)用次數(shù)/秒：1000*0.5/20+1000*0.5/160=28.125次VoNR語音用戶容量用戶個數(shù)=cce數(shù)量/用戶所在信道條件占用的cce數(shù)量/VoNR調(diào)用次數(shù)各個信道條件的VoNR語音用戶數(shù)極好點用戶（CCE占用1個）好點用戶（CCE占用2個）中點用戶（CCE占用4個）差點用戶（CCE占用8個）極差點用戶（CCE占16個）40040021610854備注：1）、極好點：控制信道占用1個CCE，SINR>9dB2）、好點：控制信道占用2個CCE，SINR<9dBandSINR>3.2dB3）、中點：控制信道占用4個CCE，SINR<3.2dBandSINR>-0.8dB4）、差點：控制信道占用8個CCE，SINR<-0.8dBandSINR>-3.8dB在100MHz帶寬下，5G網(wǎng)絡可承載約400個用戶（用戶在極好點、好點時可以滿足）；當用戶都在極差點時，理論上最多可承載約54個用戶。700MVoNR容量分析VoNR控制信道CCE個數(shù)計算方法如下表：VoNR控制信道CCE個數(shù)計算表700M頻段NRB個數(shù)單tti的CCE數(shù)量（3個符號用于控制信道，CCE利用率為90%）每秒總的CCE數(shù)量（1ms/tti）每秒用于下行業(yè)務的CCE數(shù)量(控制信道上下行比例1:1)每秒用于上行業(yè)務的CCE數(shù)量(控制信道上下行比例1:1)16072720003600036000VoNR用戶調(diào)用次數(shù)計算根據(jù)現(xiàn)網(wǎng)配置：語音靜默因子為0.5，語音包發(fā)送周期為20ms，靜默包發(fā)送周期為160ms。VoNR用戶調(diào)用次數(shù)/秒：1000*0.5/20+1000*0.5/160=28.125次VoNR語音用戶容量用戶個數(shù)=cce數(shù)量/用戶所在信道條件占用的cce數(shù)量/VoNR調(diào)用次數(shù)各個信道條件的VoNR語音用戶數(shù)極好點用戶（CCE占用1個）好點用戶（CCE占用2個）中點用戶（CCE占用4個）差點用戶（CCE占用8個）極差點用戶（CCE占16個）60060032116080備注：1）、極好點：控制信道占用1個CCE，SINR>9dB2）、好點：控制信道占用2個CCE，SINR<9dBandSINR>3.2dB3）、中點：控制信道占用4個CCE，SINR<3.2dBandSINR>-0.8dB4）、差點：控制信道占用8個CCE，SINR<-0.8dBandSINR>-3.8dB5）、極差點：控制信道占用16個CCE，SINR<-3.8dB對于2×30MHz帶寬的700M5G網(wǎng)絡可支持約600個用戶（用戶在好點可以滿足）；當用戶都在極差點時，理論上最多可承載約80個用戶。ViNR容量分析視頻電話對網(wǎng)絡上下行要求一致，且視頻數(shù)據(jù)包較語音包大，小區(qū)邊緣容量受限于業(yè)務信道。終端的視頻ViNR的視頻清晰度根據(jù)網(wǎng)絡變化自適應調(diào)整。不同分辨率對應參數(shù)表視頻分辨率或標準480P（標清）720P（高清）1080P（全高清）（H265）分辨率640*4801280*7201920*1080像素pixel3072009216002073600色深colorbit/Pixel888每像素bit數(shù)（RGB標準）242424每像素bit數(shù)（YUV預處理）121212幀率framepersecond303030編解碼壓縮比compressionrate200200400所需碼率Mbps0.551.152.1速率碼率比所需速率帶寬計算Mbps1.052.242.6GViNR容量分析用戶個數(shù)=min{下行小區(qū)容量/視頻VoNR網(wǎng)絡需求,上行小區(qū)容量/視頻VoNR網(wǎng)絡需求}2.6G網(wǎng)絡承載能力關系表網(wǎng)絡承載能力（5G2.6GHz，100MHz帶寬，64通道）速率（Mbps）下行平均吞吐量1024上行平均吞吐量179單用戶邊緣下行吞吐量93（平均占用100%RB資源）單用戶邊緣上行吞吐量2~3（平均占用20%RB資源）備注：2.6G按照上行1Mbps速率進行規(guī)劃，實際拉網(wǎng)測試最低2~3Mbps。基于業(yè)務信道容量的視頻VoNR用戶數(shù)計算不同分辨率下的用戶數(shù)表業(yè)務類型5QI=2承載的業(yè)務需求小區(qū)平均承載并發(fā)用戶數(shù)小區(qū)邊緣承載并發(fā)用戶數(shù)(2.6G/700MHz)1080P分辨率視頻電話4Mbps440720P分辨率視頻電話2.21Mbps805480P分辨率視頻電話1.1Mbps16210小區(qū)平均可承載44個1080P用戶、或80個720P用戶、或162個480用戶；小區(qū)邊緣，無法承載1080P用戶，可承載5個720P用戶或10個480P用戶。700MViNR容量分析用戶個數(shù)=min{下行小區(qū)容量/視頻VoNR網(wǎng)絡需求,上行小區(qū)容量/視頻VoNR網(wǎng)絡需求}。700M網(wǎng)絡承載能力關系表網(wǎng)絡承載能力（5G700MHz，2*30MHz帶寬，4通道）（Mbps）速率（Mbps）下行平均吞吐量199上行平均吞吐量65單用戶邊緣下行吞吐量24（平均占用100%RB資源）單用戶邊緣上行吞吐量5（平均占用20%RB資源）基于業(yè)務信道容量的視頻VoNR用戶數(shù)計算不同分辨率下的用戶數(shù)表業(yè)務類型5QI=2承載的業(yè)務需求小區(qū)平均承載并發(fā)用戶數(shù)小區(qū)邊緣承載并發(fā)用戶數(shù)1080P分辨率視頻電話4Mbps166720P分辨率視頻電話2.21Mbps2911480P分辨率視頻電話1.1Mbps5922小區(qū)平均可承載16個1080P用戶、或29個720P用戶、或59個480用戶；小區(qū)邊緣，可承載6個1080P用戶、或11個720P用戶或22個480P用戶。各廠家最低版本要求各廠家主設備VoNR開通要求的運行環(huán)境，具體如下：運行需求華為中興中信科愛立信諾基亞License基本功能無license要求基本功能無license要求基本功能無license要求基本功能無license要求基本功能無license要求軟件要求版本要求21B及以上V5.45及以上V1.00.20N21.2SRAN21B硬件要求BBU要求BTS/DBS3900&5900系列基站，其中3900系列基站要求BBU為BBU3910無要求無要求無要求5GairscaleBTS組網(wǎng)要求支持SA組網(wǎng)，gNodeB和5GC之間的傳輸時延需小于20ms，支持N26接口，4/5G核心網(wǎng)互通并支持VoNR與VOLTE之間的互操作其它要求終端要求終端需支持VoNR，支持HO或者redirection到4G核心網(wǎng)要求需5G核心網(wǎng)支持VoNR業(yè)務及相關功能，如果需要支持VoNR緊急呼叫，5GC也需支持VoNR緊急呼叫VoNR功能開啟和基線參數(shù)VoNR功能開啟方式簡單介紹如下，具體參數(shù)配置參見附錄1。華為激活配置示例：//打開小區(qū)級VoNR功能開關圖華為VoNR功能開關（2）中興參數(shù)路徑：【CU小區(qū)配置】-【移動性功能】-【NR語音開關指示】說明：在VoNR開關打開后，如果終端支持VoNR能力，當占用NR網(wǎng)絡發(fā)起語音業(yè)務時走VoNR流程，如果終端不支持VoNR能力，當占用NR網(wǎng)絡發(fā)起語音業(yè)務時主動走EPSFB流程。中興VoNR功能開關（3）中信科參數(shù)路徑：【NR業(yè)務】-【NR小區(qū)】-【NR小區(qū)算法】-【NR小區(qū)VoNR算法表】圖中信科VoNR功能開關（4）愛立信VoNR功能為基本包，無需額外的License，開啟時，根據(jù)EPSFB支持情況選擇相應的參數(shù)設置方式：既支持VoNR又支持非VoNR終端接入,

不支持VoNR的終端使用盲重定向的EPSFB,EpsFallbackOperation=1既支持VoNR又支持非VoNR終端接入,

對于不支持VoNR的終端使用基于測量重定向的EPSFB,EpsFallbackOperation=3既支持VoNR又支持非VoNR終端接入,

對不支持VoNR的終端使用基于測量切換的EPSFB,

EpsFallbackOperation=4愛立信VoNR功能開關（5）諾基亞設置路徑：Objectpath:MRBTS?NRBTS?NRCELL；設置功能開關為Ture。圖諾基亞VoNR功能開關VoNR關鍵功能VoNR語音業(yè)務提供延遲更低、音質更高的實時話音業(yè)務，并且數(shù)據(jù)包發(fā)送也有特點，語音包發(fā)送周期為20ms、靜默包發(fā)送周期為160ms。當前，5G網(wǎng)絡的覆蓋廣度和深度還有待進一步提升，弱覆蓋和高干擾場景下如何最大化提升語音感知是VoNR優(yōu)化的重點工作之一。本指導書所涉及到的功能，都是主流設備廠家已經(jīng)支持或計劃支撐的常用功能，可提升用戶的VoNR感知。省公司可根據(jù)基站所處場景以及設備功能成熟度，選擇性開啟。各廠家VoNR增強功能支持情況功能名稱華為中興大唐愛立信諾基亞EVS自適應編碼支持支持V1.00.60.70支持不支持弱場起呼轉EPSFB功能支持支持V1.00.60.70不支持不支持VoNR頭壓縮RoHC支持支持支持22版本后再開啟支持VoNRRLC分片優(yōu)化支持支持支持支持支持VoNR基于語音質量切換功能支持支持V1.00.60.70不支持22R4VoNR專用C-DRX功能支持支持支持支持支持基于覆蓋的VoNR到VoLTE的切換支持支持支持支持支持VoNR5QI1/5QI5上行預調(diào)度支持支持支持支持支持上行MCS選階優(yōu)化支持5.55版本2022Q3支持支持支持VoNR質差終端黑名單功能支持5.55版本2022Q32022Q4不支持2023：Q3EVS自適應編碼EVS于2014年9月在3GPP通過標準化評估，但對于4G而言，由于推出時間較晚，4G產(chǎn)業(yè)鏈成熟度不足，僅少數(shù)的幾款終端支持EVS，因此未能大規(guī)模商用?；贓VS不僅僅使能高清語音，更可以有效提升覆蓋，因此在通信運營商及通信設備商的聯(lián)合推動下，最終將EVS作為5G語音必選落入3GPP標準。EVS通過支持多速率語音編解碼，提升編碼的靈活性和效率，支持更快的語音編解碼速率來提升語音體驗，比如，從13.2kbits/s開始，EVS-SWB的語音音質已經(jīng)接近“直接來源”（原音）的音質。EVS不同編碼方式支持的編碼速率表編碼方式支持的語音編碼速率（kbit/s）采樣頻率（kHz）EVS-NB5.9、7.2、8.0、9.6、13.2、16.4、24.48EVS-WB5.9、7.2、8.0、9.6、13.2、16.4、24.4、32、48、64、96、12816EVS-SWB9.6、13.2、16.4、24.4、32、48、64、96、12832EVS-FB16.4、24.4、32、48、64、96、12848AMR-WBI/O6.6、8.85、12.65、14.25、15.85、18.25、19.85、23.05、23.8516注：EVS編碼方式的編碼字長統(tǒng)一為16個比特。上表中的AMR-WBI/O編碼方式主要為了兼容支持AMR-WB編碼方式的4G終端，支持其與EVS終端進行VoNR業(yè)務。即當主被叫UE中的一方支持EVS編解碼、另一方不支持EVS編解碼但支持AMR-WB編解碼時，在使用VoNR功能的情況下，支持EVS的一方可以采用的編碼方式為AMR-WBI/O。弱場起呼轉EPSFB功能當網(wǎng)絡中同時支持VoNR功能和EPSFallback功能時，UE在弱場起呼時選擇進入EPSFallback語音呼叫流程。當處于空閑態(tài)或Inactive態(tài)的UE發(fā)起呼叫建立請求時，發(fā)送RRCSetupRequest、RRCResumeRequest或RRCResumeRequest1消息，如果消息中的信元EstablishmentCause取值為“mo-VoiceCall”，gNodeB由此判斷即將建立的是5QI1承載并下發(fā)A2測量。當處于空閑態(tài)或Inactive態(tài)的UE被呼叫時，上述消息中的信元EstablishmentCause取值為

“mt-Access”，gNodeB將下發(fā)A2測量。gNodeB根據(jù)5QI1承載建立請求前是否上報A2測量來判斷該主叫或被叫UE是否處于弱覆蓋區(qū)域，如果上報A2測量則判斷該UE處于弱覆蓋區(qū)域。此時，gNodeB將拒絕建立5QI1語音承載，并進入EPSFallback語音呼叫流程。如果UE處于非弱覆蓋區(qū)域，則進入VoNR語音呼叫流程。本功能中的A2測量相關門限支持通過參數(shù)配置。VoNR頭壓縮RoHCVoNR是基于IP網(wǎng)絡傳輸?shù)恼Z音業(yè)務，并且語音包采用的都是小包高頻傳輸（語音幀大小20ms），因此語音包的頭部的開銷占整個數(shù)據(jù)包的比例較大。對于IPv4和IPv6語音數(shù)據(jù)包，頭部開銷分別達到了40字節(jié)和60字節(jié)。語音數(shù)據(jù)包的凈荷（有效負荷）大小與語音的編碼速率有關，通常為32字節(jié)~61字節(jié)，以IPv4語音數(shù)據(jù)包為例，包頭的開銷占到了語音數(shù)據(jù)包總數(shù)據(jù)量的39.6%（40/101）~55.6%（40/72）左右，即帶寬資源的有效利用率只有44.4%~60.4%；同樣的，IPv6語音數(shù)據(jù)包對帶寬資源的有效利用率只有34.8%~50.4%。這么低的資源利用率對于帶寬資源稀缺的無線網(wǎng)絡來說是不可接受的，會直接阻礙無線網(wǎng)絡IP化的發(fā)展，因此有必要通過對包頭部分進行壓縮來提升無線資源的利用率。ROHC語音包頭壓縮通過減少語音包頭部負荷來降低無線鏈路誤碼率和時延、減少無線資源消耗。ROHC支持IPv4和IPv6包頭的壓縮，最高可以將包頭壓縮成1個字節(jié)。ROCH壓縮示意圖在ROCH協(xié)議框架中，ROHC功能位于UE和gNodeB的用戶面PDCP實體內(nèi)。ROHC功能分為兩部分：壓縮端（對包頭進行壓縮）和解壓端（對壓縮包頭進行解壓，恢復出原始包頭），壓縮原理示意如圖所示。壓縮原理示意圖VoNRRLC分片優(yōu)化在NR網(wǎng)絡上行是一個功率受限的過程，基站調(diào)度TBSize的大小會受到UE發(fā)射功率的影響。當信道質量較低時，UE發(fā)射功率受限，上行動態(tài)調(diào)度分配的TBS（transportblocksize）會隨之調(diào)小，使得RLC分片變多，從而增加了同一個VoNR語音包的調(diào)度次數(shù)。調(diào)度次數(shù)增加會導致VoNR語音包時延增大、丟包率抬升以及上行開銷增多的語音質量問題。上行RLC分片優(yōu)化功能通過限制上行動態(tài)調(diào)度分配的TBS來降低上行RLC分片數(shù)，以提高信道質量較低時的語音質量。VoNR基于語音質量切換功能基于語音質量切換是指基站實時監(jiān)控終端語音質量，終端在無線環(huán)境尚未達到互操作門限時，如果語音質量變差，則下發(fā)異頻異系統(tǒng)測量，如果達到切換門限就切換至目標小區(qū)保障語音質量，該功能主要用于弱覆蓋、高干擾以及下行質差等場景，用于改善語音質量?；谡Z音質量切換功能原理圖功能要點：網(wǎng)絡側根據(jù)VoNR上下行RTP丟包率來判斷語音用戶感知，如果RTP丟包率在連續(xù)N個周期T內(nèi)滿足丟包率門限L，則觸發(fā)語音質切測控消息，其中N、T、L門限可配置。如果同時開啟異頻異系統(tǒng)質切，在滿足質差門限時網(wǎng)絡側會同時下發(fā)異頻和異系統(tǒng)測控，NR異頻測量頻點measID排在4G異系統(tǒng)頻點前面，確保優(yōu)先觸發(fā)系統(tǒng)內(nèi)質切；在下發(fā)測控后如果語音質量變好，網(wǎng)絡側會刪除質切相關測控，繼續(xù)監(jiān)控語音質量。VoNR專用C-DRX功能VoNR每隔20ms發(fā)送一個語音包，根據(jù)VoNR的特點配置專用的DRX參數(shù)，一方面可以保障語音質量，一方面可以節(jié)約終端耗電量，提升5G用戶感知。VoNRC-DRX示意圖基于覆蓋的VoNR到VoLTE的切換通話過程中5G信號衰減到A2門限后，gNodeB收到異系統(tǒng)A2事件測量報告后，下發(fā)異系統(tǒng)A1事件測量控制，并根據(jù)異系統(tǒng)切換觸發(fā)事件類型（通過NRInterRatHoParam.InterRatHoTriggerEventType配置）的取值（“EVENT_B1”或“EVENT_B2”），下發(fā)異系統(tǒng)B1或B2事件測量控制。如果gNodeB收到UE上報異系統(tǒng)B1/B2事件，gNodeB根據(jù)小區(qū)信號質量順序生成目標小區(qū)列表，選擇信號質量最好的小區(qū)作為目標E-UTRAN小區(qū)。gNodeB執(zhí)行到目標E-UTRAN小區(qū)的切換，切換語音連續(xù)性?；谙滦懈采w的VoNR（voiceoverNR）至VoLTE（voiceoverLongTermEvolution）的切換流程與基于下行覆蓋的NG-RAN至E-UTRAN數(shù)據(jù)業(yè)務切換流程相似。區(qū)別在于：gNodeB根據(jù)NRCellEutranNFreq.VoltePriority的取值判斷是否對該LTE頻點下發(fā)測量控制：1. 如果NRCellEutranNFreq.VoltePriority取值為255，則表示該LTE頻點不支持VoLTE，則不對該LTE頻點下發(fā)測量控制。2. 如果NRCellEutranNFreq.VoltePriority取值不為255，則表示該LTE頻點支持VoLTE，對該LTE頻點下發(fā)測量控制。VoNR5QI1/5QI5上行預調(diào)度VoNR語音包通過5QI=1承載傳輸，通過開啟預調(diào)度功能，基站側可以在終端發(fā)送SR之前分配上行資源，省去終端上報SR的步驟，以便語音包得到及時調(diào)度，預期可以改善遠點語音感知?；久看巫R別到5QI5上有上下行BSR后，會在5QI5上行預調(diào)度預置BSR定時器超時后進行上行預授權，預授權的調(diào)度周期可以進行設置，每個調(diào)度周期可以進行調(diào)度。上行MCS選階優(yōu)化當VoNR用戶上行MCS階數(shù)偏高時，會導致語音業(yè)務的上行丟包率抬升，因此需確保VoNR用戶上行MCS階數(shù)合理，以保障語音包傳輸?shù)目煽啃?。上行MCS選階優(yōu)化功能支持通過降低語音業(yè)務初傳上行MCS階數(shù)來降低語音業(yè)務的上行丟包率，提升語音傳輸質量。上行MCS選階優(yōu)化功能通過參數(shù)來配置語音業(yè)務初傳的上行MCS下降階數(shù)。VoNR質差終端黑名單功能對于上報了VoNR支持能力但是功能不完善或異常的某款終端，據(jù)終端上報的UE_CAPABILITY_INFORMATION、IMEIS等特性信息，識別出該特定款終端，將該終端的UE_CAPABLITY(終端能力)特征碼加到基站黑名單中。當該款終端發(fā)起VoNR呼叫時，基站拒絕建5QI1，轉向EPSFB流程，完成語音通話。該功能建使用場景：通過投訴或者性能數(shù)據(jù)分析到某款終端不成熟后，可以在特定的小區(qū)或者全網(wǎng)屏蔽該類型終端使用VoNR。注：上述分廠家VoNR增強功能詳細介紹參見附錄2。VoNR質量評價指標體系VoNR開網(wǎng)優(yōu)化過程中需密切關注現(xiàn)拉網(wǎng)測試指標及網(wǎng)管監(jiān)控指標，以便及時采取針對性優(yōu)化措施，達到VoNR與VoLTE同感同質。路測指標對標VoLTE，從“打得通”、“接得快”、“聽得清”、“留得住”和“不掉話”5個維度，全面評估現(xiàn)網(wǎng)VoNR商用能力，具體指標參考標準如下：關鍵感知KPI指標VoNR測試指標指標定義基準值挑戰(zhàn)值打得通接通率>98%>99%成功完成呼叫次數(shù)/終端發(fā)起呼叫總數(shù)。每次通話中，主叫UE發(fā)送第一條SIPINVITE后收到網(wǎng)絡側下發(fā)的SIP180Ring消息為成功完成呼叫接得快呼叫接續(xù)時長≤2.5s≤2.3s空閑態(tài)的主叫UE發(fā)SIPINVITE后收到網(wǎng)絡側下發(fā)的SIP180Ring消息之間的時間差。聽得清丟包率≤0.5%≤0.3%（發(fā)送RTP數(shù)-接收到RTP數(shù)）/發(fā)送RTP數(shù)×100%話音MOS值>3.8>4POLQA算法平均得分語音MOS小于3.0占比＜2%＜1%MOS3.0以下采樣點數(shù)/MOS總采樣點數(shù)（VoNR2VoNR）語音MOS大于4.0占比>96%>98%MOS4.0以上采樣點數(shù)/MOS總采樣點數(shù)(VoNR2VoNR)留得住時長占比>98%>99%VoNR通話時長/全部通話時長，全部通話時長包括VoNR、EPSFB、VoLTE、CSFB、2G等通話時長5/4切換占比(語音）2%1%語音業(yè)務5/4切換次數(shù)與小區(qū)中特定5QI的QosFlow建立嘗試次數(shù)的占比

gNodeB收到UE發(fā)送的MeasurementReport消息，gNodeB切換判決要切換到E-UTRAN系統(tǒng)時，如果切換出承載包含語音業(yè)務，則記語音業(yè)務切換請求。

gNodeB收到來自AMF的INITIALCONTEXTSETUPREQUEST消息后，如果指示需要同時建立PDU會話，則針對該PDU會話中的每個QoSFlow，按照5QI統(tǒng)計N.QosFlow.Est.Att.Cell5QI和N.QosFlow.InitEst.Att.Cell5QI指標不掉話掉話率≤1%≤0.5%（主叫掉話次數(shù)+被叫掉話次數(shù)）/（成功建立呼叫次數(shù)*2）。主叫主動掛機時，主叫未收到SIP_BYE-OK或被叫未發(fā)送SIP_BYE-OK，均計算一次掉話。切換成功率>99%>99.5%切換成功次數(shù)/切換請求次數(shù)。UE收到源gNB發(fā)送的攜帶mobilityControlInfo的“RRC連接重配置”消息（RRCConnectionReconfiguration），向目標小區(qū)gNB發(fā)送RRC重配完成消息（RRCConnectionReconfigurationComplete）記為切換成功切換成功率5/5（語音）>99%>99.5%切換成功次數(shù)/切換請求次數(shù)。當服務gNodeB小區(qū)接收到UE的MeasurementReport消息后，滿足切換門限，則記切換請求。

當gNodeB目標小區(qū)收到UE返回的RRCReconfigurationComplete消息，記切換完成切換成功率5/4(語音）>98%>99%切換成功次數(shù)/切換請求次數(shù)。

UE切入到E-UTRAN系統(tǒng)后，gNodeB收到AMF發(fā)送的UECONTEXTRELEASECOMMAND消息或收到UE發(fā)送的RRCReestablishmentComplete消息時，如果切換出承載包含語音業(yè)務，則記語音業(yè)務切換成功。

gNodeB收到UE發(fā)送的MeasurementReport消息，gNodeB切換判決要切換到E-UTRAN系統(tǒng)時，如果切換出承載包含語音業(yè)務，則記語音業(yè)務切換請求。網(wǎng)管指標網(wǎng)管指標主要考慮話音和視頻業(yè)務的接通率、掉線率、切換成功率及話務量等指標，指標名稱及各主設備廠家支持情況如下，詳細內(nèi)容參見附錄3。指標名稱華為中興中信科愛立信諾基亞VoNR建立請求次數(shù)(5QI1)支持支持支持支持支持VoNR無線接通率(5QI1)支持支持支持支持支持掉線率(5QI1)(小區(qū)級)支持支持支持支持支持掉線率(5QI1)(網(wǎng)絡級)支持支持支持支持支持系統(tǒng)內(nèi)VoNR用戶切換成功率(5QI1)不支持不支持支持不支持支持系統(tǒng)間切換出準備請求次數(shù)（NG-RAN->EUTRAN）(5QI1)支持不支持支持不支持不支持系統(tǒng)間切換成功率（NG-RAN->EUTRAN）(5QI1)支持不支持支持不支持不支持全網(wǎng)每天空口業(yè)務上行字節(jié)數(shù)(5QI1)支持支持支持支持支持全網(wǎng)每天空口業(yè)務下行字節(jié)數(shù)(5QI1)支持支持支持支持支持全網(wǎng)每天VoNR語音話務量(5QI1)支持支持支持不支持支持上行PDCPSDU平均丟包率（5QI1）支持支持支持支持支持下行PDCPSDU平均丟包率（5QI1）支持不支持支持支持支持VoNR建立請求次數(shù)(5QI2)支持支持支持支持不支持VoNR無線接通率(5QI2)支持支持支持支持不支持掉線率(5QI2)(小區(qū)級)支持支持支持支持不支持掉線率(5QI2)(網(wǎng)絡級)支持支持支持支持不支持系統(tǒng)內(nèi)VoNR用戶切換成功率(5QI2)不支持不支持不支持不支持不支持系統(tǒng)間切換出準備請求次數(shù)（NG-RAN->EUTRAN）(5QI2)不支持不支持不支持不支持不支持系統(tǒng)間切換成功率（NG-RAN->EUTRAN）(5QI2)不支持不支持不支持不支持不支持全網(wǎng)每天空口業(yè)務上行字節(jié)數(shù)(5QI2)支持支持支持支持支持全網(wǎng)每天空口業(yè)務下行字節(jié)數(shù)(5QI2)支持支持支持支持支持全網(wǎng)每天VoNR視頻話務量(5QI2)支持支持支持不支持支持上行PDCPSDU平均丟包率（5QI2）支持支持支持支持支持下行PDCPSDU平均丟包率（5QI2）支持不支持支持支持支持VoNR優(yōu)化方法從VoNR測試優(yōu)化工作中總結優(yōu)化方法。主要從VoNR接入問題、VoNR接通時延問題、VoNR語音質量問題、VoNR掉話問題共計5項專題入手，以專題形式對問題進行針對性分析和優(yōu)化。VoNR接入問題從信令流程分析異常接通，VoNR呼叫流程涉及網(wǎng)元較多,如UE、GNB、核心網(wǎng)、IMS等網(wǎng)元,如果出現(xiàn)問題需要進行端到端的信令分析，VoNR呼叫建立流程包含7個階段。接入流程7階段示意圖階段15G側RRC接入：如果主/被叫是在空閑態(tài)下起呼,需要RRC接入流程。RRC接入失敗分析原因分析（1）上行干擾,弱場接入：上行干擾或者弱覆蓋下UE上行受限,UE接入的信令消息基站無法正確解調(diào)。（2）RRC連接建立定時器設置過長：基站側“RRC連接建立定時器(ms)”設置過比如為10s,如果第一次RRC建立失敗后需要等約10s才會重新發(fā)起RRC連接建立請求,容易導致VoNR通話建立超時。（3）PCI\RSI復用距離過近:PCI或者prach邏輯根序列號復用過近會導致小區(qū)間發(fā)生干擾,引起接入失敗。（4）UE去激活定時器設置過?。?.0版本去激活定時器沒有區(qū)分承載,在被叫沒開彩鈴的情況下,去激活定時器inactivetimer設置為10s,主叫收到180ringing消息10s后收到基站下發(fā)的RRC釋放消息,引起呼叫失敗。階段2鑒權加密或UE能力查詢：如果主/被叫是在空閑態(tài)下起呼,需要鑒權加密和UE能力查詢流程。鑒權加密或UE能力查詢失敗原因分析：UE,基站,5GC的鑒權配置不一致導致或者VoNR能力不攜帶導致后續(xù)不會建立5QI1。階段3QPSFlow(5QI5)建立：如果主/被叫是在空閑態(tài)下起呼,需要建立5QI5承載。（1）5QCI5切片數(shù)據(jù)漏配或者設置錯誤導致5QI5建立失敗。（2）無線信號良好,核心網(wǎng)下發(fā)5QI5承載,基站回復失敗,失敗原因為：radioNetwork=0:Ngap_CauseRadioNetwork_Root_unspecified。階段4QPSFlow建立(5QI1)建立：VoNR呼叫主被叫都需要建立5QI1專用承載.（1）核心網(wǎng)不下發(fā)5QI1:經(jīng)過終端,基站和核心網(wǎng)三方面的對比目前已經(jīng)明確了發(fā)生場景為核心網(wǎng)是在并行處理RANidle定時器觸發(fā)的釋放,此時核心網(wǎng)認為UE在idle態(tài),而終端和基站側看終端已經(jīng)處于連接態(tài)導致核心網(wǎng)5GC不下發(fā)5QI1建立,5GC核心網(wǎng)出新版本解決。（2）“NR語音開關指示”配置為“false”,導致核心網(wǎng)建立5QI1時基站拒絕。（3）終端原因導致5QI1重配失?。篣E在原小區(qū)SSBARFCN/PCI:504990/274建立5QI1時,回復5QI1建立重配的完成消息通過查看基站側信令,基站并沒有收到該消息.此時無線信號良好(RSRP:-93dBm,SINR:15dB)頻譜掃描也沒有發(fā)現(xiàn)有上行干擾,鑒于UE發(fā)起重建立的原因是重配失敗,UE雖然生成了重配完成消息,懷疑并沒有給基站發(fā)送.測試終端是HWmate30pro。（4）由于VoNR和EPSFB自適應打開，終端處于覆蓋較弱的場景，導致發(fā)起EPSFB回落。階段5被叫尋呼：如果被叫在idle態(tài)下,核心網(wǎng)需要對被叫進行尋呼。（1）無線覆蓋弱或者高干擾場景導致UE收不到尋呼消息。（2）外場測試NR弱場信號在-112~-118dBm左右時,EPSFB存在概率性出現(xiàn)被叫收不到尋呼消息的情況.目前版本尋呼信道CCE默認配置為4,解調(diào)性能不好,如果帶寬容許弱覆蓋站點調(diào)整為8。（3）被叫RRC建立失敗：UE收到paging消息后由于無線原因,或者基站問題導致RRC建立失敗,無法給核心網(wǎng)回復尋呼響應。（4）HWAMF已知問題：基站側排查當該被叫不能被尋呼到時,實際基站側并未收到對該終端的paging消息,進一步聯(lián)系HW核心網(wǎng)排查定位,是AMF800有內(nèi)部故障,需通過升級AMF800解決階段。階段6SIP流程交互（1）IMS問題沒有投遞SIP信令或者投遞不及時（2）IMS在流程正常的情況下主動發(fā)SIPCANCEL（3）IMS下發(fā)5XX,403forbidon失敗碼。階段7彩鈴階段：被叫開通視頻彩鈴業(yè)務后,主叫摘機過快導致后續(xù)流程發(fā)生了亂序.(一般只有路測時手機自動摘機時會遇到)。VoNR接通時延問題針對VoNR呼叫建立時延的優(yōu)化一般需要進行分段時延統(tǒng)計來分析,如果某段時延相比于基準時延差別較大,并且該段時延在整體時延中占比較大,那么需要針對這段時延進行重點分析。比如主叫發(fā)起invite消息到收到183消息時延較大,這段時延主要設涉及主被叫的RRC建立,默認承載建立,專載建立以及被叫的尋呼.所以可以看看這幾個流程是否存在異常,或者被叫呼叫時是否處在idle等。VoNR呼叫建立時延分析思路空口時延影響因素：做好基礎覆蓋RF優(yōu)化工作,避免或減少呼叫建立過程中發(fā)生切換,RRC重建立,NAS層消息和SIP消息等在空口的時調(diào)延度；干擾主要通過清除干擾來解決；呼叫建立時延方面VoNR互相打近點和中點基本相當,遠點比近點多240~260ms.遠點時由于SIP消息分片導致整體SIP消息調(diào)度時延變大。UE側時延影響因素：被叫開啟彩鈴/視頻彩鈴：彩鈴播放成功后核心網(wǎng)才會將180ring消息轉發(fā)給主叫,由于播放視頻彩鈴的時間長180ring消息的轉發(fā)延后導致呼叫建立時延增加.如果是視頻彩鈴主叫呼叫建立時需要進行彩鈴的媒體協(xié)商和QCI2的承載建立,也會導致呼叫建立時延增加.正常播放視頻語音彩鈴會增加呼叫建立時延600s左右,普通彩鈴影響200ms。被叫處于Idle態(tài)時：如果被叫處在idle態(tài)需要對被叫進行尋呼,對呼叫時延有較大影響。UE側Paging周期：有些終端會主動上報自己期望的尋呼周期,有些終端會主動上報期望的尋呼周期,最終的尋呼周期為UE和基站側配置取小.如果某類型UE的期望尋呼周期是320ms,基站的默認尋呼周期是1280ms,那么最終該用戶使用的尋呼周期320ms。不同終端對Sip消息的響應速度會有差異,可能會影響整體呼叫時延.芯片差異：海思終端主叫在ServiceAccept后才顯示Invite,而高通芯片在Servicerequest之前顯示,相比高通終端節(jié)省約200ms。基站側時延影響因素：（1）DRX影響：在呼叫過程終如果UE進入DRX休眠,會導致SIP消息的調(diào)度時延變長,休眠時間越長,影響時延越大.（2）QCI5預調(diào)度：定點VoNR撥打VoNR測試,打開5QI5的預調(diào)度后呼叫建立時延節(jié)約200ms左右.開啟5QI5預調(diào)度功能后,會加快SIP消息的基站調(diào)度,減少空口時延.（3）基站默認尋呼周期：設置不同大小對被叫idle下呼叫時延影響不同.（4）在存在干擾場景的情況，通過干擾避讓避開干擾帶也可以達到優(yōu)化效果.（5）通過語音優(yōu)先開關打開，使得在流程沖突的場景，優(yōu)先語音承載建立.核心網(wǎng)和IMS時延影響因素：（1）流程沖突：SMF向基站發(fā)送PDUSessionModify消息,建立5QI1的專用QoSFlow,如果空口正在發(fā)生移動性事件(如Xn切換,N2切換),核心網(wǎng)優(yōu)先處理移動性事件,SMF等待流程沖突定時器超時后再重新發(fā)送PDUSessionModify建立5QI1導致時延增大。（2）5QI1建立時發(fā)生多次PDU流程修改:需要聯(lián)合核心網(wǎng)一起排查.（3）IMS開啟183消息提前轉發(fā)功能：不等被叫建立完5QI1承載建立完畢,提前轉發(fā)183消息可以改善約100ms時延.VoNR語音質量問題VoNR語音質量通過MOS值量化評估，MOS分值越高則語音質量越高。MOS值的直接影響因素為編碼速率、丟包、時延和抖動。主要從“4個維度”進行分析。VoNR語音質量影響因素綜合影響MOS的因素，分析流程如下：MOS質差分析流程MOS質差分析與處理方案（1）故障告警基站告警會影響業(yè)務性能,尤其是嚴重告警,下表梳理了影響業(yè)務性能的告警清單,現(xiàn)場需及時處理。（2）覆蓋問題-弱覆蓋會嚴重影響VoNR語音性能,尤其是當RSRP達到語音感知臨界點時,語音包的丟包,抖動和時延都會出現(xiàn)劣化.造成弱覆蓋的原因主要有站點少,越區(qū)覆蓋,鄰區(qū)配置問題,功率參數(shù)配置問題等,需要結合實際情況及工參進行加站,RF優(yōu)化,鄰區(qū)核查優(yōu)化,參數(shù)調(diào)整等操作。覆蓋方面目前有以下幾點需要注意：1）VoNR拉遠性能測試結果的可重復性差,下圖為通過大量拉遠測試采樣點求平均得出的結果,現(xiàn)場可自行進行拉遠測試體驗。RSRP與MOS值關系圖2）當前為提升5G駐留比指標已將數(shù)據(jù)業(yè)務5G到4G切換門限下探，為保障VoNR感知需要把語音業(yè)務的異頻異系統(tǒng)切換事件和門限與數(shù)據(jù)業(yè)務分開配置,VoNR應比數(shù)據(jù)業(yè)務更早切換至4G。3）VoNR商用初期必然受限于深度覆蓋,對于電梯,車庫等快衰場景需要通過調(diào)整VoNR向VoLTE切換門限,使得用戶在出現(xiàn)感知問題前回落4G,不至于出現(xiàn)單通,斷續(xù)甚至掉話等問題。（3）干擾問題干擾分為系統(tǒng)內(nèi)干擾和系統(tǒng)外干擾兩種類型,系統(tǒng)內(nèi)干擾來源主要包括：數(shù)據(jù)配置錯誤造成干擾、頻段調(diào)整配置參數(shù)、時隙配置不對齊產(chǎn)生干擾、GPS時鐘失步干擾、小區(qū)間下行干擾及設備故障。系統(tǒng)外干擾主要包括：雜散干擾、阻塞干擾、互調(diào)干擾。上行干擾對強場用戶感知影響有限,但是對中弱場用戶感知影響較大,上行干擾對網(wǎng)絡的影響表現(xiàn)為將基站有限覆蓋范圍縮小,從大量測試結果來看,在上行NI抬升10dB時,VoNR拉遠性能下降6dB左右。同時需要關注5G同頻組網(wǎng)干擾、5G室內(nèi)外干擾、700M廣電干擾帶來的影響，相關干擾影響亟待研究。各個廠家需要關注各自的抗干擾能力，充分研究不同場景下，不同廠家設備的干擾規(guī)避能力以及對VoNR、ViNR的影響。（4）下行質差下行質差的原因主要包括：重疊覆蓋,模三干擾,重選切換參數(shù)設置不合理等因素，其中重疊覆蓋需要通過RF優(yōu)化調(diào)整,使其有主覆蓋小區(qū)；模三干擾需要通過RF優(yōu)化或PCI調(diào)整解決；越區(qū)覆蓋可通過RF優(yōu)化或功率優(yōu)化控制越區(qū)覆蓋；參數(shù)配置重點檢查重選和切換參數(shù),避免由于參數(shù)設置極端導致終端無法及時從弱場遷移至強場。（5）切換問題由于切換參數(shù)設置不合理或鄰區(qū)配置問題導致切換不及時或頻繁切換等問題會嚴重影響MOS評分,給用戶帶來很差的用戶體驗,因此必須重視對切換鏈的梳理.從大量測試數(shù)據(jù)來看,MOS均值會隨切換次數(shù)的增加而降低,異頻和異系統(tǒng)切換相對同頻切換對語音感知影響更為明顯,每增加一次切換必然會導致MOS降低。常見的切換問題和對應的解決方案表（6）RRC重建終端處于RRC_CONNECTED狀態(tài)時,如果出現(xiàn)切換失敗,無線鏈路失敗,完整性保護失敗,RRC重配置失敗等問題會觸發(fā)RRC重建過程.RRC重建流程的目的是恢復RRC連接,包括恢復SRB1承載和安全模式激活.RRC重建過程會導致短暫的語音吞字,對語音感知影響較大,因此需要通過網(wǎng)絡優(yōu)化盡量減少RRC重建發(fā)生概率。重建優(yōu)化處理建議：（7）終端問題目前市場上各類型終端較多，針對排查出的終端能力問題，需要推動終端廠家升級解決。VoNR留得住問題通過互操作策略，以優(yōu)先駐留5G為根本原則；根據(jù)4G和5G網(wǎng)絡質量情況，設置合理的互操作策略，確保UE占用最優(yōu)網(wǎng)絡。5G駐留分析問題處理得四個原則如下：具體的參數(shù)策略見附件1：基線配置。1）在5G時體驗優(yōu)于4G，則駐留在5G；2）5G邊緣用戶轉移到4G，此時滿足4G體驗優(yōu)于5G；3）通話結束后，在4G始終嘗試轉移到5G，只要5G體驗優(yōu)于4G，則實施轉移；4）防乒乓原則，本端切出條件中存在對端質量門限，同樣，對端切換條件中也包含對端質量門限；彼此耦合，但是又彼此不知，互操作設置時需要防乒乓。5）5G異頻切換策略，在當前頻段語音感知體驗不足，只要滿足異頻5G網(wǎng)絡體驗優(yōu)，則實施轉移。VoNR開通場景: VoNR開通保證連片開通，邊界通過TAC黑名單來避免切換；通過開通VoNR-VOLTE自適應切換以及基于語音質量的切換來使得用戶在邊緣可以回落到LTE。5-4的切換策略主要基于覆蓋的VoNR-Volte的切換。要求語數(shù)分離，5QI1單獨成組，并綁定組0；配置建議范圍和45G互操作門限一致。1）在NR弱覆蓋或者干擾區(qū)場景:打開基于語音質量的vonr-volte切換。使得終端在5G語音質量差的區(qū)域可以切換到LTE，語音質量主要基于丟包率來判斷，對應參數(shù)配置建議切換丟包率門限配置為5%，停止測量事件的丟包率配置為2%。2）VoNR部分開通場景：通過TAC黑名單來避免語音切換后的掉話，設置了TAC黑名單后攜帶語音業(yè)務時，將不會發(fā)生往黑名單TAC小區(qū)切換。3）VoNR未開通場景：打開EPSFB開關，當發(fā)起語音時的時候，終端通過EPSFB的方式切換回LTE。VoNR掉話問題在VoNR語音業(yè)務時,對于開通VoNR功能的用戶會在RRC連接建立后建立5QI5的信令承載,在進行VoNR通話時,會再建立5QI1的語音專用承載,5QI1的QoSFlow釋放,意味著VoNR語音業(yè)務結束,所以我們用5QI1的E-RAB異常釋放來定義VoNR語音業(yè)務掉話。掉話問題分析流程四個維度維定界尋找解決方案：（1）終端側：A、終端異常detech排查B、終端異常發(fā)起專載釋放（2）無線側：A、弱覆蓋B、高重疊C、高干擾D、容量受限E、切換異常等基礎問題優(yōu)化（3）5GC側：A、TAUrejectB專載丟失C、核心網(wǎng)主動下發(fā)專載釋放（4）IMS側：A、IMS下發(fā)BYEB、IMS沒有下發(fā)BYE200OK消息CIMS單邊釋放C、RTPTIMOUT無線側根因分析：目前較少發(fā)現(xiàn)由于核心網(wǎng)原因導致的VoNR語音掉話,大部分都是無線側原因導致的掉話,主要原因有以下幾個方面：（1）正常情況下,某個小區(qū)周邊都存在鄰區(qū),如果無線環(huán)境不是很差,都可以通過切換的方式改變服務小區(qū).當某個站點缺失鄰區(qū)或者鄰區(qū)添加不合理,會導致切換不能夠及時進行,缺失鄰區(qū)會對服務小區(qū)造成比較嚴重的干擾,從而造成掉線.因此處理掉線率較高的小區(qū)時,需要核查鄰區(qū)配置是否合理。（2）小區(qū)存在異頻鄰區(qū)時,需核查異頻切換類參數(shù)是否配置合理。（3）核查小區(qū)是否存在超遠覆蓋,導致覆蓋孤島,無法切換到周邊鄰區(qū).可以通過后臺跟蹤信令,觀察測量報告,并補齊漏配的鄰區(qū),隨后需要對覆蓋進行控制。（4）對于因弱覆蓋導致掉線,若終端處于覆蓋邊緣,周圍無可用的5G小區(qū),可以添加系統(tǒng)間鄰區(qū),UE通過切換到LTE小區(qū)進行接續(xù)。（5）5G切換時目標小區(qū)不支持VoNR導致質差掉話。（6）中興核心網(wǎng)下VoNR通話過程中切換到4G后專載沒有恢復導致掉話（7）建立5QI2專載時濾波器配置不完善導致掉話。VoNR典型優(yōu)化案例無線案例華為設備無線鏈路失敗RRC重建后，終端收到網(wǎng)絡下發(fā)的RRCRelease導致呼叫失敗現(xiàn)象概述：無線鏈路失敗后發(fā)生基于fallback模式的RRC重建，隨后終端收到RRCRelease消息，導致呼叫失敗。問題分析：在華為基站遠點測試時，被叫終端發(fā)送SIP183過程中在PCI357發(fā)生無線鏈路失敗，隨后在同一小區(qū)發(fā)起RRC重建，基站回復RRCSetup，說明發(fā)生了基于fallback模式的RRC重建（疑似基站無法獲得/保留合法的UEContext）RRC重建后，被叫終端再次發(fā)送SIP183成功，并隨后進行SIPPRACK流程，但是基站并沒有給終端配置5QI=1的DRB，大約重建流程1.5秒后收到基站下發(fā)的release原因為空的RRCRelease消息。隨后由于Tqos(6秒)超時，被叫終端發(fā)送SIP580“Preconditionfailure”給網(wǎng)絡側，呼叫建立失敗。解決方案：該問題與華為5GC和基站都有相關性。5GC在版本0解決，5QI=1在用戶跨站重建的保活優(yōu)化（VoNR業(yè)務在跨站重建轉建立5QI=1建立成功后，核心網(wǎng)保持5QI=1，保障語音業(yè)務延續(xù)）。目前版本正在杭州做FOA入網(wǎng)測試，預計2月份會獲取入網(wǎng)證，5月份完成全網(wǎng)升級；基站22A版本已獲得入網(wǎng)許可，通過Xn接口提權上下文可以恢復通話。中興區(qū)域VoNR功控參數(shù)設置不合理導致好點RTP丟包率波動性突高現(xiàn)象概述：在某區(qū)域進行VoNR語音測試，發(fā)現(xiàn)在好點（RSRP=-70dBm、SINR=15dB左右）位置測試時也會出現(xiàn)RTP丟包率高的現(xiàn)象，RTP丟包基本都發(fā)生在基站下調(diào)終端發(fā)射功率的時間。通過統(tǒng)計，此次路測中幾乎一半的RTP丟包均是由于該問題引起。問題分析：在SS-RSRP較高時，相應的路損較低，此時gNB通過上行閉環(huán)功率控制調(diào)低終端發(fā)射功率，但過低的發(fā)射功率可能導致gNB不能正常解調(diào)PUSCH信道(PUSCH誤包率上升)，從而導致RTP包未能成功發(fā)送到網(wǎng)絡側。在PUSCH重傳增多時，上行誤包率增大，gNB又通過上行閉環(huán)功率控制調(diào)高終端發(fā)射功率，此后PUSCH信道、RTP包發(fā)送正常。當PUSCHBLER低時，基站閉環(huán)功率控制持續(xù)下調(diào)，導致上行發(fā)射功率過低，影響上行數(shù)據(jù)的接收。發(fā)生連續(xù)NACK，導致丟包。分析發(fā)現(xiàn)，中興的參數(shù)配置主要針對數(shù)據(jù)業(yè)務，內(nèi)環(huán)調(diào)控周期相對較長，調(diào)控兼顧小區(qū)間干擾水平，UE功率抬升相對平穩(wěn)，盡量降低干擾水平。相對語音實時類業(yè)務，就顯示出外環(huán)對內(nèi)環(huán)影響滯后。解決方案：針對上述問題現(xiàn)象，調(diào)整內(nèi)環(huán)控制策略，修改參數(shù)配置：功控濾波周期因子，UlSinrFilterFactor：64->16。調(diào)整更為匹配語音業(yè)務，同時也兼顧數(shù)據(jù)業(yè)務。中興基于質量異系統(tǒng)切換功能與呼叫保持沖突現(xiàn)象概述：VoNR測試期間發(fā)現(xiàn)，在中興部署基于語音質量異系統(tǒng)切換功能的小區(qū)進行VoNR呼叫保持業(yè)務，呼叫保持后雙方必然出現(xiàn)5G到4G切換。針對上述問題展開分析，在發(fā)現(xiàn)問題的小區(qū)進行撥測，同步抓取呼叫保持雙方的終端日志分析：呼叫保持發(fā)起端信令分析本端VoNR起呼在17:01:30正常接聽后進入通話狀態(tài)，通話過程中本端上下行均按照RTP包序號依次遞增正常收發(fā)包。在時間點17:01:35本端發(fā)起呼叫保持，本端語音承載被設置為sendonly（只發(fā)不收）并同步將會話下行GBR和MBR配置2kbps(阻斷下行RTP流，只保留RTCP傳輸使用帶寬，此時本端將處于靜音狀態(tài)，在此之前流程均正常。但在呼叫保持大概10s后，網(wǎng)絡側下發(fā)切換至LTE重配置命令，經(jīng)查詢基站參數(shù)，確認此次切換為基于語音質量的5G至4G異系統(tǒng)切換。由于位于局樓室分5G和4G無線環(huán)境非常好的情況下進行測試，正常不會觸發(fā)基于語音質量切換。經(jīng)過咨詢中興廠家，中興基于語音質量的切換是通過監(jiān)控RTP包來實現(xiàn)的，只要上下行中任一方向滿足RTP丟包門限即會觸發(fā)基于質量切換。經(jīng)過與終端的上下行RTP包序號核對，在本端發(fā)起呼叫保持的re-invite后，上下行最后一個RTP包序號分別為156（上行）和11054(下行)，由于是進行呼叫保持業(yè)務，此后到切換的10s時間內(nèi)再無RTP包。查詢中興網(wǎng)管配置的語音質量參數(shù)，該小區(qū)配置的上下行語音質量評估周期剛好為5s*2=10s，也就是說在這10s評估周期內(nèi)中興基站將呼叫保持正常的上下行不收發(fā)包狀態(tài)誤判為RTP丟包，從而觸發(fā)了基于語音質量的異系統(tǒng)切換。被保持端信令分析針對上述分析的結果，對被保持端信令再次分析確認，在收到呼叫保持的re-invite命令后發(fā)起invite200ok將語音承載設置為recvonly(只收不發(fā))狀態(tài)，并同步將會話上行GBR和MBR配置2kbps(阻斷上行RTP流，只保留RTCP傳輸使用帶寬)，此時呼叫保持對端將會進行放音“請不要掛機，您撥打的用戶使用呼叫保持……”。在呼叫保持后大概10s后同樣觸發(fā)了基于語音質量的系統(tǒng)切換，針對RTP包序號進行分析，在呼叫保持后上行的方向在呼叫保持后最后一個包序號為528，此后再無上行RTP包。根據(jù)中興基于語音質量切換功能定義:只要上下行有一個方向出現(xiàn)質差就會觸發(fā)切換，中興基站基于呼叫保持時將放音端上行正常沒有發(fā)包狀態(tài)誤判為RTP丟包，已經(jīng)滿足語音質量切換條件觸發(fā)切換，結論與呼叫保持發(fā)起端分析一致。進一步分析發(fā)現(xiàn)，此時放音端下行雖然一直收到RTP包，但是在呼叫保持前后由于語音源變更(語音SSRC:1422155129->放音SSRC:1868718491)導致包序號重置(語音最后一個RTPRN:417->放音第一個RTPRN:24988)，如果中興基站僅基于RTP包序號判斷丟包而不考慮SSRC不同的話，同樣會將下行包序號重置誤判為RTP丟包從而觸發(fā)基于語音質量切換。綜上所述，中興基站基于語音質量切換功能不適配呼叫保持等特殊業(yè)務需求，會將呼叫保持正常的不收發(fā)包狀態(tài)誤判為RTP丟包從而觸發(fā)基于質量切換，并且在放音端由于下行SSRC不同導致RTP包序號重置誤判為丟包同樣會誤觸發(fā)基于質量切換，由于其功能不完善導致呼叫保持過程必定發(fā)起不必要異系統(tǒng)切換，影響VoNR占網(wǎng)時長，也有可能導致用戶誤判當前無線環(huán)境有問題。解決方案：主被叫任意一方使用通話保持功能觸發(fā)基于語音質量切換至4G問題和場景參數(shù)配置相關，通過調(diào)整基于質量切換算法的配置模式。啟動無線信道測量，配合丟包率聯(lián)合判決，并且調(diào)整濾波周期。在小區(qū)進行復測上述問題得到解決。中興公司內(nèi)部通過技術通知單發(fā)布全網(wǎng)，按需變更。SSRC不同導致RTP包序號重置，基站已經(jīng)考慮保護策略:如果當前RTP報文與上一個RTP報文的SSRC字段不相同，則認為丟包數(shù)等于0。中信科弱場語音起呼自適應未回SMF正確cause導致起呼失敗現(xiàn)象概述：VoNR弱場起呼自適應是指網(wǎng)路側可配置EPSFB與VoNR自適應A2門限（測量目的為啟動弱場起呼過程），當RSRP小于該門限后，終端上報A2事件，此后該用戶在此基站下語音采用EPSFB方案。在開展弱場測試中，發(fā)現(xiàn)終端可回落，但是回落后出現(xiàn)INVITE503ServiceUnavailable,導致通話失敗。問題分析：基站側已開啟弱場起呼開關，A2事件測量配置為啟動弱場起呼過程：核查對應用戶基站側log，發(fā)現(xiàn)弱場自適應到EPSFB時，基站回復核心網(wǎng)的PDUSessionResourceModifyResponse中攜帶的CAUSE為Handover

desirable

for

radio

reasons正常的EPSFB用戶基站回復核心網(wǎng)PDUSessionResourceModifyResponse中攜帶的CAUSE為IMSvoice

EPS

fallback

or

RAT

fallback

triggered綜上，中信科目前版本用戶處于VoNR轉EPSFB時，基站收到核心網(wǎng)建立5QI1的PDUSessionResourceModifyRequest后，基站會給用戶處理建立專載，但在回復SMF專載建立失敗時所攜帶的CAUSE有誤，導致SMF沒有在用戶回落到LTE去重新建立專載，影響用戶的正常接通。。解決方案：需要改攜帶的原因值，目前已經(jīng)在下一個版本V1.00.60.00版本解決，正在獲取入網(wǎng)許可證流，后續(xù)可通過版本升級解決該問題。愛立信5G基站不支持RoHC頭壓縮功能導致VoNR語音呼叫建立時延長現(xiàn)象概述：在愛立信5G基站下測試VoNR業(yè)務時，統(tǒng)計主叫側呼叫建立時延為2.64s，高于其他廠家的1.8s，現(xiàn)場嘗試開啟預調(diào)度功能后，對比呼叫建立時延無明顯改善。問題分析：通過分段統(tǒng)計對比不同廠家VoNR建立時延，發(fā)現(xiàn)愛立信在5QI=5承載建立階段的時延比其他廠家長，其他階段相差不大。進一步對比分析，發(fā)現(xiàn)其他廠家在開啟5QI=5的預調(diào)度后，時延會減少300ms以上，而愛立信開啟5QI=5的預調(diào)度后，時延無明顯改善。深入分析預調(diào)度不能生效的原因。發(fā)現(xiàn)當前基站版本不支持RoHC頭壓縮功能，懷疑VoNR上行RTP包超過預調(diào)度功能預估的初始緩存區(qū)大小，導致UE并不能在一次調(diào)度內(nèi)發(fā)送完上行RTP包，進而導致預調(diào)度功能開啟后對VoNR呼叫建立時延無明顯改善。初傳RTP包大小計算過程如下：初傳RTP包大小需要綜合考慮的因素如下：VoNR語音編碼方案:EVS24.4PDCP/RLC包頭大小非壓縮的IP/UDP/RTP包頭:不支持RoHCSIP,RTP協(xié)議使用IPV6上行語音包一次調(diào)度傳輸(BSR=0)根據(jù)以上因素，計算出的RTP包TBS大小為131bytes，計算方法如下：488bits,61bytes(voicepayload)+60bytes(非壓縮的IP/UDP/RTP包頭)+18bits,3bytes(PDCPheader,TS38.323)+56bits,7bytes(RLC+MAC+BSR+CRC)=61+60+3+7=131bytes基于以上計算，初傳RTP包大小已經(jīng)超過了預調(diào)度功能預估的初始緩存區(qū)大小，需要通過多次調(diào)度才能完成上行RTP包發(fā)送，現(xiàn)場將preschedulingDataSize參數(shù)由86修改至150，VoNR呼叫建立時延減小至1.9s，測試信令截圖如下：解決方案：因為愛立信5G暫不支持RoHC頭壓縮，導致預調(diào)度功能不能生效，從而嚴重影響VoNR的接通時延。且愛立信暫時無法給出解決該問題的具體時間。在這種情況下，建議將preschedulingDataSize參數(shù)由86修改至150Bytes，保證在一次調(diào)度內(nèi)完成上行初始RTP包發(fā)送，可明顯改善VoNR的接通時延。愛立信5G站點VoNR通話中PDSCHBLER不收斂導致高丟包現(xiàn)象概述：在VoNR業(yè)務時，VoNR平均丟包率達到1%，丟包率超過1%的通話占比達超過20%。分析發(fā)現(xiàn)在PDSCHBLER高的時候下行仍然采用高階編碼方式（64QAM/256QAM），PDSCHBLER不收斂，導致高丟包。問題分析:整個VoNR拉網(wǎng)，VoNR平均丟包率達到1%，丟包率超過1%的通話占比超過20%，PDSCHBLER大于20%的占比為35.95%；同時下行編碼64QAM占比48.35%，256QAM占比為35.92%。（對比華為區(qū)域拉網(wǎng)數(shù)據(jù)，QPSK達到占比97%）。無線環(huán)境快速變化區(qū)域無線環(huán)境平穩(wěn)區(qū)域無線環(huán)境快速變化區(qū)域無線環(huán)境平穩(wěn)區(qū)域圖中棕色面積圖代表PDSCH初始BLER，綠色曲線代表SS-SINR，黑色代表曲線DLMCS。可以看出，從該示意圖中可以看到隨著SINR的提升，MCS也隨之提升，但是也隨之BLER升。無線環(huán)境平穩(wěn)區(qū)域（左邊）：該區(qū)域SINR變化緩慢，MCS緩慢降階后，BLER隨之收斂。無線環(huán)境快速變化區(qū)域（右邊）：該區(qū)域SINR快速變化，MCS隨著SINR變化，而是向BLER收斂方向變化，最終導致BLER不收斂。解決方案：聯(lián)系愛立信總部研發(fā)，計劃升級基站版本解決該問題。（據(jù)了解，同類型問題在愛立信19年基站版本（1917）也出現(xiàn)過，當時為數(shù)據(jù)業(yè)務BLER高，導致重傳次數(shù)過多，影響峰值速率。后愛立信通過基站版本升級解決）。愛立信N21.2基站版本開啟VoNR后IPhone12終端出現(xiàn)無法被叫現(xiàn)象概述：在愛立信N21.1及N21.2基站版本測試VoNR業(yè)務時，發(fā)現(xiàn)同站下IPhone12終端出現(xiàn)無法被叫的問題。IPhone12終端VoNR業(yè)務的主被叫以及和huaweimate40pro對比測試，情況如下：1）VoNR語音業(yè)務：蘋果iPhone12主叫可以接通，被叫出現(xiàn)未接通現(xiàn)象，未接通時主叫側信令顯示abnormalSIPcall（原因值：580）。huaweimate40pro主被叫均正常2）做EPSFB語音業(yè)務：蘋果iPhone12和huaweimate40pro主被叫均正常問題分析：愛立信南通NR2.6G站點，軟件版本：N21.1以及21.2。cellName小區(qū)名nRPCInRTACNT_CC_NTNR68J78_E5H_2611南通-崇川-五山小學-E5H-2611271049000參數(shù)配置如下：MO參數(shù)取值范圍默認值參數(shù)解釋建議值McfbmcfbCellProfileEnabledtrue/falseFALSEMcfb功能開關TRUEMcfbvoiceEpsFbPossibletrue/falseTRUE是否允許語音EPSFBTRUEMcfbCellProfileepsFallbackOperation0~620:采用VoNR

2:采用盲重定向

3:采用測量的重定向

6:采用基于測量的切換0McfbCellProfileepsFallbackOperationEm0~50緊急呼叫的EPSFB或VoNR策略0McfbCellProfileepsFbTargetSearchTimer1~12000ms500基站等待B1測量時長2000McfbCellProfile,rsrpCellCandidatethreshold-140~-44-140LTE小區(qū)需滿足的B1門限-110McfbCellProfile,rsrpCellCandidatetimeToTrigger0~5120ms40B1判決時間160測試驗證：（1）測試整體情況1）VoNR語音業(yè)務，蘋果iPhone12主叫可以接通，被叫出現(xiàn)未接通現(xiàn)象，未接通時主叫側信令顯示abnormalSIPcall（原因值：580）。huaweimate40pro主被叫均正常2）做EPSFB語音業(yè)務，蘋果iPhone12和huaweimate40pro主被叫均正常終端類型呼叫描述VoNR測試EPSFB測試備注iPhone12主叫okok被叫nookVoNR:iPhone12主叫能接通

VoNR:iPhone12被叫無法接通，主叫側信令顯示abnormalSIPcall（580）HUAWEIMate40pro主叫okok被叫okok（2）iPhone12被叫測試VoNR在5G網(wǎng)打開VoNR業(yè)務時，HUAWEIMate40pro做主叫，iPhone12做被叫測試。SS-RSRP=-61dbm，SS-SINR=10db，無線環(huán)境良好。信令對比：對比正常的VoNR 信令和iphone12做被叫異常信令可以看出：第一階段：VoNR起呼階段Invite-Request均正常第二階段：PDUsessionmodification會話修改階段流程正常第三階段：呼叫振鈴接通階段：正常信令：收到Ring180，以及InviteOK200異常信令（iPhone12被叫）:Ring180和InviteOK200均未收到，收到異常信令Invite58異常信令：IPhone12做被叫正常VoNR信令事件對比：正常事件：callattempt后到callsetup以及callestablished異常事件（iPhone12被叫）:callattempt后abnormalsipcall，之后直接blockcall異常事件：IPhone12做被叫正常VoNR事件綜上，海思5G終端在愛立信SA網(wǎng)絡下語音VoNR及EPSFB均正常。蘋果iphone12終端在愛立信 SA網(wǎng)絡下VoNR語音主叫正常，被叫無法接通。但做EPSFB主被叫均正常。解決方案：經(jīng)現(xiàn)場核查驗證，參數(shù)epsFallbackOperation設置1可規(guī)避蘋果IPhone12/13使用VoNR業(yè)務時被叫未接通現(xiàn)象。此時非蘋果終端可正常使用VoNR業(yè)務，蘋果終端IPhone12/13使用EPSFB做語音業(yè)務。參數(shù)介紹：MO參數(shù)建議值參數(shù)解釋McfbCellProfileepsFallbackOperation1支持VoNR終端執(zhí)行VoNR，不執(zhí)行VoNR的終端觸發(fā)盲重定向驗證過程：huaweimate40pro終端互撥當在此參數(shù)配置下，兩部海思終端（mate40pro）之間在SA網(wǎng)絡互撥時，由于終端支持VoNR業(yè)務，主被叫均觸發(fā)VoNR語音業(yè)務，撥打多次，成功率均為100%，VoNR呼叫正常。蘋果IPhone和海思終端互撥當SA網(wǎng)絡該參數(shù)配置下，由于蘋果IPhone12/13當前版本暫不支持VoNR業(yè)務，無論蘋果IPhone12/13作