LTE_MAC协议解读.doc

第三章 MAC3.1 序言刚刚开始学习LTE的一段时间，曾经写过一个幻灯片在我们组内分享，后来发到了网站，承蒙大家厚爱到处传阅，如果现在在google上搜索一下，还是能看到很多网站上都有。但是现在自己仔细看看原来的幻灯片，发现有很多地方说得过于模糊，还有一些地方存在错误，内心感到惶恐，趁这个机会，重新整理一下对MAC的理解，结合MAC协议（3GPP 36.321）与自己在MAC层工作的经验，提供更加丰富的内容，同时也希望能够纠正谬误，开启讨论之门。3.2 概述36.321里面主要描述的是MAC的架构与处于MAC层的功能实体，并没有涉及到具体的实现，而且由于LTE取消了向以前的协议专门提供的专用信道，所有的用户数据都使用共享信道，因此对MAC的在资源以及业务调度的功能上提出了很高的要求，这也是不同设备供应商可以大显神通的地方了；而协议本身主要描述的是接受端的行为，因此在基站端可以发挥的余地就更大了。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.1与3.2分别为层二的上下行功能框架图：图3.1 层二下行功能框架图图3.1 层二上行功能框架图3.2.2 服务3.2.2.1 提供给上层的服务MAC层给上层（RLC层，也可以泛指MAC层以上的协议层）提供的服务有：- 数据传输，这里面隐含了对上层数据处理，比如优先级处理，逻辑信道数据的复用；- 无线资源分配与管理，包括MCS的选择，数据在物理层传输格式的选择，以及无线资源的使用管理，从这里我们可以知道MAC层掌握了所有物理层资源的信息。3.2.2.2 期待物理层提供的服务物理层向MAC层提供以下服务：- 数据传输，MAC层通过传输信道访问物理层的数据传输服务，而传输信道的特征通过传输格式进行定义，它指示物理层如何处理相应的传输信道，例如信道编码，交织，速率匹配等；- HARQ 反馈信令（HARQ ACK/NACK）；- 调度请求信令（SR）；- 测量（比如信道质量CQI，与编码矩阵PMI等）3.2.3 MAC层功能MAC层的各个子功能实体提供以下的功能：- 实现逻辑信道映射到传输信道；- 复用从一条或多条逻辑信道下来的数据(MAC SDUs)到传输块，并通过传输信道发给到物理层；- 把从传输信道传送上来的传输块解复用成MAC SDU，并通过相应的逻辑信道，上交给RLC层；- 调度信息的报告，UE向eNODEB请求传输资源等；- 基于HARQ机制的错误纠正功能；- 通过动态调度的方式，处理不同用户的优先级；以及对同一用户的不同逻辑信道的优先级处理，这里主要在UE端实现；- 传输格式的选择，通过物理层上报的测量信息，用户能力等，选择相应的传输格式，从而达到最有效的资源利用。以上功能与上下行以及MAC实体的对应关系如下表所示：表3.1 MAC function location and link direction associationMAC 功能 UE eNB 下行 上行逻辑信道和传输信道之间的映射 X X X X X X复用 X X X X 解复用 X X X X HARQ X X X X X X传输格式的选择 X X X 不同用户间优先级处理 X X X 同一用户不同逻辑信道优先级处理 X X X 逻辑信道优先级设置 X X 调度信息报告 X X 3.2.4 信道结构在描述与MAC相关的信道前，这里先对信道做一些简单的解释，信道可以认为是不同协议层之间的业务接入点（SAP），是下一层向它的上层提供的服务。LTE沿用了UMTS里面的三种信道，逻辑信道，传输信道与物理信道。从协议栈的角度来看，物理信道是物理层的, 传输信道是物理层和MAC层之间的, 逻辑信道是MAC层和RLC层之间的，它们的含义是：- 逻辑信道，传输什么内容，比如广播信道（BCCH），也就是说用来传广播消息的；- 传输信道，怎样传，比如说下行共享信道DL-SCH，也就是业务甚至一些控制消息都是通过共享空中资源来传输的，它会指定MCS，空间复用等等方式，也就说是告诉物理层如何去传这些信息；- 物理信道，信号在空中传输的承载，比如PBCH，也就是在实际的物理位置上采用特地的调制编码方式来传输广播消息了。进一步解释，逻辑信道按照消息的类别不同，将业务和信令消息进行分类，获得相应的信道称为逻辑信道，这种信道的定义只是逻辑上人为的定义。传输信道对应的是空中接口上不同信号的基带处理方式，根据不同的处理方式来描述信道的特性参数，构成了传输信道的概念，具体来说，就是信号的信道编码、选择的交织方式（交织周期、块内块间交织方式等）、CRC冗余校验的选择以及块的分段等过程的不同，而定义了不同类别的传输信道；物理信道，就是在特定的频域与时域乃至于码域上采用特地的调制编码等方式发送数据的通道，物理信道就是空中接口的承载媒体，根据它所承载的上层信息的不同定义了不同类的物理信道。跟MAC层相关的信道有传输信道与逻辑信道，比如传输信道是物理层提供给MAC的服务，MAC可以利用传输信道向物理层发送与接收数据，而逻辑信道是MAC层向RLC层提供的服务，RLC可以使用这些逻辑信道想MAC层发送与接收数据。3.2.4.1 传输信道MAC使用的传输信道如下表所示：表3.2 跟上下行相关的传输信道传输信道名 缩写 下行上行 Broadcast Channel 广播信道 BCH X Downlink Shared Channel 下行共享信道 DL-SCH X Paging Channel 呼叫信道 PCH X Uplink Shared Channel 上行共享信道 UL-SCH X Random Access Channel 随机接入信道 RACH X 这些传输信道的用途与处理方式如下：- BCH（广播信道），下行，固定的，预定义传输格式的，例如具有固定大小，固定发送周期，调制编码方式等等；除了MIB消息在专属的物理信道上传输外，其它的广播消息（SIB）都是在物理共享信道上传输的，不再像UMTS那样留有专门的物理信道用于传输广播消息；- PCH（呼叫信道），下行,支持UE的非连续接收达到省电的目的；映射到物理下行共享信道，与BCH类似；- DL-SCH/UL-SCH，可以传输业务数据以及系统控制信息；- RACH（随机接入信道），上行，用于指定传输随机接入前导，发射功率等等信息。由上可知，除了指定特定的资源用于系统广播消息、上行的接入信息以及上下行信道控制信息外，其他的资源对所有用户来说都是共享的，进行统一调度。如果我们对比UMTS与LTE的传输信道，就会发现LTE的传输信道要少，例如针对业务数据，不再有专用传输信道与专用控制信道，通通并入了共享信道；这样的传输信道安排，已经跟WiMAX对资源管理的方式非常相似。由于业务资源都是共享的，那么MAC的调度就要做到兼顾业务优先级，无线资源高效使用以及公平性，这对MAC的设计提出了比较高的要求。可以说不同设备商的基站性能跟MAC层的调度非常相关。3.2.4.2 逻辑信道MAC提供的逻辑信道如下表3.3所示：表3.3 逻辑信道逻辑信道名 缩写 控制信道 业务信道 Broadcast Control Channel 广播控制信道 BCCH X Paging Control Channel 呼叫控制信道 PCCH X Common Control Channel 通用控制信道 CCCH X Dedicated Control Channel 专用控制信道 DCCH X Dedicated Traffic Channel 专用数据信道 DTCH X 这些逻辑信道的用途与处理方式如下：- BCCH（广播控制信道），下行信道，用于广播系统控制信息，例如系统带宽，天线个数以及各种信道的配置参数等等；- PCCH（呼叫控制信道），下行信道，用于传输呼叫信息（被叫号码等等）以及系统信息改变时的通知；这个信道用于系统不知道这个UE所在的小区位置时的呼叫，另外，当系统知道UE的具体位置时，可以使用共享信道来呼叫，但是对于系统信息改变还是必须使用PCCH，因为那时它呼叫的是小区内的所有UE；- CCCH（通用控制信道），下行信道，用于传递UE与系统之间的控制信息，当UE还没有RRC连接时，使用这个控制信道来传递控制信息，例如传输接入时，由于还没有RRC连接，RRC连接请求消息就是发在这个逻辑信道上的。因此没有RRC连接的UE都可以使用这个信道- DCCH（专用控制信道），上/下行信道，点对点的双向信道，用于传递UE与系统之间的专用控制信息，因此UE必须建立了RRC连接；- DTCH（专用数据信道），上/下行信道,点对点的双向信道，用于传递用户数据当MAC通过PDCCH物理信道指示无线资源的使用的时候，MAC会根据逻辑信道的类型把相应的RNTI映射到PDCCH，这样用户通过匹配不同的RNTI可以获取到相应的逻辑信道的数据- C-RNTI, Temporary C-RNTI and 半静态调度C-RNTI 用于DCCH 与 DTCH;- P-RNTI 用于 PCCH；- RA-RNTI 用于在DL-SCH上接收随机接入相应；- Temporary C-RNTI 用于在随机接入过程中接收CCCH；- SI-RNTI 用于BCCH.如下图所示：图3.3 RNTI 与逻辑信道映射关系3.2.4.3 逻辑信道到传输信道的映射MAC实体负责把上行的逻辑信道映射到相应的上行传输信道，映射关系如图3.4与表3.4所示：图3.4 上行逻辑信道与传输信道映射下行映射图3.5 下行逻辑信道与传输信道映射3.3 MAC格式（协议数据单元，格式与参数）3.3.1 概述MAC PDU是八位对齐的比特流，最高位第一行的最左边比特，最低位在最后一行的最右边的比特；MAC SDU也是八位对齐的比特流，而MAC PDU里面的参数也是按照相同的顺序，高位在左边，低位在右边的顺序。3.3.2 MAC PDU（DL-SCH和UL-SCH，除了透明MAC和随机接入响应）MAC PDU具有一个头部，零个或多个SDU，零个或多个控制单元，可能还有填充位。MAC头部与MAC SDU都是可变长度的。一个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例子MAC头部是可变长的，它包含以下参数：LCID：用于指示逻辑信道、控制消息类型或者填充域；L：指示SDU或者控制消息的长度，除了最后一个子头以及固定长度的控制消息对应的字头，每一个子头都有一个L域，它的长度由F域指示；F：如果SDU或者控制消息的长度大于128byte，那么设置F=1，否则设为0，通过F的值，我们就可以知道对应的L值的大小了，也就是知道这个内容（MAC SDU或者控制消息单元的长度了）；E:指示MAC 头部是否有多个域，当E=1时，意味着接下来存在另外一组R/R/E/LCID 域，如果是0，那么接下来就是payload了；-R: 预留比特位，设为“0”3.3.3 控制信息单元由于MAC存在多个控制信息单元，这里为了节约篇幅，只对几个重要的控制信息单元进行说明3.3.3.1缓冲状态报告控制信息单元（BSR）这个控制信息单元，对于上行调度是至关重要的，作为eNB分配给UE资源的一个凭据，UE有多少数据要发送就是通过它来告诉eNB的，BSR有两种：-短BSR和截断BSR格式：一个LCG ID（逻辑信道标识）域以及对应的缓冲区大小域，eNB收到这个消息后，就知道对应的UE的这个上行逻辑信道组有多少业务数据要发送，由于eNB是对一个逻辑信道组分配资源，那么就意味着这些资源可以被这个组的逻辑信道共享，每一个逻辑信道能够获得多少资源这就取决于UE的调度了，因此UE必须按照业务属性来分配资源，否则无法保证对应的业务的服务质量（QoS）如图3.3.3-1所示；-长BSR格式：四个缓冲区大小域，对应于LCG IDs #0 到#3，如图3.3.3-2所示。图3.3.3-1: 短BSR以及截断BSR MAC控制信息单元图3.3.3-2: 长BSR控制信息单元BSR格式可以通过MAC PDU字头部中LCID域来指示，如下表3.3.3-1所示：表3.3.3-1 UL-SCH的LCID值IndexLCID values00000CCCH00001-01010逻辑信道标识01011-11001预留11010功率预留报告（PHR）11011C-RNTI11100截断BSR11101短BSR11110长BSR11111填充LCG ID 域和缓冲区大小定义如下： -LCG ID: 逻辑信道组标识域指示了上报的缓冲区状态对应的逻辑信道组，它的长度为两个比特，也就意味着系统只设置了4个逻辑信道组；-缓冲区大小： 它指示了在构造了这个BSR控制信息单元之后的逻辑信道组内所有逻辑信道总的可以发送的数据量，数据量大小的单位是字节数。它应该包含在RLC层以及PDCP层可以传输的数据，这里的含义是指应该包含从PDCP发送到RLC的业务数据部分以及由RLC产生的RLC控制信息部分，我们可以参考【3】和【4】；值得注意的是这里不包含RLC以及MAC的头部信息所要占用的字节数，因此我们在给这个逻辑信道组分配资源的时候需要考虑到这一点，可以适当的多分配一点，这样就可以减少BSR的数量，从而也就节约了空口资源。这个域由六个比特位来指示，如表3.2所示，MAC层对不同的缓冲大小区间进行了量化，量化成为64个等级（可以用六比特表示），因此只需要传索引值而不是实际的大小，这样可以节约控制信息的长度。Table 6.1.3.1-1: BSR承载的缓冲区大小水平索引缓冲区大小 (BS) 值 字节索引缓冲区大小 (BS) 值 字节0BS = 0321132 BS = 132610 BS = 10331326 BS = 1552210 BS = 12341552 BS = 1817312 BS = 14351817 BS = 2127414 BS = 17362127 BS = 2490517 BS = 19372490 BS = 2915619 BS = 22382915 BS = 3413722 BS = 26393413 BS = 3995826 BS = 31403995 BS = 4677931 BS = 36414677 BS = 54761036 BS = 42425476 BS = 64111142 BS = 49436411 BS = 75051249 BS = 57447505 BS = 87871357 BS = 67458787 BS = 102871467 BS = 784610287 BS = 120431578 BS = 914712043 BS = 140991691 BS = 1074814099 BS = 1650717107 BS = 1254916507 BS = 1932518125 BS = 1465019325 BS = 2262419146 BS = 1715122624 BS = 2648720171 BS = 2005226487 BS = 3100921200 BS = 2345331009 BS = 3630422234 BS = 2745436304 BS = 4250223274 BS = 3215542502 BS = 4975924321 BS = 3765649759 BS = 5825525376 BS = 4405758255 BS = 6820126440 BS = 5155868201 BS = 7984627515 BS = 6035979846 BS = 9347928603 BS = 7066093479 BS = 10943929706 BS = 82661109439 BS = 12812530826 BS = 96762128125 BS =BS 1500003.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/Timing Advance Command/UL Grant/Temporary C-RNTI图3.3.3-3最后也可能存在填充，这个是隐含的，跟通常的填充规则不同，通过传输块大小减去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 Command field indicates the index value TA (0, 1, 2 1282) used to control the amount of timing adjustment that UE has to apply (see subclause 4.2.3 of 2). 11比特位表示；-UL Grant: The UpLink Grant field indicates the resources to be used on the uplink (see subclause 6.2 of 2). 20比特位表示；-Temporary C-RNTI: The Temporary C-RNTI field indicates the temporary identity that is used by the UE during Random Access. 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存在上行数据需要发送基于非竞争模式的随机接入：RRC_CONNECTED状态下，当下行有数据传输时，这时上行失步“non-synchronised”，因为数据的传输除了接收外，还需要确认，如果上行失步的话，eNB无法保证能够收到UE的确认信息，因为这时下行还是同步的，因此可以通过下行消息告诉UE发起随机接入需要使用的资源，比如前导序列以及发送时机等，因为这些资源都是双方已知的，因此不需要通过竞争的方式接入系统；切换过程中的随机接入，在切换的过程中，目标eNB可以通过服务eNB来告诉UE它可以使用的资源；是否基于竞争在于在当时终端能否监听到eNB传递的下行控制信道，以便获得特定的资源用于传输上行前导，当然这个判断是由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层有可能设置两组随机接入前导: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 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功率情况决定了最终选择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作为保护时间前导序列基于ZadoffChu (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最大可监听随机接入响应的窗口范围，点格子是窗口之外的地方。如果在同一时间，多个终端选择同一个前导，这些终端都可能获得这些信息，那么就会导致冲突，而冲突的解决消除需要在后面两个步骤里面来消除，接收响应的过程如下：1. 当终端成功接收RA响应，终端调节上行发送时间，保存从这个响应里面获得临时C-RNTI用于随后的通信，直到获得最终的C-RNTI，最后发送前导序列的功率信息；2. 如果没有成功接收到响应；（出现了退避问题）计数器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取值情况：IndexBackoff Parameter value (ms)0011022033044056068071208160924010320114801296013Reserved14Reserved15Reserved基站在发送RAR消息的时候，根据负载情况选择backoff值的一个索引发给UE。由于协议的撰写，每一步都需要考虑所有的情况，因此里面存在大量的ifelse，这造成了阅读上的不便，在这里，我建议大家，把不同场景从里面抽取出来。例如随机接入，那么我们可以先分别出那些是描述初始接入，那些事描述非竞争接入的，比如非竞争接入，我们自然不需要查看竞争消除部分的内容了。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 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暂且不需要理会，也就是说这一段时间，改怎样就怎样，等到这个定时器超时了，那么它就要处于醒着的状态。DRX Retransmission TimerUE预期接收DL Retransmission的时间，也就是需要这么多时间来接受下行重传。DRX cycle lengthDRX cycle length一旦配置/重配置就固定，即不会因为active time大于on duration而变化。DRX运行：-如果在使用短DRX周期，检查当前子帧是否满足下面的公式：-或者在使用长DRX周期，那么检查如下的公式：当上面的两个条件满足其中之一，那么就启动定时器onDurationTimer，此时UE就要开始监听PDCCH信道了-如果在这个子帧HARQ RTT 定时器超时，从前面的定时器介绍我们已经知道它是期望重发的最短时间，那么这个定时器超时后，重发就有可能到来了。如果这时对于的HARQ进程的软缓冲区还有没有解码成功的数据（也就是前面的数据接收失败了，要求重传的数据），那么就启动定时器drx-RetransmissionTimer开始监听PDCCH重传相关的内容。-如果收到DRX MAC控制信息单元，也就意味着eNB要求UE进入睡眠状态，那么这时就会停止两个定时器onDurationTimer和drx-InactivityTimer，但是并不会停止跟重传相关的定时器，我想这是因为eNB即使这时还