LTE随机接入过程总结完美.docx
《LTE随机接入过程总结完美.docx》由会员分享，可在线阅读，更多相关《LTE随机接入过程总结完美.docx（22页珍藏版）》请在冰豆网上搜索。
LTE随机接入过程总结完美
随机接入过程
一.PRACH
1.PRACH的类型
表1：
PRACH类型
Preambleformat
0
1
2
3
4*
从表1可以看出，Preamble的类型一共有4种，而对于FDD系统之支持0、1、2、3这4类Preamble。
对于Preambleformat0，在时间上占用一个完整的子帧；对于Preambleformat1和2，在时间上占用两个完整的子帧；对于Preambleformat3，在时间上占用三个完整的子帧。
在频域上，Preambleformat0~3均占用一个PRB，即180KHZ的频带，区别是Preambleformat0~3的子载波间隔是1.25KHZ，并占用864个子载波，由于ZC序列的长度是839，因此Preambleformat0~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的类型、Systemframenumber（Even/Any）、Subframenumber。
具体如表2所示：
而对于PRACH的频域位置，协议中由参数
确定，它的取值范围是
。
表2：
randomaccessconfigurationforpreambleformats0~3
PRACHConfiguration
Index
Preamble
Format
Systemframenumber
Subframenumber
PRACHConfiguration
Index
Preamble
Format
Systemframenumber
Subframenumber
0
0
Even
1
32
2
Even
1
1
0
Even
4
33
2
Even
4
2
0
Even
7
34
2
Even
7
3
0
Any
1
35
2
Any
1
4
0
Any
4
36
2
Any
4
5
0
Any
7
37
2
Any
7
6
0
Any
1,6
38
2
Any
1,6
7
0
Any
2,7
39
2
Any
2,7
8
0
Any
3,8
40
2
Any
3,8
9
0
Any
1,4,7
41
2
Any
1,4,7
10
0
Any
2,5,8
42
2
Any
2,5,8
11
0
Any
3,6,9
43
2
Any
3,6,9
12
0
Any
0,2,4,6,8
44
2
Any
0,2,4,6,8
13
0
Any
1,3,5,7,9
45
2
Any
1,3,5,7,9
14
0
Any
0,1,2,3,4,5,6,7,8,9
46
N/A
N/A
N/A
15
0
Even
9
47
2
Even
9
16
1
Even
1
48
3
Even
1
17
1
Even
4
49
3
Even
4
18
1
Even
7
50
3
Even
7
19
1
Any
1
51
3
Any
1
20
1
Any
4
52
3
Any
4
21
1
Any
7
53
3
Any
7
22
1
Any
1,6
54
3
Any
1,6
23
1
Any
2,7
55
3
Any
2,7
24
1
Any
3,8
56
3
Any
3,8
25
1
Any
1,4,7
57
3
Any
1,4,7
26
1
Any
2,5,8
58
3
Any
2,5,8
27
1
Any
3,6,9
59
3
Any
3,6,9
28
1
Any
0,2,4,6,8
60
N/A
N/A
N/A
29
1
Any
1,3,5,7,9
61
N/A
N/A
N/A
30
N/A
N/A
N/A
62
N/A
N/A
N/A
31
1
Even
9
63
3
Even
9
3.Prach在协议中的配置（331协议）
4.PRACHbasebandsignalgeneration
PRACH的时域波形通过下面的公式生成：
其中
是Preamble序列。
而The
rootZadoff-Chusequence被定义为如下式：
如上所述，对于Preambleformat0~3的序列长度
为839，而对于u的取值请参看协议36.211的Table5.7.2-4。
实际上是通过
做循环移位生成的，如下式：
而
的计算方式如下式：
从中可以看出，涉及到unrestrictedsets和restrictedsets，这是由协议中的High-Speed-flag确定的，而参数
是由协议参数zeroCorrelationZoneConfig和High-Speed-flag共同确定的，具体可参考协议36.211Table5.7.2-2。
还有一些其它参数，按照下述的一些公式计算：
当
，则：
当
，则：
5.Preambleresourcegroup
每个小区有64个可用的Preamble序列，UE会选择其中一个在PRACH上传输。
这些序列可以分成两部分，一部分用于基于竞争的随机接入，另一部分用于基于非竞争的随机接入。
用于基于竞争的随机接入的Preamble又分为GroupA和GroupB，这些都是由SIB2中的Rach-ConfigCommon中下发的。
具体可参考图1：
图1：
Preamble分类
分组GroupA和GroupB的原因是为了增加一定的先验知识，从而方便ENB在RAR中给MSG3分配适当的上行资源。
如果UE认为自己的MSG3size比较大（biggerthanthemessageSizeGroupA），并且路损小于一门限，则UE选择GroupB的Preamble，否则选择GroupA的Preamble。
二.随机接入触发的原因
触发随机接入的事件主要有如下6类：
1．初始建立无线连接。
（即从RRC_IDLE态到RRC_CONNECTED，或进行attach）
2．RRC链接重建过程。
（RRCCONNECTEDRe-establishmentprocedure）
3．切换。
（handover）注意：
切换有可能是非竞争或者竞争随机接入，要看RRC_Reconfiguration消息里是否携带了Preambleindex和PrachMaskIndex。
4．RRC_CONNECTED态时，上行不同步，此时下行数据到来。
5．RRC_CONNECTED态时，上行数据到达，但上行不同步或者在PUCCH上没有可用的SR资源。
6．RRC_CONNECTED态时，需要timeadvance。
随机接入又分为基于竞争的和基于非竞争的，基于竞争的应用于上述的前5类事件，而基于非竞争的用于第3、4、6类事件。
三.随机接入过程
首先给出基于竞争的随机接入和非竞争随机接入的基本流程，如下图2图3：
图2：
基于竞争随机接入
图3：
基于非竞争的随机接入
下面详述随机接入的过程：
1．UE发送Preamble，即MSG1
UE要发送Preamble，需要：
1）选择PreambleIndex；2）选择用于发送Preamble的Prach资源；3）确定RA-RNTI；4）确定目标接收功率。
1）确定PreambleIndex
UE会根据Msg3size和路损综合选择用GroupA还是GroupB的Preambleindex，如果之前发生过接入失败，则再次接入时应选择和第一次发送的Preamble相同的Group。
对于非竞争接入，ENB通过RACH-ConfigDedicated中的ra-PreambleIndex字段或者DCIformat1A的PDCCH的PreambleIndex字段来设置UE所使用的Preamble。
需要说明的是，在某些基于非竞争的随机接入中，如果ENB将PreambleIndex配置为0，则UE按照基于竞争的随机接入，自我选择PreambleIndex。
2）PRACH资源选择
首先，prach-ConfigIndex确定了在一个无线帧内，哪些个子帧可以用于sendPrach。
而prachMaskIndex指定了此UE具体用哪个资源，对于prachMaskIndex可以参考表3：
表3：
PrachMaskIndex
对于非竞争的随机接入，ENB会通过RACH-ConfigDedicated中的ra-Prach-MaskIndex字段或者DCIformat1A的PDCCH的PrachMaskIndex字段来设置UE的MaskIndex，从而指名了UE使用哪些Prach资源。
而对于非竞争随机接入如何选择Prach的资源，协议中没有明确指出。
另外，还需要注意，如果非竞争的随机接入配置MaskIndex为0，则UE可以任意选择Prach的时域资源。
物理层的Prachtiming的机制对于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（具体请参看36.321协议）表示ENB接收Preamble时的期望到达功率。
2．UE接收RAR
UE发送Preamble之后，将在RAR的时间窗内监听携带RA-RNTI的PDCCH，以接收自己的RAR，如果在时间窗内没有检测到属于自己的RAR，则认为此次随机接入失败。
RAR的时间窗起始于n+3子帧，并持续ra-ResponseWindowSize个子帧。
具体如图4：
图4：
RAR接收时间窗
那么RAR中会携带什么呢，下面结合RAR的结构详细说明，如图5，为MACRARPDU的完整结构：
图5：
MACRARPDU结构
从上图可以看出，该MACPDU由一个MAC头（MACheader）+0个或多个MACRAR（MACRandomAccessResponse）+可能存在的padding组成。
从MACPDU的结构可以看出，如果eNodeB同一时间内检测到来自多个UE的随机接入请求，则使用一个MACPDU就可以对这些接入请求进行响应，每个随机接入请求的响应对应一个MACRAR。
如果多个UE在同一PRACH资源（时频位置相同，使用同一RA-RNTI）发送preamble，则对应的RAR复用在同一MACPDU中。
MACPDU在DL-SCH上传输，并用以RA-RNTI加扰的PDCCH。
前面已经介绍过，使用相同时频位置发送preamble的所有UE都监听相同的RA-RNTI指示的PDCCH。
MACheader由一个或多个MACsubheader组成。
除了BackoffIndicatorsubheader外，每个subheader对应一个MACRAR。
如果包含BackoffIndicatorsubheader，则该subheader只出现一次，且位于MACheader的第一个subheader处。
BackoffIndicatorsubheader的结构如图6：
图6：
BackoffIndicatorsubheader
BI（BackoffIndicator）指定了UE重发preamble前需要等待的时间范围（取值范围见36.321的7.2节）。
如果UE在RAR时间窗内没有接收到RAR，或接收到的RAR中没有一个preamble与自己的相符合，则认为此次RAR接收失败。
此时UE需要等待一段时间后，再发起随机接入。
等待的时间为在0至BI指定的等待时间区间内选取一个随机值。
（注：
如果在步骤四中，冲突解决失败，也会有这样的后退机制）
RARsubheader结构如图7：
图7：
RARsubheader
RAPID为RandomAccessPreambleIDentifier的简称，为eNodeB在检测preamble时得到的preambleindex。
如果UE发现该值与自己发送preamble时使用的索引相同，则认为成功接收到对应的RAR。
RAR的结构如图8：
图8：
RAR
TC-RNTI用于UE和eNodeB的后续传输。
冲突解决后，该值可能变成C-RNIT。
11-bit的Timingadvancecommand用于指定UE上行同步所需要的时间调整量。
具体可以参考36.213协议。
20bitULgrant指定了分配给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但没有属于自己的RARPDU），UE需要将PREAMBLE_TRANSMISSION_COUNTER加1（如果此时PREAMBLE_TRANSMISSION_COUNTER=preambleTransMax+1，则通知上层随机接入失败），之后在0~BI值之间随机选择一个backofftime，UE延迟backofftime后，再发起随机接入。
对于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中ULgrant包含1bit的字段ULdelay，如果delay为0，则UE会在n+k发送msg3，如果为1，则UE会在n+k后的下一个子帧发送msg3。
msg3在UL-SCH上传输，使用HARQ，且RAR中带的ULgrant指定的用于msg3的TB大小至少为80比特。
msg3中需要包含一个重要信息：
每个UE唯一的标志。
该标志将用于步骤四的冲突解决。
对于处于RRC_CONNECTED态的UE来说，其唯一标志是C-RNTI。
UE会通过C-RNTIMACcontrolelement将自己的C-RNTI告诉eNodeB，eNodeB在步骤四中使用这个C-RNTI来解决冲突。
C-RNTIMACcontrolelement如图10：
图10：
C-RNTIMACcontrolelement
对于非RRC_CONNECTED态的UE来说，将使用一个来自核心网的唯一的UE标志（S-TMSI或一个随机数）作为其标志。
此时eNodeB需要先与核心网通信，才能响应msg3。
对于msg能携带的消息主要有两类，一类主要是UE要带给ENB或者EPC端的一些信令，如RRCConnectionRequest、handover相关等；另一类是用于冲突解决的，比如处于连接态时需要携带C-RNTI，而处于非连接态时需要携带S-TMSI或者一个由UE产生的随机数。
注意：
此时ENB要用TC-RNTI加扰的PDCCH调度UE。
最后，需要注意的是，在MSG3阶段，协议设计了一个定时器Mac-ContentionResolutionTimer，当Mac-ContentionResolutionTimer超时并且还没有收到MSG4时，则认为本次随机接入失败，并择机重新发送Preamble，而当MSG3出现HARQ重传时，此定时器需要复位并重启。
最后再总结一下MSG3可能会携带的东西，主要包括：
C-RNTIMACControlElement、BSRMACControlElement、PHRMACControlElement、还有一些RRC消息等。
4．冲突解决（ENB发送MSG4）
关于这个问题，我认为只要关注如下：
如果在MSG3中携带了UE的C-RNTI，此时UE只要检测到了用C-RNTI加扰的PDCCH，即可以认为冲突解决。
而对于MSG3中携带的是UE的一个标识，此时UE需要检测到UE?
Contention?
Resolution?
IdentityMACControlElement，并且里面携带的信息要和MSG3中的一下才可以认为冲突解决，此时TC-RNTI升级为C-RNTI。
UE?
Contention?
Resolution?
IdentityMACControlElement如图11：
图11：
UE?
Contention?
Resolution?
IdentityMACControlElement
如果冲突解决失败，UE需要将PREAMBLE_TRANSMISSION_COUNTER加1（如果此时PREAMBLE_TRANSMISSION_COUNTER=preambleTransMax+1，则通知上层随机接入失败），之后在0~BI值之间随机选择一个backofftime，UE延迟backofftime后，再发起随机接入。
四.各种可以触发随机接入事件的信令流程
触发随机接入过程的事件有6种，见之前介绍。
触发随机接入过程的方式有3种：
1）PDCCHorder触发；2）MACsublayer触发；3）上层触发。
由PDCCHorder发起的初始随机接入过程（“initiatedbyaPDCCHorder”）只有在如下场景才会发生：
1）eNodeB要发送下行数据时，发现丢失了UE的上行同步，它会强制UE重新发起随机接入过程以获取正确的时间调整量；2）UE定位。
这时eNodeB会通过特殊的DCIformat1A告诉UE需要重新发起随机接入，并告诉UE应该使用的PreambleIndex和PRACHMaskIndex。
由PDCCH触发的随机接入的信令流程如下图（两张图，第一张为基于非竞争的，第二张基于竞争的）：
图12：
基于非竞争
图13：
基于竞争
由MACsublayer发起随机接入过程的场景有：
UE有上行数据要发送，但在任意TTI内都没有可用于发送SR的有效PUCCH资源。
此时上行数据传输的流程变为：
1．UE发送preamble；
2．eNodeB回复RAR，RAR携带了ULgrant信息；
3．UE开始发送上行数据。
什么情况下UE可能没有SR资源呢？
场景一：
从36.331可以看出，SchedulingRequestConfig是一个UE级的可选的IE（optional），默认为release。
如果eNodeB不给某UE配置SR（这取决于不同厂商的实现），则该UE只能通过随机接入来获取ULgrant。
因此，是否配置SR主要影响用户面的延迟，并不影响上行传输的功能！
场景二：
当UE丢失了上行同步，它也会释放SR资源，如果此时有上行数据要发送，也需要触发随机接入过程。
具体的信令流程图如图14所示：
图14：
上行数据要发送时没有SR资源时触发的随机接入流程
上层触发的随机接入过程包括：
1）初始接入；2）RRC连接重建；3）切换。
初始接入的随机接入信令流程如图15所示：
图15：
初始接入的随机接入信令流程
RRC连接重建的随机接入信令流程如图16所示：
图16：
RRC连接重建的随机接入信令流程
HandOver时的随机接入流程（包括基于竞争的和基于非竞争的）：
图17：
HandOver随机接入的信令流程（基于竞争）
图18：
HandOver随机接入的信令流程（基于非竞争的）
升级会员 