LTE Layer 2协议分析007——DRX流程

URA_PCH
out of
in
service service
CELL_PCH
out of
in
service service
Cell reselection
Release RRC Connection
Establish RRC Connection
CELL_DCH
CELL_FACH
out of
in
service service
SRB1承载）
– RRCConnectionSetupComplete 和 RRCConnectionReconfiguration （由SRB1承载）
– RRCConnectionSetupComplete（只携带NAS的初始直传消息）
UE各状态说明
RRC状态
状态 RRC_IDLE
RRC_CONNECTED
Camped-state (idle)
RRC协议状态的比较
• TD-SCDMA与TD-LTE协议状态比较
TD-LTE
E-UTRA Connected
Mode
UTRA: Inter-RAT Handover
E-UTRA: inter-RAT Handover
TD-SCDMA
UTRA RRC Connected Mode
小区内UE标识（1）
标识类型
RA-RNTI
T-CRNTI
C-RNTI SPSCRNTI P-RNTI
SI-RNTI
应用场景
随机接入中用于指示接 收随机接入响应消息 随机接入中，没有进行 竞争裁决前的CRNTI 用于标识RRC Connect 状态的UE
LTE主要信令和流程

[转载]第三章 LTE MAC协议解读 --- 非连续接收（DRX）分享(2012-01-10 10:10:32)[删除]标签：转载原文地址：第三章 LTE MAC协议解读 --- 非连续接收（DRX）分享作者：LTE通信人家3.4.3DRX(非连续接收)DRX，在一段时间里停止监听PDCCH信道，DRX分两种：IDLE DRX，顾名思义，也就是当UE处于IDLE状态下的非连续性接收，由于处于IDLE状态时，已经没有RRC连接以及用户的专有资源，因此这个主要是监听呼叫信道与广播信道，只要定义好固定的周期，就可以达到非连续接收的目的。

但是UE要监听用户数据信道，则必须从IDLE状态先进入连接状态。

而另一种就是ACTIVE DRX，也就是UE处在RRC-CONNECTED状态下的DRX，可以优化系统资源配置，更重要的是可以节约手机功率，而不需要通过让手机进入到RRC_IDLE 模式来达到这个目的，例如一些非实时应用，像web浏览，即时通信等，总是存在一段时间，手机不需要不停的监听下行数据以及相关处理，那么DRX就可以应用到这样的情况，另外由于这个状态下依然存在RRC连接，因此UE要转到支持状态的速度非常快。

这里我们先介绍ACTIVE DRX，而IDLE DRX我打算放在呼叫那部分来介绍。

而要理解DRX，我们就必须理解下面要描述的几个定时器与概念（所有的时间都是基于子帧的，也就是ms为单位）：On duration TimerUE每次从DRX醒来后维持醒着的时间,UE在该段时间内会搜索PDCCH。

Inactivity TimerUE在醒着时每次成功解码HARQ初始发送的PDCCH后保持active的时间，它的意思就是，当UE收到的PDCCH指示的是一个UL/DL的初始传输，而不是重传。

UE在醒着时每次成功解码HARQ初始发送的PDCCH后保持active的时间Active TimeUE从DRX醒来后保持醒着的总时间，在此时间段，UE监听PDCCH，包括所有导致UE 处于ACTIVE的状态，比如是DRX周期开始“On Duration”，或者收到初始传输的PDCCH，或者是监听重传，等等，在36.321 5.7节，是这样定义ACTIVE TIME的，如果配置了DRX，那么ACTIVE Time 包括以下时间：∙onDurationTimer、drx-InactivityTimer、drx-RetransmissionTimer以及mac-ContentionResolutionTimer运行的时间，或者∙有SR（调度请求）已近发送到PUCCH，并且处于挂起的状态（也就是这个调度请求还没有满足，如此之类的）或者，∙对一个挂起的HARQ重传存在上行授权，并且在对应的HARQ 缓冲区里面有数据；或者∙在非竞争随机接入后，成功收到随机接入响应消息，此时应该有PDCCH发送给UE 指示一个新的传输，但是这个PDCCH还没有收到，此时UE还是必须处于ACTIVE状态HARQ RTT TimerUE预期DL Retransmission到达的最少间隔时间，也就是说重传最早会什么时候到，那么UE暂且不需要理会，也就是说这一段时间，改怎样就怎样，等到这个定时器超时了，那么它就要处于醒着的状态。

eMTC终端eDRX空闲过程的研究与实现李贵勇;黄俊杰【摘要】随着物联网设备接入蜂窝网,传统的长期演进(LTE)终端协议栈已不能满足物联网对低功耗和广覆盖的要求.根据第三代合作伙伴计划(3GPP)协议提出的增强型机器类通信(eMTC)系统,对 eMTC 系统终端协议栈空闲态延长的非连续接收(eDRX)过程中的寻呼和测量进行研究,提出了层一控制层(L1 C),并设计了L1 C空闲态下寻呼和测量的流程.通过可视化工作室(Visual Studio)和可扩展标记语言(XML)验证了设计的合理性与可行性.%As more devices in the Internet of Things connecting to the cellular network,the traditional LTEterminals'protocol stack can no longer meet the demand of low power consumption and wide coverage.Based on the enhanced Machine Type Com-munication (eMTC)system proposed by 3GPP in the protocol,the paper studies the paging and measurement of the extended Discontinuous Reception(eDRX)of the eMTC system in terminal side.We also propose the Layer 1-Control (L1C)and design the procedure of paging and measurement.Finally,we use Visual Studio and Extensible Markup Language(XML)to verify the rationality and feasibility of the design.【期刊名称】《光通信研究》【年(卷),期】2018(000)002【总页数】4页(P71-74)【关键词】协议栈;延长的非连续接收机制;层一控制层;可扩展标记语言【作者】李贵勇;黄俊杰【作者单位】重庆邮电大学通信与信息工程学院,重庆 400065;重庆邮电大学通信与信息工程学院,重庆 400065【正文语种】中文【中图分类】TN929.50 引言物联网要求更低复杂度、更低功耗的设备，更长的电池寿命，并且要求更大的覆盖范围来满足一些极端场景[1]，因此需要对传统的长期演进(Long Term Evolution，LTE)空闲下非连续接收(Discontinuous Reception，DRX)机制进行改进，从而满足物联网场景下的需求。

LTE信令流程解析李青春2014-7-8目录第一章协议层与概念6661.2.1NAS协议〔非接入层协议〕71.2.2RRC层〔无线资源控制层〕81.2.3PDCP层〔分组数据会聚协议层〕81.2.4RLC层〔无线链路控制层〕91.2.5MAC层〔媒体接入层〕91.2.6PHY层〔物理层〕10121314第二章主要信令流程152.1 开机附着流程15182.3 UE发起的service request流程2225262.5.1 切换的含义与目的262.5.2 切换发生的过程262.5.3 站内切换272.5.4 X2切换流程282.5.5 S1切换流程302.5.6 异系统切换简介332.6 CSFB流程332.6.1 CSFB主叫流程342.6.2 CSFB被叫流程352.6.3 紧急呼叫流程372.7 TAU流程382.7.1 空闲态不设置“ACTIVE〞的TAU流程392.7.2 空闲态设置“ACTIVE〞的TAU流程412.7.3 连接态TAU流程43442.8.1 专用承载建立流程442.8.2 专用承载修改流程462.8.3 专用承载释放流程48502.9.1 关机去附着流程502.9.1 非关机去附着流程512.10 小区搜索、选择和重选542.10.1 小区搜索流程542.10.1 小区选择流程542.10.3 小区重选流程55第三章异常信令流程593.1 附着异常流程603.1.1 RRC连接失败603.1.2 核心网拒绝613.1.3 eNB未等到Initial context setup request消息623.1.4 RRC重配消息丢失或eNB内部配置UE的安全参数失败633.2 ServiceRequest异常流程643.2.1 核心网拒绝643.2.2 eNB建立承载失败653.3 承载异常流程67673.3.2 eNB本地建立失败〔核心网主动发起的建立〕673.3.3 eNB未等到RRC重配完成消息，回复失败683.3.4 UE NAS层拒绝6970第四章系统消息解析714.1 系统消息724.2 系统消息解析734.2.1 MIB 〔Master Information Block〕解析734.2.2 SIB1 〔System Information Block Type1〕解析744.2.3 SystemInformation消息78第五章信令案例解析87875.2 流程中各信令消息解析885.2.1 RRC_CONN_REQ:RRC连接请求885.2.2 RRC_CONN_SETUP:RRC连接建立895.2.3 RRC_CONN_SETUP_CMP:RRC连接建立完成965.2.4 S1AP_INITIAL_UE_MSG:初始直传消息965.2.5 S1AP_INITIAL_CONTEXT_SETUP_REQ:初始化文本建立请求985.2.6 RRC_UE_CAP_ENQUIRY:UE能力查询1025.2.7 RRC_UE_CAP_INFO:UE能力信息1035.2.8 S1AP_UE_CAPABILITY_INFO_IND:UE能力信息指示1105.2.9 RRC_SECUR_MODE_CMD:RRC安全模式命令1185.2.10 RRC_CONN_RECFG:RRC连接重配置1195.2.11 RRC_SECUR_MODE_CMP:RRC安全模式完成1245.2.12 RRC_CONN_RECFG_CMP:RRC连接重配置完成1245.2.13 S1AP_INITIAL_CONTEXT_SETUP_RSP:初始化文本建立完成125 5.2.14 S1AP_ERAB_MOD_REQ:ERAB修改请求1265.2.15 RRC_DL_INFO_TRANSF:RRC下行直传消息1285.2.16 S1AP_ERAB_MOD_RSP:ERAB修改完成1295.2.17 RRC_CONN_RECFG:RRC连接重配置1305.2.18 RRC_UL_INFO_TRANSF:RRC上行直传消息1375.2.19 S1AP_UL_NAS_TRANS:上行NAS直传消息1385.2.20 RRC_CONN_RECFG_CMP:RRC连接重配置完成1395.2.21 RRC_CONN_RECFG:RRC连接重配置1405.2.22 RRC_CONN_RECFG_CMP:RRC连接重配置完成1425.2.23 RRC_MEAS_RPRT:RRC测量报告1435.2.24 RRC_UL_INFO_TRANSF:RRC上行信息传输1445.2.25 S1AP_UL_NAS_TRANS:上行NAS信息传输1445.2.26 S1AP_UE_CONTEXT_MOD_REQ:UE文本更改请求1465.2.27 S1AP_UE_CONTEXT_MOD_RSP:UE文本更改响应1475.2.28 RRC_CONN_REL:RRC连接释放1485.2.29 S1AP_UE_CONTEXT_REL_REQ:UE文本释放请求1505.2.30 S1AP_UE_CONTEXT_REL_CMD:UE文本释放命令1515.2.31 S1AP_UE_CONTEXT_REL_CMP:UE文本释放完成152概述本文通过对重要概念的阐述，为信令流程的解析做铺垫，随后讲解LTE中重要信令流程，让大家熟悉各个物理过程是如何实现的，其次通过异常信令的解读让大家增强对异常信令流程的判断，再次对系统消息的解析，让大家了解系统消息的特点和携带的内容。