资源预览内容
第1页 / 共17页
第2页 / 共17页
第3页 / 共17页
第4页 / 共17页
第5页 / 共17页
第6页 / 共17页
第7页 / 共17页
第8页 / 共17页
第9页 / 共17页
第10页 / 共17页
亲,该文档总共17页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述
TD-LTE 接通过程解析以及指标的分析、定 位、优化思路 接通率优化的思路遵循以下原则: 1. 通过话统分析是否出现接入成功率低的问题,根据局方对接入成功率指标的要 求启动问题定位或专题优化。 2. 通过对话统的原始数据进行分析,查出问题出现最多的 TOP 站点和 TOP 时间段。 3. 针对 TOP 站点进行针对性的网管信令跟踪,LMT 跟踪,告警检查等。 4. 如果网管信令和 LMT 跟踪仍然无法定位问题,针对性的进行路测复现问题,采 集前后台 log,请相关开发人员协助定位。 当获取接入问题的 TOP 小区和 TOP 时段后,通过网管信令跟踪,LMT 跟踪,告警 检查等方法首先排查是否设备异常、组网配置问题: 1. 排查小区状态。 - 检查各单板状态、RRU 是否正常,小区状态是否为可用;- 查看小区是否存在告警,进行告警分析;手动恢复告警后查看告警是否存在;上报 问题;2. 排查 UE、小区、核心网组网配置、对接参数是否正常(常见于实验网阶段)。 - 检查 UE 的频点配置是否与 eNB 一致,检查 UE 的 PLMN 与 eNB 配置的 PLMN 是 否一致,如果频点、PLMN 配置不正确,UE 进行小区搜索失败。 - 检查核心网是否有开户信息。测试的 IMSI 没开户,表现为用户完成随机接入, 上行直传消息后核心网立即回“S1AP_DL_CONTEXT_REL_CMD” ,释放 UE。 - 检查 SCTP 链路状态是否 OK,如果异常,需要检查 ENODB 与 MME 连接的网线 是否插好,端口是否与配置的 SCTP 端口号一致,是否与 MME 正常通信; - 检查 S1 接口状态是否正常,S1 接口是否处于闭塞状态,寻求设备侧同事的帮助 和研发指导。 - 检查安全模式配置。UE 和核心网需要共同开启或关闭鉴权,并且按照运营商提供的“LTE USIM 卡参数建议”配置 C 值和 R 值。eNB 和核心网需要共同开启或关闭完 整性保护算法和加密算法,并且保证配置的算法一致。 - 检查 IPPATH。基站在完成安全模式控制和 UE 能力查询后,将申请准备 GTPU 资 源,如果资源准备失败会向核心网返回促使上下文建立失败响应消息: INIT_CONTEXT_SETUP_FAIL,原因值为:transport resource unavailable。在这种情况下, 需要 MML 查看 IPPACH 配置是否正确,并且确认核心网在初始上下文建立请求中携带 的 IPPACH 值是否与 eNB 一致。 在上述基本检查皆未发现问题时,考虑进行路测,跟踪前、后台信令,进一步从 空口无线环境对指标的影响角度进行问题的分析和解决。 根据初始接入的前台信令流程,从 UE 发起 attach 请求开始,将 UE 接入过程分解 为三个阶段:RRC 建立过程,初始直传和安全模式控制,E-RAB 建立过程。目前用户量 较少 E-RAB 建立较少有失败的现象,而随机接入过程出现的问题较多,导致 RRC 连接 无响应,引起起呼失败,所以解决随机接入失败问题是当前提升接通率的关键。图 接通率分析思路 1接入失败根因分析全貌图注意: 接通率的计算是从UE发起“attach请求”或“业务请求”到“初始上下文建立完成” 这一过程,UE搜索不到小区或由于其他原因无法驻留小区不计算在接通率中,但作为 接入失败的一种现象也在根因全貌分析图中进行了说明。 2随机接入问题分析 随机接入过程发生在以下五种场景: 1. 从空闲态转到连接态的初始接入;2. 无线链路失败后的接入;3. 切换过程中的接入;4. 当UE处于连接态时下行数据到达是因为某些原因需要随机接入,如上行失步 时有下行数据到达;5. 当UE处于连接态时上行数据到达是因为某些原因需要随机接入,如上行失步 时有上行数据到达。 随机接入分为基于冲突的随机接入和基于非冲突的随机接入两个流程,其区别为 针对两种流程其选择随机接入前缀的方式。前者为UE从基于冲突的随机接入前缀中依 照一定算法随机选择一个随机前缀;后者是基站侧通过下行专用信令给UE指派非冲突 的随机接入前缀。基于竞争的随机接入适用于上述1、2、5三种场景,非竞争的随机 接入适用于上述3、4两种场景。 图 基于竞争的随机接入图 基于非竞争的随机接入 1. MSG1:UE选择随机接入前导preamble,在PRACH上发送随机接入请求; 2. MSG2:ENB的MAC层产生随机接入响应RAR,并在PDSCH上发送; 3. MSG3:UE的RRC层产生 RRC Connection Request,并开启竞争解决定时器,等待 竞争解决消息; 4. MSG4:RRC Connection Setup 由ENB的RRC层产生,连同竞争解决控制信息映射 到PDSCH上发送。 基于竞争的随机接入成功后,UE的RRC层生成RRC Connection Set up Complete 并发往eNB。而非竞争的接入过程与基于竞争的接入过程最大差别在于接入前导的分配 是由eNodeB产生的,这样就减少了竞争和冲突解决过程。 从前台UE侧角度分析竞争的随机接入失败发生在以下三个阶段:1. MSG1发送后是否收到MSG2;2. MSG3是否发送成功;3. MSG4是否正确接收。 2.1 MSG1发送后是否收到MSG2图 MSG1分析思路 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收到MSG2后若没有发出MSG3,检查MSG2带的授权信息是 否正确;若UE已发出MSG3的PUSCH,结合基站侧信令查看EnodeB是否收到到RRC Connection Request,若基站侧已发出RRC Connection Setup前台未收到,如 “2.2.3 MSG4是否正确接收” MSG4过程分析;若基站侧RRC Connection Request未 收到,说明上行存在问题;1. 检查MTS上行通道的接收功率是否-99dBm,若持续超过-99dBm,解决上行干 扰问题。 2. 检查RAR中携带的MSG3功率 参数是否合适,调整MSG3发送的功率。 2.3 MSG4是否正确接收 在随机接入过程中出现MSG4fail,失败原因是failure at MSG4 due to CT timer expired。CT timer即冲突检测定时器,UE发出MSG3后开启CT timer等待冲 突解决Msg4,若定时器到期时仍未收到msg4触发随机接入失败。该问题的分析思路如 下图:图 MSG4 fail分析思路 1. UE是否收到PDCCH,若没有收到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、核心网的鉴权、完保、加密参数 的调整来解决问题。
网站客服QQ:2055934822
金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号