LTE网络连接速率分析.pdf

TD-LTE网络连接速率分析思路连接速率优化思路遵循以下方法: 1.通过流量统计分析，是否存在接入成功率低的问题，请根据接入权限要求启动成功率指数问题位置或主题优化. 2.通过分析对话系统的原始数据，找出问题最多的TOP站点和TOP时间段. 3.针对TOP站点的目标网络管理信令跟踪，LMT跟踪，警报检查等. 4.如果网络管理信令和LMT跟踪仍然无法找到问题，请执行驱动测试以重现问题，收集前后日志，并请相关开发人员协助定位. 获取接入问题的TOP信元和TOP周期后，首先通过网管信令跟踪，LMT跟踪，告警检查等方法，首先检查设备是否存在异常或网络配置问题: 1.检查信元状态. 检查各单板，RRU的状态是否正常，单电池状态是否可用； 检查单元格中是否有告警，并进行告警分析；手动检查警报以查看警报是否存在；报告问题； 2.对UE，小区和核心网络组进行故障排除网络配置和对接参数是否正常（在实验网络阶段常见）. 检查UE的频率配置是否与eNB一致，并检查UE的PLMN与eNB配置的PLMN是否一致. 如果频率和PLMN配置不正确，则UE将无法进行小区搜索. 检查核心网络是否具有开户信息.

经过测试的IMSI没有开设帐户，这意味着用户已完成随机访问. 在上行链路直接消息之后，核心网络立即返回到“ S1AP_DL_CONTEXT_REL_CMD”以释放UE. 检查SCTP链接状态是否正常. 如果异常，则需要检查是否连接了ENODB和MME的网线，端口是否与配置的SCTP端口号一致，以及与MME的通信是否正常. 检查S1接口状态是否正常，是否处于阻塞状态，请寻求设备侧同事的帮助和研发指导. 检查安全模式配置. UE和核心网络需要共同开启或关闭身份验证，并根据运营商提供的``LTE USIM卡参数建议''配置C和R值. eNB和核心网需要共同开启或关闭完整性保护算法和加密算法lte接通率公式，并确保配置的算法一致. 检查IPPATH. 在完成安全模式控制和UE能力查询后，基站将申请准备GTPU资源. 如果资源准备失败，它将返回到核心网络的响应消息，提示上下文建立失败: INIT_CONTEXT_SETUP_FAIL，原因值为: 传输资源不可用在这种情况下，MML需要检查IPPACH配置是否为正确，并确认核心网初始上下文建立请求中携带的IPPACH值是否与eNB一致.

在上述基本检查中没有发现问题时，请考虑进行驾驶测试，跟踪前端和后端信号，并从空中接口无线环境对指示器的影响的角度进一步分析和解决问题. 根据初始接入的前台信令过程，从UE的附着请求开始，将UE接入过程分解为三个阶段: RRC建立过程，初始直接传输和安全模式控制以及E-RAB建立过程. 目前，用户数量相对较少. E-RAB建立故障较少，随机接入过程故障较多，导致RRC连接无响应，导致呼叫失败. 因此，解决随机访问失败问题的方法是连接当前升级. 费率的关键. 图连通性分析思路驱动测试数据是否连接失败是是RRC连接建立失败随机访问问题否是初始直接传输过程失败身份验证和保护问题否是RRC连接重新配置失败E-RAB建立问题否异常问题否结束1分析访问失败的根本原因. 图片已满. 该单元未激活. 覆盖范围很差. UE没有接收到广播消息. 频率配置不一致. 单元搜索失败. UE广播消息不匹配. PLMN配置错误. 停车阈值设置不合理. 选择S标准来处理异常Premble传输功率低eNB未接收MSG1 UE未接收MSG2 eNB未发送MSG2下行链路弱字段，干扰了UE接收的RAR不匹配eNB接收的Preamble不匹配UE随机发送的UE接入失败，具有随机访问上行链路干扰eNB未收到MSG3，未解决上行链路，未收到MSG3，未调度MAC，UE无法接收MSG4下行链路弱字段，干扰eNB未发送核心网络，未接收到初始UE信息，SCTP链路问题，IPPATH问题身份验证以及无法确保核心网络未打开的故障. 核心网发起用户释放UE，eNB，核心网安全模式参数不一致. eNB尚未发布RRC以重新分配eNB资源. 源准备失败eNB MAC层未调度UE未接收到RRC重新配置下行链路丢失消息​​/ PDCCH丢失检测ERAB建立失败空口消息错误UE未反馈RRC重新配置完成UE问题注: 连接速率的计算是从UE发起的从“附接请求”或“服务请求”到“初始上下文建立完成”，UE由于其他原因而无法找到该小区或无法驻留在该小区上. 它不计入连接速率，但这是访问失败的一种现象，它也在根本原因分析图表中得到了说明.

2随机访问问题分析随机访问过程发生在以下五个场景中: 1.从空闲状态到连接状态的初始访问； 2.无线链接失败后访问； 3.在切换访问期间； 4.当UE处于连接状态时，由于需要随机接入的一些原因，下行数据到达，例如上行数据不同步时下行数据到达； 5.当UE处于连接状态时，由于诸如上行链路数据在上行链路不同步时到达的原因而需要某些随机接入，因此上行链路数据到达. 随机访问分为基于冲突的随机访问和基于非冲突的随机访问两个过程. 区别在于为两个进程选择了随机访问前缀. 前者是UE根据某种算法从基于冲突的随机接入前缀中随机选择一个随机前缀. 后者是基站侧通过下行专用信令为UE分配无冲突的随机接入前缀. 基于竞争的随机访问适用于以上三种情况1、2和5，基于非竞争的随机访问适用于以上三种情况3、4. 图基于竞争的随机接入图基于非竞争的随机接入UEeNBRA前同步码分配1（MSG1）随机访问前同步码2（MSG2）随机访问响应3（MSG3）1. MSG 1: UE在PRACH上选择随机访问前同步码；发送随机访问请求； 2. MSG2: ENB的MAC层生成随机访问响应RAR并在PDSCH上发送； 3. MSG3: UE的RRC层生成RRC连接请求并启动争用解决计时器，等待争用解决新闻.

; 4. MSG4: RRC连接设置由ENB的RRC层生成，并映射到PDSCH，并与争用解决控制信息一起发送. 在基于竞争的随机接入成功之后，UE的RRC层生成RRC连接建立完成并将其发送给eNB. 非竞争性访问过程与基于竞争的访问过程之间的最大区别在于，访问前导码的分配是由eNodeB生成的，从而减少了竞争和冲突解决过程. 从前台的UE角度来看，随机接入失败的争用分析分为以下三个阶段: 1.发送MSG1后是否收到MSG1； 2.是否成功发送了MSG3； 3.是否正确接收了MSG4. 2.1发送MSG2后是否接收到MSG1图MSG1分析思路PRACH触发，原因: 连接请求NMSG1是否发出终端检查问题Y并结合后台MTS PRACH信道接收情况，NN分析是否接收到上游问题MSG2接收到PDCCHYY组合使用RSRP，SINR进行下行链路问题分析MSG3进程分析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聚合度的初始值. 2.2是否成功发送了MSG3？ MSG3分析思路UE已收到MSG2N检查MSG2承载的上行链路是否发送了MSG3的PUSCH授权信息YN基站侧是否收到RRC连接请求上游故障处理YMSG4分析过程根据随机接入过程，UE收到了MSG3是否为MSG2之后没有发送，请检查MSG2中的授权信息是否正确；如果UE已发送了MSG3的PUSCH，则与基站侧的信令结合，以查看EnodeB是否已收到RRC连接请求，以及基站侧是否已发出RRC连接设置. 如果“ 2.3 MSG4被正确接收” MSG4流程分析；如果在基站侧没有收到RRC连接请求，则表明上游存在问题； 1.检查MTS上行信道的接收功率是否大于-99dBm，如果继续超过-99dBm，则解决上行干扰问题.

2. 检查RAR中携带的MSG3功率参数是否合适，并调整MSG3发送的功率. 2.3是否正确接收了MSG4？随机访问期间发生MSG4失败. 失败的原因是由于CT计时器到期而导致MSG4失败. CT计时器是碰撞检测计时器. 在发送MSG3之后，UE启动CT计时器并等待冲突解决Msg4. 如果计时器到期并且未收到msg4，则随机访问失败. 问题的分析思路如下: 图MSG4失败分析思路E-NodeB发布了RRCConnection Setup1. 根据RSRP和SINR，调整覆盖范围NUE是否接收到MSG4的PDCCH. 2.调整专用PDCCH的聚合度. 3.增加PDCCH的DCI 1A的功率. 速率偏移NY检查重发的PDCCH是否携带了UE是否接收了MSG4. PDCCH是否重传NY. 解决PDSCH接收问题. 结束1.UE是否接收到PDCCH. 解决PDCCH接收问题. 2.您是否在多次接收PDCCH之后收到PDSCH？ （1）确认接收到的PDCCH是否重传该消息，并检查该重传消息的DCI格式是否正确填充； （2）无法接收PDSCH，检查PDSCH使用的MCS，检查PA参数配置，并适当增加PDSCH编号的RB分配.

3鉴权分析，安全问题分析，鉴权和主要性能造成的安全故障如下: 1. eNB发起INIT_UE_MSG后，等待核心网回复初始上下文建立请求超时，也就是说，核心网没有发出初始的上下文建立请求消息，然后eNB主动发起释放RRC连接，导致连接失败. 2. eNB发起INIT_UE_MSG，并直接与核心网传输NAS消息. 在安全模式控制交互之前，它会收到核心网络传递的S1AP_UeContextReleaseCommandMsg消息，然后eNodeB发出RRC连接释放. 3. eNB收到核心网下发的S1AP_InitialContextSetupReq后，与UE进行模式控制交互，UE回复SecurityModeFailure，导致连接失败. 通常，这些问题与UE，eNB和核心网络的身份验证，安全性和加密算法配置有关，并且需要多个网络元素来配合调查. 问题1.2您可以检查核心网络侧信令上的身份验证失败原因. 问题3可以通过分析空中接口消息来检查SMC故障的原因. 通过调整UE，eNB和核心网络的身份验证lte接通率公式，安全性和加密参数来解决该问题.

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/dianqi/article-163308-1.html