21.7 Msg3
基于非竞争的随机接入过程，preamble是某个UE专用的，所以不存在冲突；又因为该UE已经拥有在接入小区内的唯一标识C-RNTI，所以也不需要gNB给它分配C-RNTI。因此，只有基于竞争的随机接入过程才需要步骤三和步骤四。
之所以将3条消息称为Msg3，而不是某一条具体消息的原因，其在于根据UE状态的不同和应用场景的不同，这条消息也可能不同，因此就称为Msg3，即随机接入过程的第3条消息，其在不同场景下的Msg3如下所描述：
- RRC_IDLE态下初始接入，通过RRCSetupRequest；
- RRC_INACTIVE态下恢复接入，通过RRCRRequest；
- RRC连接重建，通过RRCReestablishmentRequest；
- 上行失步，上行数据到达，下行数据到达(竞争)，通过CRNTI；
- 其他SI请求，通过RRCSystemInfoRequest；
- 切换(竞争)，通过CRNTI + RRCReconfigurationComplete；
Msg3中需要包含一个重要信息：每个UE唯一的标识，该标识将用于步骤四的冲突解决。
对于处于RRC_CONNECTED态的UE来说，其唯一标识是C-RNTI。
对于处于RRC_IDLE态的UE来说，将使用一个来自核心网的唯一的UE标识：39比特的ng-5G-S-TMSI-Part1或一个39比特的随机数作为其标识。此时gNB需要先与核心网通信，才能响应Msg3。
对于处于RRC_INACTIVE态的UE来说，将使用一个来自核心网的唯一的UE标识：24比特的resumeIdentity(ShortI-RNTI-Value)或40比特的resumeIndetity(I-RNTI-Value)作为标识，用于恢复UE上下文。
当UE处于RRC_CONNECTED态但上行不同步时，UE有自己的C-RNTI，在随机接入过程的Msg3中，UE会通过C-RNTI MAC control element将自己的C-RNTI告诉gNB，gNB在步骤4中使用这个C-RNTI来解决冲突。
对于Msg3而言，使用CCCH传输的Msg3时，UE还没有C-RNTI，而CCCH传输的Msg3有两种大小，从38.331查看UL-CCCH-Message得知RRC建立请求、RRC恢复请求、RRC重建请求、RRC系统信息请求使用上行CCCH逻辑信道，并且为48比特；而查看UL-CCCH1-Message得知RRC系统信息请求1使用上行CCCH逻辑信道，其大小为64比特，从上文得知，处于RRC_INACTIVE态的UE进行恢复时，其有两种大小的恢复ID，则UL-CCCH-Message中的RRC系统信息请求携带的是24bite的resumeIdentity，UL-CCCH1-Message中的RRC系统信息请求1携带的是40比特的resumeIdentity。
目前文章逐步移至微信公众号更新，有兴趣可扫下面二维码进行关注，谢谢。
