RRC重建对VoLTE性能影响分析.doc

RRC重建对VoLTE性能影响分析【摘要】VoLTE呼叫中RRC重建和数据业务触发机制以及对RRC层影响完全相同，在LTE常规优化和投诉处理中因为影响较小而经常被忽视。但如本文分析的，RTCP协议对底层链路失败引起的re-cover机制支持不好，所以RRC重建过程很容易被用户感知到；另外RRC重建更有可能造成VoLTE掉话和接入失败。所以VoLTE优化和商用保障过程中，需要仔细梳理现网存在RRC重建的原因，并有针对性的采取优化措施。【关键字】VoLTE, RRC Reestablishment, reconfigurationFailure,RTP re-cover, MOD3 interference, RLC SN SIZE1. 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包恢复时间都在35秒之内，但实际上用户感受到的语音中断期（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_STAMPLTE KPI Serving PCI Port 1LTE KPI Serving RSRPdBm LTE KPI SINRdB LTE KPI PUSCH PowerdBm LTE KPI PDSCH BLER% LTE KPI PUSCH BLER% Cause2015-09-22 13:28:07.000135-104519025uplink2015-09-22 12:42:04.000300-109-12310090uplink2015-09-22 12:58:45.00085-91-1.51604.5uplink2015-09-22 12:59:05.000140-1012211430uplink2015-09-22 13:10:23.000264-120-1232251downlink2015-09-22 13:10:29.000103-119-6237582downlink2015-09-22 13:28:10.000135-10372209uplink2015-09-22 16:05:04.000116-1042.3322.673.675uplink2015-09-22 16:07:51.000318-114-10236680uplink2.1.1模3干扰引起下行质差RRC重建：Cell NameNELocal Cell IDeNodeB IDPhysical cell IDMOD3 94034B1194034110050263253244C1153244212109116294810A119481001005515822.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 expiryl Random access failurel 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而触发重建，概率性出现重建失败导致掉话。2.2.2 参数配置引起的RRC重建：该类问题很容易发生在VoLTE开通初期，由于参数频繁修改很容易造成相邻基站VoLTE参数不一致。场景一Pdcp/RLC SnSize参数由7/5优化为12/10，由于参数优化只在部分站点实施，势必存在终端在源站和目标站点Pdcp/RLC SnSize参数不一致进行切换的场景，协议定义在上述场景下，PDCP SN SIZE不能修改，而RLC SN SIZE可以修改，我司按照协议实现，在该场景下会修改RLC SN SIZE为目标小区配置，但是在切换失败重建到目标eNodeB场景，由于终端在重建时进行了参数回退，而eNodeB并没有重新配置RLC SN SIZE，导致终端使用源小区RLC SN SIZE，eNodeB使用目标小区RLC SN SIZE。下图所示，eNodeB在解PDCP SN时和终端没有对齐，解出的是语音包IP头的第一个字节。 因为语音包IP头的第一个字节通常为固定值，所以eNodeB会解出连续几个包的SN号相同，按目前PDCP丢包机制，连续包的SN号相同，eNodeB会误统计为丢了（SN最大值1）个包，这样导致话统误统了大量丢包，实际丢包数要远小于话统丢包数。场景二由于三星终端已知问题，如果切换消息中目标小区RLC SN SIZE不一致，会触发终端重建请求原因值为reconfigurationFailure。切换重配消息中目标小区RLC SN SIZE与原小区不一致UE申请RRC重建，原因值为reconfigurationFailure2.3 重载场景下SRI和GAP冲突造成的RRC重建 小区重载场景下当部分用户SRI周期扩张到40ms后，当UE需要做异频、异系统测量而配置GAP时，GAP测量周期会概率性的和SRI冲突。上图中sr-ConfigIndex为51，通过下表可以查到SR的周期为40ms（与GAP周期一致），并且SR的子帧为51-35=16GAP测量起始子帧为11，因此SRI和GAP完全冲突，从而造成UE在收到GAP测量的RRC重配消息后完全不能发送RRC完成消息. eNodeB侧看到的情况是含GAP测量的RRC重配消息发送后，一直没有收到完成消息。最终eNodeB释放空口UE侧则是连续发送多个Measurement消息后UE申请RRC重建，上层的RTP因为超时也