NR中系统消息如MIB - 可用于无线帧同步等，SIB1 - 小区物理信道公共配置等，是驻留一个小区所必需获得的信息，这类系统信息小区是进行周期性广播。
在SI的配置中，系统消息分为BroadCasting和non-BroadCasting，BroadCasting类系统消息基站也是周期性进行广播的，而non-BroadCasting类系统消息则是通过一种on-demand的方式，即如果需要读取这类系统消息，那么UE需要先发送请求给基站，基站响应UE之后，再下发系统消息。
为什么引入这种on-demand的方式？
NR中引入了Beam的概念，为了支持小区的全覆盖，基站需要在不同的Slot对不同方向的Beam分别广播系统消息，在NR/5G - 广播数据SSB/SIB1/SI/Paging调度小总结文中可以看到这种Beam Sweep的下发方式。
Beam Sweep
在中低频段，Beam的个数为4/8，但是在高频时候，Beam的个数最大为64，那么可以看到，如果采用非广播的方式，可以节省基站的功耗。有预测，到2026年，5G或许会使网络能耗添加150％至170％，增幅最大的是宏基站和数据中心。
另外一方面，如果都采用广播方式，则还需要将PDCCH资源预留以保证系统消息的调度，这些资源不能用于其他PDSCH的调度。
UE是怎么请求读取non-BroadCasting系统消息？
有两种方式。
方式一是通过给系统消息（SI）分配指定的preamble index，UE通过发送PRACH来请求基站下发系统消息，这种基站通过下发MSG2来响应UE，只需要MSG2中的RAPID与UE发送的preamble index一致，则认为基站接收到了UE的请求。
使用方式一，使用的是非竞争性随机接入，不会存在RACH冲突，需要为on demand SI请求预留RACH资源。
方式二是不指定SI对应的preamble index，这种配置下，UE还是通过竞争性随机接入方式来请求，在RAR调度的MSG3中携带需要请求读取的系统消息类型，在随机接入竞争解决成功之后读取系统消息。
基站下发SI的方式可以是广播，在所有的beam方向下发，由于preamble信息中包含了UE期望下行接收的beam方向，基站应该也可以只在UE的beam方向上下发。通过38.311中的描述，UE还是按照SI的配置方式，协议中并未看到对于基站实现的明确描述，在周期性时间点上的SI-Window内读取系统消息。SI的时间位置计算可以参考NR SI Message。
在参考文章1中还介绍了一种Listen Before Request（LBR）机制。UE尝试先在最近一个SI周期的SI-Window内进行读取non-Broadcasting SI，如果未读取到则再通过SI-Request请求基站下发non-Broadcasting SI。
参考文章
1. 《5G On-Demand SI Acquisition Framework and Performance Evaluation》
https://www.researchgate.net/publication/337177632_5G_On-Demand_SI_Acquisition_Framework_and_Performance_Evaluation