TD-LTE接入时延

h151346

                 


TD-LTE接入时延
优化指导书




法律声明

若接收中兴通讯股份有限公司（以下称为“中兴通讯”）的此份文档，即表示您已同意以下条款。若不同意以下条款，请停止使用本文档。

本文档版权所有中兴通讯股份有限公司。保留任何未在本文档中明示授予的权利。文档中涉及中兴通讯的专有信息。未经中兴通讯事先书面许可，任何单位和个人不得复制、传递、分发、使用和泄漏该文档以及该文档包含的任何图片、表格、数据及其他信息。

和 是中兴通讯的注册商标。中兴通讯产品的名称和标志是中兴通讯的商标或注册商标。在本文档中提及的其他产品或公司名称可能是其各自所有者的商标或注册商标。在未经中兴通讯或第三方权利人事先书面同意的情况下，阅读本文档并不表示以默示、不可反言或其他方式授予阅读者任何使用本文档中出现的任何标记的权利。

本产品符合有关环境保护和人身安全方面的设计要求，产品的存放、使用和弃置应遵照产品手册、相关合同或相关国法律、法规的要求进行。

本文档按“现状”和“仅此状态”提供。本文档中的信息随着中兴通讯产品和技术的进步将不断更新，中兴通讯不再通知此类信息的更新。
中兴通讯股份有限公司
地址:        中国深圳市科技南路55号
邮编        518057
网站:        http://support.zte.com.cn

邮箱:        doc@zte.com.cn

       





版本更新说明

产品版本        资料版本        资料编号        资料更新说明
TD-LTE_V2.0.030P02B10.1118                        手册第一次发行
                       
                       




作者
资料版本        日期        作者        审核者        批准者
1.0        2011-12-5        王建国        李廉、袁海军       
1.1        2011-12-20        王建国        袁海军,李毅,周浩,申婷       
1.2        2012-1-4        王建国        袁海军        袁海军


适用对象：TD-LTE性能相关工作人员

使用建议：在阅读本文档之前，建议先了解下面的知识和技能：
序号        知识技能        参考资料
1        TD- LTE基本信令流程        《TD-LTE基本信令流程》
2        TD-LTE基本原理和关键技术        《TD-LTE基本原理和关键技术V3.0》
3        TD-LTE 覆盖优化        《TD-LTE 覆盖优化指导书V1.7》

后继资料：在阅读完本文档之后，你可能需要下面资料：
序号        参考资料        资料说明
1        《TD-LTE 接入优化指导书》        介绍TD-LTE系统接入问题优化的思路和案例
2        《TD-LTE 切换优化指导书》        介绍TD-LTE系统切换问题优化的思路和案例
3        《TD-LTE 覆盖优化指导书》        介绍TD-LTE系统覆盖问题优化的思路和案例
关于这篇文档
摘要
章节        描述
1  随机接入概述
介绍随机接入的原理知识
2  接入时延问题分析思路
重点分析随机接入中,RRC建立过程遇到的问题
3  接入时延案例分析
分享T1项目中接入时延案例
附录A  参考资料
后续补充

目录
1        接入流程概述        1
1.1        接入信令流程        1
1.2        前台随机接入信令详解        3
2        接入时延分析思路        5
2.1        随机接入问题分析        6
2.1.1        MSG1发送到收到MSG2时延        8
2.1.2        收到MSG2到发送MSG3时延        10
2.1.3        发送MSG3到收到MSG4时延        11
2.2        核心网相关问题分析        12
2.2.1        传输时延        12
2.2.2        基站处理时延        12
2.2.3        核心网处理时延        12
2.3        E-RAB建立问题分析        12
3        接入时延案例解析        12
3.1        MSG1多次重发导致时延增加        12
3.1.1        现象描述        12
3.1.2        现象分析        13
3.1.3        解决方法及验证        16
3.1.4        总结        17
附录A        接入时延指导书中流程图文件        18

图目录
图 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  TD-LTE上行行时隙配比图        8
图 2 4  MSG1问题分析思路        9
图 2 5  MSG3问题分析思路        10
图 2 6  MSG4 问题分析思路        11
表目录
表 2 1  RRC建立时分段建议最大值说明        8

1        接入流程概述
在TD-LTE系统中，处于IDLE状态的UE高层发起attach request或Service Request触发物理层初始随机接入，建立RRC连接，再通过初始直传建立传输NAS消息的信令连接，最后建立E-RAB的过程称为接入过程。
1.1        接入信令流程
初始接入信令流程如图 1 1所示。
消息1～5随机接入过程，建立RRC连接。
消息6~9 初始直传建立S1连接，完成这些过程即标志着NAS signalling connection建立完成，见3GPP协议24.301。
消息10~12 UECapabilityEnquiry过程。
消息13~14安全模式控制过程。
消息15~17 RRC Connection Reconfiguation ，E-RAB建立过程。
关于信令内容详解，参见文档《TD-LTE基本信令流程》
图 1 1  初始接入信令流程图


1.2        前台随机接入信令详解
在LTE系统中，随机接入过程直接影响接入时延，以下着重介绍PRACH相关信元的查看。
随机接入开始之前需要对接入参数进行初始化，此时物理层接受来自高层的参数、随机接入信道的参数以及产生前导序列的参数，UE通过广播信息获取PRACH的基本配置信息。
RACH所需的信息在SIB2的公共无线资源配制信息（radio Resource Config Common）发送，如图1-2，图1-3所示：
图 1 2  SIB2 rach_Config

主要包含以下参数信息
        基于竞争的随机接入前导的签名个数60；即可用前导个数60.
        Group A中前导签名个数56；即中心用户可用前导个数.
        PRACH的功率攀升步长POWER_RAMP_STEP 2dB。
        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,超时后重发Msg1.
        MAC冲突解决定时器MAC Contention Resolution Timer：索引值7，范围{2、3、4、5、6、7、8、10},索引值7对应64sf；即UE发送Msg3后,等待Msg4的时间最长为64ms,超时后随机接入失败.
        MSG3 HARQ的最大发送次数：maxHARQ-Msg3Tx 3；即UE发送Msg3后,如果没有收到ACK,UE将重发Msg3,同时重启MAC冲突解决定时器-MAC Contention Resolution Timer.
图 1 3  SIB2 Prach_Config

主要包含以下参数信息：
        本小区的逻辑根序列索引 root Sequence Index 80，该参数为规划参数,相邻小区不能相同.
        随机接入前缀的发送配置索引Prach Config Index 6,决定PRACH随机接入前缀发送的时间和频点.
        循环移位的索引参数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一致。
RA RNTI-随机接入无线网络临时标识(Random Access Radio Network Temporary Identifier):
只存在于随机接入阶段的Msg1到Msg2阶段,UE根据特定算法产生该值,通过Msg1带给ENodeB,ENodeB再用该值对Msg2加扰,UE只有收到Msg2中携带的相同的RA RNTI,才能正确解调PDCCH.
  提示1: 更多关于RA-RNTI知识,可参考3GPP协议36321中5.1.4Random Access Response reception章节
2        接入时延分析思路
根据初始接入的信令流程分解UE接入过程为三个阶段：
        RRC建立过程，
        与核心网相关的初始直传和安全模式控制过程，
        RRC重配建立E-RAB的过程。
当前工具不支持信令的分段,各段时延需要运用EXCEL表格进行手工统计。
目前用户量较少,而且E-RAB建立过程比较稳定，只是随机接入过程出现的问题较多，存在多次发送Msg1现象.所以解决随机接入时延问题是当前接入时延的关键。
图 2 1  接入时延分析思路

2.1        随机接入问题分析
随机接入分为基于竞争的随机接入和基于非竞争的随机接入两个流程，其区别为针对两种流程其选择随机接入前缀的方式。前者为UE从基于竞争的随机接入前缀中依照一定算法随机选择一个随机接入前缀；后者是基站通过RRC重配消息给UE指派非冲突的随机接入前缀。初始接入采用基于竞争的随机接入，切换采用非竞争的随机接入。
图 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侧角度分析随机接入时延的3个阶段：
1.        MSG1发送到收到MSG2时延； 建议最大值14ms
2.        收到MSG2到发送MSG3时延；建议最大值 2ms
3.        发送MSG3到收到MSG4时延。建议最大值22ms
  注意:此处提出的建议最大值是在上下行时隙配比为2时(即上下行时隙1:3配置)的时延情况,不同的配置,时延会有所区别.
图 2 3  TD-LTE上行行时隙配比图

  提示:文中建议最大值的说明:
表 2 1  RRC建立时分段建议最大值说明
        MSG1->RAR        MSG2->MSG3        MSG3->MSG4
典型时延        10        2        20
裕量        15*0.25                20*0.1
1.        MSG1->RAR阶段,考虑到Msg1重发概率为25%,重发间隔是15ms,该阶段的时延预留15*0.25=3.75,由于UE时延精度是1ms,向上取整得到4ms.
2.        其它阶段每段预留10%的信令重传概率,每段裕量向上取整可得到各阶段时延裕量,见表格.2-1.
2.1.1        MSG1发送到收到MSG2时延
如果MSG1发送到收到MSG2时延>14ms,需要进一步分析MSG1问题,思路如下:
图 2 4  MSG1问题分析思路

UE发出MSG1后未收到MSG2,等待超时后，UE按照Prach发送周期对MSG1进行重发,导致时延增加。若收不到MSG2的PDCCH，可分别对上行和下行进行分析：
上行：
1.        结合后台MTS的PRACH信道收包情况，确认上行是否收到MSG1。
2.        检查MTS上行通道的接收功率是否>-99dBm，若持续超过-99dBm，解决上行干扰问题，比如是否存在GPS交叉时隙干扰。
3.        PRACH相关参数调整：提高PRACH期望接收功率，增大PRACH的功率攀升步长，降低PRACH绝对前缀的检测门限。
4.         需要查看后台配置的Prach Config Index配置的PRACH发送间隔是否过长.如果配置过程会导致PRACH单位时间发送的概率较小,导致时延增加.

下行：
1.        UE侧收不到以RA_RNTI加扰的PDCCH，检查下行RSRP是否>-119dBm，SINR>-3dB，下行覆盖问题通过调整工程参数、RS功率、PCI等改善。
2.        PDCCH相关参数调整：比如增大公共空间CCE聚合度初始值.初始值越高,越容易解调。
  提示:关于PRACH内容详解，参见3GPP协议36211-880中-表 5.7.1-3: 前导格式0～ 4的随机接入配置（TDD）
表 5.7.1-3: 前导格式0～ 4的随机接入配置（TDD）
PRACH 配置序号        前导格式        每10 ms的密度
版本

0        0        0.5        0
1        0        0.5        1
2        0        0.5        2
3        0        1        0
4        0        1        1
5        0        1        2
6        0        2        0
7        0        2        1
8        0        2        2
2.1.2        收到MSG2到发送MSG3时延
收到MSG2到发送MSG3时延；建议最大值 2ms,因为这段时间只是UE内部处理时间,如果时延超过2ms,需要进行MSG3问题分析,思路如下:
图 2 5  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，解决上行干扰问题。
2.        检查RAR中携带的MSG3功率 参数是否合适，调整MSG3发送的功率。
2.1.3        发送MSG3到收到MSG4时延
发送MSG3到收到MSG4的时延,建议最大值22ms.如果该阶段时延超过22ms,需要考虑MSG4的问题,分析思路如下图：
图 2 6  MSG4 问题分析思路

1.        UE是否收到PDCCH，若没有收到PDCCH，从下行信号分析及参数两方面解决解决PDCCH接收问题。
2.        多次收到PDCCH后是否收到PDSCH？
（1）        确认收到的PDCCH是否重传消息，检查重传消息的DCI格式填写是否正确；
（2）        PDSCH收不到，检查PDSCH采用的MCS是否与当前信噪比匹配,常见问题是由于MCS过大,导致消息解错;检查PA参数配置;适当增大PDSCH的RB分配数。
2.2        核心网相关问题分析
2.2.1        传输时延
BBU和核心网之间经历了复杂的传输系统，信令在传输系统上的时延也是不容忽视的。传输时延测试方法如下
1.输入” telnet  ENodeB IP”,使用该命令登录到CC板
2.输入 /ushell 命令
3.输入用户名: zte
4.输入密码:  zte
5.用命令 brsping "MME IP",10(次数),200(长度)"EnodeB IP"
2.2.2        基站处理时延
待后续补充。
2.2.3        核心网处理时延
待后续补充。
2.3        E-RAB建立问题分析
从RRC重配到重配完成，主要取决于UE内部处理时延和重配消息大小。
3        接入时延案例解析
3.1        MSG1多次重发导致时延增加
3.1.1        现象描述
测试时间: 2011年10月25日
测试工具: CNT + 高通终端
后台版本: TD-LTE_V2.0.030P02B08.0926;
测试方法: 短呼测试
呼叫次数        最大时延        最小时延        平均时延        目标时延        备注
82        1069        410        564.8        56        通过协商,接入时延定义为RRC连接和重配两个阶段的合
测试结果:CNA只支持完整接入时延统计,RRC建立时延需要手工统计.
完整接入时延=RRC重配完成-RRC连接请求,可以由CNA统计得出结果.
问题在于福冈的测试结果和F7测试结果存在较大差距:
LOG日期        呼叫次数        最大时延        最小时延        平均时延
福冈测试数据        82        1069        410        564.8
F7测试数据        56        830        282        392.6
3.1.2        现象分析
3.1.2.1        诊断消息对比分析
通过抓取短呼LOG的诊断信令进行详细分析:
        ZTE 408ms                F7 412ms
时延        ATTACH REQ        时延        ATTACH REQ
1        RRC Connection Request        0        RRC Connection Request
0        MAC RACH Trigger        0        MAC RACH Trigger
5        Msg1        2        System Information Block Type1
2        System Information Block Type1        3        Msg1
8        RAR        10        RAR
0        Msg3        1        Msg3
20        Msg4        18        Msg4
0        MAC RACH Attempt        0        MAC RACH Attempt
0        RRC Connection Setup        0        RRC Connection Setup
2        ML1 Downlink Dedicated Configuration        1        ML1 Downlink Dedicated Configuration
0        ML1 Uplink Dedicated Configuration        0        ML1 Uplink Dedicated Configuration
0        ML1 Grant Manager Dedicated Configuration        0        ML1 Grant Manager Dedicated Configuration
0        MAC Configuration        0        MAC Configuration
1        RLC DL Configuration        0        RLC DL Configuration
0        RLC UL Configuration        1        RLC UL Configuration
0        PDCP DL Configuration        0        PDCP DL Configuration
0        PDCP UL Configuration        0        PDCP UL Configuration
0        RRC Connection Setup Complete        0        RRC Connection Setup Complete
                (9)        RRC Connection Setup
32        UE Capability Enquiry        125        DL InformationTransfer
2        UE Capability Information        2        UL Information Transfer
108        DL InformationTransfer        214        UE Capability Enquiry
3        UL Information Transfer        2        UE Capability Information
215        Security Mode Command        17        Security Mode Command
0        PDCP DL Configuration        3        PDCP DL Configuration
0        PDCP UL Configuration        0        PDCP UL Configuration
1        Security Mode Complete        0        Security Mode Complete
19        ML1 Radio Link Monitoring               
2        RRC Connection Reconfiguration        1        RRC Connection Reconfiguration
2        ML1 Downlink Dedicated Configuration        0        ML1 Downlink Dedicated Configuration
1
        ML1 Uplink Dedicated Configuration        0        ML1 Uplink Dedicated Configuration
0        ML1 Grant Manager Dedicated Configuration        1        ML1 Grant Manager Dedicated Configuration
0        MAC Configuration        0        MAC Configuration
1        RLC DL Configuration        0        RLC DL Configuration
0        RLC UL Configuration        0        RLC UL Configuration
0        PDCP DL Configuration        0        PDCP DL Configuration
0        PDCP UL Configuration        2        PDCP UL Configuration
0        RRC Connection Reconfiguration Complete        0        RRC Connection Reconfiguration Complete
诊断消息中可以看到具体是哪些信令等待时间较长,用黄色表格标出.
3.1.2.2        结合基站侧信令分析
在基站侧的信令中可以看到存在5次接入,全部接入成功,下表是1次接入的信令截取:
    ms        时延        Name
520        0        RrcConnectionRequest
530        10        RrcConnectionSetup
590        60        RrcConnectionSetupComplete
590        0        S1AP_InitialUeMessageMsg
700        110        S1AP_DownlinkNasTransportMsg
700        0        DlInformationTransfer
750        50        UlInformationTransfer
750        0        S1AP_UplinkNasTransportMsg
900        150        S1AP_InitialContextSetupRequestMsg
900        0        UeCapabilityEnquiry
940        40        UeCapabilityInformation
940        0        S1AP_UeCapabilityInfoIndicationMsg
940        0        SecurityModeCommand
980        40        SecurityModeComplete
960        0        RrcConnectionReconfiguration
980        20        RrcConnectionReconfigurationComplete

基站侧的3次接入的时延分析结果如下:
接入次数        T1_UU        T2_S1        T2_UU        T3_UU        合计
68        63.2        353.6        166.8        37.6        595.6
基站在发送安全模式命令后平均等待15.8ms,再发送RRC重配消息.等待25.6ms后收到安全模式完成消息,又等待12ms后才收到重配完成消息.
T1到T3时间段包含信令说明:
T1_UU        From    RrcConnectionRequest        ENodeB Receiving
　        Until   RrcConnectionSetupComplete        ENodeB Receiving
T2_S1        From    S1AP_InitialUeMessageMsg        ENodeB Sending
　        Until   SecurityModeComplete        ENodeB Receiving
T2_UU        UlInformationTransfer        UeCapabilityInformation
　        SecurityModeComplete
T3_UU        From   RrcConnectionReconfiguration　        ENodeB Sending
　        Until  RrcConnectionReconfigurationComplete        ENodeB Receiving
从上面的统计结果来看,接入时延有579.8ms,其中S1口的时延就占了353.6ms,共61%的时延.
3.1.2.3        前台信令分段分析
为了定位时延问题的原因,我们将CNT采集的诊断信令分为3个阶段:
1.        RRC连接阶段；
2.        与核心网交互阶段;
3.        RRC重配阶段.
分段后的福冈数据和F7数据统计对比如下:
UE侧        接入次数        T1_UU        T2_UU        T3_UU        合计
福冈        84        68.2        492.3        4.35        564.8
F7        56        37.4        351.6        3.6        392.6
T1到T3时间段包含信令说明:
T1_UU        From    RrcConnectionRequest        RRC连接阶段
　        Until   RrcConnectionSetupComplete       
T2_UU        UlInformationTransfer  UeCapabilityInformation        与核心网交互阶段
　        SecurityModeComplete       
T3_UU        From   RrcConnectionReconfiguration　        RRC重配阶段
        Until RrcConnectionReconfigurationComplete　       
通过对比,福冈的RRC建立过程时延要比F7多出30ms,和核心网信令交互的阶段时延相差140ms,总计多出170ms的接入时延.
        RRC连接阶段:
从RrcConnectionRequest到RrcConnectionSetupComplete
我司UE侧的时延受Msg1的影响很大,多发一次Msg1,延时就多20ms, 受MSG1重发影响,该段的接入时延均值在68.2ms,而F7的数据少有Msg1重发,平均时延在37.4ms
        与核心网交互阶段
从RrcConnectionSetupComplete 到RrcConnectionReconfiguration　之间,福冈基站侧在520.4ms左右,其中S1口时延占68%; UE侧的时延是492.3ms
而F7的基站侧时延无法统计,UE侧时延只有 351.6ms,差距140ms.
        RRC连接重配阶段:
从RrcConnectionReconfiguration到RrcConnectionReconfigurationComplete
该过程时延比较稳定,时延在4.35ms左右,F7的该段平均时延仅用3.6ms,两者差异较小.
3.1.3        解决方法及验证
从以上的分析结果来看,起呼时延主要存在两个阶段:
        S1口传输时延.
        Msg1重发导致时延.
3.1.3.1        基站侧S1口时延
从基站侧的数据分析结果来看:
接入次数        T1_UU        T2_S1        T2_UU        T3_UU        合计
68        63.2        353.6        166.8        37.6        595.6
在基站侧的时延统计中,S1口的时延最大,S1有两条信令的交互:
时延        Messege Name
110        S1AP_DownlinkNasTransportMsg
150        S1AP_InitialContextSetupRequestMsg

从下表LTE各网元主要功能中可以看出,此两条有较长时延的信令都是来自核心网MME网元.
E-Node B        MME        Serving GW        PDN GW
具有现3GPP Node B全部和RNC大部分功能，包括：
1.物理层功能
2.MAC、RLC、PDCP功能
3.RRC功能
4.资源调度和无线资源管理
5.无线接入控制
6.移动性管理        1.NAS信令以及安全性功能
2.3GPP接入网络移动性导致的CN节点间信令
3. 空闲模式下UE跟踪和可达性
4.漫游
5.鉴权
6. 承载管理功能（包括专用承载的建立）        1.支持UE的移动性切换用户面数据的功能
2.E-UTRAN空闲模式下行分组数据缓存和寻呼支持
3.数据包路由和转发
上下行传输层数据包标记        1.基于用户的包过滤
2.合法监听
3.IP地址分配
4.上下行传输层数据包标记
5.DHCPv4和DHCPv6（client、relay、server）
从基站的信令跟踪看时延较长的部分在S1口上,而且时延不固定,需要从基站测ping测试核心网MME,确定中间的传输时延情况.
但是由于局方OMC无远程登录基站权限,该段时延还需要WCP提供.
3.1.3.2        Msg1重发问题
通过咨询研发专家，将PRACH Absolute Preamble Threshold for Enode B Detecting Preamble 参数进行修改，将该值从2000改到50,修改前后对比:
LOG日期        接入次数        RRC建立        与核心网交互        RRC重配        合计        备注
11月29日        21        40.2        360.8        3.05        404.5        F7外场
12月02日        183        42.35        414.6        4.47        461.4        优化后结果
3.1.4        总结
接入时延问题的分析和定位主要来自测试数据的统计和详细信令的分析.可以运用EXCEL分段筛选出需要分析切换关键信令,计算出每段的时延情况.建议信令分段方法:
        RRC建立过程，
        与核心网交互的初始直传和安全模式控制过程，
        RRC重配建立E-RAB的过程。
在第1阶段中需要注意MSG1是否有重发,每次重发的间隔情况,MSG1消息的内容是否正确,终端发射功率释放正常, UE是否收到MSG2,需要查看PDCCH的调度,对应的PDSCH是否收到,CRC通过情况,MCS的调度情况以及MSG2解调正确与否.在第2阶段中包含有和核心网的信令交互,需要考虑和核心网之间传输的时延.
目前TD-LTE的时延问题主要在Msg1的重发, 由于Preamble漏检概率较高导致,该情况在后台通过修改门限参数PRACH Absolute Preamble Threshold for Enode B Detecting Preamble,将该值修改到50,Meg1重发问题基本得到解决.  
附录A         接入时延指导书中流程图文件