1. RRC重建對VoLTE影響
對于數(shù)據(jù)業(yè)務使用來說，短時間的業(yè)務中斷很難被用戶覺察到。因此在業(yè)務進行過程中發(fā)生的RRC異常釋放和切換失敗，只要后續(xù)RRC重建成功，甚至即使重建不成功，網(wǎng)絡側或者UE側很快又發(fā)起連接建立并成功建立連接，對用戶體驗基本不會帶來影響更不太會引起投訴，RRC異常釋放后如果重建成功甚至不會影響KPI指標。
但對于實時的會話業(yè)務來說，RRC重建明顯影響用戶感知并引起投訴：
1. RRC重建前后短時的業(yè)務中斷會被用戶立即感受到，表現(xiàn)為聽不清、通話吞字、一段時間聽不到聲音、視頻停滯等，
2. LTE中的無線鏈路失敗（RLF）并不會直接導致VoLTE話音呼叫的掉話，但是在有些情況下還是會在RLF之后出現(xiàn)VoLTE掉話。比如重建時如果不能建立UM承載則會掉話，或者重建后應用層不能恢復RTP包也會造成RTP timeout。
3. VoLTE呼叫建立階段發(fā)生RRC重建，可能引起和PRACK的沖突，IMS CORE定時器超時，IMS向主叫終端發(fā)480 TEMPORARILY UNAVAILABLE錯誤碼
RRC重建對語音質量影響
以下公式為無線鏈路失敗引起RRC重建場景下，RTP包恢復時間T的計算公式：
t是RLC完成一個RTP包的傳輸間隔，取值為100ms。N為RRC重建嘗試次數(shù)。
對于多數(shù)運營商來說，底層RTP包恢復時間都在3~5秒之內，但實際上用戶感受到的語音中斷期（audio muting）要遠遠大于這個時間。主要原因就是RTP/RTCP協(xié)議最初是基于IETF開發(fā)的，并未充分考慮在鏈路質量不穩(wěn)定的無線網(wǎng)絡承載，對于底層鏈路失敗引起的re-cover機制支持不好。下圖顯示在RRC層已經(jīng)恢復后，RTP層乃至應用層數(shù)據(jù)并不會馬上恢復。
VoLTE測試中也經(jīng)常能夠發(fā)現(xiàn)，RRC重建前后MOS的兩個采樣點都非常低，而前一個采樣點主要是受到重建前空口RTP丟包的影響，重建后的低MOS采樣點則可能是上層協(xié)議不能正常生成RTP包引起的。
2. RRC重建根因分析
下圖為某商用FDD網(wǎng)絡，路測中發(fā)現(xiàn)的RRC重建原因歸類。其中超過64%的屬于基礎網(wǎng)絡問題，包括弱覆蓋和鄰區(qū)干擾引起的質量問題；約27%屬于規(guī)劃配置類問題，包括PCI沖突以及相鄰基站RLC SNSIZE不一致造成的切換失��；約9%屬于6.0下已知的重載場景SRI和GAP沖突造成的重建。
2.1 無線原因引起的RRC重建
2.1.1 弱覆蓋場景下的重建
無線原因造成的RRC重建與數(shù)據(jù)業(yè)務重建觸發(fā)原因相同，但常規(guī)優(yōu)化中因為KPI影響較小且很少產生用戶投訴而常常被忽略。
根據(jù)VoLTE鏈路預算和實測結果，下行RSRP在-110dBm以內時，可以認為RSRP對MOS的影響不大，但上行覆蓋受限的場景可能仍然造成RRC重建。
下表是列舉了無線原因RRC重建前空口上下行主要指標，可以看到除了RSRP接近-120dBm的弱覆蓋場景外，部分重建發(fā)生在下行覆蓋尚好，伴隨著上行BLER迅速抬升，上行功率已經(jīng)到達峰值。
對于覆蓋尤其是室內深度覆蓋不佳的網(wǎng)絡，數(shù)據(jù)業(yè)務用戶體驗受到的影響程度可能不大，但語音業(yè)務即使有TTIB、上行COMP等特性仍然會頻繁出現(xiàn)RRC重建，用戶不良感知明顯。
TIME_STAMP | LTE KPI Serving PCI Port 1 | LTE KPI Serving RSRP[dBm] | LTE KPI SINR[dB] | LTE KPI PUSCH Power[dBm] | LTE KPI PDSCH BLER[%] | LTE KPI PUSCH BLER[%] | Cause |
2015-09-22 12:42:04.000 | 300 | -109 | -1 | 23 | 100 | 90 | uplink |
2015-09-22 12:58:45.000 | 85 | -91 | -1.5 | 16 | 0 | 4.5 | uplink |
2015-09-22 12:59:05.000 | 140 | -101 | 2 | 21 | 14 | 30 | uplink |
2015-09-22 13:10:23.000 | 264 | -120 | -1 | 23 | 22 | 51 | downlink |
2015-09-22 13:10:29.000 | 103 | -119 | -6 | 23 | 75 | 82 | downlink |
2015-09-22 13:28:10.000 | 135 | -103 | 7 | 22 | 0 | 9 | uplink |
2015-09-22 16:05:04.000 | 116 | -104 | 2.33 | 22.67 | 3.67 | 5 | uplink |
2015-09-22 16:07:51.000 | 318 | -114 | -10 | 23 | 66 | 80 | uplink |
2.1.1模3干擾引起下行質差RRC重建：
Cell Name | NE | Local Cell ID | eNodeB ID | Physical cell ID | MOD3 |
94034B11 | 94034 | 1 | 10050 | 263 | 2 |
53244C11 | 53244 | 2 | 12109 | 116 | 2 |
94810A11 | 94810 | 0 | 10055 | 158 | 2 |
2.2 規(guī)劃配置類引起的RRC重建
2.2.1 PCI沖突導致重建
VoLTE測試中RRC重建多次復現(xiàn)，最終鎖定在PCI13為問題小區(qū)。這是因為采用商用終端復現(xiàn)，在問題點來回移動測試，發(fā)現(xiàn)72往13可以切成功，其它小區(qū)往72切也可以成功，
只有13往72每次都是重建不是切換，重建前也沒有同頻切換A3的測量報告，只有CoMP A3的測量報告。UE觸發(fā)重建的原因為RLF。問題有一個比較奇怪的現(xiàn)象是，UE在發(fā)起一次重建后，僅相隔200ms左右又發(fā)起第二次重建。
按照協(xié)議規(guī)定，觸發(fā)RLF有3個原因：
l T310 timer expiry
l Random access failure
l UL RLC retransmit reached the maximum retransmit threshold
但是我們分析了UE log，重建前以上三個條件都不滿足。
因此我們最初懷疑是終端問題，為了驗證，我們采用TUE進行復測，結果是TUE可以從PCI13小區(qū)往PCI72正常切換。因此我們尋求IOT同事找終端共同分析。
但還有一個疑點是，為什么每次都是在PCI13小區(qū)出問題，其它小區(qū)沒有問題。在又一次復現(xiàn)的重建失敗，分析后發(fā)現(xiàn)該覆蓋區(qū)域存在兩個PCI為13的小區(qū)。
重建失敗的流程：用戶從199246_16（PCI249）切入198860_2（PCI13），RLF重建到198861_1（PCI13）被拒絕掉話，之后重新接入198861_1（PCI13）之后又RLF重建到198661_0（PCI 116）成功。
在客戶修改沖突的PCI后，問題解決。對于為什么UE會發(fā)起重建并沒有確切的結論（未得到高通的反饋），根據(jù)之前客戶提供的問題描述膠片的一些信息，推測是UE做了某種異常檢測機制會觸發(fā)重建。由于該覆蓋區(qū)域存在兩個PCI13的小區(qū)，導致強干擾，造成UE檢測異常，RLF而觸發(fā)重建，概率性出現(xiàn)重建失敗導致掉話。
[[i] 本帖最后由 ranhj 于 2016-12-8 09:45 編輯 [/i]]
關注樓主