5G/NR 随機接入過程之Msg3

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。

目前文章逐漸移至微信公衆号更新，有興趣可掃下面二維碼進行關注，謝謝。