1.MSG3的作用
1）向基站提供UE的合法身份辨別以完成接入，擷取相應的注冊服務
2）攜帶發起競争随機接入（CBRA）的原因，如EstablishmentCause、ResumeCause等
2.MSG3類型
MSG3可以分為兩種類型：CCCH SDU、C-RNTI MAC CE + [other]，如表1所示。圖中未标明C-RNTI MAC CE的，均為CCCH SDU。CCCH SDU承載在SRB0上，使用RLC TM模式，在實作時，可在RRC與MAC之間直接互動。這兩種類型除系統消息請求外均需要攜帶UE的身份辨別，這是因為系統消息是廣播發送的，小區内所有UE均可接收，且UE也不需要進入RRC連接配接态。Note：競争同步重配和其他連接配接态的的CBRA的MSG3類型一緻，這裡為了強調切換這種場景，故單獨進行了描述。
表1 NR MSG3内容
(1)RRCSetupRequest(48bits)
該信元用于處于RRC Idle态的UE建立RRC連接配接，使用5G-S-TMSI（5G S-Temporary Mobile Subscription Identifier）的高39bits或者39bits随機值作為UE的身份辨別。5G-S-TMSI由AMF Set ID、AMF Pointer 以及5G-TMSI組成，具體結構如下所示，從其結構組成中可以看出，5G-S-TMSI在AMF内是唯一的。
[5G-S-TMSI] = [AMF Set ID][AMF Pointer][5G-TMSI]
圖1 RRCSetupRequest信元 (2)RRCResumeRequest和RRCResumeRequest1
該信元用于處于RRC Inactive态的UE恢複RRC連接配接。RRC Inactive是LTE的基礎上新增的一種RRC狀态，此狀态的UE僅斷開AS連接配接，NAS層連接配接依然保持，同時基站也會儲存UE的上下文資訊。是以UE建連時，與Idle态相比，基站不需要再次擷取UE能力，不需要重配安全等流程，縮短了接入過程的時延；與connected态相比，不需要測量上報、切換等流程，利于終端節能。UE的Inactive态是由基站控制的，基站可以根據UE目前承載的業務屬性、支援的最大使用者容量等資訊進行判決是否通知connected态UE進入RRC Inactive态。基站通過攜帶參數suspendConfig的RRCRelease消息通知UE進入Inactive态。UE收到該消息後，會存儲C-RNTI、RB等資訊，并挂起除SRB0外的所有RB。當下列事件發生時，UE發起連接配接恢複流程：
✓ 存在需要發送的NAS信令或其他上行資料
✓ 收到NG-RAN paging（如果收到的是核心網paging，UE進入Idle态建連）
✓ RNA更新
UE可以通過RRCResumeRequest或RRCResumeRequest1向基站請求恢複連接配接。這兩個信元的差別展現在參數resumeIdentity，RRCResumeRequest1使用的是40bits的fullI-RNTI，RRCResumeRequest使用的是24bits的shortI-RNTI，基站在suspendConfig會将這兩種RNTI全部通知給UE。UE則根據SIB1中的參數useFullResumeID置是/否為TRUE，來選擇RRCResumeRequest1或RRCResumeRequest。fullI-RNTI由gNB ID和UE ID兩部分組成，可以根據系統部署情況，靈活設定這兩者各自占用的Bit數；shortI-RNT是由full-RNTI截斷形成；一般營運商僅使用其中一種。
圖2 RRCResumeRequest信元
圖3 RRCResumeRequest1信元 (3)RRCReestablishmentRequest 該信元用于RRC Connected态、已激活AS側安全、且建立了SRB2和至少一個DRB的UE繼續保持RRC連接配接态。當下列事件發生時，UE發起連接配接重建流程：
✓ MCG無線鍊路失敗（MAC随機接入失敗屬于該分支）
✓ MCG同步重配失敗，如切換失敗
✓ 從NR小區移動到其他小區失敗
✓ SRB1或SRB2完整性校驗失敗（RRCReestablishment消息除外，因為這會産生死循環）
✓ RRC重配失敗
重建請求通過參數ReestabUE-Identity辨別UE的身份，該參數包含（原）小區的PCI、UE C-RNTI等資訊，如圖4所示。
圖4 RRCReestablishmentRequest信元 (4)RRCSystemInfoRequest
該信元用于非RRC Connected的UE請求OSI（除MIB和SIB1外的其他系統消息）。基站可以根據自身政策（如節能考慮）、部署場景（不同UE對OSI的需求可能不同）等來選擇是按需發送OSI還是周期發送OSI。如果選擇按需發送OSI，且未配置專用RACH資源，則UE需要某個系統消息時，就需要發起MSG3為RRCSystemInfoRequest的競争随機接入。RRCSystemInfoRequest-IEs->requested-SI-List中系統消息的順序與SIB1->SchedulingInfo->schedulingInfoList的順序一緻。當下列事件發生時，UE發起系統消息請求流程：
✓ 小區選擇
✓ 小區重選
✓ 進入小區覆寫範圍
✓ 同步重配完成後
✓ 從其他RAT進入NR小區
✓ 收到系統消息更新訓示
✓ 收到PWS（公衆預警系統）通知，如ETWS 、CMAS
✓ UE沒有收到有效OSI
圖5 RRCSystemInfoRequest信元 (5)C-RNTI MAC CE
對于RRC Connected态UE發起的競争随機接入，MSG3均為C-RNTI MAC CE，該C-RNTI可能是原小區配置設定，也可能為目标小區配置設定的，即切換場景。
圖6 C-RNTI MAC CE
3.MSG3資源
MSG3的資源配置設定在MSG2中介紹了部分，這裡從MSG3與其他PUSCH排程差別的角度，再補充下。
1）時域資源配置設定
✓ MSG3不支援slot aggregation
✓ MSG3對應的PUSCH排程需要在K2的基礎上，額外添加Δ的處理時延
✓ RAR UL grant可以使用Default A PUSCH時域資源配置設定表格，也可以使用pusch-ConfigCommon中配置的時域資源配置設定表格
2）頻域資源配置設定
✓ 目前激活上行BWP如果包含初始上行BWP（CP以及SCS相同），則使用初始上行BWP排程（Note:這裡并不涉及BWP切換）；否則使用目前激活上行BWP排程，但是使用的RB數量不能大于初始上行BWP大小
✓ DCI中頻域資源字段的截斷補長相關操作在DCI中描述
✓ MSG3的排程僅能使用type1頻域資源配置設定方式
3）HARQ
✓ RAR授權預設采用RV=0，HARQ ID=0（包括CFRA）
✓ 對于RAR授權的PUSCH，CFRA是用C-RNTI加擾，CBRA則使用TC-RNTI加擾
✓ MSG3重傳的DCI使用TC-RNTI加擾，基站可以單獨設計MSG3的重傳次數，UE在ra-SearchSpace檢索
4）其他
如果MSG3包含CCCH SDU，則MSG3授權不能小于56bits（如果MSG3是RRCResumeRequest1，則不能小于72bits）
Reference:
[1]3GPP TS 23.003: “Numbering, Addressing and Identification”.
[2]3GPP TS 38.213: “NR; Physical Layer Procedures for control”.
[3]3GPP TS 38.214: “NR; Physical Layer Procedures for data”.
[4]3GPP TS 38.321: “NR; Medium Access Control (MAC); Protocol specification”.
[5]3GPP TS 38.331: “NR; Radio Resource Control (RRC); Protocol specification”.
更多内容，請關注微信公衆号—滄海Radio