LTE TDD问题定位指导书-接入篇-

1、产品名称Product name密级Confidentiality levelLTE TDD内部公开产品版本Product versionTotal 60pages 共60页LTE TDD问题定位和优化指导书-接入篇本文介绍了用户接入的流程和用户接入失败时问题定位的基本方法，常见问题排查方法部分主要面向网络维护人员，介绍了一些常见问题的定位排查手段和方法，主要应用场景为通过KPI指标发现问题，通过CHR、告警日志、标口跟踪、UE侧log进行问题定位。概念和基本原理基本概念（1）用户Attach流程：图1 用户接入流程（2）随机接入流程介绍随机接入过程的发生有以下五种场景：从空闲态转到连接态的初

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

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

4、的RRC信令消息，目的是通知UE RRC连接的建立结果及相关配置信息。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_Setup消息后，在T300定时器超时前，收到相

5、同的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会在定时器超时后重新发起Attach，ENB侧记为新的一次初始接入；RRC_

6、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.

7、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。【

8、C点】当eNodeB收到UE返回的RRC Connection Setup Complete消息时统计相应指标，L.RRC.ConnReq.Succ加1。RRC Setup Success Rate计算）/(L.RRC.ConnReq.Att)*100%RRC连接建立失败话统统计小区内不同原因的RRC连接建立失败的次数及总的RRC连接失败次数。RRC Connection Reject消息是eNodeB发送给UE的RRC信令消息，目的是通知UE本次接入过程被eNodeB拒绝。ERAB承载建立尝试话统统计小区E-RAB建立尝试总次数。E-RAB建立过程一般由UE在需要向无线网络申请服务时主动发起

9、，并通过初始UE上下文建立流程或E-RAB建立流程完成建立。E-RAB建立尝试总次数用于统计UE发起的总的E-RAB建立尝试次数。ERAB承载建立成功话统统计小区E-RAB建立成功总次数。E-RAB建立过程一般由UE在需要向无线网络申请服务时主动发起，并通过初始UE上下文建立流程或E-RAB建立流程完成建立。E-RAB建立尝试总次数用于统计UE发起的总的E-RAB建立成功次数。话统统计方法 图4如 HYPERLINK mk:MSITStore:C:DOCUME1L001401LOCALS1Tempnotes6030C8eNodeB性能指标参考.chm:/lte/lte-enodeb-perfo

10、rmance-counter-reference/MtType_12.html l MtType_12_fig1#MtType_12_fig1 3、4中A点所示，当eNodeB收到来自MME的E-RAB SETUP REQUEST或者INITIAL CONTEXT SETUP REQUEST消息时统计该指标。如果E-RAB SETUP REQUEST或者INITIAL CONTEXT SETUP REQUEST消息中要求同时建立多个E-RAB，则相应指标按各个业务的QCI分别进行累加。ERAB Setup Success Rate计算公式）/()*100%ERAB承载建立失败话统统计小区内E-

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

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

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

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

15、失败原因话统可以得出得出ERAB建立失败原因分布：。初始上下文建立失败的几种现象：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传递的NAS Attac

16、h消息后的处理流程。初始上下文建立失败需要检查基站配置，查看告警，跟踪Uu口，S1口进行分析。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字段

17、记录的接入时上行信道质量DMRS_SINR和DMRS_RSRP，可以初步确认用户是否处于上行弱覆盖区域：DMRS_SINR0db或DMRS_RSRPPRACH-PreambleID字段（示例中PreambleID=29，发送时刻的帧号为296，子帧号为3，下面用296.3描述帧号子帧号）。 图22 UE侧TTI跟踪中RACH信息用LAE打开eNB CELL DT跟踪文件，查看PreambleID为29的记录。如果无法查找到，则表示eNB没有检测到PreambleID。（文件中PreambID、RID对应的值为PreambleID）。如果找到相同的PreambleID，表明eNB收到了UE发送的

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

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

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

21、SRP低于-130dBm，可认为接收功率接近低噪。如果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，就可以认为eNB已经发送给了UE。当然，还可以通过以下方式确认MSG4是否被调度：通过LA

22、E打开eNB IFTS跟踪，查看TB0_RRC Message Type字段为RRC_CONN_SETUP的记录。如下图所示eNB在调度了Msg4。 图26 ENB L2 TTI下行跟踪信息如果eNB没有下发MSG4消息，通过采集eNB CHR信息分析具体原因，建议交由研发人员进行定位分析。2、确认UE收到了MSG4：方法1：通过UE OMT查看UE是否收到MSG4（RRC_CONN_SETUP）。示例如下。图27 MSG4指示如果UE没有收到MSG4可以通过TTI跟踪确认是否是PDCCH检测不到，还是PDSCH CRC错误导致。通过UE的TTI跟踪进行核对。一般的，RAR消息后的第1个PDS

23、CH为MSG4调度，时刻点在收到RAR消息的20ms内。如果在收到RAR消息较长时间内没有解到PDCCH，可认为UE没有检测到PDCCH。如果UE没有收到PDCCH，可根据记录的RSRP、SINR、频偏等测量量以及CCE个数等调度信息分析PDCCH漏检。一般的，10M、20M带宽下信令消息的PDCCH固定采用CCE个数为4进行调度，PDSCH采用MCS=1阶调度。一般的，当SINR小于-5可认为低于PDCCH（CCE=4）的解调门限。一般的，如果RSRP-SINR明显高于UE底噪（-124dBm），可认为干扰较大。如果UE收到PDCCH，可根据UE TTI跟踪查看PUSCH CRC校验结果。下

24、面的示例中表示UE在接收到Msg4消息，且CRC正确。图28 UE TTI下行跟踪信息方法2：通过eNB侧的控制信道PUCCH的上的ACK反馈信息进行分析。协议规定eNB下发PDSCH，UE需要在4个TTI后（TDD反馈方式参看协议）反馈ACK信息，如果UE正确解到PDSCH，反馈ACK；如果解调错误则反馈NACK。而ACK有两种方式传送，一种是随路，也就是在PUSCH上传输；一种是PUCCH。一般的，如果反馈的为DTX，且ACKPWR接近低噪（-130dBm）或、ACKSINR为-10dB或更低，可认为UE没有收到PDCCH。注：ACKPwr为PUCCH RB导频上的总功率，由于PUCCH

25、RB可能为多用户码分复用，所以可能出现ACK PWR功率较高，但SINR很低的情况，所以这里描述的在单用户情况下有效。一般的，如果反馈的结果为NACK，可认为UE PDSCH CRC错误。PDSCH CRC错误时，根据UE测量信息分析原因，如果SINR低于解调能力，排查是否是在小区边界，导致接收信号功率过低排查是否存在邻区干扰以下表示eNB在收到PUCCH上反馈的ACK。根据协议，bundling模式下的ACK应该在反馈。图29 PUCCH的ACK反馈3、核对UE和eNB MSG5消息，确认eNB是否收到MSG5消息。1）确认UE L3是否发送了MSG5消息。通过OMT空口信令跟踪，查看UE是

26、否发送了MSG5（RRC_CONN_SETUP_CMP），如果界面显示有MSG5消息，但并不表示UE已经发送了MSG5给eNB。这是因为MSG5为第1条上行动态调度，需要向eNB发送SRI请求，ENB收到SRI后才会给UE调度。如果开了预调度，也有可能不发送SRI。以下是预调度关闭的分析，预调度打开时可能没有SRI。图30 MSG5指示2） 确认UE是否发送了SRI请求。通过UE L1 TTI上行跟踪的SRI是否为“有”。下例所示，UE在发送了SRI请求。图31 UE L1 TTI上行跟踪3） 确认eNB是否收到了SRI请求。通过eNB L1 TTI上行跟踪观察检测到收到SRI跟踪，如下例所示

27、，eNB在中检测到了SRI说明eNB收到了SRI请求。图32 eNB L1 TTI跟踪确认eNB是否进行了上行调度。通过eNB L1 TTI下行跟踪观察是否发送了UL GRANT，或者通过eNB L1 TTI上行跟踪观察上行调度结果。协议规定ENB下发ULGANT后，UE会在4个TTI后（TDD为4个TTI后第一个上行TTI）在PUSCH上传信息。所以下行跟踪记录的发送UL GRANT的时刻和上行跟踪记录的PUSCH调度信息会相差4个TTI。如图所示，eNB在调度了UL Grant：图33 eNB UL Grant指示确认UE是否收到了UL GRANT，并正确发送了PUSCH。UE TTI上下

28、行跟踪可以看到UE是否解到了UL GRANT和发送了PUSCH，协议规定UE在收到UL Grant的4TTI（TDD为4个TTI后第一个上行子帧）后发送上行PUSCH，所以UL Grant和上行PUSCH跟踪信息会相差4个TTI。如图所示，UE在收到了UL Grant：图34 UE UL Grant接收指示确认eNB是否收到MSG5，通过eNB上行TTI跟踪分析上行接收情况，示例所示收到了PUSCH，并且CRC正确：图35 上行PUSCH接收如果上行调度CRC错误，可通过调度信息、DMRS测量、SRS测量等信息进行分析。一般的，如果DMRS Rsrp（子载波级的eNB接收功率，）接近低噪（-1

29、30dBm），说明接收功率很低。一般的，需要通过UE发送功率和UE路损推算接收到的RSRP是否合理。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。一般的，如果RSRP-SINR明显高于低噪，说明有较大干扰。请排查环境是否存在干扰源或其他干扰因素。一般的，如果下行RSRP为

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

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

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

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

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

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

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

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

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

39、：是，转（9）B：否，转（5）MME是否回响应:A:是,转(13)B:否,转(10)通过DSP SCTPLINK查看SCTP链路状态是否为闭塞状态,A:是,转(11);B:否,转(12)解闭塞;联系MME维护人员,查询是否MME故障回响应S1_SETUP_FAIL,判断当前基站是否支持协议兼容,如果支持,通过MOD RRGLOBALSWITCH来修改相关协议版本,如果不支持,转(17);通过UBL S1INTERFACE解闭塞;MME已经处于过载状态,不允许用户接入;请定位小区故障原因;请联系研发人员；常见优化方法优化覆盖从RRCConnReq重发次数来看，现网有下行SetUp丢失的情况。考虑

40、到现网部分场景覆盖比较差，出现下行SetUp丢失的情况可能比较多。SetUp为动态调度，码率17，相应MCS=0，基于此，SetUp已经以低阶高功率发送，再优化SetUp的意义不大，即使SetUp能发下来，后面的流程也很难走下去。因此，主要还是要优化RF来优化覆盖，以提高接入成功率。MSG3受限的优化方法若判断MSG3受限，可以通过提高功率攀升步长和前导初始接收目标功率值的方法提升MSG3成功率，修改命令为MOD RACHCFG，参数为PwrRampingStep和PreambInitRcvTargetPwr。Preamble的优化如果定位发现可能是Preamble受限导致，可以将Preamb

41、le的Format格式设置为Format1、2、3，修改命令为MOD CELL，参数名称为PreambleFmt。典型案例IPPATH配置不正确导致用户接入后被释放问题描述用户无法接入，打开IFTS跟踪显示如下：图44 IFTS跟踪样例问题分析通过IFTS跟踪查看释放前的消息中是否存在如下错误“GTPU setup fail”。图45 IFTS跟踪样例解决措施通过RMV IPPATH删除错误的IPPATH配置，通过ADD IPPATH添加正确的IPPATH。图46 添加正确的IPPATHNcs值配置过小导致UE接入失败问题描述案例一：上海外场两个AWS站点在验证站间切换时，发现从发展站切换到乾昌站总是成功，而从乾昌站切换到发展站总是失败，失败原因为切换时UE随机接入失败。案例二：德国DD 800M项目，UE在距基站处初始接入失败，现象与案例一相同。问题分析案例一：问题发生时UE每次上报随机接入Preamble，都可以收到eNB的响