问题定位指导书-接入篇2013

1、LTE TDD问题和优化指导书-接入篇名称Product name密级ity levelLTE TDD内部公开版本Product versionTotal 60pages 共60页本文介绍了用户接入的流程和用户接入失败时问题的基本方法，常见问题排查方法部分主要面向网络维护，介绍了一些常见问题的排查和方法，主要应用场景为通过KPI指标发现问题，通过CHR、告警日志、标口跟踪、UE侧log进行问题。1概念和基本原理1.1基本概念（1）用户Attach流程：UEE-NODEBRRC CONN SETUP REQRRC CONN SETUPRRC CONN SETUP CMPINITIAL UE ME

2、SSAGEINITIAL UE CONTEXT SETUP REQRRC SECURITY MODE CMDRRC SECURITY MODE CMPRRC CONN RECFGRRC CONN RECFG CMPINITIAL UE CONTEXT SETUP RSPSAEB SETUP REQRRC CONN RECFGRRC CONN RECFG CMPSAEB SETUP RSP图1用户接入流程（2）随机接入流程介绍直传过程（业务协商、流程通知）直传过程（鉴权、业务协商）MME随机接入过程的发生有以下五种场景：1、 从空闲态转到连接态的初始接入；2、 无线失败后的接入；3、 切换过程中

3、的接入；4、 当UE处于连接态时下行数据到达时因为某些原因需要随机接入，如上行失步时有下行数据到达；5、 当UE处于连接态时上行数据到达时因为某些原因需要随机接入，如上行失步时有上行行数据到达；随机接入分为竞争接入与非竞争接入两种，其中竞争随机接入适用于上述1、2、5三种场景，而非竞争随机接入适用于3、4两种场景。随机接入基本流程如下：UEeNB1Random Access PreambleUEeNBRandom Access Response2RA Preamble assignment013Scheduled TransmissionRandom Access PreambleConten

4、tion Resolution42Random Access Response图2 随机接入流程图（左：基于竞争的随机接入 右：基于非竞争的随机接入）1.2接入流程话统介绍1.2.1 随机接入话统随机接入过程分为基于竞争的随机接入和基于非竞争的随机接入两种基本过程。“RA测量(小区)(RA.Cell)”统计小区内不同随机接入过程的前导接收次数、RAR次数以及竞争过程中的 Contention Resolution次数，用于分析随机接入的负载、成功率等相关情况。1.2.2 RRC连接建立请求话统统计 eNodeB 内各小区收到的 RRC 的建立请求次数。RRC Connection Reques

5、t 消息是 UE向 eNodeB的第一条 RRC 信令消息，目的是请求建立一条 RRC 连接。1.2.3 RRC连接建立尝试话统统计小区内不同类型RRC 的建立尝试次数，即eNodeB 响应UE 的RRC Connection Request消息并下发 RRC Connection Setup 消息的次数。RRC Connection Setup 消息是 eNodeB 发送给 UE 的 RRC 信令消息，目的是通知 UE RRC 连接的建立结果及相关配置信息。1.2.4 RRC连接建立成功话统统计小区内不同类型 RRC 的建立成功次数，即 eNodeB 收到UE 的 RRC Connectio

6、n SetupComplete 的次数。RRC Connection Setup Complete 消息是 UE的 RRC 信令消息，目的是通知 eNodeB 本次 RRC 连接建立完成，并携带 NAS 信令信息以及 PLMN 的选择信息。话统统计方法图3 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

7、_Req消息。Case2：T300超时后，UE仍未收到RRC_Conn_Setup，UE重新搜网，发起初始接入，UeID是取0239的随机值或上层下发的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 Ca

8、use为“emergency”，指标L.RRC.ConnReq.Att.Emc加1。（3）如果RRC Connection Request消息信元Establishment Cause为“highPriorityAccess”，指标L.RRC.ConnReq.Att.HighPri加1。（4）如果RRC Connection Request消息信元EstablishmentCause为“mt-Access”，指标L.RRC.ConnReq.Att.Mt加1。（5）如果RRC Connection Request消息信元EstablishmentCause为“mo-Singnalling”，指标

9、L.RRC.ConnReq.Att.MoSig加1。（6）如果RRC Connection Request消息信元EstablishmentCause为“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。RRC Setup Suc

10、cess Rate计算RRCSetupSuccessRate=（L.RRC.ConnReq.Succ）/(L.RRC.ConnReq.Att)*100%1.2.5 RRC连接建立失败话统统计小区内不同原因的RRC连接建立失败的次数及总的RRC连接失败次数。RRCConnection Reject消息是eNodeB给UE的RRC信令消息，目的是通知UE本次接入过程被eNodeB拒绝。1.2.6 ERAB承载建立尝试话统统计小区E-RAB建立尝试总次数。E-RAB建立过程一般由UE在需要向无线网络申请服务时主动发起，并通过初始UE上下文建立流程或E-RAB建立流程完成建立。E-RAB建立尝试总次数

11、用于统计UE发起的总的E-RAB建立尝试次数。1.2.7 ERAB承载建立成功话统统计小区E-RAB建立成功总次数。E-RAB建立过程一般由UE在需要向无线网络申请服务时主动发起，并通过初始UE上下文建立流程或E-RAB建立流程完成建立。E-RAB建立尝试总次数用于统计UE发起的总的E-RAB建立成功次数。话统统计方法图4如3、4中A点所示，当eNodeB收到来自MME的E-RAB SETUP REQUEST或者INITIAL CONTEXTSETUP REQUEST消息时统计该指标。如果E-RAB SETUP REQUEST或者INITIAL CONTEXT SETUPREQUEST消息中要

12、求同时建立多个E-RAB，则相应指标按各个业务的QCI分别进行累加。ERAB Setup Success Rate计算公式ErabSetupSuccessRate=（L.E-RAB.SuccEst）/(L.E-RAB.AttEst)*100%1.2.8 ERAB承载建立失败话统统计小区内E-RAB不同原因值的建立失败次数。E-RAB是承载用户业务数据的接入层承载，它在小区内的建立成功率，直接反映了小区为用户提供E-RAB连接建立的能力。E-RAB建立失败统计，可以反映出网络中各种原因的E-RAB建立失败的分布情况。1.3工具简介（1）KPI话统用于统计RRC建立成功率，ERAB建立成功率，失败

13、原因等信息（M2000,国内OMC920）。（2）标准信令跟踪（eNB UU口跟踪、eNB S1口跟踪、eNB X2口、UE OMT信令跟踪）可以获取信令消息交互情况。适用于进行简单问题排查（LMT或M2000，国内OMC920）。2常见问题简单排查方法2.1基本思路接入失败通常有三大类原因：无线侧参数配置问题、信道以及网侧配置问题。因此遇到无法接入的情况，可以大致按以下步骤进行排查。（1）通过话统分析是否出现接入成功率低的问题，当前RRCeRAB接通率指标一般为98%，也可根据局点对接入成功率指标的特殊要求启动问题。（2）确认是否全网指标，如果是全网指标，需要检查操作，告警，是否存在网络变动

14、和升级行为。（3）如果是部分站点指标，拖累全网指标，需要寻找TOP站点。（4）RRC连接建立和ERAB建立成功率最低的TOP10站点和TOP时间段。（5）查看TOP站点告警，检查单板状态，RRU状态，小区状态，OM操作，配置是否异常。（6）提取CHR日志，分析接入时的msg3的信道质量和SRS的SINR是否较差（弱覆盖），是否存在TOP用户。（7）针对TOP站点进行针对性的标准信令跟踪、干扰检测进行分析。（8）如果标准信令和干扰检测无异常，将一键式日志，标口跟踪，干扰检测结果返回给开发分析。详细流程图如下：开始Y全网话统分析，是否达标？N是否全网指标？YNNTOP站点告警，操作，状态，配置是否

15、异常Y告警，操作和配置恢复后KPINNN图5 接入问题优化流程图2.1.1TOP小区筛选通过M2000导出全网话统文件，按照（L.RRC.ConnReq.Att-L.RRC.ConnReq.Succ）提交接入问题排查交付件供研发分析告警恢复，评估操作影响和升级影响恢复正常？根据CHR确认是否弱覆盖？YY根据信令跟踪确认是否终端问题，核心网问题，ENB配Y置问题YN解决问题，KPI 恢复?Y问题结束优化覆盖按照接入失败次数和接入成功率确认TOP站点检查告警，操作， 是否存在网络变动和升级操作。次数从高到低排序，结合接入成功率，选出TOP10站点接入成功率低的小区。按照（L.E-RAB.AttEs

16、t-L.E-RAB.SuccEst）次数从高到低排序，结合ERAB建立成功率选出TOP10 ERAB建立成功率低的站点。检查TOP小区的状态是否正常，可以在M2000上，通过MML命令“DSP CELL”能查看到小区的总体信息。如果小区状态显示不是“正常”，可以按如下方法进行简单排查：如果存在S1链路异常告警，请检查S1链路配置是否正确。如果存在RSSI/RSRP通道不平衡，需要检查天馈干扰，如果存在驻波告警，需要通过DSP TXBRANCH，DSP RXBRANCH查看RRU发射和接收通道状态。如果存在小区不可用告警，需要返回主控和基带板一键式日志。2.1.2TOP小区话统分析通过RRC建立

17、失败话统可以得出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_

18、MODE_FAIL消息SecurityM2下发了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

19、用户的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

20、可 以 认 为 终 端 处 于 弱 覆 盖 区 域 。图6 CHR字段说明截图2.1.4TOP小区跟踪通过话统分析出TOP小区和TOP时间段后，在对应的小区和时间段，打开Uu口，S1口，X2口跟踪，查看接入流程在哪一步失败。通过TOP用户的TMSI在网侧获取到IMSI，可以启动该用户的全网跟踪2.1.5TOP小区环境干扰分析通过频谱扫描仪功能查看下行是否存在邻区干扰、外部系统干扰等。通过ENB小区干扰检测的性能跟踪分析是否存在上行干扰。如存在外部干扰或邻区干扰，需要进行干扰源排查。2.2配置类问题排查2.2.1UE配置问题1.Test UE频点配置针对我司UE，检查频点配置是否与eNB一致，如

21、果频点不正确，UE表现为小区搜索失败。图7 测试UE频点配置2.E398/E392 Attach类型设置LTE网通常没有配置CS域的通道，只有PS域。当E398 Attach类型为CS&PS combinedattach时，就会导致只Attach了PS域，CS域一直附着失败，UE最终被掉。将E398的Attach方式修改为PS_ONLY可以解决此问题。图8 Attach信令截图3.终端规格问题以E398s/E392u为例， 只支持Band38和Band40，如果小区设置为其他频带，终端将无法接入。另外，需要确认部分终端对无线层加密算法的支持程度，如果小区配置中使用了终端不支持算法进行加

22、密和完整性保护，终端可能会出现接入失败。以海思为例，通过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算法，其它两种算法不支持，则可设置ucEiaCap0x20 换算成二进制为0010，表示只支持AES

23、算法。目前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，受上下行配比约束，下行最

24、多能用8个，PDCCH功控开关关闭时可以接入。图9 PDCCH符号数配置2.IPPATH配置问题在完成了安全的配置与UE能力的获取后并向小区申请,会向TRM申请GTPU,如果申请失败则会向网返回初始上下文建立失败响应INIT_CONTEXT_SETUP_FAIL;原因值填写transportresourceunavailable(0)；如下图所示；跟踪如下所示:图10 初始上下文建立失败响应信令截图在这种情况下,对照开站summary首先查看一下MML中的IPPATH是否配置正确,如果已经配置正确,则查看请初始上下文建立请求消息(INIT_CONTEXT_SETUP_REQ消息)中transp

25、ortlayeraddress的信元值是否为配置的IPPATH值,如果不一样则需要确认一下是我们配置错误还是网填写错误。同时查看路由信息配置是否正确，如果IPPATH正确，但路由错误，同样会出现传输不可用的错误信息。如果以上都不符合则需要把IFTS打开,将跟踪发给研发来确认问题的原因；图11 初始上下文建立请求消息信令3问题和性能优化3.1问题流程详述3.1.1UE无法驻留小区问题指导以OMT跟踪的TUE信令为例，分析方法如下。UE首先进行小区搜索，通过UE OMT的层间消息和关键消息查看是否成功驻留到小区。OMT中出现如下消息表示用户能驻留到小区，否则为UE无法驻留到小区。图12 UE OM

26、T关键时间跟踪消息如果UE无法驻留到小区，通过OMT空口消息跟踪查看用户是否能收到系统消息。（ 1 ） 确 认 UE 是 否 能 搜 索 到 小 区 。 通 过 OMT 的 层 间 消 息 跟 踪 察 看“ID_RRC_PHY_CELL_SEARCHING_IND”消息；打开消息，usCellNumber表示UE搜索到的小区数，接下去的列表中显示了小区ID、RSRP等信息。图13 UE OMT空口消息跟踪信息如果小区数为0或者搜索到的小区ID不是目标小区的小区ID，则说明没有搜索到小区。Ø一般的，可能是小区覆盖太差导致的，可以通过重新选点、核查覆盖参数的方式进行排查。Ø一般

27、的，可能是频点等配置参数不正确导致，确认一下频点或者重新配置一下频点。具体查看方式如下：图14 UE OMT配置窗口（2）确认一下是否收到系统消息，判断是那条消息的问题。RRC_MASTER_INFO_BLOCK表示MIB消息。RRC_SIB _TYPE1、RRC_SYS_INFO为SIB消息。图15 UE OMT消息跟踪消息（3）如果能收到系统消息，而用户没有发起MM_ATTACH_REQ。Ø一般的，可能是用户配置了手动ATTACH模式，请修改为Auto模式，或手动进行ATTACH操作。图16，小区信息在SIB1中，且为可选项，如果没有小Ø一般的，可能是小区被区信息，可认

28、为小区未。图17 协议36331 6.3.1中小区的消息描述Ø一般的，可能是S准则没通过，导致用户无法驻留到小区。协议规定了小区驻留电平，如果用户测量到小区的信道强度一段时间内小于小区配置的驻留电平，UE L3会发起小区重选，重新选择可驻留的小区。设置小区驻留门限是为了保障用户在小区中能正常开展业务的一个门限值，一般的，如果小区信号低于该门限值，可认为用户已经不能维持正常的业务了，即使驻留在小区也没有实际意义。在实际系统中为了到达用户会在网络中“永存”等考虑可能会将该值设置为较低。小区驻留门限配置可以从SIB3消息中获取，具体的查看方式如下，q-RxLevMin就是小区最小驻留电平，

29、其为2dB。示例中的最小驻留门限为-128dBm。图18 UE OMT消息跟踪在UE接收完系统消息后，UE L3会指示UE L1进行小区RSRP的测量，L3收到L1的测量信息后进行S准则的。通过UE OMT层间消息跟踪可查看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，10

30、M，15M，20M），示例中的RSRP =15038/256-93.3-18-30.1 = -82dBm。图19 UE OMT消息跟踪如果RSRP不满足S门限，说明信号覆盖较差，通过选点和覆盖核查解决；ØØ如果无法重新选点考虑降低驻留门限进试；Ø如果小区RSRP高于驻留门限但仍无法驻留，则请IOT协助。3.1.2随机接入过程问题指导随机接入过程是指UEPreamble到eNB收到MSG5的过程。该过程问题主要通过eNB小区跟踪、eNB L1 TTI跟踪、eNB UU口跟踪、UE TTI跟踪、UE OMT信令跟踪、UEOMT层间消息进行对比分析。以下为用户Attac

31、h流程中随机接入的时序图，供参考。由于上下行调度都是eNB控制的，其下行传输的信息都没有严格的限制，一般只要满足定时器不超时即可，而UE侧上下行资源都是eNb控制，所以对UE上行会有严格的时序控制（ACK信息反馈是4个TTI，ULGrant到上行发PUSCH是4个TTI，SRI必须在分配的上发，发MSG3是收到RAR后的6、7个TTI发）。610.1: UEPreamble610.1: eNB解到PreambleeNB处理时间，没有严格规定， 环境上常见的间隔在58个TTI内610.7: UE收到RAR消息610.7: eNBRAR消息6个TTI(或7个)，见协议36213-6.1.1611.

32、3: UEMSG3611.3: eNB收到MSG3消息eNB处理时间，没有严格规定， 一般在35个TTI内612.6: UE收到MSG4消息4个TTI，HARQ时序，见协议36213-8.3612.6: eNBMSG4UE具体处理时延有关和SRI分配有关， 没有严格规定613.0: UEACK信息613.0:eNB收到ACK信息613.7:UESRI请求613.7:eNB收到SRI请求eNB处理时间，没有严格规定，614.0:UE收到ulgrant4个TTI，HARQ时序，见协议36213-8.4614.0:eNB下发ulgrant614.4:UEPUSCH614.4:eNB在PUSCH解到数

33、据（MSG5）（MSG5）备注：由于上下行调度都是eNB控制的，其下行传输的信息都没有严格的限制，一般只要满足定时器不超时即可，而UE测上下行都是eNb控制，所以对UE上行会有严格的时序控制（ACK信息反馈是4个TTI，Ulgrant到上行发PUSCH是4个TTI，SRI必须在分配的TTI发）上发，发MSG3是收到RAR后的6、7个随机接入时序图问题1：UE发起了Attach，而UE没有收到RAR消息；UE发起了Attach，而UE却没有发送RAR_SETUP_REQ；UE发起了Attach，而eNB没有收到MSG3消息；1、问题确认确认UE发起了ATTACH，通过UE OMT的空口消息进行确

34、认。图202、确认UE是否收到RAR消息，出现Mac recv rar succ表示UE已经收到RAR消息。图21如果UE没有收到RAR消息，一般的，UE OMT或串口出现如下打印1）出现RAR超时：该信息表示UE没有收到RAR的DL Grant。（OMT查看）2）出现RAR CRC错：该信息表示UE收到了RAR的DL Grant，但是PDSCH出现CRC错。（OMT查看）3）出现RAR匹配失败，并出现超时。该信息表明UE收到了RAR消息，但与的PREAMBLE信息不匹配，该信息并不包含自己的RAR信息。UE在RAR消息后，会一直去盲检PDCCH。如果有多个UE同时发起RAR信息，而eNB并不

35、是同时调度RAR信息；或者如果UE在发Preamble的时刻有其他UE同时接入或存在RACH虚警，而eNB没有检测到该UE的Preamble信息（具体原因有很多，包括信等）；或者eNB检测Preamble错误，此时就会出现RAR不匹配道原因、等信息。（提交研发通过串口查看）比较容易出现的是Preamble错误，而且引起Preamble错误的原因为UE位置或eNB上下行通道时延不对齐导致，该问题的典型现象为eNB检测到的Preamble ID与UE实际的Preamle ID相差1。一般的，可以通过设置eNB接入范围规避。如果需要进一步和确认问题可以通过以下方式，核对eNB和UE的TTI级信息进行

36、进一步。（1）核对UE和eNB的Preamble信息，分析eNB是否收到了UE的Preamble ID。具体查看方式如下：用LAE打开UE TTI跟踪文件。查看L2->PRACH->PreambleID字段（示例中PreambleID=29，时刻的帧号为296，子帧号为3，下面用296.3描述帧号子帧号）。图22 UE侧TTI跟踪中RACH信息用LAE打开eNB CELL DT跟踪文件，查看PreambleID为29的。Ø如果无法查找到，则表示eNB没有检测到PreambleID。（文件中PreambID、RID对应的值为PreambleID）。Ø如果找到相同的

37、PreambleID，表明eNB收到了UE的Preamble。如果帧号子帧号不匹配，说明这个不是正确的。如果eNB没有收到Preamble ID，。Ø确认UE是否正常。核对PRACH配置是否正确。Ø（2）核对eNB和UE的RAR消息，分析UE是否收到eNB的RAR消息。用LAE打开CELL DT跟踪文件，查看PreambleID为29的RAR：Ø通过LAE分析UE TTI跟踪：n 如果UE检测到RA-RNTI加扰的PDSCH且TTI与eNB侧相对应，表明UE收到了RAR消息。示例中RAR TTI为296.9。图23 UE下行接收RAR消息信息n如果UE没有收到RA

38、R消息则通过UE TTI跟踪的测量信息进行进一步分析：u 在UE接收RAR消息前，TTI 跟踪没有相关测量值，无法进一步分析是什么原因导致无法收到RAR消息。（3）核对UE和eNB MSG3消息，确认eNB是否收到UE的MSG3消息。首先，通过UE OMT跟踪可以确认UEMSG3（RRC_CONN_REQ）。该信息表明了UE L3已经了MSG3，但并不表明UE L1确实已经将消息给了eNB，例如：最常见的，如果UE没有接到UL GRANT，UE就无法MSG3。可以通过UE TTI跟踪进行进一步分析。UE在RACH后第1次上行PUSCH传输的数据就是MSG3消息，且Msg3是TmpC-RNTI加

39、扰的。可以从UE TTI跟踪观察到492.7上了Tmp C-RNTI加扰的PUSCH:图24 UE L1 TTI上行跟踪信息eNB侧查看是否收到Msg3：eNB一般在RAR后的10个TTI内收到MSG3消息。n如果MSG3 CRC错误，可以比对一下MSG3的调度信息：u ENB的信息包括：RB0_RB1_Num（RB位置、RB数），Modu（调制方式），SRS（存在SRS指示）。u UE侧信息包括：Prb0/Prb1（RB位置），RbNum（RB数），调制方式，CellSrs/UESrs（存在SRS指示）n如果MSG3 CRC错误，通过测量值判断是否是由于SINR低导致eNB无法解调：u 如果

40、SINR低于-2dB，可认为已经低于解调门限。u 如果RSRP低于-130dBm，可认为接收功率接近低噪。u 如果RSRP值-SINR明显高于低噪（-130dBm）可认为干扰较大。（4）核对eNB和UE MSG4消息，确认UE是否收到MSG4消息：1、确认eNB下发了MSG4消息首先通过LMT UU口跟踪可以查看L3是否了MSG4，具体查看方式如下：在UU口跟 踪 中 如 果 eNB 收到 MSG3 （ RRC_CONN_REQ ） 消 息 后 ， 是 否了 MSG4（RRC_CONN_SETUP）。图25对于MSG4为信令，在系统中其调度优先级比较高，在通常情况下LMT上观察到MSG4，就可

41、以认为eNB已经给了UE。当然，还可以通过以下方式确认MSG4是否被调度：Ø 通过 LAE 打开 eNB IFTS 跟 踪 ， 查 看 TB0_RRC Message Type 字段为 RRC_CONN_SETUP的。如下图所示eNB在299.5调度了Msg4。图26 ENB L2 TTI下行跟踪信息n如果eNB没有下发MSG4消息，通过eNB CHR信息分析具体原因，建议交由研发进行分析。2、确认UE收到了MSG4：Ø 方法1：通过UE OMT查看UE是否收到MSG4（RRC_CONN_SETUP）。示例如下。图27 MSG4指示n 如果UE没有收到MSG4可以通过TTI

42、跟踪确认是否是PDCCH检测不到，还是PDSCH CRC错误导致。通过UE的TTI跟踪进行核对。一般的，RAR消息后的第1个PDSCH为MSG4调度，时刻点在收到RAR消息的20ms内。如果在收到RAR消息较长时间内没有解到PDCCH，可认为UE没有检测到PDCCH。ü如果UE没有收到PDCCH，可根据的RSRP、SINR、频偏等测量量以及CCE个数等调度信息分析PDCCH漏检。u 一般的，10M、20M带宽下信令消息的PDCCH固定采用CCE个数为4进行调度，PDSCH采用MCS=1阶调度。一般的，当SINR小于-5可认为低于PDCCH（CCE=4）的解调门限。u 一般的，如果RS

43、RP-SINR明显高于UE底噪（-124dBm），可认为干扰较大。ü如果UE收到PDCCH，可根据UE TTI跟踪查看PUSCH CRC校验结果。下面的示例中表示UE在299.5接收到Msg4消息，且CRC正确。图28 UE TTI下行跟踪信息Ø方法2：通过eNB侧的控制信道PUCCH的上的ACK反馈信息进行分析。协议规定eNB下发PDSCH，UE需要在4个TTI后（TDD反馈方式参看协议36.213）反馈ACK信息，如果UE正确解到PDSCH，反馈ACK；如果解调错误则反馈NACK。而ACK有两种方式传送，一种是随路，也就是在PUSCH上传输；一种是PUCCH。n一般的，

44、如果反馈的为DTX，且ACKPWR接近低噪（-130dBm）或、ACKSINR为-10dB或更低，可认为UE没有收到PDCCH。注：ACKPwr为PUCCH RB导频上的总功率，由于PUCCH RB可能为多用户码分复用，所以可能出现ACK PWR功率较高，但SINR很低的情况，所以这里描述的在单用户情况下有效。n一般的，如果反馈的结果为NACK，可认为UE PDSCH CRC错误。u PDSCH CRC错误时，根据UE测量信息分析原因，如果SINR低于解调能力，l排查是否是在小区边界，导致接收信号功率过低l排查是否存在邻区干扰以下表示eNB在300.2收到PUCCH上反馈的ACK。根据协议36

45、.213，bundling模式下299.5的ACK应该在300.2反馈。图29 PUCCH的ACK反馈3、核对UE和eNB MSG5消息，确认eNB是否收到MSG5消息。1）确认UE L3是否了MSG5消息。通过OMT空口信令跟踪，查看UE是否了MSG5（RRC_CONN_SETUP_CMP），如果界面显示有MSG5消息，但并不表示UE已经了MSG5给eNB。这是因为MSG5为第1条上行动态调度，需要向eNBSRI请求，ENB收到SRI后才会给UE调度。如果开了预调度，也有可能不SRI。以下是预调度关闭的分析，预调度打开时可能没有SRI。图30 MSG5指示2） 确认UE是否了SRI请求。通过

46、UE L1 TTI上行跟踪的SRI是否为“有”。下例所示，UE在300.3了SRI请求。图31 UE L1 TTI上行跟踪3） 确认eNB是否收到了SRI请求。通过eNB L1 TTI上行跟踪观察检测到收到SRI跟踪，如下例所示，eNB在300.3中检测到了SRI说明eNB收到了SRI请求。图32 eNB L1 TTI跟踪4）确认eNB是否进行了上行调度。通过eNB L1 TTI下行跟踪观察是否了ULGRANT，或者通过eNB L1 TTI上行跟踪观察上行调度结果。协议规定ENB下发ULGANT后，UE会在4个TTI后（TDD为4个TTI后第一个上行TTI）在PUSCH上UL GRANT的时刻

47、和上行跟踪的PUSCH传信息。所以下行跟踪的调度信息会相差4个TTI。，eNB在300.6调度了UL Grant：图33 eNB UL Grant指示5）确认UE是否收到了UL GRANT，并正确了PUSCH。UE TTI上下行跟踪可以看到UE是否解到了UL GRANT和了PUSCH，协议规定UE在收到UL Grant的4TTI（TDD为4个TTI后第一个上行子帧）后上行PUSCH，所以UL Grant和上行PUSCH跟踪信息会相差4个TTI。，UE在300.6收到了UL Grant：图34 UE UL Grant接收指示6）确认eNB是否收到MSG5，通过eNB上行TTI跟踪分析上行接收情况

48、，示例所示301.2收到了PUSCH，并且CRC正确：图35 上行PUSCH接收Ø 如果上行调度CRC错误，可通过调度信息、DMRS测量、SRS测量等信息进行分析。n一般的，如果DMRS Rsrp（子载波级的eNB接收功率，）接近低噪（-130dBm），说明接收功率很低。u一般的，需要通过UE功率和UE路损推算接收到的RSRP是否合理。UE可以这样估算：Pwr = P0 + alpha * 下行PL + f(i) +10logM。其中P0、Alpha可通过系统消息获取、PL可通过路损计算得到（PL=RS-下行RSRP），系统f（i）=-1，M为调度的RB个数。如果计算得到的Pwr大于

49、UE最大，则Pwr=Ue最大。ENB接收功率RSRP=Pwr 10log(12*M) 上行PL。一般的，如果RSRP-SINR明显高于低噪，说明有较大干扰。请排查环境u是否存在干扰源或其他干扰因素。u 般的， 如果下行RSRP 为中近点， 而上行接收的RSRP 接近底噪（-130dBm），可能为UE没有数据，如果UE跟踪显示UE发了数据，可以分析一下UE和eNB的配置（RB位置和RB数等配置信息）。一般的，还可以分析一下SRS测量得到的TA是否合理。如果MCS阶数很u高，而TA提前，比较容易造成CRC错误。3.1.3安全模式、RB重配问题指导MME无响应或MME主动发起的造成的用户一般是发起I

50、NIT_UE_MSG后,等待网的初始上下文建立请求消息超时(即网没有下发初始上下文请求消息),然后由主动发起的用户, 在这种情况下需要跟核心网侧维护确认一下为什么没有发起初始上下文建立请求消息；另一种情况是发起INIT_UE_MSG后,网立即下发了消息UE_CONTEXT_REL_CMD,在这种情况下,首先确认一下INIT_UE_MSG中的PLMNID与侧的配置是否一致,如果不一致,需要重新配置后再接入；如果已经一致,则需要跟网侧维护确认一下网下发消息的原因；具体显示的跟踪样例如下所示:图36 信令跟踪样例UE无响应造成用户一般UE无响应造成的有四种情况:1、下发了RRC_CONN_SETUP

51、消息没有收到UE的RRC_CONN_SETUP_CMP消息;2、下发了RRC_SECUR_MODE_CMD消息没有收到UE的RRC_SECUR_MODE_CMP消息;3、下发了RRC_UE_CAP_ENQUIRY消息没有收到UE的RRC_UE_CAP_INFO消息;4、下发了RRC_CONN_RECFG消息没有收到UE的RRC_CONN_RECFG_CMP消息;因为第一种情况正处于RRC连接建立状态,所以不需要回网响应,其它三种情况都需要回网初始上下文建立失败响应(即消息INIT_CONTEXT_SETUP_FAIL);在发生了上述四种情况后,需要在UE那里确认一下侧下发的这条消息(比如RRC

52、_CONN_SETUP)UE的跟踪上是否收到,如果没有收到,则需要查一下发出的这条消息在的L2处是否收到并下发给了UE,并查看一下发出的这条消息UE的L2是否收到并传递给了UE的L3;如果UE的L3收到了这条消息,则需要查看一下UE是否发出响应的消息(比如RRC_CONN_SETUP_CMP);跟踪样例如下所示:图37 信令跟踪样例上图是因为没有收到UE的RRC_SECUR_MODE_CMP消息导致超时造成的用户;无线申请失败导致用户在完成了安全的配置与UE能力的获取后会向小区申请,如果申请失败,则会向网返回初始上下文建立失败响应INIT_CONTEXT_SETUP_FAIL;原因值一般会填写

53、radioresource not available(25);如下图所示;在这种情况下,一般都是向小区申请失败导致的初始上下文建立失败;一般可以先导出MML的参数配置,然后与默认参数进行对比,查看一下是否一些与小区相关的参数配置错误（可以与基线比较，参数相关参见基线参数配置，参数基线可以从随版本发布的文档包获取）,如果参数没有问题,则请把IFTS打开,将跟踪反馈给研发确认问题的原因；跟踪如下所示:图38 信令跟踪样例GTPU申请失败在完成了安全的配置与UE能力的获取后并向小区申请,会向TRM申请GTPU,如果申请失败则会向网返回初始上下文建立失败响应INIT_CONTEXT_SETUP_FAIL;原因值一般会填写transportresourceunavailable(0);如下图所示;跟踪如下所示:图39 信令跟踪样例在这种情况下,首先查看一下MML中的IPPATH是否配置正确,如果已经配置正确,则查看请初始上下文建立请求消息(INIT_CONTEXT_SETUP_REQ消息)中tra