文档库 最新最全的文档下载
当前位置:文档库 › LTE接入问题分析

LTE接入问题分析

LTE接入问题分析
LTE接入问题分析

1、无线接通率指标

无线接通率=RRC连接建立成功率*E-RAB建立成功率=(RRC连接建立完成次数/RRC连接请求次数(不包括重发))*E-RAB建立成功总次数/E-RAB建立尝试总次数*100%

1.1、 RRC连接建立成功率

RRCSetupSuccessRate=(L.RRC.ConnReq.Succ)/(L.RRC.ConnReq.Att)*100%

话统统计方法:

RRC建立统计点

【A点】

(1)指标L.RRC.ConnReq.Att加1,不统计重发的次数。

Case1:eNB下发RRC_Conn_Setup消息后,在T300定时器超时前,收到相同的UeID发起的RRC_Conn_Req(Setup丢失,UE MAC冲突解决定时器超时后重发RRC_Conn_Req,UeID 不变),记为一次重发RRC_Conn_Req消息。

Case2:T300超时后,UE仍未收到RRC_Conn_Setup,UE重新搜网,发起初始接入,UeID 是取0~239的随机值或上层下发的TMSI。eNB侧记为新的一次初始接入,L.RRC.ConnReq.Att 加1。

Case3:发起Attach后会启动T3410定时器。如果UE发出RRC_Conn_Setup_Cmp后,ENB 没有收到,UE会在定时器超时后重新发起Attach,ENB侧记为新的一次初始接入;RRC_Conn_Setup_Cmp丢失不会触发重建,发起重建的前提是安全已经激活。

(2)如果RRC Connection Request消息信元Establishment Cause为“emergency”,指标L.RRC.ConnReq.Att.Emc加1。

(3)如果RRC Connection Request消息信元Establishment Cause为“highPriorityAccess”,指标L.RRC.ConnReq.Att.HighPri加1。

(4)如果RRC Connection Request消息信元Establishment Cause为“mt-Access”,指标L.RRC.ConnReq.Att.Mt加1。

(5)如果RRC Connection Request消息信元Establishment Cause为“mo-Singnalling”,指标L.RRC.ConnReq.Att.MoSig加1。

(6)如果RRC Connection Request消息信元Establishment Cause为“mo-Data”,指标L.RRC.ConnReq.Att.MoData加1。

【B点】

当eNodeB下小区接收到UE发送的RRC Connection Request消息并下发RRC Connection Setup消息给UE时,指标L.RRC.ConnSetup加1。

【C点】

当eNodeB收到UE返回的RRC Connection Setup Complete消息时统计相应指标,L.RRC.ConnReq.Succ加1。

1.2 、ERAB建立成功率

ErabSetupSuccessRate=(L.E-RAB.SuccEst)/(L.E-RAB.AttEst)*100%

话统统计方法:

图4

如上图中A点所示,当eNodeB收到来自MME的E-RAB SETUP REQUEST或者INITIAL CONTEXT SETUP REQUEST(初始上下文设置请求)消息时统计该指标。如果E-RAB SETUP REQUEST或者INITIAL CONTEXT SETUP REQUEST消息中要求同时建立多个E-RAB,则相应指标按各个业务的QCI分别进行累加。

2、接入性能优化流程

接入失败通常有三大类原因:无线侧参数配置问题、信道环境影响以及核心网侧配置问题。因此无线接通率优化流程可以按以下步骤进行:

(1)通过话统分析是否出现接入成功率低的问题,当前RRC\eRAB接通率指标一般为98%,也可根据对接入成功率指标的特殊要求启动问题定位。

(2)确认是否全网指标恶化,如果是全网指标恶化,需要检查操作,告警,是否存在网

络变动和升级行为。检查无线侧以及核心网侧参数配置是否合理,如定时器T300、T302、T3410,以及参数小区接入禁止、小区最小接入电平、IPPATH、Ncs等。

(3)如果是部分站点指标恶化,影响全网指标,需要找出TOP站点。

(4)查询RRC连接建立和ERAB建立成功率最低的TOP10站点和TOP时间段。

(5)查看TOP站点告警,检查单板状态,RRU状态,小区状态,OM操作,配置是否异常。

(6)针对TOP站点进行针对性的标准信令跟踪、干扰检测进行分析。

(7)如果标准信令和干扰检测无异常,将一键式日志,标口跟踪,干扰检测结果返回给厂家技术人员分析。

接入问题优化流程图如下图所示:

接入问题优化流程图

3、接入问题排查分析

3.1、E_NB配置问题排查

?PDCCH符号数配置问题

测试局点为了尽可能提高下行吞吐率, PDCCH通常固定1符号,但在20M带宽以下,可能出现无法接入的问题。

5M小区,PDCCH固定1符号,总共能使用的CCE个数为3,由于CCE资源受限接入不了。

10M小区,PDCCH固定1符号,总共能使用的CCE个数为8个,受上下行配比约束,下行最多能用5个,而10M小区公共信令的聚合级别为8,需要8个,因此CCE资源受限所以接入不了。

15M小区,PDCCH固定1符号,总共能使用的CCE个数为12,受上下行配比约束,下行最多能用8个,PDCCH功控开关关闭时可以接入。

PDCCH符号数配置

?IPPATH配置问题

基站在完成了安全的配置与UE能力的获取后并向小区申请资源,会向TRM申请GTPU资源,如果申请资源失败则会向核心网返回初始上下文建立失败响应INIT_CONTEXT_SETUP_FAIL;原因值填写transport resource unavailable(0);如下图所示:

初始上下文建立失败响应信令截图

在这种情况下,对照开站summary首先查看一下MML中的IPPATH是否配置正确,如果已经配置正确,则查看请初始上下文建立请求消息(INIT_CONTEXT_SETUP_REQ消息)中transportlayeraddress的信元值是否为配置的IPPATH值,如果不一样则需要确认一下是我们配置错误还是核心网填写错误。同时查看路由信息配置是否正确,如果IPPATH正确,但路由错误,同样会出现传输资源不可用的错误信息。如果以上都不符合则需要把IFTS打开,将跟踪发给厂家技术人员来确认问题的原因。

初始上下文建立请求消息信令

3.2、top小区分析处理

3.2.1、TOP小区筛选

通过U2000导出全网每日话统文件,按照(L.RRC.ConnReq.Att-L.RRC.ConnReq.Succ)次数从高到低排序,结合接入成功率,选出TOP10站点接入成功率低的小区。

按照(L.E-RAB.AttEst-L.E-RAB.SuccEst)次数从高到低排序,结合ERAB建立成功率选出TOP10 ERAB建立成功率低的站点。

目前TOP小区提取暂按以下方式操作:

①RRC请求次数大于50次

②接通率小于98%。

③在一周之类重复出现2次以上的小区。

若前三种无法提取出TOP小区,可按RRC,ERAB建立失败次数,分开求和后降序排列筛选RRC 和ERAB建立失败的TOP小区。

3.2.2、TOP小区状态检查

检查TOP小区的状态是否正常,可以在U2000上,通过MML命令“DSP CELL”能查看到小区的总体信息。

如果小区状态显示不是“正常”,可以按如下方法进行简单排查:

如果存在S1链路异常告警,请检查S1链路配置是否正确。

如果存在RSSI/RSRP通道不平衡,需要检查天馈互调干扰,

如果存在驻波告警,需要通过DSP TXBRANCH,DSP RXBRANCH查看RRU发射和接收通道状态。

如果存在小区不可用告警,需要返回主控和基带板一键式日志。

3.2.3、TOP小区指标分析

通过话统可以得出TOP小区原因分布,TOP小区中RRC和ERAB建立失败次数原因值说明:

①对小区RRC建立失败次数:

资源分配失败而导致RRC连接建立失败的次数,指标ID:1526727083;重点关注top 资源是否足够,包括top用户数,传输、PRB等;

UE无应答而导致RRC连接建立失败的次数,指标ID:1526727084;关注质差、干扰、无线环境等;

小区发送RRC Connection Reject消息次数,指标ID:1526728269;关注传输问题、是否拥塞、干扰;

因为SRS资源分配失败而导致RRC连接建立失败的次数,指标ID:1526728485;重点关注SRS带宽、配置指示、配置方式、SRS ACK/NACK设置是否合理等;

因为PUCCH资源分配失败而导致RRC连接建立失败的次数,指标ID:1526728486;关注PUCCH信道相关参数设置是否合理,CQI RB数配置是否合理等;

流控导致的RRC Connection Request 消息丢弃次数,指标ID:1526728489;关注拥塞,业务流控相关参数是否设置正确等;

流控导致的发送RRC Connection Reject消息次数,指标ID:1526728490;关注拥塞,业务流控相关参数是否设置正确等;

②对小区E-RAB建立失败次数:

因未收到UE响应而导致E-RAB建立失败的次数,指标ID:1526726717;处理建议:需排查覆盖,干扰,质差,ENODEB参数设置错误,终端及用户行为异常等原因。

核心网问题导致E-RAB建立失败次数,指标ID:1526728276;处理建议:需跟踪信令,排查核心网问题(EPC参数设置,TAC码设置的一致性,对用户开卡限制,硬件

故障方面排查);

传输层问题导致E-RAB建立失败次数,指标ID:1526728277;处理建议:需查询传输是否有故障,高误码,闪断,传输侧参数设置问题。

无线层问题导致E-RAB建立失败次数,指标ID:1526728278;处理建议:处理建议:需排查覆盖,干扰,质差,ENODEB参数设置错误,终端及用户行为异常等原因。

无线资源不足导致E-RAB建立失败次数,指标ID:1526728279;处理建议:1、排查TOP小区资源是否足够,是否故障引起,若存在资源不足问题,可考虑参数调整,

流量均衡(小区选择,重选和切换类参数);2、结合现场调整天馈,流量均衡;3、

热点区域,增补基站等;

安全模式配置失败导致E-RAB建立失败次数,指标ID:1526728280;处理建议:需排查覆盖,干扰,质差,ENODEB参数设置错误,终端及用户行为异常等原因。

3.2.4、TOP用户分析

通过CHR日志分析可以获取RRC建立失败和ERAB建立失败TOP用户的TMSI。在CHR数据中,可以通过TMSI来确定是否为同一个用户,具体方法如下:

当前华为核心网TMSI分配的机制是对于同一个IMSI用户,TMSI的右起第三个byte的数据进行随机赋值,即某用户的TMSI中只有第三个字节的8bit发生变化(如AA ** BB CC)就是同一用户。如下图所示,C0 ** 00 05就是同一个用户。

使用INSIGHTSHARP工具分析同一TMSI用户的多个接入流程,查看L2_SRB_LOG字段记录的接入时上行信道质量DMRS_SINR和DMRS_RSRP,可以初步确认用户是否处于上行弱覆盖区域:DMRS_SINR<0db或DMRS_RSRP<-131dbm可以认为终端处于弱覆盖区域。

CHR字段说明截图

3.2.5、TOP小区跟踪

通过话统分析出TOP小区和TOP时间段后,在对应的小区和时间段,打开Uu口,S1口,X2口跟踪,查看接入流程在哪一步失败。

通过TOP用户的TMSI在核心网侧获取到IMSI,可以启动该用户的全网跟踪。

3.2.6、TOP小区环境干扰分析

通过频谱扫描仪功能查看下行是否存在邻区干扰、外部系统干扰等。通过E_NB小区干扰检测的性能跟踪分析是否存在上行干扰。如存在外部干扰或邻区干扰,需要进行干扰源排查。

4、案例分析

4.1、SGW链路不通引起的无线接通率偏低案例分析

【现象描述】:

6月7日对南宁移动LTE全网站点进行KPI统计,发现部分站点在6月6日(10:00-11:00)时间段内无线接通率偏低,其中部分小区无线接通率仅有5.25%,详细指标如下:

无线接通率:

无线掉线率:

切换成功率:

无线接通率主要通过话务统计获得,根据区公司推荐的公式为:无线接通率=[RRC连接建立次数]/[RRC连接请求次数(不包括重发)]*[E-RAB建立成功总次数]/[E-RAB建立尝试总次数]*{100}。从以上KPI指标统计情况可以看出RRC连接建立成功率、切换成功率、无线掉线率指标均无明显异常,无线接通率偏低主要是因为E-RAB建立失败引起。

通过OMC920提取E-RAB建立失败小区原因如下:

?eNodeB发起的S1 RESET导致的E-RAB异常释放

?传输层问题导致的E-RAB异常释放

?切换流程失败导致E-RAB异常释放

?无线层问题导致的E-RAB异常释放

?核心网问题导致的激活的E-RAB异常释放

?网络拥塞导致的E-RAB异常释放

?安全模式配置失败导致E-RAB建立失败

?无线资源不足导致E-RAB建立失败

?等待UE响应超时导致E-RAB建立失败

?无可用资源导致E-RAB建立失败

提取E-RAB建立失败指标情况如下:

从以上KPI指标统计结果来看,以上小区RRC建立成功率良好,无线接通率偏低主要

是因为无可用资源导致。

【原因分析】:

E-RAB建立流程是UE的专有承载建立过程,当UE完成初始UE上下文接入过程后,当需要进行新的业务服务时,会发起E-RAB建立过程。同样地,E-RAB建立过程也会伴随有NAS消息的交互,目的是在NAS层协商业务参数用于接入层的资源分配。下图所示为典型的E-RAB建立过程:

①在完成初始UE上下文建立过程后,当UE需要进行业务建立时,会通过 NAS层消息交

互向MME申请建立专有承载。

② MME收到UPLINK NAS TRANSPORT后,根据NAS层消息内容为UE分配专有承载资源,

并向eNodeB发送E-RAB SETUP REQUEST消息。消息中主要携带E-RAB建立列表,列表

包括E-RAB ID、承载的QoS信息、传输层配置信息以及NAS层信息。

③eNodeB收到E-RAB SETUP REQUEST消息后,根据UE申请的资源按照相应的RRM算法为

UE分配相关资源,包括:传输资源、无线资源、调度资源、功率资源、天线资源等

等。并向UE发送RRC Connection Reconfiguration消息。

④UE收到RRC Connection Reconfiguration消息后,根据eNodeB为其分配的相关资源

完成参数配置,并向eNodeB发送RRC Connection Reconfiguration Complete消息,通知eNodeB配置完成。

⑤eNodeB完成上述操作后即成功地为UE建立起对应的E-RAB承载,因此向MME发送

E-RAB SETUP RESPONSE消息,E-RAB建立流程结束。

从后台提取指标发现该小区无可用资源导致E-RAB建立失败,对此可以通过以下几个方面来进行分析:

?eNodeB参数配置有误

?核心网问题(EPC参数设置,TAC码设置的一致性,对用户开卡限制,硬件故障方面排

查)

?该区域存在弱覆盖

?终端及用户行为异常

?基站与核心网之间存在链路故障

后台提取以上小区告警情况,发现在此时间段出现有大量用户面承载链路故障告警

E-RAB建立过程会为UE建立多条E-RAB承载,E-RAB建立的发起者可以是UE自身,也可以由网络发起。当UE需要进行新的业务时,或网络侧需要为UE建立新的业务时,就可以通过NAS层的专有承载激活过程为UE建立E-RAB,专有承载激活过程中UE和网络侧会协商QoS信息,接入网根据QoS信息为UE进行资源分配,并完成E-RAB的建立过程。从以上查询结果可以看出,在此时间段内以上E-RAB建立异常小区均出现用户面承载链路故障告警,且定位对端SGW侧IP地址均为100.81.50.33/100.81.50.34,怀疑该SGW链路异常引起E-RAB 建立失败。

【处理过程】:

?核查以上站点eNodeB参数均无异常。

?经现网查询EPC、TAC等参数配置无误,核心网侧反馈相关参数配置无异常。

?核查核心网侧SGW链路发现在6月6月(10:00-16:00)期间核心网相关人员关闭

了IP地址为100.81.50.33和100.81.50.34的两个SGW链路端口,从而导致大量

E-RAB建立失败的情况。对此可以提取6月7日、6月8日相关指标统计情况如下:

【处理结果】:

根据以上测量统计、E-RAB信令流程分析结果来看,该小区无线接通率偏低主要是因为SGW 链路不通引起,对应的SGW链路恢复后各小区无线接通率指标恢复正常。

相关文档