TDSCDMA CS域问题定位分析.docx
《TDSCDMA CS域问题定位分析.docx》由会员分享，可在线阅读，更多相关《TDSCDMA CS域问题定位分析.docx（27页珍藏版）》请在冰豆网上搜索。
TDSCDMACS域问题定位分析
CS域问题定位分析
HuaweiTechnologiesCo.,Ltd.
华为技术有限公司
TableofContents目录
1CS语音接通率问题定位分析3
1.1概述3
1.2RRC接入失败原因分析及优化措施4
1.2.1资源拥塞导致RRCreject接入失败4
1.2.2RLSETUPFAIL导致RRC接入失败6
1.2.3RRC.FailConnEstab.NoReply（无响应）导致RRC接入失败8
1.2.4室内小区接入问题定位12
2CS掉话率问题定位分析17
2.1概述17
2.2CS掉话原因分析及优化措施18
2.2.1SRBReset导致的掉话18
2.2.2RlFailure导致的掉话23
2.2.3TOP问题小区处理25
2.2.4TOP终端影响26
CS域问题定位分析
关键词：
CS域接入掉话问题分析
摘要：
本文主要是针对在日常网络优化过程中，总结了CS域方面的RRC接入失败，以及CS掉话方面的常见问题定位、分析思路，以及提出优化方法和解决方案。
缩略语清单：
缩略语
英文全名
中文解释
RRC
RadioResourceControl
无线资源控制
ISCP
InterferenceSignalCodePower
干扰信号码功率
RSCP
ReceivedSignalCodePower
接收信号码功率
SRB
SignalingRadioBearer
信令无线承载
RL
RadioLink
无线链路
CRC
CyclicRedundancyCheck
循环冗余校验
1CS语音接通率问题定位分析
1.1概述
本文主要针对CS域RRC接通率较低，重点从产品问题、TOP小区问题、无线环境及干扰问题等方面，结合话统中RRC接通率失败原因进行问题分析和指标提升；
1）TOP小区
主要是通过数据统计和分析，确认影响该指标的是部分点，还是整体面的问题，举例：
统计分析6、7、8月份全网CS域RRC建立失败的TOP10小区失败次数占全网比例，基本持续在10％以上，情况严重时达到40％左右，确定TOP小区对指标提升影响较大，优化过程中需重点解决对指标影响较大的TOP小区。
2）产品问题
通常指标提升过程中，产品新版本发布上网都可以对前期发现的产品问题进行修正，因此发现产品问题对于提升网络指标起到很重要的作用。
结合现网情况，经过产品定位，确认在RRC建立失败原因的RLSETUPFAIL类中，返回原因值为配置不支持的主要是由于RNC和NODEB的产品问题导致，升级新版本可解决大部份该类问题。
3）无线环境问题
无线环境方面主要是从覆盖和干扰两个方面来进行分析，主要是通过PCHR中CS域RRC建立失败的数据按照无线环境信号RSCP，和ISCP进行统计，找出是否在弱覆盖、ISCP高即干扰较大的情况下出现接入失败，通过数据统计：
a.在接入电平<-95时，RRC建立失败率最高，随着接入电平减弱，CS域RRC建立成功率降低，接入失败与弱覆盖强相关；
b.全网接入主要集中在ISCP（-100,105）之间，失败率最高，ISCP干扰不是导致RRC建立失败的主要原因。
1.2RRC接入失败原因分析及优化措施
图1话统RRC建立失败原因统计
1.2.1资源拥塞导致RRCreject接入失败
RRC连接拒绝原因为拥塞时，说明系统已经判断小区处于拥塞状态，需要对该小区的性能统计指标进行分析，主要从下面两个方面来分析：
1.从话统数据统计中确认该小区是否还在其他的接入失败原因；
目前的机制是一旦出现连续100次RRC建立失败，则认为小区进入拥塞状态，后续收到的RRC建立消息按照80％的概率直接拒绝；
出现拥塞主要是由于其他原因的次数较多，导致触发了系统内判断小区拥塞的机制，针对出现这类问题的小区，首先重点解决首先导致RRC建立失败的主要原因，再解决拥塞问题；
2.小区码资源受限；可根据话统的码资源利用情况等数据进行确认，是否因码资源不足导致拥塞，针对这类TOP小区，建议扩容，增加载波解决拥塞问题。
【案例】
从UE侧看，发现UE发起RRCCONNECTREQ消息后，网络侧直接返回RRCCONNECTREJECT消息，原因值为congestion（拥塞），如下图所示：
图2Ue接入失败时UE侧LOG
查看话统数据cr.carrier表统计，确定该小区在UE接入时（测试机器时间略快于后台服务器），主载波的下行码道资源已被全部占用，码道资源不足导致接入失败。
图3话统ca.carrier表统计数据
通过对全网拥塞小区扩容以及TOPN小区处理，因拥塞原因导致接入失败的比例呈明显下降趋势，到9月最后一周的数据统计，因该类原因导致的接入失败至占全网接入失败的0.64%。
图4话统数据RRC建立失败原因-拥塞统计
1.2.2RLSETUPFAIL导致RRC接入失败
主要是在RNC收到UE上报的RRCCONNECTREQ消息，向NodeB发送NBAP_RL_SETUP_REQ，直接收到NodeB返回的NBAP_RL_SETUP_FAIL，或者没有收到NodeB响应消息，导致RRC接入失败，出现该类问题，需重点关注和分析IUB接口是否正常，重点检查传输链路是否正常，以及NODEB运行是否正常。
【案例】
从UU口跟踪的LOG，发现UE发起RRCCONNECTREQ消息后，网络侧直接返回RRCCONNECTREJECT消息，原因值为unspecified，如下图所示：
图5RNC侧log1
查看IUB接口LOG，RL_SETUP_FAIL，失败原因为：
requested_configuration_not_supported
图6RNC侧log2
出现该类失败原因小区在现网中不固定，而且失败次数较多，很难复现，对指标影响较大；
经过定位，该问题属于产品问题，问题原因分析如下：
当业务由于某种原因失败时，UE发起信令释放指示，RNC的异常处理存在问题，RNCRR只通知RNCNBM释放资源，没有通知NB释放资源。
这样RNC和NB存在资源不一致的情况。
NodeB会一直等待同步，不释放资源。
如果有其它UE接入/重配/切换到该小区，如果RNC分配到到该资源上，就会因码道冲突而失败，接入/切换失败体现为NBAP_RL_SETUP_FAIL，重配失败体现为NBAP_RL_RECFG_FAIL。
由于上行同步存在误检可能性，NODEB仍有可能同步并发送RLrestoration给RNC，此时RNC因为已经没有该UE资源，会发起NBAPReset，清掉NB资源，之后就不会再有码道冲突问题。
这就是现场问题出现后会以一定概率消失的原因。
解决措施：
升级RNC和NODEB版本，在现场未升级版本之前，只能通过去激活/激活小区来规避该问题。
全网升级RNC和NODEB版本，RLSETUPFAIL导致的接入次数明显减少，平均失败次数在60次左右，占全网失败次数仅为0.27%。
图7话统数据RRC建立失败原因-RLSETUPFAIL统计
1.2.3RRC.FailConnEstab.NoReply（无响应）导致RRC接入失败
RNC收不到RRCCONNECTIONSETUPCOMPLETE消息，是全网中最主要的问题原因，主要从如下几个流程来考虑：
1.UE是否收到RRCCONNECTIONSETUP消息；
RRCCONNECTIONSETUP消息是在FACH上发送给UE，可以通过：
1）在NodeB上关闭FACH赋形，FACH赋形如果不准确，会影响信道性能，关闭FACH赋形后，观察是否有所改善；
2）下行功率不足，PCCPCHRSCP较低，C/I差，导致UE没有收到SETUP消息；目前SCCPCH功率配置的值一般是-3db，可以提高SCCPCH功率，满足信号覆盖不好的地方功率需求。
可以通过检查同一UE下一次发送RRC_CONNECT_REQ间隔是否是T300设置值，如果是，说明UE没有收到RRC_CONN_SETUP消息，属于下行链路问题，则可以通过上述的优化方法进行调整，如果不是，说明T300已经停止即UE收到了RRC_CONN_SETUP消息，属于上行问题。
2.UE是否发送RRCCONNECTIONSETUPCOMPLETE消息；
UE收到RRCCONNECTSTEUP消息，没有发送RRCCONNECTIONSETUPCOMPLETE消息，
前期通过对室内TOP小区排查时，发现UE在收到RRCCONNECTION消息，就没有发送RRCCONNECTIONSETUPCOMPLETE消息，如下下图所示：
图8起呼失败终端侧LOG
后经过问题定位确认：
干放的时隙配比和小区的不一致，导致在时隙3上产生强烈的干扰，BLER高达100％，UE不能正常解码，导致UE不能正常消息流程。
3.UE已发送RRCCONNECTIONSETUPCOMPLETE消息，RNC没有收到；
可以通过调整闭环功控等参数来提高上行发射功率，提高接入成功率。
针对问题1）和问题3），在电平和干扰情况都较理想的情况，均没有复现该问题，暂时只能通过参数调整的手段，进行优化，主要的增大上行/下行干扰余量，增加上行/下行发射功率。
针对接通率较差的小区，可适当将上行干扰余量提高至6，例如下图中，针对10T中RRC接通率较差的小区，8号修改上行干扰余量从3到6，修改后，CS域RRC接通率呈明显上升趋势，而CS和PS掉话率并没有明显恶化。
图9调整上行干扰余量RRC建立成功率统计
图10调整上行干扰余量CS掉话率和PS掉话率统计
关内站点较为密集的城区，下行干扰余量不建议修改过大，会造成掉话率恶化。
例如针对2T，1号修改下行干扰余量到180后，CS和PS掉话率呈明显上升趋势，5号和11号持续降低部分小区的下行干扰余量到90后，掉话率明显降低，已低于修改前，没有出现恶化；
图11调整上行和下行干扰余量RRC建立成功率统计
图12调整上行和下行干扰余量语音掉话率统计
图13调整上行和下行干扰余量PS掉话率统计
1.2.4室内小区接入问题定位
室内站点相对于室外站点，主要是增加了室分处理系统，在前期深圳项目中部分室内站点由于室分系统存在问题，导致接通率较低，重点针对室内小区进行拨测和处理，问题分析思路如下：
1）确认基站是否有告警，例如驻波比告警、传输告警、GPS告警等，若存在上述告警，建议先进行产品排障；
2）确认该小区的UPPCHISCP值（UPPCHISCP正常值为-100dBm～-110dBm.）和载波时隙干扰测量值（上行的时隙干扰ISCP正常值为-100dBm～-110dBm.），若出现ISPC值较大的情况，建议先排除干扰问题，重点检查是否由于室外站点信号覆盖到室内，造成干扰；
3）通过室分图纸，确认哪里区域是RRU直接覆盖，哪些区域是干放覆盖，分开进行CQT测试，确认问题区域或者楼层。
若COT测试确认问题主要在干放覆盖区域，则问题定位重点应放在室分干放系统上，干放系统主要问题一般为：
干放故障、干放时隙配置不一致、上下行链路不平衡等
4）若确认问题在RRU直接覆盖区域，在覆盖问题区域的该路PAHT下，直接连接小天线进行测试，确认问题是产品问题，还是室分连接系统问题
1.干放时隙配比与小区不一致问题
在某室内站点的部分楼层CS/PS域测试，有时能正常呼叫，有时不能建立RRC连接，而且成功率非常低。
通过测试软件发现RRC无法建立时，PCCPCHRSCP在-60dBm，但是业务信道DPCHRSCP很低一般在-110dbm左右，且此时BLER很高，甚至达到100%。
查看UE所占用的时隙发现：
当下行占用的是第3时隙时RRC无法正常建立连接，同时业务信道的DPCHRSCP很低；而当下行占用第4时隙时则各项业务正常，业务信道DPCHRSCP正常，通过查看室内覆盖方案出现现象的区域都是干放覆盖的区域，截图如下：
占用第3时隙时的截图：
图14UE在第3时隙接入时信令截图
占用第4时隙时的截图：
图15UE在第4时隙接入时信令截图
通过室分监控室查看干放的时隙配置参数，发现转换点还是按3：
3时隙来配置，而小区的时隙配比为2：
4，随后将干放的配置改为2：
4后，复测此干放覆盖区域，各项业务正常，如下截图：
图16修改后UE在第3时隙接入时信令截图
定位和解决这类干放时隙配置与小区不一致的问题，可以采取该小区的时隙3的优先级设置最高，再进行AMR拨打测试，此时若发现PCCPCHRSCP和DPCHRSCP值相差很大，而且BLER很高，UE起呼很困难，则可以初步判断干放的时隙配比有问题，在时隙3上产生强干扰，造成接通率低。
2.干放上下行链路不平衡问题
在室内小区中若存在有信号打不通电话的情况，主要现象是UE已发送RRCCONNECTREQUEST消息，但是网络侧没有收到，导致接入失败。
出现这种情况，首先还是分RRU直接覆盖区域和干放覆盖区域分别进行CQT测试，如果只是在干放覆盖区域存在起呼困难的问题则将问题的定位重点放在室分系统上。
问题定位可参考如下流程：
1.在RRU覆盖区域找一个弱信号点（PCCPCHRSCP为<－95dBm），进行多次的CQT测试，若每次都能接入成功，则判断RRU的上下行链路是平衡的，如下图所示：
图17RRU覆盖区域起呼正常截图
然后，同样在干放覆盖区域找一个弱信号点（PCCPCHRSCP为-95dBm左右），进行多次的CQT测试，若每次接入都不成功或很难接入，则说明干放的上行链路损耗比较大，而且在相同电平的情况下，在RRU直接覆盖区域不存在起呼困难的问题，则可以把问题的定位重点放在室分系统上，大多数情况均是干放的上行增益比较低，则通知室分厂家重新对干放进行调试，如下图所示：
2CS掉话率问题定位分析
2.1概述
对CS域掉话率提升接通率较低，重点从产品问题、TOP小区问题、终端问题、无线环境及干扰问题等方面，结合PCHR数据CS掉话原因进行问题分析和指标提升；
1）TOP小区
统计分析6、7、8月份全网CS掉话率的TOP10小区失败次数占全网比例，在7月最后一周为22.36%，8月最后一周为30.95%。
其中未替换站点对指标影响较大，以RNC1T为例，统计8月18日~8月24日期间，莲北村T1、莲北村T2、新田高层T1、新田高层T34个小区的掉话次数，占整个RNC的18％，CS掉话率与TOPN小区强相关,尤其是未替换站点的影响情况。
2）产品问题
通常指标提升过程中，产品新版本发布上网都可以对前期发现的产品问题进行修正，因此发现产品问题对于提升网络指标起到很重要的作用。
结合现网情况，经过产品定位，确认在切换过程中上报多条测量报告时，未收到物理信道重配完成消息，导致掉话的问题主要是RNC的产品问题导致，升级新版本即可解决该类问题。
3）终端问题
通过PCHR数据统计分析，CS掉话率域固定台等终端强相关，以RNC1T/2T/3T，在8月19日~8月23日的数据统计为例：
TOP终端：
86901300（中兴无线座机U110）、86005600（联想无线座机TD105）、86007500（华为无线座机ETS5623）、86000200（三星手机i688）
IMEI（型号）
占总掉话的比例
86005600（联想无线座机TD105）
12%
86901300（中兴无线座机U110）
8%
86007500（华为无线座机ETS5623）
7%
86000200（三星i688）
10%
●从接入电平分析，无线座机起呼时并不处于弱覆盖区域；
●从无线座机的用户行为分析，大部分未发生切换,目前掉话用户及小区不固定;从PCHR分析，掉话前上下行链路都变差；
●措施：
继续对掉话进行研究,是无线环境波动还是终端的波动,需继续研究,当前可先采取”梳理无线座机集中的小区，提高3/2G切换门限”的措施加以提升；
4）无线环境问题
从接入电平分析，绝大部分掉话事件起呼时并不处于弱覆盖区域，掉话时表现为SRBReset和RlFail，说明链路由好变差。
对于处于弱覆盖区域起呼的用户，很可能是用户重选不及时或用户锁定T网;
2.2CS掉话原因分析及优化措施
分析6月下旬的CS掉话率指标，从PCHR工具统计的导致掉话的主要原因如下图所示。
图18CS掉话原因统计（以深圳某天数据为例）
2.2.1SRBReset导致的掉话
其中SRBReset占比最高，SRBReset在PCHR中主要体现为以下两种信令流程：
1）切换完成后“测量控制”未正确接收导致SRBReset；2）切换过程中的“物理信道重配”或“物理信道重配完成”未正确接收；
以上两种原因导致的掉话均发生在切换过程中，发生异常的信令如下图红框所示。
图19切换信令流程图
导致以上掉话的原因主要有产品bug、干扰、无线信道快衰等原因。
●其中产品bug的分析及解决见“（5）技术问题攻关”部分。
●干扰可以通过RF优化、频点扰码优化、参数优化等网络优化手段改善。
●无线信道快衰导致的丢包需要产品处理机制进行优化。
1）切换完成后“测量控制”未正确接收导致SRBReset；
图20切换后下发测量控制后掉话
这种问题最常见的一种场景，就是网络侧已经下发的测量控制，但是UE侧没有收到，大概在测量控制下发7.8s左右，掉话。
UTRAN通过在下行链路DCCH上使用AMRLC发送测量控制消息，对于AM消息，RLC层需要收到对端的Ack消息才算流程正常。
通常一条消息会分成几个数据包发送，每一个数据包都需要对端反馈Ack消息。
以测量控制消息为例，视邻区的多少网络侧会将其分成数量不等的包，如果其中有一个包的Ack初次没有收到（可能是UE下行没有收到，也可能是UE没回Ack），网络侧会发起重传，周期200ms，重传40次，如果这段时间一直收不到Ack，则视为流程异常，RLC层会发起SRBReset。
关于Ack收不到，9月份T3G在深圳测试时只抓到为数不多的几次，现象是UE在收最后一个数据包的时候无线链路质量变差，CRC校验全错，此后7.8s一直很差，网络侧等待超时后发起SRBReset。
针对无线链路质量变差，目前没有明确定位在产品或者终端问题，可以通过RF优化、频点扰码优化、参数优化等网络优化手段改善。
图21掉话前信令流程
湖北大厦一直处于掉话的Top小区列表，对于该小区的掉话，用户不集中。
通过分析话统发现，20251小区有15个系统内邻区，且20251主载频与同站邻区20252的辅1载频同频，加之该站点话务量可能较高，造成同频切换次数过多，失败次数增加，增加掉话风险。
话统信息如图。
图22该小区的切换邻区统计
调整20252小区辅1载频的频点，降低同频切换的概率，辅助RF优化工作对该片区掉话率有改善。
2）切换过程中的“物理信道重配”或“物理信道重配完成”未正确接收；
图23切换时为收到物理信道重配完成掉话
从以往RNC及UE侧log可以看出“物理信道重配完成”收不到的现象在非固定小区随机出现，表现为UE在间隔较短的时间内上报两条测量报告。
这种场景在密集城区，邻区关系比较复杂的场景下比较易发，因为在这种场景下信号电平波动较大，UE会判断多个小区满足测量报告触发条件。
从获取的RNC侧LOG分析，发现出现这种情况的根因是：
1、为了加快切换流程，目前接力切换中采用了立即激活方式，即收到测量报告后立即执行切换流程。
物理层传输很快切换至目标小区，但第二条测量报告还没有在原小区完成传输，剩余的数据包会在新小区继续传输。
2、考虑到物理信道重配置的传输时长和终端的处理时长，网络侧会给MACD层配置一个激活时间。
如果RNC侧MACD激活时间还没有到，RNC在原小区接收数据，不会在新的小区接收数据包；激活时间超时后，RNC在目标小区接收数据，不会在原小区接收数据。
3、网络中出现的“物理信道重配完成”收不到就是由于MACD层的这个激活时间配置过长，导致采用立即激活机制后加快的切换流程与之冲突，即前文提到的第二条测量报告在目标小区传输的剩余部分过早到达MACD，由于激活时间未到，RNC无法接收新小区上来的数据包，导致测量报告的部分数据包被丢弃。
如果激活时间设置过短，可能由于终端处理时长较长导致激活时间超时，造成UE在原小区传输的数据包丢失。
通俗的说，由于RNC原来采取单发机制，在多测量报告的场景下，UE的第二条测量报告部分在原小区发送，部分在目标小区发送，此时因为RNC配置的上行目标小区接收时间未到，第二部分数据包无法正确接收，导致目标小区上行数据包的序号错位，进而影响后续“物理信道重配置完成”消息的正确接收。
SP005补丁优化了处理流程，采用双发机制，采用这种机制后可以在新旧链路上同时发送数据包，可以保证终端的测量报告在新小区重传，从根本上解决这个问题。
针对深圳的情况，此补丁更具有特殊意义。
1、深圳现网我司的区域关内属于密集城区，邻区关系复杂，RNC处理机制造成的“物理信道重配完成”收不到的问题更易发生；
2、由于深圳现网较我司其他地区网络存在大量商用用户，用户日常活动的区域更符合该问题发生的场景。
所以，这类问题在深圳网络中所占的掉话原因比例较其他区域更高。
对全网打上SP005补丁后，该问题得到解决，CS掉话率提升明显。
2.2.2RlFailure导致的掉话
从PCHR统计工具的截图中可以看到典型的RlFailure导致掉话的流程。
图24起呼后RLFAIL导致掉话
对于这一类掉话需要从参数优化和RF优化两个方面进行改善。
1）参数优化
NodeB在检测UE与网络侧上行失步后，由于深圳由以下参数配置：
NOUTSYNCIND=20,TRLFAILURE=200，表示NodeB将在无线链路失步后23.2秒上报RLFAILIND,NodeB的RECCTT定时器将决定在上报RLFAILIND后，什么时候上报NBAP_RESET_REQ，而RNC收到该消息后，将发送IUreleaserequest给核心网，释放会话，导致掉话。
但目前深圳现网的RECCTT参数设置为60。
为了降低掉话率，我们进行尝试修改。
修改了RECCTT定时器，从60修改为250，表示NODEB应该在发送RLRAILIND后25秒上报NBAP_RESET_REQ释放呼叫。
通过对CS业务的PCHR数据分析，我们可以看到以下的信令流程图：
在RECCTT=60时，CS在收到无线链路失败后2秒释放，而RECCTT=250时，CS在17秒后释放。
图25RECCTT=250时CS释放时间
图26RECCTT=60时CS释放时间
但RECCTT=60时，CS在收到无线链路失败后2秒释放，而RECCTT=250时，CS在17秒后释放。
2.2.3TOP问题小区处理
案例1：
问题描述：
从话统信息中可以获知某个RNCCS掉话的Top小区，但这些Top小区确切的掉话原因从话统中不易获取，比如是Top小区中的Top终端造成的还是Top小区离散用户，借助PCHR工具可以精确定位。
问题分析：
以RNC1T为例
1）从话统中看到莲北村
升级会员 