本文涉及到的内容有：
（1）UE在什么时候開始接收RAR
（2）怎么确定RA-RNTI
（3）UE没有收到RAR后的处理
（4）RAR的格式
1.UE监測RAR
文章《LTE-TDD随机接入过程（2）-前导码Preamble的格式与时频位置》已经具体说明了UE发送Preamble前导码的时频位置。当UE发出Preamble后，并非马上准备接收RAR（Random Access Response），而是在发送前导码之后的第3个子帧之后才開始准备接收RAR。当然，UE也不可能一直等待RAR。假设UE连续检測了ra-ResponseWindowSize个子帧仍然没有收到RAR。则不再继续监測RAR信息。
the UE shall monitor the PDCCH for Random Access Response(s) identified by the RA-RNTI defined below, in the RA Response window which starts at the subframe that contains the end of the preamble transmission plus three subframes and has length ra-ResponseWindowSize subframes. |
|---|
ra-ResponseWindowSize參数由SIB2中的RACH-ConfigCommon字段带给UE，范围是2-10个子帧，即UE最多连续监測RAR的时长是10ms。
2.RA-RNTI的计算
eNB加扰RAR、UE解扰RAR的RA-RNTI并不在空口中传输。但UE和eNB都须要唯一确定RA-RNTI的值。否则UE就无法解码RAR，因此RA-RNTI就必须通过收发两方都明白的Preamble的时频位置来计算RA-RNTI的值。
RA-RNTI: The Random Access RNTI is used on the PDCCH when Random Access Response messages are transmitted. It unambiguously identifies which time-frequency resource was utilized by the UE to transmit the Random Access preamble. |
|---|
协议规定了RA-RNTI的计算公式为：RA-RNTI= 1 t_id 10*f_id。
当中，t_id表示发送Preamble的起始位置的子帧ID号（范围是0-9），f_id表示四元素组中的f_RA值（范围是0-5），之前的文章《LTE-TDD随机接入过程（2）-前导码Preamble的格式与时频位置》已经具体描写叙述了这两个值的具体含义。
eNB仅仅要能解码出Preamble前导码，就能唯一确定t_id和f_id參数，也就能唯一确定RA-RNTI值。
3.UE没有收到RAR的处理
UE有可能在RAR的监測窗体内没有解码到RAR消息，这有可能是eNB側没有检測到PRACH中的Preamble信息，有可能是没有调度RAR信息。也有可能是下行无线链路有干扰导致UE解码RAR失败，不管是哪种原因。UE没有收到RAR是有可能发生的。
假设在RAR响应窗体内没有收到RAR，或者收到的RAR中携带的Preamble并非本UE之前发送的Preamble，那么表示UE本次接收RAR失败，UE将运行例如以下操作：
（1）将本地变量PREAMBLE_TRANSMISSION_COUNTER加1 （2）假设PREAMBLE_TRANSMISSION_COUNTER变量=（preambleTransMax 1）。那么将通知协议上层“本次RA失败”，不再运行（3）、（4）过程。这之后的流程，是继续运行新一次的RA过程。还是运行扫频选小区，甚至换网过程。协议并没有明白说明，由UE側基带厂商自行决定。 （3）假设PREAMBLE_TRANSMISSION_COUNTER<（preambleTransMax 1），且之前的Preamble是由UE側MAC选择的，那么UE将在0到backoff參数之间随机选择一个值，作为当前失败时刻到下一次发送Preamble时刻的时延。 （4）选择时频资源位置，又一次发起RA过程。 |
|---|
从上述过程能够看到。UE側在每次RA过程中。会维护一个计数器PREAMBLE_TRANSMISSION_COUNTER，范围是【0，preambleTransMax】，一旦超过preambleTransMax值，则表示本次RA失败。preambleTransMax參数表示本次Preamble发送（含重传）的最大次数，和ra-ResponseWindowSize參数一样，也是包括在SIB2中的RACH-ConfigCommon字段中。见上文截图。范围从3到200不等。一般取5次就可以。
backoff參数表示上次接收RAR失败到下次又一次发送Preamble之间的最大延时。单位是ms，eNB側的MAC层通过RAR消息配置到UE。范围是0-960ms。假设值属于Reserved，则依照960ms处理。
前导码的发送和重传时机例如以下图所看到的。
MSG1每次发送前导码的功率值PREAMBLE_RECEIVED_TARGET_POWER计算例如以下：
PREAMBLE_RECEIVED_TARGET_POWER = preambleInitialReceivedTargetPower DELTA_PREAMBLE (PREAMBLE_TRANSMISSION_COUNTER – 1) *powerRampingStep |
|---|
当中，
PREAMBLE_TRANSMISSION_COUNTER是当前MSG1的传输次数。第一次（新传）时，PREAMBLE_TRANSMISSION_COUNTER被设置为1。
preambleInitialReceivedTargetPower表示初始功率值，范围从-120dBm到-90dBm不等。
powerRampingStep表示功率抬升因子。范围从0dB到6dB不等。
上述三个參数都由SIB2中的RACH-ConfigCommon字段带给UE，见前文截图。
DELTA_PREAMBLE是一个功率偏移量。与Preabmle的格式相关。
4.RAR的格式
随机接入过程中的MAC PDU包括3个部分：MAC头、payload（1个或多个RAR单元）和可选的填充padding。
MAC头包括1个或多个MAC子头。但仅仅能有1个子头能够包括Backoff Indicator，且这个子头仅仅能放在第一个子头位置。
其它没有包括Backoff Indicator的子头均相应一个RAR单元。
例如以下图所看到的。之所以将BI子头放在第一个子头位置。我想可能是为了降低UE側的处理时间，比方存在这样的情况：UE1-UE10共10个UE同一时候接入。假设将UE1的RAPID子头不放在第一个位置。那么UE1还要遍历接下来的全部子头，读取每一个子头的E值和T值，才干知道这个RAR有没有携带BI子头，而假设规定BI子头固定放在第一个位置，那么UE1在解码BI子头和自己的RAPID子头后，就不须要关心余下全部子头的T字段了。
带BI（Backoff Indicator）參数的MAC子头，由E/T/R/R/BI组成，而其它的子头则由E/T/RAPID组成，例如以下图所看到的。须要注意的是。在没有解码到不论什么BI值的时候。UE本地使用的BI參数是0ms。而假设一旦解码成功RAR，不管这个RAR是否携带了本UE的Preamble。UE都要存下本次解码得到的BI，以备重传Preamble的时候使用。但一旦又一次发起RA过程，UE側BI參数都将被复位为0ms。
子头中每一个字段的含义是：
E: Extension field，扩展域。 指示兴许是否还有MAC子头，1表示还有还有一个子头，0表示后面不再有MAC子头。 T: Type field，类型域。 指示MAC子头后面跟的是Backoff Indicator还是RA Preamble ID（即UE上报的Preamble值）。1表示当前MAC子头后面携带了RA Preamble ID，0表示后面携带的是BI指示（Backoff Indicator）。 R: Reserved bit，固定填0。 BI: Backoff Indicator。占4个bit位，范围0-15，左边是高bit位。右边是低bit位（下同）。 RAPID: Random Access Preamble Identifier，随机前导码标识。MSG1携带，占6个bit位，范围0-63。 |
|---|
假设有2个UE正在进行随机接入，且计算得到的RA-RNTI一样，而前导码不一样时。包括RAR的PDU头的格式例如以下所看到的。仅仅有当不同UE的RA-RNTI同样时。RAR消息才干封装到一个MAC-PDU里，不同的RA-RNTI。不能封装在一个MAC PDU中。
payload指1个或多个RAR控制单元，具体个数取决于MAC子头中相应的RAPID的个数。
假设RAR是对2个前导码进行的响应，则MAC PDU须要有2个RAR控制单元。RAR控制单元的格式例如以下。
每一个RAR的长度固定为6个字节。各字段的含义为：
Timing Advance Command：时间提前命令域，占11个bit位。 通知UE进行上行同步的TA值。UL Grant：上行授权，占20个bit位。指示UE用于上行传输MSG3的资源，包括时频位置、是否跳频、功控等參数。低字节Oct2为高bit位，高字节Oct4为低bit位。Temporary C-RNTI：暂时C-RNTI。占16个bit位。UE兴许发送的MSG3消息使用该值加扰。 |
|---|
对于2个RAR的MAC PDU。它的格式例如以下。
20bits的UL GRANT包括的内容有：
– Hopping flag – 1 bit，指示PUSCH是否运行跳频。 – Fixed size resource block assignment – 10 bits，指示MSG3的RB资源分配。与带宽有关，以后会具体介绍。 – Truncated modulation and coding scheme – 4 bits，指示MSG3使用的MCS。 – TPC command for scheduled PUSCH – 3 bits，指示PUSCH的TPC參数。– UL delay – 1 bit。指示MSG3发送时刻。 《LTE-TDD HARQ（1）-上行HARQ时序》已经具体介绍了这个參数的具体含义。– CQI request – 1 bit。 指示UE是否上报CQI。 |
|---|
比方UE接收到的RAR码流为0x410008DC0C212F，则根据协议规则。解析的步骤例如以下：
能够知道。该RAR针对的是PreambleID=1的随机接入响应。UL_GRANT的解析步骤例如以下，当中RIV的解析过程与带宽相关，会在兴许MSG3的相关博文中再专门介绍。
5.參考文献
（1）3GPP TS 36.321 V9.6.0 (2012-03) Medium Access Control (MAC) protocol specification
（2）3GPP TS 36.213 V9.3.0 (2010-09) Physical layer procedures
（3）http://www.mscbsc.com/askpro/response-327421.html
（4）http://www.sharetechnote.com/
发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/168048.html原文链接：https://javaforall.cn
