Study 5, Msg3的PDU为什么是9个字节？

Msg3的PDU为什么是9个字节？

在 UE发送的 RRC Connection Request 信息里包含 UE-Identity 字段，establishmentCause字段和spare字段，这三个字段在 RRCConnectionRequest-r8-IEs。

RRC Connection Request通过逻辑信道UL-CCCH传输。在UL-CCCH-Message中通过选择 0 进入c1再选择 1 进入 RRC Connection Request。

从RRCConnectionRequest出发，选择rrcConnectionRequest-r8需1个比特，此时该比特为0。UE-Identity 字段可能是 s-TMSI 或者 randomValue，选择前者或后者需1个比特，前者或后者均为 BIT STRING (SIZE (40))。establishmentCause字段为3个比特，000-111 分别对应{ emergency, highPriorityAccess, mt-Access, mo-Signalling, mo-Data, delayTolerantAccess-v1020, mo-VoiceCall-v1280, spare1}。RRCConnectionRequest-r8-IEs的spare字段1个比特。

这样在UL-CCCH传输传输的SDU共（1+1+1+1+40+3+1=48比特）6个字节。假设UE-Identity为随机数 C2C04B2ACF，接入原因是mt-Access，那么SDU为 5C 2C 04 B2 AC F4。

eNB如何知道接收的信息是RRC Connection Request？eNB如果能确定接收到的是UL-CCCH-Message，根据SDU结构中的选择比特01就可以确定RRC Connection Request及各个字段。

在SDU加上PDU HEAD信息可以确定逻辑信道和SDU的长度。对于以上的SDU，PDU HEAD为2字节，结构为R/R/E/LCID/F/L ,其中R为保留比特设为0，E为0/1表示HEAD是否结束，LCID为5比特的逻辑信道ID，F=0/1表示长度的格式为短或长，L为SDU字节长度 （36.321）。

实际上PDU的长度由eNB在Msg2（RA-Response）中指示的资源分配来决定。如果UE收到的RA-Response MAC PDU为 61 00 B0 C0 4C 2C 09，UE可以解析出以下信息： 

E = 0(False)

T = 1

RAPID = 33

Timing Advanced = 11

Hopping Flag 0 = False

Fixed Size Resource Block Assignment = 96 (RB Start = 46, RB Length = 2) 

MCS = 2, I_TBS = 2, rv = 0

TPC Command for PUCCH 3 = 0

UL Delay 0 = False

CQI Request = False

T_CRNTI = 11273

这里，RB Length = 2，MCS = 2, I_TBS = 2, rv = 0决定了Msg3的PDU长度，根据标准中的块长度设置（36.213 Table 7.1.7.2.1-1），对应分配的资源块和MCS，PDU的长度为9字节（72比特）。

对于所要传输Msg3，除了SDU 6字节，对应于该SDU的 PDU Head 2字节外，还需要补充1个字节，这个补充字节可直接由一个1字节的填充HEAD来实现。填充HEAD放在SDU前，因为是最后一个HEAD，不需要L域。

SDU的 PDU Head为 2006（0010 0000 0000 0110），这里E=1表示HEAD未结束， 0 0000为CCCH的LCID，F=0为短长度格式，SDU长度6字节；填充HEAD为 1F（0001 1111），这里E=0表示HEAD结束，1 1111为 Padding 的LCID。

因此，该Msg3的PDU为 20 06 1F 5C 2C 04 B2 AC F4。

 ShareTechnote