9 LO_NAST3022_C01_1 TD-LTE接入问题分析

合集下载

LO_NAST3034_C01_0 TD-LTE与2G3G互操作解决方案

TD-LTE与2G/3G互操作解决方案1目录第1章TD-LTE与2G/3G互操作概述 (1)1.1 互操作背景 (1)1.2 互操作内容 (1)1.3 互操作发展步骤 (2)第2章TD-LTE与2G/3G互操作解决方案 (5)2.1 网络选择 (5)2.1.1 网络选择原理 (5)2.1.2 网络选择策略 (6)2.2 小区选择 (6)2.3 小区重选 (6)2.3.1 互操作小区重选原理 (6)2.3.2 互操作小区重选策略 (7)2.3.3 对现网的影响分析 (10)2.4 小区切换 (11)2.4.1 PS域切换（数据业务解决方案） (12)2.4.2 CS域切换（语音业务解决方案） (17)第3章TD-LTE与2G/3G互操作核心网演进 (23)3.1 2G/3G核心网架构 (23)3.2 TD-LTE核心网架构 (25)3.3 核心网演进步骤与策略 (26)第4章TD-LTE与2G/3G互操作网络改造分析 (29)4.1 2G/3G网络不升级 (29)4.2 2G/3G网络部分升级 (29)4.3 2G/3G网络全部升级 (30)第5章参考文献 (31)1第1章TD-LTE与2G/3G互操作概述1.1 互操作背景TD-LTE拥有支持高速数据业务、大吞吐率和高用户容量的优势，但暂不支持语音业务，TD-LTE在一段时间内，将只是作为核心商务区的连续覆盖。

TD-LTE的建设由热点城市和发达地区开始，在TD-LTE网络规模从小到大的发展过程中，必须利用现有的GSM,UMTS-SCDMA和UMTS网络进行有益补充。

GSM、UMTS和TD-LTE会在较长一段时间内共存。

如何有效利用已有的网络，建设一个GSM/UMTS/LTE紧密融合的网络，利用几张网络的优势，互为补充，发挥最大的综合优势是一项重要的课题。

图1-1 网络覆盖示意图网络之间的互操作技术是实现TD-LTE与2G、3G多网融合，优势互补的最重要的一项策略。

最新(完美版)04_LO_NAST3031_C01_0_TD-LTE切换问题分析与优化

TD-LTE切换问题分析课程目标：●了解TD-LTE切换概念●掌握TD-LTE测量时间类型及触发原理●掌握TD-LTE切换过程及信令流程●掌握切换相关参数及优化原则目录第1章切换概述 (1)1.1 切换流程介绍 (1)1.1.1 切换流程图 (1)1.1.2 切换分类介绍 (4)1.2 前台信令解析 (6)1.2.1 测量控制 (7)1.2.2 测量报告 (7)1.2.3 终端测量机制 (8)1.2.4 测量报告内容 (9)1.2.5 切换命令 (9)1.2.6 在目标小区随机接入（MSG1） (10)1.2.7 基站回应随机接入响应（RAR） (11)1.2.8 终端反馈重配完成，切换结束 (11)第2章切换优化整体思路 (13)2.1 测量报告发送后未收到切换命令 (15)2.2 目标小区MSG1发送异常情况 (18)2.3 接收RAR异常情况 (19)第3章切换相关常用参数汇总 (20)小区参考信号的功率 (20)中心UE的PDSCH与小区RS的功率偏差 (21)小区选择所需要的最小接收水平 (22)测量时的RSRP层3滤波系数 (22)Event Identity (23)小区个体偏移 (25)Time to Trigger (25)Hysteresis (26)事件上报次数 (27)事件上报周期 (28)最大上报小区 (29)第4章切换优化常见问题及案例 (30)4.1 漏配邻区 (30)4.1.1 前台分析漏配邻区的现象 (30)4.1.2 漏配邻区带来的影响 (36)4.1.3 漏配邻区处理方法 (37)4.2 无线环境引起的切换异常 (37)4.2.1 上行干扰引起的目标测接入困难 (37)4.2.2 环境复杂引起的切换问题 (50)4.3 上行失步导致掉话问题处理经验总结 (57)4.3.1 现象描述 (57)4.3.2 现象分析 (57)4.3.3 解决方法及验证 (61)4.3.4 经验总结 (62)第5章非正常情况引起的切换问题案例 (63)5.1 版本问题引起的切换异常 (63)5.1.1 高通LOG问题现象 (63)5.1.2 该问题带来的影响 (64)5.1.3 研发初步定位 (70)5.2 不同厂商切换差异 (70)5.2.1 问题现象 (70)5.2.2 问题分析 (70)5.2.3 问题总结 (74)图目录图 1-1 切换流程图 (1)图 1-2 站内切换信令流程图 (4)图 1-3 X2口切换信令流程图 (5)图 1-4 S1口切换信令流程图 (6)图 2-1 正常切换信令，CNT采集 (7)图 2-2 重配消息中的测量控制（RRC CONNECT RECONFIGRATION） (7)图 2-3 a3时间报告示意图 (8)图 2-4 测量报告内容 (9)图 2-5 切换命令 (10)图 2-6 MSG1 (10)图 2-7 MSG2 (11)图 2-8 切换执行过程 (11)图 2-9 MSG3 (12)图 3-1 切换问题分析整体思路 (14)图 3-2 发送测量报告后未收到切换命令处理流程 (17)图 4-1 多次测量报告现象 (31)图 4-2 第一个测量报告内容 (31)图 4-3 第四次测量报告内容 (31)图 4-4 切换命令 (32)图 4-5 源小区测量控制信息 (33)图 4-6 漏配邻区引起的掉话 (34)图 4-7 第一个测量报告内容 (34)图 4-8 源小区测量控制信息 (35)图 4-9 SINR (36)图 4-10 流量 (36)图 4-11 上行干扰问题点 (38)图 4-12 上行干扰引起的问题现象 (43)图 4-13 上行干扰引起的问题现象2 (44)图 4-14 上行干扰引起的问题3 (45)图 4-15 上行干扰问题验证 (45)图 4-16 上行干扰引起的集中掉话区域 (46)图 4-17 正常GPS后台查询图形 (47)图 4-18 异常GPS后台查询图形 (47)图 4-19 GPS失步闭塞小区配置 (49)图 4-20 覆盖引起的切换失败点1 (51)图 4-21 失败点RSRP (52)图 4-22 失败点信令 (52)图 4-23 覆盖引起的切换失败点2 (53)图 4-24 失败点信令 (53)图 4-25 失败点RSRP (54)图 4-26 覆盖引起的切换失败点3 (55)图 4-27 失败点信令 (55)图 4-28 失败点RSRP (56)图 5-1 切换命令 (63)图 5-2 事件上报 (63)图 5-3 切换前后RLM Report1 (64)图 5-4 切换前后RLM Report2 (64)图 5-5 华为与我司切换命令差异 (71)图 5-6 收到切换命令后在我司接入信令 (72)图 5-7 前台发送的重建立消息 (73)图 5-8 后台收到重建立消息 (73)第1章切换概述1.1 切换流程介绍1.1.1 切换流程图图 1-1 切换流程图Measurement Control测量控制，一般在初始接入或上一次切换命令中的重配消息里携带-Measurement Report测量报告，终端根据当前小区的测量控制信息，将符合切换门限的小区进行上报-HO Request源小区在收到测量报告后向目标小区申请资源及配置信息（站内切换的话为站内交互，站间切换会使用X2口或者S1口，优先使用X2口）-HO Request Ack目标小区将终端的接纳信息以及其它配置信息反馈给源小区-RRC Connection Reconfiguration将目标小区的接纳信息及配置信息发给终端，告知终端目标小区已准备好终端接入，重配消息里包含目标小区的测量控制-SN Status Transfer源小区将终端业务的缓存数据移至目标小区-Random Access Preamble终端收到第5步重配消息（切换命令）后使用重配消息里的接入信息进行接入-Random Access Response目标小区接入响应，收到此命令后可认为接入完成了，然后终端在RRC层上发重配完成消息（第9步）-RRC Connect Reconfiguration complete（HO Confirm）上报重配完成消息，切换完成-Release Resource当终端成功接入后，目标小区通知源小区删除终端的上下文信息1.1.2 切换分类介绍按照我们实际情况，切换可分为eNb站内切换，X2口切换以及S1口切换，下边分别进行介绍（下边介绍的所有切换都是基于已经接入且获取到了测量配置后）1.1.2.1 站内切换站内切换过程比较简单，由于切换源和目标都在一个小区，所以基站在内部进行判决，并且不需要向核心网申请更换数据传输路径图 1-2 站内切换信令流程图1.1.2.2 X2口切换用于建立X2口连接的邻区间切换，在接到测量报告后需要先通过X2口向目标小区发送切换申请（图1-1第3步），得到目标小区反馈后（图1-1第4步）才会向终端发送切换命令，并向目标测发送带有数据包缓存、数据包缓存号等信息的SNStatus Transfer 消息，待UE在目标小区接入后，目标小区会向核心网发送路径更换请求，目的是通知核心网将终端的业务转移到目标小区，X2切换优先级大于S1切换图 1-3 X2口切换信令流程图1.1.2.3 S1口切换S1口发生在没有X2口且非站内切换的有邻区关系的小区之间，基本流程和x2口一致，但所有的站间交互信令都是通过核心网S1口转发，时延比X2口略大图 1-4 S1口切换信令流程图1.2 前台信令解析切换的大部分问题可在前台信令中进行分析，本文以前台信令为主介绍整个切换流程及问题分析思路图 1-5 正常切换信令注意：这里的重配完成只是组包完成，实际是在MSG3里发送的前台信令窗的交互过程主要是是图1-1里的1、2、5、7、8、9几步，现在来分别介绍1.2.1 测量控制测量控制信息是通过重配消息里下发的，测量控制一般存在于初始接入时的重配消息和切换命令中的重配消息中。

TD-LTE接入问题分析与优化

下行信道质量如何？RSRP？SINR？是否是PDCCH没收到？是否多次收到PDCCH，而没有收到PDSCH。
分析将MAC Contention Resolution Timer由48sf改为64sf，使得UE发送 MSG3后等待接收MSG4的时间由48ms增大到64ms，增加弱场起呼时 UE接收MSG4的概率。
初始接入的信令流程
消息1～5随机接入过程，建立 RRC连接。
消息6~9 初始直传建立S1连接，完成这些过程标志着NAS signalling connection建立完成。
消息10~12 UECapabilityEnquiry 过程。
消息13~14安全模式控制过程。
初始接入的信令流程
消息15~17 RRC Connection Reconfiguation ，E-RAB建立过程。
接入问题案例分析-2
修改CRT定时器为64ms后，通过MSG4 Report和LTE MAC RACH Attemt看到基于竞争的随机接入成功。
接入问题案例分析-1
参数调整
通过降低“eNode B对PRACH的绝对前缀检测门限”，提高 PRACH检测概率，提升MSG1正确解调的概率。
参数：eNode B对PRACH的绝对前缀检测门限 PRACH Absolute Preamble Threshold for Enode B Detecting Preamble
下行：
1. UE侧收不到以RA_RNTI加扰的PDCCH，检查下行RSRP是否>119dBm，SINR>-3dB，下行覆盖问题通过调整工程参数、RS功率、 PCI等改善。
2. PDCCH相关参数调整：比如增大公共空间CCE聚合度初始值。
接通率的分析思路

TD_LTE接入失败分析

LTE接入失败问题分析1问题描述在某次测试中发现UE 在PCI126、127 小区做业务时，多次发起RRC Connection Request 消息，但始终无法接入。

2问题原因分析问题信令：如上图UE 在问题小区多次发起Service Requset 随后发起RRC Connection Request 。

但系统侧一直未响应RRC Connection Setup 。

通过后台跟踪打印发现网络侧未收到Message3 ，如下图：随机接入排查思路：步骤一：在发送上行接入前导序列之前，终端应该已经和系统下行同步好了，下行同步意味着UE 获得了帧同步以及系统广播消息，但是上行并没有同步。

通过前导序列，让eNB 知道存在一个终端试图跟基站建立连接；根据确认的前导分配相应的资源用于发送消息3 （MSG3 ）；步骤二：eNB 通过时隙调整确保上行同步，也就是发送time-advance 消息实现；同时分配上行资源，这些内容就是由随机接入响应消息携带；步骤三：在已经分配的资源上发送用户ID ，以及相应的UL-SCH 信息用于发送用户ID 以及RRC 连接请求之类的等基本信息，也就是所谓的消息3 了（MSG3 ），具体内容跟用户所处的状态相关；步骤四：通过DL-SCH 发送冲突解决消息到终端。

只有第一步是纯粹的物理层过层，后面三个步骤跟普通的数据传输过程没有区别，看MAC 协议经常看到MSG3 或者MSG4 等等，因为在随机接入的过程中，这些消息的内容不是固定，有时候可能携带的是RRC 连接请求，有时候可能会带一些控制消息甚至业务数据包，因此简称为消息3 之类，其意思就是第三条消息。

从DSP 监控可以判断MSG2 网络侧已经发送，因为没有内部消息无法判断UE 是否正确解析MSG2 ，在层3 中可以看到MSG3 UE 已经发送，所以认为MSG3 消息问题，该问题针对MSG3 发布上去进行分析。

现场排查手段：1. 首先对该站点的告警进行过滤，该站点无任何告警。

LTE常见告警故障分析教学内容

LTE常见告警故障分析1.1光口接收链路故障原因分析：•光纤有损坏•光模块问题•ODF架处法兰盘有光损•近端、远端之间的线路故障处理方法：•根据所出的光口接收链路故障的位置(基带处理板光口或RRU光口)更换相应的光纤•同上，更换相应的光模块•排除以上2种原因外，可试更换光纤连接处的法兰盘•可通过在远近端处互相发光、收光，以此判断线路是否存在故障1.2RRU链路断原因分析：•RRU掉电•光路故障•光模块损坏•基带板故障引起RRU链路断处理方法：•检查RRU是否上电•如果RRU正常上电，排除光模块或光路是否有光损•观察基带板指示灯闪烁状态是否正常，如异常，则先插拔基带板使其复位；如果以上因素全都排除，则更好RRU1.3天馈驻波比异常原因分析：•RRU通道接口与天线端口之间连接的跳线未连接好•设备接口渗进雨水• RRU与天线端口之间连接的跳线有损坏•RRU内部出现故障处理方法：•检查RRU通道接口与天线端口之间连接的跳线是否连接好，重新连接•检查RRU故障通道口内是否有渗进雨水，如有，需清理干净；另外设备被雨水浸泡后会有所腐蚀生锈，可用砂纸打磨后重新连接•如无以上情况，请尝试更换跳线，之后重启RRU，查看是否还会出现驻波比告警•通过以上操作后再出现，直接更换RRU1.4天线校正失败原因分析：•LTE天线校正序列发射电平上下行为同一个DV参数，经过研发部门分析600版本中默认的下行校正序列发射电平过大，有可能会导致部分RRU校正序列接收电平饱和，导致校正失败。

处理方法：•修改DV参数降低校正序列发射电平后，可以规避由此造成的天线校正失败问题。

•经过修改DV参数仍然出现此告警，则更换RRU室外的话TD通常是通道馈线分为9根除了八个通道之外还有一个校准线，如果那个接错了会造成通道功率校准失败，驻波比忽高忽低。

可能是校准线损坏，更换校准跳线就行了；也可能是校准通道故障，这个就要更换RRU 设备了。

1.5智能天线校准异常原因分析：•智能天线校准线缆连接故障•RRU内部故障处理方法：•更换RRU校准通道跳线•更换RRU校准通道跳线无效，直接更换RRU1.6输入电压异常原因分析：•输入电压异常一般常见于拉远站，由于室外交转直电源柜供电功率不足或接电异常会导致出现此故障处理方法：•检查设备电源线与电源柜是否有连接问题•如连接没问题，则考虑电源柜所带设备是否过多，可减少连接的设备或增加电源柜解决此问题1.7基站退出服务原因分析：•基带板故障•如果1个基站的所有RRU光口链路故障、设备掉电或其它原因导致RRU链路断，则会引起基站退出服务•数据有误：无线参数—>TD-LTE—>资源接口配置—>基带资源:未调整RRU通道口为2即LTE通道处理方法：•检查BBU基带板指示灯闪烁状态是否正常，可试插拔复位，待查看告警是否消除•若基带板无故障，通过光功率计等测试仪确定光路光信号是否有衰减，查看整站RRU是否有掉电情况发生•以上情况均排除后，检查后台数据是否有误即资源接口配置—>基带资源:查看RRU通道口(LTE通道)是否已调整为2 (此情况只适用于室分的双通道RRU) 1.8内部故障原因分析：•RRU内部时钟类出现异常处理方法：•先查看故障小区是否存在其它告警，如：驻波比告警、RRU功率检测异常、输入电压异常等，若有，先排除此类告警•若无其它告警，则对设备下电复位，此告警如再次出现，直接更换RRU 1.9基站同步异常、没有可用的空口时钟源、GNSS天馈链路故障原因分析：•一个基站如果GPS出现故障，这3种告警则会同时出现•未连接GPS•已连接GPS，但室内外接头处接触不良•GPS馈线有弯折等硬伤•主控板损坏处理方法：•首先应检查机房和室外是否连接GPS•如已连接，则检查室内外GPS直弯头处连接情况，重新连接•重新连接后告警仍不能消除，则需检查GPS馈线是否有弯折类的硬伤，若有，则更换新的馈线•以上因素排除后告警仍不能消除，则直接更换主控板1.10设备掉电原因分析：• RRU所接市电停电•有市电但RRU因内部故障不上电处理方法：•先检查RRU所接市电是否有电，如果停电，待市电恢复后查看告警•如果有市电，但RRU未显示上电，掉电重新上电RRU若仍无反映直接更换RRU 1.11单板通讯链路断原因分析：•单板掉电•BBU的PM板供电功率不足•主控板故障导致其他单板不能正常上电•单板软件故障、反复重启处理方法：•热插拔单板复位后，查看单板是否正常•如果插拔无反应，计算PM板供电功率是否满足当前BBU 的所有单板所需功率•如果PM板无本身无故障，供电功率也满足，需查看主控板是否正常•以上因素排除后告警仍不消除，直接更换该单板1.12硬件类型和配置不一致原因分析：•实际设备连接的单板与OMC配置的单板类型不一致处理方法：•根据实际需要，更换前台所插单板或修改后台配置的单板类型1.13网元断链告警原因分析：•前后台数据不一致•机房设备掉电•传输线路光缆断•主控板故障处理方法：•在站点已开通的情况下出现网元断链，需检查后台数据是否有修改导致前后数据不一致•如果数据一致，核实机房设备是否掉电•核查传输线路光缆是否断开•排除以上因素外，核实BBU的主控板是否出现故障(软件故障、单板电路损坏等)，如果有此类故障，更换主控板1.141.15X2断链告警以下三条都会影响切换的，无论出现哪条，都代表X2链路出现了问题。

TD-LTE站点华为设备常见故障告警处理

T D-L T E(4G)站点华为设备常见故障告警处理(总11页)本页仅作为文档封面，使用时可以删除This document is for reference only-rar21year.MarchFAQ-TD站点常见故障告警处理一、射频单元RRU类告警....................................................... 错误!未定义书签。

、射频单元驻波告警................................................... 错误!未定义书签。

、射频单元通道异常告警........................................... 错误!未定义书签。

、射频单元校准通道异常告警................................... 错误!未定义书签。

、射频单元通道幅相一致性告警............................... 错误!未定义书签。

、射频单元发射通道增益异常告警........................... 错误!未定义书签。

、射频单元下行输出功率异常告警........................... 错误!未定义书签。

、射频单元硬件故障告警........................................... 错误!未定义书签。

、射频单元时钟异常告警........................................... 错误!未定义书签。

、射频单元光接口性能恶化告警............................... 错误!未定义书签。

、BBU连接的射频单元交流掉电告警........................ 错误!未定义书签。

、射频单元配置但不可用告警................................... 错误!未定义书签。

LTE接入问题分析

1、无线接通率指标无线接通率=RRC连接建立成功率*E-RAB建立成功率=(RRC连接建立完成次数/RRC连接请求次数（不包括重发）)*E-RAB建立成功总次数/E-RAB建立尝试总次数*100%1.1、RRC连接建立成功率RRCSetupSuccessRate=（L.RRC.ConnReq.Succ）/(L.RRC.ConnReq.Att)*100%话统统计方法：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_Req消息。

Case2：T300超时后，UE仍未收到RRC_Conn_Setup，UE重新搜网，发起初始接入，UeID是取0~239的随机值或上层下发的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 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.ConnReq.Att.Mt 加1。

1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。

TD-LTE接入问题分析课程目标：●掌握LTE随机接入基本过程●理解LTE 随机接入主要参数●理解PRACH信道规划思路●掌握一般接入问题的分析思路●掌握常见接入故障的解决方法错误！文档中没有指定样式的文字。

中兴通讯版权所有未经许可不得扩散2015版权所有©中兴通讯股份有限公司第I 页目录第1章初始接入概述 (1)1.1 初始接入信令流程 (1)1.2 随机接入信令IE 查看 (3)第2章接通率分析思路 (6)2.1 随机接入问题分析 (6)2.1.1 MSG1发送后是否收到MSG2 (8)2.1.2 MSG3是否发送成功 (9)2.1.3 MSG4是否正确接收 (9)2.2 鉴权、加密问题分析 (10)2.3 E-RAB 建立问题分析 (10)第3章接入问题案例解析 (11)3.1 MSG1多次重发未响应 (11)3.1.1 问题现象 (11)3.1.2 问题分析和解决 (12)3.1.3 总结 (16)3.2 MSG4冲突检测定时器超时 (17)3.2.1 问题现象 (17)3.2.2 问题分析 (19)3.2.3 解决方法和验证 (24)错误！文档中没有指定样式的文字。

第II页2015版权所有©中兴通讯股份有限公司中兴通讯版权所有未经许可不得扩散图目录图1-1 初始接入信令流程图 (1)图1-2 SIB2 rach_Config (3)图1-3 SIB2 Prach_Config (4)图1-4 CNT中msg1截图 (5)图2-1 接通率分析思路 (6)图2-2 基于竞争的随机接入 (7)图2-3 MSG1分析思路 (8)图2-4 MSG4 fail分析思路 (10)图3-1 MSG1多次发送未响应 (11)图3-2 MSG1无响应时的RSRP (12)图3-4 msg4 fail(QCA T) (19)图3-5 msg4 fail cause(QCAT) (20)图3-6 正常起呼随机接入过程(QCA T) (20)图3-7 正常起呼PDCCH decoding Result(QCAT) (21)图3-8 正常起呼PDSCH统计(QCAT) (21)图3-9 多次PDCCH未收到PDSCH(QCAT) (21)图3-10 UE收到第一次PDCCH的解码(QCAT) (22)图3-11 UE收到第二次PDCCH的解码(QCA T) (22)图3-12 UE未收到PDSCH(QCAT) (23)图3-13 UE未收到PDCCH的消息流程(QCAT) (23)图3-14 UE未收到PDSCH(QCAT) (24)图3-15 第一次msg4 fail，随机接入重发后接入成功(QCA T) (24)图3-16 随机接入重发后收到PDSCH(QCAT) (25)图3-17 第二次msg4 fail，随机接入重发后接入成功(QCA T) (25)错误！文档中没有指定样式的文字。

1.1 初始接入信令流程初始接入信令流程如错误！未找到引用源。

所示。

消息1～5随机接入过程，建立RRC 连接。

消息6~9 初始直传建立S1连接，完成这些过程即标志着NAS signalling connection 建立完成，见24.301。

消息10~12 UECapabilityEnquiry 过程。

消息13~14安全模式控制过程。

消息15~17 RRC Connection Reconfiguation ，E-RAB 建立过程。

关于信令内容详解，参见文档《TD-LTE 基本信令流程》图 1-1 初始接入信令流程图错误！文档中没有指定样式的文字。

随机接入开始之前需要对接入参数进行初始化，此时物理层接受来自高层的参数、随机接入信道的参数以及产生前导序列的参数，UE 通过广播信息获取PRACH 的基本配置信息。

RACH 所需的信息在SIB2的公共无线资源配制信息（radio Resource Config Common ）发送，如图1-2，图1-3所示：图 1-2 SIB2 rach_Config错误！文档中没有指定样式的文字。

●PRACH初始前缀目标接收功率PREAMBLE_INITIAL_RECEIVED_TARGET_POWER ：-110dBm；基站侧期望接收到的PRACH功率●PRACH前缀重传的最大次数PREAMBLE_TRANS_MAX 8；●随机接入响应窗口RA-Response Window Size 索引值7，范围{2、3、4、5、6、7、8、10}，索引值7对应10sf,即UE发送Msg1后,等待Msg2的时间10ms,超时后重发。

●MAC冲突解决定时器MAC Contention Resolution Timer：索引值7对应64sf，范围{2、3、4、5、6、7、8、10}；即UE发送Msg3,等待Msg4的时间64ms,超时后随机接入失败。

●MSG3 HARQ的最大发送次数：maxHARQ-Msg3Tx 3；即UE发送Msg3,如果没收到ACK,重发Msg3,同时重启MAC冲突解决定时器。

●本小区的逻辑根序列索引root Sequence Index 80，该参数为规划参数；●随机接入前缀的发送配置索引Prach Config Index 6；●循环移位的索引参数zeroCorrelationZoneconfig 4；UE获取PRACH相关配置后，发起随机接入，在MSG1消息里可以检验UE是否按照系统消息携带的参数进行随机接入，如图1-4所示：图1-4 CNT中msg1截图根据小区下发的PRACH config，UE采用随机接入前导序列为49，根序列为649进行接入。

可以看到UE采用前导序列format 0，随机接入请求在系统帧907\子帧2上发送，随机接入响应的接收窗从SFN\SF：907\5到SFN\SF：908\5，窗长为10ms，与“随机接入响应窗口RA-Response Window Size”配置10sf一致。

目前用户量较少E-RAB建立几乎没有失败的现象，而随机接入过程出现的问题较多，导致RRC连接无响应，引起起呼失败，所以解决随机接入失败问题是当前提升接通率的关键。

图2-1 接通率分析思路2.1 随机接入问题分析随机接入分为基于冲突的随机接入和基于非冲突的随机接入两个流程，其区别为针对两种流程其选择随机接入前缀的方式。

初始接入采用基于竞争的随机接入，切换采用非竞争的随机接入。

图 2-2 基于竞争的随机接入（1） MSG 1：UE 在PRACH 上发送随机接入前缀；（2） MSG2：ENB 的MAC 层产生随机接入响应，并在PDSCH 上发送；（3） MSG3：UE 的RRC 层产生RRC Connection Request 并映射到PUSCH上发送；（4） MSG4：RRC Connection Setup 由ENB 的RRC 层产生，并映射到PDSCH上发送。

至此，基于竞争的随机接入冲突解决完成，UE 的RRC 层生成RRC Connection Set up Complete 并发往eNB 。

从前台UE 侧角度分析随机接入失败发生的阶段： 1. MSG1发送后是否收到MSG2； 2. MSG3是否发送成功； 3.MSG4是否正确接收。

若收不到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.1.2 MSG3是否发送成功根据随机接入流程，UE收到MSG2后若没有发出MSG3，检查MSG2带的授权信息是否正确；若UE已发出MSG3的PUSCH，结合基站侧信令查看EnodeB是否收到到RRC Connection Request，若基站侧已发出RRC Connection Setup前台未收到，如2.1.3节MSG4过程分析；若基站侧RRC Connection Request未收到，说明上行存在问题；1. 检查MTS上行通道的接收功率是否>-99dBm，若持续超过-99dBm，解决上行干扰问题。