TDLTE优化-接入

1、内部公开confidentiality levelTDLTE接入性能优化2014-01-21华为机密，未经许可不得扩散第2页,共49页Page 2 , Total49本文介绍了用户接入的流程和用户接入失败时问题定位的基本方法，常见问题排查方法部分主要面向网络维护人员，介绍了一些常见问题的定位排查手段和方法，主要应用场景为通过KPI指标发现问题，通过CHR、告警日志、标口跟踪、UE侧log进行问题定位。1 概念和基本原理1.1 基本概念（1）用户Attach流程：图1 用户接入流程（2）随机接入流程介绍随机接入过程的发生有以下五种场景：1、 从空闲态转到连接态的初始接入；2、 无线链接失败后的接

2、入；3、 切换过程中的接入；4、 当UE处于连接态时下行数据到达时因为某些原因需要随机接入，如上行失步时有下行数据到达；5、 当UE处于连接态时上行数据到达时因为某些原因需要随机接入，如上行失步时有上行行数据到达；随机接入分为竞争接入与非竞争接入两种，其中竞争随机接入适用于上述1、2、5三种场景，而非竞争随机接入适用于3、4两种场景。随机接入基本流程如下：图2 随机接入流程图（左：基于竞争的随机接入 右：基于非竞争的随机接入）1.2 接入流程话统介绍1.2.1 随机接入话统随机接入过程分为基于竞争的随机接入和基于非竞争的随机接入两种基本过程。“RA测量(小区)(RA.Cell)”统计小区内不同

3、随机接入过程的前导接收次数、RAR发送次数以及竞争过程中的Contention Resolution发送次数，用于分析随机接入的负载、成功率等相关情况。1.2.2 RRC连接建立请求话统统计eNodeB内各小区收到的RRC的建立请求次数。RRC Connection Request消息是UE向eNodeB发送的第一条RRC信令消息，目的是请求建立一条RRC连接。1.2.3 RRC连接建立尝试话统统计小区内不同类型RRC的建立尝试次数，即eNodeB响应UE的RRC Connection Request消息并下发RRC Connection Setup消息的次数。RRC Connection S

4、etup消息是eNodeB发送给UE的RRC信令消息，目的是通知UE RRC连接的建立结果及相关配置信息。1.2.4 RRC连接建立成功话统统计小区内不同类型RRC的建立成功次数，即eNodeB收到UE的RRC Connection Setup Complete的次数。RRC Connection Setup Complete消息是UE发送的RRC信令消息，目的是通知eNodeB本次RRC连接建立完成，并携带NAS信令信息以及PLMN的选择信息。话统统计方法图3 RRC建立统计点【A点】（1）指标L.RRC.ConnReq.Att加1，不统计重发的次数。Case1：eNB下发RRC_Conn_

5、Setup消息后，在T300定时器超时前，收到相同的UeID发起的RRC_Conn_Req（Setup丢失，UE MAC冲突解决定时器超时后重发RRC_Conn_Req，UeID不变），记为一次重发RRC_Conn_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会在定时器超时后重新发起At

6、tach，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 Ca

7、use为“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消息给U

8、E时，指标L.RRC.ConnSetup加1。【C点】当eNodeB收到UE返回的RRC Connection Setup Complete消息时统计相应指标，L.RRC.ConnReq.Succ加1。RRC Setup Success Rate计算RRCSetupSuccessRate=（L.RRC.ConnReq.Succ）/(L.RRC.ConnReq.Att)*100%1.2.5 RRC连接建立失败话统统计小区内不同原因的RRC连接建立失败的次数及总的RRC连接失败次数。RRC Connection Reject消息是eNodeB发送给UE的RRC信令消息，目的是通知UE本次接入过程被

9、eNodeB拒绝。1.2.6 ERAB承载建立尝试话统统计小区E-RAB建立尝试总次数。E-RAB建立过程一般由UE在需要向无线网络申请服务时主动发起，并通过初始UE上下文建立流程或E-RAB建立流程完成建立。E-RAB建立尝试总次数用于统计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收到来

10、自MME的E-RAB SETUP REQUEST或者INITIAL CONTEXT SETUP REQUEST消息时统计该指标。如果E-RAB SETUP REQUEST或者INITIAL CONTEXT SETUP REQUEST消息中要求同时建立多个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是承载用户业务数据的接入层

11、承载，它在小区内的建立成功率，直接反映了小区为用户提供E-RAB连接建立的能力。E-RAB建立失败统计，可以反映出网络中各种原因的E-RAB建立失败的分布情况。1.3 工具简介（1）KPI话统记录用于统计RRC建立成功率，ERAB建立成功率，失败原因等信息（M2000,国内OMC920）。（2）标准信令跟踪（eNB UU口跟踪、eNB S1口跟踪、eNB X2口、UE OMT信令跟踪）可以获取信令消息交互情况。适用于进行简单问题排查（LMT或M2000，国内OMC920）。2 常见问题简单排查方法2.1 基本定位思路接入失败通常有三大类原因：无线侧参数配置问题、信道环境影响以及核心网侧配置问题

12、。因此遇到无法接入的情况，可以大致按以下步骤进行排查。（1）通过话统分析是否出现接入成功率低的问题，当前RRCeRAB接通率指标一般为98%，也可根据局点对接入成功率指标的特殊要求启动问题定位。（2）确认是否全网指标恶化，如果是全网指标恶化，需要检查操作，告警，是否存在网络变动和升级行为。（3）如果是部分站点指标恶化，拖累全网指标，需要寻找TOP站点。（4）查询RRC连接建立和ERAB建立成功率最低的TOP10站点和TOP时间段。（5）查看TOP站点告警，检查单板状态，RRU状态，小区状态，OM操作，配置是否异常。（6）提取CHR日志，分析接入时的msg3的信道质量和SRS的SINR是否较差（

13、弱覆盖），是否存在TOP用户。（7）针对TOP站点进行针对性的标准信令跟踪、干扰检测进行分析。（8）如果标准信令和干扰检测无异常，将一键式日志，标口跟踪，干扰检测结果返回给开发人员分析。 详细流程图如下：图5 接入问题优化流程图2.1.1 TOP小区筛选通过M2000导出全网每日话统文件，按照（L.RRC.ConnReq.Att-L.RRC.ConnReq.Succ）次数从高到低排序，结合接入成功率，选出TOP10站点接入成功率低的小区。 按照（L.E-RAB.AttEst-L.E-RAB.SuccEst）次数从高到低排序，结合ERAB建立成功率选出TOP10 ERAB建立成功率低的站点。检查

14、TOP小区的状态是否正常，可以在M2000上，通过MML命令“DSP CELL”能查看到小区的总体信息。如果小区状态显示不是“正常”，可以按如下方法进行简单排查：如果存在S1链路异常告警，请检查S1链路配置是否正确。如果存在RSSI/RSRP通道不平衡，需要检查天馈互调干扰，如果存在驻波告警，需要通过DSP TXBRANCH，DSP RXBRANCH查看RRU发射和接收通道状态。如果存在小区不可用告警，需要返回主控和基带板一键式日志。2.1.2 TOP小区话统分析通过RRC建立失败话统可以得出TOP小区RRC建立失败原因分布：L.RRC.SetupFail.NOReply多为弱覆盖或终端异常；

15、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_CM

16、P消息3 基站下发了RRC_CONN_RECFG消息,没有收到UE的RRC_CONN_RECFG_CMP消息4 基站下发了RRC_UE_CAP_ENQUIRY消息,没有收到UE的RRC_UE_CAP_INFO消息初始上下文建立请求消息超时，需要核心网侧配合，查看核心网侧在收到ENB传递的NAS Attach消息后的处理流程。初始上下文建立失败需要检查基站配置，查看告警，跟踪Uu口，S1口进行分析。2.1.3 TOP用户分析通过CHR日志分析可以获取RRC建立失败和ERAB建立失败TOP用户的TMSI。在CHR数据中，可以通过TMSI来确定是否为同一个用户，具体方法如下：当前华为核心网TMSI分

17、配的机制是对于同一个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可以认为终端处于弱覆盖区域。图6 CHR字段说明截图2.1.4 TOP小区跟踪通过话统分析出TOP小区和

18、TOP时间段后，在对应的小区和时间段，打开Uu口，S1口，X2口跟踪，查看接入流程在哪一步失败。通过TOP用户的TMSI在核心网侧获取到IMSI，可以启动该用户的全网跟踪2.1.5 TOP小区环境干扰分析通过频谱扫描仪功能查看下行是否存在邻区干扰、外部系统干扰等。通过ENB小区干扰检测的性能跟踪分析是否存在上行干扰。如存在外部干扰或邻区干扰，需要进行干扰源排查。2.2 配置类问题排查2.2.1 UE配置问题1.华为Test UE频点配置针对我司UE，检查频点配置是否与eNB一致，如果频点不正确，UE表现为小区搜索失败。图7 测试UE频点配置2.E398/E392 Attach类型设置LTE核心

19、网通常没有配置CS域的通道，只有PS域。当E398 Attach类型为CS&PS combined attach时，就会导致只Attach了PS域，CS域一直附着失败，UE最终被释放掉。将E398的Attach方式修改为PS_ONLY可以解决此问题。图8 Attach信令截图3.终端规格问题以E398s/E392u为例， 只支持Band38和Band40，如果小区设置为其他频带，终端将无法接入。另外，需要确认部分终端对无线层加密算法的支持程度，如果小区配置中使用了终端不支持算法进行加密和完整性保护，终端可能会出现接入失败。以海思芯片为例，通过Histudio在NV项中找到UE_NET_

20、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算法。目前UE对三种算法都支持，所以不管在测试还是商用使用过程中，建议按照默认设置，不要

21、更改这些值。2.2.2 ENB配置问题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功控开关关闭时可以接入。图9 PDCCH符号数配置2

22、.IPPATH配置问题基站在完成了安全的配置与UE能力的获取后并向小区申请资源,会向TRM申请GTPU资源,如果申请资源失败则会向核心网返回初始上下文建立失败响应INIT_CONTEXT_SETUP_FAIL;原因值填写transport resource unavailable(0)；如下图所示；跟踪如下所示:图10 初始上下文建立失败响应信令截图在这种情况下,对照开站summary首先查看一下MML中的IPPATH是否配置正确,如果已经配置正确,则查看请初始上下文建立请求消息(INIT_CONTEXT_SETUP_REQ消息)中transportlayeraddress的信元值是否为配置的

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

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

25、一下频点。具体查看方式如下：图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中，且为可选项，如果没有小区禁止信息，可认为小区未禁止。图17 协议36331 6.3

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

27、驻留门限为-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，10M，15M，20M

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

29、以下为用户Attach流程中随机接入的时序图，供参考。由于上下行调度都是eNB控制的，其下行传输的信息都没有严格的限制，一般只要满足定时器不超时即可，而UE侧上下行资源都是eNb控制，所以对UE上行发送会有严格的时序控制（ACK信息反馈是4个TTI，UL Grant到上行发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发起了ATTA

30、CH，通过UE OMT的空口消息进行确认。图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消息后，会一直去盲检PDC

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

32、步定位和确认问题可以通过以下方式，核对eNB和UE的TTI级信息进行进一步定位。（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。（文

33、件中PreambID、RID对应的值为PreambleID）。Ø 如果找到相同的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侧相对

34、应，表明UE收到了RAR消息。示例中RAR TTI为296.9。 图23 UE下行接收RAR消息信息n 如果UE没有收到RAR消息则通过UE TTI跟踪的测量信息进行进一步分析：u 在UE接收RAR消息前，TTI 跟踪没有记录相关测量值，无法进一步分析是什么原因导致无法收到RAR消息。（3）核对UE和eNB MSG3消息，确认eNB是否收到UE发送的MSG3消息。首先，通过UE OMT跟踪可以确认UE发送MSG3（RRC_CONN_REQ）。该信息表明了UE L3已经发送了MSG3，但并不表明UE L1确实已经将消息发送给了eNB，例如：最常见的，如果UE没有接到UL GRANT，UE就无法发

35、送MSG3。可以通过UE TTI跟踪进行进一步分析。UE在发送RACH后第1次上行PUSCH传输的数据就是MSG3消息，且Msg3是Tmp C-RNTI加扰的。可以从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位置）

36、，RbNum（RB数），调制方式，CellSrs/UESrs（存在SRS指示）n 如果MSG3 CRC错误，通过测量值判断是否是由于SINR低导致eNB无法解调：u 如果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）消息后，是

37、否发送了MSG4（RRC_CONN_SETUP）。图25对于MSG4为信令，在系统中其调度优先级比较高，在通常情况下LMT上观察到MSG4，就可以认为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：

38、通过UE OMT查看UE是否收到MSG4（RRC_CONN_SETUP）。示例如下。图27 MSG4指示n 如果UE没有收到MSG4可以通过TTI跟踪确认是否是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固定

39、采用CCE个数为4进行调度，PDSCH采用MCS=1阶调度。一般的，当SINR小于-5可认为低于PDCCH（CCE=4）的解调门限。u 一般的，如果RSRP-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信息，如

40、果UE正确解到PDSCH，反馈ACK；如果解调错误则反馈NACK。而ACK有两种方式传送，一种是随路，也就是在PUSCH上传输；一种是PUCCH。n 一般的，如果反馈的为DTX，且ACKPWR接近低噪（-130dBm）或、ACKSINR为-10dB或更低，可认为UE没有收到PDCCH。注：ACKPwr为PUCCH RB导频上的总功率，由于PUCCH RB可能为多用户码分复用，所以可能出现ACK PWR功率较高，但SINR很低的情况，所以这里描述的在单用户情况下有效。n 一般的，如果反馈的结果为NACK，可认为UE PDSCH CRC错误。u PDSCH CRC错误时，根据UE测量信息分析原因，

41、如果SINR低于解调能力，l 排查是否是在小区边界，导致接收信号功率过低l 排查是否存在邻区干扰以下表示eNB在300.2收到PUCCH上反馈的ACK。根据协议36.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条上行动态调度，需要向eNB发送SRI请

42、求，ENB收到SRI后才会给UE调度。如果开了预调度，也有可能不发送SRI。以下是预调度关闭的分析，预调度打开时可能没有SRI。图30 MSG5指示2） 确认UE是否发送了SRI请求。通过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下行跟踪观察是否发送了U

43、L GRANT，或者通过eNB L1 TTI上行跟踪观察上行调度结果。协议规定ENB下发ULGANT后，UE会在4个TTI后（TDD为4个TTI后第一个上行TTI）在PUSCH上传信息。所以下行跟踪记录的发送UL GRANT的时刻和上行跟踪记录的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后第一个上行子帧）后

44、发送上行PUSCH，所以UL Grant和上行PUSCH跟踪信息会相差4个TTI。如图所示，UE在300.6收到了UL Grant：图34 UE UL Grant接收指示6） 确认eNB是否收到MSG5，通过eNB上行TTI跟踪分析上行接收情况，示例所示301.2收到了PUSCH，并且CRC正确：图35 上行PUSCH接收Ø 如果上行调度CRC错误，可通过调度信息、DMRS测量、SRS测量等信息进行分析。n 一般的，如果DMRS Rsrp（子载波级的eNB接收功率，）接近低噪（-130dBm），说明接收功率很低。u 一般的，需要通过UE发送功率和UE路损推算接收到的RSRP是否合理。

45、UE发射功率可以这样估算：Pwr = P0 + alpha * 下行PL + f(i) + 10logM。其中P0、Alpha可通过系统消息获取、PL可通过路损计算得到（PL=RS-下行RSRP），系统f（i）=-1，M为调度的RB个数。如果计算得到的Pwr大于UE最大发射功率，则Pwr=Ue最大发射功率。ENB接收功率RSRP=Pwr 10log(12*M) 上行PL。u 一般的，如果RSRP-SINR明显高于低噪，说明有较大干扰。请排查环境是否存在干扰源或其他干扰因素。u 一般的，如果下行RSRP为中近点，而上行接收的RSRP接近底噪（-130dBm），可能为UE没有发送数据，如果UE跟踪

46、显示UE发了数据，可以分析一下UE和eNB的资源配置（RB位置和RB数等配置信息）。u 一般的，还可以分析一下SRS测量得到的TA是否合理。如果MCS阶数很高，而TA提前，比较容易造成CRC错误。3.1.3 安全模式、RB重配问题定位指导MME无响应或MME主动发起的释放造成的用户释放一般是基站发起INIT_UE_MSG后,等待核心网的初始上下文建立请求消息超时(即核心网没有下发初始上下文请求消息),然后由基站主动发起的用户释放, 在这种情况下需要跟核心网侧维护人员确认一下为什么没有发起初始上下文建立请求消息；另一种情况是基站发起INIT_UE_MSG后,核心网立即下发了释放消息UE_CONT

47、EXT_REL_CMD,在这种情况下,首先确认一下INIT_UE_MSG中的PLMNID与基站侧的配置是否一致,如果不一致,需要重新配置后再接入；如果已经一致,则需要跟核心网侧维护人员确认一下核心网下发释放消息的原因；具体显示的跟踪样例如下所示:图36 信令跟踪样例UE无响应造成用户释放一般UE无响应造成的释放有四种情况:1、 基站下发了RRC_CONN_SETUP消息没有收到UE的RRC_CONN_SETUP_CMP消息;2、 基站下发了RRC_SECUR_MODE_CMD消息没有收到UE的RRC_SECUR_MODE_CMP消息;3、 基站下发了RRC_UE_CAP_ENQUIRY消息没有

48、收到UE的RRC_UE_CAP_INFO消息;4、 基站下发了RRC_CONN_RECFG消息没有收到UE的RRC_CONN_RECFG_CMP消息;因为第一种情况正处于RRC连接建立状态,所以不需要回核心网响应,其它三种情况都需要回核心网初始上下文建立失败响应(即消息INIT_CONTEXT_SETUP_FAIL);在发生了上述四种情况后,需要在UE那里确认一下基站侧下发的这条消息(比如RRC_CONN_SETUP)UE的跟踪上是否收到,如果没有收到,则需要查一下基站发出的这条消息在基站的L2处是否收到并下发给了UE,并查看一下基站发出的这条消息UE的L2是否收到并传递给了UE的L3;如果U

49、E的L3收到了这条消息,则需要查看一下UE是否发出响应基站的消息(比如RRC_CONN_SETUP_CMP);跟踪样例如下所示:图37 信令跟踪样例上图是因为没有收到UE的RRC_SECUR_MODE_CMP消息导致超时造成的用户释放;无线资源申请失败导致用户释放基站在完成了安全的配置与UE能力的获取后会向小区申请资源,如果申请失败,则会向核心网返回初始上下文建立失败响应INIT_CONTEXT_SETUP_FAIL;原因值一般会填写radio resource not available(25);如下图所示;在这种情况下,一般都是向小区申请资源失败导致的初始上下文建立失败;一般可以先导出MM

50、L的参数配置,然后与默认参数进行对比,查看一下是否一些与小区相关的参数配置错误（可以与基线比较，参数相关参见基线参数配置，参数基线可以从随版本发布的文档包获取）,如果参数没有问题,则请把IFTS打开,将跟踪反馈给研发人员确认问题的原因；跟踪如下所示:图38 信令跟踪样例GTPU资源申请失败基站在完成了安全的配置与UE能力的获取后并向小区申请资源,会向TRM申请GTPU资源,如果申请资源失败则会向核心网返回初始上下文建立失败响应INIT_CONTEXT_SETUP_FAIL;原因值一般会填写transport resource unavailable(0);如下图所示;跟踪如下所示:图39 信令

51、跟踪样例在这种情况下,首先查看一下MML中的IPPATH是否配置正确,如果已经配置正确,则查看请初始上下文建立请求消息(INIT_CONTEXT_SETUP_REQ消息)中transportlayeraddress的信元值是否为配置的IPPATH值,如果不一样则需要确认一下是我们配置错误还是核心网填写错误。如果以上都不符合则开启IFTS跟踪,将跟踪日志反馈给研发人员确认问题的原因；图40 信令跟踪样例由基站主动发起的用户释放如果UE释放是由基站主动发起的，则一般是基站先发起UE_CONTEXT_REL_REQ消息,如下所示,如果以上都不符合则开启IFTS跟踪,将跟踪日志反馈给研发人员确认问题的

52、原因图41 信令跟踪样例由UE主动发起的用户正常释放如果UE释放是正常的关机所致,会由核心网主动发起UE_CONTEXT_REL_CMD,且释放原因值为nas_detach.如下图的跟踪所示:图42 信令跟踪样例3.1.4 S1接口异常问题定位S1接口异常通常可以采用以下方式进行排查。图43 S1接口异常排查思路（1） 首先DSP S1INTERFACE查看以下四个信息：S1InterfaceState（S1接口状态），S1SctpLinkState（SCTP链路状态），S1InterfaceIsBlock（S1接口是否处于闭塞状态），MmeIsOverLoad（MME是否处于过载状态），主要

53、情况分为以下四种，1) S1SctpLinkState为异常，转（2）； 2) S1SctpLinkState为正常，S1InterfaceState为异常，转（7）；3) S1SctpLinkState为正常，S1InterfaceState为正常，S1InterfaceIsBlock处于闭塞,转(14)；4) S1SctpLinkState为正常，S1InterfaceState为正常，MmeIsOverLoad处于过载(15)；（2） DSP SCTPLINK查看SCTP链路状态是否OK，A：是，转（5）B：否，转（3）（3） 查看ENODEB与MME连接的网线是否插好，端口是否与配置的

54、SCTP端口号一致:A：插好且一致，转（4）B：没有插好或不一致，请将网线插到配置的位置;（4） 打开LMT上的SCTP跟踪，查看SCTP跟踪中是否与MME正常通信A：正常通信，转（5）B：不正常通信，转（6）（5） RMV S1INTERFACEID删除该S1接口重新添加一遍，再查看S1接口信息，如果仍然有问题，转(17)；（6） 联系ROSA的同事定位问题原因，如果时间紧急，请删除该SCTP链路后重新添加，再转（4）；（7） 如果是ENODEB系统首次起来，查看小区：DSP CELL，判断小区是否OK：A：是，转（8）B：否，转（16）（8） 打开LMT跟踪的S1接口跟踪，查看S1接口是否

55、持续向MME发送S1_SETUP_REQ消息:A：是，转（9）B：否，转（5）（9） MME是否回响应:A:是,转(13)B:否,转(10)（10） 通过DSP SCTPLINK查看SCTP链路状态是否为闭塞状态,A:是,转(11);B:否,转(12)（11） 解闭塞;（12） 联系MME维护人员,查询是否MME故障（13） 回响应S1_SETUP_FAIL,判断当前基站是否支持协议兼容,如果支持,通过MOD RRGLOBALSWITCH来修改相关协议版本,如果不支持,转(17);（14） 通过UBL S1INTERFACE解闭塞;（15） MME已经处于过载状态,不允许用户接入;（16） 请

56、定位小区故障原因;（17） 请联系研发人员；3.2 常见优化方法3.2.1 优化覆盖从RRCConnReq重发次数来看，现网有下行SetUp丢失的情况。考虑到现网部分场景覆盖比较差，出现下行SetUp丢失的情况可能比较多。SetUp为动态调度，码率<0.117，相应MCS=0，基于此，SetUp已经以低阶高功率发送，再优化SetUp的意义不大，即使SetUp能发下来，后面的流程也很难走下去。因此，主要还是要优化RF来优化覆盖，以提高接入成功率。3.2.2 MSG3受限的优化方法若判断MSG3受限，可以通过提高功率攀升步长和前导初始接收目标功率值的方法提升MSG3成功率，修改命令为MOD RACHCFG，参数为PwrRampingStep和PreambInitRcvTargetPwr。3.2.3 Preamble的优化如果定位发现可能是Preamble受限导致，可以将Preamble的Format格式设置为Format1、2、3，修改命令为MOD CELL，参数名称为