系统消息的发送和接收

Overview

在上篇博文“小区同步流程”中我们介绍了终端通过读取候选SSB获取了候选小区下行系统帧的10ms边界，完成了下行同步流程。同时我们也提到了此时终端只知道候选SSB的时频域位置信息，对于小区的其他信息一无所知。为了完成终端在候选小区驻留的目的，终端还需要通过发起随机接入流程和候选小区进行上行同步，而随机接入所需要的相关参数(e.g., preamble信息，PRACH信息等)都需要从系统消息中获取，这其中包括了小区级别的配置信息。

如果大家熟悉LTE的话，就会知道在LTE系统中，SIB消息分为SIB 1/2/3/4......，SIB1为必须发送的SIB消息，该消息携带了一些小区级别的基本消息，同时SIB1主要用来指示后续有哪些SIB消息会周期性发送，终端通过读取SIB1来得知后续还需要读取哪些SIB消息。SIB2中包含了小区级别的信息，包括物理层公共配置信息，上下行信道的公共配置信息以及随机接入相关的配置信息等，因此SIB2在一个LTE小区中也是必须发送的SIB消息。另外最重要的一点是： 在LTE系统中，终端对于所有SIB消息的接收都是被动的，无法主动要求基站发送某条SIB消息。这种SIB消息的发送方式实际上是时频域资源的浪费，因为可能基站发送的某条/某些SIB消息对于接入该基站的某个终端甚至全部终端来说是不需要的，但是基站仍然会周期性地占用时频域资源来发送它们。

针对这种问题，在NR系统中除了延续LTE系统中SIB消息的发送机制，同时又做了以下改进：

1. SIB1作为必须发送的系统消息(由基站主动发送)，也叫做Remaing Minimum System Information(RMSI, 剩余最小系统信息)。SIB1包含了小区级别的配置信息，包括随机接入所需要的配置信息。
2. 其余SIB消息属于非必需消息，也就是说除了SIB1基站必须周期性发送之外，其他的系统消息基站可以像LTE系统一样主动周期性发送；也可以不周期性发送除SIB1外的其他系统消息，将主动权交给终端，一个特定的终端需要什么类型的系统消息，就主动向基站发送请求消息以获取该系统消息，这也被称作按需发送的系统消息(on demand SIBs)。按需发送系统消息的出现省去了周期性发送各种不同周期系统消息的流程，避免了NR系统的时频域资源的浪费。

下面我们就分三部分来说系统消息：MIB，SIB1和其余SIB。
 

MIB

MIB包含在SSB当中，其具体信息如下：

我们在前面的博文中已经大致介绍了SSB的结构和组成，这里我们不再一一叙述，只简单介绍一下MIB的传输机制。

MIB承载在SSB上，使用PBCH物理信道以80ms为周期循环发送。看到这里可能有的朋友会产生疑问：在博文“小区同步流程”中，我们提到过终端在小区初始接入过程中，SSB的发送周期是20ms，而NR中MIB是SSB的一部分，那也就是说MIB的发送周期是20ms，那么为什么这里我们又说MIB是为80ms为周期发送呢？

这是因为这里说的“PBCH以80ms为周期发送MIB”，指的是在这80ms周期内，MIB的编码信息恒定不变，然后每20ms发送一次。检查一下上面的表格大家可以看到MIB信息中仅写到当前系统帧号的高6位，而低4位是放在PBCH的payload里面的。我们举个例子，比如MIB在系统帧100~107中发送，那么应当在系统帧号为100,102,104,106中发送四次。在这四次发送中，MIB信息保持不变，表征系统帧号高6位的字段“systemFrameNumber”的二进制数值始终为‘000110’，PBCH payload中表征系统帧号低四位的二进制数值分别是：‘0100’，‘0110’，‘1000’和‘1010’。

除去终端接入小区的流程中SSB周期默认为20ms之外，SSB的周期还可以配置为其他数值，其周期可以从5ms到最大160ms之间变化。这个主要是通过SIB1或者用于切换流程的信令"ReconfigurationWithSync "中的字段“ssb-PeriodicityServingCell”实现的：

所不同的是SIB1中的“ssb-PeriodicityServingCell”用于指示当前小区的SSB周期，而"ReconfigurationWithSync"中的“ssb-PeriodicityServingCell”用于指示切换流程中的目标小区的SSB周期。 

从博文“小区同步流程”中我们已经知道，一个小区所有的SSB都发生在一个系统帧的5ms之内，而根据SSB pattern的不同，这些SSB的总数可能为4,8，64。为了更加灵活地分配下行时频域资源，一个小区的SSB并不需要按照最大数量配置并发送，也就是说NR系统中的基站可以自主决定在5ms内哪些时频域资源需要预留给SSB并周期性发送，哪些时频域资源不需要预留给SSB，这个概念叫做SSB突发集(SSB Position Burst)。这个概念主要用于FR2也就是毫米波场景，目前的毫米波商用场景，主要是混合波束赋形或者模拟波束赋形，也就是说一个NR基站为了要达到覆盖指定范围区域的目的，必须以波束扫描(beam sweeping)的方式在不同的时间片(即时分复用方式)内将波束指向不同的方向。这些不同的波束上就需要有不同的SSB。此时可以按照一个小区指向不同方向的波束个数来定义需要发送SSB个数，这是通过SIB1中的RRC信令ServingCellConfigCommonSIB实现的：

N.B. 波束相关的概念请阅读博文“波束管理”，更详细的内容我会在后面相关的博文中叙述，这里不会展开介绍波束的识别及选择方面的知识。

RMSI (SIB1)

现在我们来解决从上篇博文就一直遗留的一个问题：如何获取SIB1的时频域位置。SIB1是使用PDSCH来传输的，其对应的PDCCH是使用SI-RNTI加扰的DCI format 1_0。那么我们首先就要知道承载SIB1的PDSCH其对应的PDCCH在时频域的位置，只有知道了PDCCH的信息，才能知道解码SIB1所需要的信息。如果大家看过博文“搜索空间以及终端接收控制信息的流程”，就会知道SIB1的PDCCH所在的CORESET我们称之为CORESET 0,其对应的搜索空间是Type0-PDCCH公共搜索空间(也就是索引为0的搜索空间)。这就意味着我们对SIB1的PDCCH的盲检要在CORESET 0对应的search space 0上进行。

终端目前所接收到的带有明确信息的信令只有MIB消息，那么我们只有在MIB消息里去寻找是否包含CORESET0和search space 0的信息。大家查看一下“MIB”一节中的表格，就可以发现有这么一个字段‘pdcch-ConfigSIB1’,这个字段就是用来指示SIB1相关信息的，具体是怎么实现的呢，我们下面详细叙述。

SIB1在时频域上的资源位置

MIB中的字段'pdcch-ConfigSIB1'拆解如下：

这也就是说，终端从IE：pdcch-ConfigSIB1的4个MSB中获取对应Type0-PDCCH公共搜索空间对应的CORESET 0的RB个数和symbol个数以及CORESET 0在频域上与对应SSB的相对关系，具体对应关系请参考3GPP 38.213 Table 13-1至13-10；同时终端从IE：pdcch-ConfigSIB1的4个LSB中确定Type0-PDCCH公共搜索空间search space 0，具体对应关系请参考Table 13-11至13-15。

 

 

 我们现在对以上表格的一些概念解释一下。

从Table 13-1至13-10可以知道，针对SSB和CORESET在时频域上的复用引入了一个新的概念：SS/PBCH block and CORESET multiplexing pattern，一共有3种：SS/PBCH block and CORESET multiplexing pattern 1、SS/PBCH block and CORESET multiplexing pattern 2和SS/PBCH block and CORESET multiplexing pattern 3。不同的pattern决定了终端监听Type0-PDCCH公共搜索空间方式的不同。

对于SS/PBCH block and CORESET multiplexing pattern 1，终端在从slot 开始的两个连续的slot上监听Type0-PDCCH公共搜索空间上的PDCCH；对于索引为i的SSB，slot 要满足以下条件：

 当时，所在的系统帧为偶数系统帧；

当 时，  所在的系统帧 为奇数系统帧。

其中，

       - 变量M和O在Table 13-11和13-12中给出；

       -  是基于CORESET中接收到的PDCCH的SCS。
       - 以上公式中slot  和 中的CORESET的第一个OFDM符号的索引由Table 13-11和13-12最后一列“First symbol Index”给出；

 对于SS/PBCH block and CORESET multiplexing pattern 2和3，终端在一个slot上监听Type0-PDCCH公共搜索空间上的PDCCH，Type0-PDCCH公共搜索空间的周期等于SSB的周期。

从以上Table可知，Table 13-1~Table 13-10给出了与Type0-PDCCH公共搜索空间相关的CORESET 0在时频域上的位置；Table 13-11~Table 13-15给出了CORESET 0上PDCCH occasion的时域位置。结合这两点终端就可以盲检出传输SIB1的PDSCH对应的PDCCH，从而通过读取相应的DCI信息知道传输SIB1的PDSCH的时频域位置从而解码SIB1。下面我们举几个例子来说明一下：

例1：

前置条件： SSB SCS = 15kHz   PDCCH SCS = 30kHz; ControlResourceSetZero = 0；SearchSpaceZero = 0； frequency bands with minimum channel bandwidth = 10MHz; 工作频段位于FR1且<=3GHz；SS/PBCH block and CORESET multiplexing pattern 1；

     我们首先需要知道Type0-PDCCH公共搜索空间相关联的PDCCH occasion在时域上的位置：

      从博文‘小区同步流程’我们可以知道，对于FR1， SSB SCS = 15kHz的场景，候选SSB的第一个symbol索引为：2,8,16，22。

      时域上，对于SS/PBCH block and CORESET multiplexing pattern 1，UE监听PDCCH开始的slot： ， 上面我们已经知道在本例中SSB的索引 i = 0, 1, 2, 3，查Table 13-11，

由于searchSpaceZero = 0,因此可知Index = 0，从而得到O=0， M = 1。因此对应的和如下：

计算可知CORESET 0所在的系统帧为偶数系统帧，CORESET 0的第一个symbol索引为0；这样我们就得到了对应的CORESET和SSB在时域上的位置如下图所示：

接下来我们需要知道Type0-PDCCH公共搜索空间相关联的PDCCH occasion在频域上的位置： 

根据前置条件我们应该查阅Table 13-2中index = 0的这一行，得到：

 

例2：

前置条件： SSB SCS = 120kHz   PDCCH SCS = 60kHz; ControlResourceSetZero = 8；SearchSpaceZero = 0；SS/PBCH block and CORESET multiplexing pattern 2；工作频段位于FR2；

我们首先需要知道Type0-PDCCH公共搜索空间相关联的PDCCH occasion在时域上的位置：

从博文‘小区同步流程’我们可以知道，对于FR2， SSB SCS = 120kHz的场景，候选SSB的第一个symbol索引为：

           {4,8,16,20} + 28 x n， n = 0,1,2,3,5,6,7,8,10,11,12,13,15,16,17,18

时域上，对于SS/PBCH block and CORESET multiplexing pattern 2，UE监听PDCCH开始的slot，查Table 13-13可知，

从该表我们知道PDCCH occasion所在系统帧和slot满足：

 ；

也就是说PDCCH occasion与索引为i的SSB处于相同的系统帧上的同一个slot上。

CORESET 0的第一个OFDM符号索引为：0，1，6，7；对应的SSB索引分别为：

i = 4k，i = 4k + 1，i = 4k + 2，i = 4k + 3；k = 0,1,...,15

在本例中，当SSB子载波间距SCS = 120 kHz时，SSB索引i和第一个符号索引的对照关系如下图：

 

接下来我们需要知道Type0-PDCCH公共搜索空间相关联的PDCCH occasion在频域上的位置：

根据前置条件我们应该查阅Table 13-7中Index = 8的这一行：

  

 

 
 

这里还需要提醒一下，并不是所有的SSB都有对应的SIB1。为了防止终端浪费时间去监听实际上不存在的SIB1，在PBCH中使用 的数值来判断该PBCH携带的SSB是否存在对应的SIB1。我们知道对于FR1， 的数值范围是0~23；对于FR2，  的数值范围是0~11；那么对于FR1，如果 >23或者对于FR2， >11，此时终端就认为该SSB没有对应的SIB1。

最后我们再看看终端在收到SIB1之后，是如何能确认它所接入的小区的initial BWP的时频域位置的，这里我们仍然以博文“小区同步流程”中引用的技术网站  ShareTechnote中“  SIB1 decoding”一文中的例子：

 在博文“小区同步流程”中，我们已经计算出SSB中心频点位置为3488.16 MHz，底部频点位置为：3484.56 MHz。下面我们一步一步来得出其他信息：

1. 通过信令参数offsetToCarrier = 0，我们可以知道PointA的位置和initial DL BWP的下边界(也就是序号最小的子载波)相同；

2. 因为MIB里面表示的ssb-SubcarrierOffset = 0，我们同时认为在本例中PBCH payload中代表最高位 = 0；这意味着SSB的载波0与initial DL BWP中的CRB 的载波0在频域上的位置相同，因此我们根据信令参数：offsetToPointA = 24就可以得到PointA在频域上的位置为：3484.56 MHz - 24 x 12 x 15 kHz = 3480.24 MHz；

3. 通过信令参数：locationAndBandwidth = 13750和CarrierBandwidth = 51；我们可以得到initial DL BWP的CRB起始位置=0，也就是说PointA在频域上的位置就是initial DL BWP在频域上的起始位置，以及CRB0 = 0；

4.  通过信令参数：subcarrierSpacing = 30 kHz和CarrierBandwidth = 51，我们可以知道initial DL BWP的中心频点位置：3480.24 MHz + (51 x 30 kHz x 12)/2 =  3489.42 MHz

这样终端就获取到了所接入小区的initial DL BWP的频域信息。

 SIB1的传输周期

 SIB1以160ms为周期发送，对于SS/PBCH block and CORESET multiplexing pattern 1，SIB1在160ms周期内每20ms重复传输一次；对于SS/PBCH block and CORESET multiplexing pattern 2和3，SIB1DE 重复传输周期与SSB相同。

其它系统消息

我们前面说过，除去SIB1之外的系统消息都称作‘其它系统消息’。对于其他系统消息基站可以像LTE系统一样主动周期性发送；也可以不周期性发送除SIB1外的其他系统消息，将主动权交给终端，由终端在需要时发起消息请求流程来请求需要的系统消息。下面我们逐一介绍。

周期性发送

其他系统消息使用RRC信令周期性发送的流程与LTE类似，分为以下几个部分：

1. 在SIB1的信令IE：SI-SchedulingInfo中给出需要周期性发送的SIB信息，包括SIB消息的类型、发送周期等。详细内容请看以下表格：

 当信令参数：si-BroadcastStatus设置为'broadcasting'时，对应的由SIB-TypeInfo->type指定的SIB消息由基站周期性发送。信令参数：si-Periodicity指定了SIB消息的发送周期。信令参数si-WindowLength指定了终端接收SIB消息的时间窗口。

2. 基站按照信令参数schedulingInfoList中配置的SIB信息来确定发送对应SIB消息的时间窗口，这里类似于LTE系统，NR也为SIB消息定义了一个SI-window，所有的SIB消息SI-window长度相同。每个SIB消息与一个SI-window相关联，并且不同SIB消息的SI-window在时域上不能重叠，每个SIB消息周期性地在对应的SI-window中传输。一个SI-window在时域上的位置确定如下：

 3. 基站按照步骤2中的每个需要周期性发送的SIB消息，在其对应的si-window中周期性传输，相同周期的SIB消息可以在同一个PDSCH中传输。

按需发送

对于终端而言，首先需要知道哪些SIB消息是需要自己主动发起请求流程来获取的，这仍然是通过SIB1中的SI-SchedulingInfo来实现：

可以看出，终端在成功接收到SIB1之后就可以得知后续有哪些SIB消息是可以周期性接收，哪些是需要自己主动请求才能获取。既然是终端发起请求，那么就需要有上行资源预留给终端。但是终端在读取系统消息的时候只完成了和基站的下行同步，还没有完成(或者说开始)上行同步流程，更谈不上预留上行资源给终端使用了。

针对这种场景，NR设计了使用随机接入的前导序列来作为上行资源传输终端的SIB请求消息。由于preamble消息不能携带RRC信令，因此NR系统是利用为每种on-demannd SIB消息定义了不同的随机接入资源来区分不同的SystemInformationRequest消息，如下：

 N.B. 

1. 随机接入相关的参数我们不在这里详细解释，相关内容放在下篇博文‘随机接入流程’中介绍。

2. 信令参数SI-RequestResources为每个不同的SIB消息定义了不同的preamble索引和RA occasion。终端针对不同的SIB消息使用不同的preamble索引和RA occasion，基站根据接收到的preamble索引以及其所在的RA occasion来判断终端请求的是哪一个具体的SIB。

下面我们来说一下on-demand SIB信令流程，有以下两种场景：

1. MSG1-based SI Request

在Msg1-based S1 Request场景中，终端使用RRC信令SIB1中SI-RequestConfig所提供的preamble来请求SIB消息。一个preamble可以用于获取一个或者多个SIBs。

首先，终端发送一个特定的preamble来请求对应的SIB消息，也就是上图中的Msg 1；在接收到preamble之后，基站使用Msg2回复终端的请求消息并同时根据终端发送的preamble广播对应的SIB消息。当多个终端使用相同的preamble请求相同的SIB消息时，基站可以成功解码该preamble并广播对应的SIB消息，这样所有请求该SIB消息的终端都能接收到请求的SIB消息。由此可见，Msg1-based SI Request的优点是可以避免由于RA资源冲突造成的请求流程失败，并且只需要使用到Msg1和Msg2，节省了信令交互。缺点是需要在基站上行频谱资源中预留所有在SIB1->SI-RequestConfig中配置的随机接入资源，这样在随机接入资源不足时会导致基站性能下降。

 2. MSG3-based SI Request

 在本场景中，终端可以借用基于竞争的随机接入流程来发起on-demand SI请求：

1. 终端发起随机接入，所用的preamble index由终端自己选择。
2. 基站根据接收到的preamble，发送RAR消息给对应的终端。
3. 终端使用RAR中基站提供的上行资源来发送Msg3，这个消息里面携带的是RRCSystemInfoRequest信令而不是rrcSetupRequest信令。
4. 基站发送Msg4(也就是对应Msg3的HARQ-ACK消息)并发送终端请求的SIB消息。

 需要注意的是，Msg3-based SI消息请求流程虽然使得基站不用特意为on-demand SI request流程保留preamble以及相应的随机接入资源，达到了节省上行时频域资源的目的。但是这样就引入了竞争机制，如果发起SI request的终端和别的发起基于竞争的终端使用了相同的preamble和PRACH 资源，这就导致它们都会去接收使用相同RA-RNTI加扰的RAR，从而引入了竞争接入的机制，一旦竞争接入失败，本次on-demand SI request流程就宣告失败，发起SI request的终端就不得不再次发起同一流程。