本文涉及到的内容有:
(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/