LTE MAC procedure

1、3.4 MAC 过程3.4.1 随机接入过程3.4.1.1 概述随机接入是蜂窝系统一个最基本的功能，它使终端与网络建立连接成为可能，诚如其名，这样的接入的发起以及采用的资源具有随机性，当然接入成功也具有随机性，那么在什么情况下需要发起随机接入的过程呢？随机的接入场景如下： 基于竞争模式的随机接入：RRC_IDLE状态下的初始接入；无线链路出错以后的初始接入；RRC_CONNECTED状态下，当有上行数据传输时，例如在上行失步后“non-synchronised”， 或者没有PUCCH资源用于发送调度请求消息，也就是说在这个时候除了通过随机接入的方式外，没有其它途径告诉eNB，UE存在上行数据需

2、要发送基于非竞争模式的随机接入：RRC_CONNECTED状态下，当下行有数据传输时，这时上行失步“non-synchronised”，因为数据的传输除了接收外，还需要确认，如果上行失步的话，eNB无法保证能够收到UE的确认信息，因为这时下行还是同步的，因此可以通过下行消息告诉UE发起随机接入需要使用的资源，比如前导序列以及发送时机等，因为这些资源都是双方已知的，因此不需要通过竞争的方式接入系统；切换过程中的随机接入，在切换的过程中，目标eNB可以通过服务eNB来告诉UE它可以使用的资源；是否基于竞争在于在当时终端能否监听到eNB传递的下行控制信道，以便获得特定的资源用于传输上行前导，当然这个

3、判断是由eNB作出的，而不是UE自己来决定的。3.4.1.2随机接入过程初始化随机接入过程可以由PDCCH order或者MAC子层自己来触发，如果UE收到一个发给它的PDCCH传输含有一个PDCCH order，那么它就会发起一个随机接入过程，PDCCH order或者是RRC消息会指示ra-PreambleIndex与ra-PRACH-MaskIndex信息以告诉UE它可以使用的前导序列以及发送机会。在发起随机接入过程之前，下面的信息必须已经具备了：- 用于发送随机接入前导的PRACH资源已经准备好了，由prach-ConfigIndex指示；- 有可用的随机接入前导，在MAC层有可能设置

4、两组随机接入前导: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

5、 numberOfRA-Preambles 1UE选择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功率情况决

6、定了最终选择GroupA还是B的前导序列-获得了接收随机接入响应的窗口大小参数ra-ResponseWindowSize，UE会在这个窗口期监听eNB是否给它回了响应，这个响应有eNB分配给UE的资源用于发送MSG3的。因此这个窗口大小就是UE等待的时间了，如果没有收到响应，那么UE就认为它发的前导没有被eNB收到，那么就要开始后面的处理了；-功率提升步长powerRampingStep.假如在前面发起的接入过程失败了，但是还没有达到最大尝试次数，那么UE就会提升功率发送下一次前导以提供发送成功的机会；-可以尝试发送的次数preambleTransMax，一般超过这个次数就认为UE无法接入了，

7、至少可以认为这次的接入是失败的，会报告给上层协议层；-eNB期待接收到的前导序列目标功率preambleInitialReceivedTargetPower，这个值太高了，会造成干扰，太低了可能无法收到前导序列；-前导序列格式对应的功率偏移量，我们知道有5种前导序列，每一种格式都对应一个基准选择发射功率；-MSG3 HARQ重传最大次数maxHARQ-Msg3Tx.-竞争消除定时器mac-ContentionResolutionTimer.注：在某一时刻只能有一个随机接入过程，如果这个UE在处于一个随机接入过程，但是同时又收到新的随机接入的请求，这取决于UE的实现，是继续当前的过程，还是取消当

8、前过程，然后根据新的请求发起一个新的过程3.4.1.3初始随机接入这里我们对这种最初需要使用的接入模式进行详细的介绍，这个过程一般分成四步，如前一页图所示：图3.4.1-1竞争随机接入过程步骤一、在发送上行接入前导序列之前，终端应该已经和系统下行同步好了，下行同步意味着UE获得了帧同步以及系统广播消息，但是上行并没有同步。通过前导序列，让eNB知道存在一个终端试图跟基站建立连接；根据确认的前导分配相应的资源用于发送消息3（MSG3）；步骤二、 eNB通过时隙调整确保上行同步，也就是发送time-advance消息实现；同时分配上行资源，这些内容就是由随机接入响应消息携带；步骤三、在已经分配的资

9、源上发送用户ID，以及相应的UL-SCH信息用于发送用户ID以及RRC连接请求之类的等基本信息，也就是所谓的消息3了（MSG3），具体内容跟用户所处的状态相关；步骤四、通过DL-SCH发送冲突解决消息到终端。只有第一步是纯粹的物理层过层，后面三个步骤跟普通的数据传输过程没有区别，看MAC协议经常看到MSG3或者MSG4等等，因为在随机接入的过程中，这些消息的内容不是固定，有时候可能携带的是RRC连接请求，有时候可能会带一些控制消息甚至业务数据包，因此简称为消息3之类，其意思就是第三条消息。步骤一、发送随机接入前导图3.4.1-2 随机接入资源预留的资源带宽为6个RB，那么对于LTE支持的所有带

10、宽都是可以满足的，这样可以非常方便的实现系统扩展，在物理层设计都会基于这样的考虑的，比如同步信道以及物理广播信道都是如此。考虑到在发送前导序列时，上行并没有同步，需要防止对其他非接入资源的干扰，因此前导的序列长度大约0.9ms，留下0.1ms作为保护时间前导序列基于ZadoffChu (ZC)，通过特定的移位获得，这种序列有一些很好的特性，比如具有很好的自相关性，恒定幅度等，具体的前导序列设计与检测原理看本系列的物理信道设计部分，使用什么样的前导，终端通过广播消息获得，然后从某一范围的序列随机选取一前导序列。步骤二、 随机接入响应当eNB检测到这个前导序列，则在DL-SCH上发送一个响应，包含

11、：该序列索引号、时间调整信息、资源调度信息（也就是分配给该用户的上行资源）以及临时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永远为零，但是对

12、于TDD就不一样了，由于本文不涉及TDD系统，因此不再延伸来讲。监听时间从发送前导后的三个子帧开始，并持续ra-ResponseWindowSize 个子帧数，该窗口大小通过读取系统广播消息（SIB2）获得，在前面有说明。这个值最大可设为10，因为大于10的话，有可能造成误解，因为在下一个无线帧里也有发生随机接入的机会，因此为了防止这种情况，这个窗口最大设为10，大家可以去查看36.331里面这个参数范围就知道，具体原理如下图所示： 图3.4.1-3随机接入响应监听示意图红色为发送RA的地方，绿色部分为UE最大可监听随机接入响应的窗口范围，点格子是窗口之外的地方。如果在同一时间，多个终端选择同

13、一个前导，这些终端都可能获得这些信息，那么就会导致冲突，而冲突的解决消除需要在后面两个步骤里面来消除，接收响应的过程如下：1. 当终端成功接收RA响应，终端调节上行发送时间，保存从这个响应里面获得临时C-RNTI用于随后的通信，直到获得最终的C-RNTI，最后发送前导序列的功率信息；2. 如果没有成功接收到响应；（出现了退避问题）计数器PREAMBLE_TRANSMISSION_COUNTER 加一a. 如果计数器等于PREAMBLE_TRANS_MAX + 1，以及达到最大发送次数了: 向上层报告随机接入出错了。b. 如果RA前导是由MAC选择的，那么从0到backoff时间之间随机选择一个

14、值，然后延迟上面所选择值的时间，重新开始一个RA过程。c. 否则，重选RA资源，例如功率，前导，相应的PRACH，发起新的随机接入过程。为了避免完全翻译协议，中间一些过程省略了，具体过程请大家看协议。步骤三、终端识别通过前面两步，终端已经获得上行同步，以及随后通信的必要信息，但是要能够实现上行数据传输，则必须获得唯一的C-RNTI，根据不同的用户状态，这个过程会有不同的消息交互；如果需要消除竞争，那么还有可能发送竞争消除ID以备在第四步的时候用做竞争消除确认操作。因为多个UE可能选择了相同的前导序列，因此在第二步他们获得的资源是一样的，那么发送消息3时，就会在相同的地方选择相同的方式发送，那么

15、自然就会有冲突，这就相当于大家都要竞争接入了。也许大家会问，大家使用相同的资源发送，不是会冲突么，为什么还要做竞争消除呢？那是因为虽然有冲突，但是eNB还是有可能解出某个UE发送的MSG3，那么通过第四步的竞争消除消息，就可以让这个UE成功接入了。例如某一个UE离基站比较远，信号比较弱，而另外一个UE离基站近，信号比较强，较远的UE可能造成的干扰并不是很大，那么eNB还是可以解出较近的那个UE的消息3了。另外在消息3，还会携带竞争消除ID，这个ID是唯一的，不会跟其他UE重复的，因此最好就是这个UE IMSI之类的。提前说一下，在消息4里面会把这个ID带上，发给UE，那么UE自然知道它已经成功

16、接入了。步骤四、竞争消除我们知道消息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会认

17、为随机接入失败并丢弃这个MAC PDU；如果竞争消除定时器超时，则认为接入失败；失败后，会按照后退机制重新开始随机接入过程直到尝试次数超过门限值，那时则会向上层报告接入失败。（出现了退避问题）注：值得注意的是，消息四是没有重传机制的，我们设想一下，如果消息四采用重传，由于这个时候竞争没有消除，那么如果有些UE解码成功，有些解码失败；或者有些收到有些没有收到，那么就会出现同时ACK/NACK的情况；虽然消息三也会出现类似的情况，但是由于会确认信息的是eNB，它一次只会回一种确认信息，因此不会影响后面的处理。3.4.1.4 后退机制在系统处于过载的情况下，例如它无法再分配更多的MSG3使用的资源等

18、等，这个时候它自然希望一些UE能够晚一点发，我们也注意到了在接收随机接入响应的时候以及RAR消息格式里面有一个backoff的东西，这就是后退机制的参数了，如果监听RAR消息的UE发现有一个backoff指示，那么它就会把这个值保存起来，在随后需要重新做随机接入的时候，可以随机从0到backoff值里的选一个值作为推迟发前导序列的时间。在通信系统里面我们碰到很多的后退机制，比如WiMAX系统的截断二进制后退机制，那么这两者的区别是什么呢？LTE系统里，后退的范围是由基站确定的，基站可以根据系统当前的负载情况来选择一个恰当的值；而在WiMAX里面由UE自己确定，当UE发现没有收到基站响应，就会按

19、照二的指数增加后退窗口的长度，然后在这个窗口里面随机选一个时延来发送前导序列。两者各有优劣。下表是backoff取值情况：IndexBackoff Parameter value (ms)0011022033044056068071208160924010320114801296013Reserved14Reserved15Reserved基站在发送RAR消息的时候，根据负载情况选择backoff值的一个索引发给UE。由于协议的撰写，每一步都需要考虑所有的情况，因此里面存在大量的ifelse，这造成了阅读上的不便，在这里，我建议大家，把不同场景从里面抽取出来。例如随机接入，那么我们可以先分别出

20、那些是描述初始接入，那些事描述非竞争接入的，比如非竞争接入，我们自然不需要查看竞争消除部分的内容了。3.4.3 DRX(非连续接收)DRX，在一段时间里停止监听PDCCH信道，DRX分两种：IDLE DRX，顾名思义，也就是当UE处于IDLE状态下的非连续性接收，由于处于IDLE状态时，已经没有RRC连接以及用户的专有资源，因此这个主要是监听呼叫信道与广播信道，只要定义好固定的周期，就可以达到非连续接收的目的。但是UE要监听用户数据信道，则必须从IDLE状态先进入连接状态。而另一种就是ACTIVE DRX，也就是UE处在RRC-CONNECTED 状态下的DRX， 可以优化系统资源配置，更重要

21、的是可以节约手机功率，而不需要通过让手机进入到RRC_IDLE 模式来达到这个目的，例如一些非实时应用，像web浏览，即时通信等，总是存在一段时间，手机不需要不停的监听下行数据以及相关处理，那么DRX就可以应用到这样的情况，另外由于这个状态下依然存在RRC连接，因此UE要转到支持状态的速度非常快。这里我们先介绍ACTIVE DRX，而IDLE DRX我打算放在呼叫那部分来介绍。而要理解DRX，我们就必须理解下面要描述的几个定时器与概念（所有的时间都是基于子帧的，也就是ms为单位）：On duration TimerUE每次从DRX醒来后维持醒着的时间,UE在该段时间内会搜索PDCCH。Inac

22、tivity 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 包

23、括以下时间： -onDurationTimer、drx-InactivityTimer、drx-RetransmissionTimer 以及 mac-ContentionResolutionTimer 运行的时间，或者-有SR（调度请求）已近发送到PUCCH，并且处于挂起的状态（也就是这个调度请求还没有满足，如此之类的）或者，-对一个挂起的HARQ重传存在上行授权，并且在对应的HARQ 缓冲区里面有数据；或者-在非竞争随机接入后，成功收到随机接入响应消息，此时应该有PDCCH发送给UE指示一个新的传输，但是这个PDCCH还没有收到，此时UE还是必须处于ACTIVE状态HARQ RTT Time

24、rUE预期DL Retransmission到达的最少间隔时间，也就是说重传最早会什么时候到，那么UE暂且不需要理会，也就是说这一段时间，改怎样就怎样，等到这个定时器超时了，那么它就要处于醒着的状态。DRX Retransmission TimerUE预期接收DL Retransmission的时间，也就是需要这么多时间来接受下行重传。DRX cycle lengthDRX cycle length一旦配置/重配置就固定，即不会因为active time大于on duration而变化。DRX运行：-如果在使用短DRX周期，检查当前子帧是否满足下面的公式：-或者在使用长DRX周期，那么检查如下

25、的公式：当上面的两个条件满足其中之一，那么就启动定时器onDurationTimer，此时UE就要开始监听PDCCH信道了-如果在这个子帧HARQ RTT 定时器超时，从前面的定时器介绍我们已经知道它是期望重发的最短时间，那么这个定时器超时后，重发就有可能到来了。如果这时对于的HARQ进程的软缓冲区还有没有解码成功的数据（也就是前面的数据接收失败了，要求重传的数据），那么就启动定时器drx-RetransmissionTimer开始监听PDCCH重传相关的内容。-如果收到DRX MAC控制信息单元，也就意味着eNB要求UE进入睡眠状态，那么这时就会停止两个定时器onDurationTimer和

26、drx-InactivityTimer，但是并不会停止跟重传相关的定时器，我想这是因为eNB即使这时还是希望那个继续监听重传的内容。-如果drx-InactivityTimer 超时或者收到DRX MAC控制信息单元:-如果配置了短DRX周期:-那么启动或者重启drxShortCycleTimer;-使用短DRX周期。-否则；-使用长DRX 周期。-如果drxShortCycleTimer超时，那么-使用长DRX 周期。由于在短周期里面没有收到PDCCH，则就认为确实没什么数据发送接收，那么短周期的监听似乎没有必要，因此把监听的周期变长一点，这样长短周期配合能够达到更好的DRX效果。上面一段话

27、大部分摘自协议，并且加了自己的理解，但是也省略了一些我认为对协议理解无关的内容，如果大家还想完全了解，建议完整的读完协议。看来这么多文字描述，我想最好用一个图列来说明问题了，下面就是一个稍微复杂的例子：我们来看看上图，一开始的时候无论是长或者短周期都会启动onDurationTimer定时器，开始监听PDCCH，一开始收到下行的一个新包（1），但是解码失败，此时就要启动两个定时器一个是drx-InactivityTimer定时器用来延长监听的时间的，还有一个是HARQ RTT定时器，因为失败了，所以它估计最早重传会这个定时器超时后来到，所以在这一段时间里，它还是可以不理会重传。接着有一个上行的

28、包发送（2），此时需要重启drx-InactivityTimer定时器，因为现在要完成这个上行的包发送的处理，所以它还会持续监听这么长时间，不过这个包成功了，所以没有什么意外它就会得到定时器超时；然后定时器还没有超时，这个时候又来了一个下行的新包（3），所以又要启动drx-InactivityTimer定时器，不过由于新包解码成功，因此得到定时器超时，它就进入了睡眠状态了，此时要启动drxShortCycleTimer定时器，图上没有画出来。经过一段时间，这个周期结束了，进入下一个短周期的开始点了，因此需要重启onDurationTimer定时器。这个定时器没结束之前，HARQ RTT定时器超

29、时，UE认为此后重传可能会到，所以要启动HARQ 重传定时器监听重传的PDCCH信息，接着重传到了，并且成功了。随后又发送了一个上行包，没有出错，因此得到定时器超时，就进入睡眠状态，此时需要启动drxShortCycleTimer定时器，但是到它超时这段时间都没有收到PDCCH，因此它就进入了长DRX周期了。这一个过程就完成了。DRX、跟WiMAX power-saving 模式的实现机制是一样的，多个定时器的配合在于对于特定情况下，虽然从DRX cycle情况处于睡眠状态的时间，但是依然需要监听PDCCHLong 和Short周期的交互配合在于提高DRX的效果，当short DRX time

30、r 超时但是没有任何PDCCH只是接收，那么转入到Long 周期提高power saving 效果降低系统延时3.4.4 调度方式3.4.4.1 前言在前面我们经常提到LTE系统的共享信道，除了很少的几个信道有专门对应的物理信道，例如广播信道（PBCH），而且它传的主要也是MIB消息，而其余的SIB消息依然使用共享信道传输，因此它而显然的告诉我们，资源是以共享的方式存在。那么对调度器的设计的要求自然就提高了，跟早期的很多接入系统不同每个用户的业务都有专门的信道。当然到了HSPA时已经是共享信道的概念，但是主要还是针对数据业务。因此LTE于此之前的系统都有很大的区别了。调度器的设计，需要考虑它的

31、目的与基本的调度原则，在此略微列出，目的：调度的好坏对于系统的性能影响很大，对于LTE十分重要，我们在前面讲了，LTE的几乎所有的应用与业务都是使用共享信道，由于各个业务与应用的对服务质量（QoS）的要求是不同的，因此调度的好坏直接影响的就是QoS是否可以满足，也即是用户的使用体验是否比较好；最好的利用时/频/空/功率资源用于不同的UEs和不同的业务，保证各种业务的QoS，提高系统的容量，另外除了满足业务的服务质量外，我们还必须保证系统的容量能够得到保证，否则一个系统除了只能支持少数用户，那也没有意义，如何充分提高系统容量，那么就必须把链路性能跟服务质量结合起来作为调度的考虑因素。基本调度原则

32、eNB负责上下行的调度，上下行是不同的调度器负责，因为上下行使用完全独立的资源，而且在链路性能的监测方面几乎也是独立的，因此设计时，尽量能够独立，但是如果采用TD-LTE的制式，能够结合上下行结合起来调度呢？我想这是应该做的，比如上行调度，完全可以参考下行反馈的信道质量，乃至于空间复用方式选择上；调度器需要考虑的因素包括业务的QoS，业务量以及相关的无线承载，无线条件以及UE能力等；给于UE的UL-SCH的资源是对应一个UE逻辑信道组，而不是对应一个无线承载的。调度器因此调度器的设计需要考虑以下的因素：QoS，针对不同业务，需要保证的业务质量；不同用户之间的优先级处理；同用户的不同业务的优先级

33、处理，这体现在对不同的逻辑信道的处理上；用户所处的无线信号状况，选择最好的信号用户，可以最大的吞吐量，但是缺乏公平公平性考虑，如果考虑轮询，那么系统的性能有可能降低，因此以上两个原因都必须考虑在内基本调度资源：Resource Block(RB)调度间隔: (基本TTI)1ms，但是多个TTI可以绑定组成更长的TTI，这样可以获得更大带宽效率，这对高速率业务很有用负责选择TB大小，MCS，天线映射由于取消了专用传输信道，因此除了分配给特定的管理消息的资源，例如同步信道，系统广播消息，参考信号，随机接入等，其他资源都是共享的，因此相对于3G的调度方式，它更像WiMAX的调度方式，是一个完全动态的

34、调度方式，因此系统的性能完全取决于它的调度算法的好坏上，以下因素将是它的调度需要考虑的：虽然我们一再强调资源是共享的，但是在调度方式上面依然有很多选择，主要是针对不同业务特性设计的，如下所示：动态调度对于UL-SCH 和DL-SCH是最基本的调度方式，下图是上行动态调度示意图：图3.4.4-1 上行动态调度示意图上图说明简单描述了一个上行动态调度的示意图，1. 首先在UE端有一个事件产生，一般是上行有数据发送，已经放在了缓冲区里了，那么它需要为这些数据申请上行资源用于发送。它可以通过SR-PUCCH上行SR控制信道来发送调度请求，或者通过PRACH，此时是采用竞争的方式发送调度请求；2. eN

35、B按照一定的调度原则，如果可以的话就会分配一些资源用于发送BO（Buffer Occupation）信息，通过上行调度授权（UL grant）告诉UE；3. UE发送BO报告告诉eNB对应的逻辑信道组有多少数据要发送，对于上行eNB调度是针对逻辑信道组而不是一个无线承载；4. 然后eNB对用户请求的资源情况，分配相应的资源，然后通过UL grant通知UE；5. UE在自己的逻辑信道直接，根据一定的优先级原则，发送上行数据。半静态调度是一种优化的方式（例如对于UL & DL VoIP)，RRC信令负责静态调度参数(周期)的配置，PDCCH信令负责激活/去激活半静态调度资源。静态调度静态

36、调度，显然是有周期性，可配置性的。这些主要是针对广播消息，也就是SIB消息映射到共享信道，然后周期性的发送，还有就是基本上一旦系统起来，它占用的资源就是按照静态分配的形式来使用。还有就是呼叫，它总是周期性的获得调度资源，虽然呼叫不是什么时候都有的，不过考虑到它的周期性，也可以看成静态调度。对动态调度在系统设计上的支持：更加灵活的传输格式完全可变长的RLC PDU 大小的结构，这根以前3G的半静态 RLC PDU大小非常不同，这种结构的设计对高数据率的时候，可以采用很长的RLC PDU，因为额外开销所占比例降低了，这样可以提高带宽的利用率。3.4.4.2 半静态调度（SPS）半静态调度跟WIMA

37、X系统的UGS相似，由于这些资源主要是分配那些需要周期性调度的业务，比如VoIP，既然是周期性需要的，那么为何不采用事先配置来做呢？这样就可以减少PDCCH的资源，要知道在LTE PDCCH的资源是非常宝贵，上下行共用的；而且如果不发自然也相应的减少了空口资源的使用。当通过RRC消息激活SPS调度，则需要提供以下信息，（可以查36.331来获得这些参数的具体描述与定义）：SPS C-RNTI-上行调度间隔semiPersistSchedIntervalUL 与隐含指示多少个空传之后释放连接参数implicitReleaseAfter;-下行调度间隔semiPersistSchedInterva

38、lDL 以及多少个HARQ进程用于半静态调度numberOfConfSPS-Processes；如果RRC去激活上行或者下行连接，那么相应的配置授权与配置的资源要丢弃。3.4.4.2.1下行当下行SPS资源分配配置好以后，在每一个子帧，UE通过计算下面的公式来判断是不是在这个子帧有这个资源分配：-(10 * SFN + subframe) = (10 * SFNstart time + subframestart time) + N * semiPersistSchedIntervalDL modulo 10240, N > 0 其中SFNstart time 和subframestar

39、t time 是配置资源分配的起始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) modulo 10240, N>0。其中SFNstart time 和subframestart time 是配置资源

40、分配的起始SFN与起始子帧，这两个值的设置可以在初始化或者重配的时候告诉UE的。UE在经过连续implicitReleaseAfter 次在SPS分配的资源上空传（MAC PDU不包含任何MAC SDU）后就要清掉这个配置好的上行授权。注：在清掉配置的上行授权后，还可以继续发送SPS的重传，当然这个资源就要按照通常的调度来获得了。3.4.5调度请求调度请求（SR）用于请求上行共享信道资源用于发送上行数据所用，当触发了SR时，它就会一直处于挂起的状态直到它被取消为止，也就是要么当这次请求得到满足或者这个SR没有必要了等。由于必须有上行资源，UE才能够发送上行的数据，UE要求被调度的缓冲区状态报告

41、（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都没有合法的PUCC

42、H资源用于发送SR，那么就要发起一个随机接入的过程，并且取消所有挂起的SR，这段话的意思就是，当UE有数据要发送，这是就要向eNB请求上行资源，但是却没有PUCCH来发送SR，那么就要通过随机接入来发送调度请求。如果在这个TTI UE有合法的PUCCH资源用于发送SR，并且这个TTI不属于测量时间（由于在切换的情况下，UE要测量邻小区的信号，根本无法处理当前服务小区的服务，因此即使在当前属于UE的服务时间，它也不能够做任何发送与接收的任务，其它过程跟SR类似）-如果 SR_COUNTER < dsr-TransMax:-把SR_COUNTER加1;-只是物理层在PUCCH上发送SR信号；

43、-否则:指示RRC释放PUCCH/SRS资源（一般来说eNB会响应UE的SR请求，但是如果SR连续在空口丢失了，那么我们可以任何链路出错了，此时相当于释放连接）清掉任何的配置的下行分配的资源（下行SPS等）以及上下授权（上行SPS）发起随机接入过程并且取消所有挂起的SR- 如果在这个TTI里有可用的上行资源，那么就取消所有挂起的SR，因为此时请求已经得到eNB的确认，并且被eNB调度了。3.4.6缓冲区状态报告（BSR）在介绍SR时，我们已经知道上行数据的传输需要的资源是通过BSR来获得，缓冲区状态报告过程是用于向服务eNB提供UE共有多少数据存在上行的缓冲区里需要发送的信息，RRC通过配置两个定时器periodicBSR-Timer 和