LTE随机接入过程总结完美

LTE随机接入过程总结完美
LTE随机接入过程总结完美

L T E随机接入过程总结完

The latest revision on November 22, 2020

随机接入过程

一. PRACH

1. PRACH 的类型

从表1可以看出,Preamble 的类型一共有4种,而对于FDD 系统之支持0、1、2、3这4类Preamble 。对于Preamble format 0,在时间上占用一个完整的子帧;对于Preamble format 1和2,在时间上占用两个完整的子帧;对于Preamble format 3,在时间上占用三个完整的子帧。在频域上,Preamble format 0~3均占用一个PRB ,即180KHZ 的频带,区别是Preamble format 0~3的子载波间隔是,并占用864个子载波,由于ZC 序列的长度是839,因此Preamble format 0~3真正占用中间的839个子载波传输Preamble ,而剩余的25个子载波作为两边的保护带宽。

不同类型的Preamble 有长度不一样的CP 和保护间隔,小区的覆盖范围和保护间隔GT 有关,具体可参考如下公式:

R = GT * C / 2

其中,R 为小区半径、GT 为保护间隔、C 表示光速。至于不同类型的Preamble 对应的小区半径可参考如下:

Preamble 格式0:持续时间1ms ,可支持半径约14km ; Preamble 格式1:持续时间2ms ,可支持半径约77km ; Preamble 格式2:持续时间2ms ,可支持半径约29km ; Preamble 格式3:持续时间3ms ,可支持半径约107km ;

2. PRACH 的时频位置

首先给出PRACH 的时域位置,协议中由参数prach-ConfigIndex 给出,每个prach-ConfigIndex 给出了Preamble 的类型、System frame number(Even/Any)、Subframe number 。具体如表2所示:

而对于PRACH 的频域位置,协议中由参数RA

PRBoffset n 确定,它的取值范围是60UL RB RA PRBoffset -≤≤N n 。

表2:random access configuration for preamble formats 0~3

3.Prach在协议中的配置(331协议)

4.PRACH baseband signal generation

PRACH的时域波形通过下面的公式生成:

()()()()∑∑

-=-?+++-=-??=10

21

2,PRACH

ZC CP RA 21

0ZC ZC

)(N k T t f k K k j N n N nk j

v u e e

n x t s ?ππβ

其中)(,n x v u 是Preamble 序列。而The th u root Zadoff-Chu sequence 被定义为如下式:

()10,ZC )

1(ZC

-≤≤=+-N n e

n x N n un j

u π

如上所述,对于Preamble format 0~3的序列长度ZC N 为839,而对于u 的取

值请参看协议的Table 。

)(,n x v u 实际上是通过()n x u 做循环移位生成的,如下式:

)mod )(()(ZC ,N C n x n x v u v u +=

而v C 的计算方式如下式:

CS ZC CS CS CS RA RA

RA RA RA

start shift shift CS shift group shift 0,1,...,1,0for unrestricted sets

0for unrestricted sets

(mod )for restricted sets 0,1,...,1

v vN v N N N N C d v n v n N v n n n ?=-≠??????==????+=+-????

从中可以看出,涉及到unrestricted sets 和restricted sets ,这是由协议

中的High-Speed-flag 确定的,而参数CS N 是由协议参数zeroCorrelationZoneConfig 和High-Speed-flag 共同确定的,具体可参考协议 。还有一些其它参数,按照下述的一些公式计算:

?

??-<≤=otherwise 20ZC ZC p N N p p

d u

当3ZC CS N d N u <≤,则:

????

??()

,)2(max 2CS start RA group ZC RA shift start ZC RA group CS RA shift start CS RA

shift N d n d N n d N n N n d d N d n u u u --==+==

当2)(CS ZC ZC N N d N u -≤≤,则:

????

??()

()

RA shift

CS start RA group RA shift start RA group CS RA shift ZC start CS ZC RA shift ,0,)(max min 2)2(n N d n d n d d n N n d N d N d N n u u u u -==+-=-=

5. Preamble resource group

每个小区有64个可用的Preamble 序列,UE 会选择其中一个在PRACH 上传输。这些序列可以分成两部分,一部分用于基于竞争的随机接入,另一部分用于

基于非竞争的随机接入。用于基于竞争的随机接入的Preamble又分为GroupA和GroupB,这些都是由SIB2中的Rach-ConfigCommon中下发的。具体可参考图1:

图1:Preamble分类

分组GroupA和GroupB的原因是为了增加一定的先验知识,从而方便ENB在RAR中给MSG3分配适当的上行资源。如果UE认为自己的MSG3 size比较大(bigger than the messageSizeGroupA),并且路损小于一门限,则UE选择GroupB的Preamble,否则选择GroupA的Preamble。

二. 随机接入触发的原因

触发随机接入的事件主要有如下6类:

1.初始建立无线连接。(即从RRC_IDLE态到RRC_CONNECTED,或进行attach)

2.RRC链接重建过程。(RRC CONNECTED Re-establishment procedure)

3.切换。(hand over)注意:切换有可能是非竞争或者竞争随机接入,要看RRC_Reconfiguration消息里是否携带了Preamble index和Prach MaskIndex。

4.RRC_CONNECTED态时,上行不同步,此时下行数据到来。

5.RRC_CONNECTED态时,上行数据到达,但上行不同步或者在PUCCH上没有可用的SR 资源。

6.RRC_CONNECTED态时,需要time advance。

随机接入又分为基于竞争的和基于非竞争的,基于竞争的应用于上述的前5类事件,而基于非竞争的用于第3、4、6类事件。

三. 随机接入过程

首先给出基于竞争的随机接入和非竞争随机接入的基本流程,如下图2图3:

图2:基于竞争随机接入

图3:基于非竞争的随机接入

下面详述随机接入的过程:

1.UE发送Preamble,即MSG1

UE要发送Preamble,需要:1)选择Preamble Index;2)选择用于发送Preamble的Prach资源;3)确定RA-RNTI;4)确定目标接收功率。

1)确定Preamble Index

UE会根据Msg3 size和路损综合选择用GroupA还是GroupB的

Preamble index,如果之前发生过接入失败,则再次接入时应选择和第一

次发送的Preamble相同的Group。对于非竞争接入,ENB通过RACH-

ConfigDedicated中的ra-PreambleIndex字段或者DCI format 1A的

PDCCH的Preamble Index字段来设置UE所使用的Preamble。需要说明的是,在某些基于非竞争的随机接入中,如果ENB将Preamble Index配置为0,则UE按照基于竞争的随机接入,自我选择Preamble Index。

2)PRACH资源选择

首先,prach-ConfigIndex确定了在一个无线帧内,哪些个子帧可以用于send Prach。而prach Mask Index指定了此UE具体用哪个资源,对于prach Mask Index 可以参考表3:

表3:Prach Mask Index

对于非竞争的随机接入,ENB会通过RACH-ConfigDedicated中的ra-Prach-MaskIndex字段或者DCI format 1A的PDCCH的Prach Mask Index 字段来设置UE的MaskIndex,从而指名了UE使用哪些Prach资源。而对于非竞争随机接入如何选择Prach的资源,协议中没有明确指出。另外,还需要注意,如果非竞争的随机接入配置MaskIndex为0,则UE可以任意选择Prach的时域资源。

物理层的Prach timing的机制对于Prach时域资源的选择也会有影响,主要注意如下几类:

第一:如果UE在子帧n接收到RAR,但是没有一个响应与其发送的preamble对应,则UE应该在不迟于子帧n+5的时间内重新发送Preamble。

第二:如果UE在时间窗内没有检测到属于自己的RAR,则UE应该在不迟于子帧n+4的时间内重新发送Preamble。

第三:如果随机接入是由PDCCH触发的,则UE将在子帧n+k算起的第一个可用的PRACH子帧发送Preamble,其中k>=2。

而在Mac层协议中,如果UE没有收到RAR,则会选择一定的子帧延迟发送新的Preamble,这个是否和物力层协议中相矛盾呢

此问题和朋朋交流后,认为由高层触发时,采用物理层的机制,而由MAC层触发的时候采用MAC的机制。

3)确定RA-RNTI

RA-RNTI的计算方式如下式:

RA-RNTI= 1 + t_id+10*f_id

其中,t_id表示preamble发送的第一个子帧(0<=t_id<10),而f_id 表示频域位置(f_id<6)。对于FDD,每个子帧只有一个频域资源用来发送

Preamble,因此f_id固定为0。

4)Prach发射功率的确定

上面的公式取定了Prach的发射功率,为UE在子帧i上允许的最大发射功率,而则是UE通过小区参考信号测量出的路损,

而PREAMBLE_RECEIVED_TARGET_POWER(具体请参看协议)表示ENB接收

Preamble时的期望到达功率。

2.UE接收RAR

UE发送Preamble之后,将在RAR的时间窗内监听携带RA-RNTI的PDCCH,以接收自己的RAR,如果在时间窗内没有检测到属于自己的RAR,则认为此次随机接入失败。RAR的时间窗起始于n+3子帧,并持续ra-ResponseWindowSize个子帧。

具体如图4:

图4:RAR接收时间窗

那么RAR中会携带什么呢,下面结合RAR的结构详细说明,如图5,为MAC RAR PDU的完整结构:

图5:MAC RAR PDU结构

从上图可以看出,该MAC PDU由一个MAC 头(MAC header)+ 0个或多个MAC RAR(MAC Random Access Response)+ 可能存在的padding组成。

从MAC PDU的结构可以看出,如果eNodeB同一时间内检测到来自多个UE的随机接入请求,则使用一个MAC PDU就可以对这些接入请求进行响应,每个随机接入请求的响应对应一个MAC RAR。

如果多个UE在同一PRACH资源(时频位置相同,使用同一RA-RNTI)发送preamble,则对应的RAR复用在同一MAC PDU中。

MAC PDU在DL-SCH上传输,并用以RA-RNTI加扰的PDCCH。前面已经介绍过,使用相同时频位置发送preamble的所有UE都监听相同的RA-RNTI指示的PDCCH。

MAC header由一个或多个MAC subheader组成。除了Backoff Indicator subheader外,每个subheader对应一个MAC RAR。如果包含Backoff Indicator subheader,则该subheader只出现一次,且位于MAC header的第一个subheader 处。

Backoff Indicator subheader的结构如图6:

图6:Backoff Indicator subheader

BI(Backoff Indicator)指定了UE重发preamble前需要等待的时间范围(取值范围见的节)。如果UE在RAR时间窗内没有接收到RAR,或接收到的RAR 中没有一个preamble与自己的相符合,则认为此次RAR接收失败。此时UE需要等待一段时间后,再发起随机接入。等待的时间为在0至BI指定的等待时间区间内选取一个随机值。(注:如果在步骤四中,冲突解决失败,也会有这样的后退机制)

RAR subheader结构如图7:

图7:RAR subheader

RAPID为Random Access Preamble IDentifier的简称,为eNodeB在检测preamble时得到的preamble index。如果UE发现该值与自己发送preamble时使用的索引相同,则认为成功接收到对应的RAR。

RAR的结构如图8:

图8:RAR

TC-RNTI用于UE和eNodeB的后续传输。冲突解决后,该值可能变成C-RNIT。

11-bit的Timing advance command用于指定UE上行同步所需要的时间调整量。具体可以参考协议。

20bit UL grant指定了分配给msg3的上行资源。当有上行数据传输时,例如需要解决冲突,eNodeB在RAR中分配的grant不能小于56bit。Gant的结构如图9:

图9:Grant结构

UE随机选择一个preamble用于随机接入,就可能导致多个UE同时选择同一PRACH资源的同一个preamble,从而导致冲突的出现(使用相同的RA-RNTI和preamble,因此还不确定RAR是对哪个UE的响应),这时需要一个冲突解决机制来解决这个问题。冲突的存在也是RAR不使用HARQ的原因之一。

如果UE使用专用的preamble用于随机接入,则不会有冲突,也就不需要后续的冲突解决处理,随机接入过程也就到此结束了。(基于非竞争的随机接入)如果接入过程失败(即在RAR窗内没有收到RAR,或者有RAR但没有属于自己的RAR PDU),UE需要将PREAMBLE_TRANSMISSION_ COUNTER加1(如果此时PREAMBLE_TRANSMISSION_ COUNTER = preambleTransMax + 1,则通知上层随机接入失败),之后在0~BI值之间随机选择一个backoff time,UE延迟backoff time后,再发起随机接入。对于Preamble的发射功率而言,如果没有达到最大的随机接入尝试次数preambleTransMax,则UE将在上次发射功率的基础上,提升功率powerRampingStep来发送下次preamble,以提高发射成功的概率。

3.UE发送MSG3

基于非竞争的随机接入,preamble是某个UE专用的,所以不存在冲突,又因为该UE已经拥有在接入小区内的唯一标志C-RNTI,所以也不需要eNodeB给它分配C-RNTI。因此,只有基于竞争的随机接入才需要步骤三和步骤四。

之所以称为msg3而不是某一条具体消息的原因在于,根据UE状态的不同和应用场景的不同,这条消息也可能不同,因此统称为msg3,即第3条消息。

如果UE在子帧n成功地接收了自己的RAR,则UE应该在n+k的第一个可用的上行子帧发送msg3,而对于FDD系统k为6。需要注意的是,在RAR中UL grant包含1bit的字段UL delay,如果delay为0,则UE会在n+k发送msg3,如果为1,则UE会在n+k后的下一个子帧发送msg3。

msg3在UL-SCH上传输,使用HARQ,且RAR中带的UL grant指定的用于msg3的TB大小至少为80比特。

msg3中需要包含一个重要信息:每个UE唯一的标志。该标志将用于步骤四的冲突解决。

对于处于RRC_CONNECTED态的UE来说,其唯一标志是C-RNTI。UE会通过C-RNTI MAC control element将自己的C-RNTI告诉eNodeB,eNodeB在步骤四中使用这个C-RNTI来解决冲突。C-RNTI MAC control element如图10:

图10:C-RNTI MAC control element

对于非RRC_CONNECTED态的UE来说,将使用一个来自核心网的唯一的UE标志(S-TMSI或一个随机数)作为其标志。此时eNodeB需要先与核心网通信,才能响应msg3。

对于msg能携带的消息主要有两类,一类主要是UE要带给ENB或者EPC端的一些信令,如RRC ConnectionRequest、handover相关等;另一类是用于冲突解决的,比如处于连接态时需要携带C-RNTI,而处于非连接态时需要携带S-TMSI或者一个由UE产生的随机数。注意:此时ENB要用TC-RNTI加扰的PDCCH调度UE。

最后,需要注意的是,在MSG3阶段,协议设计了一个定时器Mac-ContentionResolutionTimer,当Mac-ContentionResolutionTimer超时并且还没有收到MSG4时,则认为本次随机接入失败,并择机重新发送Preamble,而当MSG3出现HARQ重传时,此定时器需要复位并重启。

最后再总结一下MSG3可能会携带的东西,主要包括:C-RNTI MAC Control Element、BSR MAC Control Element、PHR MAC Control Element、还有一些RRC 消息等。

4.冲突解决(ENB发送MSG4)

关于这个问题,我认为只要关注如下:

如果在MSG3中携带了UE的C-RNTI,此时UE只要检测到了用C-RNTI加扰的PDCCH,即可以认为冲突解决。

而对于MSG3中携带的是UE的一个标识,此时UE需要检测到UEContentionResolutionIdentity MAC Control Element,并且里面携带的信息要和MSG3中的一下才可以认为冲突解决,此时TC-RNTI升级为C-RNTI。

UEContentionResolutionIdentity MAC Control Element如图11:

图11:UEContentionResolutionIdentity MAC Control Element 如果冲突解决失败,UE需要将PREAMBLE_TRANSMISSION_ COUNTER加1(如果此时PREAMBLE_TRANSMISSION_ COUNTER = preambleTransMax + 1,则通知上层随机接入失败),之后在0~BI值之间随机选择一个backoff time,UE延迟backoff time后,再发起随机接入。

四. 各种可以触发随机接入事件的信令流程

触发随机接入过程的事件有6种,见之前介绍。

触发随机接入过程的方式有3种:1)PDCCH order触发;2)MAC sublayer触发;3)上层触发。

由PDCCH order发起的初始随机接入过程(“initiated by a PDCCH order”)只有在如下场景才会发生:1)eNodeB要发送下行数据时,发现丢失了UE的上行同步,它会强制UE重新发起随机接入过程以获取正确的时间调整量;2)UE定位。这时eNodeB会通过特殊的DCI format 1A 告诉UE需要重新发起随机接入,并告诉UE应该使用的Preamble Index和PRACH Mask Index。

由PDCCH触发的随机接入的信令流程如下图(两张图,第一张为基于非竞争的,第二张基于竞争的):

图12:基于非竞争

图13:基于竞争

由MAC sublayer发起随机接入过程的场景有:UE有上行数据要发送,但在任意TTI内都没有可用于发送SR的有效PUCCH资源。此时上行数据传输的流程变为:

1.UE 发送preamble;

2.eNodeB回复RAR,RAR携带了UL grant信息;

3.UE开始发送上行数据。

什么情况下UE可能没有SR资源呢

场景一:从可以看出,SchedulingRequestConfig是一个UE级的可选的IE (optional),默认为release。如果 eNodeB不给某UE配置SR(这取决于不同厂商的实现),则该UE只能通过随机接入来获取UL grant。因此,是否配置SR主要影响用户面的延迟,并不影响上行传输的功能!

场景二:当UE丢失了上行同步,它也会释放SR资源,如果此时有上行数据要发送,也需要触发随机接入过程。

具体的信令流程图如图14所示:

图14:上行数据要发送时没有SR资源时触发的随机接入流程

上层触发的随机接入过程包括:1)初始接入;2)RRC连接重建; 3)切换。

初始接入的随机接入信令流程如图15所示:

图15:初始接入的随机接入信令流程

RRC连接重建的随机接入信令流程如图16所示:

图16:RRC连接重建的随机接入信令流程HandOver时的随机接入流程(包括基于竞争的和基于非竞争的):

图17:HandOver随机接入的信令流程(基于竞争)

图18:HandOver随机接入的信令流程(基于非竞争的)

相关主题
相关文档
最新文档