S^2：聊聊3GPP标准化那些事儿——Msg3重复传输

mipha

转自微信公众号 S2微沙龙

今天跟大家聊一聊3GPP Rel-17 NR覆盖增强WI中的Msg3重复传输增强方案。

『关键问题』

3GPP Rel-16及以前的协议并不支撑Msg3重复传输，为使能该特性，主要有两个关键问题：一个是Msg3重复传输请求的识别问题，也即网络侧如何识别出支撑Msg3重复传输的CE（Coverage enhancement）终端发出了Msg3重复传输请求，从而能更有针对性的为它们分配相应的传输资源；另一个问题就是如何指示Msg3的重复传输次数。

『Msg3重复传输请求与识别』

先来看第一个问题，识别问题，这里大家主要考虑初始随机接入情况。

UE在完成小区搜索后，会根据系统消息配置发起随机接入。

这里大家考虑4步随机接入过程，Msg1~Msg4，可以说Msg1是UE跟网络侧的第一次通话，也是Msg3之前与网络侧的唯一通话机会。

那趁着这个机会UE要说些什么，才能让网络侧知道它想进行Msg3重复传输的心情呢？

很遗憾，它说不了什么，它能告诉网络侧的只有一个Preamble序列，而这个序列也只能在网络侧指示的若干个特定时频域位置上才能传输。

但这恰恰也够了，并且以此衍生出两种前期方案：

方案一：为CE终端配置特定的Preamble，并以该序列作为Msg3重复传输请求，当UE判断自己需要进行Msg3重复传输时，采用这些特定的Preamble，否则采用普通的Preamble。

方案二：为CE终端配置特定的PRACH传输时/频域资源，并以此作为重复传输请求。

最终，从方案设计、协议影响等方面综合考虑，选择了方案一。但方案一也有它的缺点，毕竟一个PRACH传输时机上只有64个Preamble，这些Preamble还要拿出一部分用于非竞争随机接入，并且一个PRACH传输时机可能会与多个SSB关联，这些SSB也要瓜分Preamble。因此，方案一可能会在一定程度上导致Msg1的冲突问题。

『Msg3重复传输次数指示』

以上解决了Msg3请求的识别问题，最终是否调度相应用户进行Msg3重复传输，重复传输次数是多少，需要由网络侧决定。也就是说，即使CE终端请求了Msg3重复传输，网络侧依然可以不调度该UE进行Msg重复传输，也即重复传输次数配置为1。

那接下来的问题是，网络侧怎么指示重复传输次数呢？

关于这点，各企业观点在大面上还是比较一致的， 对于Msg3的初传，通过Msg2的RAR UL grant中的某个字段来指示。RAR UL grant的字段内容如下表所示：

RAR grant field	Number of bits
Frequency hopping flag	1
PUSCH frequency resource allocation	14, for operation without shared spectrum channel access 12, for operation with shared spectrum channel access
PUSCH time resource allocation	4
MCS	4
TPC command for PUSCH	3
CSI request	1
ChannelAccess-CPext	0, for operation without shared spectrum channel access 2, for operation with shared spectrum channel access

从上表可以看出，一共有27个比特，且没有冗余比特，也就意味着需要复用现有的字段来指示Msg3重复传输次数。那具体用哪个字段呢？好家伙，这下大家的观点就散开了，除了首尾两个字段，其他所有字段都有相应支撑的企业。

从RAN1 #105次会议开始，形成Working assumption，要从FDRA，TDRA，MCS，TPC或CSI中选一个字段，一直到RAN1 #107历经4次会的讨论，才最终敲定选择MCS字段。

这块内容的讨论进展可谓非常缓慢，基本就是每次会删一个选项。到最后，关于各个指示方案的优缺点已经分析的非常充分了，甚至还专门做了仿真评估。其中最激烈的，就是MCS与TDRA之争，两方的支撑企业数基本一致，各企业也都很坚持，哪方都说服不了另一方改变观点。

其实，不管用MCS还是用TDRA，都有其相应的优劣势，也都能工作，那这种情况怎么办？投票！最终MCS凭借些许优势突围。

笔者对最终的这个结果还是比较认同的，也希翼该方案在将来能发挥出希望的效果。

『Msg3重复传输整体流程小结』

步骤1：UE请求Msg3重复传输。当UE发现下行路损参考的RSRP值低于某一RSRP门限时，在配置的PRACH传输时机上发送特定的Preamble。

步骤2：基站调度Msg3重复传输。当基站检测到特定的Preamble时，判定相应UE发送了Msg3重复传输请求。由基站决定是否调度Msg3重复传输，并通过MCS信息域的最高2位比特指示Msg3重复传输次数（可以为1），MCS域的剩余比特用于指示MCS值。

步骤3：UE获知Msg3传输配置，并根据相应配置进行Msg3传输。

『写在最后』

Rel-17的覆盖增强标准化工作基本已经步入尾声，但是覆盖增强并没有结束，大家Rel-18见！