lte mac 协议

2013211543

3.2.1 MAC架构

    MAC协议层在LTE协议栈的位置如下所示：

图3.1 MAC层在LTE协议栈的位置

MAC实体在UE以及eNB上都存在的，它们主要处理如下传输信道：

-   广播信道（Broadcast Channel，BCH）；

-   下行共享信道（Downlink Shared Channel，DL-SCH）；

-   寻呼信道（Paging Channel，PCH）；

-   上行共享信道（Uplink Shared Channel, UL-SCH）；

-   随机接入信道（Random Access Channel,RACH）。

其实这些信道只是概念上的，因为传输信道的管理上不像逻辑信道那样设立专门的逻辑信道号，它只是从功能是进行了描述，因此实现上是否真正存在这样的传输信道，这在于个厂商自己。对于MAC层与物理层之间的处理，自然可以设置专门的通道，也可以只是通过一些简单的标识来处理，当然这也是信道的一种表现形式。

3.3 MAC格式（协议数据单元，格式与参数）

3.3.1概述

MAC PDU是八位对齐的比特流，最高位第一行的最左边比特，最低位在最后一行的最右边的比特；MAC SDU也是八位对齐的比特流，而MAC PDU里面的参数也是按照相同的顺序，高位在左边，低位在右边的顺序。

3.3.2 MAC PDU（DL-SCH和UL-SCH，除了随机接入响应）

MAC PDU具有一个头部，零个或多个SDU，零个或多个控制单元，可能还有填充位。

MAC头部与MACSDU都是可变长度的。

一个MAC PDU头部，MAC PDU头部可能有一个或多个子头部（subheader），每一个对应一个SDU、控制信息单元(control element)或者填充位。

一个普通MAC PDU子头部由六个域（R/R/E/LCID/F/L）组成，但是对于最后一个子头部、固定长度的MAC控制信息单元以及填充位对应的子头部，它们只包含四个域（R/R/E/LCID）

图3.3.2-1: R/R/E/LCID/F/L MAC 子头部

图3.3.2-2: R/R/E/LCID MAC 字头部

MAC PDU子头部的顺序跟MAC SDU，MAC控制信息单元以及填充部分出现的顺序是相应的。

MAC控制信息单元处于任何MAC SDU的前面。

填充部分一般放在MAC PDU的最后面，不过如果只有一个字节或者两个字节的填充部分时，它就放在MAC PDU的最前面。填充部分的内容可以是任何值，因为接收方会直接忽略掉这里面的内容。

对于一个UE，每次一个传输块只能携带一个MAC PDU，当然它也告诉大家，如果有两个传输块时，可以携带两个PDU（这就是当使用空间复用的传输方式时）。

图3.3.2-3: 具有头部、控制信息单元、SDUs以及填充部分的MAC PDU例子

3.3.3.1 MAC PDU RAR (随机接入响应)

随机接入响应对于的PDU遵循MAC PDU的规则，只是里面的内容有所不同而已，它可以包含多个随机接入响应。除了BACKOFF对应的子头部外，每一个子头部对应于一个RAR消息，如果存在BACKOFF指示，那么它对应的子头部要放在第一个MAC子头部的位置上，并且只能出现一次。一个RAR的PDU其实可以不包含RAR消息，而只是包含一个BACKOFF指示信息，如图3.3.3-4所示。

一个MAC PDU 子头部由三个头部域组成（E/T/RAPID），如图图3.3.3-1 所示。

但是对于BACKOFF 指示的子头部包含五个域（E/T/R/R/BI）如图图3.3.3-2 所示。

A MAC RAR 包含四个域R/TimingAdvance Command/UL Grant/Temporary C-RNTI。

最后也可能存在填充，这个是隐含的，跟通常的填充规则不同，通过传输块大小减去MAC头部大小以及RAR大小就可以推断出来。

图3.3.3-1: E/T/RAPID MAC 子头部

图3.3.3-2: E/T/R/R/BI MAC 字头部

图3.3.3-3: MAC RAR

图3.3.3-4:含有头部与多个RAR的MAC PDU的例子

3.3.3.2RAR消息的MAC头部

RAR消息对应的MAC头部是可变长度的，定义如下

-     E: 扩展域用于指示MAC头部还有其它域（例如其它RAR消息对于的子头部），如果E被置为“1”，也就是说随后至少还有一个（E/T/RAPID）域，否则，就指示随后是RAR消息或者填充部分，这里大家会发现对于RAR的填充部分它是紧随MAC头部的;

-     T: 类型域，用于指示这个MAC子头部包含的是随机接入ID（前导序列ID）还是BACKOFF指示，T置为“0”，也就是说这个子头部包含的是BI值， 如果是“1”，就意味着在这个子头部出现的是随机接入前导ID域；

-     R: 预留比特，置为"0";

-     BI: BACKOFF指示，通常是在小区过载的情况下，指示UE延后发送随机接入过程。4比特位表示；

-     RAPID: 随机接入前导与指示发送的随机接入前导序列，6比特位表示。

3.3.3.3RAR消息内容

MAC RAR消息大小是固定的，包含如下域：

-     R: 预留比特，置为“0”；

-     Timing Advance Command: The Timing Advance Commandfieldindicates theindex value TA (0, 1, 2…1282) used to control the amount of timing adjustment that UE has to apply (seesubclause 4.2.3of [2]). 11比特位表示；

-     UL Grant: TheUpLink Grant field indicates the resources to be used on the uplink (seesubclause 6.2 of [2]). 20比特位表示；

-     Temporary C-RNTI: The Temporary C-RNTIfield indicates the temporary identity that is used by the UE during RandomAccess. The size of the Temporary C-RNTI field is 16 bits.

3.4 MAC 过程

3.4.1随机接入过程

3.4.1.1 概述

随机接入是蜂窝系统一个最基本的功能，它使终端与网络建立连接成为可能。

基于竞争模式的随机接入：

RRC_IDLE状态下的初始接入；

无线链路出错以后的初始接入；

RRC_CONNECTED状态下，当有上行数据传输时，例如在上行失步后“non-synchronised”， 或者没有PUCCH资源用于发送调度请求消息，也就是说在这个时候除了通过随机接入的方式外，没有其它途径告诉eNB，UE存在上行数据需要发送

3.4.1.2   随机接入过程初始化

随机接入过程可以由PDCCH order或者MAC子层自己来触发，如果UE收到一个发给它的PDCCH传输含有一个PDCCH order，那么它就会发起一个随机接入过程，PDCCH order或者是RRC消息会指示ra-PreambleIndex与ra-PRACH-MaskIndex(随机接入PRACH掩码索引)信息以告诉UE它可以使用的前导序列以及发送机会。

在发起随机接入过程之前，下面的信息必须已经具备了：

- 用于发送随机接入前导的PRACH资源已经准备好了，由prach-ConfigIndex指示；

- 有可用的随机接入前导，在MAC层有可能设置两组随机接入前导:Group B与Group A，分布用于指示发送的MSG3的大小，Group B的前导序列个数由下面的参数推导可得

Group B前导序列个数 = numberOfRA-Preambles - sizeOfRA-PreamblesGroupA

在SIB2里面定义的PRACH的无线资源里面会提供上面的两个参数，从上面可以知道如果Group A的前导序列跟总的随机接入前导序列相等，那么UE就知道不存在Group B的前导序列，Group A与Group B的前导序列编号如下：

[0  sizeOfRA-PreamblesGroupA– 1]以及[sizeOfRA-PreamblesGroupA numberOfRA-Preambles – 1]

UE选择Group A还是选择Group B就看是否有这个需要以及满足一定的条件，比如UE希翼在发送MSG3里面携带VoIP的包，那么自然需要的资源就要大一些，那么当eNB收到UE发送的前导序列属于Group B时，它就会分配多一点资源给UE来发送MSG3

-    如果存在Group B的前导序列，那么由于Group B对于的MSG3消息比较大，因此必须满足一些额外的要求， messagePowerOffsetGroupB与messageSizeGroupA, 配置的UE发射功率 PCMAX，前导序列与MSG 3的功率偏移量，这些值跟当前的UE功率情况决定了最终选择GroupA还是B的前导序列

-    获得了接收随机接入响应的窗口大小参数ra-ResponseWindowSize，UE会在这个窗口期监听eNB是否给它回了响应，这个响应有eNB分配给UE的资源用于发送MSG3的。因此这个窗口大小就是UE等待的时间了，如果没有收到响应，那么UE就认为它发的前导没有被eNB收到，那么就要开始后面的处理了；

-    功率提升步长powerRampingStep.假如在前面发起的接入过程失败了，但是还没有达到最大尝试次数，那么UE就会提升功率发送下一次前导以提供发送成功的机会；

-    可以尝试发送的次数preambleTransMax，一般超过这个次数就认为UE无法接入了，至少可以认为这次的接入是失败的，会报告给上层协议层；

-    eNB期待接收到的前导序列目标功率preambleInitialReceivedTargetPower，这个值太高了，会造成干扰，太低了可能无法收到前导序列；

-    前导序列格式对应的功率偏移量，大家知道有5种前导序列，每一种格式都对应一个基准选择发射功率；

-    MSG3 HARQ重传最大次数maxHARQ-Msg3Tx.

-    竞争消除定时器mac-ContentionResolutionTimer.

注：在某一时刻只能有一个随机接入过程，如果这个UE在处于一个随机接入过程，但是同时又收到新的随机接入的请求，这取决于UE的实现，是继续当前的过程，还是取消当前过程，然后根据新的请求发起一个新的过程

3.4.1.3初始随机接入

这里大家对这种最初需要使用的接入模式进行详细的先容，这个过程一般分成四步：

图3.4.1-1竞争随机接入过程

步骤一、在发送上行接入前导序列之前，终端应该已经和系统下行同步好了，下行同步意味着UE获得了帧同步以及系统广播消息，但是上行并没有同步。通过前导序列，让eNB知道存在一个终端试图跟基站建立连接；

根据确认的前导分配相应的资源用于发送消息3（MSG3）；

步骤二、 eNB通过时隙调整确保上行同步，也就是发送time-advance消息实现；同时分配上行资源，这些内容就是由随机接入响应消息携带；

步骤三、在已经分配的资源上发送用户ID，以及相应的UL-SCH信息用于发送用户ID以及RRC连接请求之类的等基本信息，也就是所谓的消息3了（MSG3），具体内容跟用户所处的状态相关；

步骤四、通过DL-SCH发送冲突解决消息到终端。

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

步骤一、发送随机接入前导

图3.4.1-2 随机接入资源

预留的资源带宽为6个RB，那么对于LTE支撑的所有带宽都是可以满足的，这样可以非常方便的实现系统扩展，在物理层设计都会基于这样的考虑的，比如同步信道以及物理广播信道都是如此。

考虑到在发送前导序列时，上行并没有同步，需要防止对其他非接入资源的干扰，因此前导的序列长度大约0.9ms，留下0.1ms作为保护时间

前导序列基于Zadoff–Chu (ZC)，通过特定的移位获得，这种序列有一些很好的特性，比如具有很好的自相关性，恒定幅度等，具体的前导序列设计与检测原理看本系列的物理信道设计部分，使用什么样的前导，终端通过广播消息获得，然后从某一范围的序列随机选取一前导序列。

步骤二、随机接入响应

当eNB检测到这个前导序列，则在DL-SCH上发送一个响应，包含：该序列索引号、时间调整信息、资源调度信息（也就是分配给该用户的上行资源）以及临时RNTI，用于接下来的交互过程中让UE监听相应的PDCCH信道

所有发送前导序列的终端则使用一个预留给随机接入响应使用的ID(RA-RNTI )监听来L1/L2控制信道用于解码DL-SCH，从而获得上面的的信息；

RA-RNTI =1 + t_id + 10*f_id

其中，

t_id， 指定PRACH的第一个subframe索引号 (0 <= t_id < 10)

f_id， 在这个subframe里的PRACH索引，也就是频域位置索引，不过对于FDD系统来说，只有一个频域位置，因此f_id永远为零，但是对于TDD就不一样了，由于本项目不涉及TDD系统，因此不再延伸来讲。

监听时间从发送前导后的三个子帧开始，并持续ra-ResponseWindowSize个子帧数，该窗口大小通过读取系统广播消息（SIB2）获得，在前面有说明。这个值最大可设为10，因为大于10的话，有可能造成误解，因为在下一个无线帧里也有发生随机接入的机会，因此为了防止这种情况，这个窗口最大设为10，参见36.331，具体原理如下图所示：

                                      图3.4.1-3随机接入响应监听示意图

红色为发送RA的地方，绿色部分为UE最大可监听随机接入响应的窗口范围，点格子是窗口之外的地方。

如果在同一时间，多个终端选择同一个前导，这些终端都可能获得这些信息，那么就会导致冲突，而冲突的解决消除需要在后面两个步骤里面来消除，接收响应的过程如下：

• 当终端成功接收RA响应，终端调节上行发送时间，保存从这个响应里面获得临时C-RNTI用于随后的通信，直到获得最终的C-RNTI，最后发送前导序列的功率信息；
• 如果没有成功接收到响应；
  

计数器PREAMBLE_TRANSMISSION_COUNTER 加一

a. 如果计数器等于PREAMBLE_TRANS_MAX + 1，以及达到最大发送次数了:

向上层报告随机接入出错了。

b. 如果RA前导是由MAC选择的，那么从0到backoff时间之间随机选择一个值，然后延迟上面所选择值的时间，重新开始一个RA过程。

c. 否则，重选RA资源，例如功率，前导，相应的PRACH，发起新的随机接入过程。

步骤三、终端识别

通过前面两步，终端已经获得上行同步，以及随后通信的必要信息，但是要能够实现上行数据传输，则必须获得唯一的C-RNTI，根据不同的用户状态，这个过程会有不同的消息交互；

如果需要消除竞争，那么还有可能发送竞争消除ID以备在第四步的时候用做竞争消除确认操作。因为多个UE可能选择了相同的前导序列，因此在第二步他们获得的资源是一样的，那么发送消息3时，就会在相同的地方选择相同的方式发送，那么自然就会有冲突，这就相当于大家都要竞争接入了。也许大家会问，大家使用相同的资源发送，不是会冲突么，为什么还要做竞争消除呢？那是因为虽然有冲突，但是eNB还是有可能解出某个UE发送的MSG3，那么通过第四步的竞争消除消息，就可以让这个UE成功接入了。例如某一个UE离基站比较远，信号比较弱，而另外一个UE离基站近，信号比较强，较远的UE可能造成的干扰并不是很大，那么eNB还是可以解出较近的那个UE的消息3了。

另外在消息3，还会携带竞争消除ID，这个ID是唯一的，不会跟其他UE重复的，因此最好就是这个UE IMSI之类的。提前说一下，在消息4里面会把这个ID带上，发给UE，那么UE自然知道它已经成功接入了。

步骤四、竞争消除

大家知道消息3是有可能冲突的，在发完消息后就要立即启动竞争消除定时器（而随后每一次重传消息3都要重启这个定时器）。对于初始接入来说，如果在第三步上行消息包含CCCH SDU(例如RRC连接请求消息)，而收到下行PDCCH发送给临时C-RNTI：

如果MAC PDU解码成功：

停止竞争消除定时器，如果MAC PDU包含UE竞争消除ID的控制消息单元并且这个ID跟上行发送的竞争消除ID匹配，则认为竞争消除成功，并对这个MAC PDU 解复用并提取里面的内容，把临时C-RNTI设置为C-RNTI，同时丢弃临时C-RNTI，然后确认随机接入成功；

否则，

丢弃临时C-RNTI，UE会认为随机接入失败并丢弃这个MAC PDU；

如果竞争消除定时器超时，则认为接入失败；

失败后，会按照后退机制重新开始随机接入过程直到尝试次数超过门限值，那时则会向上层报告接入失败。

注：值得注意的是，消息四是没有重传机制的，大家设想一下，如果消息四采用重传，由于这个时候竞争没有消除，那么如果有些UE解码成功，有些解码失败；或者有些收到有些没有收到，那么就会出现同时ACK/NACK的情况；虽然消息三也会出现类似的情况，但是由于会确认信息的是eNB，它一次只会回一种确认信息，因此不会影响后面的处理。

3.4.1.4 后退机制

       在系统处于过载的情况下，例如它无法再分配更多的MSG3使用的资源等等，这个时候它自然希翼一些UE能够晚一点发，大家也注意到了在接收随机接入响应的时候以及RAR消息格式里面有一个backoff的东西，这就是后退机制的参数了，如果监听RAR消息的UE发现有一个backoff指示，那么它就会把这个值保存起来，在随后需要重新做随机接入的时候，可以随机从0到backoff值里的选一个值作为推迟发前导序列的时间。

       在通信系统里面大家碰到很多的后退机制，比如WiMAX系统的截断二进制后退机制，那么这两者的区别是什么呢？LTE系统里，后退的范围是由基站确定的，基站可以根据系统当前的负载情况来选择一个恰当的值；而在WiMAX里面由UE自己确定，当UE发现没有收到基站响应，就会按照二的指数增加后退窗口的长度，然后在这个窗口里面随机选一个时延来发送前导序列。两者各有优劣。下表是backoff取值情况：

Index	Backoff Parameter value (ms)
0	0
1	10
2	20
3	30
4	40
5	60
6	80
7	120
8	160
9	240
10	320
11	480
12	960
13	Reserved
14	Reserved
15	Reserved

基站在发送RAR消息的时候，根据负载情况选择backoff值的一个索引发给UE。

3.4.3 DRX(非连续接收)

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 Timer(持续时间定时器：指示从DRX周期开始连续的PDCCH子帧数)

UE每次从DRX醒来后维持醒着的时间,UE在该段时间内会搜索PDCCH。

Inactivity Timer

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

UE在醒着时每次成功解码HARQ初始发送的PDCCH后保持active的时间

Active Time

UE从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 RTTTimer

UE预期DL Retransmission到达的最少间隔时间，也就是说重传最早会什么时候到，那么UE暂且不需要理会，也就是说这一段时间，该怎样就怎样，等到这个定时器超时了，那么它就要处于醒着的状态。

DRXRetransmission Timer

UE预期接收DL Retransmission的时间，也就是需要这么多时间来接收下行重传。

DRX cyclelength

DRX cyclelength一旦配置/重配置就固定，即不会因为active time大于on duration而变化。

DRX运行：

-     如果在使用短DRX周期，检查当前子帧是否满足下面的公式：

-     或者在使用长DRX周期，那么检查如下的公式：

当上面的两个条件满足其中之一，那么就启动定时器onDurationTimer，此时UE就要开始监听PDCCH信道了

-     如果在这个子帧HARQ RTT 定时器超时，从前面的定时器先容大家已经知道它是希望重发的最短时间，那么这个定时器超时后，重发就有可能到来了。如果这时对于HARQ进程的软缓冲区还没有解码成功的数据（也就是前面的数据接收失败了，要求重传的数据），那么就启动定时器drx-RetransmissionTimer开始监听PDCCH重传相关的内容。

-     如果收到DRX MAC控制信息单元，也就意味着eNB要求UE进入睡眠状态，那么这时就会停止两个定时器onDurationTimer和drx-InactivityTimer，但是并不会停止跟重传相关的定时器，我想这是因为eNB即使这时还是希翼那个继续监听重传的内容。

-     如果drx-InactivityTimer 超时或者收到DRX MAC控制信息单元:

-     如果配置了短DRX周期:

-     那么启动或者重启drxShortCycleTimer;

-     使用短DRX周期。

-     否则；

-     使用长DRX 周期。

-     如果drxShortCycleTimer超时，那么

-     使用长DRX 周期。由于在短周期里面没有收到PDCCH，则就认为确实没什么数据发送接收，那么短周期的监听似乎没有必要，因此把监听的周期变长一点，这样长短周期配合能够达到更好的DRX效果。

上面一段话大部分摘自协议，并且加了自己的理解，但是也省略了一些我认为对协议理解无关的内容。下面是一个稍微复杂的例子：

大家来看看上图，

一开始的时候无论是长或者短周期都会启动onDurationTimer定时器，开始监听PDCCH，一开始收到下行的一个新包（1），但是解码失败，此时就要启动两个定时器一个是drx-InactivityTimer定时器用来延长监听的时间的，还有一个是HARQ RTT定时器，因为失败了，所以它估计最早重传会这个定时器超时后来到，所以在这一段时间里，它还是可以不理会重传。

接着有一个上行的包发送（2），此时需要重启drx-InactivityTimer定时器，因为现在要完成这个上行的包发送的处理，所以它还会持续监听这么长时间，不过这个包成功了，所以没有什么意外它就会得到定时器超时；

然后定时器还没有超时，这个时候又来了一个下行的新包（3），所以又要启动drx-InactivityTimer定时器，不过由于新包解码成功，因此得到定时器超时，它就进入了睡眠状态了，此时要启动drxShortCycleTimer定时器，图上没有画出来。

经过一段时间，这个周期结束了，进入下一个短周期的开始点了，因此需要重启onDurationTimer定时器。这个定时器没结束之前，HARQ RTT定时器超时，UE认为此后重传可能会到，所以要启动HARQ 重传定时器监听重传的PDCCH信息，接着重传到了，并且成功了。

随后又发送了一个上行包，没有出错，因此得到定时器超时，就进入睡眠状态，此时需要启动drxShortCycleTimer定时器，但是到它超时这段时间都没有收到PDCCH，因此它就进入了长DRX周期了。

这一个过程就完成了。

DRX、跟WiMAX power-saving 模式的实现机制是一样的，多个定时器的配合在于对于特定情况下，虽然从DRX cycle情况处于睡眠状态的时间，但是依然需要监听PDCCH

Long 和Short周期的交互配合在于提高DRX的效果，当short DRX timer 超时但是没有任何PDCCH只是接收，那么转入到Long 周期

提高power saving 效果

降低系统延时

静态调度

   静态调度，显然是有周期性，可配置性的。这些主要是针对广播消息，也就是SIB消息映射到共享信道，然后周期性的发送，还有就是基本上一旦系统起来，它占用的资源就是按照静态分配的形式来使用。还有就是呼叫，它总是周期性的获得调度资源，虽然呼叫不是什么时候都有的，不过考虑到它的周期性，也可以看成静态调度。

3.4.4.2.1       下行

当下行SPS资源分配配置好以后，在每一个子帧，UE通过计算下面的公式来判断是不是在这个子帧有这个资源分配：

-     (10* SFN + subframe) = [(10 * SFNstart time + subframestart time)+ N * semiPersistSchedIntervalDL]modulo 10240, N > 0

其中SFNstart time 和subframestarttime 是配置资源分配的起始SFN与起始子帧，这两个值的设置可以在初始化或者重配的时候告诉UE的。

3.4.4.2.2       上行

当上行SPS授权（Grant）配置好，则UE

-     认为在满足下式的子帧都会存在这个授权：

-     (10* SFN + subframe) = [(10 * SFNstart time + subframestart time) + N * semiPersistSchedIntervalUL + Subframe_Offset * (N modulo 2)] modulo10240, N>0。

其中SFNstart time 和subframestarttime 是配置资源分配的起始SFN与起始子帧，这两个值的设置可以在初始化或者重配的时候告诉UE的。

UE在经过连续implicitReleaseAfter 次在SPS分配的资源上空传（MAC PDU不包含任何MAC SDU）后就要清掉这个配置好的上行授权。

注：在清掉配置的上行授权后，还可以继续发送SPS的重传，当然这个资源就要按照通常的调度来获得了。

3.4.5      调度请求

调度请求（SR）用于请求上行共享信道资源用于发送上行数据所用，当触发了SR时，它就会一直处于挂起的状态直到它被取消为止，（也就是要么当这次请求得到满足或者这个SR没有必要等了结束）。由于必须有上行资源，UE才能够发送上行的数据，UE要求被调度的缓冲区状态报告（BSR），它是MAC控制信息单元，在共享信道上发送的，也是需要资源来发送的，那么如何获得用于发送BSR的上行资源呢？这就要先在PUCCH上发送SR或者通过PRACH发送。由于分配给UE的PUCCH是周期性的独占式的资源，UE应该总是有资源的；但是如果在PUCCH上发送的SR总是失败，那么也就需要通过PRACH的竞争方式来获得调度机会。

如果触发了一个SR，并且同时没有其它的SR被挂起，那么UE就要把SR_COUNTER设置为0，只要有一个SR正被挂起，那么在每一个TTI，UE都要按照下面流程处理：

如果在这个TTI，没有UL-SCH资源可用于发送数据：

如果在任何TTI内，UE都没有合法的PUCCH资源用于发送SR，那么就要发起一个随机接入的过程，并且取消所有挂起的SR，这段话的意思就是，当UE有数据要发送，这时就要向eNB请求上行资源，但是却没有PUCCH来发送SR，那么就要通过随机接入来发送调度请求。

如果在这个TTI UE有合法的PUCCH资源用于发送SR，并且这个TTI不属于测量时间（由于在切换的情况下，UE要测量邻小区的信号，根本无法处应当前服务小区的服务，因此即使在当前属于UE的服务时间，它也不能够做任何发送与接收的任务，其它过程跟SR类似）

-     如果 SR_COUNTER < dsr-TransMax:

-     把SR_COUNTER加1;

-     指示物理层在PUCCH上发送SR信号；

-     否则:

指示RRC释放PUCCH/SRS资源（一般来说eNB会响应UE的SR请求，但是如果SR连续在空口丢失了，那么大家可以认为链路出错了，此时相当于释放连接）

清掉任何的配置的下行分配的资源（下行SPS等）以及上下授权（上行SPS）

发起随机接入过程并且取消所有挂起的SR

-   如果在这个TTI里有可用的上行资源，那么就取消所有挂起的SR，因为此时请求已经得到eNB的确认，并且被eNB调度了。