5gnr技术提速最明显：点点滴滴学5G NR随机接入流程之竞争解决流程
5gnr技术提速最明显：点点滴滴学5G NR随机接入流程之竞争解决流程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上下文。 - 切换(竞争)，通过CRNTI RRCReconfigurationComplete； - RRC连接重建，通过RRCReestablishmentRequest； - 上
引言前面讲随机接入流程时提到随机接入主要分为两种类型，一种是非竞争的随机接入；一种是竞争的随机接入，其中 基于非竞争的随机接入过程，preamble是由于gNB专门为UE分配，所以不存在冲突问题；另外又因为该UE已经拥有在接入小区内的唯一标识C-RNTI，所以也不需要gNB给它分配C-RNTI 而基于竞争的随机接入流程在一种可能：即多个UE可能在同一个RACH Occasion(相同的时频资源)上使用相同的PRACH Preamble发送了Msg1，这样的话Msg2中的TC-RNTI就有可能被多个UE使用，所以需要Msg3/4进一步区分UE，为UE指定明确的C-RNTI，避免冲突。本文主要介绍竞争解决的流程
1. Msg3消息介绍之所以称为Msg3，而不是指某一条具体消息的原因，其在于根据UE状态的不同和应用场景的不同，这条消息也可能不同，因此就称为Msg3，即随机接入过程的第3条消息，其在不同场景下的Msg3如下所描述：
- RRC_IDLE态下初始接入，通过RRCSetupRequest；
- RRC_INACTIVE态下恢复接入，通过RRCResumeRequest；
- 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上下文。
2. 竞争解决流程协议38321中根据UE是否拥有合法的CRNTI，竞争解决处理流程主要分以下两种场景
2.1 CCCH SDU在MSG3中传输UE在Msg3上发送CCCH SDU（如RRCSetupRequest等），这些CCCH SDU里面包含竞争解决身份identity， 在这种场景下，在MSG3发送对应PUSCH符号结束之后，则开启ra-ContentionResolutionTimer，在Timer未超时之前，在ra-SearchSpace上检测Temporary C-RNTI的DCI format 1-0，在调度的PDSCH译码正确的情况下，如果解析到UE Contention Resolution Identity MAC CE，且其内容与发送的CCCH SDU两者内容一致，则认为随机接入成功，满足上述条件后，UE会认为随机接入过程成功（如图1所示）。
在随机接入成功之后，停止ra-ContentionResolutionTimer
1. 如果是SI-Request触发的随机接入，则向上层告知系统消息读取请求成功，丢弃其中的Temporary C-RNTI；
2. 否则，将Temporary C-RNTI转化为C-RNTI，C-RNTI为UE在小区中的一个标识，后续网络对UE的DCI调度，其比特级处理过程中的CRC加扰使用C-RNTI加扰；
图1
2.2 C-RNTI MAC CE在MSG3中传输在这种情况下，并不是接收Temporary C-RNTI的DCI/PDSCH进行冲突解决，而是通过接收C-RNTI调度的DCI来判断竞争解决是否成功，如果使用C-RNTI可以成功解出Msg4的PDCCH，就会认为随机接入成功（如图2所示）。
图2
需要主要的是图2中的红色字体部分，当随机接入的场景是PDCCH order或者Beam failure，则msg4为CRNT加扰的DCI信息，如果是其他场景则msg4为CRNT加扰的DCI信息和一个新的UL grant，这个来源于38321协议（如图3所示）。
图3
