基于38523-1协议一致性协议的NR的 层2之MAC概述-1 5GPCT [url=]5GPCT[/url] 微信公众号”5GPCT0”,一起讨论5G协议 作为一个工作6年的通信老兵,在这里分享一个基于38523-1协议一致性协议的NR的 层2之MAC概述-1 以38523-1中的7.1.X.X.X用例来说明下关于MAC的概述 一、 MAC的概述【MAC层的成员】l MAC层的配置是由RRC层控制的 l MAC层处理的信道有: - BroadcastChannel (BCH)广播信道; - Downlink Shared Channel(s) (DL-SCH); - Paging Channel (PCH)寻呼信道; - Uplink Shared Channel(s) (UL-SCH); - Random Access Channel(s) (RACH)随机接入信道 当UE配置了SCG时(NSA模式),UE MAC实体会配置两个MAC 实体,一个用于SCG,一个用于MCG,这两个实体的功能一般(特殊情况除外)是分别独立操作的(即使是双胞胎命运也是不一样的!),他们所对应的每个MAC实体所考虑的Serving Cells, C-RNTI, radiobearers, logical channels, upper and lower layer entities, LCGs, and HARQentities considered和定时器/计数器也是独立设置的, 二、 MAC的服务【MAC层的权力及义务】对于上层,MAC对自己的要求是: l 传数据 l 无线资源的分配 对于物理层,MAC希翼得到的服务是 l data transfer services;【上层传给我,我再传给你】 l signalling of HARQ feedback;【我传给你了,请你给我个反馈(HARQ 反馈)】 l signalling of Scheduling Request;【调度申请,想让我干活,请填电子流】 l measurements (e.g. Channel QualityIndication (CQI)).【请告诉我工作环境怎么样,待遇怎么样,需不需要加班!】 三、 MAC层各种信道的映射(太抽象,暂忽略)四、 MAC的作用【MAC层这玩意是干啥的】1) 随机接入过程因为前面提到,MAC有Random Access Channel(s),所以大家看看在MAC角度的随机接入过程,在任何时间点MAC实体只能有一个随机接入过程(一对一服务!!),如果MAC正在进行随机接入的过程时,又有一个新的随机接入申请,那么是丢掉正在进行的随机接入并开始新的随机接入,还是拒绝新的随机接入保持正在进行的随机接入取决于UE的实现 l 随机接入的初始化: 随机接入分为非竞争型随机接入和竞争型随机接入,两者之间的区别在于基站是否明确指示UE一个非0的前导码,若是分配了有效前导码即是基于非竞争随机接入,若是由UE自主选择一个前导码即是基于竞争随机接入 由协议38321中随机接入的初始时MAC层应该: --刷新Msg3的缓冲区 --设置三个参数:PREAMBLE_TRANSMISSION_COUNTER为1/ PREAMBLE_POWER_RAMPING_COUNTER为1/PREAMBLE_BACKOFF为0ms --如果明确了用于随机接入的载波,则选择通知的载波用于随机接入且将PCMAX 设置为信号载波的 P CMAX,F,C,;如果没有明确且随机接入过程的服务小区配置了 optionalUplink,并且下行链路路径损耗参考的 RSRP 小于rsrp-ThresholdSSB-SUL,则将SUL 载波进行随机接入流程并设置PCMAX 设置为 SUL 载波的 P CMAX,F,C 。 从协议中可以看到UE在每次RA过程中,会维护一个计数器PREAMBLE_TRANSMISSION_COUNTER其范围是【0,preambleTransMax】,一旦超过preambleTransMax这个值就表示RA失败了,这个参数包含在SIB2消息RACH-ConfigCommon中,一般取5次 l 在前导码发送后MAC应该: 由协议38321中随机接入前导码发送后MAC层应该: --在随机接入前导码传输结束时,在 TS 38.213[6]中规定的第一个 PDCCH 场景,启动在RACH-ConfigCommon 中配置的 ra-ResponseWindow,当 ra-ResponseWindow 正在运行时,监视由 RA-RNTI 标识的用于随机接入响应的 SpCell 的 PDCCH --如果随机接入响应包含具有与发送的PREAMBLE_INDEX 相对应的随机接入前导码标识符的 MAC 子PDU,认为此随机接入响应接收成功 --如果在BeamFailureRecoveryConfig 中配置的 ra-ResponseWindow 到期并且未收到发往 C-RNTI 的 PDCCH,则认为此随机接入响应接收失败 从协议中大家可以看到,前导码发送后,MAC会启动一个ra-ResponseWindow,如果期间收RAR则随机接入成功,收不到则表示失败 l 发送MSg3之后,MAC应该: 由协议38321中Msg3发送后MAC层应该: --启动ra-ContentionResolutionTimer 并在 Msg3 传输结束后的第一个符号中的每次 HARQ 重传时重新启动 ra-ContentionResolutionTimer --如果 C-RNTI MAC CE 包含在 Msg3 中,随机接入过程由 MAC 子层本身或 RRC 子层发起,并且 PDCCH 传输被寻址到 C-RNTI 并且包含用于新传输的 UL 许可/随机接入过程是由 PDCCH 命令发起的,并且 PDCCH 传输被寻址到 C-RNTI/波束故障恢复启动了随机接入过程(如子条款 5.17 中所述),并且 PDCCH 传输被寻址到 C-RNTI(以上三种情况)都被认为是随机接入成功 --如果 CCCH SDU 包含在 Msg3 中,并且 PDCCH 传输发送到其 TEMPORARY_C-RNTI,如果 MAC PDU 成功解码,则认为随机接入成功 从协议中大家可以看到,这里涉及到了MAC CE,在基于竞争的随机接入响应中,若是msg3携带CCCH的MAC SDU信息(涉及层三消息),那么必须在解码msg4之前,用TC-RNTI地址解码PDCCH信息(TC-RNTI的有效值为0*0001~0*FFF3之间);而若是msg3携带C-RNTI的MAC CE信息(纯粹MAC层,不涉及层三消息),那么必须在解码msg4之前,用C-RNTI地址解码PDCCH信息,而不采用TC-RNTI,也即手机不理会msg2中分配的TC-RNTI地址 l 完成随机接入流程 完成随机接入流程后,MAC 实体应: --丢弃显式信令无争用随机接入资源,但无争用随机接入资源,用于波束故障恢复请求,如果有的话; --刷新用于在 Msg3 缓冲区中传输 MAC PDU 的 HARQ 缓冲区 -------下面是基于协议38523-1测试基于RRC 的RACH用例:------- 7.1.1.1.1 Correctselection of RACH parameters / Random access preamble and PRACH resourceexplicitly signalled to the UE by RRC / contention free random access procedure7.1.1.1.1-1 测试目的(TP)1. UE在收到SS发送的包含rach-config的RRCReconfiguration消息时,UE可以发送rach-config中的preamble序列 2. UE随机接入失败且 PREAMBLE_TRANSMISSION_COUNTER小于PREAMBLE_TRANS_MAX时,UE重新发起随机接入 7.1.1.1.1-2具体流程描述(TD)(1)Case的前期准备条件PCell1: E-UTRA cell 1 PSCell: NR cell 1/NR cell2 UE: none (2)Case的具体步骤 Preamble:根据38.508-1[4]的通用流程,UE完成E-UTRA的注册后处于链接态(关注微信公众号 “5GPCT” 获取通用流程) Step1: SS传输一个RRCReconfiguration消息通知NR单元1切换到目标NRCell 2,且该消息包括一个RACH-ConfigDedicated (RRCReconfiguration->CellGroupConfig->RACH-ConfigDedicated)
基于38523-1协议一致性协议的NR的 层2之MAC概述-1.pdf
(810.1 KB, 下载次数: 6)
可以看到在RACH-ConfigDedicated中SSb的ra_preambleIndex 被设置为52 Step3: SS在NR小区2上发送随机访问响应 Step4: SS在NR小区2上发送随机访问响应 Step5:UE回RRCReconfigurationComplete 以上就是基于RRC的随机接入,下面看下基于PDCCH order的随机接入 ---------------------------------------------------------------- ----下面是基于协议38523-1测试基于PDCCH order的RACH用例:---- 7.1.1.1.1a Correct selection of RACH parameters / Randomaccess preamble and PRACH resource explicitly signalled to the UE by PDCCHOrder / contention free random access procedure7.1.1.1.1a-2具体流程描述(TD)(1)Case的前期准备条件PCell1: E-UTRA cell 1 PSCell: NR cell 1/NR cell2 UE: none (2)Case的具体步骤 Preamble:根据38.508-1[4]的通用流程,UE完成E-UTRA的注册后处于链接态(关注微信公众号 “5GPCT” 获取通用流程) Step1: SS传输一个RRCReconfiguration消息通知NR单元1切换到目标NRCell 2,且该消息中RACH-ConfigDedicated设置为不存在
Step2:UE发送RRCReconfigurationComplete, Step3:SS在NR-SpCell上发送PDCCH命令(PDCCHorder) Step4:UE发送PRACH Preamble Step5:SS发送RAR 以上是MAC的随机接入部分 -------------相关协议下载------------ 3Gpp 协议网址:http://www.3gpp.org/ftp/
|