TDLTE优化接入.docx
- 文档编号:24276211
- 上传时间:2023-05-26
- 格式:DOCX
- 页数:50
- 大小:2.16MB
TDLTE优化接入.docx
《TDLTE优化接入.docx》由会员分享,可在线阅读,更多相关《TDLTE优化接入.docx(50页珍藏版)》请在冰豆网上搜索。
TDLTE优化接入
TDLTE接入性能优化
本文介绍了用户接入的流程和用户接入失败时问题定位的基本方法,常见问题排查方法部分主要面向网络维护人员,介绍了一些常见问题的定位排查手段和方法,主要应用场景为通过KPI指标发现问题,通过CHR、告警日志、标口跟踪、UE侧log进行问题定位。
1概念和基本原理
1.1基本概念
(1)用户Attach流程:
图1用户接入流程
(2)随机接入流程介绍
随机接入过程的发生有以下五种场景:
1、从空闲态转到连接态的初始接入;
2、无线链接失败后的接入;
3、切换过程中的接入;
4、当UE处于连接态时下行数据到达时因为某些原因需要随机接入,如上行失步时有下行数据到达;
5、当UE处于连接态时上行数据到达时因为某些原因需要随机接入,如上行失步时有上行行数据到达;
随机接入分为竞争接入与非竞争接入两种,其中竞争随机接入适用于上述1、2、5三种场景,而非竞争随机接入适用于3、4两种场景。
随机接入基本流程如下:
图2随机接入流程图(左:
基于竞争的随机接入右:
基于非竞争的随机接入)
1.2接入流程话统介绍
1.2.1随机接入话统
随机接入过程分为基于竞争的随机接入和基于非竞争的随机接入两种基本过程。
“RA测量(小区)(RA.Cell)”统计小区内不同随机接入过程的前导接收次数、RAR发送次数以及竞争过程中的ContentionResolution发送次数,用于分析随机接入的负载、成功率等相关情况。
1.2.2RRC连接建立请求话统
统计eNodeB内各小区收到的RRC的建立请求次数。
RRCConnectionRequest消息是UE向eNodeB发送的第一条RRC信令消息,目的是请求建立一条RRC连接。
1.2.3RRC连接建立尝试话统
统计小区内不同类型RRC的建立尝试次数,即eNodeB响应UE的RRCConnectionRequest消息并下发RRCConnectionSetup消息的次数。
RRCConnectionSetup消息是eNodeB发送给UE的RRC信令消息,目的是通知UERRC连接的建立结果及相关配置信息。
1.2.4RRC连接建立成功话统
统计小区内不同类型RRC的建立成功次数,即eNodeB收到UE的RRCConnectionSetupComplete的次数。
RRCConnectionSetupComplete消息是UE发送的RRC信令消息,目的是通知eNodeB本次RRC连接建立完成,并携带NAS信令信息以及PLMN的选择信息。
话统统计方法
图3RRC建立统计点
【A点】
(1)指标L.RRC.ConnReq.Att加1,不统计重发的次数。
Case1:
eNB下发RRC_Conn_Setup消息后,在T300定时器超时前,收到相同的UeID发起的RRC_Conn_Req(Setup丢失,UEMAC冲突解决定时器超时后重发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)如果RRCConnectionRequest消息信元EstablishmentCause为“emergency”,指标L.RRC.ConnReq.Att.Emc加1。
(3)如果RRCConnectionRequest消息信元EstablishmentCause为“highPriorityAccess”,指标L.RRC.ConnReq.Att.HighPri加1。
(4)如果RRCConnectionRequest消息信元EstablishmentCause为“mt-Access”,指标L.RRC.ConnReq.Att.Mt加1。
(5)如果RRCConnectionRequest消息信元EstablishmentCause为“mo-Singnalling”,指标L.RRC.ConnReq.Att.MoSig加1。
(6)如果RRCConnectionRequest消息信元EstablishmentCause为“mo-Data”,指标L.RRC.ConnReq.Att.MoData加1。
【B点】
当eNodeB下小区接收到UE发送的RRCConnectionRequest消息并下发RRCConnectionSetup消息给UE时,指标L.RRC.ConnSetup加1。
【C点】
当eNodeB收到UE返回的RRCConnectionSetupComplete消息时统计相应指标,L.RRC.ConnReq.Succ加1。
RRCSetupSuccessRate计算
RRCSetupSuccessRate=(L.RRC.ConnReq.Succ)/(L.RRC.ConnReq.Att)*100%
1.2.5RRC连接建立失败话统
统计小区内不同原因的RRC连接建立失败的次数及总的RRC连接失败次数。
RRCConnectionReject消息是eNodeB发送给UE的RRC信令消息,目的是通知UE本次接入过程被eNodeB拒绝。
1.2.6ERAB承载建立尝试话统
统计小区E-RAB建立尝试总次数。
E-RAB建立过程一般由UE在需要向无线网络申请服务时主动发起,并通过初始UE上下文建立流程或E-RAB建立流程完成建立。
E-RAB建立尝试总次数用于统计UE发起的总的E-RAB建立尝试次数。
1.2.7ERAB承载建立成功话统
统计小区E-RAB建立成功总次数。
E-RAB建立过程一般由UE在需要向无线网络申请服务时主动发起,并通过初始UE上下文建立流程或E-RAB建立流程完成建立。
E-RAB建立尝试总次数用于统计UE发起的总的E-RAB建立成功次数。
话统统计方法
图4
如3、4中A点所示,当eNodeB收到来自MME的E-RABSETUPREQUEST或者INITIALCONTEXTSETUPREQUEST消息时统计该指标。
如果E-RABSETUPREQUEST或者INITIALCONTEXTSETUPREQUEST消息中要求同时建立多个E-RAB,则相应指标按各个业务的QCI分别进行累加。
ERABSetupSuccessRate计算公式
ErabSetupSuccessRate=(L.E-RAB.SuccEst)/(L.E-RAB.AttEst)*100%
1.2.8ERAB承载建立失败话统
统计小区内E-RAB不同原因值的建立失败次数。
E-RAB是承载用户业务数据的接入层承载,它在小区内的建立成功率,直接反映了小区为用户提供E-RAB连接建立的能力。
E-RAB建立失败统计,可以反映出网络中各种原因的E-RAB建立失败的分布情况。
1.3工具简介
(1)KPI话统记录用于统计RRC建立成功率,ERAB建立成功率,失败原因等信息(M2000,国内OMC920)。
(2)标准信令跟踪(eNBUU口跟踪、eNBS1口跟踪、eNBX2口、UEOMT信令跟踪)可以获取信令消息交互情况。
适用于进行简单问题排查(LMT或M2000,国内OMC920)。
2常见问题简单排查方法
2.1基本定位思路
接入失败通常有三大类原因:
无线侧参数配置问题、信道环境影响以及核心网侧配置问题。
因此遇到无法接入的情况,可以大致按以下步骤进行排查。
(1)通过话统分析是否出现接入成功率低的问题,当前RRC\eRAB接通率指标一般为98%,也可根据局点对接入成功率指标的特殊要求启动问题定位。
(2)确认是否全网指标恶化,如果是全网指标恶化,需要检查操作,告警,是否存在网络变动和升级行为。
(3)如果是部分站点指标恶化,拖累全网指标,需要寻找TOP站点。
(4)查询RRC连接建立和ERAB建立成功率最低的TOP10站点和TOP时间段。
(5)查看TOP站点告警,检查单板状态,RRU状态,小区状态,OM操作,配置是否异常。
(6)提取CHR日志,分析接入时的msg3的信道质量和SRS的SINR是否较差(弱覆盖),是否存在TOP用户。
(7)针对TOP站点进行针对性的标准信令跟踪、干扰检测进行分析。
(8)如果标准信令和干扰检测无异常,将一键式日志,标口跟踪,干扰检测结果返回给开发人员分析。
详细流程图如下:
图5接入问题优化流程图
2.1.1TOP小区筛选
通过M2000导出全网每日话统文件,按照(L.RRC.ConnReq.Att-L.RRC.ConnReq.Succ)次数从高到低排序,结合接入成功率,选出TOP10站点接入成功率低的小区。
按照(L.E-RAB.AttEst-L.E-RAB.SuccEst)次数从高到低排序,结合ERAB建立成功率选出TOP10ERAB建立成功率低的站点。
检查TOP小区的状态是否正常,可以在M2000上,通过MML命令“DSPCELL”能查看到小区的总体信息。
如果小区状态显示不是“正常”,可以按如下方法进行简单排查:
如果存在S1链路异常告警,请检查S1链路配置是否正确。
如果存在RSSI/RSRP通道不平衡,需要检查天馈互调干扰,
如果存在驻波告警,需要通过DSPTXBRANCH,DSPRXBRANCH查看RRU发射和接收通道状态。
如果存在小区不可用告警,需要返回主控和基带板一键式日志。
2.1.2TOP小区话统分析
通过RRC建立失败话统可以得出TOP小区RRC建立失败原因分布:
L.RRC.SetupFail.NOReply多为弱覆盖或终端异常;L.RRC.Setup.ResFail由小区资源分配失败导致。
通过ERAB建立失败原因话统可以得出得出ERAB建立失败原因分布:
L.E-RAB.FailEst.RNL的统计包含了指标L.E-RAB.FailEst.NoRadioRes、L.E-RAB.FailEst.SecurModeFail及指标L.E-RAB.FailEst.NoReply的统计情况。
初始上下文建立失败的几种现象:
1基站下发了RRC_SECUR_MODE_CMD消息,收到UE的RRC_SECUR_MODE_FAIL消息
2基站下发了RRC_SECUR_MODE_CMD消息,没有收到UE的RRC_SECUR_MODE_CMP消息
3基站下发了RRC_CONN_RECFG消息,没有收到UE的RRC_CONN_RECFG_CMP消息
4基站下发了RRC_UE_CAP_ENQUIRY消息,没有收到UE的RRC_UE_CAP_INFO消息
初始上下文建立请求消息超时,需要核心网侧配合,查看核心网侧在收到ENB传递的NASAttach消息后的处理流程。
初始上下文建立失败需要检查基站配置,查看告警,跟踪Uu口,S1口进行分析。
2.1.3TOP用户分析
通过CHR日志分析可以获取RRC建立失败和ERAB建立失败TOP用户的TMSI。
在CHR数据中,可以通过TMSI来确定是否为同一个用户,具体方法如下:
当前华为核心网TMSI分配的机制是对于同一个IMSI用户,TMSI的右起第三个byte的数据进行随机赋值,即某用户的TMSI中只有第三个字节的8bit发生变化(如AA**BBCC)就是同一用户。
如下图所示,C0**0005就是同一个用户。
使用INSIGHTSHARP工具分析同一TMSI用户的多个接入流程,查看L2_SRB_LOG字段记录的接入时上行信道质量DMRS_SINR和DMRS_RSRP,可以初步确认用户是否处于上行弱覆盖区域:
DMRS_SINR<0db或DMRS_RSRP<-131dbm可以认为终端处于弱覆盖区域。
图6CHR字段说明截图
2.1.4TOP小区跟踪
通过话统分析出TOP小区和TOP时间段后,在对应的小区和时间段,打开Uu口,S1口,X2口跟踪,查看接入流程在哪一步失败。
通过TOP用户的TMSI在核心网侧获取到IMSI,可以启动该用户的全网跟踪
2.1.5TOP小区环境干扰分析
通过频谱扫描仪功能查看下行是否存在邻区干扰、外部系统干扰等。
通过ENB小区干扰检测的性能跟踪分析是否存在上行干扰。
如存在外部干扰或邻区干扰,需要进行干扰源排查。
2.2配置类问题排查
2.2.1UE配置问题
1.华为TestUE频点配置
针对我司UE,检查频点配置是否与eNB一致,如果频点不正确,UE表现为小区搜索失败。
图7测试UE频点配置
2.E398/E392Attach类型设置
LTE核心网通常没有配置CS域的通道,只有PS域。
当E398Attach类型为CS&PScombinedattach时,就会导致只Attach了PS域,CS域一直附着失败,UE最终被释放掉。
将E398的Attach方式修改为PS_ONLY可以解决此问题。
图8Attach信令截图
3.终端规格问题
以E398s/E392u为例,只支持Band38和Band40,如果小区设置为其他频带,终端将无法接入。
另外,需要确认部分终端对无线层加密算法的支持程度,如果小区配置中使用了终端不支持算法进行加密和完整性保护,终端可能会出现接入失败。
以海思芯片为例,通过Histudio在NV项中找到UE_NET_CAPABILITY项查看加密及完整性算法。
ucEeaCap:
加解密算法。
ucEiaCap:
完整性保护算法。
高位3个Bit从高到底分别代表NULL、SNOW3G、AES算法
与协议24301中表9.9.3.34.1是一致。
1代表支持,0代表不支持。
比如上图中ucEeaCap与ucEiaCap的值都为0xe0代表NULL、SNOW3G与AES算法都支持。
如果需要更改,比如需要设置UE可支持的加密算法为AES算法,其它两种算法不支持,则可设置ucEiaCap=0x20换算成二进制为0010,表示只支持AES算法。
目前UE对三种算法都支持,所以不管在测试还是商用使用过程中,建议按照默认设置,不要更改这些值。
2.2.2ENB配置问题
1.PDCCH符号数配置问题
测试局点为了尽可能提高下行吞吐率,PDCCH通常固定1符号,但在20M带宽以下,可能出现无法接入的问题。
10M小区,PDCCH固定1符号,总共能使用的CCE个数为8个,受上下行配比约束,下行最多能用5个,而10M小区公共信令的聚合级别为8,需要8个,因此CCE资源受限所以接入不了
5M小区,PDCCH固定1符号,总共能使用的CCE个数为3,同样由于CCE资源受限接入不了
15M小区,PDCCH固定1符号,总共能使用的CCE个数为12,受上下行配比约束,下行最多能用8个,PDCCH功控开关关闭时可以接入。
图9PDCCH符号数配置
2.IPPATH配置问题
基站在完成了安全的配置与UE能力的获取后并向小区申请资源,会向TRM申请GTPU资源,如果申请资源失败则会向核心网返回初始上下文建立失败响应INIT_CONTEXT_SETUP_FAIL;原因值填写transportresourceunavailable(0);如下图所示;
跟踪如下所示:
图10初始上下文建立失败响应信令截图
在这种情况下,对照开站summary首先查看一下MML中的IPPATH是否配置正确,如果已经配置正确,则查看请初始上下文建立请求消息(INIT_CONTEXT_SETUP_REQ消息)中transportlayeraddress的信元值是否为配置的IPPATH值,如果不一样则需要确认一下是我们配置错误还是核心网填写错误。
同时查看路由信息配置是否正确,如果IPPATH正确,但路由错误,同样会出现传输资源不可用的错误信息。
如果以上都不符合则需要把IFTS打开,将跟踪发给研发人员来确认问题的原因;
图11初始上下文建立请求消息信令
3问题定位和性能优化
3.1问题定位流程详述
3.1.1UE无法驻留小区问题定位指导
以OMT跟踪的TUE信令为例,分析定位方法如下。
UE首先进行小区搜索,通过UEOMT的层间消息和关键事件消息查看是否成功驻留到小区。
OMT中出现如下消息表示用户能驻留到小区,否则为UE无法驻留到小区。
图12UEOMT关键时间跟踪消息
如果UE无法驻留到小区,通过OMT空口消息跟踪查看用户是否能收到系统消息。
(1)确认UE是否能搜索到小区。
通过OMT的层间消息跟踪察看“ID_RRC_PHY_CELL_SEARCHING_IND”消息;打开消息,usCellNumber表示UE搜索到的小区数,接下去的列表中显示了小区ID、RSRP等信息。
图13UEOMT空口消息跟踪信息
如果小区数为0或者搜索到的小区ID不是目标小区的小区ID,则说明没有搜索到小区。
Ø一般的,可能是小区覆盖太差导致的,可以通过重新选点、核查覆盖参数的方式进行排查。
Ø一般的,可能是频点等配置参数不正确导致,确认一下频点或者重新配置一下频点。
具体查看方式如下:
图14UEOMT配置窗口
(2)确认一下是否收到系统消息,判断是那条消息的问题。
RRC_MASTER_INFO_BLOCK表示MIB消息。
RRC_SIB_TYPE1、RRC_SYS_INFO为SIB消息。
图15UEOMT消息跟踪消息
(3)如果能收到系统消息,而用户没有发起MM_ATTACH_REQ。
Ø一般的,可能是用户配置了手动ATTACH模式,请修改为Auto模式,或手动进行ATTACH操作。
图16
Ø一般的,可能是小区被禁止,小区禁止信息在SIB1中,且为可选项,如果没有小区禁止信息,可认为小区未禁止。
图17协议363316.3.1中小区禁止的消息描述
Ø一般的,可能是S准则判决没通过,导致用户无法驻留到小区。
协议规定了小区驻留电平,如果用户测量到小区的信道强度一段时间内小于小区配置的驻留电平,UEL3会发起小区重选,重新选择可驻留的小区。
设置小区驻留门限是为了保障用户在小区中能正常开展业务的一个门限值,一般的,如果小区信号低于该门限值,可认为用户已经不能维持正常的业务了,即使驻留在小区也没有实际意义。
在实际系统中为了到达用户会在网络中“永存”等考虑可能会将该值设置为较低。
小区驻留门限配置可以从SIB3消息中获取,具体的查看方式如下,q-RxLevMin就是小区最小驻留电平,其单位为2dB。
示例中的最小驻留门限为-128dBm。
图18UEOMT消息跟踪
在UE接收完系统消息后,UEL3会指示UEL1进行小区RSRP的测量,L3收到L1的测量信息后进行S准则的判决。
通过UEOMT层间消息跟踪可查看UE的接收功率,具体查看方式如下,“ID_RRC_PHY_CELLSEARCH_MEAS_IND”中包含了频点、小区ID、RSRP等信息。
由于为内部接口消息,RSRP需要通过公式转换得到,具体公式如下:
实际的RSRP=上报的RSRP/256-93.3-18-{21.1,24.1,27.1,30.1,33.1,33.1}(根据带宽选择1.4M,3M,5M,10M,15M,20M),
示例中的RSRP=15038/256-93.3-18-30.1=-82dBm。
图19UEOMT消息跟踪
Ø如果RSRP不满足S门限,说明信号覆盖较差,通过选点和覆盖核查解决;
Ø如果无法重新选点考虑降低驻留门限进行测试;
Ø如果小区RSRP高于驻留门限但仍无法驻留,则请联系IOT人员协助定位。
3.1.2随机接入过程问题定位指导
随机接入过程是指UE发送Preamble到eNB收到MSG5的过程。
该过程问题定位主要通过eNB小区跟踪、eNBL1TTI跟踪、eNBUU口跟踪、UETTI跟踪、UEOMT信令跟踪、UEOMT层间消息进行对比分析。
以下为用户Attach流程中随机接入的时序图,供参考。
由于上下行调度都是eNB控制的,其下行传输的信息都没有严格的限制,一般只要满足定时器不超时即可,而UE侧上下行资源都是eNb控制,所以对UE上行发送会有严格的时序控制(ACK信息反馈是4个TTI,ULGrant到上行发PUSCH是4个TTI,SRI必须在分配的资源上发,发MSG3是收到RAR后的6、7个TTI发)。
随机接入时序图
问题1:
UE发起了Attach,而UE没有收到RAR消息;UE发起了Attach,而UE却没有发送RAR_SETUP_REQ;UE发起了Attach,而eNB没有收到MSG3消息;
1、问题确认
确认UE发起了ATTACH,通过UEOMT的空口消息进行确认。
图20
2、确认UE是否收到RAR消息,出现Macrecvrarsucc表示UE已经收到RAR消息。
图21
如果UE没有收到RAR消息,一般的,UEOMT或串口出现如下打印
1)出现RAR超时:
该信息表示UE没有收到RAR的DLGrant。
(OMT查看)
2)出现RARCRC错:
该信息表示UE收到了RAR的DLGrant,但是PDSCH出现CRC错。
(OMT查看)
3)出现RAR匹配失败,并出现超时。
该信息表明UE收到了RAR消息,但与发送的PREAMBLE信息不匹配,该信息并不包含自己的RAR信息。
UE在发送RAR消息后,会一直去盲检PDCCH。
如果有多个UE同时发起RAR信息,而eNB并不是同时调度RAR信息;或者如果UE在发Preamble的时刻有其他UE同时接入或存在RACH虚警,而eNB没有检测到该UE的Preamble信息(具体原因有很多,包括信道原因、发射功率等);或者eNB检测Preamble错误,此时就会出现RAR不匹配等信息。
(提交研发通过串口查看)
比较容易出现的是Preamble错误,而且引起Preamble错误的原因为UE位置或eNB上下行通道时延不对齐导致,该问题的典型现象为eNB检测到的PreambleID与UE实际发送的PreamleID相差1。
一般的,可以通过设置eNB接入范围规避。
如果需要进一步定位和确认问题可以通过以下方式,核对eNB和UE的TTI级信息进行进一步定位。
(1)核对UE和eNB的Preamble信息,分析eNB是否收到了UE发送的PreambleID。
具体查看方式如下:
用LAE打开UETTI跟踪文件。
查看L2->PRACH->PreambleID字段(示例中PreambleID=29,发送时刻的帧号为296,子帧号为3,下面用296.3描述帧号子帧号)。
图22UE侧TTI跟踪中RACH信息
用LAE打开eNBCELLDT跟踪文件,查看PreambleID为29的记录。
Ø如果无法查找到,则表示eNB没有检测到PreambleID。
(文件中PreambID、RID对应的值为PreambleID)。
Ø如果找到相同的PreambleID,表明eNB收到了
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- TDLTE 优化 接入
![提示](https://static.bdocx.com/images/bang_tan.gif)