本文涉及到的內容有：
（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. |
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值。 |
對於2個RAR的MAC PDU。它的格式例如以下。
20bits的UL GRANT包括的內容有：
| - Hopping flag – 1 bit，指示PUSCH是否運行跳頻。
指示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/