语音质量提升专题_RRC重建汇编.docxVIP

语音质量提升专题_RRC重建一、概述VoLTE呼叫中RRC重建和数据业务触发机制以及对RRC层影响完全相同，在LTE常规优化和投诉处理中因为影响较小而经常被忽视。但RTCP协议对底层链路失败引起的re-cover机制支持不好，所以RRC重建过程很容易被用户感知到；另外RRC重建更有可能造成VoLTE掉话和接入失败。所以VoLTE优化和商用保障过程中，需要仔细梳理现网存在RRC重建的原因，并有针对性的采取优化措施。对于数据业务使用来说，短时间的业务中断很难被用户觉察到。因此在业务进行过程中发生的RRC异常释放和切换失败，只要后续RRC重建成功，甚至即使重建不成功，网络侧或者UE侧很快又发起连接建立并成功建立连接，对用户体验基本不会带来影响更不太会引起投诉，RRC异常释放后如果重建成功甚至不会影响KPI指标。但对于实时的会话业务来说，RRC重建明显影响用户感知并引起投诉：RRC重建前后短时的业务中断会被用户立即感受到，表现为听不清、通话吞字、一段时间听不到声音、视频停滞等，LTE中的无线链路失败（RLF）并不会直接导致VoLTE话音呼叫的掉话，但是在有些情况下还是会在RLF之后出现VoLTE掉话。比如重建时如果不能建立UM承载则会掉话，或者重建后应用层不能恢复RTP包也会造成RTP timeout。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包引起的。二、RRC重建原因分析当处于RRC连接状态时，如果出现切换失败、无线链路失败、完整性保护失败、RRC重配置失败等情况，将会触发RRC连接重建过程。RRC重建原因主要包括基础网络问题，规划配置类问题；基础网络问题包括弱覆盖、越区覆盖、邻区漏配和干扰引起的质量问题；规划配置类问题，包括PCI冲突以及相邻基站RLC SNSIZE不一致造成的切换失败；以及重载场景SRI和GAP冲突造成的重建。RRC重建过程旨在重建RRC连接，包括SRB1操作的恢复，以及安全的重新激活。处于RRC_CONNECTED状态的UE，安全已被激活，可发起该过程继续RRC连接。仅当相关小区是具有UE上下文的小区时，连接重建才会成功。假使E-UTRAN认可重建，SRB1的操作会恢复，而其它RB将继续保持挂起。如果AS安全没有被激活，UE不会发起该过程，而直接转到RRC_IDLE状态。总体信令流程图如下：三、RRC重建被拒原因（描述RRC重建成功和被拒理论原因）失步、完整性校验失败、达到最大重传次数等都会导致无线资源的重建。重建要成功，首先要确定重选的小区是否存有已经挂起的无线承载资源信息。如果是切换失败导致的重建，且重建场景发生在target cell，则重建是否会被eNB接受需要看target cell中是否有该UE的上下文（即如果是inter-ENB切换，是否有X2口用来传递UE的上下文），如果target cell没有该UE context，重建会被eNB拒绝，然后UE需要再发起TAU Request流程。RRC重建被拒主要有等待RRC连接重建立完成定时器超时、eNB接纳失败、UE上下文找不到、再次重建立、其他原因等，short MAC-I较验失败也会被拒绝；四、RRC重建处理思路（处理流程图）针对RRC重建失败，首先需要检查基站、传输等状态是否异常，排查基站、传输等问题后再进行分析。整个切换过程异常情况我们分为几个阶段：测量报告发送后是否收到切换命令，收到重配命令后是否成功在目标测发送MSG1成功发送MSG1之后是否正常收到MSG2在某一环节出现问题我们可查询相应处理流程进行排查。由于终端未收到切换命令，可能有两种情况：1、基站未收到测量报告（可通过后台信令跟踪检查）：检查覆盖点是否合理，主要是检查测量报告点的RSRP,SINR等覆盖情况，确认终端是否在小区边缘，或存在上行功率