如何用MSG1发送系统消息

对于Idle和Inactive模式，将有网络控制MSG1或MSG3是否可以用于发送系统消息请求。如果特定于UE需要获取的每个SIB或SIB集合的PRACH前导码和PRACH资源包括在最小SI中，则使用MSG1指示SI请求。如果UE需要获取的特定于每个SIB或SIB集合的PRACH前导码和PRACH资源不包括在最小SI中，则SI请求包括在MSG3中。

对于NR的系统消息，有如下规定：

1.用于其它SI的调度信息包括SIB类型、有效性信息、SI周期性和SI窗口信息，并且无论其它SI是否被周期性地广播都被提供。

2.最小SI中的调度信息包括有关SI块是周期性广播还是按需提供的指示符。

3.如果最小SI指示SIB未被广播，则UE不假设该SIB是在其SI窗口中以每个SI周期周期性地广播的。因此，UE可以发送SI请求以接收该SIB。

4.在发送SI请求之后，为了接收所请求的SIB，UE在该SIB的一个或多个SI周期中监视所请求的SI的SI窗口。

图1说明了使用基于MSG1的SI请求获得按需提供（即不定期广播）的SIB（例如，SIB X）的部署。MSI包括指示SIB X是按需广播还是提供的指示符。在此示例中，指示符设置为“1”，指示SIB X是按需提供的。

• 获取SIB X的UE检查MSI，并基于关于SI块的指示符。

• UE然后基于MSI中的信息确定它必须使用MSG1或MSG3指示SI请求。

• 如果网络希望UE使用MSG 1指示SI请求，则UE需要获取的特定于每个SIB或SIB集合的PRACH前导码和PRACH资源被包括在最小SI中。

• UE然后使用所选择的PRACH前导码和PRACH资源来发送PRACH前同步码。由于闭环功率控制在空闲和非活动状态下是不可能的，因此UE以与任何其他PRACH前导码传输相同的方式基于开环估计来计算SI请求传输的初始功率，并对路径损耗进行完全补偿。

• 在发送指示用于接收SIB X的SI请求的PRACH前导码之后，UE在SIB X中的一个或多个SI周期中监视SIB X（根据调度信息）的SI窗口。

与任何其他PRACH前导码传输类似，gNB可能因为较差的无线信道条件而没有成功接收到用于SI请求的PRACH前同步码传输。UE有两种可能的方法来识别其发送的SI请求是否被gNB成功接收。

方法1：在发送SI请求（即用于接收SIB X的PRACH前导码）之后，UE在SIB X一个或多个SI周期中监视SIB X（根据调度信息）的SI窗口。

• 如果UE没有接收到所请求的SIB X，则它认为gNB没有成功接收到SI请求。

方法2：在发送用于接收SIB X的SI请求即PRACH前导码之后，UE监视用于接收与其PRACH传输相对应的RAR的RAR窗口。与指示SI请求的PRACH传输相对应的RAR应至少包括随机接入前导码标识符（RAPID： random access preamble identifier）。不需要诸如定时提前、C-RNTI等其他信息。UE在RAR窗口中监视由RA-RNTI标识的RAR的NR-PDCCH。对于指示SI请求的PRACH前导码传输，与任何其他PRACH前同步码传输一样，以相同的方式计算RA-RNTI。

• 如果UE接收到RAR，则认为gNB成功接收到SI请求。UE然后（根据调度信息）在SIB X的一个或多个SI周期中监视SIB X中的SI窗口。

• 如果UE未接收到RAR，则认为gNB未成功接收到SI请求。

下面进一步比较这两种用于SI TX故障检测的方法。

检测SI请求传输失败的时延：在方法1的情况下，UE可以在监视所请求SIB的一个或多个SI周期中的SI窗口之后确定SI请求传输是否失败。在方法1中，检测SI请求传输失败的最佳情况（见图2A）时延等于‘SI request processing time’ + ‘length of SI Window’。在方法1中，检测SI请求传输失败的最坏情况（见图2B）时延等于‘SI request processing time-1’ + ‘length of SI period’ + ‘length of SI Window’.。在方法2中，检测SI请求传输是否失败的时延（见图2C）等于‘SI request processing time’ + ‘length of RAR Window’。因此，与方法2相比，方法1中检测SI请求传输失败的时延可能相当高。这可以通过配置更短的SI周期来减少。在较长SI周期的情况下，网络可以组合几个SI请求并广播一次所请求的SIB，从而减少信令开销。这对于较短的SI周期是不可能的。

UE功耗：在两种情况下比较两种方法的UE功耗：SI请求传输成功和SI请求传输失败。

a） 场景1：SI请求传输成功

在方法2中，UE需要首先监视RAR窗口，并且在接收到RAR之后，UE需要监视SI窗口。因此，在方法2中，UE在最坏情况下需要监控的TTI总数等于‘length of RAR window’ + ‘Length of SI Window’。在方法1中，不存在RAR，因此UE只需要监视‘Length of SI Window’ TTI。与方法1相比，方法2的情况下UE功耗更大。然而，如果RAR窗口的长度很小（例如，对于SI请求可以设置为1或2 TTI），则UE功耗可以是可比较的。

b） 场景2：SI请求传输失败

在方法2中，UE需要在发送SI请求之后首先监视RAR窗口。如果未接收到RAR，则假设SI请求传输失败，因此不监视SI窗口。因此，在方法2中，UE需要监视的TTI的总数等于 ‘length of RAR window’。

在方法1中，不存在RAR，因此UE需要在发送SI请求之后监视‘Length of SI Window’ 个TTI。如果SI窗口和RAR窗口的长度相同，则两种方法中的UE功耗相同。然而，SI窗口通常长于RAR窗口，因此与方法2相比，在方法1的情况下UE功耗将更高。

下面的表1总结了两种方法的利弊。

在检测到SI请求未被成功发送之后，UE很自然地重传SI请求（即PRACH前导码传输）。在指示SI请求的PRACH前同步码重传期间，功率像任何其它PRACH前导码重传一样被斜升。

如果即使在发送了用于最大重试次数的SI请求之后，SI请求传输也不成功，则UE可以认为驻留小区不合适，并执行小区重新选择，因为UE无法获得期望的系统信息。在缺少期望的系统信息的情况下，UE不能从驻留小区获得期望的服务（与UE不能获取的系统信息相关联）。