介紹VoLTE網優問題分析和優化方法，為後續VoLTE測試或網絡優化提供參考。
1.1 IMS註冊流程VoLTE用戶建立語音通話之前，前提必須要在MME附著和IMS註冊，以下為UE開機註冊流程：
整個IMS註冊流程可以分為MME附著和IMS註冊兩個過程：
1. MME附著：
UE剛開機時，先進行物理下行同步，搜索測量進行小區選擇，選擇到一個合適或者可接納的小區後，進行隨機接入完成上行同步並在LTE附著，建立 QCI=9默認承載，此過程為MME附著流程。
2. IMS註冊：
（1） VoLTE本質也是數據業務，需要建立相應業務類型的QoS承載，以承載業務數據或信令。支持VoLTE的終端在完成LTE MME附著後，在UE向IMS網元發起註冊前，必須建立QCI=5的承載，用以承載IMS SIP信令；當QCI=5承載建立完成後，UE與IMS進行SIP信令的交互。
（2） UE向IMS發送REGISTER消息，通過IMS網元P-CSCF將註冊消息轉到I-CSCF，I-CSCF通過HSS為UE選擇一個S-CSCF並將註冊消息轉給S-CSCF，S-CSCF從HSS獲得用戶的鑑權參數並通過S-CSCF、I-CSCF到P-CSCF發給UE，UE獲得鑑權數據後，完成手機對網絡的校驗；隨後發起用戶的二次註冊請求，UE利用鑑權數據與共享密鑰生成的某鑑權參數（RES）與S-CSCF保存的某鑑權參數（XRES）對比通過後，最終完成網絡對UE的鑑權校驗。IMS以200 OK消息響應二次REGISTE消息，完成在IMS的註冊。
至此，用戶若要進行VoLTE語音呼叫，需通過觸發核心網建立一條用於傳輸IMS語音包的QCI=1專用承載進行語音通話。基於IMS的VoLTE語音通話需要建立QCI=9、QCI=5、QCI=1三條承載。
上圖說明：
1. 上圖黑色線為信令，綠色線SIP信令。
2. 步驟1～5建立RRC連接：步驟3和4用於UE與eNB進行連接建立，連接建立的主要目的是衝突解決，建立信令承載SRB1，為後續的NAS 的Attach Req消息提供鏈路承載；消息5（Attach Req消息）可以附帶在RRC 連接建立完成消息，並需要被透傳到MME。
3. 步驟6~13建立S1連接：對於消息6，由於此時eNB和MME的S1鏈路還沒有建立完成，所以eNB發送INITIAL UE MESSAGE到MME，消息中攜帶eNB為S1分配的eNB UE S1AP ID，Attach Req消息附帶在INITIAL UE MESSAGE透傳到MME的NAS層。
4. 消息13說明：MME發起INITIAL CONTEXT SETUP REQUEST給eNB，請求eNB建立承載資源，消息中攜帶的NASPDU表明是否接受UE發起的Attach Req消息。如果接受，同時消息中攜帶該UE總計的最大bit率，多條待建的承載信息（QOS參數，上行對應的媒體面地址，TEID），UE的安全能力(UE支持的完整性檢查和加密能力,安全能力在attach req中帶給MME)，安全Key值(用於eNB推導完整性key和加密key)，UE無線能力(支持的接入類型(E UTRA，GERAN等))，如果INITIAL CONTEXT SETUP REQ消息中不攜帶UE的無線能力，eNB可以發起RRC UECapabilityEnquiry流程。
5. 消息14~16說明：實現的時候，為了節省Attach時延，eNB在發送完消息6後，就問UE要能力信息，即先執行消息14、15。
6. 消息17~19說明：eNB發送完消息17，並不需要等收到消息18，就直接發送消息19。
7. 消息23~28說明：IMS SIP註冊消息需要建立QCI=5承載，當QCI=8/9的默認承載建立後，UE發起的另一個PDN連接建立請求用於建立QCI 5承載（消息23），消息24~27為MME到UE間建立QCI=5默認承載的信令流程。
8. 如果發起IMSI attach時，UE的IMSI與另外一個UE的IMSI重複，並且其他UE已經Attach，則核心網會釋放先前的UE。如果IMSI中的MNC與核心網配置的不一致，則核心網會回復AttachReject。
1.2 VoLTE呼叫流程VoLTE呼叫類型包含四種：空閒態（Idle）呼叫空閒態（Idle）、空閒態（Idle）呼叫連接態（Connected）、連接態（Connected）呼叫空閒態（Idle）、連接態（Connected）呼叫連接態（Connected），其中，第一種場景業務流程最為常見且複雜。後三種場景只是主叫或被叫有一個或兩個處於連接態（Connected），無RRC連接過程，因此，可以參照第一種場景的業務流程。
以下以空閒態（Idle）呼叫空閒態（Idle）為例：
正常的VoLTE呼叫建立包括RRC連接建立和SIP會話建立：
RRC連接建立：RRC IDLE狀態的終端通過「隨機接入-RRC連接建立-DRB建立」空口過程完成與無線網的連接並開始上、下行數據傳送，視作成功完成連接建立。
SIP會話建立：從主叫終端發起SIP INVITE消息到接收到網絡側下發的SIP 200 OK（invite）消息。
上面流程圖說明如下：
1. IDLE下主叫UE發起VoLTE語音業務，主叫UE與eNB完成RRC連接建立過程，初始上下文建立過程，eNB下發RRC重配消息，此重配中帶有QCI9和QCI5承載的重配置信息，完成QCI8/9和QCI5C承載重配。
2. 待QCI5承載重配完成後，主被叫UE可以與IMS進行SIP會話流程交互，主叫發SIP信令INVITE消息到IMS，IMS轉發INVITE消息首先經過PDN網關到SGW網關，SGW發現UE B為IDLE模式，發送下行數據到達通知給MME，MME對被叫發起尋呼。
3. 處於IDLE下的被叫收到Paging消息後，被叫發起和主叫同樣的空口信令流程，完成RRC連接建立過程，初始上下文建立過程，eNB下發RRC重配消息，此重配中帶有QCI9和QCI5承載的重配置信息，完成QCI8/9和QCI5C承載重配。
4. 主被叫發起QCI1專用承載建立，用以承載語音數據包。
5. 當主叫UE收到被叫INVITE的200OK消息後，向被叫響應ACK消息，待被叫收到ACK後，通話開始。
6. 若被叫發起掛機，將發送BYE消息給主叫，主叫收到後，回復200OK（BYE）給被叫，通話結束，隨後主被叫資源釋放。
另外，對於VoLTE掉話，是指UE異常退出RRC_CONNECTED狀態導致的連接中斷，即：空口RRC連接不是終端主動發起的異常釋放，或者在UE沒有收到Release消息的情況下，直接從RRC-CONNECTED狀態轉到RRC-IDLE。
常見的現象有如正在VoLTE通話中，收到來自eNB的RRC連接釋放消息且RRC重建失敗，如下圖：
常見的VoLTE掉話或接入失敗原因有覆蓋問題、幹擾問題、切換問題、鄰區問題及設備問題等，對於掉話問題，通過相應的數據分析其掉話的原因，並根據不同的掉話類型採取具體的解決方案，詳見第5章節。
1 路測指標定義下表為中移VoLTE試點階段時的相關指標定義，目前中移重點關注的基本指標為：
考核關鍵指標
我司目標值
備註
呼叫接通率
>99%
掉話率
<0.5%
系統內切換成功率
>99%
eSRVCC切換成功率
>98%
eSRVCC觸發率
<2.6%
eSRVCC的用戶面中斷時延
<200ms
端到端RTP丟包率
<1%
MOS值
>3.8
初傳上行BLER
<5%
初傳下行BLER
<5%
剩餘下行BLER
<1%
剩餘下行BLER
<1%
IMS呼叫建立時延
<3s
被叫處於IDLE態下，主叫撥打被叫
<2s
被叫處於連接態，主叫撥打被叫
對於接通率、掉話率、eSRVCC切換成功率，網優側需要做好基礎優化，如覆蓋、鄰區（系統內/間、鄰區參數、鄰區完善等）、合理參數設置等這幾個方面的網優工作。
以下為外場路測指標定義，後續估計會有所增加或改動，以下供了解：
指標分類
指標名稱
定義
資源佔用類
上行RB數
每秒上行調度RB數/每秒上行實際調度次數*100%
下行RB數
每秒下行調度RB數/每秒下行實際調度次數*100%
上行MCS
每秒上行調度MCS值之和/每秒實際調度次數*100%
下行MCS
每秒下行調度MCS值之和/每秒實際調度次數*100%
上行終端發射功率
每秒內終端發射功率的平均值
GSM通話時長佔比
指定時間內終端在GSM制式下的通話時長 / 指定時間內終端總通話時長*100%
呼叫eSRVCC切換佔比
發生eSRVCC切換的呼叫次數 / 總呼叫次數*100%
語音質量類
MoS
MoS盒輸出的平均意見得分（PoLQA算法）
BLER
初傳BLER
（初傳次數-初傳成功次數）/初傳次數*100%
剩餘BLER
（初傳次數-多次重傳後成功次數）/初傳次數*100%
語音丟包率
（發送數據包數—接收數據包數）/發送數據包數*100%
抖動
接收端RTP/PDCP層數據包時延方差
呼叫建立時延
終端發出的第一條隨機接入消息到接收到網絡側下發的SIP 180 Ring消息時間差
IP包時延
從主叫發出到被叫接收的RTP層數據包時間差
端到端時延
主叫端語音編碼器輸入到被叫端解碼輸出的時間差
上行速率
過去一秒內，上行PDCP層發送的總比特數
下行速率
過去一秒內，下行PDCP層接收的總比特數
切換中斷時延
網內控制面
終端在源小區收到RRC重配消息指示切換，到終端在目標小區收到RRC重配消息指示切換完成的時間差
網內用戶面
源小區最後一個PDCP層數據包到目標小區接收到的第一個PDCP層數據包的時間差
網間控制面
空口
從eNodeB下發Handover Command到終端向BSS發送HO Complete的時間差
核心網
MME向eMSC發送PS to CS Request，到收到PS to CS Complete/Ack的時間差
網間用戶面
源小區最後一個PDCP層數據包到目標小區建立專有信道恢復話音的時間差
話音掛機時延
主叫端發起BYE Message到收到網絡側下發的SIP 200 OK消息差
RRC重建時延
從終端發生RLF（Radio Link Failure，無線鏈路失敗）的時刻，大盤終端發出RRC Connection Reestablishment Complete的時刻
KPI指標類
IMS註冊成功率
IMS註冊成功次數 /終端開機次數*100%
話音接通成功率
成功完成呼叫次數/終端發起呼叫總數*100%
掉話率
掉話次數/成功建立呼叫次數*100%
網內切換成功率
切換成功次數/切換請求次數*100%
eSRVCC切換成功率
eSRVCC切換成功次數/eSRVCC切換嘗試次數*100%
尋呼成功率
尋呼成功次數/EPC發起尋呼請求總次數*100%
平均長保時間
用戶保持通話狀態時間的平均值
緊急呼叫建立成功率
撥打緊急呼叫成功接通次數/總撥打次數*100%
裡程掉話比
掉話次數 / 呼叫行駛的裡程數（km）*100%
1 eNB無線參數配置版本601P01 VoLTE功能限制：對於商用初期，VoLTE用戶不太多的情況下，關閉QCI1承載的SPS和DRX功能。
具體配置可以參考《ZTE LTE TDDVoLTE(V3.30.601)基本原理與開通指導書_R2.0》。
2 5月指標趨勢及問題分類佔比2.1 5月指標5月份攻關小組通過版本升級、覆蓋優化、鄰區關係優化、參數核查等手段，長沙河西區域整體VoLTE指標提升明顯
日期
LTE接通成功率
呼叫在LTE撥打的次數
呼叫在LTE撥打成功的次數
LTE掉話率
主叫在LTE掉話的次數
被叫在LTE掉話的次數
2015-5-6
100.00%
70
70
5.71%
4
0
2015-5-7
96.77%
62
60
0.00%
0
0
2015-5-8
93.01%
143
133
6.77%
4
5
2015-5-9
97.30%
74
72
6.94%
2
3
2015-5-11
96.06%
127
122
3.28%
4
0
2015-5-12
96.67%
150
145
2.76%
4
0
2015-5-13
99.47%
188
187
1.07%
1
1
2015-5-14
97.87%
328
321
4.98%
14
2
2015-5-15
98.56%
348
343
1.75%
6
0
2015-5-16
99.18%
243
241
1.66%
3
1
2015-5-17
95.81%
167
160
1.25%
2
0
2015-5-18
100.00%
106
106
0.00%
0
0
2015-5-19
99.23%
389
386
1.04%
4
0
2015-5-20
99.01%
405
401
0.50%
2
0
2015-5-21
98.51%
201
198
0.51%
1
0
2.2 問題分類佔比
截止5月21日的 R5p 版本全網路測軟體拉網log已分析完畢，其中未接通事件51個，掉話事件71個，分類情況如下：
未接通問題分類
未接通數量
未接通分類佔比
無線覆蓋問題
7
13.73%
TAU過程中尋呼問題
12
23.53%
核心網問題
3
5.88%
終端問題
10
19.61%
重定向問題
7
13.73%
站點斷鏈
4
7.84%
測試軟體問題
4
7.84%
原因不明
2
3.92%
鄰區漏配
2
3.92%
合計
51
100.00%
掉話問題分類
掉話數量
掉話分類佔比
無線覆蓋問題
15
21.13%
站點斷鏈
10
14.08%
室分信號洩露
8
11.27%
測試軟體問題
4
5.63%
鄰區漏配
12
16.90%
TAU過程中專用承載建立問題
2
2.82%
原因不明
2
2.82%
重定向問題
18
25.35%
合計
71
100.00%
1.1 遺留問題序號
問題描述
進展
問題狀態
責任人
1
4G系統內做TAU時，核心網沒有向目標小區發尋呼消息；
5.13：核心網側研發分析判斷是否可以進行部分機制的調優
5.18:【核心網答覆】：是流程衝突，在尋呼的時候，收到TAU消息，我們會當做Paging response處理，如果TAU Request消息中沒有攜帶active flag，那麼用戶面隧道是無法建立的，消息也無法投遞。
這個問題在核心網的下一個補丁中做優化，我們會在TAU過程中無論UE是否攜帶了active flag都去建立用戶面隧道。
open
陶宜富
2
從2G/3G到4G的系統間TAU，核心網沒有消息回應；
5.13：核心網側研發分析判斷是否可以進行部分機制的調優，
5.18:【無線側的疑問】：認為2G到4G重選，被叫此時並不是在呼叫狀態回到4G，HSS應該重新域選擇，把呼叫重新轉到4G來尋呼。不然以後這種場景就是打不通。
【核心網答覆】：還未收到專家答覆，待回復。
open
陶宜富
3
跨TAC後，在462696-2小區15:46:24呼叫建立之2s，核心網S1ap上收到兩條ERAB釋放(QCI=1/QCI=5)的指示後掉話
5.18:【核心網答覆】：分析有可能是SGW把會話誤刪了，導致eNB收到了error Indication，然後發起了釋放。需要看無線log是否是分析的原因。；現網SGW確實有個已知的問題，在「MME改變，SGW沒有改變的短時間內4切3再切4」過程中，SGW會刪除上下文導致用戶掉線
open
陶宜富
2 VoLTE網絡優化分析和案例總結2.1 覆蓋類問題2.1.1 地形環境導致弱覆蓋
【問題現象】路測表現為：主被叫手機當前小區和所有鄰區RSRP均小於-110dbm，無主服務小區導致SINR<-3dbm,無線環境惡化，導致掉線、切換失敗、接入失敗等異常事件頻發。
【問題分析】結合現場環境和基站拓撲圖，對周邊所有基站進行逐個勘察和驗證覆蓋，對於地形原因導致無法徹底解決的區段，提交後續工程建設方案。
【解決方案】：
1：核查局方站點規劃方案，如果有規劃站點，提高建設開通優先級，如果無建設規劃，提交建站方案；
2：測試2G網絡覆蓋情況，對於2覆蓋良好情況下，開啟SRVCC功能；同時確保2G側FR功能開啟，確保及時回落4G。
3：對於有測試考核要求的情況下，採取規避路線，減少異常事件發生概率；
2.1.2 鄰區漏配導致弱覆蓋【問題現象】
DT測試中，此類問題主要表象為如下幾種情況：
1. 頻發A3事件而無法切換；
2. 通常伴隨主被叫佔用小區不同，RSRP相差較大；
3. 切換鏈紊亂；
4. 容易引發掉線、重建立、切換失敗等事件
如下圖：
【問題分析】
1：前臺測試分析，核對A3事件上報小區信息是否包含在RRCConnectionReconfiguration。如未包含，則確定為漏配鄰區。核對基站拓撲圖，判斷是否需要添加該鄰區，排除過覆蓋、針狀覆蓋小區（室分洩露小區、非道路覆蓋小區等）尤其需要慎重添加，防止切換後無法及時切出問題發生。
如下圖所示，兩個基站相距200m，並且為相鄰基站，所以建議補充鄰區關係
2：後臺IMSI跟蹤信令分析，可以通過UDA工具篩選UnknowPciNotify，對於持續上報未定義PCI的現象要重點結合基站拓撲圖來進一步確定是否添加鄰區。
如下圖，後臺信令分析同樣發現上報多個測量報告切換候補鄰區為486，結合拓撲圖，最終建議添加鄰區關係
【解決方案】：
1：近距離相鄰基站通常採用添加遺漏鄰區方案；
2：過覆蓋小區優先控制覆蓋；
3：針狀覆蓋場景不建議添加，此問題一般影響較短路面，優先控制覆蓋；
2.1.2.1 實例1【問題現象】
主被叫佔用新開基站983529133（PCI149)後無鄰區關係導致無線環境惡化；
【問題分析】
下圖為主被叫佔用該小區後，RSRP由強到弱，無線環境逐步惡化，A3事件頻繁上報但是未發起切換，查看鄰區配置發現該站僅僅配置自身2個小區為鄰區關係，通過了解，此站點為新建基站，未實施單驗和入網優化工作，因此在此路段頻繁導致掉話、重建立等事件發生
【解決方案】
1：及時開展單站優化和鄰區關係補充，確保單站業務性能通過驗收；
2：開通站點第一時間通知優化團隊進行參數核查、鄰區核查、性能測試，確保入網後正常投入網絡運行。
2.1.3 站點故障導致弱覆蓋
【問題現象】
測試中，此問題表現為：無法佔用附近基站，會伴隨鄰區漏配、過覆蓋情況發生，易導致未接通、掉線、切換鏈紊亂等現象；
如下圖，基站462682位於麓楓路和鹹嘉湖西路十字口，為該兩條主幹道主服務小區，測試到該路段後始終未佔用該基站，RSRP下降到-110dbm以下，切換鏈紊亂，導致掉線。
【問題分析】
站點「長沙陽明山莊23棟(地華梅溪湖拉遠)ZL-B8300462682PT」因糾紛暫時下網，導致周邊無主覆蓋小區；
【解決方案】：
需儘快恢復「長沙陽明山莊23棟(地華梅溪湖拉遠)ZL-B8300462682PT」；對周邊小區開啟SRVCC切換。
2.1.4 越區覆蓋導致無法切換【問題現象】
過覆蓋問題主要表象為：
未佔用過覆蓋小區情況下，當前小區可能會發生SINR惡化，伴隨上報測量報告包含周邊未知PCI。
佔用過覆蓋小區情況下，RSRP變化較大，伴隨上行信號異常，鄰區漏配現象，易導致掉線、接入失敗、切換失敗等異常事件。
如下圖，手機佔用PCI=121小區，enodeid=471089，無法向周邊PCI=110切換，最終導致掉話；
【問題分析】
此類問題需要結合周邊道路測試分析和基站拓撲關係來判斷問題小區為周邊哪個區域的主覆蓋小區，進而採取優化手段進行調整；
如下圖描述，問題點區域最近4次切換鏈為1、2、3、4次切換，其中2、3、4切換和PCI=121有關，同時分析周邊道路主服務小區並無PCI=121,查看拓撲圖發現該站位於周邊較遠區域，同時前往PCI=121測試發現，經緯度正確，主要原因是地勢較高導致；
【解決方案】：
針對周邊過覆蓋小區，採用調整俯仰角、天線掛高、基站分布等手段；
對於特殊場景建設的基站，比如此案例中該站實際主要覆蓋附近風景區，但是地勢原因導致信號無法徹底控制，可以採取單向刪除過遠基站鄰區，避免孤島效應。
2.1.4.1 實例1 嶽華路長房和園附近長沙觀沙嶺消防隊2小區越區覆蓋【問題描述】
UE從4625062到4620931切換不及時導致重建
【問題分析】
1、增強4625333、4620931在此處的覆蓋；
2、壓低4625062下傾角2-3°。
已調整4625333、4620931小區方位角及下傾角至該路口覆蓋，但覆蓋方向存在部分阻擋，已達最大優化調整，調整後測試效果不明顯，後調整新開站點長沙嶽麓大道與嶽華路交叉口-3小區覆蓋至該片區域，調整後覆蓋得到一定增強，如需徹底解決該片區域覆蓋問題，需開通該區域規劃站址長沙綠洲小區景觀塔。
【解決方案和複測結果】
通過上述調整，該站點及時切換到983474，越區覆蓋小區此處信號減弱。
2.1.5 切換參數設置錯誤導致無法切換【問題現象】
車輛由東向西行駛在茶子山，當於基站462514退服後不能及時向附近小區切換，使得該路段RSRP差，最終導致掉話。如下圖
對比前期測試該路段正常，如下圖：
【問題分析】
從路測佔用小區來看，即使該站斷站，如果可以向462576-2（PCI=259中心頻點1895Mhz）切換，信號可以保持在-105dbm，不會發生掉話現象。查看未切換到462576-2原因，從路測信令來看，A2事件上報後，重配消息中沒有攜帶該異頻鄰區，首先認為沒有配置該鄰區關係。但是後臺核查鄰區列表後發現已經添加該鄰區，進一步排查為什麼重配消息中未攜帶該鄰區關係，發現【EUtranCellMeasurementTDD】表中的「eutranMeasParas_interCarriFreq」異頻載頻裡面沒有配置1895導致，補充添加後可以正常切換。
【解決方案】
1：主因是由於基站462514退服導致跨站切換不順暢，因此優先解決故障站點
2：從該事件發現，如果測量參數【EUtranCellMeasurementTDD】中漏配異頻頻點，也會導致無法下發該異頻頻點鄰區，即使配置了鄰區關係也是無效，所以需要日常優化中定期核查【EUtranCellMeasurementTDD】表中的「eutranMeasParas_interCarriFreq」是否包含鄰區定義的頻點。
2.1.6 異頻重定向【問題現象】
終端上報A3測量事件後，基站直接發送重定向的RRCrelease消息，導致掉話
【問題分析】
圖中可以看到，終端上發A3事件後，系統直接發送了重定向到37900的RRC release消息，導致此次掉話。
【解決方案】：
1、通過後臺參數，打開鄰區切換功能，解決配置了鄰區但沒打開切換功能的重定向。
2.2 幹擾類問題【問題現象】
測試中一般表現為RSRP良好但SINR偏差，幹擾嚴重區域容易導致掉線、切換失敗等各類異常事件發生。
【問題分析方法】
幹擾類問題涉及方面較多，有系統內幹擾和系統外幹擾，詳細排查方法可以參考排查指導文檔，這裡僅僅對現場發現的案例進行描述。
2.2.1 實例1：PCI規劃不合理導致下圖中，測試區域發現信號RSRP良好同時伴隨SINR較差，優先排查PCI規劃問題，發現近距離有同PCI基站，如下圖：
2.2.2 實例2：重疊覆蓋引發幹擾網格17內西二環路段存在同頻基站分布密集，存在200-300米路段SINR差，此段路段發生重建概率較高，是掉話隱患點，23日測試發生1起主叫掉話。
下圖圈中區域來自4個站點信號均在-95dbm~-100dbm，當切換到PCI=66/67後，SINR容易惡化，地勢較為平坦，周邊間距均在300-400m。
【解決方案】：
針對PCI規劃不合理問題，建議重新規劃和修改PCI。
針對重疊覆蓋引發幹擾問題，首先通過RF優化控制覆蓋，減少重疊覆蓋，其次採用異頻組網方案解決。比如此西二環路段，PCI=66/67/68三個小區可以不用覆蓋該路段，其他三個小區可以良好覆蓋不同區段，引入PCI=66/67/68後易發生摸3幹擾。
2.2.3 實例3：重疊覆蓋引發幹擾主叫在清水路段462326附近收到近距離100m處小區4742163（PCI254)幹擾，導致無法切換發起重建立，該路段基站覆蓋過密集。
【解決方案】：
針對PCI規劃不合理問題，建議重新規劃和修改PCI。
針對重疊覆蓋引發幹擾問題，首先通過RF優化控制覆蓋，減少重疊覆蓋，其次採用異頻組網方案解決。比如此西二環路段，PCI=66/67/68三個小區可以不用覆蓋該路段，其他三個小區可以良好覆蓋不同區段，引入PCI=66/67/68後易發生摸3幹擾。
2.2.4 實例4：嶽麓大道與嶽華路交叉口東側SINR值較差切換失敗【問題描述】
嶽麓大道與嶽華路交叉口東側，UE佔用4623813的SINR值較差，導致切換失敗。
【問題分析】
1、添加4623813與983474133、4625261的鄰區關係。
2、控制4623813在嶽麓大道上的越區覆蓋；
3、核查新開站983474133（170）背向覆蓋與4750223（83）形成強模三幹擾。
4、調整4623813下傾角2°至4°，方位角300°至290°，983474133下傾角2°至0°。
【複測結果】
通過控制覆蓋、鄰區關係優化，該路段幹擾現象消失
2.3 基站版本問題2.3.1 TM3\8切換後掉話
【問題現象】
從前臺信令看掉話流程，終端的模式為TM3，然後上發A2測量，然後終端收到異頻測量控制的重配消息，發送完成後下行鏈路失步，之後發起重建後掉話。此過程中，無線環境在RSRP -100，SINR 3左右。從後臺信令分析，基站側收到終端上發的A2，然後下發測量重配消息，緊接著發送TM8模式切換的重配消息，出現TM8的重配無法下發，用戶面上報SRB1的RLC的ERRORIND導致釋放而掉話
【問題分析】
12:09:14秒的重配置為TM3模式
12:09:14秒上發的是A2測量重配，然後廣播消息，在12:09:26秒收到重建請求後被拒。
12:09:26秒終端上發BYE掉話。
基站側12:09:18收到A2測量
12:09:18秒TM8模式轉換的重配。
12:09:25秒出現錯誤的標示，該重配未下發，達到最大重傳次數。
12:09:25秒文本釋放。
【解決方案】：
此問題為已知版本問題，現場已升級至R5p版本，該問題驗證通過；
2.4 核心網相關問題2.4.1 QCI=5未建立【問題現象】
主叫發起會話請求，無響應，導致未接通；
【問題描述】
主叫12:27:57發起invite，12:28:13 無響應之後未接通，檢查DRB承載，發現優先級為9的承載有兩條，如下圖所示：
【解決方案】
HSS刪除多餘APN籤約，之後恢復正常，如下圖所示；
2.4.2 TAU過程中Paging問題
【問題現象】
10:28:22，主叫起呼發起invite request 之後QCI=1建立，被叫未收到此次呼叫的Paging；
【問題分析】
被叫10:28:23移動過程中發生小區重選，TAC改變發起TAU更新，未收到此次呼叫Paging導致的未接通事件；
此次未收到Paging是流程衝突，在尋呼的時候，收到TAU消息，我們會當做Pagingresponse處理，如果TAURequest消息中沒有攜帶activeflag，那麼用戶面隧道是無法建立的，消息也無法投遞
【解決方案】
核心網在下一個補丁中修正，會在TAU過程中無論UE是否攜帶了active flag都去建立用戶面隧道；
2.4.3 從2G/3G回到4G核心網未發Paging【問題描述】
主叫在4G起呼，被叫3G回到4G，核心網未下發Paging
【問題分析】
主叫16:23:39發起inviterequest 被叫從3G回到4G 16:23:49 ims註冊成功未收到此次Paging，當用戶在3G下，HSS已經做了域選擇，此時用戶重選到4G，是沒有辦法逆轉的。該場景沒有規範支撐
【解決方案】
核心網答覆，暫時無協議支撐
2.4.4 跨TAC之後 QCI=1被刪除【問題描述】
跨TAC後，在462696-2小區15:46:24呼叫建立之2s，核心網S1ap上收到兩條ERAB釋放(QCI=1/QCI=5)的指示後掉話
【問題分析】
SGW把會話誤刪了，導致eNB收到了error Indication，然後發起了釋放。現網SGW確實有個已知的問題，在「MME改變，SGW沒有改變的短時間內4切3再切4」過程中，SGW會刪除上下文導致用戶掉線
【解決方案】
需SGW升級版本解決
2.4.5 起呼過程中伴隨切換，ACCEPT消息丟失導致的QCI=1釋放；【問題描述】
終端在起呼過程中伴隨切換，終端透傳給核心網的ACT消息超時沒有被核心網接收到導致的釋放；
【問題分析】
21:01:23，主叫UE發起尋呼，被叫UE收到後發起ERAB承載，建立完成；21:01:26，被叫UE收到RRC重配置消息中要求去激活QCI1的承載，隨後被叫UE上報INVITE580（precondition failure），導致本次未接通。
【解決方案】
DT消息沒有等到（丟了），核心網有沒有保護機制，需核心網解決；
2.5 終端異常2.5.1 終端異常主動掛機導致未接通事件【問題現象】
被叫向主叫發180振鈴消息，主叫端也成功收到被叫180振鈴消息，但在被叫發出180消息後，緊接著3秒後向主叫發406用戶忙消息（見下圖），核心網收到後給主叫放音，然後釋放，相同的現象，兩次呼叫未接通。
從信令上看，被叫發486用戶忙消息，是終端主動拒絕的原因，和網絡無關。至於被叫為什麼在振鈴3秒後發用戶忙和拒絕消息，終端問題，需要終端解決。
2.5.2 終端不上報TAU請求【問題現象】
主叫正常呼叫後從PCI=17,TAU=29580小區切換到PCI=64，TAU=29482小區後不主動發起TAU請求後RRC釋放,重新接入到其它小區,3次重複這樣過程後，終端主動發BYE，被叫終端TAU正常。由於對於不同TAU切換後手機終端需要上報TAU請求，此處終端始終未發起TAU，為終端原因
2.6 測試軟體統計2.6.1 異常統計掉話【問題現象】
被叫在2G下人工釋放，上報DISCONNECT，掛機流程結束，此時主叫在4G下收到IMS下發BYE，並去激活了QCI=1承載，並標記為normal call clearing，但仍會統計為dropped ，此時主叫繼續正常釋放流程，為軟體統計問題。
2.7 eSRVCC切換問題分析2.7.1 GSM鄰區參數錯誤導致掉話【問題現象】
手機在LTE覆蓋弱場，收到B2測量的重配消息後，手機發起Measurementreport（B2事件）後收到網絡下發的RRC Connection Release，重定向到2G後掉話。
【問題分析】
當UE上報A2測量報告後，eNB下發B2重配消息給UE，根據B2重配消息，UE測量滿足B2-1和B2-2條件並上報B2事件，上報的B2事件包含準備切換的目標2G小區BCCH/NCC/BCC，見下圖：
1. 正常情況下，eNB收到該B2事件測量報告後下發mobilityFromEUTRACommand消息給UE，切換到該GSM鄰區；
2. 異常情況下網絡下發RRC Connection Release消息使UE重定向到BCCH為512的GSM小區，如下圖：
隨後主叫重定向到GSM網絡，在2G網絡手機狀態是空閒態，統計為掉話，如下圖：
通過以上現象分析可知UEVoLTE業務eSRVCCC切換到BCCH 525(BSIC 12)的G網鄰區失敗，核查網管中該G網鄰區參數配置，發現該鄰區BSIC配置為7，與實際UE測量的BSIC 12不一致，修改網管中該G網鄰區BSIC為12後，可正常切換到該小區，掉話解決
【解決方案】：
同步LTE-->GSM網絡鄰區定義和實際GSM網絡規劃數據，如上案例，LTE-->GSM鄰區定義中BSCI配置為7，而實際UE測量的BSIC為12，將LTE定義GSM鄰區中BSIC改為12後，正常eSRVCC。
2.7.2 切換準備失敗【問題現象】
UE空口表現為發起多次B2測量後無法進行eSRVCC，最終易導致重建立和掉話事件發生；
eNB側表現為接收到手機上報B2測量並發起切換請求，但是收到來自核心網的切換準備失敗消息；
【問題分析】
正常情況下，eNB收到該B2事件測量報告後下發mobilityFromEUTRACommand消息給UE，UE會收到mobilityFromEUTRACommand並實施切換；
異常情況下，UE發起多個B2事件而未收到mobilityFromEUTRACommand，此時可能涉及空口無線環境惡化導致B2事件測量報告未上報給eNB，需要結合eNB側信令分析。如下圖：
當eNB收到B2測報後向MME發送handoverrequire消息（為eSRVCC切換準備資源），但隨後收到了切換準備失敗的回覆。見下圖：
導致此類失敗的原因通常是核心網沒有對目標小區配置eSRVCC相關功能參數的原因，需要核心網檢查目標網絡小區相關參數是否生效或正確配置。
【解決方案】：
導致此類失敗的原因通常是核心網未配置SRVCC功能、未配置目標MSC、未配置TAU等原因，需要同核心網及目標網絡核查相關配置是否生效。
2.7.3 GSM鄰區頻點配置不全【問題現象】
UE上報A2事件後，網絡下發B2重配消息並成功上報網絡後，手機RSRP滿足B2-1判決門限卻始終未上報B2事件測量報告，最終容易導致重定向、掉話事件發生
【問題分析】
實際網絡中會存在由於無線環境的改變、G網參數優化後同步不及時或RF優化等原因，導致LTE小區的GSM鄰區頻點配置不夠準確，對於A2重配裡下發的GSM頻點在終端測量後，不滿足B2-2事件，導致無法觸發eSRVCC。如下圖：
其他可能原因：需要檢查系統間鄰區是否已經設置為「支持切換」，如下圖
【解決方案】：
完善和及時更新LTE鄰區定義中的GSM鄰區關係和參數定義；
對於問題點，建議進行GSM網絡掃頻或者結合GSM測試數據分析，檢查這些頻點是否已包含在後臺配置中
2.7.4 手機原因導致無法SRVCC切換【問題現象】
主被叫手機在相同小區，主叫手機上報A2後重配消息包含B2門限和異系統頻點信息，而被叫手機上報A2後重配消息未包含異系統配置信息，進而導致被叫沒有進行SRVCC，主叫正常SRVCC。如下圖
【問題分析】
由於一個小區下兩種不同行為，首先需要排查手機上報能力，從UE附著請求消息或TAU(TrackingArea Updates)消息中發現被叫手機上報的UE能力不包含SRVCC能力消息，並描述不支持GSM頻帶。主叫包含，因此重點排查手機哪方面出現了異常，由於前期測試無此問題，懷疑測試期間手機誤設置為鎖定LTE導致，因此將手機設定為鎖定LTE和支持2、3、4G模式對比驗證。
下圖是未鎖定LTE情況下TrackingArea Updates信令描述，包含手機支持SRVCC能力指示
下圖是被叫鎖定LTE網絡後，TrackingArea Updates信令，標示手機不支持E-GSMor R-GSM。沒有支持SRVCC標示。
【解決方案】：
此類問題需要檢查手機設置和實際支持能力，確保上報支持能力。
2.8 其他2.8.1 參數配置問題導致異常返回GSM【問題現象】
主叫手機佔用462502基站發起INVITErequest和servicerequest後手機進入GSM網絡發起後續接入流程。
【問題分析】
如下圖所示，主被叫佔用相同小區，無線環境良好，主叫無法駐留在LTE進行呼叫，被叫正常，佔用其他基站無此問題，手機調換後對比測試問題依舊存在主叫流程異常，和手機關係不大。
查看系統消息sib2發現存在如下異常，導致主叫無法正常呼叫，見下圖、
後臺排查參數發現該站設置如下：
參數名稱
參數描述
取值定義
現網取值
建議設置
參數說明
acBarringFactor
信令接入概率因子
0:0,1:0.05,2:0.1,3:0.15,4:0.2,5:0.25,6:0.3,7:0.4,8:0.5,9:0.6,10:0.7,11:0.75,12:0.8,13:0.85,14:0.9,15:0.95,16:1
10
16
該參數是UE發起主叫信令而建立RRC連接時，UE能夠接入小區的概率的參考值。如果UE投擲的隨機數小於該參數，則允許接入；否則，禁止接入。
acBarringTime
信令禁止接入時間(秒)
0:4,1:8,2:16,3:32,4:64,5:128,6:256,7:512
1
0
該參數表示發起信令接入時的平均禁止接入時間
acBarringFactorOrig
呼叫接入概率因子
0:0,1:0.05,2:0.1,3:0.15,4:0.2,5:0.25,6:0.3,7:0.4,8:0.5,9:0.6,10:0.7,11:0.75,12:0.8,13:0.85,14:0.9,15:0.95,16:1
10
16
該參數是UE發起呼叫而建立RRC連接時，UE能夠接入小區的概率的參考值。如果UE投擲的隨機數小於該參數，則允許接入；否則，禁止接入。
acBarringTimeOrig
呼叫禁止接入時間(秒)
0:4,1:8,2:16,3:32,4:64,5:128,6:256,7:512
1
0
該參數表示發起呼叫接入時的平均禁止接入時間
【驗證結果】
修改後該站VOLTE呼叫正常。如下圖
3 總結通過2015年後對長沙現網年後2多月網絡KPI指標提升攻關，獲得一些寶貴經驗，同時，也對目前VoLTE技術在應用中，存在網元間協調交互，終端處理，KPI指標定義等存在問題提供一些思考，需要運營商帶動產業鏈一起來解決。
3.1 VOLTE網絡指標提升策略根據長沙VOLTE網絡問題分析,重新根據網優、基站、核心網、終端以及重定向分類，未接通部分分布如下
未接通原因分布
掉話原因分布如下：
掉話原因分布
可見，未接通原因主要集中在於核心網和網優，掉話原因主要是網優和重定向。
根據上述情況，整理出VOLTE網絡提升策略如下：
1、基站版本統一和關閉異頻重定向功能：基站TM3/8的問題和異頻重定向都會導致UE掉話，因此需要後臺維護人員定期核查全網站點版本以及重定向開關是否關閉，尤其對於新開站點和斷鏈恢復站點要重點核查。
2、鄰區合理優化，避免漏配鄰區導致UE無法切換最終脫網或者重定向到異系統。需要關注室分站點室外洩露、越區站點覆蓋、針狀覆蓋等。
3、幹擾優化，注意切換區重疊覆蓋，PCI模3影響等。
4、弱覆蓋區域esrvcc開啟：部分路段由於工程原因，短期無法加站，需要通過esrvcc及時切換到異系統，減少掉話。但最終該類問題解決還需要推動運營商加站解決覆蓋。
5、終端在某次異常後可能會出現連續異常事件，需要注意路測呼叫遇到此種情況時，可以通過重啟終端或者飛行模式解決。
6、4G網絡中被叫TAU時不響應尋呼，對於中興核心網需要升級版本，對於其他廠商，需要確認是否支持相關功能。
7、對於終端異常問題需要運營商協調推動終端解決
註：問題1~5可以參考《TD-LTE VoLTE網絡優化指導R2.0》
3.2 VoLTE技術演進和完善3.2.1 網元間協同VoLTE作為一個新的技術，我們規模驗證過程也遇到一些問題，而這些問題對網絡用戶感知帶來一定影響，而協議流程沒有明確定義需要運營商和設備商一起來推動解決：
1，終端從2/3G系統返回4G系統時，無法尋呼的問題：原因在於被叫在2/3G時，網絡已經做完域選擇，把呼叫直接轉到MGCF和CS互通，尋呼消息也是在CS。而此時被叫已經回到4G，沒有收到時正常的。同時網絡也不會再次將呼叫重新選擇到4G來尋呼，從2/3G呼叫回到4G是沒有規範支撐的。（參見案例說明）
2，UE在進行專用承載激活的時候，同時發生切換，由於NAS層的activate dedicated EPS bearercontext accept消息未發送到核心網，導致呼叫失敗的問題。該問題在多個廠家均出現過，需要核心網增加此種情況下暫態容錯處理。（參見案例說明）
3，SIP信令傳輸協議採用TCP和UDP差異，導致2返4G呼叫接通率受到影響。也是未來運營商牽頭需要界定的。
4，NAS層，RRC層和SIP信令的協調，保證事件控制串行化。例如：主叫發起釋放流程，網絡要求各網元釋放命令，由於NAS層，RRC層和SIP信令在時序上不完全匹配，會有可能導致在被叫終端收到NAS層和RRC層釋放承載，此時，SIP釋放命令還未到達被叫，導致被叫終端SIP上下文有可能被掛起，為完成釋放。
3.2.2 網絡跟蹤區域規劃跟蹤區規劃在VoLTE部署也是一個不容忽視問題，需要和CSFB的TAC規劃策略協調，儘量避免過於頻繁TAU更新，影響尋呼成功率和呼叫接通率。
eSRVCC後，終端呼叫完成後返回4G是必須要走一遍TAU更新流程是否有必要？同樣影響尋呼尋呼成功率以及呼叫接通率，很顯然空口信令開銷也是有影響。
3.2.3 KPI指標定義規則目前我們拉網的VoLTE的KPI指標評估，完全依賴路測軟體統計給出，後續對網絡質量KPI評估，後續從核心網，基站以及終端，需要在指標評估體系上需要進一步完善。
3.3 後續思考從海外VoLTE商用和試驗網經驗來看，VoLTE網絡完全可以提供更高的頻譜利用率、更好的話音體驗以及更豐富的業務體驗，從而應對來自OTT的競爭與挑戰，使語音業務在LTE時代繼續成為運營商重要的現金流來源。
LTE語音是通過AMR被編碼成TTI20ms的VoIP數據，考慮到有效負荷以及各協議層的開銷，VoIP空口傳輸的實際速率要求較低，而語音業務對時延較為敏感，因此，TD-LTE VoLTE語音質量保證以及對數據業務影響體現下面幾個方面：
1） VoLTE對於LTE網絡覆蓋和SINR有極高的要求，經測試和數據業務相比收縮3dB左右。網絡規劃和網優優化是語音引入需要加強一個重要工作。
2） VoLTE對單小區RRC連接用戶數和激活用戶比例差距會縮小，小區內激活用戶比例大大增加，需要對網絡語音和數據的負荷比例進行調控。
3） 語音業務接入和調度優先級，影響數據業務業務感知體驗和容量受限。擴容需求會有所增加。3:1配比下，如：接入100語音用戶下，數據業務平均帶寬：
平均數據吞吐量（Mbps）
下行
上行
AMR-NB 12.2kbps/AMR-WB 12.65kbps
22
1.9
AMR-WB 23.85kbps
21
1.5
一些特殊場景，例如高鐵究，和CA結合；一些特殊場景下，例如：宏+微場景網絡部署技術研究都有待於我們在VoLTE技術逐步推進摸索和探索。以高鐵為例：
地鐵場景下，目前還沒有完整實測數據，以如下三種典型語音視頻業務為分析模型：
典型速率
小區邊緣折算到RB/MCS
BLER要求（首傳）
語音
12.2kbps
下行RB=14/MCS=0、上行RB=15/MCS=0
10%
高清語音
23.85kbps
下行RB=22/MCS=0、上行RB=18/MCS=1
10%
視頻
400kbps
下行RB=92/MCS=11
1%
圖1 AWGN模型vsHST350kmh模型PDSCH信道解調性能
根據鏈路級仿真的結果，HST350km/h信道情況下高速用戶與靜止態用戶性能接近。
綜上，高鐵場景下，實測和仿真數據表明，在高鐵小區採用頻偏補償算法後，對小區邊緣上下行速率影響很小。因此可以認為，高鐵場景在規劃時，對於RS-SINR的要求同樣要提升3dB。
VOLTE入網會讓RRC激活和RRC在線用戶比例縮小。也就是調度頻次增加。地鐵場景下，用戶群移動對於空閒態影響，TAU，重選影響看，在系統內應該和正常PS業務相當。VOLTE連接態用戶，地鐵場景覆蓋好，可以不引人VOLTE eSRVCC。如果需要補盲，eSRVCC功能在2G到4G返回帶來一部分TAU跟新負荷。
地鐵場景下，不可避免存在系統內的群移動切換效應，而語音用戶感知更為敏感。因此，對於切換需要保證無線環境質量，用戶快速切換到覆蓋量小區。同時，對於設備並發切換能力，滿足短時間突發切換需求。
因此，我們從2015年對網絡進行全面KPI指標提升，是VoLTE真正走向成熟化道路一個契機，後面還需要我們不斷積累經驗，不斷改進和優化。