9 LONAST3022C011 TDLTE接入问题分析.docx
《9 LONAST3022C011 TDLTE接入问题分析.docx》由会员分享，可在线阅读，更多相关《9 LONAST3022C011 TDLTE接入问题分析.docx（23页珍藏版）》请在冰豆网上搜索。
9LONAST3022C011TDLTE接入问题分析
TD-LTE接入问题分析
课程目标：
●掌握LTE随机接入基本过程
●理解LTE随机接入主要参数
●理解PRACH信道规划思路
●掌握一般接入问题的分析思路
●掌握常见接入故障的解决方法
目录
第1章初始接入概述1
1.1初始接入信令流程1
1.2随机接入信令IE查看3
第2章接通率分析思路6
2.1随机接入问题分析6
2.1.1MSG1发送后是否收到MSG28
2.1.2MSG3是否发送成功9
2.1.3MSG4是否正确接收9
2.2鉴权、加密问题分析10
2.3E-RAB建立问题分析10
第3章接入问题案例解析11
3.1MSG1多次重发未响应11
3.1.1问题现象11
3.1.2问题分析和解决12
3.1.3总结16
3.2MSG4冲突检测定时器超时17
3.2.1问题现象17
3.2.2问题分析19
3.2.3解决方法和验证24
图目录
图11初始接入信令流程图1
图12SIB2rach_Config3
图13SIB2Prach_Config4
图14CNT中msg1截图5
图21接通率分析思路6
图22基于竞争的随机接入7
图23MSG1分析思路8
图24MSG4fail分析思路10
图31MSG1多次发送未响应11
图32MSG1无响应时的RSRP12
图34msg4fail（QCAT）19
图35msg4failcause（QCAT）20
图36正常起呼随机接入过程（QCAT）20
图37正常起呼PDCCHdecodingResult（QCAT）21
图38正常起呼PDSCH统计（QCAT）21
图39多次PDCCH未收到PDSCH（QCAT）21
图310UE收到第一次PDCCH的解码（QCAT）22
图311UE收到第二次PDCCH的解码（QCAT）22
图312UE未收到PDSCH（QCAT）23
图313UE未收到PDCCH的消息流程（QCAT）23
图314UE未收到PDSCH（QCAT）24
图315第一次msg4fail，随机接入重发后接入成功（QCAT）24
图316随机接入重发后收到PDSCH（QCAT）25
图317第二次msg4fail，随机接入重发后接入成功（QCAT）25
表目录
表31修改PRACH检测门限后的接通率12
表32短呼接通率统计17
表33未接通呼叫分析18
表34解码重传PDCCH的MCS为2922
第一章初始接入概述
在TD-LTE系统中，处于Inactive状态或IDLE状态的UE通过发起attachrequest或ServiceRequest触发初始随机接入，建立RRC连接，再通过初始直传建立传输NAS消息的信令连接，最后建立E-RAB。
一.1初始接入信令流程
初始接入信令流程如图11所示。
消息1～5随机接入过程，建立RRC连接。
消息6~9初始直传建立S1连接，完成这些过程即标志着NASsignallingconnection建立完成，见24.301。
消息10~12UECapabilityEnquiry过程。
消息13~14安全模式控制过程。
消息15~17RRCConnectionReconfiguation，E-RAB建立过程。
关于信令内容详解，参见文档《TD-LTE基本信令流程》
图11初始接入信令流程图
一.2随机接入信令IE查看
在LTE系统中，随机接入过程直接影响接入时延，以下着重介绍PRACH相关信元的查看。
随机接入开始之前需要对接入参数进行初始化，此时物理层接受来自高层的参数、随机接入信道的参数以及产生前导序列的参数，UE通过广播信息获取PRACH的基本配置信息。
RACH所需的信息在SIB2的公共无线资源配制信息（radioResourceConfigCommon）发送，如图1-2，图1-3所示：
图12SIB2rach_Config
图13SIB2Prach_Config
主要包含以下参数信息：
主要包含以下参数信息
●基于竞争的随机接入前导的签名个数60；可用前导个数
●GroupA中前导签名个数56；中心用户可用的前导个数
●PRACH的功率攀升步长POWER_RAMP_STEP2dB。
●PRACH初始前缀目标接收功率PREAMBLE_INITIAL_RECEIVED_TARGET_POWER：
-110dBm；基站侧期望接收到的PRACH功率
●PRACH前缀重传的最大次数PREAMBLE_TRANS_MAX8；
●随机接入响应窗口RA-ResponseWindowSize索引值7，范围{2、3、4、5、6、7、8、10}，索引值7对应10sf,即UE发送Msg1后,等待Msg2的时间10ms,超时后重发。
●MAC冲突解决定时器MACContentionResolutionTimer：
索引值7对应64sf，范围{2、3、4、5、6、7、8、10}；即UE发送Msg3,等待Msg4的时间64ms,超时后随机接入失败。
●MSG3HARQ的最大发送次数：
maxHARQ-Msg3Tx3；即UE发送Msg3,如果没收到ACK,重发Msg3,同时重启MAC冲突解决定时器。
●本小区的逻辑根序列索引rootSequenceIndex80，该参数为规划参数；
●随机接入前缀的发送配置索引PrachConfigIndex6；
●循环移位的索引参数zeroCorrelationZoneconfig4；
UE获取PRACH相关配置后，发起随机接入，在MSG1消息里可以检验UE是否按照系统消息携带的参数进行随机接入，如图1-4所示：
图14CNT中msg1截图
根据小区下发的PRACHconfig，UE采用随机接入前导序列为49，根序列为649进行接入。
可以看到UE采用前导序列format0，随机接入请求在系统帧907\子帧2上发送，随机接入响应的接收窗从SFN\SF：
907\5到SFN\SF：
908\5，窗长为10ms，与“随机接入响应窗口RA-ResponseWindowSize”配置10sf一致。
第二章接通率分析思路
根据初始接入的信令流程分解UE接入过程为三个阶段：
RRC建立过程，初始直传和安全模式控制，E-RAB建立过程。
目前用户量较少E-RAB建立几乎没有失败的现象，而随机接入过程出现的问题较多，导致RRC连接无响应，引起起呼失败，所以解决随机接入失败问题是当前提升接通率的关键。
图21接通率分析思路
二.1随机接入问题分析
随机接入分为基于冲突的随机接入和基于非冲突的随机接入两个流程，其区别为针对两种流程其选择随机接入前缀的方式。
前者为UE从基于冲突的随机接入前缀中依照一定算法随机选择一个随机前缀；后者是基站侧通过下行专用信令给UE指派非冲突的随机接入前缀。
初始接入采用基于竞争的随机接入，切换采用非竞争的随机接入。
图22基于竞争的随机接入
（1）MSG1：
UE在PRACH上发送随机接入前缀；
（2）MSG2：
ENB的MAC层产生随机接入响应，并在PDSCH上发送；
（3）MSG3：
UE的RRC层产生RRCConnectionRequest并映射到PUSCH上发送；
（4）MSG4：
RRCConnectionSetup由ENB的RRC层产生，并映射到PDSCH上发送。
至此，基于竞争的随机接入冲突解决完成，UE的RRC层生成RRCConnectionSetupComplete并发往eNB。
从前台UE侧角度分析随机接入失败发生的阶段：
1.MSG1发送后是否收到MSG2；
2.MSG3是否发送成功；
3.MSG4是否正确接收。
二.1.1MSG1发送后是否收到MSG2
图23MSG1分析思路
UE发出MSG1后未收到MSG2，UE按照Prach发送周期对MSG1进行重发。
若收不到MSG2的PDCCH，可分别对上行和下行进行分析：
上行：
1.结合后台MTS的PRACH信道收包情况，确认上行是否收到MSG1。
2.检查MTS上行通道的接收功率是否>-99dBm，若持续超过-99dBm，解决上行干扰问题，比如是否存在GPS交叉时隙干扰。
3.PRACH相关参数调整：
提高PRACH期望接收功率，增大PRACH的功率攀升步长，降低PRACH绝对前缀的检测门限。
下行：
1.UE侧收不到以RA_RNTI加扰的PDCCH，检查下行RSRP是否>-119dBm，SINR>-3dB，下行覆盖问题通过调整工程参数、RS功率、PCI等改善。
2.PDCCH相关参数调整：
比如增大公共空间CCE聚合度初始值。
二.1.2MSG3是否发送成功
根据随机接入流程，UE收到MSG2后若没有发出MSG3，检查MSG2带的授权信息是否正确；若UE已发出MSG3的PUSCH，结合基站侧信令查看EnodeB是否收到到RRCConnectionRequest，若基站侧已发出RRCConnectionSetup前台未收到，如2.1.3节MSG4过程分析；若基站侧RRCConnectionRequest未收到，说明上行存在问题；
1.检查MTS上行通道的接收功率是否>-99dBm，若持续超过-99dBm，解决上行干扰问题。
2.检查RAR中携带的MSG3功率参数是否合适，调整MSG3发送的功率。
二.1.3MSG4是否正确接收
在随机接入过程中出现MSG4fail，失败原因是failureatMSG4duetoCTtimerexpired。
CTtimer即冲突检测定时器，UE发出MSG3后开启CTtimer等待冲突解决Msg4，若定时器到期时仍未收到msg4触发随机接入失败。
该问题的分析思路如下图：
图24MSG4fail分析思路
1.UE是否收到PDCCH，若没有收到PDCCH，从下行信号分析及参数两方面解决解决PDCCH接收问题。
2.多次收到PDCCH后是否收到PDSCH？
（1）确认收到的PDCCH是否重传消息，检查重传消息的DCI格式填写是否正确；
（2）PDSCH收不到，检查PDSCH采用的MCS，检查PA参数配置，适当增大PDSCH的RB分配数。
二.2鉴权、加密问题分析
暂无
二.3E-RAB建立问题分析
目前无E-RAB失败现象，待后续补充。
第三章接入问题案例解析
三.1MSG1多次重发未响应
三.1.1问题现象
短呼测试中出现UE发出attachreq和RRCConnectionRequest后未收到RRCConnectionSetup，造成呼叫未接通。
查看路测信令，如图3-1所示，在小区PCI11，8次msg1发送未收到MSG2，检查后台告警此时无GPS失锁告警。
图31MSG1多次发送未响应
图32MSG1无响应时的RSRP
三.1.2问题分析和解决
下行RSRP为-91dBm，接收电平良好，MSG1发送了8次，均未收到MSG2。
通过降低“eNodeB对PRACH的绝对前缀检测门限”，提高PRACH信号的检查概率，提升MSG1正确解调的概率。
参数：
eNodeB对PRACH的绝对前缀检测门限
PRACHAbsolutePreambleThresholdforEnodeBDetectingPreamble
取值范围：
1-65535
单位：
线性值
缺省值：
2000
将“eNodeB对PRACH的绝对前缀检测门限”从2000改为50，修改后进行短呼测试，RRCConnectSuccess为100%。
在小区PCI11，从MSG1发送的间隔上观察，再未出现MSG1重发无响应的现象。
表31修改PRACH检测门限后的接通率
ID
KPIType
Correspond
Attempt
Ratio（%）
1
RandomAccessSuccess[%]
110
110
100
2
RRCConnectSuccess[%]
34
34
100
3
InitialAccessSuccess[%]
31
31
100
4
E-RABConnectSuccess[%]
71
71
100
三.1.3总结
MSG1多次重发无响应造成的起呼失败，在排除无GPS干扰的前提下，通过降低“eNodeB对PRACH的绝对前缀检测门限”，提高PRACH检测概率，解决未接通。
三.2MSG4冲突检测定时器超时
三.2.1问题现象
10月中旬对FT区域进行50%模拟加载下的短呼性能摸底测试，路测发现前台偶尔收不到MSG4，导致接通失败。
核对NodeB侧信令发现后台已经下发了RRC层消息RRCConectionSetup，但是未收到RRCConectionSetupComplete。
例如10月14日的数据如下：
表32短呼接通率统计
KPIType
Correspond
Attempt
Ratio（%）
RandomAccessSuccess[%]
412
419
98.33%
RRCConnectSuccess[%]
198
204
97.06%
InitialAccessSuccess[%]
140
147
95.24%
一共发生了7次随机接入失败，其中6次发生在起呼阶段，影响接通率指标（红色字发生在呼叫保持阶段）。
表33未接通呼叫分析
Time
Event
Action
cause
Comment
16:
54:
39:
656
Randomaccessfail
F
RRCconnection无响应
PCI11，后台信令已发setup，前台未收到。
16:
54:
49:
734
Randomaccessfail
F
RRCconnection无响应
PCI11rsrp-91，sinr-9.8。
后台信令已发setup，前台未收到。
18:
07:
06:
234
Randomaccessfail
F
RRCreestablishment无响应
4到46切换失败，在PCI34小区进行RRC连接重建，SINR-11.6，未收到RRC连接重建。
18:
13:
06:
328
Randomaccessfail
F
RRCconnection无响应
PCI38没收到RRC连接建立。
后台发setup，1s后RRCrelease.
18:
13:
16:
640
Randomaccessfail
F
RRCconnection无响应
PCI38没收到RRC连接建立。
后台发setup，1s后RRCrelease。
18:
14:
24:
453
Randomaccessfail
F
RRCconnection无响应
PCI46没收到RRC连接建立。
SINR-15.6，RSRP-99。
后台发setup，1s后RRCrelease。
18:
14:
34:
687
Randomaccessfail
F
RRCconnection无响应
PCI46没收到RRC连接建立。
后台发setup，1s后RRCrelease。
三.2.2问题分析
通过大量短呼测试，RRC连接无响应均为msg4fail，失败原因：
failureatMSG4duetoCTtimerexpired。
图34msg4fail（QCAT）
图35msg4failcause（QCAT）
MSG4CTTimer超时主要有两种情况：
1.UE发出MSG3后收到多次PDCCH但未收到PDSCH；2.UE发出MSG3后未收到PDCCH。
正常接通的信令如下：
图36正常起呼随机接入过程（QCAT）
图37正常起呼PDCCHdecodingResult（QCAT）
图38正常起呼PDSCH统计（QCAT）
三.2.2.1多次PDCCH未收到PDSCH
前台Time:
07:
19:
32.621，cell:
PCI28，msg4CT定时器超时。
RSRP：
-88.25dBm,SINR：
-4.9dB。
图39多次PDCCH未收到PDSCH（QCAT）
msg3的SFN\SF：
879\7，msg4第一次PDCCH的SFN\SF：
882\9，间隔32ms；第二次PDCCH的SFN\SF:
884\1，间隔12ms，可以看到两次PDCCH均正确接收。
但是从PDSCH统计中没有看到MSG4的接收信息，基站侧信令显示RRCsetup消息已发出。
解码UE收到的两次PDCCH的payload，MCS均为29，说明UE收到的PDCCH均为重传。
图310UE收到第一次PDCCH的解码（QCAT）
图311UE收到第二次PDCCH的解码（QCAT）
表34解码重传PDCCH的MCS为29
16进数
dci-format
lvrb-dvrb
RB分配
MCS
0x88BFD04800000000
1
0
0010001011111
11101（29）
0x8899D06800000000
1
0
0010001001100
11101（29）
D028********
1
0
0010001110100
11101
（29）
图312UE未收到PDSCH（QCAT）
三.2.2.2Msg3后未收到PDCCH
UE起呼在PCI30，RSRP：
-91.06dBm，SINR：
-4.7dB。
三次随机接入均没有收到PDCCH，最终起呼失败。
在PDSCH统计中也没有看到以Temp-CRNTI加扰的PDSCH，说明UE没有收到msg4的调度信息，进而收不到MSG4。
图313UE未收到PDCCH的消息流程（QCAT）
图314UE未收到PDSCH（QCAT）
三.2.3解决方法和验证
MAG4CTTimer超时，无论是MSG4的PDCCH收不到还是MSG4的PDSCH收不到，均为下行无线信道质量较差引起的。
通过以下组合手段改善下行数据的接收：
1）将MACContentionResolutionTimer由48sf改为64sf，增加UE接收MSG4PDCCH的概率。
2）将PDCCHCCE聚合度初始值由自适应调整改为固定CCE聚合度4，增大PDCCH正确解调的概率。
3）将PDCCHDCI1A格式的功率由0dB修改为3dB，增大UE正确解调PDCCH的概率。
修改完毕后，11月4日在原路段进行短呼测试。
整个测试过程未出现接通失败，虽然出现两次msg4fail，但经过随机接入重发，最终起呼成功。
图315第一次msg4fail，随机接入重发后接入成功（QCAT）
图316随机接入重发后收到PDSCH（QCAT）
图317第二次msg4fail，随机接入重发后接入成功（QCAT）
升级会员 