CS域问题定位分析

1、CS域问题定位分析Table of Contents 目 录1CS语音接通率问题定位分析31.1概述31.2RRC接入失败原因分析及优化措施31.2.1资源拥塞导致RRC reject接入失败31.2.2RL SETUP FAIL导致RRC接入失败31.2.3RRC.FailConnEstab.NoReply(无响应）导致RRC 接入失败31.2.4室内小区接入问题定位32CS掉话率问题定位分析32.1概述32.2CS掉话原因分析及优化措施32.2.1SRB Reset导致的掉话32.2.2Rl Failure导致的掉话32.2.3TOP问题小区处理32.2.4TOP终端影响3List of

2、Figure 图目录图1 话统RRC建立失败原因统计（以深圳某天话统数据为例）3图2 Ue接入失败时UE侧LOG3图3 话统ca.carrier表统计数据3图4 话统数据RRC建立失败原因-拥塞统计3图5 RNC侧log13图6 RNC侧log23图7 话统数据RRC建立失败原因-RL SETUP FAIL统计3图8 起呼失败终端侧LOG3图9 调整上行干扰余量RRC建立成功率统计3图10 调整上行干扰余量CS掉话率和PS掉话率统计3图11 调整上行和下行干扰余量RRC建立成功率统计3图12 调整上行和下行干扰余量语音掉话率统计3图13 调整上行和下行干扰余量PS掉话率统计3图14 UE在第3

3、时隙接入时信令截图3图15 UE在第4时隙接入时信令截图3图16 修改后UE在第3时隙接入时信令截图3图17 RRU覆盖区域起呼正常截图3图18 CS掉话原因统计（以深圳某天数据为例）3图19 切换信令流程图3图20 切换后下发测量控制后掉话3图21 掉话前信令流程3图22 该小区的切换邻区统计3图23 切换时为收到物理信道重配完成掉话3图24 起呼后RL FAIL导致掉话3图25 RECCTT=250时 CS释放时间3图26 RECCTT=60时 CS释放时间3图27 20281小区掉话信息3图28 链路释放前的链路信息3图29 掉话前信令流程3图30 掉话前信令流程3图31 CS掉话流程3

4、图32 起呼电平统计3图33 9月1日PCHR CS掉话记录3图34 9月1日PCHR CS掉话统计指标输出3CS域问题定位分析关键词：CS域 接入 掉话 问题分析摘 要：本文主要是针对在日常网络优化过程中，总结了CS域方面的RRC接入失败，以及CS掉话方面的常见问题定位、分析思路，以及提出优化方法和解决方案。1 CS语音接通率问题定位分析1.1 概述本文主要针对CS域RRC接通率较低，重点从产品问题、TOP小区问题、无线环境及干扰问题等方面，结合话统中RRC接通率失败原因进行问题分析和指标提升；1) TOP小区主要是通过数据统计和分析，确认影响该指标的是部分点，还是整体面的问题，举例：统计分

5、析6、7、8月份全网CS域RRC建立失败的TOP 10小区失败次数占全网比例，基本持续在10以上，情况严重时达到40左右，确定TOP小区对指标提升影响较大，优化过程中需重点解决对指标影响较大的TOP小区。2) 产品问题通常指标提升过程中，产品新版本发布上网都可以对前期发现的产品问题进行修正，因此发现产品问题对于提升网络指标起到很重要的作用。结合现网情况，经过产品定位，确认在RRC建立失败原因的RL SETUP FAIL类中，返回原因值为配置不支持的主要是由于RNC和NODEB的产品问题导致，升级新版本可解决大部份该类问题。3) 无线环境问题无线环境方面主要是从覆盖和干扰两个方面来进行分析，主要

6、是通过PCHR中CS域RRC建立失败的数据按照无线环境信号RSCP，和ISCP进行统计，找出是否在弱覆盖、ISCP高即干扰较大的情况下出现接入失败，通过数据统计：a.在接入电平<-95时，RRC建立失败率最高，随着接入电平减弱，CS域RRC建立成功率降低，接入失败与弱覆盖强相关；b.全网接入主要集中在ISCP(-100,105)之间，失败率最高，ISCP干扰不是导致RRC建立失败的主要原因。1.2 RRC接入失败原因分析及优化措施图1 话统RRC建立失败原因统计（以深圳某天话统数据为例）1.2.1 资源拥塞导致RRC reject接入失败RRC连接拒绝原因为拥塞时，说明系统已经判断小区处

7、于拥塞状态，需要对该小区的性能统计指标进行分析，主要从下面两个方面来分析：1. 从话统数据统计中确认该小区是否还在其他的接入失败原因；目前的机制是一旦出现连续100次RRC建立失败，则认为小区进入拥塞状态，后续收到的RRC建立消息按照80的概率直接拒绝；出现拥塞主要是由于其他原因的次数较多，导致触发了系统内判断小区拥塞的机制，针对出现这类问题的小区，首先重点解决首先导致RRC建立失败的主要原因，再解决拥塞问题；2. 小区码资源受限；可根据话统的码资源利用情况等数据进行确认，是否因码资源不足导致拥塞，针对这类TOP小区，建议扩容，增加载波解决拥塞问题。【案例】从UE侧看，发现UE发起RRC CO

8、NNECT REQ消息后，网络侧直接返回RRC CONNECT REJECT消息，原因值为congestion（拥塞），如下图所示：图2 Ue接入失败时UE侧LOG查看话统数据cr.carrier表统计，确定该小区在UE接入时（测试机器时间略快于后台服务器），主载波的下行码道资源已被全部占用，码道资源不足导致接入失败。图3 话统ca.carrier表统计数据通过对全网拥塞小区扩容以及TOPN小区处理，因拥塞原因导致接入失败的比例呈明显下降趋势，到9月最后一周的数据统计，因该类原因导致的接入失败至占全网接入失败的0.64%。图4 话统数据RRC建立失败原因-拥塞统计1.2.2 RL SETUP

9、FAIL导致RRC接入失败主要是在RNC收到UE上报的RRC CONNECT REQ消息，向NodeB发送NBAP _RL_ SETUP_REQ，直接收到NodeB返回的NBAP_RL_SETUP_FAIL，或者没有收到NodeB响应消息，导致RRC接入失败，出现该类问题，需重点关注和分析IUB接口是否正常，重点检查传输链路是否正常，以及NODEB运行是否正常。【案例】从UU口跟踪的LOG，发现UE发起RRC CONNECT REQ消息后，网络侧直接返回RRC CONNECT REJECT消息，原因值为unspecified，如下图所示：图5 RNC侧log1查看IUB接口LOG，RL_SET

10、UP_FAIL，失败原因为：requested_configuration_not_supported图6 RNC侧log2出现该类失败原因小区在现网中不固定，而且失败次数较多，很难复现，对指标影响较大；经过定位，该问题属于产品问题，问题原因分析如下：当业务由于某种原因失败时，UE发起信令释放指示，RNC的异常处理存在问题，RNC RR只通知RNC NBM释放资源，没有通知NB释放资源。这样RNC和NB存在资源不一致的情况。NodeB会一直等待同步，不释放资源。如果有其它UE接入/重配/切换到该小区，如果RNC分配到到该资源上，就会因码道冲突而失败，接入/切换失败体现为NBAP_RL_SETU

11、P_FAIL，重配失败体现为NBAP_RL_RECFG_FAIL。由于上行同步存在误检可能性，NODEB仍有可能同步并发送RL restoration给RNC，此时RNC因为已经没有该UE资源，会发起NBAP Reset，清掉NB资源，之后就不会再有码道冲突问题。这就是现场问题出现后会以一定概率消失的原因。解决措施：升级RNC和NODEB版本，在现场未升级版本之前，只能通过去激活/激活小区来规避该问题。全网升级RNC和NODEB版本，RL SETUP FAIL导致的接入次数明显减少，平均失败次数在60次左右，占全网失败次数仅为0.27%。图7 话统数据RRC建立失败原因-RL SETUP FA

12、IL统计1.2.3 RRC.FailConnEstab.NoReply(无响应）导致RRC 接入失败RNC收不到RRC CONNECTION SETUP COMPLETE消息，是全网中最主要的问题原因，主要从如下几个流程来考虑：1. UE是否收到RRC CONNECTION SETUP消息；RRC CONNECTION SETUP消息是在FACH上发送给UE，可以通过：1) 在NodeB上关闭FACH赋形，FACH赋形如果不准确，会影响信道性能，关闭FACH赋形后，观察是否有所改善；2) 下行功率不足，PCCPCH RSCP较低，C/I差，导致UE没有收到SETUP消息；目前SCCPCH功率配

13、置的值一般是-3db，可以提高SCCPCH功率，满足信号覆盖不好的地方功率需求。可以通过检查同一UE下一次发送RRC_CONNECT_REQ间隔是否是T300设置值，如果是，说明UE没有收到RRC_ CONN _SETUP消息，属于下行链路问题，则可以通过上述的优化方法进行调整，如果不是，说明T300已经停止即UE收到了RRC_ CONN _SETUP消息，属于上行问题。2. UE是否发送RRC CONNECTION SETUP COMPLETE消息；UE收到RRC CONNECT STEUP消息，没有发送RRC CONNECTION SETUP COMPLETE消息，前期通过对室内TOP小区

14、排查时，发现UE在收到RRC CONNECTION消息，就没有发送RRC CONNECTION SETUP COMPLETE消息，如下下图所示：图8 起呼失败终端侧LOG后经过问题定位确认：干放的时隙配比和小区的不一致，导致在时隙3上产生强烈的干扰，BLER高达100，UE不能正常解码，导致UE不能正常消息流程。3. UE已发送RRC CONNECTION SETUP COMPLETE消息，RNC没有收到；可以通过调整闭环功控等参数来提高上行发射功率，提高接入成功率。针对问题1）和问题3），在电平和干扰情况都较理想的情况，均没有复现该问题，暂时只能通过参数调整的手段，进行优化，主要的增大上行/

15、下行干扰余量，增加上行/下行发射功率。针对接通率较差的小区，可适当将上行干扰余量提高至6，例如下图中，针对10T中RRC接通率较差的小区，8号修改上行干扰余量从3到6，修改后，CS域RRC接通率呈明显上升趋势，而CS和PS掉话率并没有明显恶化。图9 调整上行干扰余量RRC建立成功率统计图10 调整上行干扰余量CS掉话率和PS掉话率统计关内站点较为密集的城区，下行干扰余量不建议修改过大，会造成掉话率恶化。例如针对2T，1号修改下行干扰余量到180后，CS和PS掉话率呈明显上升趋势，5号和11号持续降低部分小区的下行干扰余量到90后，掉话率明显降低，已低于修改前，没有出现恶化；图11 调整上行和下

16、行干扰余量RRC建立成功率统计图12 调整上行和下行干扰余量语音掉话率统计图13 调整上行和下行干扰余量PS掉话率统计1.2.4 室内小区接入问题定位室内站点相对于室外站点，主要是增加了室分处理系统，在前期深圳项目中部分室内站点由于室分系统存在问题，导致接通率较低，重点针对室内小区进行拨测和处理，问题分析思路如下：1) 确认基站是否有告警，例如驻波比告警、传输告警、GPS告警等，若存在上述告警，建议先进行产品排障；2) 确认该小区的UPPCH ISCP值(UPPCH ISCP正常值为-100dBm-110dBm.)和载波时隙干扰测量值(上行的时隙干扰ISCP正常值为-100dBm-110dBm

17、.)，若出现ISPC值较大的情况，建议先排除干扰问题，重点检查是否由于室外站点信号覆盖到室内，造成干扰；3) 通过室分图纸，确认哪里区域是RRU直接覆盖，哪些区域是干放覆盖，分开进行CQT测试，确认问题区域或者楼层。若COT测试确认问题主要在干放覆盖区域，则问题定位重点应放在室分干放系统上，干放系统主要问题一般为：干放故障、干放时隙配置不一致、上下行链路不平衡等4) 若确认问题在RRU直接覆盖区域，在覆盖问题区域的该路PAHT下，直接连接小天线进行测试，确认问题是产品问题，还是室分连接系统问题1. 干放时隙配比与小区不一致问题在某室内站点的部分楼层CS/PS域测试，有时能正常呼叫，有时不能建立

18、RRC连接，而且成功率非常低。通过测试软件发现RRC无法建立时， PCCPCH RSCP在-60dBm，但是业务信道DPCH RSCP很低一般在-110dbm左右，且此时BLER很高，甚至达到100%。查看UE所占用的时隙发现：当下行占用的是第3时隙时RRC无法正常建立连接，同时业务信道的DPCH RSCP很低；而当下行占用第4时隙时则各项业务正常，业务信道DPCH RSCP正常，通过查看室内覆盖方案出现现象的区域都是干放覆盖的区域，截图如下：占用第3时隙时的截图：图14 UE在第3时隙接入时信令截图占用第4时隙时的截图：图15 UE在第4时隙接入时信令截图通过室分监控室查看干放的时隙配置参数

19、，发现转换点还是按3：3时隙来配置，而小区的时隙配比为2：4，随后将干放的配置改为2：4后，复测此干放覆盖区域，各项业务正常，如下截图：图16 修改后UE在第3时隙接入时信令截图定位和解决这类干放时隙配置与小区不一致的问题，可以采取该小区的时隙3的优先级设置最高，再进行AMR拨打测试，此时若发现PCCPCH RSCP和DPCH RSCP值相差很大，而且BLER很高，UE起呼很困难，则可以初步判断干放的时隙配比有问题，在时隙3上产生强干扰，造成接通率低。2. 干放上下行链路不平衡问题在室内小区中若存在有信号打不通电话的情况，主要现象是UE已发送RRC CONNECT REQUEST消息，但是网络

20、侧没有收到，导致接入失败。出现这种情况，首先还是分RRU直接覆盖区域和干放覆盖区域分别进行CQT测试，如果只是在干放覆盖区域存在起呼困难的问题则将问题的定位重点放在室分系统上。问题定位可参考如下流程：1.在RRU覆盖区域找一个弱信号点（PCCPCH RSCP为<95dBm），进行多次的CQT测试，若每次都能接入成功，则判断RRU的上下行链路是平衡的，如下图所示：图17 RRU覆盖区域起呼正常截图然后，同样在干放覆盖区域找一个弱信号点（PCCPCH RSCP为-95dBm左右），进行多次的CQT测试，若每次接入都不成功或很难接入，则说明干放的上行链路损耗比较大，而且在相同电平的情况下，在R

21、RU直接覆盖区域不存在起呼困难的问题，则可以把问题的定位重点放在室分系统上，大多数情况均是干放的上行增益比较低，则通知室分厂家重新对干放进行调试，如下图所示：2 CS掉话率问题定位分析2.1 概述对CS域掉话率提升接通率较低，重点从产品问题、TOP小区问题、终端问题、无线环境及干扰问题等方面，结合PCHR数据CS掉话原因进行问题分析和指标提升；1) TOP小区统计分析6、7、8月份全网CS掉话率的TOP 10小区失败次数占全网比例，在7月最后一周为22.36%，8月最后一周为30.95%。其中未替换站点对指标影响较大，以RNC1T为例，统计8月18日8月24日期间，莲北村T1、莲北村T2、新田

22、高层T1、新田高层T3 4个小区的掉话次数，占整个RNC的18，CS掉话率与TOPN小区强相关,尤其是未替换站点的影响情况。2) 产品问题通常指标提升过程中，产品新版本发布上网都可以对前期发现的产品问题进行修正，因此发现产品问题对于提升网络指标起到很重要的作用。结合现网情况，经过产品定位，确认在切换过程中上报多条测量报告时，未收到物理信道重配完成消息，导致掉话的问题主要是RNC的产品问题导致，升级新版本即可解决该类问题。3) 终端问题通过PCHR数据统计分析，CS掉话率域固定台等终端强相关，以RNC1T/2T/3T，在8月19日8月23日的数据统计为例：TOP终端：（中兴无线座机U110）、（

23、联想无线座机TD105）、（华为无线座机ETS5623）、（三星手机i688）IMEI（型号）占总掉话的比例（联想无线座机TD105）12%（中兴无线座机U110）8%（华为无线座机ETS5623）7%（三星i688）10%l 从接入电平分析，无线座机起呼时并不处于弱覆盖区域；l 从无线座机的用户行为分析，大部分未发生切换,目前掉话用户及小区不固定;从PCHR分析，掉话前上下行链路都变差；l 措施：继续对掉话进行研究,是无线环境波动还是终端的波动,需继续研究,当前可先采取”梳理无线座机集中的小区，提高3/2G切换门限”的措施加以提升；4) 无线环境问题从接入电平分析，绝大部分掉话事件起呼时并不

24、处于弱覆盖区域，掉话时表现为SRB Reset和Rl Fail，说明链路由好变差。对于处于弱覆盖区域起呼的用户，很可能是用户重选不及时或用户锁定T网; 2.2 CS掉话原因分析及优化措施分析6月下旬的CS掉话率指标，从PCHR工具统计的导致掉话的主要原因如下图所示。图18 CS掉话原因统计（以深圳某天数据为例）2.2.1 SRB Reset导致的掉话其中SRB Reset占比最高，SRB Reset在PCHR中主要体现为以下两种信令流程：1）切换完成后“测量控制”未正确接收导致SRB Reset；2）切换过程中的“物理信道重配”或“物理信道重配完成”未正确接收；以上两种原因导致的掉话均发生在切

25、换过程中，发生异常的信令如下图红框所示。图19 切换信令流程图导致以上掉话的原因主要有产品bug、干扰、无线信道快衰等原因。l 其中产品bug的分析及解决见“（5）技术问题攻关”部分。l 干扰可以通过RF优化、频点扰码优化、参数优化等网络优化手段改善。l 无线信道快衰导致的丢包需要产品处理机制进行优化。1) 切换完成后“测量控制”未正确接收导致SRB Reset；图20 切换后下发测量控制后掉话这种问题最常见的一种场景，就是网络侧已经下发的测量控制，但是UE侧没有收到，大概在测量控制下发7.8s左右，掉话。UTRAN通过在下行链路DCCH上使用AM RLC发送测量控制消息，对于AM消息，RLC

26、层需要收到对端的Ack消息才算流程正常。通常一条消息会分成几个数据包发送，每一个数据包都需要对端反馈Ack消息。以测量控制消息为例，视邻区的多少网络侧会将其分成数量不等的包，如果其中有一个包的Ack初次没有收到（可能是UE下行没有收到，也可能是UE没回Ack），网络侧会发起重传，周期200ms，重传40次，如果这段时间一直收不到Ack，则视为流程异常，RLC层会发起SRB Reset。关于Ack收不到，9月份T3G在深圳测试时只抓到为数不多的几次，现象是UE在收最后一个数据包的时候无线链路质量变差，CRC校验全错，此后7.8s一直很差，网络侧等待超时后发起SRB Reset。针对无线链路质量变

27、差，目前没有明确定位在产品或者终端问题，可以通过RF优化、频点扰码优化、参数优化等网络优化手段改善。图21 掉话前信令流程湖北大厦一直处于掉话的Top小区列表，对于该小区的掉话，用户不集中。通过分析话统发现，20251小区有15个系统内邻区，且20251主载频与同站邻区20252的辅1载频同频，加之该站点话务量可能较高，造成同频切换次数过多，失败次数增加，增加掉话风险。话统信息如图。图22 该小区的切换邻区统计调整20252小区辅1载频的频点，降低同频切换的概率，辅助RF优化工作对该片区掉话率有改善。2) 切换过程中的“物理信道重配”或“物理信道重配完成”未正确接收；图23 切换时为收到物理信

28、道重配完成掉话从以往RNC及UE侧log可以看出“物理信道重配完成”收不到的现象在非固定小区随机出现，表现为UE在间隔较短的时间内上报两条测量报告。这种场景在密集城区，邻区关系比较复杂的场景下比较易发，因为在这种场景下信号电平波动较大，UE会判断多个小区满足测量报告触发条件。从获取的RNC侧LOG分析，发现出现这种情况的根因是：1、 为了加快切换流程，目前接力切换中采用了立即激活方式，即收到测量报告后立即执行切换流程。物理层传输很快切换至目标小区，但第二条测量报告还没有在原小区完成传输，剩余的数据包会在新小区继续传输。2、 考虑到物理信道重配置的传输时长和终端的处理时长，网络侧会给MACD层配

29、置一个激活时间。如果RNC侧MACD激活时间还没有到， RNC在原小区接收数据，不会在新的小区接收数据包；激活时间超时后，RNC在目标小区接收数据，不会在原小区接收数据。3、 网络中出现的“物理信道重配完成”收不到就是由于MACD层的这个激活时间配置过长，导致采用立即激活机制后加快的切换流程与之冲突，即前文提到的第二条测量报告在目标小区传输的剩余部分过早到达MACD，由于激活时间未到，RNC无法接收新小区上来的数据包，导致测量报告的部分数据包被丢弃。如果激活时间设置过短，可能由于终端处理时长较长导致激活时间超时，造成UE在原小区传输的数据包丢失。通俗的说，由于RNC原来采取单发机制，在多测量报

30、告的场景下，UE的第二条测量报告部分在原小区发送，部分在目标小区发送，此时因为RNC配置的上行目标小区接收时间未到，第二部分数据包无法正确接收，导致目标小区上行数据包的序号错位，进而影响后续“物理信道重配置完成”消息的正确接收。SP005补丁优化了处理流程，采用双发机制，采用这种机制后可以在新旧链路上同时发送数据包，可以保证终端的测量报告在新小区重传，从根本上解决这个问题。针对深圳的情况，此补丁更具有特殊意义。1、 深圳现网我司的区域关内属于密集城区，邻区关系复杂，RNC处理机制造成的“物理信道重配完成”收不到的问题更易发生； 2、 由于深圳现网较我司其他地区网络存在大量商用用户，用户日常活动

31、的区域更符合该问题发生的场景。所以，这类问题在深圳网络中所占的掉话原因比例较其他区域更高。对全网打上SP005补丁后，该问题得到解决，CS掉话率提升明显。2.2.2 Rl Failure导致的掉话从PCHR统计工具的截图中可以看到典型的Rl Failure导致掉话的流程。图24 起呼后RL FAIL导致掉话对于这一类掉话需要从参数优化和RF优化两个方面进行改善。1）参数优化NodeB在检测UE与网络侧上行失步后，由于深圳由以下参数配置：NOUTSYNCIND=20,TRLFAILURE=200，表示NodeB将在无线链路失步后23.2秒上报RL FAIL IND,NodeB的RECCTT定时器

32、将决定在上报RL FAIL IND后，什么时候上报NBAP_RESET_REQ，而RNC收到该消息后，将发送IU release request给核心网，释放会话，导致掉话。但目前深圳现网的RECCTT参数设置为60。为了降低掉话率，我们进行尝试修改。修改了RECCTT定时器，从60修改为250，表示NODEB应该在发送RL RAIL IND后25秒上报NBAP_RESET_REQ释放呼叫。通过对CS业务的PCHR数据分析，我们可以看到以下的信令流程图：在RECCTT=60时，CS在收到无线链路失败后2秒释放，而RECCTT=250时，CS在17秒后释放。图25 RECCTT=250时 CS释

33、放时间图26 RECCTT=60时 CS释放时间但RECCTT=60时，CS在收到无线链路失败后2秒释放，而RECCTT=250时，CS在17秒后释放。2.2.3 TOP问题小区处理案例1：问题描述：从话统信息中可以获知某个RNC CS掉话的Top小区，但这些Top小区确切的掉话原因从话统中不易获取，比如是Top小区中的Top终端造成的还是Top小区离散用户，借助PCHR工具可以精确定位。问题分析：以RNC1T为例1) 从话统中看到莲北村T1（20281）一直位于CS掉话的Top小区列表；2) 通过PCHR工具，插入UE标示，发现这个小区的掉话并不集中于Top终端,如图1所示；图27 20281小区掉话信息分析某个终端掉话前的信令流程，发现掉话原因为链路质量变差，疑似UE没有收到Measurement Control，层2收不到ack消息导致SRB复位。见图28、图29。图28 链路释放前的链路信息图29 掉话前信令流程3) 经过分析，其他掉话终端与以上现象类似，基本可以确定是小区无线环境导致了掉话。经过核查，该小区属于未替换站，根据之前的测试经验，新老站之间的切换会存在概率性的切换失败，从而导致掉话。解决措施：1) 根