1. RRC重建对VoLTE影响
对于数据业务使用来说,短时间的业务中断很难被用户觉察到。因此在业务进行过程中发生的RRC异常释放和切换失败,只要后续RRC重建成功,甚至即使重建不成功,网络侧或者UE侧很快又发起连接建立并成功建立连接,对用户体验基本不会带来影响更不太会引起投诉,RRC异常释放后如果重建成功甚至不会影响KPI指标。
但对于实时的会话业务来说,RRC重建明显影响用户感知并引起投诉:
1. RRC重建前后短时的业务中断会被用户立即感受到,表现为听不清、通话吞字、一段时间听不到声音、视频停滞等,
2. LTE中的无线链路失败(RLF)并不会直接导致VoLTE话音呼叫的掉话,但是在有些情况下还是会在RLF之后出现VoLTE掉话。比如重建时如果不能建立UM承载则会掉话,或者重建后应用层不能恢复RTP包也会造成RTP timeout。
3. VoLTE呼叫建立阶段发生RRC重建,可能引起和PRACK的冲突,IMS CORE定时器超时,IMS向主叫终端发480 TEMPORARILY UNAVAILABLE错误码
RRC重建对语音质量影响
以下公式为无线链路失败引起RRC重建场景下,RTP包恢复时间T的计算公式:
t是RLC完成一个RTP包的传输间隔,取值为100ms。N为RRC重建尝试次数。
对于多数运营商来说,底层RTP包恢复时间都在3~5秒之内,但实际上用户感受到的语音中断期(audio muting)要远远大于这个时间。主要原因就是RTP/RTCP协议最初是基于IETF开发的,并未充分考虑在链路质量不稳定的无线网络承载,对于底层链路失败引起的re-cover机制支持不好。下图显示在RRC层已经恢复后,RTP层乃至应用层数据并不会马上恢复。
VoLTE测试中也经常能够发现,RRC重建前后MOS的两个采样点都非常低,而前一个采样点主要是受到重建前空口RTP丢包的影响,重建后的低MOS采样点则可能是上层协议不能正常生成RTP包引起的。
2. RRC重建根因分析
下图为某商用FDD网络,路测中发现的RRC重建原因归类。其中超过64%的属于基础网络问题,包括弱覆盖和邻区干扰引起的质量问题;约27%属于规划配置类问题,包括PCI冲突以及相邻基站RLC SNSIZE不一致造成的切换失败;约9%属于6.0下已知的重载场景SRI和GAP冲突造成的重建。
2.1 无线原因引起的RRC重建
2.1.1 弱覆盖场景下的重建
无线原因造成的RRC重建与数据业务重建触发原因相同,但常规优化中因为KPI影响较小且很少产生用户投诉而常常被忽略。
根据VoLTE链路预算和实测结果,下行RSRP在-110dBm以内时,可以认为RSRP对MOS的影响不大,但上行覆盖受限的场景可能仍然造成RRC重建。
下表是列举了无线原因RRC重建前空口上下行主要指标,可以看到除了RSRP接近-120dBm的弱覆盖场景外,部分重建发生在下行覆盖尚好,伴随着上行BLER迅速抬升,上行功率已经到达峰值。
对于覆盖尤其是室内深度覆盖不佳的网络,数据业务用户体验受到的影响程度可能不大,但语音业务即使有TTIB、上行COMP等特性仍然会频繁出现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 规划配置类引起的RRC重建
2.2.1 PCI冲突导致重建
VoLTE测试中RRC重建多次复现,最终锁定在PCI13为问题小区。这是因为采用商用终端复现,在问题点来回移动测试,发现72往13可以切成功,其它小区往72切也可以成功,
只有13往72每次都是重建不是切换,重建前也没有同频切换A3的测量报告,只有CoMP A3的测量报告。UE触发重建的原因为RLF。问题有一个比较奇怪的现象是,UE在发起一次重建后,仅相隔200ms左右又发起第二次重建。
按照协议规定,触发RLF有3个原因:
l T310 timer expiry
l Random access failure
l UL RLC retransmit reached the maximum retransmit threshold
但是我们分析了UE log,重建前以上三个条件都不满足。
因此我们最初怀疑是终端问题,为了验证,我们采用TUE进行复测,结果是TUE可以从PCI13小区往PCI72正常切换。因此我们寻求IOT同事找终端共同分析。
但还有一个疑点是,为什么每次都是在PCI13小区出问题,其它小区没有问题。在又一次复现的重建失败,分析后发现该覆盖区域存在两个PCI为13的小区。
重建失败的流程:用户从199246_16(PCI249)切入198860_2(PCI13),RLF重建到198861_1(PCI13)被拒绝掉话,之后重新接入198861_1(PCI13)之后又RLF重建到198661_0(PCI 116)成功。
在客户修改冲突的PCI后,问题解决。对于为什么UE会发起重建并没有确切的结论(未得到高通的反馈),根据之前客户提供的问题描述胶片的一些信息,推测是UE做了某种异常检测机制会触发重建。由于该覆盖区域存在两个PCI13的小区,导致强干扰,造成UE检测异常,RLF而触发重建,概率性出现重建失败导致掉话。
[[i] 本帖最后由 ranhj 于 2016-12-8 09:45 编辑 [/i]]